Re: [Mono-docs-list] [Mono-dev] Can not checkout trunk on windows
Sorry but it isnt totaly solved. Now ive got the following error: Cant check out path 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\c__CompilerGenerated2+c__CompilerGenerated13.xml': Bad syntax for filename, directoryname or drivename * This is free text translated from german windows Steve Jonathan Pryor schrieb: On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: Suggestions? All I can suggest is that namespace XML files should contain some character/string that namespaces are highly unlikely to contain, e.g. instead of en/System.xml for the XML documentation on the System namespace, use en/Namespace-System.xml. Any such character/string *must* be usable on Windows, so no ':' or similar characters can be used. We should add support for a different name like: ns-System.xml And then we can rename the files for the docs that we maintain. This has been done. Mike Kestner suggested using a namespaces.xml file; I chose not to do this as it made the migration of monodocer/monodocs2html/ecma-provider easier. And keep the old code for documentation that might be out that has not been updated by us. Monodoc will currently look for the older filename and rename accordingly; ecma-provider will check for both, with a preference for the non ns-prefixed name. monodocs2html currently requires the ns- prefixed files, as I couldn't think of an easy way to do the fallback within the XSLT. - Jon ___ Mono-docs-list maillist - Mono-docs-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-docs-list
Re: [Mono-winforms-list] Plastic 2.0 preview is out: check the winforms!
It would ne nice for those of us starting in mono to describe what plastic is! wonder when these things get incorporated into a Fedora update??? I haven't seen any in a long time! From: [EMAIL PROTECTED] To: mono-winforms-list@lists.ximian.com Date: Thu, 3 Jan 2008 00:38:01 +0100 Subject: [Mono-winforms-list] Plastic 2.0 preview is out: check the winforms! Hi there, I guess you'd like to have a look into the new Plastic SCM user interface. It is entirely written in C# and it looks superb, so I think you'll enjoy watching some of the things that can be achieved with the Mono WinForms implementation. Take a look at: http://labs.codicesoftware.com Enjoy! pablo ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list _ i’m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited
Sorry that I did not suggest this earlier, but did you look at using a
scheme for embedding the Lookuptables in the runtime like e.g. Char does?
The problem with using static fields is that they are per-domain and always
need to be (re)initialized.
Assume the following (worst) case:
We have 1000 Appdomains and each appdomain does a single ToString for a
double value.
In that case your implementation will:
* Consume more than 36MB RAM just for the lookup-tables
* Each of the single ToStrings will probably be about 10 times (just
making up a number) slower than now because for every single call you
recreate the entire lookuptable(s)
Moving the (pregenerated) lookuptables into the runtime will:
* Reduce the memory to a *single* instance of the lookuptable for all
Appdomains/Processes
* Potentially reduce memory by using mem-mapping
* Remove *ALL* initialization, which means full speed even with a single
ToString call.
* Nearly no overhead except a single internalcall to retieve the
datapointer(s)
* No race-conditions, no locking
This way it might even make sense to keep some of the original _decHex
Tables (maybe reduced in array size and do they both need Int32 anyways?).
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf
Gesendet: Donnerstag, 3. Januar 2008 09:21
An: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com
Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky
Betreff: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono
revisited
Hi, all.
Let me try to clarify a few things:
1. The Hex support is not for hexadecimal formatting but for speeding up
decimal formatting.
2. Following the reviews about the array size, the _decHexLen' array is
removed and the '_decHexDigits' is reduced to size of 400 bytes.
3. The third array that is part of the double ToString algorithm is
already defined within a nested class and will be initialized only when a
double/float ToString is invoked.
Attached is a revised version of 'NumberFormatter.cs' that includes these
changes.
Eyal.
-Original Message-
From: Andreas Nahr [mailto:[EMAIL PROTECTED]
Sent: 03 January 2008 03:17
To: 'Prakash Punnoor'; mono-devel-list@lists.ximian.com
Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal
Alaluf
Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited
The array initialization should also be done lazily and not in the
static constructor (should be removed completely because it drags in
other static fields that need to be preinitialized, code compiled
and so
on).
Especially the Hex support is IMHO completely off bounds. I
(personally) rarely see hex output and making EVERYBODY pay for a
hex speedup doesn't seem right. A simple if (array == null) Init ();
will be enough. You will pay per-call, but it is relatively cheap.
The only thing that is worth keeping in mind is that if this is a
static field, initialization probably needs to be protected by a lock
(I say probably, because we *could* ignore the race by carefully
making sure that we assign the public array only after it has been
initialized, so we would end up with N copies of an array initialized
in the worst case, but N-1 will be discarded by the GC).
You can also use the Bill Pugh's trick by using a nested class, so the jit
should lazily initialize it (it works with .net, no idea whether it does
with
mono.)
I don't know whether it would work with mono either but you may get
additional problems having a nested class in a structure ;)
Also there is no need to lock for multithreading. As Miguel wrote we can
simply ignore the race in this situation. Worst case two (or n) Lookuparrays
get created and all except one immediately garbage-collected after their
use.
All you need to have is
void Init () {
int[] temp = new int[x];
doinits()
staticField = temp; // Must not happen before doinits() }
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
Hi Ivan,
You are right, I've reverted the Hashtable patch and everything works
fine. TestGetProperties in TypeDescriptorTests is ok also.
Look at attached patch.
Regards,
Vladimir
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ivan N.
Zlatev
Sent: Thursday, January 03, 2008 2:24 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
Vladimir Krasnov wrote:
Hello,
Please review and approve attached patch for
TypeDescriptor.GetProperties() method. This fixes the order of
properties in the returning collection which is important for
System.Web data bound controls.
You can get rid off the Hashtable used in TypeInfo.GetProperties. I
introduced it because at some point Type.GetProperties used to return
two AnotherProperty PropertyInfos for typeof(B) in the following case:
class A
{
public string AnotherProperty {
}
}
class B : A
{
public new string AnotherProperty {
}
}
It seems to no longer be the case (back then I did not test the
Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor),
but you should test to make sure. You can check test #G2 in
TestGetProperties in TypeDescriptorTests.
Regards,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
TypeDescriptor.cs.patch
Description: TypeDescriptor.cs.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
On Thu, 2008-01-03 at 03:32 -0800, Vladimir Krasnov wrote:
Hi Ivan,
You are right, I've reverted the Hashtable patch and everything works
fine. TestGetProperties in TypeDescriptorTests is ok also.
Look at attached patch.
Looks good, please commit, thanks.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ivan N.
Zlatev
Sent: Thursday, January 03, 2008 2:24 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Patch for System.ComponentModel.TypeDescriptor
Vladimir Krasnov wrote:
Hello,
Please review and approve attached patch for
TypeDescriptor.GetProperties() method. This fixes the order of
properties in the returning collection which is important for
System.Web data bound controls.
You can get rid off the Hashtable used in TypeInfo.GetProperties. I
introduced it because at some point Type.GetProperties used to return
two AnotherProperty PropertyInfos for typeof(B) in the following case:
class A
{
public string AnotherProperty {
}
}
class B : A
{
public new string AnotherProperty {
}
}
It seems to no longer be the case (back then I did not test the
Type.GetProperties behavior on msnet and assumed bug in TypeDescriptor),
but you should test to make sure. You can check test #G2 in
TestGetProperties in TypeDescriptorTests.
Regards,
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Ivan N. Zlatev
Web: http://www.i-nZ.net
It's all some kind of whacked out conspiracy.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited
Hi, Andreas.
It does make sense to make the 'DblExpTab' common to all appdomains.
How do you implement such a scheme in Mono? Is it possible to achieve this
without going out to unsafe code and internal methods?
If the above is complicated, do you think that it makes sense to consider the
above as a separate task since the array size is now 24K and a scenario with
1000 domains is a rare scenario?
Thanks, Eyal.
-Original Message-
From: Andreas Nahr [mailto:[EMAIL PROTECTED]
Sent: 03 January 2008 11:19
To: Eyal Alaluf; 'Andreas Nahr'; 'Prakash Punnoor';
mono-devel-list@lists.ximian.com
Cc: 'Atsushi Eno'; 'Miguel de Icaza'; 'Juraj Skripsky'
Subject: AW: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono
revisited
Sorry that I did not suggest this earlier, but did you look at using a
scheme for embedding the Lookuptables in the runtime like e.g. Char does?
The problem with using static fields is that they are per-domain and always
need to be (re)initialized.
Assume the following (worst) case:
We have 1000 Appdomains and each appdomain does a single ToString for a
double value.
In that case your implementation will:
* Consume more than 36MB RAM just for the lookup-tables
* Each of the single ToStrings will probably be about 10 times (just
making up a number) slower than now because for every single call you
recreate the entire lookuptable(s)
Moving the (pregenerated) lookuptables into the runtime will:
* Reduce the memory to a *single* instance of the lookuptable for all
Appdomains/Processes
* Potentially reduce memory by using mem-mapping
* Remove *ALL* initialization, which means full speed even with a single
ToString call.
* Nearly no overhead except a single internalcall to retieve the
datapointer(s)
* No race-conditions, no locking
This way it might even make sense to keep some of the original _decHex
Tables (maybe reduced in array size and do they both need Int32 anyways?).
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf
Gesendet: Donnerstag, 3. Januar 2008 09:21
An: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com
Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky
Betreff: [SPAM] Re: [Mono-dev] [SPAM] Re: ToString() performace in Mono
revisited
Hi, all.
Let me try to clarify a few things:
1. The Hex support is not for hexadecimal formatting but for speeding up
decimal formatting.
2. Following the reviews about the array size, the _decHexLen' array is
removed and the '_decHexDigits' is reduced to size of 400 bytes.
3. The third array that is part of the double ToString algorithm is
already defined within a nested class and will be initialized only when a
double/float ToString is invoked.
Attached is a revised version of 'NumberFormatter.cs' that includes these
changes.
Eyal.
-Original Message-
From: Andreas Nahr [mailto:[EMAIL PROTECTED]
Sent: 03 January 2008 03:17
To: 'Prakash Punnoor'; mono-devel-list@lists.ximian.com
Cc: 'Miguel de Icaza'; 'Andreas Nahr'; 'Atsushi Eno'; 'Juraj Skripsky'; Eyal
Alaluf
Subject: AW: [Mono-dev] [SPAM] Re: ToString() performace in Mono revisited
The array initialization should also be done lazily and not in the
static constructor (should be removed completely because it drags in
other static fields that need to be preinitialized, code compiled
and so
on).
Especially the Hex support is IMHO completely off bounds. I
(personally) rarely see hex output and making EVERYBODY pay for a
hex speedup doesn't seem right. A simple if (array == null) Init ();
will be enough. You will pay per-call, but it is relatively cheap.
The only thing that is worth keeping in mind is that if this is a
static field, initialization probably needs to be protected by a lock
(I say probably, because we *could* ignore the race by carefully
making sure that we assign the public array only after it has been
initialized, so we would end up with N copies of an array initialized
in the worst case, but N-1 will be discarded by the GC).
You can also use the Bill Pugh's trick by using a nested class, so the jit
should lazily initialize it (it works with .net, no idea whether it does
with
mono.)
I don't know whether it would work with mono either but you may get
additional problems having a nested class in a structure ;)
Also there is no need to lock for multithreading. As Miguel wrote we can
simply ignore the race in this situation. Worst case two (or n) Lookuparrays
get created and all except one immediately garbage-collected after their
use.
All you need to have is
void Init () {
int[] temp = new int[x];
doinits()
staticField = temp; // Must not happen before doinits() }
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] set culture uses serialization?
Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.IO.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueuedObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObjectGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Header[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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] set culture uses serialization?
Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Head er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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
[Mono-dev] Accidental changes in commit 91959?
Hi Miguel,
I've noticed that you made the following change to
System.Net.Mail/SmtpClient.cs in commit 91959*:
--- trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs2007/12/06
14:22:51 90809
+++ trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs2007/12/27
18:30:23 91959
@@ -275,7 +275,7 @@
private string EncodeBody (AlternateView av)
{
- Encoding encoding = av.ContentType.CharSet != null ?
Encoding.GetEncoding (av.ContentType.CharSet) : Encoding.UTF8;
+ //Encoding encoding = av.ContentType.CharSet != null ?
Encoding.GetEncoding (av.ContentType.CharSet) : Encoding.UTF8;
byte [] bytes = new byte [av.ContentStream.Length];
av.ContentStream.Read (bytes, 0, bytes.Length);
The Changelog only describes a change to WebClient.cs. There are also
two small changes to HttpListenerContext.cs without Changelog entry.
Were those changes intended and what's the motivation/Changelog behind
them?
- Juraj
*)
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959view=log
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Web.Extensions Version 1.0.61025.0
Hello Igor, you removed the System.Web.Extensions Version 1.0.61025.0 in revision 92081. Now we have a Sys.Web.Extension only for 3.5 and a System.Web.Extensions.Design version 1.0.61025.0. This breaks existing .NET 2.0 Applications that are using the 2.0 AddOn version 1.0.61025.0. I also noticed that on current svn head i got following error (with the 1.0.61025.0 assembly) upgraded from working r89031: System.Web.HttpException: Path '/ScriptResource.axd' was not found. at System.Web.StaticFileHandler.ProcessRequest (System.Web.HttpContext context) [0x0] at System.Web.HttpApplication+c__CompilerGenerated2.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] Daniel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] set culture uses serialization?
Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System.I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObje ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.Head er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header[]) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serial ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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] System.Web.Extensions Version 1.0.61025.0
Daniel, I will revert version to 1.0.61025.0, It suppose to solve the problems. Igor. -Original Message- From: Daniel Nauck [mailto:[EMAIL PROTECTED] Sent: Thursday, January 03, 2008 6:34 PM To: Igor Zelmanovich; mono-devel-list@lists.ximian.com Cc: Marek Habersack Subject: System.Web.Extensions Version 1.0.61025.0 Hello Igor, you removed the System.Web.Extensions Version 1.0.61025.0 in revision 92081. Now we have a Sys.Web.Extension only for 3.5 and a System.Web.Extensions.Design version 1.0.61025.0. This breaks existing .NET 2.0 Applications that are using the 2.0 AddOn version 1.0.61025.0. I also noticed that on current svn head i got following error (with the 1.0.61025.0 assembly) upgraded from working r89031: System.Web.HttpException: Path '/ScriptResource.axd' was not found. at System.Web.StaticFileHandler.ProcessRequest (System.Web.HttpContext context) [0x0] at System.Web.HttpApplication+c__CompilerGenerated2.MoveNext () [0x0] at System.Web.HttpApplication.Tick () [0x0] Daniel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] set culture uses serialization?
In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System .I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQu eu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.He ad er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri al ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header []) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri al ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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] [PATCH] assembly name fixes for AssemblyName and runtime
Hey Andrés, Yes, you're right. I've updated that bug report with some additional info. Gert -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Andrés G. Aragoneses [ knocte ] Sent: woensdag 2 januari 2008 9:30 To: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] assembly name fixes for AssemblyName and runtime Gert Driesen escribió: The attached patches fix some issue in self-constructed AssemblyName instances, and more importantly it fixes the FullName and GetPublicKey(Token) of AssemblyName instances returned for AssemblyBuilders and baked assemblies. For baked assemblies, AssemblyName.FullName did not contain the PublicKeyToken=null spec for non-signed assemblies, like MS does. Fixing this involved changes in both corlib and the runtime. In the runtime we were also not reporting a failure for an assembly name containing a Version, Culture or PublicKeyToken spec without an actual value. Fixing this allows us to enable several tests that were previously failing. More details are available in the changelog for each patch. Hey Gert, looking the tests briefly it seems that this patch would also cover bug 322919, am I right? Regards, Andrés [ knocte ] -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Accidental changes in commit 91959?
Hey, The Changelog only describes a change to WebClient.cs. There are also two small changes to HttpListenerContext.cs without Changelog entry. Were those changes intended and what's the motivation/Changelog behind them? I forgot to update the ChangeLog for that, but the only reason for the change was that encoding was an unused variable, so it removed the warning that we got on every build. - Juraj *) http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959view=log ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Accidental changes in commit 91959?
Ah, I see. Sorry about the noise then. - Juraj On Thu, 2008-01-03 at 13:32 -0500, Miguel de Icaza wrote: Hey, The Changelog only describes a change to WebClient.cs. There are also two small changes to HttpListenerContext.cs without Changelog entry. Were those changes intended and what's the motivation/Changelog behind them? I forgot to update the ChangeLog for that, but the only reason for the change was that encoding was an unused variable, so it removed the warning that we got on every build. - Juraj *) http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/System/System.Net.Mail/SmtpClient.cs?rev=91959view=log ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] set culture uses serialization?
You could try calling Thread.CurrentCulture, compare the return value with the culture you want to set, and only call the setter if the two are different. Zoltan On Jan 3, 2008 6:40 PM, Steve Bjorg [EMAIL PROTECTED] wrote: In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,System .I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQu eu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteOb je ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging.He ad er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri al ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header []) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Seri al ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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] set culture uses serialization?
Well, the application runs in 10 different languages simultaneously. So, this is only going to help in a few cases. In other words, I should forget about CurrentCulture and instead use a manual override in all my date and number formatting invocations? That's going to be a major pain... :( Is this how it behaves under .Net as well? I'm really surprised about the behavior since CultureInfo is immutable (afaik). - Steve - Steve G. Bjorg MindTouch 555 W. Beech St. Suite 501 San Diego, CA 92101 619.795.8459x1106 office 619.795.3948 fax 425.891.5913 mobile On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote: You could try calling Thread.CurrentCulture, compare the return value with the culture you want to set, and only call the setter if the two are different. Zoltan On Jan 3, 2008 6:40 PM, Steve Bjorg [EMAIL PROTECTED] wrote: In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Syst em .I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Qu eu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging. He ad er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se ri al ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header []) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se ri al ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.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] set culture uses serialization?
Hi, CultureInfo might be inmutable, but its components like NumberFormatInfo are not. Also, even if it is inmutable, objects cannot be shared across appdomains, so we couldn't use the object set by the application in another domain. We assume that the thread culture is set only rarely, so the serialization overhead should not be a problem. Zoltan On Jan 3, 2008 8:37 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Well, the application runs in 10 different languages simultaneously. So, this is only going to help in a few cases. In other words, I should forget about CurrentCulture and instead use a manual override in all my date and number formatting invocations? That's going to be a major pain... :( Is this how it behaves under .Net as well? I'm really surprised about the behavior since CultureInfo is immutable (afaik). - Steve - Steve G. Bjorg MindTouch 555 W. Beech St. Suite 501 San Diego, CA 92101 619.795.8459x1106 office 619.795.3948 fax 425.891.5913 mobile On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote: You could try calling Thread.CurrentCulture, compare the return value with the culture you want to set, and only call the setter if the two are different. Zoltan On Jan 3, 2008 6:40 PM, Steve Bjorg [EMAIL PROTECTED] wrote: In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Syst em .I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Qu eu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write Ob je ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messaging. He ad er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se ri al ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Header []) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Se ri al ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at MindTouch.Dream.Task.Execute (System.VoidHandler,MindTouch.Dream.TaskBehavior) 0x00093 The odd thing is that it appears setting the culture invokes the serializer!?! Our async execution framework sets the culture for all asynchronous operations. Question is, why is it using serialization though? Can I avoid this somehow and still set the culture? Thx. - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] set culture uses serialization?
Zoltan, thanks again for your quick reply. That assumption might be true for desktop applications, but not for a server which runs a localized application. Each request is handled in the website's configured culture. The matter is made even worse when the server tries to be smart and handle the request by using asynchronous operations. Each completion handler must reset the current culture since it it will resume on an arbitrary thread of the thread pool. Maybe I'm going all wrong about this? What is the recommended pattern for running a localized web-application that uses asynchronous operations? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 11:59 AM, Zoltan Varga wrote: Hi, CultureInfo might be inmutable, but its components like NumberFormatInfo are not. Also, even if it is inmutable, objects cannot be shared across appdomains, so we couldn't use the object set by the application in another domain. We assume that the thread culture is set only rarely, so the serialization overhead should not be a problem. Zoltan On Jan 3, 2008 8:37 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Well, the application runs in 10 different languages simultaneously. So, this is only going to help in a few cases. In other words, I should forget about CurrentCulture and instead use a manual override in all my date and number formatting invocations? That's going to be a major pain... :( Is this how it behaves under .Net as well? I'm really surprised about the behavior since CultureInfo is immutable (afaik). - Steve - Steve G. Bjorg MindTouch 555 W. Beech St. Suite 501 San Diego, CA 92101 619.795.8459x1106 office 619.795.3948 fax 425.891.5913 mobile On Jan 3, 2008, at 11:17 AM, Zoltan Varga wrote: You could try calling Thread.CurrentCulture, compare the return value with the culture you want to set, and only call the setter if the two are different. Zoltan On Jan 3, 2008 6:40 PM, Steve Bjorg [EMAIL PROTECTED] wrote: In short, I cannot change the current culture without incurring the serialization cost, correct? Or am I missing something? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 8:48 AM, Zoltan Varga wrote: Because code in other appdomains might call Thread.CurrentCulture on the same thread object since thread objects are shared between appdomains. Zoltan On Jan 3, 2008 4:30 PM, Steve Bjorg [EMAIL PROTECTED] wrote: Zoltan, thx for response. I can see how serialization applies to app domains, but why would it serialize inside the same app domain? Isn't CultureInfo an immutable object? - Steve -- Steve G. Bjorg http://wiki.mindtouch.com http://wiki.opengarden.org On Jan 3, 2008, at 6:49 AM, Zoltan Varga wrote: Hi, The current culture is shared between appdomains so the runtime stores it in serialized form. Zoltan On Jan 3, 2008 8:21 AM, Steve Bjorg [EMAIL PROTECTED] wrote: I ran into the following error today on our system (note: I truncated the stack for legibility). The interesting part is in bold (prefixed by * in case the formatting got lost) Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS Stacktrace: at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x4 at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x0004c at System.IO.MemoryStream.Write (byte[],int,int) 0x0007a at System.IO.BinaryWriter.Write (string) 0x000c8 at GregorianCalendar__TypeMetadata.WriteTypeData (System.Runtime.Serialization.Formatters.Binary.ObjectWriter,Sy st em .I O.BinaryWriter,bool) 0x0001f at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri te Ob je ct (System.IO.BinaryWriter,long,object) 0x0020d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri te Ob je ctInstance (System.IO.BinaryWriter,object,bool) 0x0014c at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri te Qu eu edObjects (System.IO.BinaryWriter) 0x0002d at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Wri te Ob je ctGraph (System.IO.BinaryWriter,object,System.Runtime.Remoting.Messagin g. He ad er[]) 0x0003a at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter. Se ri al ize (System.IO.Stream,object,System.Runtime.Remoting.Messaging.Head er []) 0x00206 * at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter. Se ri al ize (System.IO.Stream,object) 0x00015 * at System.Threading.Thread.set_CurrentUICulture (System.Globalization.CultureInfo) 0x00056 at
Re: [Mono-dev] [Mono-docs-list] Can not checkout trunk on windows
Ok, now the checkout works perfectly. I inform you when ive got the next problem ;-) Steve Jonathan Pryor schrieb: This file has been removed. Any other issues with a Win32 checkout? - Jon On Wed, 2008-01-02 at 22:40 +0100, Steve Wagner wrote: Sorry but it isnt totaly solved. Now ive got the following error: Cant check out path 'C:\mono-svn\monodoc\class\System.Web\en\System.Web\c__CompilerGenerated2+c__CompilerGenerated13.xml': Bad syntax for filename, directoryname or drivename * This is free text translated from german windows Steve Jonathan Pryor schrieb: On Wed, 2007-12-26 at 10:32 -0500, Miguel de Icaza wrote: Suggestions? All I can suggest is that namespace XML files should contain some character/string that namespaces are highly unlikely to contain, e.g. instead of en/System.xml for the XML documentation on the System namespace, use en/Namespace-System.xml. Any such character/string *must* be usable on Windows, so no ':' or similar characters can be used. We should add support for a different name like: ns-System.xml And then we can rename the files for the docs that we maintain. This has been done. Mike Kestner suggested using a namespaces.xml file; I chose not to do this as it made the migration of monodocer/monodocs2html/ecma-provider easier. And keep the old code for documentation that might be out that has not been updated by us. Monodoc will currently look for the older filename and rename accordingly; ecma-provider will check for both, with a preference for the non ns-prefixed name. monodocs2html currently requires the ns- prefixed files, as I couldn't think of an easy way to do the fallback within the XSLT. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [SPAM] Re: [PATCH] Implement support for .emitbyte directive onilasm
Thanks for spoting the typo Andreas. On Jan 2, 2008 2:37 PM, Andreas Nahr [EMAIL PROTECTED] wrote: Any reason why the class is named EmitByteIntr instead of EmitByteInstr ? -- *Von:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *Im Auftrag von *Rodrigo Kumpera *Gesendet:* Sonntag, 30. Dezember 2007 19:58 *An:* mono-devel-list@lists.ximian.com; Ankit Jain *Betreff:* [SPAM] Re: [Mono-dev] [PATCH] Implement support for .emitbyte directive onilasm Forgot to attach EmityteInst.cs. On Dec 30, 2007 4:50 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote: The attached patch implements support for the .emitbyte directive. Please review it. Thanks, Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace in Mono revisited
It does make sense to make the 'DblExpTab' common to all appdomains. How do you implement such a scheme in Mono? Is it possible to achieve this without going out to unsafe code and internal methods? Afaik to gain all the advantages you need one internal method to return the pointers and unsafe code for accepting the pointer. The scheme is pretty straightforward (compare Char or CultureInfo): Runtime: * Pregenerate the table data * convert to a C constant array * embed that into the runtime (e.g. http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metadata/culture-inf o-tables.h?rev=88796view=auto) * Create one runtime method to return a pointer to the array Classlib: * Define internalcall to the runtime method * Store the retrieved pointer in a static variable * Use the pointer as you would use the array (syntax is compatible, so no need to change the code) * Get Array-Bounds-Check-Removal for free :) If the above is complicated, do you think that it makes sense to consider the above as a separate task since the array size is now 24K and a scenario with 1000 domains is a rare scenario? Well I personally am much more concerned about the additional startup cost of the current suggestion (Managed already has a high startup cost and this is measurably increasing it) than the additional memory cost. But not everybody will think that way... So imho it would be worth implementing in the runtime. Greetings Andreas P.S. WAY back then I tried to do the same without runtime support by acquiring a pointer to an embedded resource file. I don't know if this works now, but back then it didn't (as far as I can remember). A starting point MIGHT be Assembly.GetManifestResourceInternal ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] trying to compil moon
hey, thank's sorry for the latter respons, i spend holliday at reunion island (very far from france). In fact i try with the latest rpm from MDV in first, after this error i uninstall them and install expat directly from oficial source (configure make make install), and then post here. I'm go back in france in 2 week in an half ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Looking for an mplayer (or similar) wrapper
On Jan 3, 2008 8:10 AM, Miguel de Icaza [EMAIL PROTECTED] wrote: Wasn't Gstreamer# died? BTW, there's also a very interesting discussion on Banshee list about doing a replacement: MonoMedia [1]. Aaron did some work on GStreamer# which was significantly cleaned up, but as far as I know, the code is burried under some subdirectory somewhere because he felt it was not ready for public consumption. http://anonsvn.mono-project.com/viewcvs/branches/abock/gstreamer-sharp/ The last theoretical problem/issue I remember with gst-sharp was related to how to handle dynamic elements vs. static bindings you need to have for them. I don't think it was ever solved but maybe Aaron knows more. -- Michael. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] NET S3 client
Hi! I have written a Amazon S3 client for NET and would like to release it for use to the community. It is IMHO better then the Amazon one as it handles Streams not byte arrays, foolows Net naming conventions and is generally cleaner code. Is there an established place for third party Mono libs? I remember there once was a debate about that, but AFAIR it never came to a conclusion (but maybe I missed something). Will you (the mono team) be interested in that as a new lib in the mono bundle (like Mono.S3 for example). I will be happy to hear from you, what's the best way to go. Best regards, Michał Ziemski ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Speed difference Windows - Linux
Hi, I have a speed problem with Mono 1.2.6 I have to sort ListString with 88 000 records (Bulgarian and English words) on Windows Mono sort it for about 5 seconds but on Linux it takes at least 30 - 40 seconds. I think Mono have to use same algorithm for sorting? begin:vcard fn:Ventsislav Mladenov n:Mladenov;Ventsislav adr:;;;Slivnitsa;Sofia;2200;Bulgaria email;internet:[EMAIL PROTECTED] tel;cell:+359878682762, +359888990488 x-mozilla-html:TRUE version:2.1 end:vcard ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Speed difference Windows - Linux
Hi, Are you using the same version of the mono runtime on both your windows box and linux box? The sorting algorithm should be the same, so if there's a difference in performance, it's from something else. Also, if you can create a testcase which easily demonstrates the problem, it'd make things easy to debug. Alan. On Jan 2, 2008 10:22 PM, Ventsislav Mladenov [EMAIL PROTECTED] wrote: Hi, I have a speed problem with Mono 1.2.6 I have to sort ListString with 88 000 records (Bulgarian and English words) on Windows Mono sort it for about 5 seconds but on Linux it takes at least 30 - 40 seconds. I think Mono have to use same algorithm for sorting? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] How to add a combobox to a toolbar
Hi, Can someone please help me. i need to add a combobox to a toolbar using stetic but i'm new to monodevelop and i have no clue. thanks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to add a combobox to a toolbar
well I dont know about Stetic, because I dont use MonoDevelop, but in code its pretty easy. Toolbar tb = new Toolbar(); ComboBox cb = ComboBox.NewText(); tb.Add(cb); On Jan 2, 2008 7:52 PM, Darwin Reynoso [EMAIL PROTECTED] wrote: Hi, Can someone please help me. i need to add a combobox to a toolbar using stetic but i'm new to monodevelop and i have no clue. thanks ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
Congratulations on the release! On 1/2/08, William Lahti [EMAIL PROTECTED] wrote: PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? Yes, slight problem with the server, all fixed now. andreia gaita ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
Am 03.01.2008 um 19:18 schrieb Andreia Gaita: On 1/2/08, William Lahti [EMAIL PROTECTED] wrote: PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? Yes, slight problem with the server, all fixed now. Sounds familiar ... same trouble 2006. ;) Andreas ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
Yes indeed, I'm excited to see JIT part of the kernel. Careful, MS will steal that idea. lol There has been some serious discussions around here on how your building an OS with 100% C#. Your own compiler to translate C# to asm is the best guess. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreia Gaita Sent: Thursday, January 03, 2008 12:19 PM To: William Lahti Cc: mono-list@lists.ximian.com Subject: Re: [Mono-list] SharpOS 0.0.1 Release Congratulations on the release! On 1/2/08, William Lahti [EMAIL PROTECTED] wrote: PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? Yes, slight problem with the server, all fixed now. andreia gaita ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
I'm very impresionate... o.O And... congratulations, i never guess that C# should be able to build an operating system. When i get a some of free time, i will try it. Hopefully that Sharp OS to become a great project. Again, congratulations. And follow the suggestion of Gavin Landon: Be careful, because M$ will steal that idea. Take the precautions that corresponds. Best regards. 2008/1/2, William Lahti [EMAIL PROTECTED]: 'm happy to announce that we have released version 0.0.1 of SharpOS, including our AOT compiler and a basic kernel with an interactive shell. This is a proof of concept release intended to gather awareness, support and participation from community members, so if you are interested in working on this project we encourage you to sign up for our mailing list. For those of you who don't know about SharpOS, it is a project to write an operating system purely in C#, which was actually spawned from the Operating system in C# thread on mono-devel-list. Although we don't have object instantiation or meta data embedding in our kernel yet, the release proves clearly that the concept is possible. Our next milestone focuses on supporting managed code in the kernel, as well as using that managed code to improve our current systems as much as possible. Our wiki and project management suite is at http://sharpos.org/. Our file releases area at SourceForge (http://sourceforge.net/project/platformdownload.php?group_id=196652) contains tarballs and zips with source code, binaries, and disk images for testing. We've also got ISO images for trying SharpOS on real computers (that don't have floppy drives, that is), as well as the usual configurations for Bochs, VMWare, and Virtual PC. And have a wonderful new year everyone! PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
Well, MS already has that Singularity project... Or whatever it's called... V. Daniel Soto wrote: I'm very impresionate... o.O And... congratulations, i never guess that C# should be able to build an operating system. When i get a some of free time, i will try it. Hopefully that Sharp OS to become a great project. Again, congratulations. And follow the suggestion of Gavin Landon: Be careful, because M$ will steal that idea. Take the precautions that corresponds. Best regards. 2008/1/2, William Lahti [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 'm happy to announce that we have released version 0.0.1 of SharpOS, including our AOT compiler and a basic kernel with an interactive shell. This is a proof of concept release intended to gather awareness, support and participation from community members, so if you are interested in working on this project we encourage you to sign up for our mailing list. For those of you who don't know about SharpOS, it is a project to write an operating system purely in C#, which was actually spawned from the Operating system in C# thread on mono-devel-list. Although we don't have object instantiation or meta data embedding in our kernel yet, the release proves clearly that the concept is possible. Our next milestone focuses on supporting managed code in the kernel, as well as using that managed code to improve our current systems as much as possible. Our wiki and project management suite is at http://sharpos.org/. Our file releases area at SourceForge ( http://sourceforge.net/project/platformdownload.php?group_id=196652) contains tarballs and zips with source code, binaries, and disk images for testing. We've also got ISO images for trying SharpOS on real computers (that don't have floppy drives, that is), as well as the usual configurations for Bochs, VMWare, and Virtual PC. And have a wonderful new year everyone! PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
Before people go off on a huge tangent about how MS are going to steal the idea, you've already stolen theirs ;) http://en.wikipedia.org/wiki/Singularity_(operating_system) Still, it's an interesting project. Alan. On Jan 3, 2008 7:23 PM, Daniel Soto [EMAIL PROTECTED] wrote: I'm very impresionate... o.O And... congratulations, i never guess that C# should be able to build an operating system. When i get a some of free time, i will try it. Hopefully that Sharp OS to become a great project. Again, congratulations. And follow the suggestion of Gavin Landon: Be careful, because M$ will steal that idea. Take the precautions that corresponds. Best regards. 2008/1/2, William Lahti [EMAIL PROTECTED]: 'm happy to announce that we have released version 0.0.1 of SharpOS, including our AOT compiler and a basic kernel with an interactive shell. This is a proof of concept release intended to gather awareness, support and participation from community members, so if you are interested in working on this project we encourage you to sign up for our mailing list. For those of you who don't know about SharpOS, it is a project to write an operating system purely in C#, which was actually spawned from the Operating system in C# thread on mono-devel-list. Although we don't have object instantiation or meta data embedding in our kernel yet, the release proves clearly that the concept is possible. Our next milestone focuses on supporting managed code in the kernel, as well as using that managed code to improve our current systems as much as possible. Our wiki and project management suite is at http://sharpos.org/. Our file releases area at SourceForge ( http://sourceforge.net/project/platformdownload.php?group_id=196652) contains tarballs and zips with source code, binaries, and disk images for testing. We've also got ISO images for trying SharpOS on real computers (that don't have floppy drives, that is), as well as the usual configurations for Bochs, VMWare, and Virtual PC. And have a wonderful new year everyone! PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? -- fury long name: William Lahti handle :: fury freenode :: xfury blog :: http://xfurious.blogspot.com/ ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] trying to compil moon
hey, thank's sorry for the latter respons, i spend holliday at reunion island (very far from france). In fact i try with the latest rpm from MDV in first, after this error i uninstall them and install expat directly from oficial source (configure make make install), and then post here. I'm go back in france in 2 week in an half ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] SharpOS 0.0.1 Release
William Lahti escribió: 'm happy to announce that we have released version 0.0.1 of SharpOS, including our AOT compiler and a basic kernel with an interactive shell. This is a proof of concept release intended to gather awareness, support and participation from community members, so if you are interested in working on this project we encourage you to sign up for our mailing list. For those of you who don't know about SharpOS, it is a project to write an operating system purely in C#, which was actually spawned from the Operating system in C# thread on mono-devel-list. Although we don't have object instantiation or meta data embedding in our kernel yet, the release proves clearly that the concept is possible. Our next milestone focuses on supporting managed code in the kernel, as well as using that managed code to improve our current systems as much as possible. Our wiki and project management suite is at http://sharpos.org/. Our file releases area at SourceForge (http://sourceforge.net/project/platformdownload.php?group_id=196652) contains tarballs and zips with source code, binaries, and disk images for testing. We've also got ISO images for trying SharpOS on real computers (that don't have floppy drives, that is), as well as the usual configurations for Bochs, VMWare, and Virtual PC. And have a wonderful new year everyone! PS: I've had a lot of trouble posting to the list because Postfix says the dates on the email are in the future?? I'm curious, do you have rough numbers about performance loss compared to a non-managed OS like Linux (I guess the difference is huge right now, but what do you think you can reach if it begins to get optimized?). BTW, does this approach have the advantage of a micro-kernel safe approach or is it only safe from the point of view of memory leaks (thanks to the garbage collector)? Thanks in advance, and congratulations for this great project. Andrés [ knocte ] -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
