[Mono-dev] Question - pass a socket between processes
Hi there, I'm trying to pass a socket from a process to another one, in order to create a front-end server and a back-end server of Plastic SCM. Well, I'm able to do that (thanks to Dick Porter) using the following: new Socket(AddressFamily.Unix, SocketType.Dgram, ProtocolType.IP); then running "sendmsg" with the SCM_RIGHTS set. I'm able to create a UnixStream from the file descriptor of the socket, then use it as a stream. The thing is I'd like to use it as a Socket so that I can use the Socket.BeginReceive method and take advantage of the underlying "epoll" stuff. Is it possible? I tried using si.ProtocolInformation = DataConverter.Pack( "l", (int)AddressFamily.InterNetwork, (int)SocketType.Stream, (int)ProtocolType.Tcp, /*isbound*/ (int)1, (long)fd); Socket result = new Socket(si); But it seems the trick doesn't work :P Ideas will be more than welcome! Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about NetworkStream.BeginRead
I will try to post my findings optimizing the Tcp Channel. Basically, a huge boost is possible, under heavy load (100 concurrent connections, tested with 1200, 1500 and so on), making the initial read async, so you decouple conns from server threads, even if the rest of the message reading is sync. This is step one. Next is clearly limiting the number of worker threads: do not attend the request on the same IOCP thread or threadpool thread but with an specific pool of worker threads, so you're attending all requests with 2,3 threads per core, not more. A server with 300-400 or more threads is only making things even worse. On 16/03/2012 19:08, gelin yan wrote: On Sat, Mar 17, 2012 at 2:03 AM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Ok: the problem is that I was wrapping the NetworkStream with a BufferedStream, and BufferedStream is not async in Mono, while it is async in .NET :( On 16/03/2012 16:57, pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi, I'm working on some changes to make the TcpChannel work in async mode. Instead of changing all the reads and writes to async, I'm just modifying the intial message status read to async, so instead of having a pile of threads waiting for IO on the server (waiting for clients to call or disconnect), there will be only as few threads as running methods. It works great on Windows even under huge load (I'm testing on a 100-nodes cluster on EC2). But, now, trying on Linux simply fails because this call: networkStream.BeginRead(buffer, 0, 6, callback, null); where networkStream is System.Net.Sockets.NetworkStream locks. What it actually does is to block and then invoke the callback, but it doesn't go through until the callback finishes, which I think is not the desired behavior. I'm running: Mono JIT compiler version 2.10.2 (tarball Mon Apr 18 15:12:52 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com http://www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: debugger softdebug LLVM: yes(2.9svn-mono) GC:Included Boehm (with typed GC and Parallel Mark) It fails with older monos too. Obviously I'm doing something wrong. Is there a way I can fix it? Thanks, pablo ___ 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 Hi.. Is it possible to post some benchmarks for that once you fixed your bugs. I am interested in using async socket with mono on Linux..thx. ___ 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] Question about NetworkStream.BeginRead
Hi, I'm working on some changes to make the TcpChannel work in async mode. Instead of changing all the reads and writes to async, I'm just modifying the intial message status read to async, so instead of having a pile of threads waiting for IO on the server (waiting for clients to call or disconnect), there will be only as few threads as running methods. It works great on Windows even under huge load (I'm testing on a 100-nodes cluster on EC2). But, now, trying on Linux simply fails because this call: networkStream.BeginRead(buffer, 0, 6, callback, null); where networkStream is System.Net.Sockets.NetworkStream locks. What it actually does is to block and then invoke the callback, but it doesn't go through until the callback finishes, which I think is not the desired behavior. I'm running: Mono JIT compiler version 2.10.2 (tarball Mon Apr 18 15:12:52 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: debugger softdebug LLVM: yes(2.9svn-mono) GC:Included Boehm (with typed GC and Parallel Mark) It fails with older monos too. Obviously I'm doing something wrong. Is there a way I can fix it? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Question about NetworkStream.BeginRead
Ok: the problem is that I was wrapping the NetworkStream with a BufferedStream, and BufferedStream is not async in Mono, while it is async in .NET :( On 16/03/2012 16:57, pablosantosl...@terra.es wrote: Hi, I'm working on some changes to make the TcpChannel work in async mode. Instead of changing all the reads and writes to async, I'm just modifying the intial message status read to async, so instead of having a pile of threads waiting for IO on the server (waiting for clients to call or disconnect), there will be only as few threads as running methods. It works great on Windows even under huge load (I'm testing on a 100-nodes cluster on EC2). But, now, trying on Linux simply fails because this call: networkStream.BeginRead(buffer, 0, 6, callback, null); where networkStream is System.Net.Sockets.NetworkStream locks. What it actually does is to block and then invoke the callback, but it doesn't go through until the callback finishes, which I think is not the desired behavior. I'm running: Mono JIT compiler version 2.10.2 (tarball Mon Apr 18 15:12:52 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: debugger softdebug LLVM: yes(2.9svn-mono) GC:Included Boehm (with typed GC and Parallel Mark) It fails with older monos too. Obviously I'm doing something wrong. Is there a way I can fix it? Thanks, pablo ___ 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.Runtime.Remoting.Channels.Tcp upgrade to Async
I think Dick's async channel was never integrated. Any interest out there on relaunching it?? Maybe integrating the code + a blog post?? Makes sense? On 23/02/2012 16:00, Robert Jordan wrote: Hi Pablo, On 23.02.2012 14:17, pablosantosl...@terra.es wrote: Hi there, As far as I see here: https://github.com/mono/mono/tree/master/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp the good old TCP channel has been largely untouched for about 4 years now. We use it on a daily basis in Plastic SCM (with some tweaks) but I wonder if there's interest in converting it into Async sockets. We're considering it right now, but my question is also: do you think remoting is dead and should stay this way? Any better alternative? Remoting won't die anytime soon because it's a core part of the AppDomain machinery (I'm still using it in new projects whenever cross-framework compatibility isn't necessary and where security can be handled by another layer). About yours (or Dick Porter's?) Async patch: The problem is there aren't any Remoting maintainers left. I did it in the past (mostly bug fixing), but I'm starting to forget about the details ;) If you want this patch in Mono, you'd have to maintain at least the TcpChannel (monitoring Bugzilla, etc.). OTOH, given how plugable Remoting is, it would be easier to maintain your own AsycTcpChannel instead of risking a maintenance burden... 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.Runtime.Remoting.Channels.Tcp upgrade to Async
I'm thinking on a slightly modified version since the pure async one wasn't able to improve perf. under heavy load. We're currently trying on EC2 with 500 concurrent version control clients against a single Plastic SCM server, and reducing thread count and such will help :) On 23/02/2012 16:00, Robert Jordan wrote: Hi Pablo, On 23.02.2012 14:17, pablosantosl...@terra.es wrote: Hi there, As far as I see here: https://github.com/mono/mono/tree/master/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp the good old TCP channel has been largely untouched for about 4 years now. We use it on a daily basis in Plastic SCM (with some tweaks) but I wonder if there's interest in converting it into Async sockets. We're considering it right now, but my question is also: do you think remoting is dead and should stay this way? Any better alternative? Remoting won't die anytime soon because it's a core part of the AppDomain machinery (I'm still using it in new projects whenever cross-framework compatibility isn't necessary and where security can be handled by another layer). About yours (or Dick Porter's?) Async patch: The problem is there aren't any Remoting maintainers left. I did it in the past (mostly bug fixing), but I'm starting to forget about the details ;) If you want this patch in Mono, you'd have to maintain at least the TcpChannel (monitoring Bugzilla, etc.). OTOH, given how plugable Remoting is, it would be easier to maintain your own AsycTcpChannel instead of risking a maintenance burden... 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
[Mono-dev] System.Runtime.Remoting.Channels.Tcp upgrade to Async
Hi there, As far as I see here: https://github.com/mono/mono/tree/master/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp the good old TCP channel has been largely untouched for about 4 years now. We use it on a daily basis in Plastic SCM (with some tweaks) but I wonder if there's interest in converting it into Async sockets. We're considering it right now, but my question is also: do you think remoting is dead and should stay this way? Any better alternative? We use it because: - It give us high perf (binary serialization, custom serialization of types all the time and so on) - It works like a charm between windows/linux/mac/solaris Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] monodevelop site is down
Hi, Sorry if I'm posting to the wrong list but I can't find Lluis anymore (his novell email seems to be gone). Just let you know that monodevelop.com is down, so people trying to get 2.6 will be in trouble http://monodevelop.com/index.php?title=Download/What's_new_in_MonoDevelop_2.6 pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] TFS code
Hi there, Looong ago I remember I read some Team Foundation Server client code was developed and uploaded to the mono repo. Since we're heavily working on Plastic SCM interop with TFS, Git and others, I'd like to use the TFS Client code to access TFS. Where is it located? I can't find it under olive where I remember it was located... Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono WinForms running on Solaris 11... great!
Hi there, Yes, it's me again talking about Solaris... this time, MWF on Solaris 11. It seems the latest version got rid of some well-known X problems: http://www.facebook.com/album.php?aid=253265id=8260127524saved Enjoy! pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.8 with sgen on Solaris 10 SPARC
Hi all, Just wanted to let you know that our main internal Plastic SCM server has been running now for more than 1 month without issues on Solaris SPARC using Mono 2.8 and sgen! Cheers, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Some screenshots of Mono on Solaris
Hi guys, Please check this: http://codicesoftware.blogspot.com/2010/10/welcome-crazy-monkeys-mono-on-solaris.html for some MWF screenshots on Solaris 10. We've already uploaded the new 2.8 Solaris 10 SPARC package and OpenSolaris x86 package to the mono site so I guess they'll get published soon. Dick is working on Solaris 10 x86 packages too. Enjoy ;) pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Hi,
I got the same issue (Mono/C#) running as root.
On 18/10/2010 0:44, Robert Nagy wrote:
Ignore that diff i just sent, it's stupid, i did not read
the code correctly. Working on something that fixes the problem
correctly.
On (2010-10-18 00:22), Robert Nagy wrote:
You get errno 13 (EACCES) because you are not running it as root
and getpwnam_r will try to give you struct passwd which inludes
the encrypted password of the user so errno will be set to EACCES,
but the other fields will be set.
According to the comment in mph.h getpnam_r only returns ERANGE on
linux and -1 on Mac OS, bt errno == ERANGE was wrong anyways.
On OpenBSD we return 1 until everything is okay and then we return 0.
The following diff fixes OpenBSD and Mac OS too.
diff --git a/support/mph.h b/support/mph.h
index 8a61999..08ce5ea 100644
--- a/support/mph.h
+++ b/support/mph.h
@@ -198,8 +198,8 @@ recheck_range (int ret)
{
if (ret == ERANGE)
return 1;
- if (ret == -1)
- return errno == ERANGE;
+ if (ret != 0)
+ return errno = ERANGE;
return 0;
}
On (2010-10-13 12:56), Jonathan Pryor wrote:
On Wed, 2010-10-13 at 16:38 +0200, pablosantosl...@terra.es wrote:
This is what I get:
$ ./a.out tester
# checking return value 1; errno=13
That's...horribly wrong.
First, what's errno=13? (i.e. what EVALUE is 13? I'm sure OpenBSD has
different values than Linux does.)
Regardless, OpenBSD doesn't appear to be conforming to the standard
here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html
If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error.
The value '1' is likely not the correct errno for ERANGE (Under Linux,
EPERM has the value 1), and since the return value isn't -1
recheck_range() won't check errno against ERANGE either.
However, this does point out a bug in MonoPosixHelper: if getpwnam_r()
returns non-zero it should treat it as an error, which is clearly not
happening here (and is why we're printing garbage data to the screen).
This would only marginally help you, though, as it would result in no
users being found, ever.
The fundamental problem is that Mono_Posix_Syscall_getpwnam_r()'s logic
for checking for ERANGE (so it'll resize the buffer and try the call
again) is failing under OpenBSD, and from what I can see here the
problem is within OpenBSD, not MonoPosixHelper.
Patches welcome to properly support OpenBSD. :-)
- Jon
___
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
[Mono-dev] UnixUserInfo issues in OpenBSD
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] UnixUserInfo issues in OpenBSD
Reading your C code I see once more how powerful C# is... :P
This is what I get:
$ ./a.out tester
# checking return value 1; errno=13
User tester:
pw_name=ÇEðÄ
À
¢
pw_uid=752427404
pw_gid=-809631572
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
$ ./a.out pablo
# checking return value 1; errno=13
User pablo:
pw_name=ÇEðÄ
À
¢
pw_uid=656871820
pw_gid=-809738964
pw_gecos=(null)
pw_dir=(null)
pw_shell=UåSj
We're getting an errno in both cases...
OpenBSD is a cool beast! :P
On 13/10/2010 15:29, Jonathan Pryor wrote:
I have no idea why it's failing. Sorry.
What I can do is send you a C program which closely mirrors what
Mono.Unix is doing. Could you compile and run it, and see if it fails
in the same ways? The program source is attached.
- Jon
On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
Hi all,
The following simple program fails on OpenBSD:
using System;
using Mono.Unix;
public class Info
{
public static void Main()
{
Console.WriteLine(Environment.UserName);
Console.WriteLine(new
UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
}
}
Environment.UserName retrieves the right user.
The two next calls fail saying invalid param:
Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
It seems the problem is the return of the native method getpwuid_r, that
returns 1 instead of 0.
I tried running as root to (suspected it could be a permissions issue)
but I get the same result.
I thought it could be related to an old issue with UnixGroupInfo which
fails if the groups are incorrectly defined (have unexisting users) but
I think this time my config files are correctly set... :O
Thanks,
pablo
___
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] Memory usage differences between GC and OS
Hi all, I could have titled it where my mem has gone? too :P I've been talking to Mark Probst today regarding some issues and questions related to general memory usage. We've been testing sgen for months now and we're currently moving our internal production server to Solaris/SPARC Mono/sgen (MONO_GC_PARAMS=major=copying), after being able to complete our entire PNUnit suite on SPARC. Well, the point of the email is the following: something I've found several times is a situation where GC.GetTotalMemory gives me something like, let's say, 40Mb, then VIRT is something like 200Mb and RES is 80Mb. Mark refreshed me that jitted and non-jitted code will be eating up memory, then metadata and so on... and of course the GC internals with things like free memory lists and so on. But, I think it would be great for application developers to really understand how this is working and where your memory is going, because the diff between 40Mb and 200Mb is simply... huge! Sometimes you find yourself calculating the mem your classes are going to eat, to find out that you're spending more on the uncontrolled part than the one you were carefully designing. On Windows you can use things like Ants memory Profiler to help you figuring out (and most of the time you encounter a HUGE free mem block), but I think it would be great to understand it too on Mono and maybe even be able to tweak it somehow... Boehm GC had the drawback of being unable to free VIRT mem (something we had to fight several times ourselves with Plastic and huge servers), but fortunately that's not the case with sgen, but we still end up with big differences between what gc thinks and what OS thinks. Regards, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage differences between GC and OS
Hi Andreas, As you wrote: That 200Mb isn't memory! It is address space. And as you have about 17592186044416 Mb of address space available on a 64-bit system 200MB isn't much to worry about. Yep, ok, there's a longer story behind: we worked close to the Mono team figuring out several issues in Boehm in the past, specially detecting situations where the lousy way to detect objects it uses is able to mess up the whole thing in seconds and doing something as easy as introducing a long in the stack (passing it as a parameter) ends up with your app eating 1GB of RAM in a second. Fortunately it is not so dramatic with 64bits systems. The thing is: yes, I wouldn't care about VIRT that much but since Boehm doesn't do a very decent work, at the end your real mem keeps growing because GC thinks there's no free mem and so on... Which ends up being a problem. When I start up the process I was talking about, and run a few test iterations, it only needs like 70-80Mb, so I guess all the assemblies are already memmapped here, problem is, as I mention, that it keeps growing, and growing, and growing. And no, it's not due to assembly loading. And it doesn't grow with .NET GC either (on Windows), not at least at the same pace. So, yes, it's not about being concerned by a few Mb here or there, it's about being able to keep real systems running understanding what the memory is being spent on, when GC tells you it's using 1GB but VIRT points to 3Gb and RES to 1.8Gb... These are basically the situations I'm concerned about, the 200Mb ones was just a simple example. Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Git faq updated with workflows
Hi all, I've just posted a very detailed entry describing branch per task. http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html I didn't specifically talk about Plastic so it's perfectly doable with Git too. pablo On 29/07/2010 13:17, pablosantosl...@terra.es wrote: All, I'd strongly recommend you separate every task (every entry on bugzilla) on a separated branch. I'm very used to it since this is the way we work internally in Plastic (and what we do recommend to all our customers). It gives you perfect traceability and flexibility to handle all changes. Git is perfectly capable of handling high number of branches (as plastic is too, something you didn't have with SVN), so I think this one is a perfect solution. Basically it means: you'll be using branches instead of commits as unit of change. Hope it helps, pablo On 29/07/2010 3:52, Andreia Gaita wrote: I've added a couple of simple workflows to our git faq, http://www.mono-project.com/GitFAQ#Workflow . See if these work for you, they should make it easier to avoid merge commits. There are plenty of ways to do things, and these don't include working on forks, although it's not too different. More to come later, opinions welcome. andreia gaita ___ 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] Git faq updated with workflows
All, I'd strongly recommend you separate every task (every entry on bugzilla) on a separated branch. I'm very used to it since this is the way we work internally in Plastic (and what we do recommend to all our customers). It gives you perfect traceability and flexibility to handle all changes. Git is perfectly capable of handling high number of branches (as plastic is too, something you didn't have with SVN), so I think this one is a perfect solution. Basically it means: you'll be using branches instead of commits as unit of change. Hope it helps, pablo On 29/07/2010 3:52, Andreia Gaita wrote: I've added a couple of simple workflows to our git faq, http://www.mono-project.com/GitFAQ#Workflow . See if these work for you, they should make it easier to avoid merge commits. There are plenty of ways to do things, and these don't include working on forks, although it's not too different. More to come later, opinions welcome. andreia gaita ___ 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] Migration to GitHub completed!
Hi all, So, now instead of a svn checkout, in order to build from sources, should we type something like the following? git clone git://github.com/mono/mono.git Is that correct? I guess not really since it's downloading the entire mono repo, which is a terrible overkill, isn't it?? Thanks, pablo On 23/07/2010 8:38, Raja R Harinath wrote: Hi, pablosantosl...@terra.es pablosantosl...@terra.es writes: Congrats Gonzalo!!! Question: how long did the import take?? The actual import run takes about 2-3 hours. The whole process of debugging and fixing the import tool, fine-tuning the import, figuring out mappings between SVN committers and GitHub accounts, etc. took about a month. - Hari ___ 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] Migration to GitHub completed!
Hi Alan, But, now I'm downloading the entire history of mono instead of a single copy of 'master', right? pablo On 28/07/2010 11:24, Alan wrote: Hey, On Wed, Jul 28, 2010 at 10:21 AM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi all, So, now instead of a svn checkout, in order to build from sources, should we type something like the following? git clone git://github.com/mono/mono.git http://github.com/mono/mono.git Is that correct? Yes, this is correct. The download size is a bit bigger than with svn but not significantly so. Note that this single repo is the combination of the old 'mono' and 'mcs' modules which were in SVN. You don't have to make two separate checkouts anymore. Alan I guess not really since it's downloading the entire mono repo, which is a terrible overkill, isn't it?? Thanks, pablo On 23/07/2010 8:38, Raja R Harinath wrote: Hi, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es writes: Congrats Gonzalo!!! Question: how long did the import take?? The actual import run takes about 2-3 hours. The whole process of debugging and fixing the import tool, fine-tuning the import, figuring out mappings between SVN committers and GitHub accounts, etc. took about a month. - Hari ___ 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] Migration to GitHub completed!
Excellent! On 28/07/2010 11:32, Jérémie Laval wrote: Yes you are but if you aren't interested in contributing with this repository (no pushing or pulling from) you can pass the --depth 1 switch to git clone which will only fetch one revision (that is HEAD). You will still be able to pull from github but that's pretty much it. -- Jérémie Laval jeremie.la...@gmail.com mailto:jeremie.la...@gmail.com http://neteril.org On Wed, Jul 28, 2010 at 11:26 AM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi Alan, But, now I'm downloading the entire history of mono instead of a single copy of 'master', right? pablo On 28/07/2010 11:24, Alan wrote: Hey, On Wed, Jul 28, 2010 at 10:21 AM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi all, So, now instead of a svn checkout, in order to build from sources, should we type something like the following? git clone git://github.com/mono/mono.git http://github.com/mono/mono.git http://github.com/mono/mono.git Is that correct? Yes, this is correct. The download size is a bit bigger than with svn but not significantly so. Note that this single repo is the combination of the old 'mono' and 'mcs' modules which were in SVN. You don't have to make two separate checkouts anymore. Alan I guess not really since it's downloading the entire mono repo, which is a terrible overkill, isn't it?? Thanks, pablo On 23/07/2010 8:38, Raja R Harinath wrote: Hi, pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es writes: Congrats Gonzalo!!! Question: how long did the import take?? The actual import run takes about 2-3 hours. The whole process of debugging and fixing the import tool, fine-tuning the import, figuring out mappings between SVN committers and GitHub accounts, etc. took about a month. - Hari ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto: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 mailto: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] Playing with Mono.Terminal, no success
Hi,
Any updates on this?
Thanks,
pablo
On 11/05/2010 9:21, pablosantosl...@terra.es wrote:
Hi Miguel,
Well, here's my code (I tried a different example than the one sent before)
using System;
using Mono.Terminal;
namespace clustermgr
{
class MainClass
{
public static void Main(string[] args)
{
Application.Init(false);
Dialog d = new Dialog (40, 8, Print);
Button b = new Button (All Pages);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
b = new Button (Current Page);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
Application.Iteration += delegate {
Application.Refresh();
};
Application.Run(d);
}
}
}
Problem is that the app ends immediately, I don't see anything on the
screen... Maybe I'm just misunderstanding the whole thing, I don't know...
pablo
On 10/05/2010 20:33, Miguel de Icaza wrote:
Hello,
I'm trying the simple sample at: http://www.mono-project.com/MonoCurses
Application.Init (false);
Dialog d = new Dialog (40, 8, Hello);
d.Add (new Label (0, 0, Hello World));
Application.Run (d);
on an OpenSuse box.
But it doesn't work for me, it just exits and breaks the terminal... :-(
Run your program like this to make sure it does not leave you in a
broken state:
mono sample.exe; stty sane
Please post a full sample and I'll take a look at 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] Playing with Mono.Terminal, no success
Hi Miguel,
Well, here's my code (I tried a different example than the one sent before)
using System;
using Mono.Terminal;
namespace clustermgr
{
class MainClass
{
public static void Main(string[] args)
{
Application.Init(false);
Dialog d = new Dialog (40, 8, Print);
Button b = new Button (All Pages);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
b = new Button (Current Page);
b.Clicked += delegate {
d.Running = false;
};
d.AddButton (b);
Application.Iteration += delegate {
Application.Refresh();
};
Application.Run(d);
}
}
}
Problem is that the app ends immediately, I don't see anything on the
screen... Maybe I'm just misunderstanding the whole thing, I don't know...
pablo
On 10/05/2010 20:33, Miguel de Icaza wrote:
Hello,
I'm trying the simple sample at: http://www.mono-project.com/MonoCurses
Application.Init (false);
Dialog d = new Dialog (40, 8, Hello);
d.Add (new Label (0, 0, Hello World));
Application.Run (d);
on an OpenSuse box.
But it doesn't work for me, it just exits and breaks the terminal... :-(
Run your program like this to make sure it does not leave you in a
broken state:
mono sample.exe; stty sane
Please post a full sample and I'll take a look at it.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Playing with Mono.Terminal, no success
Hi there, I'm trying the simple sample at: http://www.mono-project.com/MonoCurses Application.Init (false); Dialog d = new Dialog (40, 8, Hello); d.Add (new Label (0, 0, Hello World)); Application.Run (d); on an OpenSuse box. But it doesn't work for me, it just exits and breaks the terminal... :-( pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] some sysctl fixes for OpenBSD
Robert,
I tried to reach you using your email but I get tons of errors.
Are you able to build latest Mono on OpenBSD now? Are you going to
maintain it?
Thanks,
pablo
On 08/04/2010 10:42, Robert Nagy wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
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 sysctl fixes for OpenBSD
Cool! We recently added a FreeBSD box to our collection of test machines
and I've a OpenBSD with an old Mono (a port, which compiled at first
shot) but I had some issues (it doesn't work exactly like the FreeBSD
one for some reason). I'd love to see Plastic SCM running on OpenBSD
soon so I'll definitely will give it a try.
pablo
On 08/04/2010 13:33, Robert Nagy wrote:
Hey
Yeah we have been using it for quiet some time now. Both 2.6.3 and svn HEAD
works just fine now.
On (2010-04-08 12:51), pablosantosl...@terra.es wrote:
Robert,
I tried to reach you using your email but I get tons of errors.
Are you able to build latest Mono on OpenBSD now? Are you going to
maintain it?
Thanks,
pablo
On 08/04/2010 10:42, Robert Nagy wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] sgen progress
Hi all, Yesterday night I had the opportunity to make a tiny contribution to Mark's big effort on sgen implementation. We were running a heavy load test consisting on 80 plastic scm clients working against a single server, which was using sgen. The test has been run several times already but yesterday: it worked fine!! More than 10 hours working non stop, allocating and releasing memory and being able to keep a much lower mem-footprint than its Boehm counterpart There're still many things to work on but... sgen is coming!! Congratulations! pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Could not load type 'System.Data.SchemaSerializationMode' with Mono 2.6
Hi there, We're sending a DataSet with remoting from a server (built with 2.0 profile) to a client (built with 1.0 profile) and we get this: Could not load type 'System.Data.SchemaSerializationMode' It wasn't happening prior to mono 2.6. There were any changes on 2.6 that could be changing this behaviour? Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Boehm GC reaching max_map_count
Hi there, We're experiencing problems with a server running on a 64bits box with plenty of RAM. After a few hours it crashed and the problem was that it was reaching the max_map_count limit. We raised it to two times the default (64k) but it also crashed. The problem is the following: normally the process has a number close to 100 or 200 mappings, but then, in less than a second, it grows beyond the limit and crashes. The process is not allocating memory (it stays stable although quite high) at this point, so we think it must be related to BoehmGC doing some collection or something. The process is heavily multithreaded. Mono is built with --with-large-heap and runs on a 64 bits box (where the pointer guessing issues with BoehmGC don't hit us so strongly as it happens on 32 bit systems). Well, anyone has any idea why this is happening? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing Mono 2.6.1 Solaris packages
Hi! I'm more than happy to announce that we've just released Mono 2.6.1 packages for Solaris 10 SPARC and OpenSolaris x86!! I expect Solaris 10 x86 to be following soon. They're both available at the Mono downloads page already! They're easy to build from sources, but even easier to install from a package!! :-P. Thanks Dick for making it happen. Feedback will be welcome. We'd like to see mono packages for all Unix flavors ready to install, and since we're successfully running on FreeBSD, it will probably be next... Enjoy, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] soft debugger
Hi there, On which platforms is the soft debugger supported? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] soft debugger
on every OS or just Linux?? I know it's on Mac too, we're using it! :-) On 21/02/2010 23:15, Zoltan Varga wrote: On amd64/x86/arm. Zoltan On Sun, Feb 21, 2010 at 11:10 PM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi there, On which platforms is the soft debugger supported? Thanks, pablo ___ 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] Building Mono trunk on FreeBSD
Up and running! :-) On 10/02/2010 10:28, Robert Jordan wrote: On 10.02.2010 00:29, pablosantosl...@terra.es wrote: Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory You need bash. Look at /mcs/tools/gensources.sh. 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] Building Mono trunk on FreeBSD
It's fixed, thanks! :-) On 10/02/2010 12:43, Andrés G. Aragoneses wrote: So the configure script is missing the check for Bash? Maybe we should add something like http://lists.freedesktop.org/archives/xorg/2008-March/033417.html Regards El 10/02/10 12:27, pablosantosl...@terra.es escribió: Up and running! :-) On 10/02/2010 10:28, Robert Jordan wrote: On 10.02.2010 00:29, pablosantosl...@terra.es wrote: Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory You need bash. Look at /mcs/tools/gensources.sh. 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Process.GetCurrentProcess().MainModule.FileName broken on 2.6.1 on FreeBSD
It still failed on 2.4.3 We'll try to fix it. pablo On 10/02/2010 21:10, Rodrigo Kumpera wrote: Hi Pablo, On Wed, Feb 10, 2010 at 6:05 PM, psant...@codicesoftware.com mailto:psant...@codicesoftware.com psant...@codicesoftware.com mailto:psant...@codicesoftware.com wrote: Hi there, [tes...@freebox ~/test]$ ../mono/bin/mono main.exe Unhandled Exception: System.ArgumentOutOfRangeException: Index is less than 0 or more than or equal to the list count. Parameter name: index 0 FreeBSD is not a supported OS, it basically works by virtue of been very similar to OSX. So, if you're lucky, and fails on OSX, just file a bug report and we'll work on it. Beyond that, all we can do is to gladly accept patches from the community. Rodrigo ___ 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] Building Mono trunk on FreeBSD
Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory Creating ../../build/deps/System.ServiceModel.Web_test_net_2_0.dll.response ... Creating ../../build/deps/System.ServiceModel.Web_test_net_2_0.dll.makefrag ... gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' Creating ../../build/deps/net_2_0_System.ServiceModel.Web.dll.makefrag ... gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake all-local gmake[8]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' MCS [net_2_0] System.ServiceModel.Web.dll error CS2008: No files to compile were specified gmake[8]: *** [../../class/lib/net_2_0/System.ServiceModel.Web.dll] Error 1 gmake[8]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/usr/home/pablo/monosrc/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[4]: *** [profile-do--net_2_0--all] Error 2 gmake[4]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/usr/home/pablo/monosrc/mono/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/pablo/monosrc/mono' gmake: *** [all] Error 2 On 09/02/2010 21:17, pablosantosl...@terra.es wrote: Ok, I'll give it a try On 09/02/2010 20:04, Zoltan Varga wrote: Hi, I'm pretty sure mono requires GNU make, and might not work with bsd's own make. Zoltan On Tue, Feb 9, 2010 at 6:19 PM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi there, I'm trying to build trunk on FreeBSD. Here's what I got. I'm not an expert on FreeBSD so I might be doing something wrong. $ uname -a FreeBSD freebox.codicesoftware.com http://freebox.codicesoftware.com 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 (cd .libs rm -f libMonoSupportW.la ln -s ../libMonoSupportW.la libMonoSupportW.la) Making all in data Making all in net_2_0 Making all in Browsers Making all in runtime d=`cd ../support pwd`; sed 's,target=libMonoPosixHelper[^]*,target='$d/libMonoPosixHelper.la',' ../data/config etc/mono/configt if test -z ; then :; else sed 's,configuration, dllmap dll=gdiplus.dll target= /,' etc/mono/configt etc/mono/configtt; mv -f etc/mono/configtt etc/mono/configt; fi mv -f etc/mono/configt etc/mono/config /bin/sh ../mkinstalldirs _tmpinst/bin mkdir -p -- _tmpinst/bin cp mono-wrapper _tmpinst/bin/mono echo '#! /bin/sh' _tmpinst/bin/ilasm ; r=`pwd`; m=`cd ../../mcs pwd`; echo 'exec '$r/_tmpinst/bin/mono' '$m/ilasm/ilasm.exe' $@' _tmpinst/bin/ilasm ; chmod +x _tmpinst/bin/ilasm echo '#! /bin/sh' _tmpinst/bin/gmcs ; r=`pwd`; m=`cd ../../mcs pwd`; echo 'exec '$r/_tmpinst/bin/mono' '$m/class/lib/net_2_0/gmcs.exe' $@' _tmpinst/bin/gmcs ; chmod +x _tmpinst/bin/gmcs echo '#! /bin/sh' _tmpinst/bin/al2 ; r=`pwd`; m=`cd ../../mcs pwd`; echo 'exec '$r/_tmpinst/bin/mono' '$m/class/lib/net_2_0/al.exe' $@' _tmpinst/bin/al2 ; chmod +x _tmpinst/bin/al2 if test -w ../../mcs; then :; else chmod -R +w ../../mcs; fi cd ../../mcs make NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5 net_2_1_raw ' CC='gcc' all-profiles Makefile, line 66: Need an operator Makefile, line 68: Need an operator Makefile, line 70: Need an operator Makefile, line 72: Need an operator build/rules.make, line 45: Need an operator build/rules.make, line 47: Need an operator build/rules.make, line 55: Need an operator build/rules.make, line 56: Need an operator build/rules.make, line 57: Need an operator build/rules.make, line 58: Need an operator build/rules.make, line 59: Need an operator build/rules.make, line 60: Need an operator build/rules.make, line 61: Need an operator build/rules.make, line 62: Need an operator build/rules.make, line 63: Need
Re: [Mono-dev] Building Mono trunk on FreeBSD
Actually the problem was that the script for webbrowser assumes /bin/bash but in FreeBSD it's /usr/local/bin/bash... ouch! On 10/02/2010 0:36, Zoltan Varga wrote: Hi, Its possible that we depend on the behavior of some system utils as well, I don't known which, since the file list is stored in a file and read from there. Zoltan On Wed, Feb 10, 2010 at 12:29 AM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory Creating ../../build/deps/System.ServiceModel.Web_test_net_2_0.dll.response ... Creating ../../build/deps/System.ServiceModel.Web_test_net_2_0.dll.makefrag ... gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' Creating ../../build/deps/net_2_0_System.ServiceModel.Web.dll.makefrag ... gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake all-local gmake[8]: Entering directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' MCS [net_2_0] System.ServiceModel.Web.dll error CS2008: No files to compile were specified gmake[8]: *** [../../class/lib/net_2_0/System.ServiceModel.Web.dll] Error 1 gmake[8]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[7]: *** [do-all] Error 2 gmake[7]: Leaving directory `/usr/home/pablo/monosrc/mcs/class/System.ServiceModel.Web' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/usr/home/pablo/monosrc/mcs/class' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[4]: *** [profile-do--net_2_0--all] Error 2 gmake[4]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[3]: *** [profiles-do--all] Error 2 gmake[3]: Leaving directory `/usr/home/pablo/monosrc/mcs' gmake[2]: *** [all-local] Error 2 gmake[2]: Leaving directory `/usr/home/pablo/monosrc/mono/runtime' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/pablo/monosrc/mono' gmake: *** [all] Error 2 On 09/02/2010 21:17, pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Ok, I'll give it a try On 09/02/2010 20:04, Zoltan Varga wrote: Hi, I'm pretty sure mono requires GNU make, and might not work with bsd's own make. Zoltan On Tue, Feb 9, 2010 at 6:19 PM, pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es mailto:pablosantosl...@terra.es wrote: Hi there, I'm trying to build trunk on FreeBSD. Here's what I got. I'm not an expert on FreeBSD so I might be doing something wrong. $ uname -a FreeBSD freebox.codicesoftware.com http://freebox.codicesoftware.com http://freebox.codicesoftware.com 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 16:02:27 UTC 2010 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 (cd .libs rm -f libMonoSupportW.la ln -s ../libMonoSupportW.la libMonoSupportW.la) Making all in data Making all in net_2_0 Making all in Browsers Making all in runtime d=`cd ../support pwd`; sed 's,target=libMonoPosixHelper[^]*,target='$d/libMonoPosixHelper.la',' ../data/config etc/mono/configt if test -z ; then :; else sed 's,configuration, dllmap dll=gdiplus.dll target= /,' etc/mono/configt etc/mono/configtt; mv -f etc/mono/configtt etc/mono/configt; fi mv -f etc/mono/configt etc/mono/config /bin/sh ../mkinstalldirs _tmpinst/bin mkdir -p -- _tmpinst/bin cp mono-wrapper _tmpinst/bin/mono echo '#! /bin/sh' _tmpinst/bin/ilasm ; r=`pwd`; m=`cd ../../mcs pwd`; echo 'exec '$r/_tmpinst/bin/mono' '$m/ilasm/ilasm.exe' $@' _tmpinst/bin/ilasm ; chmod +x _tmpinst/bin/ilasm echo
Re: [Mono-dev] Fundamental performance problems with Mono
Hi, Could you also share some test code so we can gain a better understanding of the issue/s? Thanks, pablo On 07/01/2010 16:37, zvikag wrote: Hello all, The bottom line of this message is that I don't see how can one write a high-performance socket server in Mono... Here is the story: I am writing a proxy server using .NET Socket API. This proxy does almost entirely I/O work - copying buffers from one socket to another. Now, Mono doesn't implement the newer http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs.aspx XXXAsync Socket API that was introduced in .NET 2.0 SP1 (or more accurately, implements it http://www.mail-archive.com/mono-l...@lists.ximian.com/msg28621.html perfunctorily ). So I was left to use the APM Socket API which produces tons of garbage objects under heavy load. When testing the server on Linux under load we saw very frequent CPU bursts that crippled the throughput of the server. After profiling with the mono built-in profiler I confirmed that the reason for the high CPU usage was the GC collections that got more and more frequent and took more and more time. I then read a little bit and realized that the Mono GC is non-generational which might explain the long GC cycles (if it was generational it could have collected the garbage objects that were created during async socket operations in generation 0 and probably stop there, but it has to traverse the entire managed heap). So the combination of the non-generational GC and the unimplemented XXXAsync Socket API result in very poor performance of the Mono server. The maximum throughput of the server with Mono on Linux is about half of that on Windows using .NET. I attached the GC stats and profiling results of a 15 minute run. http://old.nabble.com/file/p27026906/profile_alloc.log profile_alloc.log http://old.nabble.com/file/p27026906/gc_stats.log gc_stats.log Can you help me out here? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interactive C# shell for server monitoring
Sure, I've seen that. My question is if anyone already played with it, introducing it into an app and giving a network access to it. Jb Evain wrote: Hey Pablo, On 11/11/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Any experience anyone using Interactive C# shell (http://www.mono-project.com/CsharpRepl) embedded into a server process for monitoring purposes (accessible through a socket maybe?) It's doable using the attach functionality of Mono: http://tirania.org/blog/archive/2008/Sep-29.html ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interactive C# shell for server monitoring
Ok, thanks Miguel. Miguel de Icaza wrote: Hello, Sure, I've seen that. My question is if anyone already played with it, introducing it into an app and giving a network access to it. The problem today with CSharp and attach is that it is not integrated with the main loop of an application, so it is inherently unsafe. For Gtk# based applications, since we know that there is a main loop, we plug naturally into the main loop, so it is not an issue, but with server applications it is anyone's guess what kind of event processing exists. In those cases, it would be best if the specific server application provides an explicit interface to get C# source and evaluate it. Miguel. ___ 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?
I agree (especially thinking about the chunk-pool I mentioned) having separate classes can be better, so that everyone can choose. Andreas Nahr wrote: I'm still not sure this is a good idea. A lot of this depends on the use-case for MemoryStream. If 1) A MemoryStream is created with a parameterless constructor and then a lot of data written to it multiple times the ChunkedStream will be better always. 2) If a MemoryStream is created with a parameterless constructor and only gets a few bytes long ChunkedStream might bring considerable overhead. 3) If MemoryStream is created with a fixed size then ChunkedStream will be somewhat, but acceptably slower and have a higher overhead. But it will be totally abysmal once GetBuffer comes into play. 4) If MemoryStream is constructed from a (large) byte array (in the scientific field I'm coming from this is by far the most common usage I've seem; that is basically using MemoryStream as a (read-only) Stream-Wrapper around a byte array) then performance will be abysmal when constructing (if you chunkify e.g. a 500MB byte array) AND again with GetBuffer (recreate the array). So would be O (n) or even O (2*n) instead of O (0). It might be possible to create an implementation that can deal with all this (would need to have variable sized buffers, keep things it gets passed in the constructor alive with small overhead, etc.), but it will be quite complex and come with a large base overhead. And even then the GetBuffer O(n) problem remains in a few scenarios. Maybe it would be better to just leave the class as is and document that for certain scenarios alternative implementations are available that do a MUCH better job. Everybody can easily replace the use of MemoryStream with an alternative implementation if needed. But nobody expects this class to behave completely different from how it originally did (and seems to do in MS.Net). Andreas ___ 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?
Hi, For variable, a chunked implementation will work better once the stream exceeds the maximum size for the first chunk. Additional considerations for this case are: (a) should the first chunk have a smaller size initially to be more efficient for short streams, (b) should chunks be reusable and thus bypass the alloc/free cycle, (c) should a call to GetBuffer() automatically reset the first chunk with the newly created byte array? I think (b) can be great, but obviously it can always be a PooledCunkedMemoryStream class, or a different constructor. On Nov 10, 2009, at 4:47 AM, Steve Bjorg wrote: Allowing the first chunk to be variable sized doesn't make the code that much more complex. This would mean in read-only cases, all operations would remain O(1) since the original byte array would be preserved. For write operations, new chunks would be allocated as needed. Determining which chunk to read from or write to would need to take into account the first chunk size, but that's it. For the case where someone initializes the ChunkedMemoryStream with an existing byte array, then appends to it, and then calls GetBuffer(), we would end up with the same overhead as before since the MemoryStream would have needed to reallocate the byte array when the first append operation occurred, whereas the ChunkedMemoryStream does it on GetBuffer(). However, if the array needed to be extended multiple times due to many append operations, then the ChunkedMemoryStream will come out ahead again since it only realloacted the buffer once. At which point, the realloacted buffer could replace the first chunk so we don't do this again for repeated calls to GetBuffer(). On Nov 10, 2009, at 4:21 AM, Leszek Ciesielski wrote: Choice is not always good, and I think this is one of the cases when the default (i.e. the MemoryStream implementation) should make the choices instead presenting them to the user. Though I agree that the case of constructing a MemoryStream from an existing byte[] would require a special path in the code, as this is a stream that most likely won't be resized and in this case users are expecting the constructor to have a complexity of O(1) and GetBuffer to also be O(1). The same expectation is probably also true with a fixed size MemoryStream. On Tue, Nov 10, 2009 at 1:09 PM, pablosantosl...@terra.es pablosantosl...@terra.es wrote: I agree (especially thinking about the chunk-pool I mentioned) having separate classes can be better, so that everyone can choose. Andreas Nahr wrote: I'm still not sure this is a good idea. A lot of this depends on the use-case for MemoryStream. If 1) A MemoryStream is created with a parameterless constructor and then a lot of data written to it multiple times the ChunkedStream will be better always. 2) If a MemoryStream is created with a parameterless constructor and only gets a few bytes long ChunkedStream might bring considerable overhead. 3) If MemoryStream is created with a fixed size then ChunkedStream will be somewhat, but acceptably slower and have a higher overhead. But it will be totally abysmal once GetBuffer comes into play. 4) If MemoryStream is constructed from a (large) byte array (in the scientific field I'm coming from this is by far the most common usage I've seem; that is basically using MemoryStream as a (read-only) Stream-Wrapper around a byte array) then performance will be abysmal when constructing (if you chunkify e.g. a 500MB byte array) AND again with GetBuffer (recreate the array). So would be O (n) or even O (2*n) instead of O (0). It might be possible to create an implementation that can deal with all this (would need to have variable sized buffers, keep things it gets passed in the constructor alive with small overhead, etc.), but it will be quite complex and come with a large base overhead. And even then the GetBuffer O(n) problem remains in a few scenarios. Maybe it would be better to just leave the class as is and document that for certain scenarios alternative implementations are available that do a MUCH better job. Everybody can easily replace the use of MemoryStream with an alternative implementation if needed. But nobody expects this class to behave completely different from how it originally did (and seems to do in MS.Net). Andreas ___ 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 - Steve -- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg irc.freenode.net #mindtouch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo
[Mono-dev] Interactive C# shell for server monitoring
Hi, Any experience anyone using Interactive C# shell (http://www.mono-project.com/CsharpRepl) embedded into a server process for monitoring purposes (accessible through a socket maybe?) Thanks, pablo ___ 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?
Hi, I think a very important place were this chunked mem streams HAVE TO be placed (in fact I'll be trying them tomorrow under heavy load on our testing cluster) is in remoting: there's a huge number of mem streams being created and destroyed (one for each call) and this can help... only if the new ChunkedStream is based on a pool, which I don't think is the case but probably could be easily doable. What do you think about extending ChunkedMemoryStream to include an option based on a chunk pool, so memory is actually reused instead of freed and re-allocated? Wouldn't it be good to reduce fragmentation (I'm still thinking on remoting)?? pablo www.plasticscm.com Steve Bjorg wrote: The implementation could be adapted so that if the chunked memory stream is initialized with an existing byte array it behaves like it did in the past. It's possible that the best approached can be derived for the various MemoryStream constructors. The question is what is the most common usage pattern? If it's GetBuffer(), then there will be a performance and overhead hit. However, if it's using Write()/Read() as we do, then there are some significant gains to be had. GetBytes() would also benefit, though not as much. - Steve -- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg irc.freenode.net #mindtouch On Nov 9, 2009, at 11:41 AM, Andreas Nahr wrote: Are you talking about System.IO.MemoryStream? Then imho this would be a problematic move. Most people are used to new MemoryStream (someByteArray) being O(0) time, but with ChunkedStream would be O(n). In fact in those cases ChunkedStream would need twice the memory because it would still need to retain the original byte array (e.g. for GetBuffer). Happy hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Miguel de Icaza Gesendet: Montag, 9. November 2009 19:10 An: mono-devel-list Betreff: [Mono-dev] Should we replace MemoryStream? Hello folks, 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. 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Soft debugger HOWTO
Hi, After the announcement last week of the new soft debugger, I have several questions: - I understand MD is the primary interface *right now* for the soft debugger, is it possible to debug a Linux app too? - Is there any other available interface to use the soft debugger besides MD? - As Miguel pointed to me last week, the new softdeb will allow debuggin gon any platform, I don't know if anyone experienced it yet (I'll definitely give it a try asap), if so, any feedback? I know it's still a little bit too soon, but once the softdeb gets some good visibility, I honestly trust we're about to see a huge change in the way Mono is used. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Soft debugger HOWTO
Hi Geoff, - I understand MD is the primary interface *right now* for the soft debugger, is it possible to debug a Linux app too? You mean a native app? No. You mean a mono app on linux? Yes, on x86 and amd64 and arm currently. I'm only concerned 99.99% of the time about managed code. So that's what I need. - Is there any other available interface to use the soft debugger besides MD? You can create any interface you like on top of the Mono.Debugger.Soft.dll, MonoDevelop is the interface we support. Will it make sense to have some sort of command line interface? Maybe not, MD will always be better... - As Miguel pointed to me last week, the new softdeb will allow debuggin gon any platform, I don't know if anyone experienced it yet (I'll definitely give it a try asap), if so, any feedback? We currently have it ported to: - linux (x86, amd64, arm, arm-full-aot) - darwin (x86, arm, arm-full-aot) The point miguel was making is that porting to new architectures is a minor (1 day) task in most cases. Excellent! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
Hi, Dick and I were talking about the possible race conditions (we've found one on our code) that the system ThreadPool can have when used from the channel and the code (remember the *current* tcp channel does not use the system threadpool but a custom and really simple one). Would it be possible to use two different thread pools instantiating the system ones? Also, would it be possible to commit this code? Another related idea: it is possible (I think) to greatly improve the current TcpChannel by returning threads to the pool when they're waiting at PlasticTcpClientConnection.ProcessMessages. The problem right now is that each client connection will create a thread on the server and the thread won't be returned to the pool until the client closes the connection, even if it's just waiting for data. This is not good for high-perf environments were many requests must be processed, since a huge number of threads could be potentially spawned. My idea would be: we already have a thread for the socket accept, create a new one for Socket.Select, so that threads are returned to the pool (and its socket passed to the Socket.Select call) and then the method ProcessMessages would be called again when select returns. It's not like a full asynch channel but I think it can be even better on most situations (less overhead) and it will greatly improve responsiveness. pablo www.plasticscm.com Dick Porter wrote: Hi all Attached is a patch to add an optional asynchronous path for the TCP remoting channel server. The main benefit we see with this change is in reliability; when a single server is servicing many clients at once (we test with over 100) with large data transfers the standard synchronous channel will often drop connections. We tracked this down to the Accept() call in TcpServerChannel.cs not being able to get to incoming connections quickly enough. I was hoping that throughput of large transfers might be improved by using the threadpool's asynchronous sockets support, but it turns out that performance is pretty much the same as the current implementation. Any comments/suggestions for improvement? - Dick ___ 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] IA-64 big-endian
Hi, The most important thing is to find out the differences between Big Endian Mode IA-64 and Little Endian Mode IA-64 -- not just the byte or word order, but also find out how things are different when function call parameters are passed via the stack. BTW, Linux on Itanium runs in little endian mode. HP-UX itself runs in big endian mode, but can run little endian mode Linux applications with the Linux Runtime Environment. So may be you guys don't need to port Mono to big endian mode Itanium!! Then maybe the first step would be just trying to run a Mono built on Mono Itanium on the HP-UX and check whether it just works? pablo Rayson On Thu, Oct 29, 2009 at 6:03 PM, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Zoltan, Would you mind sharing with us your thoughts about the things to change so we can have an idea of what's involved? As Dick pointed, would we need a hardware manual? Thanks, pablo Zoltan Varga wrote: Hi, It would probably require a lot of modifications but its easier than a full port since most of the code is there. Zoltan On Thu, Oct 29, 2009 at 6:22 PM, Dick Porter dpor...@codicesoftware.com mailto:dpor...@codicesoftware.com wrote: Hi all I've been spending the last couple of days getting mono to build on ia-64/hpux - mostly so far setting up GNU tools from scratch. I've now run into a showstopper: mono/arch/ia64/ia64-codegen.h #if G_BYTE_ORDER != G_LITTLE_ENDIAN #error FIXME #endif So my question is, is fixing this going to be a case of a few fixes here and there (that I might be able to do without a hardware manual), or is it going to be a full-blown port? Thanks, - Dick ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Novell.Directory.Ldap replacement?
Hi there, We're having troubles with Novell.Directory.Ldap library. We're about to contact the developer with a couple of fixes, but it seems they just improve the situation but doesn't totally solve it. After thousands of requests (on a test program on a linux box) the app always get blocked, sometimes it's able to continue after some time, but sometimes (often) it keeps blocked forever, which is not very good on production :-P Does any replacement (commercial or not) exist? We'll try to fix it, but just in case. Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IA-64 big-endian
Zoltan, Would you mind sharing with us your thoughts about the things to change so we can have an idea of what's involved? As Dick pointed, would we need a hardware manual? Thanks, pablo Zoltan Varga wrote: Hi, It would probably require a lot of modifications but its easier than a full port since most of the code is there. Zoltan On Thu, Oct 29, 2009 at 6:22 PM, Dick Porter dpor...@codicesoftware.com mailto:dpor...@codicesoftware.com wrote: Hi all I've been spending the last couple of days getting mono to build on ia-64/hpux - mostly so far setting up GNU tools from scratch. I've now run into a showstopper: mono/arch/ia64/ia64-codegen.h #if G_BYTE_ORDER != G_LITTLE_ENDIAN #error FIXME #endif So my question is, is fixing this going to be a case of a few fixes here and there (that I might be able to do without a hardware manual), or is it going to be a full-blown port? Thanks, - Dick ___ 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] faster than hashtable?
Thanks, Good to know! I'll give it a try. Alan McGovern wrote: 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 mailto:tsp...@gmail.com wrote: 2009/10/27 psant...@codicesoftware.com mailto:psant...@codicesoftware.com psant...@codicesoftware.com mailto: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 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 ___ 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?
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 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 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?
Sure Alan! So, basically, the options are: - Use a sorted ArrayList and a binary search - Reimplement hashtable focusing on long keys - Write a wrapper to Judy 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] Error handling longs on Mono SPARC
Hi Zoltan,
Should we file a bug on bugzilla?
pablo
pablosantosl...@terra.es wrote:
Hi Zoltan,
It's the daily tarball (the date is in the version string) which I
believe is svn trunk.
pablo
Zoltan Varga wrote:
Hi,
Is this the 2.6 prerelease, or using the code from the mono-2-6 branch
? The latter has
some sparc fixes.
Zoltan
On Mon, Oct 26, 2009 at 1:11 PM, pablosantosl...@terra.es
mailto:pablosantosl...@terra.es pablosantosl...@terra.es
mailto:pablosantosl...@terra.es wrote:
Hi there,
This is our configuration:
-bash-3.00$ uname -a
SunOS atenea 5.11 snv_34 sun4u sparc SUNW,Sun-Blade-1000
-bash-3.00$ mono --version
Mono JIT compiler version 20091021 (tarball Wed Oct 21 19:04:28 CEST
2009)
Copyright (C) 2002-2009 Novell, Inc and Contributors.
www.mono-project.com http://www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: normal
Notification: Thread + polling
Architecture: sparc
Disabled: none
We're using a Mono 2.6 compiled at our test box.
We've a code like this:
long dstBrId = GetBranchNumber(brId);
log.DebugFormat(Branch {0} - {1}, brId, dstBrId);
Calling this method:
private long GetBranchNumber(long brId)
{
Branch br = (Branch) mFetchBranches[brId];
if( br != null )
{
return br.ObjId;
}
log.DebugFormat(GetBranchNumber returning {0}, brId);
return brId;
}
And that's the log it is showing:
- GetBranchNumber returning 4
- Branch 4 - 17179869188
It looks like, for some reason, this 4 is magically becoming a
17179869188!!
17179869188 is - 40004 in hex
And, it *gets fixed by building disabling the optimize mode*
Of course, a test app like this:
using System;
class Hello
{
public static void Main()
{
Hello t = new Hello();
long myval = 4;
long longVal = t.GetValue(myval);
Console.WriteLine(longVal);
}
private long GetValue(long v)
{
return v;
}
}
Does not fail.
Any idea?
Thanks,
pablo
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error handling longs on Mono SPARC
A small testcase would be very useful, it can usually be generated by taking the code which exhibits the problem, and removing stuff from it. Also, does it happen with 2.4 too ? Not sure we'll be able to reproduce it outside the real code. It's a big process, in case this has something to do with it. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error handling longs on Mono SPARC
Hi Zoltan, If you can't create a test case, could you run your app with MONO_VERBOSE_METHOD=caller method then with MONO_VERBOSE_METHOD=called method and send me the output ? Sure, I'll do. What does ' *gets fixed by building disabling the optimize mode*' means, is this a flag for the c# compiler ? Yep. I'm building with nant, I'm enabling or disabling the optimize flag. It's the same as gmcs --optimize I think. Also, the code's been built on .NET, but I don't think it will make a difference. Will try and come back to you. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Error handling longs on Mono SPARC
Hi there,
This is our configuration:
-bash-3.00$ uname -a
SunOS atenea 5.11 snv_34 sun4u sparc SUNW,Sun-Blade-1000
-bash-3.00$ mono --version
Mono JIT compiler version 20091021 (tarball Wed Oct 21 19:04:28 CEST 2009)
Copyright (C) 2002-2009 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: normal
Notification: Thread + polling
Architecture: sparc
Disabled: none
We're using a Mono 2.6 compiled at our test box.
We've a code like this:
long dstBrId = GetBranchNumber(brId);
log.DebugFormat(Branch {0} - {1}, brId, dstBrId);
Calling this method:
private long GetBranchNumber(long brId)
{
Branch br = (Branch) mFetchBranches[brId];
if( br != null )
{
return br.ObjId;
}
log.DebugFormat(GetBranchNumber returning {0}, brId);
return brId;
}
And that's the log it is showing:
- GetBranchNumber returning 4
- Branch 4 - 17179869188
It looks like, for some reason, this 4 is magically becoming a
17179869188!!
17179869188 is - 40004 in hex
And, it *gets fixed by building disabling the optimize mode*
Of course, a test app like this:
using System;
class Hello
{
public static void Main()
{
Hello t = new Hello();
long myval = 4;
long longVal = t.GetValue(myval);
Console.WriteLine(longVal);
}
private long GetValue(long v)
{
return v;
}
}
Does not fail.
Any idea?
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Error handling longs on Mono SPARC
Hi Zoltan,
It's the daily tarball (the date is in the version string) which I
believe is svn trunk.
pablo
Zoltan Varga wrote:
Hi,
Is this the 2.6 prerelease, or using the code from the mono-2-6 branch
? The latter has
some sparc fixes.
Zoltan
On Mon, Oct 26, 2009 at 1:11 PM, pablosantosl...@terra.es
mailto:pablosantosl...@terra.es pablosantosl...@terra.es
mailto:pablosantosl...@terra.es wrote:
Hi there,
This is our configuration:
-bash-3.00$ uname -a
SunOS atenea 5.11 snv_34 sun4u sparc SUNW,Sun-Blade-1000
-bash-3.00$ mono --version
Mono JIT compiler version 20091021 (tarball Wed Oct 21 19:04:28 CEST
2009)
Copyright (C) 2002-2009 Novell, Inc and Contributors.
www.mono-project.com http://www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: normal
Notification: Thread + polling
Architecture: sparc
Disabled: none
We're using a Mono 2.6 compiled at our test box.
We've a code like this:
long dstBrId = GetBranchNumber(brId);
log.DebugFormat(Branch {0} - {1}, brId, dstBrId);
Calling this method:
private long GetBranchNumber(long brId)
{
Branch br = (Branch) mFetchBranches[brId];
if( br != null )
{
return br.ObjId;
}
log.DebugFormat(GetBranchNumber returning {0}, brId);
return brId;
}
And that's the log it is showing:
- GetBranchNumber returning 4
- Branch 4 - 17179869188
It looks like, for some reason, this 4 is magically becoming a
17179869188!!
17179869188 is - 40004 in hex
And, it *gets fixed by building disabling the optimize mode*
Of course, a test app like this:
using System;
class Hello
{
public static void Main()
{
Hello t = new Hello();
long myval = 4;
long longVal = t.GetValue(myval);
Console.WriteLine(longVal);
}
private long GetValue(long v)
{
return v;
}
}
Does not fail.
Any idea?
Thanks,
pablo
___
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] [Patch] Make Boehm GC stack scanning less aggressive
Unless you need to keep production code up and running... TODAY. ;-) Rodrigo Kumpera wrote: Hi Dick, I believe there is very little reason to do development on libgc as sgen is been worked and advancing quite fast. I don't feel it's worth the risk of improving libgc. SGen is only a few months away from been production ready and it might be a better idea to spend your energy there. For example, Code to do precise marking of managed code is still to be done and is an area that help would be more than welcome. On Tue, Oct 20, 2009 at 12:44 PM, Dick Porter dpor...@codicesoftware.com mailto:dpor...@codicesoftware.com wrote: Hi all The attached patch makes the stack marking in libgc much less aggressive. Instead of marking every object that happens to be pointed to by random numbers, it uses the descriptor-based scanning function instead. I think this is safe for mono, as (as was pointed out to me) every allocation has a descriptor. It fixes the stress-test that David posted a week or two ago, and in the real world it allows our server to free up much more memory. It has been tested on a production server. Comments? - Dick ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Performance Solaris/Linux/Windows
Hi,
We're running a simple program like the following on Mono/Linux,
Mono/OpenSolaris, .NET/Windows. Same hardware (QuadCore Xeon 64bits).
The results are very interesting: Linux/Mono is a little bit faster than
Windows/.NET and OpenSolaris/Mono a little bit slower.
(FYI: we wrote the same code in Java, and running with the default VM,
Mono is *always* faster)
Ok, here comes the questions and remarks:
Solaris with Mono 2.2 is a little bit faster (about a 20% or so) than
Mono 2.7 (just built from trunk). Is there a good explanation for that?
Also, and more importantly: could you highlight some reasons why a test
like the one below is slower on Mono/OpenSolaris than Mono/Linux?
Thanks,
pablo
Mono JIT compiler version 2.2 (/branches/mono-2-2/mono r125384 Tue Feb
3 10:53:16 CET 2009)
Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC)
SIGSEGV: normal
Notification: Thread + polling
Architecture: x86
Disabled: none
Mono JIT compiler version 2.7 (/trunk/mono r144497 Wed Oct 21 01:58:57
CEST 2009)
Copyright (C) 2002-2009 Novell, Inc and Contributors. www.mono-project.com
TLS: normal
GC:Included Boehm (with typed GC and Parallel Mark)
SIGSEGV: normal
Notification: Thread + polling
Architecture: x86
Disabled: none
using System;
using System.IO;
using System.Collections;
namespace hash_access
{
public class RevisionInfo
{
public long ItemId = -1;
public short Type;// Directory, Text, Binary, ...
public long Size;
public bool CheckedOut;
public long ParentId = -1;
public long BranchId = -1;
public string RevisionNumber;
public string Hash;
public long Changeset;
public bool Last;
}
class Class1
{
[STAThread]
static void Main(string[] args)
{
int size = int.Parse(args[0]);
int ini = Environment.TickCount;
Hashtable hash = new Hashtable();
ArrayList list = new ArrayList();
for (int i = 0; i size; i++)
{
RevisionInfo revInfo = new RevisionInfo();
hash[i] = revInfo;
//hash[i.ToString()] = revInfo;
list.Add(revInfo);
}
for (int i = 0; i size; i++)
{
RevisionInfo revInfo = hash[i] as RevisionInfo;
revInfo = list[i] as RevisionInfo;
}
Console.WriteLine({0} times: {1}ms, size,
Environment.TickCount - ini);
Console.ReadLine();
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] tcmalloc
Hi there, Dick and I were talking about it today and most likely it wouldn't have a big impact since Mono does use mmap instead but.. do you guys think using tcmalloc would be worth? http://goog-perftools.sourceforge.net/doc/tcmalloc.html It's not new, but I've just found it reading the MySql 5.4 release notes, and it seems it helps boosting its performance http://mysqlha.blogspot.com/2009/01/double-sysbench-throughput-with_18.html Would it help? pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mac OS X Debugger?
Hi there, Is the Mac OS X Debugger the Unity people were working on ready to use? Thanks, pablo ___ 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) ?
Hi, Chuck Esterbrook wrote: A web search showed me that GC can be turned off with the environment variable GC_DONT_GC. Maybe that should be called MONO_GC_ON. In any case, any value will turn off the GC, including blank, so to turn it back on, unset it. I tested with a command line Mono program that is not a microbenchmark. With GC, it peaks at around 180MB and without, it peaks around 840MB and runs about 18% faster. I gave the same program less work to do and its performance boost was only 10%. So now you can try your programs without GC to see how much it contributes to performance drag. Just watch for swap. :-) Does anyone know what's involved with plugging in your own GC into Mono? Nightmare level?? -Chuck ___ 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] Issues with GC due to libgc
Is it a 64bits machine?
If so, the same is true for us.
But, with 32 bits mono, we can consistently repeat the issue. I can set
up a gotomeeting and show you how it happens.
pablo
Zoltan Varga wrote:
Hi,
On my machine, after the allocation of the 2.5GB of arrays + 10 gcs,
the RSS of the
process goes back to about 100MB. This is perfectly normal, as the GC
doesn't return
free memory to the OS in some cases, so it doesn't have to allocate it
again when the
program starts allocating memory.
Zoltan
On Mon, Sep 28, 2009 at 9:05 PM, pablosantosl...@terra.es
mailto:pablosantosl...@terra.es pablosantosl...@terra.es
mailto:pablosantosl...@terra.es wrote:
Hi all,
After several weeks working on a bunch of mem issues related to the
libgc based garbage collector, we've identified the following issue and
a possible solution (Dick already sent some workarounds to the list):
The libgc garbage collector has a really hard time identifying pointers
to objects since it guesses what is a pointer instead of actually
knowing by using data passed by the mono runtime.
It means something as simple as introducing a long on the stack (for
instance something like array = new int[100]) will block (forever)
the memory at address 100. Yes, as incredible as it sounds, it can
cause important mem problems on long living apps (typically servers).
(As a side note, this exact problem is present on sgen, since it also
scans the stack conservatively).
A small improvement could be made in the current GC with little effort,
and is supplying more class refmaps to libgc.
Libgc is very hard to modify, it contains too many hacks and
optimizations that have made the code a nightmare to understand and
modify, so we don't find useful to make anything here beyond very small
patches.
That said, mono currently can provide reference bitmaps for objects,
it's a matter of providing the right descriptor to the garbage
collector.
Libgc supports this kind of descriptors and mono already generates them
for the sgen gc, so it's just a matter of joining those together (which
should beeasy to do). This should improve a great number of scans in the
arking process, leaving only stacks and several minor objects without
precise marking. (Should become similar to the current sgen idea, where
stacks and other roots are scanned conservatively, although not
compacting).
Attached is the sample code we use to reproduce the issue on 32 bit
based Linux/Mono systems.
Some notes about the test app below:
===
the program accepts commands like gc, mem, exit, 2, or 1
2 n m creates n arrays of ints with m elements, and put them in an
arraylist. After the call completes, they are no longer referenced.
1 n m same, but waiting for a key press after each new array
gc n performs n gcs
exit exits
So, the case:
mono test.exe
2 200 70creates 2 million int arrays of 70 elements
each (virtual goes up to 777MB)
gc 10should free everything, but around 33MB
remain allocated acording to pmap:
...
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 777820K 33852K 29336K
2 20 2500 creates 20 int arrays of 25 million elements
each (2.7GB)
gc 10 now pmap shows everything is screwed up:
...
b7f2b000 8K 8K 8K rwxp /lib/ld-2.6.1.so
http://ld-2.6.1.so
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 2764356K 1696132K 1691616K
Trying with smaller sizes lets you see that segments are joined and
split, but seems that there is some inability to free everything.
==
Regards,
pablo
using System;
using System.Collections;
namespace test
{
class Program
{
static void Main(string[] args)
{
WaitForEnter();
}
private static void WaitForEnter()
{
Console.WriteLine(Command:);
while (true)
{
Console.Write( );
string line = Console.ReadLine();
string[] args = line.Split(' ');
if (args.Length = 0) continue;
switch (args[0].ToLower())
{
case exit: return;
case
Re: [Mono-dev] Issues with GC due to libgc
Hi Miguel,
Hello,
I tried your sample, in my machine the memory usage with Case1 does
go up very quickly, but then it tends to stay stable around 600 megs.
Ok, but the problem is that ALL memory should be freed, since there are
no references to the arrays. Of course you've to invoke GC. The 600Mb
in RES is a leak (Virtual Mem will only grow since libgc will never
release it, this is another patch Dick has been working on)
Later, I modified the program to not allocate 1 meg blocks, but
instead to allocation 1024 times 1k blocks (so that it allocates the
same amount of memory). The program stays stable at around 200 megs of
ram in this case.
Same as above: if we're talking about RES it should be close to 0 (ok,
size of the runtime and the program)
I am sure your program is more complicated, but the difference
between these two patterns of memory usage in my opinion are caused by
memory fragmentation, not really conservative heap scanning.
We don't think so since memory is clearly not freed, even considering
there're no references to the data.
My suggestion is to change the code in your server to use either
unmanaged buffers for large allocations, or to do buffering with smaller
blocks of memory instead of 10 megabyte blobs.
Ok, in fact this is just a simple example, our production code is not
handling arrays pointing to such a big data. We can handle arrays of
objects close to 50K elements or even more, but not millions.
Hi all,
After several weeks working on a bunch of mem issues related to the
libgc based garbage collector, we've identified the following issue and
a possible solution (Dick already sent some workarounds to the list):
The libgc garbage collector has a really hard time identifying pointers
to objects since it "guesses" what is a pointer instead of actually
"knowing" by using data passed by the mono runtime.
It means something as simple as introducing a long on the stack (for
instance something like array = new int[100]) will block (forever)
the memory at address 100. Yes, as incredible as it sounds, it can
cause important mem problems on long living apps (typically servers).
(As a side note, this exact problem is present on sgen, since it also
scans the stack "conservatively").
A small improvement could be made in the current GC with little effort,
and is supplying more class refmaps to libgc.
Libgc is very hard to modify, it contains too many hacks and
optimizations that have made the code a nightmare to understand and
modify, so we don't find useful to make anything here beyond very small
patches.
That said, mono currently can provide reference bitmaps for objects,
it's a matter of providing the right descriptor to the garbage collector.
Libgc supports this kind of descriptors and mono already generates them
for the sgen gc, so it's just a matter of joining those together (which
should beeasy to do). This should improve a great number of scans in the
arking process, leaving only stacks and several minor objects without
precise marking. (Should become similar to the current sgen idea, where
stacks and other roots are scanned conservatively, although not compacting).
Attached is the sample code we use to reproduce the issue on 32 bit
based Linux/Mono systems.
Some notes about the test app below:
===
the program accepts commands like gc, mem, exit, 2, or 1
2 n m creates n arrays of ints with m elements, and put them in an
arraylist. After the call completes, they are no longer referenced.
1 n m same, but waiting for a key press after each new array
gc n performs n gcs
exit exits
So, the case:
mono test.exe
2 200 70creates 2 million int arrays of 70 elements
each (virtual goes up to 777MB)
gc 10should free everything, but around 33MB
remain allocated acording to pmap:
...
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 777820K 33852K 29336K
2 20 2500 creates 20 int arrays of 25 million elements
each (2.7GB)
gc 10 now pmap shows everything is screwed up:
...
b7f2b000 8K 8K 8K rwxp /lib/ld-2.6.1.so
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 2764356K 1696132K 1691616K
Trying with smaller sizes lets you see that segments are joined and
split, but seems that there is some inability to free everything.
==
Regards,
pablo
plain text document attachment (Program.cs)
using System;
using System.Collections;
namespace test
{
class Program
{
static void
Re: [Mono-dev] Issues with GC due to libgc
Ok, but the problem is that ALL memory should be freed, since there are no references to the arrays. Of course you've to invoke GC. The 600Mb in RES is a leak (Virtual Mem will only grow since libgc will never release it, this is another patch Dick has been working on) This can easily be explained by memory fragmentation problems. Miguel, I don't want to drive you crazy but examining and debugging the libgc code we've found that the pages are kept marked as used instead of free (David can give you more info in case I'm missing anything). That's why I don't think fragmentation is the problem. If marking were ok, the entire mem would be freed (as it happens with 64bits mono). pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Issues with GC due to libgc
Hi all,
After several weeks working on a bunch of mem issues related to the
libgc based garbage collector, we've identified the following issue and
a possible solution (Dick already sent some workarounds to the list):
The libgc garbage collector has a really hard time identifying pointers
to objects since it guesses what is a pointer instead of actually
knowing by using data passed by the mono runtime.
It means something as simple as introducing a long on the stack (for
instance something like array = new int[100]) will block (forever)
the memory at address 100. Yes, as incredible as it sounds, it can
cause important mem problems on long living apps (typically servers).
(As a side note, this exact problem is present on sgen, since it also
scans the stack conservatively).
A small improvement could be made in the current GC with little effort,
and is supplying more class refmaps to libgc.
Libgc is very hard to modify, it contains too many hacks and
optimizations that have made the code a nightmare to understand and
modify, so we don't find useful to make anything here beyond very small
patches.
That said, mono currently can provide reference bitmaps for objects,
it's a matter of providing the right descriptor to the garbage collector.
Libgc supports this kind of descriptors and mono already generates them
for the sgen gc, so it's just a matter of joining those together (which
should beeasy to do). This should improve a great number of scans in the
arking process, leaving only stacks and several minor objects without
precise marking. (Should become similar to the current sgen idea, where
stacks and other roots are scanned conservatively, although not compacting).
Attached is the sample code we use to reproduce the issue on 32 bit
based Linux/Mono systems.
Some notes about the test app below:
===
the program accepts commands like gc, mem, exit, 2, or 1
2 n m creates n arrays of ints with m elements, and put them in an
arraylist. After the call completes, they are no longer referenced.
1 n m same, but waiting for a key press after each new array
gc n performs n gcs
exit exits
So, the case:
mono test.exe
2 200 70creates 2 million int arrays of 70 elements
each (virtual goes up to 777MB)
gc 10should free everything, but around 33MB
remain allocated acording to pmap:
...
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 777820K 33852K 29336K
2 20 2500 creates 20 int arrays of 25 million elements
each (2.7GB)
gc 10 now pmap shows everything is screwed up:
...
b7f2b000 8K 8K 8K rwxp /lib/ld-2.6.1.so
bf4b5000 32K 0K 0K ---p [anon]
bfc9e000 88K 32K 28K rwxp [stack]
e000 4K 0K 0K r-xp [vdso]
Total: 2764356K 1696132K 1691616K
Trying with smaller sizes lets you see that segments are joined and
split, but seems that there is some inability to free everything.
==
Regards,
pablo
using System;
using System.Collections;
namespace test
{
class Program
{
static void Main(string[] args)
{
WaitForEnter();
}
private static void WaitForEnter()
{
Console.WriteLine(Command:);
while (true)
{
Console.Write( );
string line = Console.ReadLine();
string[] args = line.Split(' ');
if (args.Length = 0) continue;
switch (args[0].ToLower())
{
case exit: return;
case 1: Case1(args); break;
case 2: Case2(args); break;
case mem:
Console.WriteLine(Memory now: {0},
GC.GetTotalMemory(false));
break;
case gc:
Gcs(args);
break;
default:
Console.WriteLine(Unknown command);
break;
}
}
}
private static void Gcs(string[] args)
{
int loop = (args.Length == 2) ? Int32.Parse(args[1]) : 1;
for (int i = 0; i loop; ++i)
{
Console.WriteLine(Memory {1} now : {0},
GC.GetTotalMemory(false), i);
Console.WriteLine(Memory {1} after GC: {0},
GC.GetTotalMemory(true), i);
}
}
private const int OneMeg = 1024 * 1024;
private static void Case1(string[] args)
{
int loop = (args.Length = 2) ? Int32.Parse(args[1]) : 5;
int size = (args.Length = 3) ? Int32.Parse(args[2]) : 10 * OneMeg;
ArrayList
[Mono-dev] Does MonoTouch use GC?
Hi there, Does MonoTouch use GC when running on the iPhone? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
Hi, I've just downloaded the latest SVN. This is what I get when I try to build: MCS [net_1_1] Mono.CompilerServices.SymbolWriter.dll Assembly ../../class/lib/net_1_1/tmp/Mono.CompilerServices.SymbolWriter.dll signed. Assembly ../../class/lib/net_1_1/Mono.CompilerServices.SymbolWriter.dll is strongnamed. make[8]: Leaving directory `/home/plastic/monosrc/mcs/class/Mono.CompilerServices.SymbolWriter' make[7]: Leaving directory `/home/plastic/monosrc/mcs/class/Mono.CompilerServices.SymbolWriter' make[7]: Entering directory `/home/plastic/monosrc/mcs/class/Mono.Posix' Creating ../../build/deps/net_1_1_Mono.Posix.dll.makefrag ... Creating ../../build/deps/Mono.Posix_test_net_1_1.dll.response ... Creating ../../build/deps/Mono.Posix_test_net_1_1.dll.makefrag ... make[7]: Leaving directory `/home/plastic/monosrc/mcs/class/Mono.Posix' make[7]: Entering directory `/home/plastic/monosrc/mcs/class/Mono.Posix' make all-local make[8]: Entering directory `/home/plastic/monosrc/mcs/class/Mono.Posix' MCS [net_1_1] Mono.Posix.dll Stacktrace: /bin/sh: line 1: 29810 Segmentation fault MONO_PATH="./../../class/lib/net_1_1:$MONO_PATH" /home/plastic/monosrc/mono/runtime/mono-wrapper ./../../class/lib/net_1_1/mcs.exe /codepage:65001 -optimize -d:NET_1_1 -d:ONLY_1_1 -debug /noconfig /unsafe /r:mscorlib.dll /r:System.dll /nowarn:0618,612 -target:library -out:../../class/lib/net_1_1/Mono.Posix.dll @Mono.Posix.dll.sources make[8]: *** [../../class/lib/net_1_1/Mono.Posix.dll] Error 139 make[8]: Leaving directory `/home/plastic/monosrc/mcs/class/Mono.Posix' make[7]: *** [do-all] Error 2 make[7]: Leaving directory `/home/plastic/monosrc/mcs/class/Mono.Posix' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/plastic/monosrc/mcs/class' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/plastic/monosrc/mcs' make[4]: *** [profile-do--net_1_1--all] Error 2 make[4]: Leaving directory `/home/plastic/monosrc/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/home/plastic/monosrc/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/home/plastic/monosrc/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/plastic/monosrc/mono' make: *** [all] Error 2 Miguel de Icaza wrote: Hello, Is is possible to try the upcoming compacting GC? Is it in a status close to be usable? You can try it, but it is not finished. Compile Mono with: ./configure --with-gc=sgen Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] An asynchronous System.Runtime.Remoting.Channels.Tcp
My suggestion would be using a separate ThreadPool for the channel than the one used by the system, since Dick is aware race conditions can happen (deadlocks) between code using the System ThreadPool in the process and the channel. Diff. ThreadPools will fix it. pablo Miguel de Icaza wrote: Hello, I like this patch very much, and I like that the way to enable it is through the new "run_async" configuration option. My only feedback is that I believe this is a nice enough feature that it deserves at least: * A blog entry announcing it, linking to: * A page on the Wiki with an explanation of what it does, and how to use it. Miguel. Hi all Attached is a patch to add an optional asynchronous path for the TCP remoting channel server. The main benefit we see with this change is in reliability; when a single server is servicing many clients at once (we test with over 100) with large data transfers the standard synchronous channel will often drop connections. We tracked this down to the Accept() call in TcpServerChannel.cs not being able to get to incoming connections quickly enough. I was hoping that throughput of large transfers might be improved by using the threadpool's asynchronous sockets support, but it turns out that performance is pretty much the same as the current implementation. Any comments/suggestions for improvement? - Dick ___ 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] Compacting GC
The first thing we'd need is to be able to build it. This way we can pass our test suite using SGen and most likely detect a good number of potential bugs. Dick Porter wrote: On 11 Sep 2009, at 3:26PM, Mark Probst wrote: On Fri, Sep 11, 2009 at 3:02 PM, Dick Porter dpor...@codicesoftware.com wrote: Is there a known list of jobs needed for sgen, or is it just a case of working through the failures and bugs? If you'd like to help, I'll write up a document with what I've learned debugging SGen. Yes please. - Dick ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
Must be our problem then. We'll try again, maybe we've an outdated SVN copy or something (I don't think so, but let's try again). Miguel de Icaza wrote: Hello, The first thing we'd need is to be able to build it. This way we can pass our test suite using SGen and most likely detect a good number of potential bugs. Exactly what happened? Yesterday I reconfigured my Mono like this: ./configure --with-gc=sgen And Mono built without a glitch, and that is when I replied something like "Did you try to build it?". Without an error log it is hard to determine what is happening to you. A fresh checkout with a fresh configure works for me. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
We were just planning to test it on Linux. Rodrigo Kumpera wrote: On Fri, Sep 11, 2009 at 3:21 PM, Miguel de Icaza mig...@novell.com wrote: Hello, The first thing we'd need is to be able to build it. This way we can pass our test suite using SGen and most likely detect a good number of potential bugs. Exactly what happened? Yesterday I reconfigured my Mono like this: ./configure --with-gc=sgen And Mono built without a glitch, and that is when I replied something like "Did you try to build it?". Without an error log it is hard to determine what is happening to you. A fresh checkout with a fresh configure works for me. It's worth pointing out that SGEN won't build on windows or OSX at the moment since it requires a working __thread implementation. Mark has been working on lifting this requirement but the code haven't been committed yet. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compacting GC
We tried to build it today since we're experiencing issues with libgc under really heavy load. It does not build. David can add more details if you're interested, but they show up just trying to build it. Miguel de Icaza wrote: This build option hasn't been working for a while when compiling from trunk. Did anyone fix it recently? What about trying it out? 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
Re: [Mono-dev] Compacting GC
ok, understood. We're considering working on it if we can't solve our issues (if they're finally issues) with libgc. Miguel de Icaza wrote: Hello Pablo, We tried to build it today since we're experiencing issues with libgc under really heavy load. Like I said on my first post: you can try it, but it is not finished. And by not finished, I mean, it is not finished, so it is not going to be useful for you to solve the problem under heavy load. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Unsafe struct array reading
Hi all,
I'm looking for a way to read and write array of structs from a file
(byte array).
I've the code (below) to read *one*, but I don't know how to map an
entire array.
I know there's a thousand of ways to do it with Streams, but the point
is for performance reasons I need to load them all on a single step (as
you'd do with C and fread).
Thank you
pablo
using System;
using System.Runtime.InteropServices;
namespace structIO
{
[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct YourStruct
{
public int First;
public long Second;
public double Third;
public static unsafe byte[] YourStructToBytes(YourStruct s, int
arrayLen)
{
byte[] arr = new byte[sizeof(YourStruct) * arrayLen];
fixed( byte* parr = arr )
{
* ((YourStruct * )parr) = s;
}
return arr;
}
public static unsafe YourStruct BytesToYourStruct(byte[] arr,
int arrayLen)
{
if( arr.Length (sizeof(YourStruct)*arrayLen) )
throw new ArgumentException();
YourStruct s;
fixed( byte* parr = arr )
{
s = *((YourStruct * )parr);
}
return s;
}
}
class structIOTest
{
public static void Main(string[] args)
{
YourStruct[] array = new YourStruct[10];
for( int i = 0; i array.Length; ++i )
{
array[i].First = 10;
array[i].Second = (long) 10;
array[i].Third = (double) 10;
}
byte[] data = YourStruct.YourStructToBytes(array[0],
array.Length);
YourStruct result = YourStruct.BytesToYourStruct(data, 1);
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unsafe struct array reading
Great! Now, could you share some code about how to do it? :-P Thanks, pablo Miguel de Icaza wrote: Hello, I'm looking for a way to read and write array of structs from a file (byte array). If you use the proper packing and do not care about breaking across endian systems, you can always just write the entire array of structures out and read them back in using unsafe pointers. miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compacting GC
Hi there! Is is possible to try the upcoming compacting GC? Is it in a status close to be usable? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Cause libgc to return some unused memory to the system
We tested it on our Plastic SCM load tests and it worked as expected. pablo www.plasticscm.com Dick Porter wrote: Hi all Attached is a patch to libgc that will allow it to actually unmap memory when USE_MUNMAP is defined. Currently, the unmap code just sets the mmap flags on a region to 'no access'. The patch unlinks blocks from the gc free list larger than a defined min size (currently 4k bytes), that haven't been used for several collections, and unmaps the memory. It may or may not fix https://bugzilla.novell.com/show_bug.cgi?id=495486 - the reporter forgot to attach his test case. Comments? - Dick ___ 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] Memory usage on Mono remoting
Hi Gonzalo, First, thanks for the detailed answers. Considering Boehm GC seems to have really hard times releasing memory and we're delivering GBs of data... it could be. Delivering GBs of data and having hundreds of connections should not be a problem. Years ago, when testing iFolder under those conditions everything worked just fine. But it was mod-mono-server/apache. Dick is actually checking this. I hope it's not the issue. I'm not 100% sure, but it seems reusing buffers could be a very good idea. Xsp does it too and it's much better than allocating 32kB for every request every time. Good. Also, you mentioned in a previous email that the TcpChannel should be changed so it uses Asynch sockets. I've seen you use AsyncCallBack on XSP. My question is: I guess AsynchCallback will use a thread underneath, won't it? If so: what's the advantage over launching threads to accept calls? Your guess is wrong. Those asynchronous calls from Socket are treated as if they were a WorkItem for a ThreadPool, only that when they are made, the socket is added to an epoll fd (if you're on linux with support for epoll). And when there's an event in the socket, there's a dedicated IO threadpool to take care of reading/writing data and invoking the callbacks. The advantages: if you have 10k connections, you don't need 10k threads, threads are reused (no creation overhead), ... Ok, of course. Well, when I said launching a thread I really meant launching a thread on a thread pool. Well, I'll try to use the ansync sockets then, but I guess to get the best out of them I'll need not only to use them during accept, but also read data asynchronously, right? BTW, I already replaced the built-in remoting threadpool by the System.Threading one. You mentioned it is better to use the default ThreadPool instead of the internal one in the TcpChannel, why is it going to be better? Coupled with asynchronous I/O, it will make better use of the resources available. There's no need to create 100 threads for 100 client or having 1 threadpool thread blocking on a socket asynchronous operation,... Also, if you're thinking of reusing buffers, this helps too, as the number of buffers will be bound to the maximum number of threads in the threadpool, ... Good, so, whenever I wait for a read or a write using async, the thread should be able to work on another request? I think this is the way it's implemented on Windows, but I can tell you it is still created a huge number of threads, almost 1-1 with clients under the most overloaded scenarios. Thanks, pablo -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage on Mono remoting
Hi Gonzalo, Well, I'll try to use the ansync sockets then, but I guess to get the best out of them I'll need not only to use them during accept, but also read data asynchronously, right? Correct. If possible, Write should also be asynchronous, but as long as the OS buffers everything, there should be no problem. [...] Ok, well, in fact I think I'm experiencing this right now: I've 112 clients against the same server, each of them will download about 300Mb. I see how the thread pool gets full (quad core) and then new requests are accepted but not scheduled. CPU is almost doing nothing, so I guess all threads are waiting for the synchronous socket write to complete, so performance could be much higher. Coupled with asynchronous I/O, it will make better use of the resources available. There's no need to create 100 threads for 100 client or having 1 threadpool thread blocking on a socket asynchronous operation,... Also, if you're thinking of reusing buffers, this helps too, as the number of buffers will be bound to the maximum number of threads in the threadpool, ... Good, so, whenever I wait for a read or a write using async, the thread should be able to work on another request? Correct. In fact, you don't 'wait' for an asynchronous read or write. For instance, when you call BeginRead, the socket is added to an epoll fd and you BeginRead call returns immediately. The callback you provided, if any, will be called from a different thread as soon as new data is available. Just don't spoil it by doing something like socket.EndRead (socket.BeginRead (...))) ;-) ok ! :-P Well, I see it will mean a good number of changes in the Channel. Besides, as I also told Dick and Dave on a separate thread, it seems the latest MySql provider has a HUGE memory leak (ok, or it never frees mem), which is causing a good number of problems to my test. And, it seems I also have to do something with my code since all data requests are reading byte[] in blocks of 4Mb, but not reusing the buffers at all, so when a lot of threads are doing its job, huge amounts of mem are being allocated and giving extra work to the GC which should be completely avoided. I'm a little bit concerned about the following, though: If you've a method like byte[] GetData() which is going to be invoked through remoting, even if you do custom serialization (maybe creating a DataArray class) two copies of the data will be created: one the original you created, and a second one in the serialization buffer prior to be sent to the network... :-( pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage on Mono remoting
Hi Gonzalo, Testing PlasticSCM under really heavy load (hundreds of clients against a single server delivering hundreds of Gb over the network). So no profiling... Comparing the same code, the same hardware and the same test under Linux and Windows. On Windows we run under .NET, and the test passes successfully. Dick (in CC) is looking into GC problems. System.Web uses unmanaged chunks of memory together with an unmanaged memory based stream. That's what I need. Can you point me to the right class? It's HttpResponseStream.cs all the *Bucket classes that then use an IntPtrStream. I still don't think that allocating MemoryStream (256 bytes by default) is hurting that bad. Considering Boehm GC seems to have really hard times releasing memory and we're delivering GBs of data... it could be. I'm not 100% sure, but it seems reusing buffers could be a very good idea. A wild guess is that the BufferedStream wrapping the NetworkStream is allocating much more memory (4kB by default). But if the code is rewritten following what xsp does, this should not be a problem any more. Ok, I'm not familiar with xsp, I'll take a look. I've just noticed that you use send from libc instead of the socket functions... I guess it is due to performance reasons, right? Also, you mentioned in a previous email that the TcpChannel should be changed so it uses Asynch sockets. I've seen you use AsyncCallBack on XSP. My question is: I guess AsynchCallback will use a thread underneath, won't it? If so: what's the advantage over launching threads to accept calls? You mentioned it is better to use the default ThreadPool instead of the internal one in the TcpChannel, why is it going to be better? Thanks again Gonzalo, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage on Mono remoting
Thanks Robert, So: I'll modify the TcpChannel to use ThreadPool at System.Threading instead of the built-in one. Robert Jordan wrote: pablosantosl...@terra.es wrote: Also, you mentioned in a previous email that the TcpChannel should be changed so it uses Asynch sockets. I've seen you use AsyncCallBack on XSP. My question is: I guess AsynchCallback will use a thread underneath, won't it? If so: what's the advantage over launching threads to accept calls? The thread pool threads are already launched and they are maintained by the runtime which is known to be faster than a managed thread pool implementation. Additionally, the default thread pool is already configurable (see mono(1)). You mentioned it is better to use the default ThreadPool instead of the internal one in the TcpChannel, why is it going to be better? See above. 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] TcpServerChannel loosing connections under heavy load
Hi Gonzalo, Inside the threadPool the following code: threadDone.WaitOne(PoolGrowDelay, false); Makes thread creation wait 500ms (I guess just forcing the CPU to switch to another one) each time a new thread is created (when the pool is growing). If you remove it, connection problems go away, but I guess it's not the right way to implement it. That should be modified to make use of the .NET ThreadPool and use asynchronous operations for accept, read and write (this last one is not mandatory). There's code in xsp that illustrates the way it should be done. Which ThreadPool exactly should be used? Could you point me to the right code in xsp? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Memory usage on Mono remoting
Hi all, On BinaryServerFormatterSink.cs, a new MemoryStream is being created to attend every remoting call. Under high load conditions it will make the GC work harder than required, both decreasing performance and potentially causing memory problems. It should be replaced by some sort of MemoryStream based on preallocated memory buffers. Maybe something like ChunkedMemoryStream in Rotor. http://www.koders.com/csharp/fid0C95C784238E26C8EAC95C7A852A34A0CE9305BB.aspx?s=chunkedmemorystream Are you aware of an open source implementation of this? Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage on Mono remoting
Hi, On Mon, 2009-07-13 at 19:39 +0200, pablosantosl...@terra.es wrote: Hi all, On BinaryServerFormatterSink.cs, a new MemoryStream is being created to attend every remoting call. Under high load conditions it will make the GC work harder than required, both decreasing performance and potentially causing memory problems. It should be replaced by some sort of MemoryStream based on preallocated memory buffers. Are you volunteering? Have you profiled the application or is this just a guess? Testing PlasticSCM under really heavy load (hundreds of clients against a single server delivering hundreds of Gb over the network). Yes, I'm volunteering. System.Web uses unmanaged chunks of memory together with an unmanaged memory based stream. That's what I need. Can you point me to the right class? pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage on Mono remoting
Ok, I think you mean IntPtrStream, but I'm not sure it's what I'm looking for. I think managed memory would be enough (unless the other is faster :-P), but I need the stream to reuse preallocated buffers. pablo www.plasticscm.com pablosantosl...@terra.es wrote: Hi, On Mon, 2009-07-13 at 19:39 +0200, pablosantosl...@terra.es wrote: Hi all, On BinaryServerFormatterSink.cs, a new MemoryStream is being created to attend every remoting call. Under high load conditions it will make the GC work harder than required, both decreasing performance and potentially causing memory problems. It should be replaced by some sort of MemoryStream based on preallocated memory buffers. Are you volunteering? Have you profiled the application or is this just a guess? Testing PlasticSCM under really heavy load (hundreds of clients against a single server delivering hundreds of Gb over the network). Yes, I'm volunteering. System.Web uses unmanaged chunks of memory together with an unmanaged memory based stream. That's what I need. Can you point me to the right class? pablo www.plasticscm.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-dev] TcpServerChannel loosing connections under heavy load
Hi,
I'm having issues with Mono remoting under high performance networking
scenarios. Some clients are rejected since the server is not able to
handle connections.
Look at the following code inside TcpServerChannel
(http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp/TcpServerChannel.cs?revision=110042view=markup)
I've removed the #ifdef code for clarity.
void WaitForConnections ()
{
try
{
while(!stopped)
{
Socket socket = listener.AcceptSocket ();
ClientConnection reader = new ClientConnection (this, socket,
sink);
try {
if (!threadPool.RunThread (new ThreadStart
(reader.ProcessMessages)))
socket.Close ();
} catch (Exception e)
{
}
}
}
catch (Exception e)
{
}
}
Well, each time an accept is done, a new thread is launched (from the
pool).
When a high number of threads is managed (about 130 concurrent clients),
it makes the channel reject remote requests.
Inside the threadPool the following code:
threadDone.WaitOne(PoolGrowDelay, false);
Makes thread creation wait 500ms (I guess just forcing the CPU to switch
to another one) each time a new thread is created (when the pool is
growing).
If you remove it, connection problems go away, but I guess it's not the
right way to implement it.
So, what I'll do is to enqueue the newly created ClientConnection in
the accept code instead of spawning the thread just that, so a
different one (or even the pool itself, I'll check) will consume
elements and spawn threads.
This way we avoid the accept thread from getting distracted from its
main job: accepting client connections.
It actually makes me wonder if it would be better to use asynchronous
socket calls instead of synch ones + threading, as they strongly
recommend here:
http://msdn.microsoft.com/es-es/magazine/cc300760(en-us).aspx
.NET TCP Channel is based on asynch socket calls.
My question is: are asynchronous socket calls better on Linux as they're
on Windows?
Also, it would be great (and very easy to implement) if new
configuration properties would be added to the TCP channel so things
like socket options, socket buffer sizes and so on could be set to
improve performance without touching the code (I'll work on that too).
Some very interesting guidelines that could be easily applied then are
found here: Boost socket performance on Linux:
http://www.ibm.com/developerworks/linux/library/l-hisock.html
And I see some have been already applied:
http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp/TcpConnectionPool.cs?r1=113395r2=113394pathrev=113395
Since NoDelay was set by Robert Jordan to the TcpConnectionPool.
Question: I see it applies to the client but, wouldn't it be useful for
the server too?
Thanks,
pablo
www.plasticscm.com
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
Last one I tried and build was 2.2. We're using it to test Plastic every week on OpenSolaris. The binaries are available at Blastwave, but never tried 2.4 Jonathan Soft escribió: I'm reaching the conclusion that Mono v2.4 does not work on Solaris 10 SPARC - this is based on both my own unsuccessful attempts to build and run it (or debug it, for that matter), and on the non existence of reports on the web indicating 2.4 success on the Solaris SPARC platform. Giving up for now. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono v2.4 RC2 (Solaris 10 SPARCv9)
did you try the following magic ? ulimit -Hs 10240 Jonathan Soft escribió: I've also been trying to compile mono v2.4 on Solaris 10 SPARC and have run into the trouble exactly as you describe. By running the make process with 'MONO_LOG_LEVEL=debug' I've concluded that the build process hangs as soon as the local 2.4 mono is invoked to compile runtime .cs source files (build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe etc.). By adding Mono v2.0.1 bin directory to the path we just postpone this hanging from the first attempt to use the local mono applied to 'build/deps/basic-profile-check.exe' to a later attempt applied to System.Xml. I poked arround at internal Makefiles, and by getting gmake to use v2.0.1 mono instead of local 2.4 mono, I was able to get passed System.Xml compilation, however I got stuck at mcs directory compilation, where no makefile manipulation I did could get gmake to use the preinstalled mono. As soon as gmake invokes [build root/mono/mini/mono --config build root/runtime/etc/mono/config .//class/lib/monolite/mcs.exe] we're stuck. By running truss on the hanging process it would seem that it is really caught up in a never-ending loop, but I have no idea why. No more ideas at this point, but I'll post if I make any progress. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Question about Zeroconf sample
Hi, I don't know if there's a more suitable place to send this, if so, please let me know. I was trying today the sample on the Mono Zeroconf (http://www.mono-project.com/Mono.Zeroconf) page. Well, I run it on my OpenSuse box, but the client (nor mzclient) can't see the registered service... No error or exception is raised but the following code RegisterService service = new RegisterService (); service.Name = Aaron's DAAP Share; service.RegType = _daap._tcp; service.ReplyDomain = local.; service.Port = 3689; // TxtRecords are optional TxtRecord txt_record = new TxtRecord (); txt_record.Add (Password, false); service.TxtRecord = txt_record; service.Register (); doesn's seem to register the service correctly I run it both as regular user and root, and I also checked I've the Zeroconf package installed (and of course the Mono assemblies) Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] monodevelop! congratulations!
Hi all, I'd like to thank Lluis and all the MD team for this new release! Several developers in the Plastic SCM team have just switched to MD, and we can successfully debug our server, which is a really important step ahead. It doesn't mean we'll stop using vstudio but it obviously opens a lot of possibilities for our team, specially considering we focus on multiplatform software. Congratulations! pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Can't debug from monodevelop with 2.2
Hi, I've upgraded my develop machine main mono installation to 2.2 and now I can't debug using monodevelop (ouch!). Whenever it tries to launch a process it says it needs Mono.Cecil 0.6.8.8607 but now what I have is something like 0.6.9.xxx I've tried with the latest monodevelop (just downloaded from the monodevelop site using the 1 click install), but same problem... Any pointers will be welcomed since we're *all* moving to MD today... Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can't debug from monodevelop with 2.2
Hi Lluis, Just installed from the official repositories: mono 2.2 and your last MD. It works with mono 2.0.1 I'm using OpenSuse 11 Another question: it seems the variable inspection does not work with generic collections, does it? Thanks, pablo Lluis Sanchez escribió: Looks like your debugger is not in sync with your installed mono. If you compiled the debugger from sources, you should recompile it again. El dj 19 de 02 de 2009 a les 16:57 +0100, en/na pablosantosl...@terra.es va escriure: Hi, I've upgraded my develop machine main mono installation to 2.2 and now I can't debug using monodevelop (ouch!). Whenever it tries to launch a process it says it needs Mono.Cecil 0.6.8.8607 but now what I have is something like 0.6.9.xxx I've tried with the latest monodevelop (just downloaded from the monodevelop site using the 1 click install), but same problem... Any pointers will be welcomed since we're *all* moving to MD today... Thanks, pablo ___ 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] Debugger plans
Hi, I'd like to ask you guys the plans for the Mono Debugger in the short/mid term. Are you planning to support debugger on MacOS? How hard would be to port it to other x86 OSs like Solaris? Thanks, pablo ___ 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?
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. - 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. 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 ___ 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?
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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] weird regression in 2.2 remoting
Hi, I'm having a lot of trouble with remoting and mono 2.2 in a very specific scenario. We extensively use PNUnit (Parallel NUnit) for testing our software. We run tests on Windows, Linux, MacOS x86 PPC and now Solaris. Well, I've just installed Mono 2.2 on MacOS PPC and PNUnit fails. It gets a problem initializing sockets when having to call back a remoting interface. It didn't happen on 2.0.1 and it doesn't happen on 2.4 preview 2. I was trying to isolate a test case but no way I can reproduce it outside the PNUnit. It fails too with official 2.2 on OpenSuse 11. The message is: An exception was thrown by the type initializer for System.Net.Sockets.Socket and the call stack points to TcpConnectionPool.cs:277 pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] solaris x86
Try http://blastwave.network.com/testing/mono-2.0,REV=2009.01.21-SunOS5.8-i386-CSW.pkg.gz I'll try to build 2.2 over the weekend. pablo Cetin Sert escribió: I'd like to know where these binaries can be downloaded. Regards, Cetin Sert 2009/2/6 pablosantosl...@terra.es mailto:pablosantosl...@terra.es pablosantosl...@terra.es mailto:pablosantosl...@terra.es Hi, I've just finished running our internal PNUnit test suite on Open Solaris x86 with hand-compiled Mono 2.2. It works. The same is true for Solaris 10 x86. I've published a test binary release of Mono 2.0.1 for Solaris x86 in blastwave a few weeks ago. Next one will be 2.2. MWF runs on 2.0.1 but (at least on my tests) it was not stable enough. Regards, pablo ___ 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
