Re: [Mono-devel-list] How to handle huge string collation resources?
Hi, >> Cant the same be said about the table that Atsushi is creating? Do we >> really worry about the 200k replicated between Mono and libmono.so. > > Not too much ;-). Well, it might make a difference if on the same box > somebody is using mono and libmono.so -- but not a big issue. They are not only 200KB tables (that number is just for CJK support which is rarely required) but about 500KB as a whole. > I've no idea what kind of data is in the table, and if it is endian > dependent. If it's just a byte array, we'd be fine... Well, I need more clarification for them. - For standard collation support (numbers are in length): - byte[] : 153360. - int[] : 13552. - some extent of additional byte[] : maybe less than 5000 - for CJK support which is rarely used: - ushort[] : 2 * 3 + 3 - byte[] : 2 - for String.Normalize() which is only for .NET 2.0: - byte[] : 3 - int[] : 2700 - short[] : 17600 - maybe additional int[] : 4000 So, they are mostly byte for collation, except for CJK support which is not referenced unless we use CompareInfo methods from CJK cultures. So I think managed resources won't be bad here. For String Normalization related stuff, I still think it would be better to have them in mscorlib.dll since they are unused in the default profile. > If we want to include the stuff in the C runtime, we pretty much have to > check in the generated file to SVN. We can't run C# code before the > runtime is compiled. OTOH, if we include the stuff as a managed resource > to corlib, we could run a mono app at that point to generate the file. > > While this stuff is in active development, checking in a large file to > svn is probably going to make mono-patches-list a bit annoying. I agree. > So maybe the best plan would be a managed resource for now, and once the > table is stable, moving it into C if that makes a substantial > performance difference. Ok, then right now I need to hack on corlib Makefile to run make under Mono.Globalization.Unicode. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
I believe the answer is no, you have to install Mozilla. Martin On 6/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > When I launch Monodevellop, I get this message : > > which: no mozilla in > (/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/maitrebn/bin) > Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to > your > mozilla directory > > ... > > Is there a way to use Monodevelop with FireFox ? > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > -- Martin Hinks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Patch for standardizing Mainsoft DataSetTest tests for System.Data
Eyal Alaluf wrote: Hi, all. The attached patch replaces the Mainsoft System.Data.DataSet tests with a standardized Mono tests style test - collecting a lot of separate per-method test classes into one test class that tests DataSet. One issue that I'd like to mention is that I used as namespace 'MonoTests_System.Data' rather then 'MonoTests.System.Data' for the test. The reason is that ptherwise code like the following: System.Text.StringBuilder resultXML = new System.Text.StringBuilder(); does not compile. It gives the error Test\System.Data\DataSetTest2.cs(350,11): error CS0234: The type or namespace name 'Text' does not exist in the class or namespace 'MonoTests.System' (are you missing an assembly reference?) The problem is that the compiler interprets the use of 'System' as MonoTests.System and not as the root 'System'. I consider adding a using directive and not using a full scope as a workaround to the problem and not a solution. IMO, "using" is the right solution as we have not used full scoped classes anywhere in other tests. "StringBuilder resultXML = new StringBuilder();" is simpler than full scoped one. Apart from that, feel free to commit. suresh. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
From: Miguel de Icaza The patch only has one bug as it stands today: it uses a double check lock, which is race prone: if (x == null){ lock (...){ if (x == null){ x = Allocate (); } } } The actual code: private static ResourceManager GetResourceManager () { if (resources == null) lock (resourcesLock) { if (resources == null) resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName ().Name, typeof (Locale).Assembly); } return resources; } I think this is good, because it is intended to initialize resources only once. I did not wanted to use static constructor because of the thing explained in the source code. (I don't want any TypeInitializationException, and it even could not be catched by SafeGetText) If resources is already initialized it does not lock at all that results in faster execution. But the second check is required because when two threads are waiting to acrique resourcesLock one of the will initialize resources while the other should not replace the existing one. If you still think that this is a race prone, please tell me why because I don't know the reason. I have a few more questions: what happens if a translation does not exist, or a catalog does not exist, do we have a fast-path? So probably that variable needs to be allocated statically. The ResourceManager does not load anything at the time of construction. It loads ResourceSets when they are needed by a GetString or GetObject call. Furthermore it falls back to InvariantCulture whose ResourceSet is GetTextResourceSet that simply retrurns the string passed as argument and uses no Hashtable to cache string resources. It's better to use a custom ResourceSet because this let us to take advantage all the features of ResourceManager. Also, to apply this kind of patch that will affect everything, I would like to know in advance the memory footprint (running mono --profile before/after should tell us this) and how much extra code is JITed at startup (how much slower this becomes for a sample program). I agree with Ben that string are localized only several time and the little performance overhead caused by localization can be ignored. (The overhead should be little.) And also note that currently there will be little difference because there are no other languages just English that is in the code of assemblies so not caching will be done. MWF uses object resources as well but it will not result in overhead because it currently uses the same ResourceManager and ResourceSet that will be used by this Locale.cs. And as I told several times in this topic the current ResourceSet is not efficient. ResourceManager of MS.NET uses a custom resource set called RuntimeResourceSet (private type, ResourceSet of MS.NET does the same as Mono's one) that loads each resource (either string or object) when it is needed instead of loading all of them at construction. It caches resource once they was loaded. This could be used in Mono as well or if we want we could use a ResourceSet that does no caching at all. But the advantages and disadvantages of using no cache should be compared in real life before making a decission. Note that the above problem will not cause any CPU or memory overhead yet because we have only English texts yet without .resources files. Am starting to understand your point of view on the translation technique, and it might be worth switching to the key/string translation scheme. It's good.:) By the way, the most important thing: key/string technique will have the same performance and memory requirements if you use the same ResourceManager and ResourceSet classes. The only difference will be that it will look up even English resources in a file that means some performance overhead but I think it's so little that it can be ignored. The problem of resource caching is the same for both techniques: If you cache resources they will be faster to retrieve the next time but will need memory to cache them. And of course neither of these techniques require caching at all. And of course ResourceManager can use both techniques. Andreas Nahr was talking about a custom infrastructure instead of ResourceManager but I think it's useless to use different resource format because .resources files are efficient. The most important difference is that while identifiers are permanent English texts may change that requires new satellite assemblies for all of the languages altough the texts of the other languages are not changed. From: Ben Maurer Anyways, the biggest source of jit'ing that i can see in that code is due to: typeof (Locale).Assembly.GetName ().Name Which, IIRC does a relatively wide range of stuff. This is required to can use the same name for .resources file as the assembly has. If you have a better code please let me know. By the way this is called only once so I think if it has no critical drawbacks it's not a big problem. Kornél ___ Mono-devel-list mai
Re: [Fwd: Re: [Mono-devel-list] System.Data.DataSet.ReadXml reimplementation]
Hi Eno, I made the changes we talked about, bt it turns out they probably won't make a big diff (see attached patch) The problem is that I have to collect almost always: XmlReadMode.InferSchema: in order to be able to skip if "schema" is found. XmlReadMode.Auto: as I don't know what's gonna be. XmlReadMode.DiffGram: wait for diffgram - very uncommon case, but have a test (MonoTests.System.Data.DataSetTest.ReadWriteXmlDiffGram). XmlReadMode.IgnoreSchema: to be able to ignore the schema if it's found. From the other side in most cases the schema or diffgram element will be as root or its child, so nothing would be collected anyway. Regards, Konstantin Triger Atsushi Eno wrote: Hello Konstantin, Konstantin Triger wrote: Hi Eno, I committed the code before I saw your comments on Boris email. Actually I missed it at all and Boris forwarded it to me. In any case I didn't want to ignore it and would like, with your help, create the best implementation possible. The new implementation solves some bugs, little bit cleaner as it does not have "gotos", but performs worse. I think that with a very small effort it can perform better. I really need your help to make this change safe. Can you please give your opinion on an assumption that right after the schema must reside data? If you agree, with a small change I can make a real perf improvement and we will have a really better implementation. I don't think you could quote my post without seeing it. Anyways, Am not seeing what you see. Maybe it would be the best if you post testcases that shows why the patch is required. Next, the patch has several changes in one file. There are things that could be justified and that might not be. They do not look tied together, so it is better if they are split. Without them I don't think any of discussions can go efficiently. Depending on the testcases that performant way might not be possible. As long as I know MS.NET implementation is so cheap that always reads document into DOM or something. If XML schema is the document root, then there is no data content. Existing implementation did handle content schema (at least it was designed to do that) as long as it is the top-level content of the document element. I am not aware of practical cases that such schemas in further depth are consumed (since 99.999% of .NET DataSet users is not likely to have such documents). Atsushi Eno Index: System.Data/DataSet.cs === --- System.Data/DataSet.cs (revision 46217) +++ System.Data/DataSet.cs (working copy) @@ -1023,9 +1023,17 @@ continue; } - //collect data - XmlNode n = doc.ReadNode(reader); - root.AppendChild(n); + if (mode == XmlReadMode.InferSchema || + mode == XmlReadMode.Auto || + mode == XmlReadMode.DiffGram || + mode == XmlReadMode.IgnoreSchema) { + //collect data + XmlNode n = doc.ReadNode(reader); + root.AppendChild(n); + continue; + } + + XmlDataReader.ReadXml (this, reader, mode); } if (reader.NodeType == XmlNodeType.EndElement) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Bug# 73737
Hi, Am working on Bug# 73737 and implementing PrinterSttings class. In some of the methods like GetHdevmode() and SetHdevmode() etc the method has to return DEVMODE handle. Whether I need to add unmanaged code in these method implementation? _ 44 Million Items on Sale.What Are you Looking for? http://adfarm.mediaplex.com/ad/ck/4686-26272-10936-377?ck=44MilItems Find it on eBay.in! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Character encoding problem
I have an issue with accentued characters encoding (in french) in APS.NET I've a little VS 2003 Project attached ... With MS.NET the result is : Label Dynamique : accent aigu : é accent grâve è Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR With mono, i get : Label Dynamique : accent aigu : é accent grâve è Statique: Accents : éèê Label HTML : Accents : éèèèê fr-FR In my web.config I specify : Apparently : i get problems only with accent in aspx pages. The dynamically generated accents are correctly encoded in utf-8. It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly Thank ___ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. testaccents.tar.gz Description: application/tgz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Character encoding problem
Le Jeudi 23 Juin 2005 13:16, vous avez écrit : > Hubert FONGARNAND a écrit : > >I have an issue with accentued characters encoding (in french) in APS.NET > >I've a little VS 2003 Project attached ... > >With MS.NET the result is : > > > >Label Dynamique : accent aigu : é accent grâve è > >Statique: Accents : éèê > >Label HTML : Accents : éèèèê > >fr-FR > > > >With mono, i get : > > > >Label Dynamique : accent aigu : é accent grâve è >requestEncoding="utf-8" > >responseEncoding="utf-8" > >fileEncoding="iso-8859-1" > > /> > >Statique: Accents : éèê > >Label HTML : Accents : éèèèê > >fr-FR > > > >In my web.config I specify : > > >requestEncoding="utf-8" > >responseEncoding="utf-8" > >fileEncoding="iso-8859-1" > >culture="fr-FR" > > /> > > > >Apparently : i get problems only with accent in aspx pages. The > > dynamically generated accents are correctly encoded in utf-8. > >It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly > > > >Thank > > Avec le mini serveur xsp de Mono j'optiens les caractères correctement. > Si tu utilises mod_mono pour apache, cela vient de Apache qui sort > toujours le même encodage par défaut. Regardes dans httpd.conf > Cordialement > I'm not using apache, but XSP with the last SVN version of mono. This program should work with mono 1.1.7 but it doesn't with the SVN version. I've tried on another PC with mono 1.1.8.1 and it fails too... NB: essai de parler anglais, pour que les autres puissent comprendre... ___ Ce message et les éventuels documents joints peuvent contenir des informations confidentielles. Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[mono-devel-list] Patch to standardize Mainsoft DataSet tests
Hi, all. Attched is a patch (gzipped so it won't be too big) that collects the various data set tests from Mainsoft (we had one test class per method) into one test class. One issue I'd like to mention is that I used 'MonoTests_System.Data' namespace instead of 'MonoTests.System.Data' since when using code like: System.Text.StringBuilder resultXML = new System.Text.StringBuilder(); I get the following error: Test\System.Data\DataSetTest2.cs(350,11): error CS0234: The type or namespace name 'Text' does not exist in the class or namespace 'MonoTests.System' (are you missing an assembly reference?) The problem is that the compiler understands 'System' as 'MonoTests.System'. Trying 'MonoTests.System_Data' didn't work either since it was enough that once file uses 'MonoTests.System.Data' to cause the error. I consider removing the full scope usage and adding a 'using' directive as a workaround, since this problem can happen to any test developer. Any coments are welcome. I'd like move ahead as soon as possible since I'd like to standradize the other disconnected tests we contributed. Eyal. patch.diff.gz Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
On Thu, 2005-06-23 at 11:18 +0200, Kornél Pál wrote: > private static ResourceManager GetResourceManager () > { > if (resources == null) > lock (resourcesLock) { >if (resources == null) > resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName > ().Name, typeof (Locale).Assembly); > } > return resources; > } > > I think this is good, because it is intended to initialize resources only > once. It looks good. It acts good. It isn't good. See: http://galactus.ximian.com/pipermail/mono-devel-list/2004-February/004101.html http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx In short, it will work correctlyon x86. *Maybe* on other processors. But it won't work *everywhere*. The problem is that the memory model that the CLI defines has looser semantics than x86 provides, so you can't actually hit the race condition on x86, but it will exist on Itanium (I think). Where's the race? It's between the processor, cache, and main memory on a multi-CPU machine. Dragons be there; be afraid. :-) There are four solutions: - Make `resources' `volatile', which disables any caching the processor might do. This effectively makes reads & writes a memory barrier operation, slowing things down - Always acquire a lock before reading `resources' -- also slow, due to the locking required. - If it's safe to create multiple instances of GetTextResourceManager, you could use an Interlocked.CompareExchange to set `resource' for lock-free thread-safe code. See: http://mono.myrealbox.com/source/trunk/mcs/class/System/System.Diagnostics/TraceImpl.cs And search for `#if !NO_LOCK_FREE' for an example. - Place `resource' into a different class and use a static constructor. GetResourceManager can then catch for the TypeInitializationException and provide fallback behavior. Personally, I'd go for the static constructor, as it's easier to get right. I think the Interlocked.CompareExchange code is correct (I wrote it), but I'm no lock-free expert, so there may be issues with it (but I did sleep at a Holiday Inn last night. :-) - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] C# Threading : libgcc_s.so.1 must be installed for pthread_cancel to work
Hi,We have mono 1.1.7 installed on Redhat Linux version 9.0. We have implemented a basic threading code in C#. The code is attached at the end of the mail.The output of the code is as follows:The Main() thread calls this after starting the new InstanceCaller thread.The Main () thread calls this after starting the new StaticCaller threads.You are Back in InstanceMethod.Running on Thread Alibgcc_s.so.1 must be installed for pthread_cancel to workWe get an error something related to pthread_cancel.We wrote a sample code in C which invokes pthread_cancel. The program works fine.We have the following under our PATH and LD_LIBRARY_PATH respectively/usr/bin:/usr/bin:/usr/bin:/usr/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/lib:/usr/lib:..:/usr/tibco/tibrv/lib:/lib:/usr/libwe have libgcc_s.so.1 already installed.Please suggest us what we need to do.Best RegardsPrashanth Kalvala---Thread.cs---using System;using System.Threading;namespace Test{ public class Simple { // The method that will be called when the thread is started. public void InstanceMethod() { try { // Pause for a moment to provide a delay to make threads more apparent. Thread. Sleep(3000); Console.WriteLine ("You are Back in InstanceMethod.Running on Thread A"); } catch(Exception ex) { Console.WriteLine ("asdasdadasd"); } } public static void StaticMethod() { Console.WriteLine("You are in StaticMethod. Running on Thread B."); // Pause for a moment to provide a delay to make threads more apparent. Console.WriteLine("Thread B Going to Sleep Zzzz"); Thread.Sleep(5000); Console.WriteLine("You are back in static method. Running on Thread B"); } public void Run() { // Create the thread object, passing in the // serverObject.InstanceMethod method using a ThreadStart delegate. Thread InstanceCaller = new Thread(new ThreadStart(InstanceMethod)); // Start the thread. InstanceCaller.Start(); Console.WriteLine("The Main() thread calls this " + "after starting the new InstanceCaller thread."); } public static int Main(String[] args) { Console.WriteLine ("Thread Simple Sample"); new Simple().Run(); // Create the thread object, passing in the // serverObject.StaticMethod method using a ThreadStart delegate. //Thread StaticCaller = new Thread(new ThreadStart(ServerClass.StaticMethod)); // Start the thread. //StaticCaller.Start(); Console.WriteLine("The Main () thread calls this " + "after starting the new StaticCaller threads."); return 0; } }} Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] [PATCH] Reworked unified Locale classes
Hi all, > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Jonathan Pryor > > There are four solutions: > > - Make `resources' `volatile', which disables any caching the > processor might do. This effectively makes reads & writes > a memory barrier operation, slowing things down > > - Always acquire a lock before reading `resources' -- also > slow, due to the locking required. > > - If it's safe to create multiple instances of > GetTextResourceManager, you could use an > Interlocked.CompareExchange to set `resource' for lock-free > thread-safe code. See: > > > http://mono.myrealbox.com/source/trunk/mcs/class/System/System > .Diagnostics/TraceImpl.cs > > And search for `#if !NO_LOCK_FREE' for an example. > > - Place `resource' into a different class and use a static > constructor. GetResourceManager can then catch for the > TypeInitializationException and provide fallback behavior. How about using Thread.MemoryBarrier how it's been suggested in Brad Abrams' blog: http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx Is this supposed to work on Mono? Joerg. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Character encoding problem
On Thu, 2005-06-23 at 13:06 +0200, Hubert FONGARNAND wrote: > I have an issue with accentued characters encoding (in french) in APS.NET > I've a little VS 2003 Project attached ... > With MS.NET the result is : > > Label Dynamique : accent aigu : é accent grâve è > Statique: Accents : éèê > Label HTML : Accents : éèèèê > fr-FR [...] > Apparently : i get problems only with accent in aspx pages. The dynamically > generated accents are correctly encoded in utf-8. > It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly It was a regression in CodeDom. Before June 11th, it used Encoding.UTF8 when writing its temporary files, but a patch that day removed the encoding accidentally. It's fixed in svn now. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Windows shares and FileStream
Hi, Does the FileStream class support file shares of this type "\\computer\share\file". I think not? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] configure.in patch
Continuing on with x86 Darwin work; any major objections to this: Index: configure.in === --- configure.in(revision 46409) +++ configure.in(working copy) @@ -1524,7 +1524,7 @@ libsuffix=".so" case "$host" in - powerpc-*-darwin*) + *-*-darwin*) libsuffix=".dylib" LIBC="libc.dylib" INTL="libintl.dylib" -kangaroo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
I think there is a way. Just set MOZILLA_FIVE_HOME environment variable to path where you have Firefox. Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): > I believe the answer is no, you have to install Mozilla. > > Martin > > On 6/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > > > When I launch Monodevellop, I get this message : > > > > which: no mozilla in > > (/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/maitrebn/bin) > > Cannot find mozilla installation directory. Please set MOZILLA_FIVE_HOME to > > your > > mozilla directory > > > > ... > > > > Is there a way to use Monodevelop with FireFox ? > > > > ___ > > 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-devel-list] MonoDevelop : looking for mozilla
Hi No it is not possible to use firefox, firefox is compiled in static mode, and gecko-sharp needs a shared compiled mode. Witch mozilla is. /Mikkel > I think there is a way. Just set MOZILLA_FIVE_HOME environment variable > to path where you have Firefox. > Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): >> I believe the answer is no, you have to install Mozilla. >> >> Martin >> >> On 6/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > When I launch Monodevellop, I get this message : >> > >> > which: no mozilla in >> > (/usr/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin/:/usr/games:/home/maitrebn/bin) >> > Cannot find mozilla installation directory. Please set >> MOZILLA_FIVE_HOME to your >> > mozilla directory >> > >> > ... >> > >> > Is there a way to use Monodevelop with FireFox ? >> > >> > ___ >> > 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-devel-list] Character encoding problem
Le Jeudi 23 Juin 2005 15:07, Gonzalo Paniagua Javier a écrit : > On Thu, 2005-06-23 at 13:06 +0200, Hubert FONGARNAND wrote: > > I have an issue with accentued characters encoding (in french) in APS.NET > > I've a little VS 2003 Project attached ... > > With MS.NET the result is : > > > > Label Dynamique : accent aigu : é accent grâve è > > Statique: Accents : éèê > > Label HTML : Accents : éèèèê > > fr-FR > > [...] > > > Apparently : i get problems only with accent in aspx pages. The > > dynamically generated accents are correctly encoded in utf-8. > > It seems that the conversion iso-8859-1 to utf-8 doesn't work correctly > > It was a regression in CodeDom. Before June 11th, it used Encoding.UTF8 > when writing its temporary files, but a patch that day removed the > encoding accidentally. > > It's fixed in svn now. Ok there's no more problems for labels... but, I'm sorry but this bug is not yet closed... Maybe it's another problem but... I'm working for DropDownList in ASP.NET On MS.NET the compiled html is : Accent aigu : é Accent grâve : è On Mono the compiled html is : Accent aigu : ﴁ Accent grﳺve : ﴀ There's two problems in fact: the html encoding is bad and the value parameter is bad encoded... See my attachment > > -Gonzalo > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Ce message et les �ventuels documents joints peuvent contenir des informations confidentielles. Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce message non conforme � sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite. Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour responsable de son contenu. testaccents.tar.gz Description: application/tgz ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Fwd: Re: [Fwd: Re: [Mono-devel-list] System.Data.DataSet.ReadXml reimplementation]]
Hi Eno, I don't see it in mailing list so resending. I made the changes we talked about, bt it turns out they probably won't make a big diff (see attached patch) The problem is that I have to collect almost always: XmlReadMode.InferSchema: in order to be able to skip if "schema" is found. XmlReadMode.Auto: as I don't know what's gonna be. XmlReadMode.DiffGram: wait for diffgram - very uncommon case, but have a test (MonoTests.System.Data.DataSetTest.ReadWriteXmlDiffGram). XmlReadMode.IgnoreSchema: to be able to ignore the schema if it's found. From the other side in most cases the schema or diffgram element will be as root or its child, so nothing would be collected anyway. Regards, Konstantin Triger Atsushi Eno wrote: Hello Konstantin, Konstantin Triger wrote: Hi Eno, I committed the code before I saw your comments on Boris email. Actually I missed it at all and Boris forwarded it to me. In any case I didn't want to ignore it and would like, with your help, create the best implementation possible. The new implementation solves some bugs, little bit cleaner as it does not have "gotos", but performs worse. I think that with a very small effort it can perform better. I really need your help to make this change safe. Can you please give your opinion on an assumption that right after the schema must reside data? If you agree, with a small change I can make a real perf improvement and we will have a really better implementation. I don't think you could quote my post without seeing it. Anyways, Am not seeing what you see. Maybe it would be the best if you post testcases that shows why the patch is required. Next, the patch has several changes in one file. There are things that could be justified and that might not be. They do not look tied together, so it is better if they are split. Without them I don't think any of discussions can go efficiently. Depending on the testcases that performant way might not be possible. As long as I know MS.NET implementation is so cheap that always reads document into DOM or something. If XML schema is the document root, then there is no data content. Existing implementation did handle content schema (at least it was designed to do that) as long as it is the top-level content of the document element. I am not aware of practical cases that such schemas in further depth are consumed (since 99.999% of .NET DataSet users is not likely to have such documents). Atsushi Eno -- Regards, Konstantin Triger Index: System.Data/DataSet.cs === --- System.Data/DataSet.cs (revision 46217) +++ System.Data/DataSet.cs (working copy) @@ -1023,9 +1023,17 @@ continue; } - //collect data - XmlNode n = doc.ReadNode(reader); - root.AppendChild(n); + if (mode == XmlReadMode.InferSchema || + mode == XmlReadMode.Auto || + mode == XmlReadMode.DiffGram || + mode == XmlReadMode.IgnoreSchema) { + //collect data + XmlNode n = doc.ReadNode(reader); + root.AppendChild(n); + continue; + } + + XmlDataReader.ReadXml (this, reader, mode); } if (reader.NodeType == XmlNodeType.EndElement) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Default:ChangeType, MonoType, dynamically loaded assemblies and MonoCMethod:Invoke on constructors
I'm back in town and have had a chance to look into this issue and it looks like the problem is not related to the assemblies and loading them (which is good news). Is there information about how complete the SortedList class is? I notice a comment in the documentation of 1.1.7 that implied that it was not fully implemented, but that was about it. I am using 1.1.8.1. I would really love to get my hands on MonoDevelop for this version (I've tried to build it but no luck). Thanks for the information. Gary M. Smithrud Haley Systems, Inc. Phone: 724-934-7853 [EMAIL PROTECTED] www.haley.com Moving at the Speed of Change -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Smithrud Sent: Thursday, June 16, 2005 7:55 PM To: mono-devel-list Subject: [Mono-devel-list] Default:ChangeType, MonoType,dynamically loaded assemblies and MonoCMethod:Invoke on constructors I have the following two assemblies that are being loaded dynamically from within an application. In the constructor for a class in the first assembly, it has a parameter that is an instance of a class in the second assembly. When attempting to call the constructor for the first class (using reflection), I get the exception "System.ArgumentException: parameters" (by the way, this exception could really provide more information or the outer one should so that way it is a little easier to track the problem down). Looking at the trace, it looks like the compile MonoType is different than the MonoType for the same class when loading the assembly dynamically (determined this by the tracing/debugging output). The application does not have access to the assemblies when it is built, nor does it know the order in which they are loaded. The first assembly does reference the second one when it is built, of course. In the trace, the object that is passed in the array has the correct type, but the type's are different when they are compared in Default:ChangeType (I do not know what type Mono believes it is, because I have not been able to get Mono-Develop to build. I am not sure that I can get that information from gdb either.) The question is, "Has this been tested and the problem is in my code or does Mono have an issue with this?" Unfortunately, I am leaving town tomorrow and do not have time right now to provide an example. Below is code that sort of shows the issue: using B; namespace A { public abstract class ClassA { ClassC _foo; // In B. double _value; int number; public ClassA(ClassC foo, double value, int number) { _foo = _foo; _value = value; _number = number; } } public ClassB : ClassA { public ClassB(ClassC foo, double value, int number) : base(foo,value,number) { // do whatever } } } namespace B { public ClassC { } } The exception occurs when you pass an instance of B.ClassC to the constructor of ClassB. Thanks for any information (again, I will be out of town until Tuesday, if you have any questions), Gary. ___ 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-devel-list] Character encoding problem
On Thu, 2005-06-23 at 16:45 +0200, Hubert FONGARNAND wrote: > > It's fixed in svn now. > > Ok there's no more problems for labels... > but, I'm sorry but this bug is not yet closed... Maybe it's another > problem but... > I'm working for DropDownList in ASP.NET It's a different problem, so I opened a different bug report for that. Let's followup on that report. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] MonoDevelop : looking for mozilla
Dnia 23-06-2005, czw o godzinie 16:22 +0200, Mikkel Kruse Johnsen napisał(a): > Hi > > No it is not possible to use firefox, firefox is compiled in static mode, > and gecko-sharp needs a shared compiled mode. Witch mozilla is. You mean firefox from www.mozilla.org site? I mean ie. mozilla-firefox package in Ubuntu. In my case it works. (gecko-sharp from svn). I guess mozilla-firefox was compiled to shared binaries. > > > I think there is a way. Just set MOZILLA_FIVE_HOME environment variable > > to path where you have Firefox. > > Dnia 23-06-2005, czw o godzinie 09:49 +0100, Martin Hinks napisał(a): -- Marek Sieradzki <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
Hello, > > Also, to apply this kind of patch that will affect everything, I would > > like to know in advance the memory footprint (running mono --profile > > before/after should tell us this) and how much extra code is JITed at > > startup (how much slower this becomes for a sample program). > > I agree with Ben that string are localized only several time and the little > performance overhead caused by localization can be ignored. (The overhead > should be little.) Yes, but Ben limited himself to speculation. I want to know the real impact (we have the tools, it should take a few minutes at most to find out the numbers). > And as I told several times in this topic the current ResourceSet is not > efficient. ResourceManager of MS.NET uses a custom resource set called > RuntimeResourceSet (private type, ResourceSet of MS.NET does the same as > Mono's one) that loads each resource (either string or object) when it is > needed instead of loading all of them at construction. It caches resource > once they was loaded. This could be used in Mono as well or if we want we > could use a ResourceSet that does no caching at all. But the advantages and > disadvantages of using no cache should be compared in real life before > making a decission. Ah, interesting. Am not familiar with this, but it sounds like we should look into implementing this functionality. > It's good.:) By the way, the most important thing: key/string technique will > have the same performance and memory requirements if you use the same > ResourceManager and ResourceSet classes. The only difference will be that it > will look up even English resources in a file that means some performance > overhead but I think it's so little that it can be ignored. Well, I still want to have numbers at hand so we can make a decision. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
On Thu, 2005-06-23 at 12:16 -0400, Miguel de Icaza wrote: > Hello, > > > > Also, to apply this kind of patch that will affect everything, I would > > > like to know in advance the memory footprint (running mono --profile > > > before/after should tell us this) and how much extra code is JITed at > > > startup (how much slower this becomes for a sample program). > > > > I agree with Ben that string are localized only several time and the little > > performance overhead caused by localization can be ignored. (The overhead > > should be little.) > > Yes, but Ben limited himself to speculation. [EMAIL PROTECTED] corlib]$ find -name \*.cs | xargs grep Locale.GetText | wc -l 712 [EMAIL PROTECTED] corlib]$ find -name \*.cs | xargs grep Locale.GetText | grep -v Exception | wc -l 194 Most of those 194 seem to be cases where Locale was put on a different line than the throw statement for cosmetic reasons. > I want to know the real impact (we have the tools, it should take a few > minutes at most to find out the numbers). The best way for Kornel to do that (just as an FYI since he has probably never used the tools) is to run: mono --stats foo.exe mono --profile foo.exe where `foo.exe' is a program that exercises the Locale code, but doesn't do much else, and send the output for each before and after the change. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
Note that I changed subject because this dicussion is not specific to my patch altough it applies to my patch. First of all: If any of my conclusions are wrong please let me know. From: Jonathan Pryor private static ResourceManager GetResourceManager () { if (resources == null) lock (resourcesLock) { if (resources == null) resources = new GetTextResourceManager (typeof (Locale).Assembly.GetName ().Name, typeof (Locale).Assembly); } return resources; } I think this is good, because it is intended to initialize resources only once. It looks good. It acts good. It isn't good. See: http://galactus.ximian.com/pipermail/mono-devel-list/2004-February/004101.html http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx Using the following code as the example: if (a == null) { lock(obj) { if (a == null) a = new A(); } } I see the problem as the following: 1. Declaring "a" as volatile would solve the problem but it results in performance loss because of memory barriers for each read. 2. Removing the check outside the lock would solve the problem but it results in performance loss because of memory barriers for each read. 3. It is not a problem that "a" may be seen as null even if it was already created because lock will do memory barrier. 4. The problem is that "a" may be assigned before it's content is stored (has the same side effects as using the object without executing the constructor) because reordering and this will cause problems if a processor did not cached value of "a" and wants to read it from the shared memory then it will see the object in "a" but will see an uninitialized object. 5. Using a memory barrier after the object was created but before it is assigned to "a" solves the problem and does not result in performance loss when the object is already created. So the following code is good: if (a == null) { lock(obj) { if (a == null) { object newA = new A(); Thread.MemoryBarrier(); a = newA; } } } I think using a lock is better than constructing a new instance because the new instance would be dropped if it's already created as we want to use a single instance so it's better to suspend the thread by doing a wait than creating a new instance because the CPU time can be used for useful operations instead of wating time. http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx: "Realize that synchronization is expensive. The full fence implied by Interlocked.Increment can be many 100’s of cycles on modern hardware. That penalty may continue to grow, in relative terms." I think this applies to Interlocked.CompareExchange as well. So I suggest to use this model instead of Interlocked.CompareExchange. Furthermore I think using two Thread.MemoryBarrier() is less effective than using lock and and a single Thread.MemoryBarrier() because there will be not useless object creation, Thread.MemoryBarrier() allways does a full barrier while lock does acrique at the begining and release at the end and Interlocked.CompareExchange does barriers as well so there are more barriers and thus locks in your "lock-free" code than in the locked code. From: Jörg Rosenkranz How about using Thread.MemoryBarrier how it's been suggested in Brad Abrams' blog: http://blogs.msdn.com/brada/archive/2004/05/12/130935.aspx This code does the same as the above code so this code should be good. Is this supposed to work on Mono? Thread.MemoryBarrier is not implemented by Mono yet (no exception but does nothing), but it seems that it is required only by IA64 that is not supported by Mono yet so you can already use it but will be implemented only when it will be necessary. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
On Thu, 2005-06-23 at 19:03 +0200, Kornél Pál wrote: > 1. Declaring "a" as volatile would solve the problem but it results in > performance loss because of memory barriers for each read. Well, the performance loss here isn't all that bad. On an x86 machine there is basically no loss. > 2. Removing the check outside the lock would solve the problem but it > results in performance loss because of memory barriers for each read. The real problem is that the lock can result in contention which is orders of magnitude worse than a memory barrier. > I think using a lock is better than constructing a new instance because the > new instance would be dropped if it's already created as we want to use a > single instance so it's better to suspend the thread by doing a wait than > creating a new instance because the CPU time can be used for useful > operations instead of wating time. That issue only happens in the *VERY* rare case that two threads are contending. > http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx: > "Realize that synchronization is expensive. The full fence implied by > Interlocked.Increment can be many 100’s of cycles on modern hardware. That > penalty may continue to grow, in relative terms." > > I think this applies to Interlocked.CompareExchange as well. But that only gets run once per program. Anyways the cost of reading a page in from the disk to do the Locale stuff is orders of magnitude more expensive. > So I suggest to use this model instead of Interlocked.CompareExchange. > Furthermore I think using two Thread.MemoryBarrier() is less effective than > using lock and and a single Thread.MemoryBarrier() because there will be not > useless object creation, Thread.MemoryBarrier() allways does a full barrier > while lock does acrique at the begining and release at the end and > Interlocked.CompareExchange does barriers as well so there are more barriers > and thus locks in your "lock-free" code than in the locked code. It depends on how commonly this code is used. The code is going to become horrible to maintain if we have MemoryBarriers scattered around. We should really stick to obvious locking patterns except where performance is an issue. Now, given that this code is only used in exceptional code paths (and in SWF -- but there, speed is measured in UI responsiveness, and none of the solutions are slow enough to make a difference there), the simple lock-then-check should suffice for now. -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
From: Ben Maurer On Thu, 2005-06-23 at 19:03 +0200, Kornél Pál wrote: 1. Declaring "a" as volatile would solve the problem but it results in performance loss because of memory barriers for each read. Well, the performance loss here isn't all that bad. On an x86 machine there is basically no loss. You are right but although on x86 machines the original code without volatile and MemoryBarrier works correctly we care about this problem. As the problem may occur only on MP IA64 (according to referenced articles) the solution itself has to be shaped for MP IA64 as well (as long as it does not cause performance loss on other architectures). And I think using no lock for read results in better performance than locking or doing memory barriers anyway. 2. Removing the check outside the lock would solve the problem but it results in performance loss because of memory barriers for each read. The real problem is that the lock can result in contention which is orders of magnitude worse than a memory barrier. You are right, but memory barriers should be done by lock as well so it's very inefficient. I think using a lock is better than constructing a new instance because the new instance would be dropped if it's already created as we want to use a single instance so it's better to suspend the thread by doing a wait than creating a new instance because the CPU time can be used for useful operations instead of wating time. That issue only happens in the *VERY* rare case that two threads are contending. You are right but if we know a better solution we should use that. And of course the problem because of using the original form of the code will occur only in very rare cases as well and we don't say that it's unimportant. These rare cases exist anyway and I think it's better to wait and let the CPU do something useful than doing someting useless just not to lock. And note that it even may need more time to create a new instance than waiting for the other thread to create the instance so I don't see any advantages of creating the multiple instances simultaneously. http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx: "Realize that synchronization is expensive. The full fence implied by Interlocked.Increment can be many 100’s of cycles on modern hardware. That penalty may continue to grow, in relative terms." I think this applies to Interlocked.CompareExchange as well. But that only gets run once per program. Anyways the cost of reading a page in from the disk to do the Locale stuff is orders of magnitude more expensive. You are right but if we care about performance we should care about this rare situations as well. Doing expensive research for these situations is not recommented but if we know that one solution is better than the other we should use the better instead of saying it's not important. So I suggest to use this model instead of Interlocked.CompareExchange. Furthermore I think using two Thread.MemoryBarrier() is less effective than using lock and and a single Thread.MemoryBarrier() because there will be not useless object creation, Thread.MemoryBarrier() allways does a full barrier while lock does acrique at the begining and release at the end and Interlocked.CompareExchange does barriers as well so there are more barriers and thus locks in your "lock-free" code than in the locked code. It depends on how commonly this code is used. The code is going to become horrible to maintain if we have MemoryBarriers scattered around. We should really stick to obvious locking patterns except where performance is an issue. Now, given that this code is only used in exceptional code paths (and in SWF -- but there, speed is measured in UI responsiveness, and none of the solutions are slow enough to make a difference there), the simple lock-then-check should suffice for now. It's sufficient but I can't understand why not to use a more sufficient solution if we already know that solution. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
On Thu, 2005-06-23 at 19:49 +0200, Kornél Pál wrote: > >> 2. Removing the check outside the lock would solve the problem but it > >> results in performance loss because of memory barriers for each read. > > > > The real problem is that the lock can result in contention which is > > orders of magnitude worse than a memory barrier. > > You are right, but memory barriers should be done by lock as well so it's > very inefficient. As I said, the lock is MUCH more expensive than the barrier ;-). > It's sufficient but I can't understand why not to use a more sufficient > solution if we already know that solution. Because our interests are (in order): 1. Correct code 2. Code that is not noticeably slow to the user 3. Readable/Maintainable/Clear code 4. Micro-tuned code Your stuff falls under 4. Anyways, there is no use arguing about this stuff. If you can show that more complex code results in a measurable speedup, feel free to bring it up ;-). In the meanwhile, I've done a few data-collection things: [EMAIL PROTECTED] ~]$ mono --trace=T:Locale install/lib/monodoc/browser.exe ENTER: Locale:GetText (string)([STRING:0x42720:EST], ) LEAVE: Locale:GetText (string)[STRING:0x42720:EST] ENTER: Locale:GetText (string)([STRING:0x42738:EDT], ) LEAVE: Locale:GetText (string)[STRING:0x42738:EDT] (this is after browsing about for a bit). So, it looks like it is possible the people using DateTime will experience a bit of slowness. However, I wonder if for this specific case, we can rely on the OS's database of time zones. On mcs, there were *no* calls to Locale.GetText except when I tried to compile a non-existent file. In that case, the exception was caught, however it was still localized. Can this be avoided? As for the expense of the reflection stuff you used, I have this test case: > using System; > using System.Text; > > class X { > static void Main () > { > Console.WriteLine ("X"); > //Console.WriteLine (typeof (X).Assembly.GetName ().Name); > } > } I first did stats with the C.WL alone, and then with reflection: [EMAIL PROTECTED] ~]$ mono --stats foo.exe X Mono Jit statistics Compiled methods: 149 Methods from AOT: 0 Methods cache lookup: 97 Method trampolines: 1529 Basic blocks: 964 Max basic blocks: 48 Allocated vars: 707 Analyze stack repeat: 0 Compiled CIL code size: 7665 Native code size: 15188 Max code size ratio:6.00 (TextWriter::Synchronized) Biggest method: 1726 (UTF8Encoding::InternalGetBytes) Code reallocs: 1 Allocated code size:15188 Inlineable methods: 0 Inlined methods:4 Created object count: 236 Initialized classes:144 Used classes: 65 Static data size: 188 VTable data size: 7916 [EMAIL PROTECTED] ~]$ mono --stats foo.exe foo Mono Jit statistics Compiled methods: 190 Methods from AOT: 0 Methods cache lookup: 161 Method trampolines: 1973 Basic blocks: 1211 Max basic blocks: 48 Allocated vars: 918 Analyze stack repeat: 0 Compiled CIL code size: 10557 Native code size: 20097 Max code size ratio:6.00 (TextWriter::Synchronized) Biggest method: 1726 (UTF8Encoding::InternalGetBytes) Code reallocs: 1 Allocated code size:20097 Inlineable methods: 0 Inlined methods:4 Created object count: 380 Initialized classes:167 Used classes: 79 Static data size: 256 VTable data size: 9500 -- Ben ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Double-locking and thread safety
From: Ben Maurer Anyways, there is no use arguing about this stuff. If you can show that more complex code results in a measurable speedup, feel free to bring it up ;-). Although the current code is not complex lock, MemoryBarrier and CompareExchange could be invoked a hundreds of times but to get proper results they should be executed on the right architecture (multi-processor system, threads on different processors, probably on IA64). I think it's difficult to make a managed thread to use a specific processor and MemoryBarrier is not implemented at all by Mono so it cannot be tested. And of course the runtime does not support IA64. I don't want to argue about this because it seems to be nearly impossible to test it.:) But you can make sure that creating a new instance requires more time than waiting for another thread to create it because: 1. We can assume that creating an object requires the same time because alhough it's slower to create the first instance (static constructors, file loading from disk, ...) the second thread has to wait these static constructors so the second instance cannot be created faster. 2. Usually one of the threads start to create the instance earlier so one of them will be created earlier. 3. Thus one of the threads will create the instance while all the other threads will not create their instance before the first thread. 4. Usually the other threads will finish later so it's wasting of time. And doing this has no drawbacks because if all of the threads finish the same time only one of them did usefull work and all the others were wasting CPU cycles so it sill has the advantage of CPU cycles. This theoritically seems to be better than doing the reverse. In the meanwhile, I've done a few data-collection things: [EMAIL PROTECTED] ~]$ mono --trace=T:Locale install/lib/monodoc/browser.exe ENTER: Locale:GetText (string)([STRING:0x42720:EST], ) LEAVE: Locale:GetText (string)[STRING:0x42720:EST] ENTER: Locale:GetText (string)([STRING:0x42738:EDT], ) LEAVE: Locale:GetText (string)[STRING:0x42738:EDT] (this is after browsing about for a bit). So, it looks like it is possible the people using DateTime will experience a bit of slowness. However, I wonder if for this specific case, we can rely on the OS's database of time zones. You were right I did not know or used these tools. Note that these strings are localized by the TimeZone class rather than DateTime. I don't know whether they should be localized but it is a bad practicle to localize names in the constructor. They should be localized when the string is returned because you can use different CurrentUICultures to retrive them than you used to create the class. On mcs, there were *no* calls to Locale.GetText except when I tried to compile a non-existent file. In that case, the exception was caught, however it was still localized. Can this be avoided? No. The problem is that the message (and not a key or format pattern) has to be passed to the constructor of Exception. As MS.NET uses keys they have to pass the localized message thus the message will be in the language used to throw the Exception. This should be done by Mono to preserve compatibility. Furthermore the message cannot contain any parameters ({0}, {1}, ...) it has to contain a message with parameters filled in. And as applications can use any messages (that may be localized by themselves) and probably they don't want the class library to localize their messages. As for the expense of the reflection stuff you used, I have this test case: using System; using System.Text; class X { static void Main () { Console.WriteLine ("X"); //Console.WriteLine (typeof (X).Assembly.GetName ().Name); } } My only problem is that I don't know how much penalty does this mean (I don't know how to interpret the results). I don't insist on using this code if you have a better solution please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] [PATCH] Reworked unified Locale classes
From: Miguel de Icaza From: Ben Maurer I want to know the real impact (we have the tools, it should take a few minutes at most to find out the numbers). The best way for Kornel to do that (just as an FYI since he has probably never used the tools) is to run: mono --stats foo.exe mono --profile foo.exe You are right I have never used these tools.:) I tested "internal static string GetText (string message)" without INSIDE_CORLIB. It is a very common code. getTextLock and SafeGetText are required anyway. GetResource is not changed significantly. I tested GetTextResourceManager without resource files (just used the transparent GetTextResourceSet) because the current ResourceManager and ResourceSet implementations are not currently effective enough and there are no localized resources yet. And of course localizing resources from files will result in worse performance anyway but it depends on ResourceManager and not Locale. I attached the source files and the results: mcs /out:OldLocaleBenchmark.exe LocaleBenchmark.cs OldLocale.cs mcs /out:NewLocaleBenchmark.exe LocaleBenchmark.cs NewLocale.cs mono --stats OldLocaleBenchmark.exe >OldLocaleBenchmark.stats mono --profile OldLocaleBenchmark.exe >OldLocaleBenchmark.profile mono --stats NewLocaleBenchmark.exe >NewLocaleBenchmark.stats mono --profile NewLocaleBenchmark.exe >NewLocaleBenchmark.profile I have runned this on Windows. Kornél LocaleBenchmark.tar.gz Description: GNU Zip compressed data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Fwd: Re: [Fwd: Re: [Mono-devel-list] System.Data.DataSet.ReadXml reimplementation]]
Hi Kosta, Maybe I had better take care of it by myself. I think there are some cases that we can optimize. For example when tables are already defined it does not require InferSchema and thus entire load won't be required. However similar things also happen to XmlDataReader, so they should be taken care as a whole. Please feel free to commit this patch but I'll look into them at some stage again. Thanks Atsushi Eno Konstantin Triger wrote: Hi Eno, I don't see it in mailing list so resending. I made the changes we talked about, bt it turns out they probably won't make a big diff (see attached patch) The problem is that I have to collect almost always: XmlReadMode.InferSchema: in order to be able to skip if "schema" is found. XmlReadMode.Auto: as I don't know what's gonna be. XmlReadMode.DiffGram: wait for diffgram - very uncommon case, but have a test (MonoTests.System.Data.DataSetTest.ReadWriteXmlDiffGram). XmlReadMode.IgnoreSchema: to be able to ignore the schema if it's found. From the other side in most cases the schema or diffgram element will be as root or its child, so nothing would be collected anyway. Regards, Konstantin Triger ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Reworked Patch of Timer
Hey Ben Thanks for your comments. Find the diff attached.. Can this be commited now? Regards uma Index: Timer.cs === --- Timer.cs(revision 46470) +++ Timer.cs(working copy) @@ -29,122 +29,79 @@ // using System.Runtime.InteropServices; +using System.Collections; namespace System.Threading { + #if NET_2_0 [ComVisible (true)] #endif public sealed class Timer : MarshalByRefObject, IDisposable { - sealed class Runner : MarshalByRefObject - { - ManualResetEvent wait; - AutoResetEvent start_event; - TimerCallback callback; - object state; - int dueTime; - int period; - bool disposed; - bool aborted; - public Runner (TimerCallback callback, object state, AutoResetEvent start_event) - { - this.callback = callback; - this.state = state; - this.start_event = start_event; - this.wait = new ManualResetEvent (false); - } - public int DueTime { - get { return dueTime; } - set { dueTime = value; } - } +internal class TimerTask + { +internal TimerCallback timerCallback; +internal object state; +internal int dueTime; +internal int period; +internal DateTime lastSignalledTime; +internal Timer timer; + internal bool triggered; + + + +public TimerTask(TimerCallback timercallback, object state, int dueTime, int period, Timer timer) +{ + +this.timerCallback = timercallback; +this.state = state; +this.dueTime = dueTime; +this.period = period; +this.timer = timer; + this.lastSignalledTime = DateTime.UtcNow; //we are storing now, even + + // though we have never signalled this :) + this.triggered = false; +} - public int Period { - get { return period; } - set { period = value == 0 ? Timeout.Infinite : value; } - } - bool WaitForDueTime () + internal void Callback() { - if (dueTime > 0) { - bool signaled; - do { - wait.Reset (); - signaled = wait.WaitOne (dueTime, false); - } while (signaled == true && !disposed && !aborted); - - if (!signaled) - callback (state); - - if (disposed) - return false; - } - else - callback (state); - - return true; - } - - public void Abort () + this.lastSignalledTime = DateTime.UtcNow; + timerCallback(state); + } + + internal bool IsDue() { - lock (this) { - aborted = true; - wait.Set (); - } - } - - public void Dispose () - { -
Re: [Mono-devel-list] Reworked Patch of Timer
S Umadevi wrote: >> Hey Ben >> Thanks for your comments. Find the diff attached.. >> >> Can this be commited now? >> >> Regards >> uma >> Looking over this patch, it looks like there could be some good use of foreach for looping over things. It would tighten the code up readability-wise. The performance of the foreach loop 'should' be >= the for loop, but I haven't looked at how Mono optimizes foreach really. -- Thomas Harning Jr. signature.asc Description: OpenPGP digital signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Reworked Patch of Timer (resent)
There was a small error in the previous one Hey Ben Thanks for your comments. Find the diff attached.. Can this be commited now? Regards uma Index: Timer.cs === --- Timer.cs(revision 46470) +++ Timer.cs(working copy) @@ -29,122 +29,79 @@ // using System.Runtime.InteropServices; +using System.Collections; namespace System.Threading { + #if NET_2_0 [ComVisible (true)] #endif public sealed class Timer : MarshalByRefObject, IDisposable { - sealed class Runner : MarshalByRefObject - { - ManualResetEvent wait; - AutoResetEvent start_event; - TimerCallback callback; - object state; - int dueTime; - int period; - bool disposed; - bool aborted; - public Runner (TimerCallback callback, object state, AutoResetEvent start_event) - { - this.callback = callback; - this.state = state; - this.start_event = start_event; - this.wait = new ManualResetEvent (false); - } - public int DueTime { - get { return dueTime; } - set { dueTime = value; } - } +internal class TimerTask + { +internal TimerCallback timerCallback; +internal object state; +internal int dueTime; +internal int period; +internal DateTime lastSignalledTime; +internal Timer timer; + internal bool triggered; + + + +public TimerTask(TimerCallback timercallback, object state, int dueTime, int period, Timer timer) +{ + +this.timerCallback = timercallback; +this.state = state; +this.dueTime = dueTime; +this.period = period; +this.timer = timer; + this.lastSignalledTime = DateTime.UtcNow; //we are storing now, even + + // though we have never signalled this :) + this.triggered = false; +} - public int Period { - get { return period; } - set { period = value == 0 ? Timeout.Infinite : value; } - } - bool WaitForDueTime () + internal void Callback() { - if (dueTime > 0) { - bool signaled; - do { - wait.Reset (); - signaled = wait.WaitOne (dueTime, false); - } while (signaled == true && !disposed && !aborted); - - if (!signaled) - callback (state); - - if (disposed) - return false; - } - else - callback (state); - - return true; - } - - public void Abort () + this.lastSignalledTime = DateTime.UtcNow; + timerCallback(state); + } + + internal bool IsDue() { - lock (this) { - aborted = true; - wait.Set (); - } - } - - public void Dispos