Re: [Mono-dev] Mono 1.9.0 Preview 1+ is out!!
Hi, Can I find a list of the included issues? Thanks pablo - Original Message - From: "Thomas Wiest" <[EMAIL PROTECTED]> To: "mono-devel" Sent: Friday, February 01, 2008 9:40 PM Subject: [Mono-dev] Mono 1.9.0 Preview 1+ is out!! > Hey Everyone, >We've just released Mono 1.9.0 Preview 1+ today! Please help us out > by giving it a try with your applications. > > As always, you can get the preview releases here: > http://mono.ximian.com/monobuild/preview/download-preview/ > > Please report any bugs that you may find using our Bugs page, AND reply > to this thread with the bug numbers so we can track them! > http://www.mono-project.com/Bugs > > > The earlier you file the bugs and reply to this message, the more likely > your bugs will get fixed. > > Special attention is given to regressions, so if you can tell us a > version of Mono where the bug worked and tag the summary with > [Regression], then it is much more likely your bug will get fixed. > > > Please help the Mono team to make 1.9.0 the best release of Mono ever. > Thanks again! > > Mono QA > ___ > 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] Control-C handler
Ok, and, do you have plans to integrate it in the near future? I mean, I don't know the status, but I saw there were some potential problems... - Original Message - From: "Jonathan Pryor" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: "Paolo Molaro" <[EMAIL PROTECTED]>; Sent: Saturday, January 19, 2008 1:30 PM Subject: Re: [Mono-dev] Control-C handler > On Sat, 2008-01-19 at 10:01 +0100, pablosantosluac wrote: >> Is it integrated on trunk? > > No. > > - Jon > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Control-C handler
Is it integrated on trunk? - Original Message - From: "Jonathan Pryor" <[EMAIL PROTECTED]> To: "Paolo Molaro" <[EMAIL PROTECTED]> Cc: Sent: Thursday, January 10, 2008 5:52 PM Subject: Re: [Mono-dev] Control-C handler > On Wed, 2008-01-09 at 12:33 -0500, Jonathan Pryor wrote: >> Attached are patches to mcs/class/Mono.Posix/Mono.Unix.Native and >> mono/support as an initial implementation of this idea. It currently >> uses a dedicated Mono.Posix-internal thread to do managed signal >> dispatching (as the ThreadPool is intended for short-lived tasks, and >> I'm not familiar enough with the Timer-related infrastructure to see if >> it would be a good fit). > > Attached is an updated patch set which supports both the existing/new > Stdlib.signal() semantics (as the previous patch set did) in which the > signal handler is invoked on an internal helper thread, and adds a new > Mono.Unix.UnixSignal type to permit polling and/or blocking as lupus > originally suggested. > > The one thing I don't like (but can't think of a workaround) is the > interaction between UnixSignal and Stdlib.signal(): as currently > implemented, UnixSignal and Stdlib.signal() can't handle the same signal > simultaneously -- if UnixSignal registered to handle e.g. SIGINT, then > Stdlib.signal() will return SIG_ERR, with errno set to EEXIST. > > However, the alternate IS possible: UnixSignal can handle e.g. SIGINT if > Stdlib.signal() was previously called to handle it (and will > consequently replace the original Stdlib.signal() handler). The > "original" Stdlib.signal() handler will be replaced when the UnixSignal > instance is destroyed. > > (One workaround I can think of would be for Stdlib.signal() and > UnixSignal to use the same data structures, but I want to keep the > registered_signals array as short as possible to keep down the signal > handler execution time. Plus one concern: what *should* happen if one > thread creates a UnixSignal instance for SIGINT, then calls > UnixSignal.WaitOne(), then another thread calls > Stdlib.signal(SIGINT,SIG_IGN) while WaitOne() is blocking? > > Of course, this could be used as an argument to dump Stdlib.signal() > support entirely, but it needs to stick around to permit setting SIG_IGN > on a given signal. I suppose Stdlib.signal() could be restricted to > just accepting SIG_IGN, SIG_ERR, and SIG_DFL and error out if any other > delegate instance is passed, so that people use UnixSignal for all > significant signal usage, but I don't like this either as currently each > UnixSignal.WaitOne() call requires a separate pipe, while > Stdlib.signal() uses a single pipe multiplexed across all registered > signals...) > > Thoughts? > > - 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-dev] Mono performance benchmark results
Hi, I've just read Miguel's post about language performance benchmark! http://tirania.org/blog/archive/2007/Dec-28.html Well, I have to admit I expected much better results! Although I doubt to what extent this results are meangiful at all. I mean: for the last three weeks we've been heavily working on performance for the upcoming plastic 2.0 release (www.plasticscm.com, in case you don't know what I'm talking about). We're using a big number of computers (thanks to http://www.infor.uva.es/) to stress test a single plastic server and get results out of it. We're running the tests using PNUnit (NUnit parallel extension pnunit.codicesoftware.com, which I'll be hopefully integrating into the next NUnit release thanks to Charlie Poole): they basically consist on "test agents" which simulate user actions (command line) and are almost independent from each other. Of course they all work against the same server. Well, the point is plastic is being tested running on .NET/Mono (all the clients on mono/Linux, always) and we're improving heavy load behaviour. Right now I can say we're much (much) faster than systems like Subversion (we were already with only one client, but the new version will clearly outperform it with big loads) and even wellknown commercial ones (but unfortunately I can't reveal their names... yet). My point here is plastic is running ON MONO, while the competitors are all implemented in C/C++. So, yes, language performance is important, but real life results aren't always comparable to mandelbrot plots! Regards, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Interprocess communication
Yes, remoting is "similar to com", but a full road ahead!
- Original Message -
From: FirstName LastName
To: Justin Cherniak ; Steve Bjorg
Cc: mono-devel
Sent: Thursday, December 27, 2007 4:48 PM
Subject: Re: [Mono-dev] Interprocess communication
What I'm trying to do is to make 2 processes talk on the same machine using a
linux OS. The managed process will act as the master and the unmanaged process
will act like the slave.
The type of communication I wish to use would be something easy to use like
in .NET such as COM objects. This allows me to use interface when
communicating and it avoids me to handle the communication between both
processes.
In mono, I wonder if there is something similar? If not, well, I will have
to do the communication.
In order words, is there a simple interprocess communication (like COM) that
would alllow my managed application to talk to the unmanaged application?
If so, can this communication use pipes (but not sockets) for the transport
of data?
Thanks again!
Date: Thu, 27 Dec 2007 02:37:57 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [Mono-dev] Interprocess communication
CC: [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com
Thats not a bad idea, didn't think of it...but its a little tricker to do
the other side from unmanaged code. Again I'm not sure how to work it on *nix,
but on Windows, you can use the same APIs that HttpListener uses from unmanaged
code using the HTTP Server API (see
http://msdn2.microsoft.com/en-us/library/aa364510(VS.85).aspx) or Windows HTTP
Services (client -
http://msdn2.microsoft.com/en-us/library/aa384273(VS.85).aspx)
Justin
On Dec 27, 2007 12:27 AM, Steve Bjorg <[EMAIL PROTECTED]> wrote:
You could use TcpSocket or HttpListener over localhost (loopback). Using
HttpListener is rather straightforward:
string connectionEndPoint = " http://localhost:";;
//*** setting up the listener ***
HttpListener listener = new HttpListener();
listener.Prefixes.Add(connectionEndPoint);
listener.Start ();
AsyncCallback callback = delegate(IAsyncResult ar) {
HttpListenerContext httpContext = listener.EndGetContext(ar);
//--- do your processing here ---
listener.BeginGetContext(callback, listener);
};
listener.BeginGetContext(callback, listener);
//*** sending a message ***
HttpWebRequest httpRequest =
(HttpWebRequest)WebRequest.Create(connectionEndPoint);
httpRequest.Method = "POST";
using(Stream stream = httpRequest.GetRequestStream()) {
stream.Write(data, 0, date.Length);
}
HttpWebResponse httpResponse =
(HttpWebResponse)httpRequest.GetResponse();
bool success = (httpResponse.StatusCode >= 200) &&
(httpResponse.StatusCode < 300);
httpResponse.Close()
Package this into helper functions and make the connection end point
configurable and voila, portable cross process communication. This is also a
great launch pad into making your system network distributed if need be as well
as take advantage of the various object seriializers in .net and mono.
- Steve
--
Steve G. Bjorg
http://wiki.mindtouch.com
http://wiki.opengarden.org
On Dec 26, 2007, at 8:43 PM, Justin Cherniak wrote:
Unfortunately as far as I know there is no easy one off way to do this.
That said, if you are communicating to an unmanaged process, I would assume it
is a safe assumption to assume you are targeting a particular operating system.
I can't help you much with *nix, but on windows, you have a number of
options including:
a.. COM
b.. Shared memory
c.. Window messages
What exactly are you trying to do, I (or someone else) might be able to
narrow it down to a clearer solution.
Thanks,
Justin
On Dec 26, 2007 10:21 PM, FirstName LastName <[EMAIL PROTECTED]> wrote:
Hi,
I'm currently trying to find a way to make 2 processes on the same
machine talk.
One process is managed while the other is unmanaged. How can I do
this?
Thanks!
--
HO HO HO, if you've been nice this year, email Santa! Visit
asksanta.ca to learn more!
___
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] 1.2.6 on mac
Ok, it seems the problems arised using your "blog" driver... We'll try to send you some testcases, but it won't be easy because most of the times you need a "complex" app to reproduce the problems... pablo - Original Message - From: "Geoff Norton" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: "David Suarez" <[EMAIL PROTECTED]>; Sent: Thursday, December 20, 2007 7:10 PM Subject: Re: [Mono-dev] 1.2.6 on mac > Pablo, > > >> Ok, please take a look at your macos Quartz driver running the most >> beautiful :-P winforms application: >> >> http://www.flickr.com/search/?q=plastic+scm+macos >> > > Looks great! > >> Unfortunately it is quite unstable on MacOS right now, but David can >> point out many of the issues he's finding, so I guess we can help here. >> > > Are you running 1.2.6 or the updated driver from my blog? > >> Basically we've found: >> >> - The different windows easily loose focus and the focus is kept by the >> parent window. > > If you're running the updated driver from my blog can you make a testcase > for this and file a bug please? > >> >> - Each repaint repaints everything on a control, even when a custom >> control is designed to make its own painting. This creates flickering. > > This is a known issue > > -g > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 1.2.6 on mac
Just pure Mono/WinForms... and the results really paid off! So, I think it is quite clear there are opportunities to make some great GUI multiplatform code with WinForms... so yes, mono is ready for the enterprise (http://tirania.org/blog/archive/2007/Dec-06.html), and not only on the GUI... also strong server code! :-) pablo - Original Message - From: "Gavin Landon" <[EMAIL PROTECTED]> To: "David Suarez" <[EMAIL PROTECTED]> Cc: Sent: Thursday, December 20, 2007 7:46 PM Subject: Re: [Mono-dev] 1.2.6 on mac > Wow.. Looks really good. I've done some development in AIR and that UI > I would have never guessed it wasn't AIR. > > -Original Message- > From: David Suarez [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 20, 2007 12:43 PM > To: Gavin Landon > Cc: mono-devel-list@lists.ximian.com > Subject: RE: [Mono-dev] 1.2.6 on mac > > Hi Gavin, > > >> Looks a lot better than Surround SCM.. David, are you using Adobe > AIR >> and/or Flex for the UI? > > Mono winforms only, with several custom controls. > > > ___ > 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] Control-C handler
Ok, I think I got a bit lost here... how should I proceed then? Thanks, pablo - Original Message - From: "Jonathan Pryor" <[EMAIL PROTECTED]> To: "Miguel de Icaza" <[EMAIL PROTECTED]> Cc: Sent: Thursday, December 20, 2007 8:41 PM Subject: Re: [Mono-dev] Control-C handler > On Thu, 2007-12-20 at 14:16 -0500, Miguel de Icaza wrote: >> Hello, >> >> > You can use signal(2), which is helpfully exposed by Mono.Posix.dll. >> > >> > See the attached program. >> >> This actually would corrupt the application state, because the C-c >> handler will run the entire JIT at that point and this happens in the >> same thread as the executing thread. > > Isn't there a method that says "JIT this function now"? (I thought > Marshal.Prelink() did that, which is what Stdlib.signal() calls, but I > just re-read the documentation and it doesn't do anything of the sort.) > > Before dropping to C, though, there are two alternatives: > > 1. Call handler() *before* passing it to Stdlib.signal(): > > handler (-1); > Stdlib.signal (Signum.SIGINT, handler); > /* ... as before ... */ > > This would require changing handler() to know about this initialization > call and NOT set ctrl_c_pressed if the parameter is -1. > > This would also allow a pure C# signal handler, as the method will be > JITed during the first handler() call. > > 2. Use System.Runtime.ConstrainedExecution.PrePrepareMethodAttribute on > the signal handler method. This would require that Mono have support > for Constrained Execution regions, which I believe is currently lacking, > but would presumably eventually be supported. > > - 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-dev] Control-C handler
Hi, I've found the following code to set a Control-C handler on a .NET 1.1 application. http://geekswithblogs.net/mrnat/archive/2004/09/23/11594.aspx Is there a way to do the same on Linux/Mono? 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] 1.2.6 on mac
Hi Geoff, It looks like a great work!! Ok, please take a look at your macos Quartz driver running the most beautiful :-P winforms application: http://www.flickr.com/search/?q=plastic+scm+macos Unfortunately it is quite unstable on MacOS right now, but David can point out many of the issues he's finding, so I guess we can help here. Basically we've found: - The different windows easily loose focus and the focus is kept by the parent window. - Each repaint repaints everything on a control, even when a custom control is designed to make its own painting. This creates flickering. Ok, this problems broke the app before we could get further. We weren't able to run it with the Cocoa driver. Thanks, pablo - Original Message - From: "Geoff Norton" <[EMAIL PROTECTED]> To: "David Suarez" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, December 19, 2007 8:26 PM Subject: Re: [Mono-dev] 1.2.6 on mac > David, > > http://lists.ximian.com/pipermail/mono-list/2007-December/037244.html > > -g > > On 19-Dec-07, at 9:04 AM, David Suarez wrote: > >> Hi, >> >> I'm trying a simple winforms app on macosx (tiger), just a form with a >> picture box inside, with the latest 1.2.6 installer. It keeps saying >> that it >> can't open display (X-Server required...). I understand there is a new >> native driver for winforms on mac on 1.2.6, is there any setting to >> activate >> it? >> >> I previously had an older mono version, maybe it is getting settings >> from >> that? >> >> Cheers, >> >> David >> >> 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] performance counters
Hi, I was thinking about implementing some sort of performance counter in our app to check certain parameters. I've seen PerformanceCounters are not implemented. I guess they don't have the same sense on Linux... What would be your preferred way to do so? pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Ok, I'll make a socket based test and see whether it works - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Tuesday, December 18, 2007 3:10 PM Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream Hi, pablosantosluac wrote: > Hi again, > > Ok, forget the last one! It seems I'm getting a huge variation on Linux, > but > I don't know exactly why. But now I doubt it is really related to the > "ssl" > code. > > As Sebastien pointed out, on Linux/Mono it seems my "fix" is not necessary > at all. > > > And this leads me to the second question, related to the one I was > discussing with Robert... why there is such a huge difference between > runs? > > I'm trying a simple remoting program that just exports a method which > waits > one second and returns a simple string. > > Ok, having said so, using both a regular tcp channel and a "ssl channel" > I'm > getting very different times: from completing 200 connections in 7 seconds > using SSL to doing the same in 180seconds... I can see this even with your simple test case. Sporadically it takes much longer to complete the 40 threads test. > > The same happens with tcp connection: from 2 seconds for 200 connections > to > more than 90! > > I guess this is related to something its been doing wrong with TCP/IP... > ¿?¿?¿? It seems to be some code that blocks if more than N connections are pending. Or more than N threads are running. Or both... And it's not the "usual suspect" GC. I already switched it off. Robert > > > Thanks, > > > pablo > > > > > - Original Message - > From: "pablosantosluac" <[EMAIL PROTECTED]> > To: "Sebastien Pouliot" <[EMAIL PROTECTED]> > Cc: "mono-devel-list" > Sent: Tuesday, December 18, 2007 11:18 AM > Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > > >> Hi again Sebastien, >> >> I tried to go step by step checking the topics you mentioned. >> >> I run my test (opening 200 SSL connections) >> >> 1- I tried compiling it with MS/.net 2.0. No difference at all. Same >> times >> as 1.1. >> >> 2- Run on my box: 1.4 Pentium M with 2GB RAM. (.NET) >> >> - Regular mono.security -> 58s >> - compiled mono.security "caching" (which I think is not general, so a >> different solution would be needed, but it is valid on my test) the mono >> internal certification calculation -> 31s >> >> 3- Tried on Mono/Linux (Xeon machine). >> - Regular mono.security -> 94 s >> - compiled mono.security caching internal X509 certificate generation -> >> 47s >> >> Ok, I can be doing something wrong in my test, but it really looks like a >> big performance increase, even on Mono/Linux. The point is actually >> caching >> into the Certificate the internal conversion to the Mono certificate, if >> possible. >> >> >> Thanks, >> >> >> pablo >> >> >> >> >> >> >> >> >> - Original Message - >> From: "pablosantosluac" <[EMAIL PROTECTED]> >> To: "Sebastien Pouliot" <[EMAIL PROTECTED]> >> Cc: "mono-devel-list" >> Sent: Tuesday, December 18, 2007 8:28 AM >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >>> Hi Sebastien, >>> >>> Ok, understood. >>> >>> Well, I'll run it with the profiler under mono and let you know where >>> I'm >>> loosing the time. >>> >>> So, yes, I have a big problem when running on .net then... :-( >>> >>> Ok, so, if I understand correctly, this RSA property at X509Certificate >>> class shouldn't take time when running under the mono framework, should >>> it? >>> It should be invoked anyway, but wouldn't waste time because the >>> CryptoServiceProvider is better implemented... >>> >>> Thanks, >>> >>> pablo >>> >>> - Original Message - >>> From: "Sebastien Pouliot" <[EMAIL PROTECTED]> >>> To: "pablosantosluac" <[EMAIL PROTECTED]> >>> Cc: "mono-devel-list" >>> Sent: Tuesday, December 18, 2007 1:07 AM >>> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >>> >>> >>>> Hey, >>>> >>>> On Mon, 2007-12-17 at 22:49 +0100, pablosantos
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Thanks Sebastien, Yes, I'm currently doing so: each test starts a single connection first, then it starts launching threads! Thanks pablo - Original Message - From: "Sebastien Pouliot" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: "mono-devel-list" Sent: Tuesday, December 18, 2007 2:30 PM Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > Hey, > > On Tue, 2007-12-18 at 13:13 +0100, pablosantosluac wrote: >> Hi again, >> >> Ok, forget the last one! It seems I'm getting a huge variation on Linux, >> but >> I don't know exactly why. But now I doubt it is really related to the >> "ssl" >> code. >> >> As Sebastien pointed out, on Linux/Mono it seems my "fix" is not >> necessary >> at all. >> >> >> And this leads me to the second question, related to the one I was >> discussing with Robert... why there is such a huge difference between >> runs? >> >> I'm trying a simple remoting program that just exports a method which >> waits >> one second and returns a simple string. >> >> Ok, having said so, using both a regular tcp channel and a "ssl channel" >> I'm >> getting very different times: from completing 200 connections in 7 >> seconds >> using SSL to doing the same in 180seconds... >> >> The same happens with tcp connection: from 2 seconds for 200 connections >> to >> more than 90! > > Many thing could occurs... How are you doing the timing ? Does it > includes both client and server time ? > > If so then there's an optimization that could explain this (or part of > it) variation. As I said in a previous email the SslClientStream > implements session caching. However this works (i.e. save a lot of time) > if a previous *complete* server session exists. > > Now it's possible that too much session are stared simultaneously on the > server, which requires it to do a full session for each (well many) > clients before it can start reuse them. On other runs it's possible a > single session negotiation is completed before others, in this case the > first one can be shared (with *great* performance benefit). > > On way to hack around this would be to do a single connection (from each > client to the server) before starting all the threads. That would ensure > a minimum of full (heavy) sessions are done (i.e. a maximum of session > reuse). > >> I guess this is related to something its been doing wrong with TCP/IP... >> ¿?¿?¿? >> >> >> Thanks, >> >> >> pablo >> >> >> >> >> - Original Message - >> From: "pablosantosluac" <[EMAIL PROTECTED]> >> To: "Sebastien Pouliot" <[EMAIL PROTECTED]> >> Cc: "mono-devel-list" >> Sent: Tuesday, December 18, 2007 11:18 AM >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >> > Hi again Sebastien, >> > >> > I tried to go step by step checking the topics you mentioned. >> > >> > I run my test (opening 200 SSL connections) >> > >> > 1- I tried compiling it with MS/.net 2.0. No difference at all. Same >> > times >> > as 1.1. >> > >> > 2- Run on my box: 1.4 Pentium M with 2GB RAM. (.NET) >> > >> > - Regular mono.security -> 58s >> > - compiled mono.security "caching" (which I think is not general, so a >> > different solution would be needed, but it is valid on my test) the >> > mono >> > internal certification calculation -> 31s >> > >> > 3- Tried on Mono/Linux (Xeon machine). >> > - Regular mono.security -> 94 s >> > - compiled mono.security caching internal X509 certificate >> > generation -> >> > 47s >> > >> > Ok, I can be doing something wrong in my test, but it really looks like >> > a >> > big performance increase, even on Mono/Linux. The point is actually >> > caching >> > into the Certificate the internal conversion to the Mono certificate, >> > if >> > possible. >> > >> > >> > Thanks, >> > >> > >> > pablo >> > >> > >> > >> > >> > >> > >> > >> > >> > - Original Message - >> > From: "pablosantosluac" <[EMAIL PROTECTED]> >> > To: "Sebastien Pouliot" <[EMAIL PROTECTED]>
Re: [Mono-dev] Remoting and thread pool limits
Hi Robert, I'm trying this together with a SSL remoting channel. I'm observing huge variations: I don't see anymore the "80" connections problems: I can run the test launching 200 threads and doing 200 connections in less than 2 seconds. (mono/Linux) When I use the SSL channel on Mono/Linux I can get about 7 seconds to complete the test. But the "bad" thing is that from time to time the same test takes about 40 secs for tcp and about 180 for ssl!!! I still didn't find out why there's such a difference!! Do you think it could be related to the tcp stack? Maybe it is needed to create sockets with different params or something like that? Thanks, pablo - Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: ; "Robert Jordan" <[EMAIL PROTECTED]> Sent: Monday, December 17, 2007 11:59 PM Subject: Re: [Mono-dev] Remoting and thread pool limits > Ok, so this are the ones to inspect then: ProcessMessages, > ReceiveMessageStatus and StreamRead. Well, looks ok that they are the ones > eating CPU (the system is processing requests), but... why they go worse > when dealing with more than 80 threads? > > Looking at the code I can't see anything at these methods... :-( I'll try > to > look into it again in more detail... > > Thanks, > > pablo > > - Original Message - > From: "Robert Jordan" <[EMAIL PROTECTED]> > To: > Sent: Monday, December 17, 2007 11:45 PM > Subject: Re: [Mono-dev] Remoting and thread pool limits > > >> Hi Pablo, >> >> pablosantosluac wrote: >>> Hi Robert, >>> >>> Do you think it is related to the thread creation? >> >> I don't think so. Most of the time is spent in TcpChannel: >> >> System.Runtime.Remoting.Channels.Tcp.ClientConnection::ProcessMessages() >> System.Runtime.Remoting.Channels.Tcp.TcpMessageIO::ReceiveMessageStatus(Stream,byte[]) >> System.Runtime.Remoting.Channels.Tcp.TcpMessageIO::StreamRead(Stream,byte[],int) >> >> When I stop the test at 40 threads, these methods are not at the top >> anymore. >> >> Robert >> >>> >>> I'll run some tests with the mono profiler on Linux and try to figure >>> out >>> where the time is being lost... >>> >>> >>> pablo >>> >>> >>> >>> - Original Message - >>> From: "Robert Jordan" <[EMAIL PROTECTED]> >>> To: >>> Sent: Saturday, December 15, 2007 9:25 PM >>> Subject: Re: [Mono-dev] Remoting and thread pool limits >>> >>> >>>> pablosantosluac wrote: >>>>> Well, it is not a *bug* but a feature. I wonder if it should be >>>>> changed. >>>>> If >>>>> you look into RemotingThreadPool.cs there is a line like: >>>>> >>>>> >>>>> threadDone.WaitOne(PoolGrowDelay, false); >>>>> >>>>> >>>>> This one is actually the one making the process too slow. I'm afraid >>>>> it >>>>> must >>>>> be something similar on the .NET code too! >>>>> >>>>> Of course removing this line the problem gets solved, but I guess >>>>> there >>>>> is a >>>>> reason in the channel to do that. >>>> I noticed that too, but this doesn't solve the real problem: the 200 >>>> thread test is still too slow on my machine. The degradation seems to >>>> start after 60-80 threads on my pretty weak SMP machine. >>>> >>>> Just to be sure, I've replaced RemotingThreadPool with an own, simple >>>> version based on the standard BCL ThreadPool => same issue, although >>>> I've raised the env var MONO_THREADS_PER_CPU to an insane value. >>>> >>>> Robert >>>> >>>>> >>>>> pablo >>>>> >>>>> >>>>> - Original Message - >>>>> From: "Robert Jordan" <[EMAIL PROTECTED]> >>>>> To: >>>>> Sent: Saturday, December 15, 2007 4:12 PM >>>>> Subject: Re: [Mono-dev] Remoting and thread pool limits >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> pablosantosluac wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've found the following difference working with .NET and Mono >>>>>>> remoting. >
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Hi again, Ok, forget the last one! It seems I'm getting a huge variation on Linux, but I don't know exactly why. But now I doubt it is really related to the "ssl" code. As Sebastien pointed out, on Linux/Mono it seems my "fix" is not necessary at all. And this leads me to the second question, related to the one I was discussing with Robert... why there is such a huge difference between runs? I'm trying a simple remoting program that just exports a method which waits one second and returns a simple string. Ok, having said so, using both a regular tcp channel and a "ssl channel" I'm getting very different times: from completing 200 connections in 7 seconds using SSL to doing the same in 180seconds... The same happens with tcp connection: from 2 seconds for 200 connections to more than 90! I guess this is related to something its been doing wrong with TCP/IP... ¿?¿?¿? Thanks, pablo ----- Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: "Sebastien Pouliot" <[EMAIL PROTECTED]> Cc: "mono-devel-list" Sent: Tuesday, December 18, 2007 11:18 AM Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > Hi again Sebastien, > > I tried to go step by step checking the topics you mentioned. > > I run my test (opening 200 SSL connections) > > 1- I tried compiling it with MS/.net 2.0. No difference at all. Same times > as 1.1. > > 2- Run on my box: 1.4 Pentium M with 2GB RAM. (.NET) > > - Regular mono.security -> 58s > - compiled mono.security "caching" (which I think is not general, so a > different solution would be needed, but it is valid on my test) the mono > internal certification calculation -> 31s > > 3- Tried on Mono/Linux (Xeon machine). > - Regular mono.security -> 94 s > - compiled mono.security caching internal X509 certificate generation -> > 47s > > Ok, I can be doing something wrong in my test, but it really looks like a > big performance increase, even on Mono/Linux. The point is actually > caching > into the Certificate the internal conversion to the Mono certificate, if > possible. > > > Thanks, > > > pablo > > > > > > > > > - Original Message - > From: "pablosantosluac" <[EMAIL PROTECTED]> > To: "Sebastien Pouliot" <[EMAIL PROTECTED]> > Cc: "mono-devel-list" > Sent: Tuesday, December 18, 2007 8:28 AM > Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > > >> Hi Sebastien, >> >> Ok, understood. >> >> Well, I'll run it with the profiler under mono and let you know where I'm >> loosing the time. >> >> So, yes, I have a big problem when running on .net then... :-( >> >> Ok, so, if I understand correctly, this RSA property at X509Certificate >> class shouldn't take time when running under the mono framework, should >> it? >> It should be invoked anyway, but wouldn't waste time because the >> CryptoServiceProvider is better implemented... >> >> Thanks, >> >> pablo >> >> - Original Message - >> From: "Sebastien Pouliot" <[EMAIL PROTECTED]> >> To: "pablosantosluac" <[EMAIL PROTECTED]> >> Cc: "mono-devel-list" >> Sent: Tuesday, December 18, 2007 1:07 AM >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >>> Hey, >>> >>> On Mon, 2007-12-17 at 22:49 +0100, pablosantosluac wrote: >>>> Hi again, >>>> >>>> >> Well, the line which is actually consuming 50% of the time is >>>> >> new MonoX509.X509Certificate(serverCertificate.GetRawCertData()); >>>> >> inside the ServerContext constructor. >>>> > >>>> > Are you running this under Mono or MS runtime ? >>>> >>>> MS. >>> >>> well wrong mailing list ;-) >>> >>> Seriously 1.x frameworks* has a serious design flaw wrt to [RSA| >>> DSA]CryptoServiceProvider classes (the former used by the SSL code). >>> Each time one you create an instance of it then it *always* creates a >>> new keypair - even if it is created to load an existing keypair. This >>> makes the classes unusable for server applications. >>> >>> Mono design is different and a keypair is only created if (and when) >>> required. >>> >>> >>> * at least I think it was fixed in 2.0 - I've been bugging them to fix >>> this since 1.0 beta2. >>> >>>>
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Hi again Sebastien, I tried to go step by step checking the topics you mentioned. I run my test (opening 200 SSL connections) 1- I tried compiling it with MS/.net 2.0. No difference at all. Same times as 1.1. 2- Run on my box: 1.4 Pentium M with 2GB RAM. (.NET) - Regular mono.security -> 58s - compiled mono.security "caching" (which I think is not general, so a different solution would be needed, but it is valid on my test) the mono internal certification calculation -> 31s 3- Tried on Mono/Linux (Xeon machine). - Regular mono.security -> 94 s - compiled mono.security caching internal X509 certificate generation -> 47s Ok, I can be doing something wrong in my test, but it really looks like a big performance increase, even on Mono/Linux. The point is actually caching into the Certificate the internal conversion to the Mono certificate, if possible. Thanks, pablo - Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: "Sebastien Pouliot" <[EMAIL PROTECTED]> Cc: "mono-devel-list" Sent: Tuesday, December 18, 2007 8:28 AM Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > Hi Sebastien, > > Ok, understood. > > Well, I'll run it with the profiler under mono and let you know where I'm > loosing the time. > > So, yes, I have a big problem when running on .net then... :-( > > Ok, so, if I understand correctly, this RSA property at X509Certificate > class shouldn't take time when running under the mono framework, should > it? > It should be invoked anyway, but wouldn't waste time because the > CryptoServiceProvider is better implemented... > > Thanks, > > pablo > > - Original Message - > From: "Sebastien Pouliot" <[EMAIL PROTECTED]> > To: "pablosantosluac" <[EMAIL PROTECTED]> > Cc: "mono-devel-list" > Sent: Tuesday, December 18, 2007 1:07 AM > Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > > >> Hey, >> >> On Mon, 2007-12-17 at 22:49 +0100, pablosantosluac wrote: >>> Hi again, >>> >>> >> Well, the line which is actually consuming 50% of the time is >>> >> new MonoX509.X509Certificate(serverCertificate.GetRawCertData()); >>> >> inside the ServerContext constructor. >>> > >>> > Are you running this under Mono or MS runtime ? >>> >>> MS. >> >> well wrong mailing list ;-) >> >> Seriously 1.x frameworks* has a serious design flaw wrt to [RSA| >> DSA]CryptoServiceProvider classes (the former used by the SSL code). >> Each time one you create an instance of it then it *always* creates a >> new keypair - even if it is created to load an existing keypair. This >> makes the classes unusable for server applications. >> >> Mono design is different and a keypair is only created if (and when) >> required. >> >> >> * at least I think it was fixed in 2.0 - I've been bugging them to fix >> this since 1.0 beta2. >> >>> Running with a profiler. Mono results are currently slower, but it could >>> be related to something else. >> >> If Mono is slower then this is probably elsewhere. >> >>> I'm having problems when creating more than 80 >>> threads/sockets. Don't know why yet. >>> >>> >>> >> Of course it is related to the RSA calculation inside the MonoX509 >>> >> certificate. >>> > >>> > Please provide additional details as there is no RSA computation >>> > required in the mentioned ctor. >>> > >>> >> I guess it could be catched >>> > >>> > you mean "cached" ? >>> >>> Yes, sorry, cached! >>> >>> >>> >> when attending different clients >>> >> with the same server certificate, which would improve overall >>> >> performance >>> >> (in my previous email I said it was only local to one client, but I >>> >> was >>> >> wrong). >>> > >>> > As I said this CANNOT be cached between a server and multiple clients >>> > (a >>> > little long to explain but it's how SSL is designed). >>> >>> Ok, whatever, there's a property called RSA inside the Mono X509 >>> certificate. This property gets invoked once per SSL connection, >>> actually >>> calculating the same for each connection, >> >> Well it's not the same since this is a new key pair each time ;-) but >> y
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Hi Sebastien, Ok, understood. Well, I'll run it with the profiler under mono and let you know where I'm loosing the time. So, yes, I have a big problem when running on .net then... :-( Ok, so, if I understand correctly, this RSA property at X509Certificate class shouldn't take time when running under the mono framework, should it? It should be invoked anyway, but wouldn't waste time because the CryptoServiceProvider is better implemented... Thanks, pablo - Original Message - From: "Sebastien Pouliot" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: "mono-devel-list" Sent: Tuesday, December 18, 2007 1:07 AM Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream > Hey, > > On Mon, 2007-12-17 at 22:49 +0100, pablosantosluac wrote: >> Hi again, >> >> >> Well, the line which is actually consuming 50% of the time is >> >> new MonoX509.X509Certificate(serverCertificate.GetRawCertData()); >> >> inside the ServerContext constructor. >> > >> > Are you running this under Mono or MS runtime ? >> >> MS. > > well wrong mailing list ;-) > > Seriously 1.x frameworks* has a serious design flaw wrt to [RSA| > DSA]CryptoServiceProvider classes (the former used by the SSL code). > Each time one you create an instance of it then it *always* creates a > new keypair - even if it is created to load an existing keypair. This > makes the classes unusable for server applications. > > Mono design is different and a keypair is only created if (and when) > required. > > > * at least I think it was fixed in 2.0 - I've been bugging them to fix > this since 1.0 beta2. > >> Running with a profiler. Mono results are currently slower, but it could >> be related to something else. > > If Mono is slower then this is probably elsewhere. > >> I'm having problems when creating more than 80 >> threads/sockets. Don't know why yet. >> >> >> >> Of course it is related to the RSA calculation inside the MonoX509 >> >> certificate. >> > >> > Please provide additional details as there is no RSA computation >> > required in the mentioned ctor. >> > >> >> I guess it could be catched >> > >> > you mean "cached" ? >> >> Yes, sorry, cached! >> >> >> >> when attending different clients >> >> with the same server certificate, which would improve overall >> >> performance >> >> (in my previous email I said it was only local to one client, but I >> >> was >> >> wrong). >> > >> > As I said this CANNOT be cached between a server and multiple clients >> > (a >> > little long to explain but it's how SSL is designed). >> >> Ok, whatever, there's a property called RSA inside the Mono X509 >> certificate. This property gets invoked once per SSL connection, actually >> calculating the same for each connection, > > Well it's not the same since this is a new key pair each time ;-) but > yes it's unneeded > >> because it is just "completing" >> (AFAIK) the server's certificate, if I'm not wrong, of course. I mean, >> the >> certificate you pass to the SSLServerStream gets converted again and >> again, >> and consuming time. If this can be cached, then the performance can be >> really boosted. I think this is *just* the server's certificate, nothing >> to >> do with the client (I guess). And yes, maybe it is not RSA calculation, >> but >> this is the name of the property where the time is being spent... at >> least >> under MS runtime. > > No, as I said, this is probably time "lost" doing unneeded keypair > generation (but this is not the case for Mono). > >> pablo >> >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> >> >> >> pablo >> >> >> >> >> >> >> >> - Original Message - >> >> From: "Sebastien Pouliot" <[EMAIL PROTECTED]> >> >> To: "pablosantosluac" <[EMAIL PROTECTED]> >> >> Cc: >> >> Sent: Monday, December 17, 2007 7:50 PM >> >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >> >> >> >> > Hello Pablo, >> >> > >> >> > On Mon, 2007-12-17 at 17:21 +0100, pablosantosluac wrote: >> >> >&
Re: [Mono-dev] Remoting and thread pool limits
Ok, so this are the ones to inspect then: ProcessMessages, ReceiveMessageStatus and StreamRead. Well, looks ok that they are the ones eating CPU (the system is processing requests), but... why they go worse when dealing with more than 80 threads? Looking at the code I can't see anything at these methods... :-( I'll try to look into it again in more detail... Thanks, pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Monday, December 17, 2007 11:45 PM Subject: Re: [Mono-dev] Remoting and thread pool limits > Hi Pablo, > > pablosantosluac wrote: >> Hi Robert, >> >> Do you think it is related to the thread creation? > > I don't think so. Most of the time is spent in TcpChannel: > > System.Runtime.Remoting.Channels.Tcp.ClientConnection::ProcessMessages() > System.Runtime.Remoting.Channels.Tcp.TcpMessageIO::ReceiveMessageStatus(Stream,byte[]) > System.Runtime.Remoting.Channels.Tcp.TcpMessageIO::StreamRead(Stream,byte[],int) > > When I stop the test at 40 threads, these methods are not at the top > anymore. > > Robert > >> >> I'll run some tests with the mono profiler on Linux and try to figure out >> where the time is being lost... >> >> >> pablo >> >> >> >> - Original Message - >> From: "Robert Jordan" <[EMAIL PROTECTED]> >> To: >> Sent: Saturday, December 15, 2007 9:25 PM >> Subject: Re: [Mono-dev] Remoting and thread pool limits >> >> >>> pablosantosluac wrote: >>>> Well, it is not a *bug* but a feature. I wonder if it should be >>>> changed. >>>> If >>>> you look into RemotingThreadPool.cs there is a line like: >>>> >>>> >>>> threadDone.WaitOne(PoolGrowDelay, false); >>>> >>>> >>>> This one is actually the one making the process too slow. I'm afraid it >>>> must >>>> be something similar on the .NET code too! >>>> >>>> Of course removing this line the problem gets solved, but I guess there >>>> is a >>>> reason in the channel to do that. >>> I noticed that too, but this doesn't solve the real problem: the 200 >>> thread test is still too slow on my machine. The degradation seems to >>> start after 60-80 threads on my pretty weak SMP machine. >>> >>> Just to be sure, I've replaced RemotingThreadPool with an own, simple >>> version based on the standard BCL ThreadPool => same issue, although >>> I've raised the env var MONO_THREADS_PER_CPU to an insane value. >>> >>> Robert >>> >>>> >>>> pablo >>>> >>>> >>>> - Original Message - >>>> From: "Robert Jordan" <[EMAIL PROTECTED]> >>>> To: >>>> Sent: Saturday, December 15, 2007 4:12 PM >>>> Subject: Re: [Mono-dev] Remoting and thread pool limits >>>> >>>> >>>>> Hi, >>>>> >>>>> pablosantosluac wrote: >>>>>> Hi, >>>>>> >>>>>> I've found the following difference working with .NET and Mono >>>>>> remoting. >>>>>> In >>>>>> .NET when the remoting ThreadPool reaches the pool's maximum (25 >>>>>> threads >>>>>> per >>>>>> process), it is able to continue creating new threads. In fact, you >>>>>> can >>>>>> end >>>>>> up having a remoting server with hundreds of threads. >>>>>> >>>>>> In mono the behaviour is different. Once the limit is reached it >>>>>> starts >>>>>> refusing connections. >>>>> This is unrelated to mono's remoting thread pool. You have probably >>>>> ran your tests on Windows, where mono indeed fails with a GC failure >>>>> when too many threads are created because the GC has a hard coded >>>>> max thread count limit. >>>>> >>>>> On Linux (x86_64, Mono 1.2.6) I can finish the tests: >>>>> >>>>> Linux Mono client -> Linux Mono server (same machine) >>>>> >>>>> poseidon [~/foo] $ mono client/bin/Debug/client.exe >>>>> tcp://localhost:8084/remote >>>>> 1 - Time 1206 ms >>>>> 5 - Time 2045 ms >>>>> 10 - Time 3575 ms >>>>> 20 - Time 8174 ms >>>>>
Re: [Mono-dev] Remoting and thread pool limits
Hi Robert, Do you think it is related to the thread creation? I'll run some tests with the mono profiler on Linux and try to figure out where the time is being lost... pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Saturday, December 15, 2007 9:25 PM Subject: Re: [Mono-dev] Remoting and thread pool limits > pablosantosluac wrote: >> Well, it is not a *bug* but a feature. I wonder if it should be changed. >> If >> you look into RemotingThreadPool.cs there is a line like: >> >> >> threadDone.WaitOne(PoolGrowDelay, false); >> >> >> This one is actually the one making the process too slow. I'm afraid it >> must >> be something similar on the .NET code too! >> >> Of course removing this line the problem gets solved, but I guess there >> is a >> reason in the channel to do that. > > I noticed that too, but this doesn't solve the real problem: the 200 > thread test is still too slow on my machine. The degradation seems to > start after 60-80 threads on my pretty weak SMP machine. > > Just to be sure, I've replaced RemotingThreadPool with an own, simple > version based on the standard BCL ThreadPool => same issue, although > I've raised the env var MONO_THREADS_PER_CPU to an insane value. > > Robert > >> >> >> pablo >> >> >> ----- Original Message - >> From: "Robert Jordan" <[EMAIL PROTECTED]> >> To: >> Sent: Saturday, December 15, 2007 4:12 PM >> Subject: Re: [Mono-dev] Remoting and thread pool limits >> >> >>> Hi, >>> >>> pablosantosluac wrote: >>>> Hi, >>>> >>>> I've found the following difference working with .NET and Mono >>>> remoting. >>>> In >>>> .NET when the remoting ThreadPool reaches the pool's maximum (25 >>>> threads >>>> per >>>> process), it is able to continue creating new threads. In fact, you can >>>> end >>>> up having a remoting server with hundreds of threads. >>>> >>>> In mono the behaviour is different. Once the limit is reached it starts >>>> refusing connections. >>> This is unrelated to mono's remoting thread pool. You have probably >>> ran your tests on Windows, where mono indeed fails with a GC failure >>> when too many threads are created because the GC has a hard coded >>> max thread count limit. >>> >>> On Linux (x86_64, Mono 1.2.6) I can finish the tests: >>> >>> Linux Mono client -> Linux Mono server (same machine) >>> >>> poseidon [~/foo] $ mono client/bin/Debug/client.exe >>> tcp://localhost:8084/remote >>> 1 - Time 1206 ms >>> 5 - Time 2045 ms >>> 10 - Time 3575 ms >>> 20 - Time 8174 ms >>> 40 - Time 12055 ms >>> 50 - Time 8185 ms >>> 200 - Time 46150 ms >>> >>> >>> MS.NET client -> Linux Mono server (different machines) >>> >>> troll:/cygdrive/u/foo/client/bin/Debug $ ./client.exe >>> tcp://poseidon:8084/remote >>> 1 - Time 1297 ms >>> 5 - Time 2000 ms >>> 10 - Time 3515 ms >>> 20 - Time 6016 ms >>> 40 - Time 11031 ms >>> 50 - Time 6016 ms >>> 200 - Time 94375 ms >>> >>> >>> The numbers don't look very well, though. I promise to look at >>> this when you file a bug report so that it doesn't get >>> overlooked. >>> >>> 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] SSL Channel implementation and SslServerStream
Hi again, >> Well, the line which is actually consuming 50% of the time is >> new MonoX509.X509Certificate(serverCertificate.GetRawCertData()); >> inside the ServerContext constructor. > > Are you running this under Mono or MS runtime ? MS. Running with a profiler. Mono results are currently slower, but it could be related to something else. I'm having problems when creating more than 80 threads/sockets. Don't know why yet. >> Of course it is related to the RSA calculation inside the MonoX509 >> certificate. > > Please provide additional details as there is no RSA computation > required in the mentioned ctor. > >> I guess it could be catched > > you mean "cached" ? Yes, sorry, cached! >> when attending different clients >> with the same server certificate, which would improve overall performance >> (in my previous email I said it was only local to one client, but I was >> wrong). > > As I said this CANNOT be cached between a server and multiple clients (a > little long to explain but it's how SSL is designed). Ok, whatever, there's a property called RSA inside the Mono X509 certificate. This property gets invoked once per SSL connection, actually calculating the same for each connection, because it is just "completing" (AFAIK) the server's certificate, if I'm not wrong, of course. I mean, the certificate you pass to the SSLServerStream gets converted again and again, and consuming time. If this can be cached, then the performance can be really boosted. I think this is *just* the server's certificate, nothing to do with the client (I guess). And yes, maybe it is not RSA calculation, but this is the name of the property where the time is being spent... at least under MS runtime. pablo >> >> >> Regards, >> >> >> >> pablo >> >> >> >> - Original Message - >> From: "Sebastien Pouliot" <[EMAIL PROTECTED]> >> To: "pablosantosluac" <[EMAIL PROTECTED]> >> Cc: >> Sent: Monday, December 17, 2007 7:50 PM >> Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >> > Hello Pablo, >> > >> > On Mon, 2007-12-17 at 17:21 +0100, pablosantosluac wrote: >> >> Hi again, >> >> >> >> Well, looking into the ServerContext constructor: the code converts >> >> between >> >> the System.Security cert to a Mono cert. Ok, this calculation could be >> >> skipped if a server is launching threads with the same certificate. >> >> The >> >> performance hit "caching" this one is about a 50% (launching 350 >> >> client >> >> threads simultaneously). >> > >> > Sorry but this is confusing. Let me clear this up a bit so the answer >> > will be meaningful when goggled in the future ;-) >> > >> > Converting the certificate between the minimal MS X509Certificate and >> > the Mono.Security X509Certificate is a very simple process. This could >> > be cached but this, alone, won't influence much performance. >> > >> > The key exchange does an expensive RSA operation, but it cannot be >> > cached in ServerContext. >> > >> > Now what *could* help is implementing a session cache in the >> > server[1][2]. However this helps only caching a session between the >> > server and a single client - you cannot share a session between >> > multiple >> > clients. >> > >> > That being said the server code won't scale to support, efficiently, >> > 350 >> > sessions. If you need high performance SSL code don't look at a managed >> > implementation (and IMO consider hardware acceleration). >> > >> > [1] the SslClientStream already support session caching >> > [2] contributions welcome >> > >> >> >> >> I'll try to locate the next bottleneck >> > >> > All cryptographic operations, like key exchange, encryption, integrity, >> > will show as a "bottleneck" - but they are exactly what you (should) >> > seek by choosing SSL. >> > >> >> >> >> >> >> pablo >> >> >> >> >> >> - Original Message - >> >> From: "pablosantosluac" <[EMAIL PROTECTED]> >> >> To: >> >> Sent: Monday, December 17, 2007 4:23 PM >> >> Subject: [Mono-dev] SSL Channel implementation and SslServerStream >> >> >> >>
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Hi again,
Well, the line which is actually consuming 50% of the time is
new MonoX509.X509Certificate(serverCertificate.GetRawCertData());
inside the ServerContext constructor.
Of course it is related to the RSA calculation inside the MonoX509
certificate. I guess it could be catched when attending different clients
with the same server certificate, which would improve overall performance
(in my previous email I said it was only local to one client, but I was
wrong).
Regards,
pablo
- Original Message -
From: "Sebastien Pouliot" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, December 17, 2007 7:50 PM
Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> Hello Pablo,
>
> On Mon, 2007-12-17 at 17:21 +0100, pablosantosluac wrote:
>> Hi again,
>>
>> Well, looking into the ServerContext constructor: the code converts
>> between
>> the System.Security cert to a Mono cert. Ok, this calculation could be
>> skipped if a server is launching threads with the same certificate. The
>> performance hit "caching" this one is about a 50% (launching 350 client
>> threads simultaneously).
>
> Sorry but this is confusing. Let me clear this up a bit so the answer
> will be meaningful when goggled in the future ;-)
>
> Converting the certificate between the minimal MS X509Certificate and
> the Mono.Security X509Certificate is a very simple process. This could
> be cached but this, alone, won't influence much performance.
>
> The key exchange does an expensive RSA operation, but it cannot be
> cached in ServerContext.
>
> Now what *could* help is implementing a session cache in the
> server[1][2]. However this helps only caching a session between the
> server and a single client - you cannot share a session between multiple
> clients.
>
> That being said the server code won't scale to support, efficiently, 350
> sessions. If you need high performance SSL code don't look at a managed
> implementation (and IMO consider hardware acceleration).
>
> [1] the SslClientStream already support session caching
> [2] contributions welcome
>
>>
>> I'll try to locate the next bottleneck
>
> All cryptographic operations, like key exchange, encryption, integrity,
> will show as a "bottleneck" - but they are exactly what you (should)
> seek by choosing SSL.
>
>>
>>
>> pablo
>>
>>
>> - Original Message -
>> From: "pablosantosluac" <[EMAIL PROTECTED]>
>> To:
>> Sent: Monday, December 17, 2007 4:23 PM
>> Subject: [Mono-dev] SSL Channel implementation and SslServerStream
>>
>>
>> > Hi all,
>> >
>> > I'm implemented a secured TCP remoting channel. I took the current TCP
>> > Channel as starting point, and used Ssl{Client|Server}Stream to
>> > implement
>> > communication, as Robert Jordan suggested.
>> >
>> > Well, it seems it works correctly but I've found the following issue:
>> > creating each new connection takes time (obviously), but it is
>> > basically
>> > due
>> > to a call to "new ServerContext" inside the SslServerStream
>> > constructor.
>> >
>> > The problem, in fact, seems related with the property
>> > X509Certificate::RSA.
>> > Each time a new connection is opened, a new certificate is given, and
>> > the
>> > private key used.
>> >
>> > Is there a way to actually make all this initialization just once? It
>> > would
>> > greatly improve performance both in Mono and .NET.
>> >
>> > Any idea?
>> >
>> > 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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SSL Channel implementation and SslServerStream
Hi Sebastien, > Converting the certificate between the minimal MS X509Certificate and > the Mono.Security X509Certificate is a very simple process. This could > be cached but this, alone, won't influence much performance. Well, actually caching the line I mentioned (I've already tried with the same sample I sent to the list last week, creating about 300 connections), increases performance about 50%, but yes, when connections are started from the same client. > The key exchange does an expensive RSA operation, but it cannot be > cached in ServerContext. Yes, I've seen that too. I guess this is the other line I pointed. > Now what *could* help is implementing a session cache in the > server[1][2]. However this helps only caching a session between the > server and a single client - you cannot share a session between multiple > clients. Right, this is more or less what I said, isn't it? I mean, caching somehow the initial RSA calculation done in the X509Certificate. > That being said the server code won't scale to support, efficiently, 350 > sessions. If you need high performance SSL code don't look at a managed > implementation (and IMO consider hardware acceleration). Well, that's an interesting answer. Do you mean it is better to implement a high-perf server on C than Mono/C#? Or do you just talk about implementing a whole SSL channel in C? If so, how? Could you point any samples? I'm not familiar with SSL, which hw acceleration would do it better? 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] SSL Channel implementation and SslServerStream
Hi,
Ok, the next "bottleneck" seems to be at
TlsClientKeyExchange::ProcessAsSsl3, more exactly at byte[] preMasterSecret
= deformatter.DecryptKeyExchange(clientSecret);
But I guess it wont be possible to get rid of this one, will it?
Thanks,
pablo
- Original Message -
From: "pablosantosluac" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>;
Sent: Monday, December 17, 2007 5:21 PM
Subject: Re: [Mono-dev] SSL Channel implementation and SslServerStream
> Hi again,
>
> Well, looking into the ServerContext constructor: the code converts
> between the System.Security cert to a Mono cert. Ok, this calculation
> could be skipped if a server is launching threads with the same
> certificate. The performance hit "caching" this one is about a 50%
> (launching 350 client threads simultaneously).
>
>
> I'll try to locate the next bottleneck
>
>
> pablo
>
>
> - Original Message -
> From: "pablosantosluac" <[EMAIL PROTECTED]>
> To:
> Sent: Monday, December 17, 2007 4:23 PM
> Subject: [Mono-dev] SSL Channel implementation and SslServerStream
>
>
>> Hi all,
>>
>> I'm implemented a secured TCP remoting channel. I took the current TCP
>> Channel as starting point, and used Ssl{Client|Server}Stream to implement
>> communication, as Robert Jordan suggested.
>>
>> Well, it seems it works correctly but I've found the following issue:
>> creating each new connection takes time (obviously), but it is basically
>> due
>> to a call to "new ServerContext" inside the SslServerStream constructor.
>>
>> The problem, in fact, seems related with the property
>> X509Certificate::RSA.
>> Each time a new connection is opened, a new certificate is given, and the
>> private key used.
>>
>> Is there a way to actually make all this initialization just once? It
>> would
>> greatly improve performance both in Mono and .NET.
>>
>> Any idea?
>>
>> 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] SSL Channel implementation and SslServerStream
Hi again,
Well, looking into the ServerContext constructor: the code converts between
the System.Security cert to a Mono cert. Ok, this calculation could be
skipped if a server is launching threads with the same certificate. The
performance hit "caching" this one is about a 50% (launching 350 client
threads simultaneously).
I'll try to locate the next bottleneck
pablo
- Original Message -
From: "pablosantosluac" <[EMAIL PROTECTED]>
To:
Sent: Monday, December 17, 2007 4:23 PM
Subject: [Mono-dev] SSL Channel implementation and SslServerStream
> Hi all,
>
> I'm implemented a secured TCP remoting channel. I took the current TCP
> Channel as starting point, and used Ssl{Client|Server}Stream to implement
> communication, as Robert Jordan suggested.
>
> Well, it seems it works correctly but I've found the following issue:
> creating each new connection takes time (obviously), but it is basically
> due
> to a call to "new ServerContext" inside the SslServerStream constructor.
>
> The problem, in fact, seems related with the property
> X509Certificate::RSA.
> Each time a new connection is opened, a new certificate is given, and the
> private key used.
>
> Is there a way to actually make all this initialization just once? It
> would
> greatly improve performance both in Mono and .NET.
>
> Any idea?
>
> 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] SSL Channel implementation and SslServerStream
Hi all,
I'm implemented a secured TCP remoting channel. I took the current TCP
Channel as starting point, and used Ssl{Client|Server}Stream to implement
communication, as Robert Jordan suggested.
Well, it seems it works correctly but I've found the following issue:
creating each new connection takes time (obviously), but it is basically due
to a call to "new ServerContext" inside the SslServerStream constructor.
The problem, in fact, seems related with the property X509Certificate::RSA.
Each time a new connection is opened, a new certificate is given, and the
private key used.
Is there a way to actually make all this initialization just once? It would
greatly improve performance both in Mono and .NET.
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] Remoting and thread pool limits
Hi Robert, Here are my numbers on a Linux (Xeon) box: [EMAIL PROTECTED] client]$ /opt/mono/bin/mono client.exe tcp://localhost:10020/remote 1 - Time 1296 ms 5 - Time 1023 ms 10 - Time 1025 ms 20 - Time 1031 ms 40 - Time 1041 ms 50 - Time 1041 ms 200 - Time 10126 ms As you mentioned I can't currently understand the "hit" when creating 200 threads because if you try to create them in a standalone application (a loop launching 1000 threads), it works perfectly... but doing remoting (I don't know where the problem can be), the impact is quite high... ¿Something socket related? (I doubt it!) I'll take another look into the channel's code. Regards, pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Saturday, December 15, 2007 9:25 PM Subject: Re: [Mono-dev] Remoting and thread pool limits > pablosantosluac wrote: >> Well, it is not a *bug* but a feature. I wonder if it should be changed. >> If >> you look into RemotingThreadPool.cs there is a line like: >> >> >> threadDone.WaitOne(PoolGrowDelay, false); >> >> >> This one is actually the one making the process too slow. I'm afraid it >> must >> be something similar on the .NET code too! >> >> Of course removing this line the problem gets solved, but I guess there >> is a >> reason in the channel to do that. > > I noticed that too, but this doesn't solve the real problem: the 200 > thread test is still too slow on my machine. The degradation seems to > start after 60-80 threads on my pretty weak SMP machine. > > Just to be sure, I've replaced RemotingThreadPool with an own, simple > version based on the standard BCL ThreadPool => same issue, although > I've raised the env var MONO_THREADS_PER_CPU to an insane value. > > Robert > >> >> >> pablo >> >> >> - Original Message - >> From: "Robert Jordan" <[EMAIL PROTECTED]> >> To: >> Sent: Saturday, December 15, 2007 4:12 PM >> Subject: Re: [Mono-dev] Remoting and thread pool limits >> >> >>> Hi, >>> >>> pablosantosluac wrote: >>>> Hi, >>>> >>>> I've found the following difference working with .NET and Mono >>>> remoting. >>>> In >>>> .NET when the remoting ThreadPool reaches the pool's maximum (25 >>>> threads >>>> per >>>> process), it is able to continue creating new threads. In fact, you can >>>> end >>>> up having a remoting server with hundreds of threads. >>>> >>>> In mono the behaviour is different. Once the limit is reached it starts >>>> refusing connections. >>> This is unrelated to mono's remoting thread pool. You have probably >>> ran your tests on Windows, where mono indeed fails with a GC failure >>> when too many threads are created because the GC has a hard coded >>> max thread count limit. >>> >>> On Linux (x86_64, Mono 1.2.6) I can finish the tests: >>> >>> Linux Mono client -> Linux Mono server (same machine) >>> >>> poseidon [~/foo] $ mono client/bin/Debug/client.exe >>> tcp://localhost:8084/remote >>> 1 - Time 1206 ms >>> 5 - Time 2045 ms >>> 10 - Time 3575 ms >>> 20 - Time 8174 ms >>> 40 - Time 12055 ms >>> 50 - Time 8185 ms >>> 200 - Time 46150 ms >>> >>> >>> MS.NET client -> Linux Mono server (different machines) >>> >>> troll:/cygdrive/u/foo/client/bin/Debug $ ./client.exe >>> tcp://poseidon:8084/remote >>> 1 - Time 1297 ms >>> 5 - Time 2000 ms >>> 10 - Time 3515 ms >>> 20 - Time 6016 ms >>> 40 - Time 11031 ms >>> 50 - Time 6016 ms >>> 200 - Time 94375 ms >>> >>> >>> The numbers don't look very well, though. I promise to look at >>> this when you file a bug report so that it doesn't get >>> overlooked. >>> >>> 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] Remoting and thread pool limits
Well, it is not a *bug* but a feature. I wonder if it should be changed. If you look into RemotingThreadPool.cs there is a line like: threadDone.WaitOne(PoolGrowDelay, false); This one is actually the one making the process too slow. I'm afraid it must be something similar on the .NET code too! Of course removing this line the problem gets solved, but I guess there is a reason in the channel to do that. pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Saturday, December 15, 2007 4:12 PM Subject: Re: [Mono-dev] Remoting and thread pool limits > Hi, > > pablosantosluac wrote: >> Hi, >> >> I've found the following difference working with .NET and Mono remoting. >> In >> .NET when the remoting ThreadPool reaches the pool's maximum (25 threads >> per >> process), it is able to continue creating new threads. In fact, you can >> end >> up having a remoting server with hundreds of threads. >> >> In mono the behaviour is different. Once the limit is reached it starts >> refusing connections. > > This is unrelated to mono's remoting thread pool. You have probably > ran your tests on Windows, where mono indeed fails with a GC failure > when too many threads are created because the GC has a hard coded > max thread count limit. > > On Linux (x86_64, Mono 1.2.6) I can finish the tests: > > Linux Mono client -> Linux Mono server (same machine) > > poseidon [~/foo] $ mono client/bin/Debug/client.exe > tcp://localhost:8084/remote > 1 - Time 1206 ms > 5 - Time 2045 ms > 10 - Time 3575 ms > 20 - Time 8174 ms > 40 - Time 12055 ms > 50 - Time 8185 ms > 200 - Time 46150 ms > > > MS.NET client -> Linux Mono server (different machines) > > troll:/cygdrive/u/foo/client/bin/Debug $ ./client.exe > tcp://poseidon:8084/remote > 1 - Time 1297 ms > 5 - Time 2000 ms > 10 - Time 3515 ms > 20 - Time 6016 ms > 40 - Time 11031 ms > 50 - Time 6016 ms > 200 - Time 94375 ms > > > The numbers don't look very well, though. I promise to look at > this when you file a bug report so that it doesn't get > overlooked. > > 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] Remoting and thread pool limits
Hi,
I've found the following difference working with .NET and Mono remoting. In
.NET when the remoting ThreadPool reaches the pool's maximum (25 threads per
process), it is able to continue creating new threads. In fact, you can end
up having a remoting server with hundreds of threads.
In mono the behaviour is different. Once the limit is reached it starts
refusing connections.
The other drawback of the standard (1.1) remoting (.NET) is that once the
thread pool limit is reached, each new thread takes a lng time. In fact,
replacing the standard TCP channel by, for instance, the GenuineChannels
one, performance gets increased under heavy load.
The attached code creates a remoting server which implements one method. The
method is really simple:
public string GetVal()
{
Console.WriteLine("GetVal() - ThId:{0}",
Thread.CurrentThread.GetHashCode());
Thread.Sleep(1000);
return "Hi There";
}
Well, if you have a client launching 200 threads at the same time and
calling the server, it should take about 1 second to complete. Here are my
results using .NET (it doesn't finish with mono)
1 - Time 1102 ms
5 - Time 1011 ms
10 - Time 1002 ms
20 - Time 1011 ms
40 - Time 2003 ms
50 - Time 2013 ms
200 - Time 6019 ms
Using GenuineChannels (the difference here is how they implement the
threadpool), all get about 1 sec to finish.
Please find the sample code at
http://www.codicesoftware.com/testing/remotingtransmission.rar
Regards,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] The best way to secure remoting?
Ok Robert, thanks! Well, I guess I'd have to modify TcpServerChannel.cs and TcpClientChannel.cs (I mean, create new ones) to use secured sockets or introduce some sort of encryption there... is that ok? Well, in fact I guess the code at TcpServerChannel is the one actually using sockets, isn't it? About SSL, I've found the following C# SSL library: http://www.mentalis.org/soft/projects/seclib/. Is there a better option? Thanks! pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Tuesday, December 04, 2007 4:01 PM Subject: Re: [Mono-dev] The best way to secure remoting? > pablosantosluac wrote: >> Thanks for your answer Robert. >> >> The problem is that I can't host my objects on XSP (plasticd is actually >> a >> service or a daemon, but not a hosted XSP) neither use SOAP >> (performance!)... > > I see. You could make a copy of TcpChannel and change it to > encrypt the data. Since TcpChannel already has a connection > pool, it should be already well prepared for SSL. > Two days of work, I'd guess. > > Unfortunately, the remoting infrastructure is not flexible enough > to allow other solutions. One could be deluded to implement > encryption as a channel sink, but this is really suboptimal > because you don't have sessions at this layer. > W/out sessions, SSL (and any other symmetric encryption that needs > an asymmetric key exchange phase) will be extremely slow. > > Robert > >> >> >> pablo >> >> >> - Original Message - >> From: "Robert Jordan" <[EMAIL PROTECTED]> >> To: >> Sent: Monday, December 03, 2007 10:35 PM >> Subject: Re: [Mono-dev] The best way to secure remoting? >> >> >>> pablosantosluac wrote: >>>> Hi there, >>>> >>>> AFAIK with .net 2.0 SSL is an standard channel, isn't it? >>> No, in MS.NET 2.0 it is based on NegotiateStream that uses >>> whichever authentication and encryption Windows SSPI dictates. >>> See MSDN. >>> >>>> But my question is: if I want to keep the mono-1.0 profile... what's >>>> the >>>> best way to secure remoting communication? >>> Host your remoting objects in XSP and use HttpChannel + SOAP formatter >>> over SSL. >>> >>> 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] The best way to secure remoting?
Thanks for your answer Robert. The problem is that I can't host my objects on XSP (plasticd is actually a service or a daemon, but not a hosted XSP) neither use SOAP (performance!)... pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Monday, December 03, 2007 10:35 PM Subject: Re: [Mono-dev] The best way to secure remoting? > pablosantosluac wrote: >> Hi there, >> >> AFAIK with .net 2.0 SSL is an standard channel, isn't it? > > No, in MS.NET 2.0 it is based on NegotiateStream that uses > whichever authentication and encryption Windows SSPI dictates. > See MSDN. > >> But my question is: if I want to keep the mono-1.0 profile... what's the >> best way to secure remoting communication? > > Host your remoting objects in XSP and use HttpChannel + SOAP formatter > over SSL. > > 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] The best way to secure remoting?
Hi there, AFAIK with .net 2.0 SSL is an standard channel, isn't it? But my question is: if I want to keep the mono-1.0 profile... what's the best way to secure remoting communication? 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] [U-SPAM] Re: String.GetHashCode()
I don't see the moment to try it with the plastic server... :-P - Original Message - From: "Miguel de Icaza" <[EMAIL PROTECTED]> To: "Andreas Nahr" <[EMAIL PROTECTED]> Cc: "'Robert Jordan'" <[EMAIL PROTECTED]>; Sent: Monday, December 03, 2007 3:45 PM Subject: Re: [Mono-dev] [U-SPAM] Re: String.GetHashCode() > Hello, > >First of all, I love the idea. > >> Don't forget that 4 bytes per Hashcode isn't enough. You also need a >> boolean to store if the hash is already computed (as e.g. 0 is a valid >> hash, too). > >You could assume that any string over N would contain the > precomputed hashcode immediately after the string in a sizeof(IntPtr) > aligned 32-bit location. > >What the N should still be measured. > > 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] mono-service and log4net
Well, Jörg pointed out the following: I'm not implementing the ServiceBase.Run method but just the OnStart which in turn launches a new thread. Maybe this is not the correct way to do it (although it has been running this way for almost 2 years now). It does call Main (I've just checked) but, could happen that it makes some other change afterwards (I don't know, a different app domain or something like that...) ? - Original Message - From: "Mirco Bauer" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: ; "Robert Jordan" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2007 6:08 PM Subject: Re: [Mono-dev] mono-service and log4net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] mono-service and log4net
Hi again, Well, if you set up logging in the service OnStart method... it works! :-) If you just initialize it on the application's Main method it works on Windows but not on Linux. Not sure whether it is a bug... pablo - Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: ; "Robert Jordan" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2007 2:23 PM Subject: Re: [Mono-dev] mono-service and log4net > I'm afraid is not .NET 2. I'll make some more tests and file a bug > otherwise. > > pablo > - Original Message - > From: "Robert Jordan" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, November 27, 2007 2:16 PM > Subject: Re: [Mono-dev] mono-service and log4net > > >> pablosantosluac wrote: >>> Hi there, >>> >>> I'm trying mono-service (1.2.6 preview 2) to launch our server and I've >>> located the following problem: log4net doesn't work when you run the >>> process >>> as a service, although it does work when you launch it as a "console" >>> application. >>> >>> As soon as I launch it as "service" I can't get any log. The same works >>> on >>> Windows/.NET. >> >> If you application is compiled for .NET 2.0 then you must use >> mono-service2. Please file a bug with a test case otherwise. >> >> 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] mono-service and log4net
I'm afraid is not .NET 2. I'll make some more tests and file a bug otherwise. pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 27, 2007 2:16 PM Subject: Re: [Mono-dev] mono-service and log4net > pablosantosluac wrote: >> Hi there, >> >> I'm trying mono-service (1.2.6 preview 2) to launch our server and I've >> located the following problem: log4net doesn't work when you run the >> process >> as a service, although it does work when you launch it as a "console" >> application. >> >> As soon as I launch it as "service" I can't get any log. The same works >> on >> Windows/.NET. > > If you application is compiled for .NET 2.0 then you must use > mono-service2. Please file a bug with a test case otherwise. > > 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] mono-service and log4net
Hi there, I'm trying mono-service (1.2.6 preview 2) to launch our server and I've located the following problem: log4net doesn't work when you run the process as a service, although it does work when you launch it as a "console" application. As soon as I launch it as "service" I can't get any log. The same works on Windows/.NET. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Set process name on solaris and mac
Hi there! I've found the following about changing the process name on Linux: http://abock.org/2006/02/09/changing-process-name-in-mono/ Any pointer on how to do it on Solaris and MacOS? 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] ToString() performace in Mono
well, we tried but it doesn't get a big speed up... just about 2 to 5%
- Original Message -
From: Alan McGovern
To: Petit Eric
Cc: pablosantosluac ; mono-devel-list@lists.ximian.com
Sent: Thursday, November 22, 2007 3:23 PM
Subject: Re: [Mono-dev] ToString() performace in Mono
StringBuilder is only faster if you're concatenating a lot of variables. In
this case, there's no benefit to using stringbuilder. If he was concatenating
all the numbers from i=0->1000, then yes, a stringbuilder would be better.
It might be worth cracking out a profiler and seeing where the time is spent.
As NumberStore is a struct, you would get a performance boost if it was
passed by ref as opposed to be value. I'd guesstimate that it'd be at least a
double digit increase (> 10%). If someone has the time to modify their mono
checkout to change the Int32.ToString() codepath to pass the NumberStore by ref
all the way through, let me know what the performance diff is.
It should only take about 10 mins of hacking to do the change. If the boost
is significant enough, maybe a patch would be accepted into mono to do this.
Alan.
On Nov 22, 2007 11:26 AM, Petit Eric <[EMAIL PROTECTED]> wrote:
2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
> Hi,
>
> Ok, but I'm not doing string "concat" but just converting to string, and
> using StringBuilder in this scenario, it isn't faster, as you have just
> pointed to...
yes complety right, but the first idea was about the fact for string
performance, stringbuilder is fastest, but aparently not at the
instance time, only to append a long text.
oki
now we are fixed lol
>
> My point is that ToString is about 3 times slower in Mono than its .NET
> counterpart. We'll try to get rid of it as much as we can, but some
> optimization would be really great.
>
> Thanks,
>
> pablo
>
>
> - Original Message -
> From: "Petit Eric" < [EMAIL PROTECTED]>
> To: "pablosantosluac" <[EMAIL PROTECTED]>
> Cc:
> Sent: Thursday, November 22, 2007 11:56 AM
> Subject: Re: [Mono-dev] ToString() performace in Mono
>
>
> > Windows and String
> > val is 599 and time 4391
> >
> > Windows and StringBuilder
> > val is 599 and time 5688
> >
> > Code For StringBuilder :
> >
> > using System;
> > using System.Collections.Generic;
> > using System.Text;
> >
> > namespace compareCompare
> > {
> >class Program
> >{
> >static void Main(string[] args)
> >{
> >int ini = Environment.TickCount;
> >
> >System.Text.StringBuilder k = new
System.Text.StringBuilder();
> >
> >for (int i = 0; i < 600; ++i)
> >{
> >k = new System.Text.StringBuilder(i.ToString());
> >}
> >
> > Console.WriteLine("val is {0} and time {1}", k,
> > Environment.TickCount - ini);
> >
> >while (true)
> >{
> >if (Console.ReadKey() != null) break;
> >}
> >
> >}
> >}
> > }
> >
> >
> >
> >
> > 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
> >> Anyway, how would you use it in the sample I attached to improve
> >> performance? I need to convert a different integer each pass...
> >> - Original Message -
> >> From: "Petit Eric" <[EMAIL PROTECTED] >
> >> To: "pablosantosluac" <[EMAIL PROTECTED]>
> >> Cc:
> >> Sent: Thursday, November 22, 2007 10:24 AM
> >> Subject: Re: [Mono-dev] ToString() performace in Mono
> >>
> >>
> >> > Do you try to replace String by a System.Text.StringBuilder ?
> >> >
> >> > 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
> >> >> Hi,
> >> >>
> >> >>
> >> >> I've detected a performance hit on "plastic server" running on
mono. I
> >> >> was
> >> >> actually shocked because when I checked something similar working
with
> >> >> integers, Mono was actually faster than .NET. But it seems
Re: [Mono-dev] ToString() performace in Mono
Hi,
Ok, but I'm not doing string "concat" but just converting to string, and
using StringBuilder in this scenario, it isn't faster, as you have just
pointed to...
My point is that ToString is about 3 times slower in Mono than its .NET
counterpart. We'll try to get rid of it as much as we can, but some
optimization would be really great.
Thanks,
pablo
- Original Message -
From: "Petit Eric" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, November 22, 2007 11:56 AM
Subject: Re: [Mono-dev] ToString() performace in Mono
> Windows and String
> val is 599 and time 4391
>
> Windows and StringBuilder
> val is 599 and time 5688
>
> Code For StringBuilder :
>
> using System;
> using System.Collections.Generic;
> using System.Text;
>
> namespace compareCompare
> {
>class Program
>{
>static void Main(string[] args)
>{
>int ini = Environment.TickCount;
>
>System.Text.StringBuilder k = new System.Text.StringBuilder();
>
>for (int i = 0; i < 600; ++i)
>{
>k = new System.Text.StringBuilder(i.ToString());
>}
>
>Console.WriteLine("val is {0} and time {1}", k,
> Environment.TickCount - ini);
>
>while (true)
>{
>if (Console.ReadKey() != null) break;
>}
>
>}
>}
> }
>
>
>
>
> 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
>> Anyway, how would you use it in the sample I attached to improve
>> performance? I need to convert a different integer each pass...
>> - Original Message -
>> From: "Petit Eric" <[EMAIL PROTECTED]>
>> To: "pablosantosluac" <[EMAIL PROTECTED]>
>> Cc:
>> Sent: Thursday, November 22, 2007 10:24 AM
>> Subject: Re: [Mono-dev] ToString() performace in Mono
>>
>>
>> > Do you try to replace String by a System.Text.StringBuilder ?
>> >
>> > 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
>> >> Hi,
>> >>
>> >>
>> >> I've detected a performance hit on "plastic server" running on mono. I
>> >> was
>> >> actually shocked because when I checked something similar working with
>> >> integers, Mono was actually faster than .NET. But it seems it is not
>> >> the
>> >> case with strings.
>> >>
>> >> Please consider the following code sample:
>> >>
>> >>
>> >> using System;
>> >>
>> >> namespace compareCompare
>> >> {
>> >> class Class1
>> >> {
>> >> static void Main(string[] args)
>> >> {
>> >> int ini = Environment.TickCount;
>> >>
>> >> string k = string.Empty;
>> >>
>> >> for( int i = 0; i < 600; ++i )
>> >> {
>> >> k = i.ToString();
>> >> }
>> >>
>> >> Console.WriteLine("val is {0} and time {1}", k,
>> >> Environment.TickCount - ini);
>> >> }
>> >> }
>> >> }
>> >>
>> >>
>> >> And the following results:
>> >>
>> >> >compareCompare.exe
>> >> val is 599 and time 3525
>> >>
>> >> >"c:\Archivos de programa\Mono-1.2.5.2\bin\mono.exe"
>> >> >compareCompare.exe
>> >> val is 599 and time 11577
>> >>
>> >>
>> >> 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] ToString() performace in Mono
Anyway, how would you use it in the sample I attached to improve
performance? I need to convert a different integer each pass...
- Original Message -
From: "Petit Eric" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, November 22, 2007 10:24 AM
Subject: Re: [Mono-dev] ToString() performace in Mono
> Do you try to replace String by a System.Text.StringBuilder ?
>
> 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
>> Hi,
>>
>>
>> I've detected a performance hit on "plastic server" running on mono. I
>> was
>> actually shocked because when I checked something similar working with
>> integers, Mono was actually faster than .NET. But it seems it is not the
>> case with strings.
>>
>> Please consider the following code sample:
>>
>>
>> using System;
>>
>> namespace compareCompare
>> {
>> class Class1
>> {
>> static void Main(string[] args)
>> {
>> int ini = Environment.TickCount;
>>
>> string k = string.Empty;
>>
>> for( int i = 0; i < 600; ++i )
>> {
>> k = i.ToString();
>> }
>>
>> Console.WriteLine("val is {0} and time {1}", k,
>> Environment.TickCount - ini);
>> }
>> }
>> }
>>
>>
>> And the following results:
>>
>> >compareCompare.exe
>> val is 599 and time 3525
>>
>> >"c:\Archivos de programa\Mono-1.2.5.2\bin\mono.exe" compareCompare.exe
>> val is 599 and time 11577
>>
>>
>> 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] ToString() performace in Mono
I can try for this sample, but I'm afraid the ToString is being implicity
used in several locations
- Original Message -
From: "Petit Eric" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, November 22, 2007 10:24 AM
Subject: Re: [Mono-dev] ToString() performace in Mono
> Do you try to replace String by a System.Text.StringBuilder ?
>
> 2007/11/22, pablosantosluac <[EMAIL PROTECTED]>:
>> Hi,
>>
>>
>> I've detected a performance hit on "plastic server" running on mono. I
>> was
>> actually shocked because when I checked something similar working with
>> integers, Mono was actually faster than .NET. But it seems it is not the
>> case with strings.
>>
>> Please consider the following code sample:
>>
>>
>> using System;
>>
>> namespace compareCompare
>> {
>> class Class1
>> {
>> static void Main(string[] args)
>> {
>> int ini = Environment.TickCount;
>>
>> string k = string.Empty;
>>
>> for( int i = 0; i < 600; ++i )
>> {
>> k = i.ToString();
>> }
>>
>> Console.WriteLine("val is {0} and time {1}", k,
>> Environment.TickCount - ini);
>> }
>> }
>> }
>>
>>
>> And the following results:
>>
>> >compareCompare.exe
>> val is 599 and time 3525
>>
>> >"c:\Archivos de programa\Mono-1.2.5.2\bin\mono.exe" compareCompare.exe
>> val is 599 and time 11577
>>
>>
>> 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] ToString() performace in Mono
Hi,
I've detected a performance hit on "plastic server" running on mono. I was
actually shocked because when I checked something similar working with
integers, Mono was actually faster than .NET. But it seems it is not the
case with strings.
Please consider the following code sample:
using System;
namespace compareCompare
{
class Class1
{
static void Main(string[] args)
{
int ini = Environment.TickCount;
string k = string.Empty;
for( int i = 0; i < 600; ++i )
{
k = i.ToString();
}
Console.WriteLine("val is {0} and time {1}", k,
Environment.TickCount - ini);
}
}
}
And the following results:
>compareCompare.exe
val is 599 and time 3525
>"c:\Archivos de programa\Mono-1.2.5.2\bin\mono.exe" compareCompare.exe
val is 599 and time 11577
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] Remoting question
Yes, it is possible, we do it all the time - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 1:26 AM Subject: [Mono-dev] Remoting question > Hi to all: > > Is posbile to use Mono.Remotng with classes that have methods with class > return type or object as return? > > thanks > > Mauricio > > ___ > 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] MonoSummit: Planning the Sessions
AFAIK is heavily based in COM - Original Message - From: "Miguel de Icaza" <[EMAIL PROTECTED]> To: "Jonathan Pobst" <[EMAIL PROTECTED]> Cc: "Brock Reeve" <[EMAIL PROTECTED]>; Sent: Thursday, November 08, 2007 6:06 PM Subject: Re: [Mono-dev] MonoSummit: Planning the Sessions > >> I don't know that anyone has reverse engineered the remote debugging >> protocol to enable it to run on another platform, and my gut feeling is >> it would be extremely difficult to achieve. > > Am not sure that we need to reverse engineer the protocol; Chances are > there is an API in Visual Studio to do this, as Mainsoft does this to > debug Java code on J2EE servers. > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Bugs Days.
Hi there! I'd like to know whether bug 82550 (fixed on SVN changeset 84714) will be integrated into mono 1.2.6. AFAIK it is still wrong in latest 1.2.5 It is a compiler problem so it would be nice to get it in the next one. pablo - Original Message - From: "Miguel de Icaza" <[EMAIL PROTECTED]> To: "mono-devel-list" Sent: Saturday, November 03, 2007 7:59 PM Subject: [Mono-dev] Mono Bugs Days. > On Monday and Tuesday (November 5th and 6th) we want to > spend some time triaging, prioritizing and applying easy fixes > to Mono from Bugzilla. > > We will be on irc.gnome.org on the channel #monobugday on > Monday and Tuesday going over various Mono components. > > Our entry point is: > > www.mono-project.com/Bugs > > There is a lot of low-hanging fruit that could be easily > fixed in Mono, bugs that are invalid, bugs that are missing > information, bugs that needs owners, bugs that need > confirmation and patches that have been waiting on the bug > tracking system to be applied. > > I have zero experience running a bug day and am not sure > quite how to run this on Monday, if you have some experience, > feel free to drop by, or send your comments. > > ___ > 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] MonoSummit: Planning the Sessions
> Also I am thinking about another one that could explain how to run the > unit tests successfully across many operating systems :-) Take a look at pnunit.codicesoftware.com, which will be (hopefuly) integrated in the upcoming NUnit. If anyone is interested... I'm available! - Original Message - From: ""Andrés G. Aragoneses [ knocte ]"" <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Monday, October 29, 2007 6:11 PM Subject: Re: [Mono-dev] MonoSummit: Planning the Sessions Mads Bondo Dydensborg escribió: > fredag 26 Oktober 2007 skrev Miguel de Icaza: >> Hey folks, >> >> Am looking for ideas for topics that developers would be interested >> in hearing about at the Mono Summit. > > I would be happy to hear about debugging applications with mono, the state > of > the debugger, etc. > > Also, in relation to this, debugging mono itself: when you _really_ think > what > you observe is not a bug in your program, how to go about checking mono > against the C# standard, MS implementation, whatever. I would love that BoF! Also I am thinking about another one that could explain how to run the unit tests successfully across many operating systems. I'm interested in contributing some patches but first I have to understand how to launch these tests in MS.NET using Cygwin, in order to see if my unit tests are correct or not. I don't have enough time to dive into the loop of test-error-test-error to find it out (maybe this could be a good section in the already existing planned activity by Marcos Cobeña.. I don't know). Regards, Andrés [ knocte ] -- ___ 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] C bindings VS C++ bindings (Gtk# vs. Kimono?)
Hi Arno, Do you know what will be the costs for commercial use?? Also, do you have plans to support MacOS and Solaris? If so, when? Thanks, pablo - Original Message - From: "Arno Rehn" <[EMAIL PROTECTED]> To: Sent: Saturday, September 22, 2007 6:48 PM Subject: Re: [Mono-dev] C bindings VS C++ bindings (Gtk# vs. Kimono?) > Hi, > > I'm one of the Qyoto devs and have just come across this thread. > First off, I'm glad that even companies consider Qyoto an option for the > GUI > by now and that quite some people have heard about it. > To be honest, we haven't tested Qyoto on Windows yet, but it should work > pretty flawlessly. On Linux and Mac OS X at least it works well. GUI's are > designed with the normal Qt Designer. Code can be generated with the > resulting .ui files and a program called 'uics'. > For the licensing: we can use a dual-license model for Qyoto/Kimono, like > it's > done with PyQt and Qt itself: GPL for open-source apps, QPL-like for > closed > source. > For theming: Qt uses the native API on Windows/Mac as far as possible, so > the > look and feel is native. > The API of Qt is also quite stable throughout a major version, but some > minor > things might change from time to time. > > To do some advertising: Qt does not only offer a GUI Toolkit, but also > some > other interesting features like SQL handling, SVG support, OpenGL support, > D-BUS support (one feature of D-BUS is a bit buggy on Qyoto, though), > Networking and more. > > -- > Arno Rehn > [EMAIL PROTECTED] > ___ > 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] Linq sample?
Hi, Well, I've just tried some simple tests yet, but I'd say performance is awsome... I mean, searching in an array of 120 Million objects, using about 1GB RAM looking for a simple query checking a couple of properties needed only 185ms to finish!!! Doing it iteratively (looping through the array) took 284ms against 3 in a 12Million array (linq is faster!). So, I didn't look at it in detail, but it looks pretty impressive!! pablo - Original Message - From: "Marek Safar" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: "Kamil Skalski" <[EMAIL PROTECTED]>; "Robert Jordan" <[EMAIL PROTECTED]>; Sent: Monday, September 24, 2007 7:33 PM Subject: Re: [Mono-dev] Linq sample? > Hi, >> Well, I guess I'm doing something wrong or using an old mono runtime, >> because the sample is very simple. Does it work for you? >> > Yes, it does. Please use SVN HEAD. >> Another question: is Linq performace good? >> > We are currently not in the position where we can focus on LINQ > performance. > > As far as I know nobody have tested Mono LINQ performance yet. > > Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
Oh... come on! I was so happy! :-(
Here is my code: it is just a dumb test. Note I commented out the
"console.writeline" line.
I'm not using SQL, just searching in an in-memory array...
One question too, I'm totally new to linq so, is there a way to build the
queries dynamically? I mean, maybe something like building them from a
string that you can build at runtime or so??
pablo
using System;
using System.Linq;
using System.Collections.Generic;
namespace test
{
class Revision
{
public long ObjId;
public long RevNo;
public long BranchId;
public long ItemId;
public bool Last;
public string comment;
public short Type;
public long Size;
public bool CheckedOut;
public long ParentId = -1;
public string Hash;
public long Changeset;
public Revision(long objid, long revno, long brid, long itemid, bool
last,
string comment, short type, long size, bool co, long parent,
string hash,
long cset)
{
this.ObjId = objid;
this.RevNo = revno;
this.BranchId = brid;
this.ItemId = itemid;
this.Last = last;
this.comment = comment;
this.Type = type;
this.Size = size;
this.CheckedOut = co;
this.ParentId = parent;
this.Hash = hash;
this.Changeset = cset;
}
}
class app
{
static void Main(string[] args)
{
Revision[] revs = new Revision[int.Parse(args[0])];
for( int i = 0; i < revs.Length; ++i )
{
revs[i] = new Revision(i, i % 4, i < 8000 ? 4 : i % 5, 0, i
% 12 == 0,
"this is a comment", 0, i, false, 1,
"jakdjfalskjfasjfasjfasjf", 10);
}
int ini = Environment.TickCount;
IEnumerable query = from s in revs
where s.BranchId == 4 && s.Last
select s;
int time = Environment.TickCount - ini;
int num = 0;
foreach( Revision r in query )
{
// Console.WriteLine("{0} - objid:{1}", num, r.ObjId);
++num;
}
Console.WriteLine("time retrieving {0} {1} ms", num, time);
num = 0;
ini = Environment.TickCount;
foreach( Revision r in revs )
if( r.Last && r.BranchId == 4)
++num;
Console.WriteLine("time retrieving iteratively {0} {1} ms", num,
Environment.TickCount - ini);
}
}
}
- Original Message -
From: "Kamil Skalski" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc: "Marek Safar" <[EMAIL PROTECTED]>; "Robert Jordan"
<[EMAIL PROTECTED]>;
Sent: Tuesday, September 25, 2007 5:04 PM
Subject: Re: [Mono-dev] Linq sample?
> 2007/9/25, pablosantosluac <[EMAIL PROTECTED]>:
>> Hi,
>>
>> Well, I've just tried some simple tests yet, but I'd say performance is
>> awsome... I mean, searching in an array of 120 Million objects, using
>> about
>> 1GB RAM looking for a simple query checking a couple of properties needed
>> only 185ms to finish!!!
>>
>> Doing it iteratively (looping through the array) took 284ms against 3 in
>> a
>> 12Million array (linq is faster!).
>>
>>
>
> After getting such results I would guess there is some problem with
> the benchmark. You could post it here, so we can look at it. Such
> results are hardly possible, since linq is mostly just a layer about
> the standard search code, so it should never actually run faster
> (unless we speak about some complex Linq to SQL stuff involving code
> generation etc.).
>
> --
> Kamil Skalski
> http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
well, I'm just "counting the numbers" after retrieving the query (and I
guess this is NOT the way to do it, but I'm not very used to enumerators,
specially writing my test with "vi")
Ok, I changed the loop so that now
foreach( Revision r in query )
{
// Console.WriteLine("{0} - objid:{1}", num, r.ObjId);
++num;
value += r.ObjId;
}
I print value at the end:
results: 120 elements -> linq -> 3ms, iteratively -> 28ms
results: 1200 elements (12millions) -> linq -> 294ms, iteratively -> 323
Yes, the difference is too small to be meangiful, but still, it is superb.
Is there a way to build the queries dinamically
- Original Message -
From: "Kamil Skalski" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc: "Marek Safar" <[EMAIL PROTECTED]>; "Robert Jordan"
<[EMAIL PROTECTED]>;
Sent: Tuesday, September 25, 2007 7:13 PM
Subject: Re: [Mono-dev] Linq sample?
>> foreach( Revision r in query )
>> {
>> // Console.WriteLine("{0} - objid:{1}", num, r.ObjId);
>>++num;
>> }
>
> I'm pretty sure (accounting your previous post about superb
> performance) that this loop is actually optimized out by compiler. You
> should *use* the r instance somehow, for example do a sum of all
> r.ObjId values in both of the loops and then check the numbers.
>
> --
> Kamil Skalski
> http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq status
It works with SVN HEAD!!! - Original Message - From: "Marek Safar" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: Sent: Monday, September 24, 2007 7:26 PM Subject: Re: [Mono-dev] Linq status > Hi Pablo, >> I was wondering which is the current Linq status in mono. >> > LINQ is currently under development and some pieces are already working. > >> I've downloaded and compiled the olive project, and now I have the >> System.Data.Linq assembly but I was wondering how should I write a Linq >> sample in mono. >> > Exactly the same as you would do for Microsoft .NET. Our libraries and > compliers > should be compatible. > >> I didn't find a sample or test in the code to start up with. >> >> I tried this one from msdn, but I guess I'm doing something wrong because >> I >> wasn't able to compile it. >> > You probably forget to pass -langversion:linq option This option is only > temporary (to disable not > very stable features) and will very likely be removed in the next Mono > release. > > I also recommend you to use SVN HEAD version as LINQ is under development > and SVN > contains more features than Mono 1.2.5.* release. > > Marek > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting Question
Yes, a custom one is even faster, but, by default, I've measured the mono one to be quite faster than the ms one. On Mon, 2007-09-24 at 16:42 +0200, pablosantosluac wrote: > It is fully compatible. With Mono 1.2.5 it's now fully compatible. The Dictionary (generic) collection wasn't compatible in < 1.2.5 > > Mono remoting is one of the nicest thing you'll find for Unix development. I agree, it's like sweet strawberries on vanilla ice cream. > Binary serialization outperforms the MS implementation. Not sure about that one, my custom (fast) serializer is faster :) > > pablo - Original Message - From: "Mirco Bauer" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; Sent: Monday, September 24, 2007 5:13 PM Subject: Re: [Mono-dev] Remoting Question ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
Well, I guess I'm doing something wrong or using an old mono runtime,
because the sample is very simple. Does it work for you?
Another question: is Linq performace good?
using System;
using System.Linq;
using System.Collections.Generic;
class app {
static void Main() {
string[] names = { "Burke", "Connor", "Frank",
"Everett", "Albert", "George",
"Harris", "David" };
IEnumerable query = from s in names
where s.Length == 5
orderby s
select s.ToUpper();
foreach (string item in query)
Console.WriteLine(item);
}
}
- Original Message -
From: "Kamil Skalski" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc: ; "Robert Jordan" <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2007 5:25 PM
Subject: Re: [Mono-dev] Linq sample?
> 2007/9/24, pablosantosluac <[EMAIL PROTECTED]>:
>> Thanks Robert,
>>
>> One more question: now it compiles but I can't run it.
>>
>> I'm using Mono JIT compiler version 1.2.5 (/trunk/ r84774)
>>
>> And I get:
>> Unhandled Exception: System.InvalidProgramException: Invalid IL code in
>> app:Main (): IL_: ldc.i4.8
>>
>
> Looks like a bug in compiler or runtime. You should produce a small
> sample triggering this error and post to bugzilla.
>
> --
> Kamil Skalski
> http://nazgul.omega.pl
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Linq sample?
Thanks Robert, One more question: now it compiles but I can't run it. I'm using Mono JIT compiler version 1.2.5 (/trunk/ r84774) And I get: Unhandled Exception: System.InvalidProgramException: Invalid IL code in app:Main (): IL_: ldc.i4.8 I guess I'm still doing something wrong... Thanks pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Monday, September 24, 2007 5:12 PM Subject: Re: [Mono-dev] Linq sample? > pablosantosluac wrote: >> Hi! >> >> I was wondering which is the current Linq status in mono. >> >> I've downloaded and compiled the olive project, and now I have the >> System.Data.Linq assembly but I was wondering how should I write a Linq >> sample in mono. >> >> I didn't find a sample or test in the code to start up with. >> >> I tried this one from msdn, but I guess I'm doing something wrong because >> I >> wasn't able to compile it. > > Compile it with gmcs -langversion:linq > > 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] Remoting Question
It is fully compatible. Mono remoting is one of the nicest thing you'll find for Unix development. Binary serialization outperforms the MS implementation. pablo - Original Message - From: "Phil" <[EMAIL PROTECTED]> To: Sent: Monday, September 24, 2007 4:36 PM Subject: [Mono-dev] Remoting Question > Is .NET Remoting in Mono compatible with Microsoft's implementation? > And if not, how about BinaryFormatter? > > Thanks! > > - Phil > ___ > 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] Linq sample?
Hi!
I was wondering which is the current Linq status in mono.
I've downloaded and compiled the olive project, and now I have the
System.Data.Linq assembly but I was wondering how should I write a Linq
sample in mono.
I didn't find a sample or test in the code to start up with.
I tried this one from msdn, but I guess I'm doing something wrong because I
wasn't able to compile it.
using System;
using System.Linq;
using System.Collections.Generic;
class app {
static void Main() {
string[] names = { "Burke", "Connor", "Frank",
"Everett", "Albert", "George",
"Harris", "David" };
IEnumerable query = from s in names
where s.Length == 5
orderby s
select s.ToUpper();
foreach (string item in query)
Console.WriteLine(item);
}
}
I'm just interested in "in-memory" queries.
Any suggestions?
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Linq status
Hi!
I was wondering which is the current Linq status in mono.
I've downloaded and compiled the olive project, and now I have the
System.Data.Linq assembly but I was wondering how should I write a Linq
sample in mono.
I didn't find a sample or test in the code to start up with.
I tried this one from msdn, but I guess I'm doing something wrong because I
wasn't able to compile it.
using System;
using System.Linq;
using System.Collections.Generic;
class app {
static void Main() {
string[] names = { "Burke", "Connor", "Frank",
"Everett", "Albert", "George",
"Harris", "David" };
IEnumerable query = from s in names
where s.Length == 5
orderby s
select s.ToUpper();
foreach (string item in query)
Console.WriteLine(item);
}
}
I'm just interested in "in-memory" queries.
Any suggestions?
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] Problem with sqlite and Win2000
Do you have a callstack? - Original Message - From: "Torello Querci" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Sent: Friday, September 07, 2007 10:25 AM Subject: Re: [Mono-dev] Problem with sqlite and Win2000 > Unfortunally using sqlite2 or sqlite3 I have the same result. The > application crash :( > > 2007/9/7, Torello Querci <[EMAIL PROTECTED]>: >> Hi, I not use thread, so I wait the end of a select before to do the >> next. >> Under XP work fine. >> >> Now I try to use sqlite2 instead. >> >> If you want I can attach a simple testing program with related DB. >> >> 2007/9/7, pablosantosluac <[EMAIL PROTECTED]>: >> > Hi, >> > >> > Well, you know SQLite doesn't support concurrency... don't you? >> > >> > Could it be related? >> > >> > pablo >> > - Original Message - >> > From: "Torello Querci" <[EMAIL PROTECTED]> >> > To: >> > Sent: Friday, September 07, 2007 8:50 AM >> > Subject: [Mono-dev] Problem with sqlite and Win2000 >> > >> > >> > > Hi to all, >> > > >> > > .. I have a real big problem using SQLite on old Win2000 installation >> > > (Win2000 that is not update for several reason) ... If I run several >> > > query (not is necessary a big number, sometimes 10 query is >> > > sufficient) the program crash. I try both 1.2.4 and 1.2.5 version. >> > > I try the same assembly on Linux and WinXP to run 10 query I have >> > > no problem. >> > > >> > > Any suggestion? Is a mono bug or Windows bug that is fixed in some >> > > service pack that is not installed? >> > > >> > > If you want I realize a small program to show this behavious. >> > > >> > > Thank's in advance (and sorry for my english) >> > > >> > > Best Regards >> > > Torello Querci >> > > ___ >> > > Mono-devel-list mailing list >> > > Mono-devel-list@lists.ximian.com >> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with sqlite and Win2000
Hi, Well, you know SQLite doesn't support concurrency... don't you? Could it be related? pablo - Original Message - From: "Torello Querci" <[EMAIL PROTECTED]> To: Sent: Friday, September 07, 2007 8:50 AM Subject: [Mono-dev] Problem with sqlite and Win2000 > Hi to all, > > .. I have a real big problem using SQLite on old Win2000 installation > (Win2000 that is not update for several reason) ... If I run several > query (not is necessary a big number, sometimes 10 query is > sufficient) the program crash. I try both 1.2.4 and 1.2.5 version. > I try the same assembly on Linux and WinXP to run 10 query I have > no problem. > > Any suggestion? Is a mono bug or Windows bug that is fixed in some > service pack that is not installed? > > If you want I realize a small program to show this behavious. > > Thank's in advance (and sorry for my english) > > Best Regards > Torello Querci > ___ > 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] Warnings in mono 1.2.5
I've also seen these in previous releases... - Original Message - From: "Michał Ziemski" <[EMAIL PROTECTED]> To: Sent: Monday, September 03, 2007 9:12 AM Subject: [Mono-dev] Warnings in mono 1.2.5 Hi! I am running a vanilla mono 1.2.5 on Suse 10.0. My app (Amazon S3 backup utility) occasionally (like 1 in 20 runs) produces warnings: WARNING **: _wapi_thread_abandon_mutexes: error looking up thread handle 0x408 WARNING **: _wapi_thread_set_termination_details: error looking up thread handle (nil) Despite the warnings, app works fine. My app mostly uses synchronous HttpWebRequests, no threading. Any ideas what might be the cause? I considered filing a bug, but I cannot provide any simpe testcase yet, so I decided to ask here first. Cheers, Michał Ziemski ___ 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] S390
Hi there! The Mono S390 works on Linux 390, isn't it? Ok, my question is: can a mono app running on a 390 virtual machine access resources on other partitions or in the "real" host? We'd considering giving support to "host" users using mono too... 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] Compilation and App.ico
Yes, it is the same but, I compiled 84774 and the problem is still there... I guess 82617 is not included... - Original Message - From: "Andy Hume" <[EMAIL PROTECTED]> To: "'pablosantosluac'" <[EMAIL PROTECTED]>; Sent: Thursday, August 30, 2007 12:31 PM Subject: RE: [Mono-dev] Compilation and App.ico > Is this the same as http://bugzilla.ximian.com/show_bug.cgi?id=82617 ? > > Andy > >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf >> Of pablosantosluac >> Sent: 30 August 2007 10:00 >> To: mono-devel-list@lists.ximian.com >> Subject: [Mono-dev] Compilation and App.ico >> >> Hi, >> >> After r84774 I'm trying to compile all the plastic code with mono. >> >> I've detected the compiler needs the App.ico files to be in >> non readonly state. .NET doesn't complain... >> >> 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] Conditional compilation
Yes! :-)
- Original Message -
From: "Angel Marin" <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 30, 2007 10:35 PM
Subject: Re: [Mono-dev] Conditional compilation
> pablosantosluac escribió:
>> I have a code fragment like the following:
> [...]
>
>> > define="${define}" >
>
> [...]
>
>> But when I run the app no output is generated.
>>
>> If I compile it directly with mcs it works as expected, printing the
>> Console.WriteLine message.
>>
>> Do you find something wrong? Is it a bug on Nant?
>
> Your nant task is building the code as winexe, so there is no console to
> write to. Try target="exe".
>
> Regards,
> --
> Angel Marin
> http://anmar.eu.org/
>
> ___
> 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] Conditional compilation
it works if you compile it with mcs or csc...
- Original Message -
From: "Angel Marin" <[EMAIL PROTECTED]>
To:
Sent: Thursday, August 30, 2007 10:35 PM
Subject: Re: [Mono-dev] Conditional compilation
> pablosantosluac escribió:
>> I have a code fragment like the following:
> [...]
>
>> > define="${define}" >
>
> [...]
>
>> But when I run the app no output is generated.
>>
>> If I compile it directly with mcs it works as expected, printing the
>> Console.WriteLine message.
>>
>> Do you find something wrong? Is it a bug on Nant?
>
> Your nant task is building the code as winexe, so there is no console to
> write to. Try target="exe".
>
> Regards,
> --
> Angel Marin
> http://anmar.eu.org/
>
> ___
> 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] Conditional compilation
I specified NAnt to use 1.0 with -t:mono.1.0
- Original Message -
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "'pablosantosluac'" <[EMAIL PROTECTED]>;
Sent: Thursday, August 30, 2007 10:00 PM
Subject: RE: [Mono-dev] Conditional compilation
> Pablo,
>
> What happens if you compile using gmcs, because NAnt is probably targeting
> the 2.0 profile ?
>
> I know there's a issue in gmcs where conditional compilation does not work
> correct for generic methods
> (http://bugzilla.ximian.com/show_bug.cgi?id=82443), but it should work for
> non-generic methods.
>
> Gert
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> pablosantosluac
> Sent: donderdag 30 augustus 2007 21:38
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Conditional compilation
>
> Hi,
>
> I have a code fragment like the following:
>
> using System;
> using System.Diagnostics;
>
>
> namespace conditionalcompilation
> {
> class Class1
> {
> static void Main(string[] args)
> {
> Class1 me = new Class1();
> me.Go();
> }
>
> [Conditional("YELLOW")]
> public void Go()
> {
> Console.WriteLine("Hello");
> }
> }
> }
>
>
> And the nant build file is:
>
>
>
>
>TEST
>
>
>
>
>
>
>
> define="${define}" >
>
>
>
>
>
>
>
>
>
>
>
>
> I build it with latest mono (1.2.5) (same results with 1.2.4):
> nant.bat -D:define=YELLOW -v -t:mono-1.0
>
> conditional:
>
> [csc] 'D:\data\develop\conditionalcompilation\aaa.cs' has been
> updated, recompiling.
> [csc] Compiling 3 files to
> 'D:\data\develop\conditionalcompilation\conditional.exe'.
> [csc] Contents of C:\DOCUME~1\pablo\CONFIG~1\Temp\tmp445918bc.tmp.
> [csc] /fullpaths
> [csc] /debug
> [csc] "/define:DEBUG"
> [csc] "/define:TRACE"
> [csc] /nologo
> [csc] "/target:winexe"
> [csc] "/define:YELLOW"
> [csc] "/out:D:\data\develop\conditionalcompilation\conditional.exe"
> [csc] "/reference:C:\Archivos de
> programa\Mono-1.2.4\lib\mono\1.0\System.Windows.Forms.dll"
> [csc] "/reference:C:\Archivos de
> programa\Mono-1.2.4\lib\mono\1.0\System.Drawing.dll"
> [csc] "/reference:C:\Archivos de
> programa\Mono-1.2.4\lib\mono\1.0\System.Data.dll"
> [csc] "D:\data\develop\conditionalcompilation\aaa.cs"
> [csc] "D:\data\develop\conditionalcompilation\AssemblyInfo.cs"
> [csc] "D:\data\develop\conditionalcompilation\Class1.cs"
> [csc]
>
>
> But when I run the app no output is generated.
>
> If I compile it directly with mcs it works as expected, printing the
> Console.WriteLine message.
>
> Do you find something wrong? Is it a bug on Nant?
>
> 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] Conditional compilation
Hi,
I have a code fragment like the following:
using System;
using System.Diagnostics;
namespace conditionalcompilation
{
class Class1
{
static void Main(string[] args)
{
Class1 me = new Class1();
me.Go();
}
[Conditional("YELLOW")]
public void Go()
{
Console.WriteLine("Hello");
}
}
}
And the nant build file is:
TEST
I build it with latest mono (1.2.5) (same results with 1.2.4):
nant.bat -D:define=YELLOW -v -t:mono-1.0
conditional:
[csc] 'D:\data\develop\conditionalcompilation\aaa.cs' has been
updated, recompiling.
[csc] Compiling 3 files to
'D:\data\develop\conditionalcompilation\conditional.exe'.
[csc] Contents of C:\DOCUME~1\pablo\CONFIG~1\Temp\tmp445918bc.tmp.
[csc] /fullpaths
[csc] /debug
[csc] "/define:DEBUG"
[csc] "/define:TRACE"
[csc] /nologo
[csc] "/target:winexe"
[csc] "/define:YELLOW"
[csc] "/out:D:\data\develop\conditionalcompilation\conditional.exe"
[csc] "/reference:C:\Archivos de
programa\Mono-1.2.4\lib\mono\1.0\System.Windows.Forms.dll"
[csc] "/reference:C:\Archivos de
programa\Mono-1.2.4\lib\mono\1.0\System.Drawing.dll"
[csc] "/reference:C:\Archivos de
programa\Mono-1.2.4\lib\mono\1.0\System.Data.dll"
[csc] "D:\data\develop\conditionalcompilation\aaa.cs"
[csc] "D:\data\develop\conditionalcompilation\AssemblyInfo.cs"
[csc] "D:\data\develop\conditionalcompilation\Class1.cs"
[csc]
But when I run the app no output is generated.
If I compile it directly with mcs it works as expected, printing the
Console.WriteLine message.
Do you find something wrong? Is it a bug on Nant?
Thanks,
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Compilation and App.ico
Hi, After r84774 I'm trying to compile all the plastic code with mono. I've detected the compiler needs the App.ico files to be in non readonly state. .NET doesn't complain... pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Possible bug in encoding at Solaris and PowerPC
Hi, I've found a problem with our server running on MacOSX (PPC) and Solaris SPARC. I'm reading a field in a table from a Firebird database. The field is CHAR(1). In Windows (.NET and Mono) and Linux (Mono) when you read the field using firebirdDotNet provider you get a Char as a result. In Solaris SPARC and MacOS X you get a string with two blanks at the end. I reported it to the firebirdDotNet list but they told me it must be a Mono problem because it runs on Linux and Windows. I can file a testcase but you'd probably have to look into the firebird provider... At the moment I've just made a workaround but it doesn't look like a good idea... Pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Remoting with DateTime
It is also a problem with .NET 1 working against .NET 2.0 so we didn't consider it a problem in mono. I mean, it is doing the same as .NET is doing, not being compatible. I didn't think it was worth to tell... I'll do it next time, pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Friday, August 10, 2007 8:38 PM Subject: Re: [Mono-dev] Remoting with DateTime > > pablosantosluac wrote: >> We solve it serializing the ticks instead! > > It would be nice if you guys would file bugs even if there > are workarounds. > > > Thx > Robert > > >> - Original Message - >> From: "Robert Jordan" <[EMAIL PROTECTED]> >> To: >> Sent: Friday, August 10, 2007 8:09 PM >> Subject: Re: [Mono-dev] Remoting with DateTime >> >> >>> Hi, >>> >>> Jae Stutzman wrote: >>>> Replying to my own mail... >>>> >>>> The failure happens when using TCP remoting, when I tried with HTTP the >>>> sample worked. BTW this is with SVN rev 83316. >>>> >>>> Something going on in the binary serialization i reckon. >>> The soap formatter is handling DateTime differently, unlike the >>> binary formatter which solely relies on binary serialization. >>> >>> Since DateTime is not serialization compatible between mono >>> and MS.NET 2.0, remoting doesn't work either. >>> >>> Please file a bug at http://www.mono-project.com/Bugs >>> product "Class Libraries", component "corlib". >>> >>> 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] Remoting with DateTime
We solve it serializing the ticks instead! - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Friday, August 10, 2007 8:09 PM Subject: Re: [Mono-dev] Remoting with DateTime > Hi, > > Jae Stutzman wrote: >> Replying to my own mail... >> >> The failure happens when using TCP remoting, when I tried with HTTP the >> sample worked. BTW this is with SVN rev 83316. >> >> Something going on in the binary serialization i reckon. > > The soap formatter is handling DateTime differently, unlike the > binary formatter which solely relies on binary serialization. > > Since DateTime is not serialization compatible between mono > and MS.NET 2.0, remoting doesn't work either. > > Please file a bug at http://www.mono-project.com/Bugs > product "Class Libraries", component "corlib". > > 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] Remoting with DateTime
are you using a .NET 1.1 client against a 2.0??? If so... this happens! Otherwise it works? - Original Message - From: Jae Stutzman To: mono-devel-list@lists.ximian.com Sent: Friday, August 10, 2007 7:18 PM Subject: [Mono-dev] Remoting with DateTime Is DateTime supposed to be supported as a parameter in remote calls? I'm getting an ArgumentOutOfRangeException like this: Note: This was just passing DateTime.Now Value -8590148590525713308 is outside the valid range [0,31553789759]. Parameter name: ticks Maybe DateTime is not viewed as a primitive type here...if not let me know and I'll do something else. Jae -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C# fast fuzzy text search
Hi, I guess this is out of topic but: is there a fast implementation in C# (ok, or anything else) for fuzzy text search? Something like the bitap algorithm or similar? I know dotlucene supports fuzzy search but we need to actually be able to locate big text (some lines) fragments on files, not just short strings... Ok, 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 compile with mono
Hi again, Well, the problem I had is solved compiling with profile mono-1.0. But then I still have a problem with assemblies with resources in serveral languages. pablo - Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: Sent: Monday, August 06, 2007 6:21 PM Subject: [Mono-dev] Can't compile with mono > Hi, > > When I try to compile a project with Mono (1.2.4 or 1.2.5) and the > included > nant I get a message dialog telling: > > **ERROR **: Can't find custom attr constructor image: [PATH TO MY DLL] > mtoken: 0x0a92 aborting... > > The dll is using localization extensively to support multiple languages. > > Any suggestion? > > 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] Can't compile with mono
Hi, When I try to compile a project with Mono (1.2.4 or 1.2.5) and the included nant I get a message dialog telling: **ERROR **: Can't find custom attr constructor image: [PATH TO MY DLL] mtoken: 0x0a92 aborting... The dll is using localization extensively to support multiple languages. Any suggestion? Thanks! pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Summit 07
Hi, I've seen the proposal for the next Mono Summit. I can help if you're interested in Madrid or even Valladolid (200km for Madrid, it has a big university ...). I could find help in Madrid too. Pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.5 Preview 2
Yes, because I'm looking for an specific element into an array, I'm looking
by index. Instead of creating an object of this type I just send the ID...
ok, ok, ok... I'll change it... :-(
- Original Message -
From: "Miguel de Icaza" <[EMAIL PROTECTED]>
To: "pablosantosluac" <[EMAIL PROTECTED]>
Cc: "Rolf Bjarne Kvinge" <[EMAIL PROTECTED]>; "'Wade Berrier'"
<[EMAIL PROTECTED]>;
Sent: Friday, August 03, 2007 5:43 PM
Subject: Re: [Mono-dev] Mono 1.2.5 Preview 2
>
>>
>> And I was assuming (probably it is wrong) that the parameter X was always
>> the itemId (which is a long). It used to work, but now I realize it can
>> be
>> wrong
>
> This does look very wrong. All the values in the binary search must be
> of the same type and you are casting it to two different types.
>
>>
>> public int Compare(object x, object y)
>>
>> {
>>
>>long itemId = (long)x;
>>
>>ObjectInfo objInfo = y as ObjInfo;
>>
>>// compare here objInfo.item and itemId
>>
>>
>>
>> }
>>
>>
>>
>> - Original Message -
>> From: "Rolf Bjarne Kvinge" <[EMAIL PROTECTED]>
>> To: "'pablosantosluac'" <[EMAIL PROTECTED]>; "'Wade Berrier'"
>> <[EMAIL PROTECTED]>;
>> Sent: Friday, August 03, 2007 5:09 PM
>> Subject: RE: [Mono-dev] Mono 1.2.5 Preview 2
>>
>>
>> >
>> >
>> >> -Original Message-
>> >> From: [EMAIL PROTECTED]
>> >> [mailto:mono-devel-list-
>> >> [EMAIL PROTECTED] On Behalf Of pablosantosluac
>> >> Sent: viernes, 03 de agosto de 2007 15:02
>> >> To: Wade Berrier; mono-devel-list@lists.ximian.com
>> >> Subject: Re: [Mono-dev] Mono 1.2.5 Preview 2
>> >>
>> >> Hi,
>> >>
>> >> I've just run Plastic with preview 1.2.5 and:
>> >>
>> >> - I got a "Comparer threw an exception" in a ArrayList BinarySearch
>> >> which was working with 1.2.4. It looks like the list is sending a
>> >> wrong
>> >> parameter to the Compare(object x, object y) method. The "x" is
>> >> expected
>> > to be a
>> >> long but an objects arrives.
>> >>
>> >> It looks like the order in which objects are sent to the Comparer are
>> >> switched.
>> >>
>> >
>> > Could you provide some more information on this issue (stacktraces,
>> > maybe
>> > sample code)?
>> >
>> > Rolf
>> >
>> >> pablo
>> >>
>> >> - Original Message -
>> >> From: "Wade Berrier" <[EMAIL PROTECTED]>
>> >> To:
>> >> Sent: Thursday, August 02, 2007 1:30 AM
>> >> Subject: [Mono-dev] Mono 1.2.5 Preview 2
>> >>
>> >>
>> >> > Hi,
>> >> >
>> >> > Mono 1.2.5 preview 2 sources, packages, and installers are available
>> >> at:
>> >> >
>> >> > http://mono.ximian.com/monobuild/preview/download-preview/
>> >> >
>> >> > At some point, the release notes for 1.2.5 will be available at:
>> >> >
>> >> > http://go-mono.com/archive/1.2.5/
>> >> >
>> >> > If no critical bugs are found after the preview period, these same
>> >> > downloads will be posted on mono-project.com for general
>> >> > consumption.
>> >> >
>> >> > If there are critical bugs found, only those packages/sources will
>> >> > be
>> >> > updated before publishing to mono-project.com.
>> >> >
>> >> > Since this release hasn't been pushed to our main download server,
>> >> some
>> >> > sources may be retagged if critical bugs are found. Those tags are
>> >> not
>> >> > final until we publish to mono-project.com.
>> >> >
>> >> > Changes with preview 2 over preview 1:
>> >> >
>> >> > MonoDevelop 0.15
>> >> > IPCE r6
>> >> > cocoa-sharp 0.9.4
>> >> > redcarpet/opencarpet support dropped (all the distros we support can
>> >> > install packages via yast or yum)
>> >> > Several critial bugs fixed that were found in preview1 (Thanks for
>> >> > testing!!)
>> >> > ikvm 0.34.0.2
>> >> >
>> >> > Wade
>> >> >
>> >> > ___
>> >> > 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
>> >>
>> >>
>> >> --
>> >> No virus found in this incoming message.
>> >> Checked by AVG Free Edition.
>> >> Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date:
>> >> 02/08/2007 14:22
>> >
>> >
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.5 Preview 2
Well, I'm not sure now this is a problem, maybe I'm doing something wrong,
but it works in 1.2.4 and in .NET:
I have this code
int position = ArrayList.Adapter(list).BinarySearch(itemId, this);
And I was assuming (probably it is wrong) that the parameter X was always
the itemId (which is a long). It used to work, but now I realize it can be
wrong
public int Compare(object x, object y)
{
long itemId = (long)x;
ObjectInfo objInfo = y as ObjInfo;
// compare here objInfo.item and itemId
}
- Original Message -
From: "Rolf Bjarne Kvinge" <[EMAIL PROTECTED]>
To: "'pablosantosluac'" <[EMAIL PROTECTED]>; "'Wade Berrier'"
<[EMAIL PROTECTED]>;
Sent: Friday, August 03, 2007 5:09 PM
Subject: RE: [Mono-dev] Mono 1.2.5 Preview 2
>
>
>> -Original Message-----
>> From: [EMAIL PROTECTED] [mailto:mono-devel-list-
>> [EMAIL PROTECTED] On Behalf Of pablosantosluac
>> Sent: viernes, 03 de agosto de 2007 15:02
>> To: Wade Berrier; mono-devel-list@lists.ximian.com
>> Subject: Re: [Mono-dev] Mono 1.2.5 Preview 2
>>
>> Hi,
>>
>> I've just run Plastic with preview 1.2.5 and:
>>
>> - I got a "Comparer threw an exception" in a ArrayList BinarySearch
>> which was working with 1.2.4. It looks like the list is sending a wrong
>> parameter to the Compare(object x, object y) method. The "x" is expected
> to be a
>> long but an objects arrives.
>>
>> It looks like the order in which objects are sent to the Comparer are
>> switched.
>>
>
> Could you provide some more information on this issue (stacktraces, maybe
> sample code)?
>
> Rolf
>
>> pablo
>>
>> - Original Message -
>> From: "Wade Berrier" <[EMAIL PROTECTED]>
>> To:
>> Sent: Thursday, August 02, 2007 1:30 AM
>> Subject: [Mono-dev] Mono 1.2.5 Preview 2
>>
>>
>> > Hi,
>> >
>> > Mono 1.2.5 preview 2 sources, packages, and installers are available
>> at:
>> >
>> > http://mono.ximian.com/monobuild/preview/download-preview/
>> >
>> > At some point, the release notes for 1.2.5 will be available at:
>> >
>> > http://go-mono.com/archive/1.2.5/
>> >
>> > If no critical bugs are found after the preview period, these same
>> > downloads will be posted on mono-project.com for general consumption.
>> >
>> > If there are critical bugs found, only those packages/sources will be
>> > updated before publishing to mono-project.com.
>> >
>> > Since this release hasn't been pushed to our main download server,
>> some
>> > sources may be retagged if critical bugs are found. Those tags are
>> not
>> > final until we publish to mono-project.com.
>> >
>> > Changes with preview 2 over preview 1:
>> >
>> > MonoDevelop 0.15
>> > IPCE r6
>> > cocoa-sharp 0.9.4
>> > redcarpet/opencarpet support dropped (all the distros we support can
>> > install packages via yast or yum)
>> > Several critial bugs fixed that were found in preview1 (Thanks for
>> > testing!!)
>> > ikvm 0.34.0.2
>> >
>> > Wade
>> >
>> > ___
>> > 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
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date:
>> 02/08/2007 14:22
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization performance + remoting
Rafael,
So, you basically mean changing the API from
MyType[] GetData()
to something like
byte[] GetData()
and perform the marshalling yourself?
Or maybe something like
MyArrayType GetData()
and then MyArrayType gets a customized serializer?
Thanks!
pablo
- Original Message -
From: "Rafael Teixeira" <[EMAIL PROTECTED]>
To: "Mirco Bauer" <[EMAIL PROTECTED]>
Cc: "pablosantosluac" <[EMAIL PROTECTED]>;
Sent: Friday, August 03, 2007 4:21 PM
Subject: Re: [Mono-dev] Serialization performance + remoting
> Pablo,
>
> I should add that probably custom serialization should happen at the
> Array level, not each element, or you may end experiencing a similar
> problem with System.Runtime.Serialization.ObjectIDGenerator.
>
> If you know that all the array elements are different instances (no
> repeated references), it will be a huge gain, because that is
> something you don't have a way of letting the system provided
> serializer know, so it will keep trying to generate ids and check in
> the other end to point all references to a single deserialized
> instance.
>
> In those cases I normally serialize the whole array into a very
> compact and concise blob (forget the fields descriptors or send them
> just once) and deserialize at the other end. The added complexity is
> paid well in performance, for large sets of objects.
>
> In some cases I go even further and use compression/decompression of
> the blob, to achieve even less transport time, I just experiment a bit
> to find the right threshold (minimum size) where compression is
> beneficial (it is kind of a lookup table one have to construct, to
> adjust to the real speed of the connection).
>
> Hope it helps,
>
> On 8/3/07, Mirco Bauer <[EMAIL PROTECTED]> wrote:
>> On Thu, 2007-08-02 at 22:54 +0200, pablosantosluac wrote:
>> > Thanks Mirco,
>> >
>> > Well, all my objects are already marked as [Serializable] instead of
>> > extending the MarshalByRefObject.
>>
>> Ok, then you are passing the objects by value already.
>>
>> >
>> > So, you mean if I extend the class it will go worse?
>>
>> Yes :)
>> As it will only transfer a proxy object which will always make remoting
>> calls for each method or property usage.
>> So code like this is very bad:
>> for (int i = 0; i < 10; i++) {
>> Console.WriteLine(myRemoteObject.SomeProperty);
>> }
>> that will cause 10 remoting calls...
>>
>> >
>> > The sample I'm using returns the 4700 objects in a single call (an
>> > array is
>> > returned)
>> Hmmm ok, so you have performance problems with the binary serialization
>> itself, not with the remoting/call overhead.
>>
>> Then you might want to implement custom optimized binary serialization.
>> This can be done by implementing the serializable interface yourself. I
>> have not done this yet, but I will (for smuxi), as the built in binary
>> serialization of objects in MS .NET and Mono is pretty slow (actually
>> damn slow IMHO). The problem is that they are very generic
>> implementations to fit all cases, AFAIK.
>>
>> How to implement faster binary serialization check this out:
>> http://www.codeproject.com/csharp/FastSerialization.asp
>>
>> Maybe I will start a SmartBinarySerializer project :-P not sure...
>> As there is no free (as in MIT/X11, BSD, LGPL, whatever license)
>> implementation of an optimized binary serialization :(
>>
>> --
>> Regards,
>>
>> Mirco 'meebey' Bauer
>>
>> PGP-Key:
>> http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8
>>
>> -BEGIN GEEK CODE BLOCK-
>> Version: 3.12
>> GIT d s-:+ a-- C++ UL$ P L++$>+++$ E- W+++$ N o? K- w++>! O M-
>> V? PS
>> PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y?
>> --END GEEK CODE BLOCK--
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>>
>
>
> --
> Rafael "Monoman" Teixeira
> ---
> "I myself am made entirely of flaws, stitched together with good
> intentions."
> Augusten Burroughs
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 1.2.5 Preview 2
Hi, I've just run Plastic with preview 1.2.5 and: - I got a "Comparer threw an exception" in a ArrayList BinarySearch which was working with 1.2.4. It looks like the list is sending a wrong parameter to the Compare(object x, object y) method. The "x" is expected to be a long but an objects arrives. It looks like the order in which objects are sent to the Comparer are switched. pablo - Original Message - From: "Wade Berrier" <[EMAIL PROTECTED]> To: Sent: Thursday, August 02, 2007 1:30 AM Subject: [Mono-dev] Mono 1.2.5 Preview 2 > Hi, > > Mono 1.2.5 preview 2 sources, packages, and installers are available at: > > http://mono.ximian.com/monobuild/preview/download-preview/ > > At some point, the release notes for 1.2.5 will be available at: > > http://go-mono.com/archive/1.2.5/ > > If no critical bugs are found after the preview period, these same > downloads will be posted on mono-project.com for general consumption. > > If there are critical bugs found, only those packages/sources will be > updated before publishing to mono-project.com. > > Since this release hasn't been pushed to our main download server, some > sources may be retagged if critical bugs are found. Those tags are not > final until we publish to mono-project.com. > > Changes with preview 2 over preview 1: > > MonoDevelop 0.15 > IPCE r6 > cocoa-sharp 0.9.4 > redcarpet/opencarpet support dropped (all the distros we support can > install packages via yast or yum) > Several critial bugs fixed that were found in preview1 (Thanks for > testing!!) > ikvm 0.34.0.2 > > Wade > > ___ > 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] Serialization performance + remoting
Hi again, I've just run some tests comparing mono to .net. It is exaclty the same code compiled with .NET but run with .NET and mono. The test case is a server (actually the plastic server) with the data cached and a client. So only serialization/deserialization play the game, no other processing is required. The data is about 2Mb. The test is run on a 1.5GHz Pentium M laptop with 1.5GB Ram. The time is average time after 10 runs. mono server + mono client -> 630ms mono server + .net client -> 721 ms .net server + .net client -> 1150 ms .net server + mono client -> 980 ms So it looks like mono serialization is much faster. I'm afraid the rest of the code is a bit slower running with Mono than .NET on my small test case (not the one I showed but another one not caching data). One question: is it recommended to compile with Mono to get better perfomance? I guess the answer but I just want to be sure. Thanks! pablo - Original Message - From: "pablosantosluac" <[EMAIL PROTECTED]> To: ; "Robert Jordan" <[EMAIL PROTECTED]> Sent: Friday, August 03, 2007 12:52 PM Subject: Re: [Mono-dev] Serialization performance + remoting > Thanks Robert. > > So, you mean it is better to pass an array of objects than actually a > list?? > Ok, I was already using arrays but I'll take it into account... > > pablo > - Original Message - > From: "Robert Jordan" <[EMAIL PROTECTED]> > To: > Sent: Friday, August 03, 2007 10:52 AM > Subject: Re: [Mono-dev] Serialization performance + remoting > > >> Hi Pablo, >> >> pablosantosluac wrote: >>> Because the people who actually implemented both serialization and >>> remoting >>> are in this list :-) I'd like to ask them to share with us some tips to >>> improve performance in serialization/remoting: I don't know, maybe >>> always >>> reduce the number of objects involved (unwrap the structures into >>> communication specific ones), get rid of some methods, avoid some data >>> types... whatever... >> >> Employing a remoting facade is the way to go, IMHO, even if it's >> not that hype. Try to keep the data exchange classes as flat as possible >> (struct-like, avoid lists [replace them with typed arrays], etc.). >> >> 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] Serialization performance + remoting
Thanks Robert. So, you mean it is better to pass an array of objects than actually a list?? Ok, I was already using arrays but I'll take it into account... pablo - Original Message - From: "Robert Jordan" <[EMAIL PROTECTED]> To: Sent: Friday, August 03, 2007 10:52 AM Subject: Re: [Mono-dev] Serialization performance + remoting > Hi Pablo, > > pablosantosluac wrote: >> Because the people who actually implemented both serialization and >> remoting >> are in this list :-) I'd like to ask them to share with us some tips to >> improve performance in serialization/remoting: I don't know, maybe always >> reduce the number of objects involved (unwrap the structures into >> communication specific ones), get rid of some methods, avoid some data >> types... whatever... > > Employing a remoting facade is the way to go, IMHO, even if it's > not that hype. Try to keep the data exchange classes as flat as possible > (struct-like, avoid lists [replace them with typed arrays], etc.). > > 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] Serialization performance + remoting
Thanks Mirco, Well, all my objects are already marked as [Serializable] instead of extending the MarshalByRefObject. So, you mean if I extend the class it will go worse? The sample I'm using returns the 4700 objects in a single call (an array is returned) Thanks! pablo On Thu, 2007-08-02 at 22:00 +0200, pablosantosluac wrote: > Hi, > > I'd like to get some tips on how to speed up object serialization. In my > current testing scenario I'm serializing about 7400 objects (references) > (which in turn contain about 3 objects each), and in my laptop it takes > about 1500ms to complete. As smuxi [0] uses .NET remoting very heavily I had to test/tune a lot... I found object references are very expensive, and not all objects need to be passed by reference, like simple data containers (models). Just add the Serializable attribute to those classes instead of extending MarshalByRefObject. Also synchronized calls are (time-)expensive, you should either try to reduce the number of calls or use async calls. I often use ngrep (network sniffer) to find unneeded calls, as the whole communication is very transparent, you easily do calls without knowing/noticing it ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization performance + remoting
Hi again, Will changing To "low" increase performance??? pablo - Original Message - From: "Mirco Bauer" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: Sent: Thursday, August 02, 2007 10:32 PM Subject: Re: [Mono-dev] Serialization performance + remoting ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Serialization performance + remoting
Hi, I'd like to get some tips on how to speed up object serialization. In my current testing scenario I'm serializing about 7400 objects (references) (which in turn contain about 3 objects each), and in my laptop it takes about 1500ms to complete. Well, AFAIK if you get rid of Equals and GetHashCode methods on the objects to be serialized you can improve performance. I checked it and it actually happens. My problem is that I have a code fragment on the server which takes (measured at the client) about 2seconds to finish. Well, about 500ms is actual processing, the rest is the framework doing serialization. Running with the profiler I found out that most of the time is being spent in a class called System.Runtime.Serialization.ObjectIDGenerator. It is actually trying to locate which objects are already serialized. I run with mono and got almost the same results (ok , I didn't run with the profiler but got more or less the same results in terms of timing). So, it seems the process gets more affected by the number of objects to be serialized than the size of data. Because the people who actually implemented both serialization and remoting are in this list :-) I'd like to ask them to share with us some tips to improve performance in serialization/remoting: I don't know, maybe always reduce the number of objects involved (unwrap the structures into communication specific ones), get rid of some methods, avoid some data types... whatever... 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] Updated Silverlight
I've just found the screenshots http://www.mono-project.com/MoonlightShots sorry pablo - Original Message - From: "Chris Toshok" <[EMAIL PROTECTED]> To: "Miguel de Icaza" <[EMAIL PROTECTED]> Cc: "Mono Olive - developing 3.0,3.5 and Silverlight" <[EMAIL PROTECTED]>; Sent: Monday, July 30, 2007 2:55 AM Subject: Re: [Mono-dev] Updated Silverlight > I've fixed the plugin to work with the 1.1 update, although some changes > might be considered breaking and/or portability problems if we want to > support both 1.0 and 1.1. > > 1. The plugin name and mime type have changed (from "WPFe Plug-In" >to "Silverlight Plug-In" and from "application/ag-pugin" to >"application/x-silverlight", respectively). > 2. the plugin script object needed the addition of a method >"isVersionSupported". right now it returns true only if the >version string is "1.1", but that's easy enough to fix (to add >"1.0") if that's what we want. > > One thing I've run into running the chess sample is that > System.Windows.ResourceCollection no longer exists in agclr.dll. It's > been renamed to ResourceDictionary. I've changed my local copy over to > using this name, but wanted to check on what people think: should we be > ifdef'ing and building 2 versions of agclr.dll (one for silverlight 1.0, > one for 1.1)? > > Chris > > On Sat, 2007-07-28 at 18:27 +, Miguel de Icaza wrote: >> Hello folks, >> >> An updated version of Silverlight 1.0 and 1.1 has been released; >> There are no API changes on the 1.1 .NET API, but the quote from the >> blog post is "more than 2000 bugs fixed" (this was in the rendering >> engine), so it might be worth testing against this updated engine. >> >> Announcement: >> >> http://blogs.msdn.com/tims/archive/2007/07/27/silverlight-1-0-rc1-is-here.aspx >> >> 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] Updated Silverlight
Hi, Where can I find screenshots of Mono/Linux/Silverlight? pablo - Original Message - From: "Chris Toshok" <[EMAIL PROTECTED]> To: "Miguel de Icaza" <[EMAIL PROTECTED]> Cc: "Mono Olive - developing 3.0,3.5 and Silverlight" <[EMAIL PROTECTED]>; Sent: Monday, July 30, 2007 2:55 AM Subject: Re: [Mono-dev] Updated Silverlight > I've fixed the plugin to work with the 1.1 update, although some changes > might be considered breaking and/or portability problems if we want to > support both 1.0 and 1.1. > > 1. The plugin name and mime type have changed (from "WPFe Plug-In" >to "Silverlight Plug-In" and from "application/ag-pugin" to >"application/x-silverlight", respectively). > 2. the plugin script object needed the addition of a method >"isVersionSupported". right now it returns true only if the >version string is "1.1", but that's easy enough to fix (to add >"1.0") if that's what we want. > > One thing I've run into running the chess sample is that > System.Windows.ResourceCollection no longer exists in agclr.dll. It's > been renamed to ResourceDictionary. I've changed my local copy over to > using this name, but wanted to check on what people think: should we be > ifdef'ing and building 2 versions of agclr.dll (one for silverlight 1.0, > one for 1.1)? > > Chris > > On Sat, 2007-07-28 at 18:27 +, Miguel de Icaza wrote: >> Hello folks, >> >> An updated version of Silverlight 1.0 and 1.1 has been released; >> There are no API changes on the 1.1 .NET API, but the quote from the >> blog post is "more than 2000 bugs fixed" (this was in the rendering >> engine), so it might be worth testing against this updated engine. >> >> Announcement: >> >> http://blogs.msdn.com/tims/archive/2007/07/27/silverlight-1-0-rc1-is-here.aspx >> >> 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] GUID generation
Hi, Thanks, I'll try CoCreateGuid and take a look at the libuuid. pablo - Original Message - From: Jonathan Chambers To: Robert Jordan Cc: mono-devel-list@lists.ximian.com Sent: Friday, July 27, 2007 11:16 PM Subject: Re: [Mono-dev] GUID generation Hello, pinvoking the the CoCreateGuid function from ole32.dll results in a time of 225 ms for mono. You could use that on Windows and libuuid on Linux (I didn't try it's performance). - Jonathan On 7/27/07, Robert Jordan <[EMAIL PROTECTED]> wrote: pablosantosluac wrote: > This fix looks good (performance wise) > > I don't understand why it is taking so long... Specially taking into account that the old sun blade almost needs the same time... (it is about 5000 bogomips...:-P) > > Any idea why the .net implementation is faster? Because MS.NET is probably p/invoking the unmanaged COM UUID generation API. Robert > > thanks, > > pablo > > > - Original Message ----- > From: Jonathan Chambers > To: pablosantosluac > Cc: mono-devel-list@lists.ximian.com > Sent: Friday, July 27, 2007 7:18 PM > Subject: Re: [Mono-dev] GUID generation > > > Hello, > > A quick test on my Xeon 3.6GHz reveals the following for me for generating a million GUIDs: > > .Net: 300 ms > mono: 2300 ms > mono (modified): 1875 ms > > So, not quite sure why you see 8 seconds on your server. For the modified version, I simply made the byte array inside of NewGuid static (since we are already locking for the RNG) for some performance improvement. Can someone comment if that change is acceptable? > > Thanks, > Jonathan > > > On 7/27/07, pablosantosluac <[EMAIL PROTECTED]> wrote: > Hi, > > I need to generate a large number of GUIDs. I tried with my laptop and a > .net console application and it can generate about 1million GUIDs in about > 480ms. > > Then I tried the same with mono and it needed 3.4 seconds. > > My surprise was trying on our Server (Intel(R) Xeon(TM) CPU 3.00GHz) where I > got the following results: > > 8 seconds to generate a million of GUIDs. > > Surprinsingly my old Sun Blade 1000 took almost the same time (Solaris 10 > SPARC): 9 seconds. > > I guess there is a reason why .NET implements faster GUID generation but, is > there any other globally unique number generator for Mono/Linux which I can > use? Also, any idea why the Xeon (which is much, much faster than both the > laptop and the Solaris box) is so slooow generating GUIDs? > > 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-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] GUID generation
This fix looks good (performance wise) I don't understand why it is taking so long... Specially taking into account that the old sun blade almost needs the same time... (it is about 5000 bogomips...:-P) Any idea why the .net implementation is faster? thanks, pablo - Original Message - From: Jonathan Chambers To: pablosantosluac Cc: mono-devel-list@lists.ximian.com Sent: Friday, July 27, 2007 7:18 PM Subject: Re: [Mono-dev] GUID generation Hello, A quick test on my Xeon 3.6GHz reveals the following for me for generating a million GUIDs: .Net: 300 ms mono: 2300 ms mono (modified): 1875 ms So, not quite sure why you see 8 seconds on your server. For the modified version, I simply made the byte array inside of NewGuid static (since we are already locking for the RNG) for some performance improvement. Can someone comment if that change is acceptable? Thanks, Jonathan On 7/27/07, pablosantosluac <[EMAIL PROTECTED]> wrote: Hi, I need to generate a large number of GUIDs. I tried with my laptop and a .net console application and it can generate about 1million GUIDs in about 480ms. Then I tried the same with mono and it needed 3.4 seconds. My surprise was trying on our Server (Intel(R) Xeon(TM) CPU 3.00GHz) where I got the following results: 8 seconds to generate a million of GUIDs. Surprinsingly my old Sun Blade 1000 took almost the same time (Solaris 10 SPARC): 9 seconds. I guess there is a reason why .NET implements faster GUID generation but, is there any other globally unique number generator for Mono/Linux which I can use? Also, any idea why the Xeon (which is much, much faster than both the laptop and the Solaris box) is so slooow generating GUIDs? 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] GUID generation
Hi, I need to generate a large number of GUIDs. I tried with my laptop and a .net console application and it can generate about 1million GUIDs in about 480ms. Then I tried the same with mono and it needed 3.4 seconds. My surprise was trying on our Server (Intel(R) Xeon(TM) CPU 3.00GHz) where I got the following results: 8 seconds to generate a million of GUIDs. Surprinsingly my old Sun Blade 1000 took almost the same time (Solaris 10 SPARC): 9 seconds. I guess there is a reason why .NET implements faster GUID generation but, is there any other globally unique number generator for Mono/Linux which I can use? Also, any idea why the Xeon (which is much, much faster than both the laptop and the Solaris box) is so slooow generating GUIDs? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Low level file access
Hi, What should I use to access files (write, set time, set readonly or not, and so on) at low level using Handles or file descriptors? Is it compatible with Win32? 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] Problems trying to compile Plastic on Linux
Ok, I'll try it :-P But I'm afraid it is not a bug but just something I'm doing wrong with Mono... We're also filing testcases for winforms but I expected it to be harder... Ok, I'll try... :-P - Original Message - From: ""Andrés G. Aragoneses [ knocte ]"" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 03, 2007 3:26 PM Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux pablosantosluac escribió: > I'll try but I'm afraid it won't be that easy. I guess a simple > application > will work. The problem can be with our big projects: 7 dlls, some .exe, > >100KLOC... Yes, size shouldn't be the problem but understand it is not > that > easy to reproduce... Hugh, don't want to sound rude but in my case we have > 60 dlls, and reducing Mono bugs to simple testcases still don't suppose a big task. My last example is bug 81951. Regards, Andrés [ knocte ] -- ___ 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] Problems trying to compile Plastic on Linux
Hi,
The assembly info doesn't contain a key file.
using System.Reflection;
using System.Runtime.CompilerServices;
[assembly: AssemblyDescription("BL063")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Codice Software, S.L.")]
[assembly: AssemblyProduct("Plastic")]
[assembly: AssemblyCopyright("2007")]
[assembly: AssemblyTrademark("2007")]
[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("1.5.63.0")]
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
The NANT Version is quite old:
NAnt 0.85 (Build 0.85.1932.0; rc3; 16/04/2005)
But I tried with the last one included in one of the latest Mono VMWare
machines and it fails too.
pablo
- Original Message -
From: "Gert Driesen" <[EMAIL PROTECTED]>
To: "Paolo Molaro" <[EMAIL PROTECTED]>;
Sent: Tuesday, July 03, 2007 11:43 AM
Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux
>
> - Original Message -
> From: "Paolo Molaro" <[EMAIL PROTECTED]>
> To:
> Sent: Tuesday, July 03, 2007 11:29 AM
> Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux
>
>
>> On 06/29/07 pablosantosluac wrote:
>>> I'm trying to compile the plastic server on linux using mono + NANT.
>>>
>>> It compiles all the .dll and even the .exe targets, but at the end it
>>> fails:
>> [...]
>>>[al] Starting mono ("al.exe"
>>> @"/tmp/tmp3e9e47fd.tmp"
>>> /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)'
>>> in '/home/CODICE/pablo/wk_pablo_juno/01nerva/'
>>>[al] ALINK: error A1044: Couldn't open
>>> '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file.
>>>
>>> BUILD FAILED - 0 non-fatal error(s), 45 warning(s)
>>>
>>> External Program Failed: al.exe (return code was 1):
>>> NAnt.Core.BuildException: External Program Failed: al.exe
>>> (return code was 1)
>>> at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask ()
>>> [0x0]
>> [...]
>>> We do use a signed assembly but it is a .dll (the first one to be
>>> compiled,
>>> and it seems without problems).
>>>
>>> I guess it must be very simple, but I don't understand what key file
>>> ALINK
>>> is complaining about
>
> Can you check what the value of the AssemblyKeyFile attribute is in the
> assembly for which you're creating the satellite assembly ?
>
> AL will use that value to load the key from if the keyfile argument is not
> specified on the commandline (by NAnt).
>
> Also, what version of NAnt are you using ?
>
> Gert
>
>
> ___
> 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] Problems trying to compile Plastic on Linux
Ok,
I'll try but I'm afraid it won't be that easy. I guess a simple application
will work. The problem can be with our big projects: 7 dlls, some .exe,
>100KLOC... Yes, size shouldn't be the problem but understand it is not that
easy to reproduce...
- Original Message -
From: "Paolo Molaro" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 03, 2007 11:29 AM
Subject: Re: [Mono-dev] Problems trying to compile Plastic on Linux
> On 06/29/07 pablosantosluac wrote:
>> I'm trying to compile the plastic server on linux using mono + NANT.
>>
>> It compiles all the .dll and even the .exe targets, but at the end it
>> fails:
> [...]
>>[al] Starting mono ("al.exe"
>> @"/tmp/tmp3e9e47fd.tmp"
>> /embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)'
>> in '/home/CODICE/pablo/wk_pablo_juno/01nerva/'
>>[al] ALINK: error A1044: Couldn't open
>> '/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file.
>>
>> BUILD FAILED - 0 non-fatal error(s), 45 warning(s)
>>
>> External Program Failed: al.exe (return code was 1):
>> NAnt.Core.BuildException: External Program Failed: al.exe
>> (return code was 1)
>> at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask ()
>> [0x0]
> [...]
>> We do use a signed assembly but it is a .dll (the first one to be
>> compiled,
>> and it seems without problems).
>>
>> I guess it must be very simple, but I don't understand what key file
>> ALINK
>> is complaining about
>
> Provide a tarball with a simple test case reproducing the issue and file
> a bug in bugzilla.
> Thanks!
>
> lupus
>
> --
> -
> [EMAIL PROTECTED] debian/rules
> [EMAIL PROTECTED] Monkeys do it better
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Problems trying to compile Plastic on Linux
Hi,
I'm trying to compile the plastic server on linux using mono + NANT.
It compiles all the .dll and even the .exe targets, but at the end it
fails:
[csc] Compilation succeeded - 3 warning(s)
[al] Output file
'/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server/es/loader.resources.dll'
does not exist, rebuilding.
[al] Compiling 0 files to
'/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server/es/loader.resources.dll'."
[al] Contents of /tmp/tmp3e9e47fd.tmp.
[al] /target:"lib"
[al]
/out:"/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server/es/loader.resources.dll"
[al] /culture:"es"
[al]
/template:"/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server/loader.exe"
[al] /nologo
[al]
[al] Starting mono ("al.exe"
@"/tmp/tmp3e9e47fd.tmp"
/embed:"/home/CODICE/pablo/wk_pablo_juno/01nerva/src/server/loader/loaderTranslations.es.resources",loader.loaderTranslations.es.resources)'
in '/home/CODICE/pablo/wk_pablo_juno/01nerva/'
[al] ALINK: error A1044: Couldn't open
'/home/CODICE/pablo/wk_pablo_juno/01nerva/bin/server' key file.
BUILD FAILED - 0 non-fatal error(s), 45 warning(s)
External Program Failed: al.exe (return code was 1):
NAnt.Core.BuildException: External Program Failed: al.exe
(return code was 1)
at NAnt.Core.Tasks.ExternalProgramBase.ExecuteTask ()
[0x0]
Total time: 11.7 seconds.
We do use a signed assembly but it is a .dll (the first one to be compiled,
and it seems without problems).
I guess it must be very simple, but I don't understand what key file ALINK
is complaining about
pablo
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Modal forms on 1.2.4
http://bugzilla.ximian.com/show_bug.cgi?id=81957 - Original Message - From: "Andreia Gaita" <[EMAIL PROTECTED]> To: "pablosantosluac" <[EMAIL PROTECTED]> Cc: Sent: Sunday, June 24, 2007 5:04 PM Subject: Re: [Mono-dev] Modal forms on 1.2.4 > Could you file a report, preferably with a small test case, please, on > http://bugzilla.ximian.com/enter_bug.cgi?product=Mono%3A+Class%20Libraries&component=Windows.Forms > > Thank you > > andreia > > On 6/18/07, pablosantosluac <[EMAIL PROTECTED]> wrote: >> Hi, >> >> It seems I can't submit messages to winforms list anymore. >> >> I've detected the following problem in 1.2.4 (it was not present in >> 1.2.3): >> >> 1- you have an application with a modal dialog >> 2- the dialog runs another application (also a mono winforms app) >> 3- the second app stays always below the launching one, which makes it >> unusable >> >> 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] __wapi_thread_set_termination_details
Hi, We're using a threadpool and when the application finishes, from time to time we get the following error: _wapi_thread_set_termination_details: error looking up thread handle Is just a WARNING message but I wonder why is it being raised I mean, we're not creating new threads manually but using ThreadPool.QueueUserWorkItem method 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 in UnixGroupInfo
I would rather skip the wrong user name, I guess this is the regular behaviour on Unix systems - Original Message - From: "Rafael Teixeira" <[EMAIL PROTECTED]> To: "Jonathan Pryor" <[EMAIL PROTECTED]> Cc: "pablosantosluac" <[EMAIL PROTECTED]>; Sent: Wednesday, June 20, 2007 3:11 PM Subject: Re: [Mono-dev] Error in UnixGroupInfo > Another variation to keep UnixUserInfo sealed, is to make the the > class itself accept an invalid name or a -1 as the user id, and throw > on any unknown property, except UserId (so sometimes the Name would > also be available, which helps pinpoint the failures, didn't follow > the GetMembers code to see if this would be the case). > > :) > > On 6/20/07, Rafael Teixeira <[EMAIL PROTECTED]> wrote: >> An alternative is to return 'dummy' members for the missing ones in >> GetMembers, aka >> Fowler's Special Case pattern, from the PoEAA book. >> For invalid users, return an instance of a subclass of >> Mono.Unix.UnixUserInfo, that returns UserId as -1, or some other >> invalid value. Also all other properties except Name would also have >> neutral or invalid values, and methods would do/return nothing, for >> this subclass. >> >> Just my 2 cents, >> >> On 6/20/07, Jonathan Pryor <[EMAIL PROTECTED]> wrote: >> > On Wed, 2007-06-20 at 11:30 +0200, pablosantosluac wrote: >> > > I have found an issue with Mono.Unix.UnixGroupInfo.GetMembers(). >> > > >> > > This method is meant to return the UnixUserInfo for the members of >> > > the given >> > > unix group. The issue arises when a system has an unexistent username >> > > defined in the group file. >> > > >> > > This is rather frequent, especially in a NIS environment (lazy >> > > admins). >> > > Normal unix behavior is to ignore the user and continue. >> > > UnixGroupInfo.GetMembers() raises an 'invalid username' exception, >> > > and there >> > > is no way to retrieve the rest of the users in the group. >> > > >> > > Is it right to absorb the exception in this method and continue >> > > resolving >> > > other users? >> > >> > Good question. I imagine that it would be more user-friendly to eat >> > the >> > ArgumentException and return what it can, but it would then mean that >> > the only way to know that there are invalid entries in the group file >> > is >> > to compare UnixUserInfo.GetMembers().Length to >> > UnixUserInfo.GetMemberNames().Length. >> > >> > Then again, is knowing that the group file has an invalid entry a >> > common >> > scenario that should be documented? >> > >> > Opinions? >> > >> > Thanks, >> > - Jon >> > >> > >> > ___ >> > Mono-devel-list mailing list >> > Mono-devel-list@lists.ximian.com >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> >> >> -- >> Rafael "Monoman" Teixeira >> --- >> "The reasonable man adapts himself to the world; the unreasonable one >> persists in trying to adapt the world to himself. Therefore all >> progress depends on the unreasonable man." George Bernard Shaw >> > > > -- > Rafael "Monoman" Teixeira > --- > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man." George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Error in UnixGroupInfo
Hi, I have found an issue with Mono.Unix.UnixGroupInfo.GetMembers(). This method is meant to return the UnixUserInfo for the members of the given unix group. The issue arises when a system has an unexistent username defined in the group file. This is rather frequent, especially in a NIS environment (lazy admins). Normal unix behavior is to ignore the user and continue. UnixGroupInfo.GetMembers() raises an 'invalid username' exception, and there is no way to retrieve the rest of the users in the group. Is it right to absorb the exception in this method and continue resolving other users? pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Modal forms on 1.2.4
Hi, It seems I can't submit messages to winforms list anymore. I've detected the following problem in 1.2.4 (it was not present in 1.2.3): 1- you have an application with a modal dialog 2- the dialog runs another application (also a mono winforms app) 3- the second app stays always below the launching one, which makes it unusable pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Subversion on MonoDevelop
Well, we have some experience doing tree-way merge tools with Mono Winforms on Linux... :-P - Original Message - From: "Rafael Teixeira" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Vladimir Giszpenc" <[EMAIL PROTECTED]>; Sent: Monday, May 28, 2007 4:12 PM Subject: Re: [Mono-dev] Subversion on MonoDevelop > inline > > On 5/28/07, Lluis Sanchez <[EMAIL PROTECTED]> wrote: >> El dv 25 de 05 del 2007 a les 08:04 -0400, en/na Vladimir Giszpenc va >> escriure: >> > Hi, >> > >> > PS While I am on the subject of Subversion, why is the diff window not >> > editable? >> >> Why should it be editable? What should allow you to edit? or do you mean >> 'selectable'? >> >> Lluis. > > Perhaps, what Vladimir wants is a "merge tool" window for the diff, > like the 3-pane one in TortoiseSVN, when there is conflicts. > > :) > > > -- > Rafael "Monoman" Teixeira > --- > "The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man." George Bernard Shaw > ___ > 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
