Re: [Mono-dev] Unknown chars in strings
Are you sure your application works by itself? e.g. does the application (without recompiling) works on Windows/.Net or Linux/x86/Mono? If Mono prints ? on the console it is most likely an issue with encodings/codepages (Mono contains it's own set of locale, timezone and codepage data so you shouldn't need any other c libraries). Did you check OutputEncoding? Did you try to set it to a different encoding? Happy Hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von krisztian.koc...@optimaster.eu Gesendet: Dienstag, 5. April 2011 16:45 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Unknown chars in strings Hi! I'v cross-compiled Mono to a big-endian PowerPC. Unfortunately the hungarian characters (like éáőúí) are displayed incorrectly (Mono prints '?'). If I print these chars from C with a simple printf they display correctly. The terminal supports UTF-8, but the device contains only a subset of glibc files (no locale and timezone data). Iconv data is also missing but I'v compiled a preloadable libiconv with extra code pages (and verified that it is working). Glibc version is 2.5, GCC is 4.1.1. If I redirect the output to a file the chars still bad. What are the requirements of Mono to display these characters correctly? BR, Krisztian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C# source-to-source compiler
Hi Mark, either I'm misunderstanding your idea or you are misunderstanding some of the .Net architecture. 1) C# has no own runtime library, it is practically a runtime-library-free implementation on top of the CLR base class libraries/VM. 2) I don't understand why you ever wanted to change the virtual machine in your situation. IF the runtime support you need can even be expressed in C# code (and that's what I'm understanding from your post) then there is surely no need to modify the VM at all. The next question is why you want a source-to-source compiler. It is the usual and good practice to compile source to IL and I don't see any reason why you shouldn't. If you want to be your language an extention of C# why not just take one existing C# Compiler (e.g. dmcs) and add the constructs you need? Happy hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von Mark Farnell Gesendet: Donnerstag, 4. November 2010 05:54 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] C# source-to-source compiler Hi, I plan to design a language based on an extention of C#, and I would like to use the mono compiler and abstract syntax tree. The language extension would require some runtime feature, which can be implemented by: - modifying the virtual machine, or - C# runtime library In the former case, it can be time consuming for me to navigate through the virtual machine. In the latter case, I would need a source to source compiler reading code written for the extended language and output pure C# code that links to my runtime library. For the latter option, I would like to modify the dmcs compiler to read the code written in the extended language and output pure C# code (rather than CIL bytecde). Is this possible? Are there other better ways? Thanks! Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] serialization not implemented
No, it's not specific problem with your usage. It's just not implemented in Mono. http://github.com/mono/mono/blob/master/mcs/class/System.Core/System.Collect ions.Generic/HashSet.cs#L545 BTW: I don't know if the Mono Migration Analyzer is able to detect Serialization problems, but it seems it doesn't. Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von SillySnail Gesendet: Mittwoch, 13. Oktober 2010 11:52 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] serialization not implemented Hi My program needs to serialize a bunch of user-defined instances time to time. It runs correctly with .NET framework on Windows but throws exception with latest mono-2.8 on Linux. The exception is thrown when the program tries to write (serialize) an instance to disk, and says The requested feature is not implemented. Detailed error info is at last of the mail. I've checked the program with the latest Mono Migration Analyzer and it reports all feature in my program are supported in mono. I guess the problem is in the way I work with mono rather than mono itself. Does anyone knows how to fix the problem? Thanks very much. Exception thrown: System.NotImplementedException: The requested feature is not implemented. at System.Collections.Generic.HashSet`1[System.Int64].GetObjectData (System.Runtime.Serialization.SerializationInfo info, StreamingContext context) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.GetObjectDa ta (System.Object obj, System.Runtime.Serialization.Formatters.Binary.TypeMetadata metadata, System.Object data) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject (System.IO.BinaryWriter writer, Int64 id, System.Object obj) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject Instance (System.IO.BinaryWriter writer, System.Object obj, Boolean isValueObject) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteQueued Objects (System.IO.BinaryWriter writer) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteObject Graph (System.IO.BinaryWriter writer, System.Object obj, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serializ e (System.IO.Stream serializationStream, System.Object graph, System.Runtime.Remoting.Messaging.Header[] headers) [0x0] in filename unknown:0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serializ e (System.IO.Stream serializationStream, System.Object graph) [0x0] in filename unknown:0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Memory usage differences between GC and OS
Well, the point of the email is the following: something I've found several times is a situation where GC.GetTotalMemory gives me something like, let's say, 40Mb, then VIRT is something like 200Mb and RES is 80Mb. Mark refreshed me that jitted and non-jitted code will be eating up memory, then metadata and so on... and of course the GC internals with things like free memory lists and so on. But, I think it would be great for application developers to really understand how this is working and where your memory is going, because the diff between 40Mb and 200Mb is simply... huge! As you wrote: That 200Mb isn't memory! It is address space. And as you have about 17592186044416 Mb of address space available on a 64-bit system 200MB isn't much to worry about. Moreover I don't really see much sense in trying to tweak that. But in case you are interested: Afaik one of the big blocks is simply the raw assemblies. Each of them gets loaded memmapped, so their entire file size counts into your VIRT. Happy Hacking 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 1/2 - System.Diagnostics.Contracts in corlib
Hi Chris, I have no knowledge about your GSoC project, but usually mono doesn't use C# inline documentation style. Happy hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] Im Auftrag von Chris Bacon Gesendet: Mittwoch, 16. Juni 2010 12:03 An: Marek Safar Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Patch 1/2 - System.Diagnostics.Contracts in corlib Hi, Attached is a new, improved, patch that keeps existing formatting. Sorry for the mistake. Kind regards Chris Marek Safar wrote: Hi Chris, Attached is a patch to corlib containing updates the System.Diagnostics.Contracts as part of the GSoC work I am doing. I'm sure there will be parts of this I haven't done quite right, so please let me know what they are, and I'll sort them out. Can you keep existing formatting, most of the changes are about changing tabs to spaces. Please send a new set of patches without any noise (lines you have not changed) Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ilasm as a library
Now that you mention System.Reflection, I'm not sure how you get to that statement. But I NEVER mentioned System.Reflection. I've been talking about System.Reflection.Emit which is an (entirely) different thing. https://blogs.msdn.com/jmstall/archive/2008/03/15/things-in-metadata- that-are-missing-in-reflection.aspx And what does this have to do with System.Reflection.Emit? http://weblog.ikvm.net/PermaLink.aspx?guid=9b7ada92-88d7-45c7-be83- 8e6f4f3ccb1b That's a cool source-compatible replacement for System.Reflection.Emit. So you can develop against System.Reflection.Emit and simply drop IKVM.Reflection.Emit in to replace it (or vice versa). Not everyone uses System.Reflection. The list goes on. No, not *everyone* does. But nearly everyone does it. Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hi, I'm the author (of a large part) of the current Char class and unfortunately I think you overlooked some things with the changes. What you are doing is (heavily) degrading the performance of most of the char methods (some of which are VERY commonly used) for supporting a single (likely VERY rarely used case) in a single (likely not used very much) method. 1. Lets first start with performance. Unfortunately your micro benchmark is completely omitting the most important speed factor: All the methods were designed to be inlinable (because they tend to be called in tight loops, as they are even within corelib). After your change likely most/none of them would be inlinable anymore. Your benchmark, however, does not CALL A SINGLE METHOD. It just measures the overhead of two additional mathematical operators and a memory access. That is not the big speed-sink. But even then your approach looses 25% perf for no additional gain. The original implementation was the result of (literally) thousands of performance tests. 2. Gain vs. impact. I don't see much sense in changing lots of methods in Char to something worse just to support one corner case that could be handled separately. 3. Imho the alternative is relatively simple: Just leave the Char methods as they are and add the special casing only for the one relevant method. You could just add another table (or two for bi-level table compression or one that reuses the data from the first table) as a separate entity. So you can leave all the original methods intact and ONLY if somebody really uses that method and ONLY if he uses it to query the astral plane using surrogates he actually has to pay the price for it (in the runtime loading the relevant table into memory and using that additional lookup). Happy hacking Andreas P.S. And sorry for being somewhat harsh on the patches. -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Damien Diederen Gesendet: Freitag, 14. Mai 2010 23:10 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately. Hi, I just uploaded an updated series of patches addressing bug 480178: https://bugzilla.novell.com/show_bug.cgi?id=480178#c27 This is ready to be committed as far as I am concerned, but comments are of course welcome. Note that I do *not* have commit privileges, so somebody else will have to take care of it even in case of green light. From the “cover letter”: Should apply cleanly on top of mono/mcs r157360. This version uses the same technique as v2, as suggested by Paolo (cf. comment #18), but supports two sets of tables: one compatible with v2.0.50727...v3.5.21022 of Microsoft's framework, and one matching v4.0.30319 (which incorporates substantial changes). The appropriate set is automatically chosen based on the 'corlib' profile. The mechanism can be extended to an arbitrary number of versions, and has also been tested with v1.1.4322, but these additional tables have been left out not to bloat the Mono binaries as recent 'mcs' link to the 'net_2_0' profile anyway. Please cf. the individual ChangeLog entries for more details about the compatibility and performance implications. The first patch is for 'mono'; the six others for 'mcs'. Cheers, Damien -- http://crosstwine.com tel: +49 21 89 29 39 cell: +49 174 34 89 428 “Strong Opinions, Weakly Held” — Bob Johansen ___ 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] Simple floating maths problem
Just some guess: When looking at the numbers it seems more likely that the issue is not precision of the arithmetics, but rounding of the results for casting to integer (for float it should round to nearest number (See C# spec. p139)). Maybe mono just cuts for the conversion as it is done for integral types. Greetings Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Stuart Fraser Gesendet: Freitag, 30. April 2010 00:22 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Simple floating maths problem Mono results: 0.95864 * 5 = 47931 0.89374 * 5 = 44686 0.89092 * 5 = 44545 0.89716 * 5 = 44857 0.4191 * 5 = 20954 0.79782 * 5 = 39890 .Net results : 0.95864 * 5 = 47932 0.89374 * 5 = 44687 0.89092 * 5 = 44546 0.89716 * 5 = 44858 0.4191 * 5 = 20955 0.79782 * 5 = 39891 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Simple floating maths problem
I just tried your sample and if you are looking for a quick workaround (for
yourself, not mono) remove the explicit int cast:
int fact = 5;
float[] tList = { 0.95864f, 0.89374f, 0.89092f, 0.89716f,
0.4191f, 0.79782f };
foreach (float val in tList)
{
float comp = val * fact;
Console.WriteLine({0:g} * {1:d} = {2}, val, fact, comp);
}
BTW: If you are looking for something with high precision then float is no
good choice. .Net/Mono has a Decimal type that offers high precision with
acceptable performance.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Simple floating maths problem
I've been running your modified sample under x86 .Net 3.5 and my result is:
0,95864 * 5 = 47932 = 47932 = 47932
0,89374 * 5 = 44687 = 44687 = 44687
0,89092 * 5 = 44546 = 44546 = 44546
0,89716 * 5 = 44858 = 44858 = 44858
0,4191 * 5 = 20955 = 20955 = 20955
0,79782 * 5 = 39891 = 39891 = 39891
and running it under x64 .Net 3.5 is exactly the same as above.
Only running mono on the same machine results in:
0,95864 * 5 = 47931 = 47932 = 47932
0,89374 * 5 = 44686 = 44687 = 44687
0,89092 * 5 = 44545 = 44546 = 44546
0,89716 * 5 = 44857 = 44858 = 44858
0,4191 * 5 = 20954 = 20955 = 20955
0,79782 * 5 = 39890 = 39891 = 39891
So something is fishy *g*.
Maybe I'm wrong, but if it was a precision error, then how could compi be
different from comp?
Andreas
-Ursprüngliche Nachricht-
Von: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Rolf Bjarne
Kvinge
Gesendet: Freitag, 30. April 2010 15:22
An: 'Stuart Fraser'; mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] Simple floating maths problem
Hi,
Running this modified simple on x86 .NET:
int fact = 5;
float [] tList = { 0.95864f, 0.89374f, 0.89092f,
0.89716f, 0.4191f, 0.79782f };
foreach (float val in tList) {
int comp = (int) (val * fact);
float compf = (val * fact);
int compi = (int) compf;
Console.WriteLine ({0} * {1} = {2} = {3} =
{4}, val, fact, comp, compf, compi);
}
Gives this result:
0,95864 * 5 = 47931 = 47932 = 47932
0,89374 * 5 = 44686 = 44687 = 44687
0,89092 * 5 = 44545 = 44546 = 44546
0,89716 * 5 = 44857 = 44858 = 44858
0,4191 * 5 = 20954 = 20955 = 20955
0,79782 * 5 = 39890 = 39891 = 39891
I think it's a precision issue you're running into, as Robert said.
Rolf
-Mensaje original-
De: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
boun...@lists.ximian.com] En nombre de Stuart Fraser
Enviado el: viernes, 30 de abril de 2010 0:22
Para: mono-devel-list@lists.ximian.com
Asunto: [Mono-dev] Simple floating maths problem
HI All,
I'm currently working on some code for HPC benchmarking using a number
of languages and runtimes but am primarily focussing on C#. During my
coding I have come across some inconsistencies between results between
calculated in Mono vs .Net (and C /Java), there may be a number of
reasons for this but I was after a sanity check before I start looking
into the mono runtime code...
Basically I have pulled out some of the internal values/working and
problem is thus:
int fact = 5;
float[] tList = { 0.95864f, 0.89374f, 0.89092f, 0.89716f,
0.4191f, 0.79782f };
foreach (float val in tList)
{
int comp = (int)(val * fact);
Console.WriteLine({0:g} * {1:d} = {2:d}, val, fact,
comp);
}
Mono results:
0.95864 * 5 = 47931
0.89374 * 5 = 44686
0.89092 * 5 = 44545
0.89716 * 5 = 44857
0.4191 * 5 = 20954
0.79782 * 5 = 39890
.Net results :
0.95864 * 5 = 47932
0.89374 * 5 = 44687
0.89092 * 5 = 44546
0.89716 * 5 = 44858
0.4191 * 5 = 20955
0.79782 * 5 = 39891
Obviously precision required is very important but this only appears to
be a problem on Mono.
I have tested this with Mono 2.6.2 and 2.6.4 on
- OpenSUSE 11.2 (x64) AMD Athlon x64
- Windows 7 (x64) Intel i7
- Cray XT4h (x64) AMD Opteron :)
I have tried the code being run checked and unchecked, I have compiled
with .net and run the executable under mono and done a clean mono build
and test,
I have looked through the bugzilla but haven't seen anything that
matches this, its late and I'm tired is this a bug in the mono
jit/runtime?
Suggestions on where to look for a fix?
Regards
Stuart
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
I checked again and it seems I confused that with the problems of the (String) GetHashCode implementation. Sorry for that. Greetings Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Miguel de Icaza Gesendet: Dienstag, 16. März 2010 21:26 An: Andreas Nahr Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Issues with System.Random Hello, As already said I didn't test and can't comment but keep in mind that the Random class is used (real-world) under VERY specific situations and none of them are near random. I am not sure about this. I looked through the svn log for the commits to the Random class, and I can not find any reverted patches to the Random class. In fact, I found a commit that explicitly stated Switch to Knuth results instead of Microsoft ones. Unless someone has some strong evidence and a regression report on the Random class, I see no problem with replacing our Random implementation with something better (provided the other issuelets have been resolved). But it seems to me that there is a very weak case for regressions in the Random class. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Issues with System.Random
I won't comment on the algorithm itself (keep in mind that the existing one
already was replaced once with a better one which failed miserably in real
world apps, so had to be reverted).
Also a newsgroup as source doesn't sound reliable at all.
But your patch adds errors for exceptions (which were mostly correct
before). And the unit-tests are no unit-tests. They don't test the
implementation against the specification, they test the implementation
against the implementation which is useless. And moreover you removed ALL
Random() constructor tests which most likely are the only of relevance to
real-world applications.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Adrian
Willenbücher
Gesendet: Montag, 15. März 2010 23:33
An: mono-devel-list@lists.ximian.com
Betreff: [Mono-dev] Issues with System.Random
Hello,
I noticed that the implementation of System.Random has a couple of flaws:
1.) The algorithm for the random data fails miserably in some of the Diehard
tests (http://i.cs.hku.hk/~diehard/), even
if it is slightly changed in order to generate full 32-bit random values.
2.) It might return a negative value:
if (retVal 0) retVal += MBIG;
results in -1 for retVal == int.MinValue, which is forbidden.
3.) The use of floating-point arithmetic introduces numerical errors since
int.MaxValue is not a power of two (so
1.0/int.MaxValue is not representable without errors).
I reimplemented the class using the xorshift algorithm by George Marsaglia,
which he posted on comp.lang.c
(http://groups.google.com/group/comp.lang.c/browse_thread/thread/a9915080a44
24068/), and tested it with the Diehard
battery of tests (it passed); it avoids any FP arithmetic where it is not
needed.
The interface of the class is still pretty screwed up, but sadly we can't
change that.
I also completely rewrote the unit tests; they are stricter and more precise
now. The expected values were produced by
running the C-code given by George Marsaglia.
The patches for the two files can be found below.
Regards,
Adrian
Index: mcs/class/corlib/System/Random.cs
===
--- mcs/class/corlib/System/Random.cs (revision 153607)
+++ mcs/class/corlib/System/Random.cs (working copy)
@@ -4,12 +4,11 @@
// Authors:
// Bob Smith (b...@thestuff.net)
// Ben Maurer (bmau...@users.sourceforge.net)
+// Adrian Willenbücher (awillenbuec...@gmx.de)
//
// (C) 2001 Bob Smith. http://www.thestuff.net
// (C) 2003 Ben Maurer
//
-
-//
// Copyright (C) 2004 Novell, Inc (http://www.novell.com)
//
// Permission is hereby granted, free of charge, to any person obtaining
@@ -39,104 +38,98 @@
[ComVisible (true)]
public class Random
{
- const int MBIG = int.MaxValue;
- const int MSEED = 161803398;
+ private uint [] state = new uint [5];
- int inext, inextp;
- int [] SeedArray = new int [56];
-
- public Random ()
- : this (Environment.TickCount)
+ public Random () : this(Environment.TickCount)
{
}
public Random (int Seed)
{
- int ii;
- int mj, mk;
-
- // Numerical Recipes in C online @
http://www.library.cornell.edu/nr/bookcpdf/c7-1.pdf
- mj = MSEED - Math.Abs (Seed);
- SeedArray [55] = mj;
- mk = 1;
- for (int i = 1; i 55; i++) { // [1, 55] is
special (Knuth)
- ii = (21 * i) % 55;
- SeedArray [ii] = mk;
- mk = mj - mk;
- if (mk 0)
- mk += MBIG;
- mj = SeedArray [ii];
- }
- for (int k = 1; k 5; k++) {
- for (int i = 1; i 56; i++) {
- SeedArray [i] -= SeedArray [1 + (i +
30) % 55];
- if (SeedArray [i] 0)
- SeedArray [i] += MBIG;
- }
- }
- inext = 0;
- inextp = 31;
+ state [0] = 123456789 ^ (uint)Seed;
+ state [1] = 362436069;
+ state [2] = 521288629;
+ state [3] = 88675123;
+ state [4] = 886756453;
}
- protected virtual double Sample ()
+ /* Uses the xorshift algorithm by George Marsaglia on:
+*
Re: [Mono-dev] Issues with System.Random
In Text Andreas Nahr wrote: I won't comment on the algorithm itself (keep in mind that the existing one already was replaced once with a better one which failed miserably in real world apps, so had to be reverted). I tested a sequence of 68 million 32-bit values for randomness using the Diehard test suite. Of course this is only a heuristic indicator that the sequence has good random characteristics, not a proof. However, the current implementation does not pass (some of) those tests, i.e. there exist cases where it exhibits bad random characteristics. As already said I didn't test and can't comment but keep in mind that the Random class is used (real-world) under VERY specific situations and none of them are near random. That starts with the initialization to Environment.Tickcount which IS going to deliver a relatively small set of states in 99% of all cases. On the other hand an initialization with 0 or -1 is probably just about never going to happen (Because it would only happen for 2 Milliseconds after 50 days of continuous computer uptime). But your patch adds errors for exceptions (which were mostly correct before). What errors are you referring to? As far as I can see, all exceptions mandated by the specification of System.Random are thrown (and tested). By the way, I forgot the Locale.GetText() for the exception messages. + throw new ArgumentNullException (buffer is null.); is clearly an error. First parameter is the argument name, not some descriptive text. And the unit-tests are no unit-tests. They don't test the implementation against the specification, they test the implementation against the implementation which is useless. I disagree. The expected values were not generated by my implementation, but by this reference implementation of the algorithm (compiled for 32-bit machines): I can understand your point, but this means that your ARE testing implementation against implementation. It might be good for testing if you correctly implemented your algorithm, but it is imho not suited to test if it is a conforming CLR/.Net implementation (in fact if you would use it on MS.Net it would fail completely and if you use it on current mono it would also fail). And moreover you removed ALL Random() constructor tests which most likely are the only of relevance to real-world applications. Yes, I forgot this one. However, there's not much you can test for (except that it doesn't throw an exception): the state is private, so it can't be checked directly; the value of Environment.TickCount() might change between reading it Well you can at LEAST test all the provided Next() methods with something similar than you have written. 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] dcraw.net performance
BTW: The code could likely be speed up considerably by using unsafe code with pointers. Using tons of array accesses is always going to have a decent overhead (for added protection). ABC-removal is only going to be working up to a certain point. But on the other hand if you feel that it's fast enough already... Happy Hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Sam777 Gesendet: Sonntag, 13. Dezember 2009 20:47 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] dcraw.net performance Hi, We've ported a large part of http://www.cybercom.net/~dcoffin/dcraw/ dcraw to C# (enough to convert several Canon cameras) - https://sourceforge.net/projects/dcrawnet/ https://sourceforge.net/projects/dcrawnet/ . As expected for image processing code, this is slower than the original C implementation but we've managed to claw some performance back by making it easier for the JIT to optimise bounds checking. Interestingly, Mono didn't get quite as much of a boost from this as the MS implementation: -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Sam777 Gesendet: Sonntag, 13. Dezember 2009 20:47 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] dcraw.net performance Hi, We've ported a large part of http://www.cybercom.net/~dcoffin/dcraw/ dcraw to C# (enough to convert several Canon cameras) - https://sourceforge.net/projects/dcrawnet/ https://sourceforge.net/projects/dcrawnet/ . As expected for image processing code, this is slower than the original C implementation but we've managed to claw some performance back by making it easier for the JIT to optimise bounds checking. Interestingly, Mono didn't get quite as much of a boost from this as the MS implementation: ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Should we replace MemoryStream?
I'm still not sure this is a good idea. A lot of this depends on the use-case for MemoryStream. If 1) A MemoryStream is created with a parameterless constructor and then a lot of data written to it multiple times the ChunkedStream will be better always. 2) If a MemoryStream is created with a parameterless constructor and only gets a few bytes long ChunkedStream might bring considerable overhead. 3) If MemoryStream is created with a fixed size then ChunkedStream will be somewhat, but acceptably slower and have a higher overhead. But it will be totally abysmal once GetBuffer comes into play. 4) If MemoryStream is constructed from a (large) byte array (in the scientific field I'm coming from this is by far the most common usage I've seem; that is basically using MemoryStream as a (read-only) Stream-Wrapper around a byte array) then performance will be abysmal when constructing (if you chunkify e.g. a 500MB byte array) AND again with GetBuffer (recreate the array). So would be O (n) or even O (2*n) instead of O (0). It might be possible to create an implementation that can deal with all this (would need to have variable sized buffers, keep things it gets passed in the constructor alive with small overhead, etc.), but it will be quite complex and come with a large base overhead. And even then the GetBuffer O(n) problem remains in a few scenarios. Maybe it would be better to just leave the class as is and document that for certain scenarios alternative implementations are available that do a MUCH better job. Everybody can easily replace the use of MemoryStream with an alternative implementation if needed. But nobody expects this class to behave completely different from how it originally did (and seems to do in MS.Net). Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Should we replace MemoryStream?
Are you talking about System.IO.MemoryStream? Then imho this would be a problematic move. Most people are used to new MemoryStream (someByteArray) being O(0) time, but with ChunkedStream would be O(n). In fact in those cases ChunkedStream would need twice the memory because it would still need to retain the original byte array (e.g. for GetBuffer). Happy hacking Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Miguel de Icaza Gesendet: Montag, 9. November 2009 19:10 An: mono-devel-list Betreff: [Mono-dev] Should we replace MemoryStream? Hello folks, I just blogged about a memory fragmentation issue here: http://tirania.org/blog/archive/2009/Nov-09.html And I am wondering: since MemoryStream is one of these sources of problems, we could replace this implementation with MindTouch's ChunkedStream. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SharpDevelop under Linux
I've done work on System.Design some years ago and while it may not be the most tested part of mono it already was pretty complete back then. Don't know if anything (well propertygrid does in any case) works right out of the box but it should be able to get it up and running in a short time. Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Jonathan Pobst Gesendet: Montag, 19. Oktober 2009 21:38 An: p...@all-the-johnsons.co.uk Cc: mono-devel Betreff: Re: [Mono-dev] SharpDevelop under Linux Paul wrote: My question is therefore two fold - first can I install SD with just the mono framework somehow and second is it worth the effort (in terms of hacking around) for just the winforms designer? I am pretty sure that SD just uses the Winforms designer that comes in the .Net framework (System.Design). Therefore, even if you can get it to run on Mono, it will not solve your goal, since this isn't really implemented in Mono. Jonathan ___ 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] list of platform-differences
Sorry if I didn't make myself clear. I HAVE been talking about the MS documentation, not some mono specific one. This has nothing to do with Mono but is as specified by the MS .Net Framework. You will get the same issues with .Net Compact Framework if you don't have them already. These classes are designed especially for bit-level access (in fact I see little other use for them). mfg Andreas Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Andreas Heertsch Gesendet: Dienstag, 22. September 2009 09:31 An: Andreas Nahr; mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] list of platform-differences Andreas and all offcourse this could be expected - if I RFM (read the fucking manual). But as a unexperienced mono user I expect, that mono sheelds me from any hardware dependend issue. I can understand, that this expectation is not fully realized in the present, but I would not understand, that this would not be a challenge for mono. Andreas (this one) 2009/9/21 Andreas Nahr classdevelopm...@a-softtech.com Hi, Well the BitConverter documentation says that it operates on the raw bitstream, so this should be expected. Other than that afaik only the Buffer class works directly on raw data. And of course anything related to pointers will be endian-dependent as well. Greetings Andreas (other one) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] list of platform-differences
Hi, Well the BitConverter documentation says that it operates on the raw bitstream, so this should be expected. Other than that afaik only the Buffer class works directly on raw data. And of course anything related to pointers will be endian-dependent as well. Greetings Andreas (other one) Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Andreas Heertsch Gesendet: Montag, 21. September 2009 17:51 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] list of platform-differences As I became aware, that BitConverter.GetBytes(0x1234) returns 0,0 on OSX I thought: that is a bug. But Miguel pointed out, that this depends on the platform OSX: big-endian system (PowerPC) as opposed to a little endian system. Up to that I hoped, that mono would hide all differences of any plattform from my mono-app. But this seems not to be the case. (I think, this is a challenge!) Is there a list of platform specific differences, which have a reflection in mono? Andreas -- EndoTherm GmbH http://www.endotherm.ch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug in corlib/System.Reflection (r139375)
The following addition in r139375 is buggy. if (type.ToString ().EndsWith ([*])) /*FIXME, the reflection API doesn't offer a way around this*/ return InflateType (type.GetElementType ()).MakeArrayType (1); It should not be EndsWith ([*]) but EndsWith ([*], StringComparison.Ordinal) Otherwise it may fail on certain locales (besides being much more memory intensive and much slower). 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] Moving *.Design to package mono-design
Just some info (for the additional info): System.Windows.Forms (and especially the PropertyGrid control) extremely depend on the *Design assemblies. ANY application that uses these will need the *Design assemblies at runtime. Also imho the name mono-designtime isn't optimal because it somehow suggests they are not needed at runtime which is not true. Greetings Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Sandy Armstrong Gesendet: Samstag, 8. August 2009 01:04 An: Andrew Jorgensen Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Moving *.Design to package mono-design On Fri, Aug 7, 2009 at 3:57 PM, Andrew Jorgensenajorgen...@novell.com wrote: We have a proposal to move System.Design.dll, System.Drawing.Design.dll, and System.Web.Extensions.Design.dll to a separate package to break the dependency between mono-web and mono-winforms. Tomboy has started to use System.Web so if we leave the packages as is it will suddenly depend on mono-winforms (where System.Design currently lives, which is needed by System.Web.Extensions.Design, currently in mono-web, which Tomboy doesn't need). ivanz suggests the new package be called mono-designtime. Please chime in if you have relevant information or a good reason to object. I favor this split. :-) Some additional info: * mono-winforms is a multi-megabyte package, and having a dependency on it becomes an issue for Tomboy and other apps that want to be on the openSUSE GNOME Live CD or other space-constrained environments * I cannot think of any situations where a user application would actually need *Design.dll * It looks bad to have Mono apps on Linux depend on a controversial package like mono-winforms Hope this helps, Sandy ___ 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] Moving *.Design to package mono-design
Unfortunately that leaves you with no option of avoiding aspnet pulling winforms through System.Design. :( And unfortunately, there seems to be no good way to split up the mono-web (ASP.NET) package, as the System.Web assembly seems to have quite a few responsibilities. Well all the Designer Stuff in the *Design assemblies is dynamically binding at runtime. So from a purely technical point of view there is no problem in not shipping the System.Design.dll or something like that with an application that uses anything from System.Web. Everything will work as long as you are not using any of the Design stuff (or using anything that uses the Design stuff). In fact it *should* even work when using the Design stuff, it just won't work the same way as originally expected. Afaik currently most of the Web stuff in System.Design is only stubbed out anyways, so the difference between shipping it or not should (in most cases) be minimal for *web* applications. 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] Bitmap manipulation - am I doing it right?
I don't know what you mean by Clone (I hope you don't meant the Clone Method, you shouldn't use this). Just make a copy of the relevant image part. If this is slower than making a Clone of the entire bitmap object you are doing something VERY wrong indeed. You are using Graphics.DrawImage for the copying, right? You could also use LockBits which is even faster, but that is unsafe and substantially more work. Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Stifu Gesendet: Dienstag, 31. März 2009 23:12 An: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Bitmap manipulation - am I doing it right? 2) How would you do this, technically? Because the only solution that comes to my mind is to clone a little part of my Bitmap to create the temporary copy... and making a sub-sized clone of a Bitmap is actually much slower than making a full clone. So it'd be actually slower than my current implementation. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bitmap manipulation - am I doing it right?
What you are doing is very inefficient. Two ideas: 1) Don't directly draw onto the image if you are only want so show something to the user and not really want to manipulate the image. You could easily use a rectangle control and show that above the image control. 2) Before you paint the rectangle copy the overpainted area into a temporary image. Then draw the rectangle. To (re)move the rectangle copy the data back from the temporary image (do not copy the entire image or create a new one) Andreas -Ursprüngliche Nachricht- Von: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Stifu Gesendet: Dienstag, 31. März 2009 10:10 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Bitmap manipulation - am I doing it right? Hello, I have an application that displays graphics, stored in a Bitmap. When you hover the concerned Panel, a square shows what tile you're currently highlighting. So if you move your cursor, the square moves too. What I'm doing is, each time I repaint my Panel, clone the Bitmap then draw the rectangle (square) on it. If I didn't clone it first and worked directly with the original Bitmap, then the squares would never go away, and keep on multiplying as you move your cursor over the Panel. So I'm just wondering: is cloning the right thing to do here? Or is there a better / more efficient way to achieve the same results, like some kind of temporary modifications to a Bitmap or whatever? (I'm using double buffering, so everything has to be on the same Bitmap) I already implemented clipping to improve performances, but I wanted to know if there was anything else I could do... Thanks. -- View this message in context: http://www.nabble.com/Bitmap-manipulation---am-I-doing-it-right--tp22800298p 22800298.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization
Is it possible that the serialization is correct and it is just your display
font missing the character?
Why even use another specific (28591) encoding for serialization?
Also mono 1.9.1 is ancient. Current is 2.2 and we are near 2.4, so you
should upgrade ;)
Andreas
-Ursprüngliche Nachricht-
Von: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von
voilierdusud
Gesendet: Dienstag, 24. März 2009 16:26
An: mono-devel-list@lists.ximian.com
Betreff: [Mono-dev] Serialization
Hi,
I have a problem when serializing an object.
I'm using following code but some string field contains character with
accent (encoding 8859-1). It's ok on windows with .NET but not with mono on
linux (accents are replace by '?' char)
...
using (TextWriter writer = new StreamWriter(completeFileName, true,
Encoding.GetEncoding(28591)))
{
xmlSerializer.Serialize(writer, processedObject);
}
...
Any idea ?
I'm using mono version 1.9.1
Thanks for your help
--
View this message in context:
http://www.nabble.com/Serialization-tp22682858p22682858.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unexpected compiler errors when using as keyword
Just as a very short note without looking in detail: IMHO C would always work because even if interpreted as (blah + o) as string it would be a correct statement (though it wouldn't make any sense to cast to string). So the assumption would be that it is just the precedence that is different in .Net and Mono. Happy hacking Andreas I've spent some quality time looking at parser output and the grammar and I'm having a hard time understanding why C works, but A doesn't. I'm also confused why C works at all since my interpretation of the grammar seems to imply that only putting as clauses in parenthesis will make them compatible with an additive-expression. So here are my questions: 1. Is this a known issue and is someone working on it? 2. Is my interpretation of the grammar(as specified in cs-parser.jay and/or in the ECMA-334 spec) correct and A C shouldn't work ? 3. Does anyone have suggestions on how I can get A to work. (I have a lot of instances of these and it would make me sad to have to put () around all them). Any help would be greatly appreciated. Thanks, Aaron ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 Preview 1 is out!!
Paint.Net contains large amounts of Windows platform specific code, so it will likely never run on mono cross-platform. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] Im Auftrag von sasha Gesendet: Freitag, 8. August 2008 12:46 An: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Mono 2.0 Preview 1 is out!! Paint.NET 3.30 not working with mono 2.0 I've started it in --debug mode, but there are too many bugs in WinForms implementation :-( ___ 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] Windows build
Could somebody please fix the windows build? It has been broken for ages now... Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
In Text
-Ursprüngliche Nachricht-
Von: Mirco Bauer [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 4. Juli 2008 01:52
An: mono-devel-list@lists.ximian.com
Cc: [EMAIL PROTECTED]
Betreff: Re: [Mono-patches] r107198 - trunk/mcs/class/corlib/System
On Thu, 2008-07-03 at 18:23 -0400, Andreas Nahr
([EMAIL PROTECTED]) wrote:
Author: andreas
Date: 2008-07-03 18:23:54 -0400 (Thu, 03 Jul 2008)
New Revision: 107198
Modified:
trunk/mcs/class/corlib/System/ChangeLog
trunk/mcs/class/corlib/System/IntPtr.cs
Log:
2008-07-04 Andreas Nahr [EMAIL PROTECTED]
* IntPtr: Fix parameter names, change internal name to accomodate
for parameter changes
Modified: trunk/mcs/class/corlib/System/ChangeLog
===
--- trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:22:43 UTC
(rev 107197)
+++ trunk/mcs/class/corlib/System/ChangeLog 2008-07-03 22:23:54 UTC
(rev 107198)
@@ -1,5 +1,9 @@
2008-07-04 Andreas Nahr [EMAIL PROTECTED]
+ * IntPtr: Fix parameter names, change internal name to accomodate
for parameter changes
+
+2008-07-04 Andreas Nahr [EMAIL PROTECTED]
+
* Predicate.cs:
* Object.cs:
* Nullable.cs
Modified: trunk/mcs/class/corlib/System/IntPtr.cs
===
--- trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:22:43 UTC
(rev 107197)
+++ trunk/mcs/class/corlib/System/IntPtr.cs 2008-07-03 22:23:54 UTC
(rev 107198)
@@ -57,44 +57,44 @@
#endif
public unsafe struct IntPtr : ISerializable
{
- private void *value;
+ private void *m_value;
I am not sure, but doesn't this break binary serialization
compatibility?
It shouldn't. IntPtr has an explicit Serializer implementation that deals
with setting correct names. I did not change those.
public static readonly IntPtr Zero;
#if NET_2_0
[ReliabilityContract (Consistency.MayCorruptInstance,
Cer.MayFail)]
#endif
- public IntPtr (int i32)
+ public IntPtr (int value)
{
- value = (void *) i32;
+ m_value = (void *) value;
afaik the goal can also be archived using this.value = value;
Did you try that? I actually had it this way and it refused to compile
because the value was deemed not initialized. I've got to admit that I
wasn't exactly sure why it didn't. Potential issue with the compiler maybe?
thats all, thanks.
--
Regards,
Mirco 'meebey' Bauer
PGP-Key ID: 0xEEF946C8
FOSS Developer[EMAIL PROTECTED] http://www.meebey.net/
PEAR Developer[EMAIL PROTECTED] http://pear.php.net/
Debian Developer [EMAIL PROTECTED] http://www.debian.org/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Sortkey.cs weirdness in corlib
I've seen that the SortKey class in System.Globalization is not used/compiled at all. Instead a identically named class from Mono.Globalization is used. My suggestion would be to a) delete the SortKey in the System.Globalization directory of corlib b) move the class from Mono.Globalization to System.Globalization any objections? Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
[EMAIL PROTECTED] Im Auftrag von Mirco Bauer
Gesendet: Freitag, 4. Juli 2008 12:59
An: Andreas Nahr
Cc: mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] [Mono-patches] r107198 -
trunk/mcs/class/corlib/System
public static readonly IntPtr Zero;
#if NET_2_0
[ReliabilityContract (Consistency.MayCorruptInstance,
Cer.MayFail)]
#endif
- public IntPtr (int i32)
+ public IntPtr (int value)
{
- value = (void *) i32;
+ m_value = (void *) value;
afaik the goal can also be archived using this.value = value;
Did you try that? I actually had it this way and it refused to
compile
because the value was deemed not initialized. I've got to admit that
I
wasn't exactly sure why it didn't. Potential issue with the compiler
maybe?
At least for me it works, using gmcs 1.9.1:
[EMAIL PROTECTED]:~$ cat test.cs
using System;
class Test
{
int value;
Test(int value)
{
this.value = value;
}
public static void Main ()
{
Test t = new Test(123);
Console.WriteLine(t.value);
}
}
Are you trying to make a joke? ;)
Of course this works with normal types. This is used thousands of times
throughout the class libraries.
But in *THIS* case with void * it does not seem to work. So this was the
easiest way to fix the problem.
Greetings Andreas
P.S. If you want to make further tests maybe mail me private and not through
the list to keep the noise low.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-patches] r107198 - trunk/mcs/class/corlib/System
This is used thousands of times throughout the class libraries.
But in *THIS* case with void * it does not seem to work. So this was
the easiest way to fix the problem.
Ok, I used a class and int as type. So here a test using an unsafe
struct and void* as member, just like IntPtr does:
[EMAIL PROTECTED]:~$ cat test.cs
using System;
unsafe class Test
{
int value;
Test(int value)
{
this.value = value;
}
public static void Main ()
{
Test t = new Test(123);
Console.WriteLine(t.value);
AnotherTest at = new AnotherTest(123);
Console.WriteLine((int) at.value);
}
}
public unsafe struct AnotherTest
{
internal void* value;
public AnotherTest(int value)
{
this.value = (void*) value;
}
}
[EMAIL PROTECTED]:~$ mono test.exe
123
123
Although it is interesting that this seems to work (by the way the problem was
that I couldn't even compile it). I still do not see the use of showing a test
that shows that there are situations in which it works. If you want to
reproduce the problem then I suggest that you take the Version of IntPtr (it’s
a small and simple type anyways) before my changes and then change the values
accordingly and then you will hopefully see the problem.
Then reduce it to the smallest case possible.
Then you would have to analyze the reason for it.
That (which could easily take one or more days) then leads you to maybe fix a
corner-case that probably nobody ever used (well exaggerating a little bit ;)
except the IntPtr struct.
Greetings Andreas
P.S. If you want to make further tests maybe mail me private and
not through the list to keep the noise low.
I don't think this is noise as you had issues with a possible compiler
bug, so allow other developers to join the discussion and comment on
the test-code.
I will not research any further here because imho it's just not worth my time
and there are far more important things to fix. Feel free to do if you like.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] to significantly shorten Char.cs
Hi Rodrigo,
very good suggestion ;)
Attached is a patch that only contains the Is* changes.
Happy Hacking
Andreas
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Rodrigo
Kumpera
Gesendet: Samstag, 28. Juni 2008 00:37
An: Andreas Nahr
Cc: mono-devel
Betreff: Re: [Mono-dev] [Patch] to significantly shorten Char.cs
Andreas,
How about splitting your patches in two? One with the lesser risky
CheckParameter changes and other with the Is*** changes.
The CheckParameter changes look lovely, go ahead commit then.
I would like to do some testing on other changes, that are more comple and
unfortunately I won't have time until late next week.
I know it's more work on your side, but it makes the review process easier
for both of us.
Thanks,
Rodrigo
On Thu, Jun 26, 2008 at 6:24 PM, Andreas Nahr
[EMAIL PROTECTED] wrote:
Well the main improvement is the shortening of the String-Parameter methods.
It does not affect performance negatively as far as I measured because the
methods now get inlined but were too large before.
I know that the code wasn't duplicated for performance reasons before,
because I actually wrote that code. Well most of Char anyways... ;)
IsWhiteSpace is now somewhat faster. Similar Prog from below (do not have
the original anymore) went from 21 sec total to 16,5 sec (AMD 3,2Ghz XP)
(testing one positive + one negative case). It simply saves some opcodes.
public static void Main()
{
int tickCount = Environment.TickCount;
for (int i = 0; i 0x3b9aca00; i++)
{
char.IsWhiteSpace('v');
}
Console.WriteLine((int) (Environment.TickCount - tickCount));
tickCount = Environment.TickCount;
for (int j = 0; j 0x3b9aca00; j++)
{
char.IsWhiteSpace(' ');
}
Console.WriteLine((int) (Environment.TickCount - tickCount));
}
And no, IsWhiteSpace did not get optimized away ;)
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
[EMAIL PROTECTED] Im Auftrag von Atsushi Eno
Gesendet: Donnerstag, 26. Juni 2008 23:25
An: 'mono-devel'
Betreff: Re: [Mono-dev] [Patch] to significantly shorten Char.cs
I have some comments even without reading your application/octet-stream
patch (I ususally don't read them).
- Sometimes we have some code pieces that look like duplicates
exactly because of performance improvements.
- For performance improvements there should be some benchmark
results with sources.
Atsushi Eno
Andreas Nahr wrote:
The attached patch reduces code duplication in Char by more than 130
lines
and improves the performance of some methods a little bit.
Somebody please have a short look...
Happy Hacking
Andreas
-
---
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Char.patch
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Patch] to significantly shorten Char.cs
The attached patch reduces code duplication in Char by more than 130 lines and improves the performance of some methods a little bit. Somebody please have a short look... Happy Hacking Andreas Char.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] to significantly shorten Char.cs
Well the main improvement is the shortening of the String-Parameter methods.
It does not affect performance negatively as far as I measured because the
methods now get inlined but were too large before.
I know that the code wasn't duplicated for performance reasons before,
because I actually wrote that code. Well most of Char anyways... ;)
IsWhiteSpace is now somewhat faster. Similar Prog from below (do not have
the original anymore) went from 21 sec total to 16,5 sec (AMD 3,2Ghz XP)
(testing one positive + one negative case). It simply saves some opcodes.
public static void Main()
{
int tickCount = Environment.TickCount;
for (int i = 0; i 0x3b9aca00; i++)
{
char.IsWhiteSpace('v');
}
Console.WriteLine((int) (Environment.TickCount - tickCount));
tickCount = Environment.TickCount;
for (int j = 0; j 0x3b9aca00; j++)
{
char.IsWhiteSpace(' ');
}
Console.WriteLine((int) (Environment.TickCount - tickCount));
}
And no, IsWhiteSpace did not get optimized away ;)
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
[EMAIL PROTECTED] Im Auftrag von Atsushi Eno
Gesendet: Donnerstag, 26. Juni 2008 23:25
An: 'mono-devel'
Betreff: Re: [Mono-dev] [Patch] to significantly shorten Char.cs
I have some comments even without reading your application/octet-stream
patch (I ususally don't read them).
- Sometimes we have some code pieces that look like duplicates
exactly because of performance improvements.
- For performance improvements there should be some benchmark
results with sources.
Atsushi Eno
Andreas Nahr wrote:
The attached patch reduces code duplication in Char by more than 130
lines
and improves the performance of some methods a little bit.
Somebody please have a short look...
Happy Hacking
Andreas
-
---
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Deployment
The System.Deployment namespace is in the System.Deployment.dll Assembly, not in mscorlib. The docs (e.g. http://msdn.microsoft.com/en-us/library/system.deployment.application.applicationdeployment.aspx) state this, too. Greetings A.Nahr -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] Im Auftrag von Paul Gesendet: Montag, 23. Juni 2008 23:56 An: mono-devel Betreff: [Mono-dev] System.Deployment Hi, I have a number of VB.NET programs from students that work fine under Win32, but fail when I try to build using MD. They are all calling System.Deployment which according to the docs is in mscorlib. I've added mscorlib to the references and removed System.Deployment (it's not available) and the code fails to build. What do I need to do to get a VB.NET app which calls System.Deployment to work? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Patch] Small optimization to String.Replace and StringBuilder.Replace
Did you time/measure this change?
- const int maxValue = 200; // Allocate 800 byte
maximum
+ // Allocate 800 byte maximum
+ int maxValue = Math.Min ((length + oldValue.Length -
1) / oldValue.Length, 200);
int* dat = stackalloc int[maxValue];
fixed (char* source = this, replace = newValue) {
int i = 0, count = 0;
@@ -1661,6 +1654,9 @@
}
i = found + oldValue.length;
}
+ if (count == 0)
+ return this;
+
int nlen = this.length + ((newValue.length -
oldValue.length) * count);
String tmp = InternalAllocateStr (nlen);
My assumption is that for small (common) cases this may produce a noticable
slowdown.
I'm fine with the count == 0 shortcut, but the exact calculation will
probably hurt performance.
Maybe a compromise would be
int maxValue = Math.Min (length, 200);
Happy Hacking
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:mono-devel-list-
[EMAIL PROTECTED] Im Auftrag von Juraj Skripsky
Gesendet: Montag, 16. Juni 2008 16:38
An: mono-devel
Betreff: [Mono-dev] [Patch] Small optimization to String.Replace and
StringBuilder.Replace
Hello,
Attached you'll find a patch which reduces the number of allocations
done in String.Replace and StringBuilder.Replace.
All unit tests pass.
Please review.
- Juraj
___
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 some obscure cases in Dictionary (small)
Thanks for testing. If nobody from the maintainers objects I'll commit. I've been looking for a testcase, but the error is not easily reproducible without unmanaged code. Greetings Andreas -Ursprüngliche Nachricht- Von: Juraj Skripsky [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 13. Juni 2008 14:32 An: Andreas Nahr Cc: 'mono-devel-list' Betreff: Re: [Mono-dev] Patch for some obscure cases in Dictionary (small) Hi Andreas, Your changes look good to me, it makes the code cleaner and leaner. I was the one who wrote (or rather re-wrote) the code you're changing, but I guess you need the okay-to-commit from one of the corlib maintainer(s). - Juraj On Thu, 2008-06-12 at 09:50 +0200, Andreas Nahr wrote: Re-sent without input file. Please test the patch and tell me if it is ok to apply. Does not seem to break anything for me, but did not test very extensively. You can get the input file from http://shootout.alioth.debian.org/download/knucleotide-input.txt Andreas While trying to optimize the k-nucleotide benchmark from Computer Language Shootout (or whatever) I stumbled across a corner case in Dictionary. Situation is: We are behaving different from MS.Net and current Mono behavior is somewhat illogical. But the case itself is surely outside of the spec ;) We are changing the indexer itself in the indexer (base problem, concrete is a bit more complex). Anyways this could be patched (it's slightly faster, too). Happy Hacking P.S. Am attaching the benchmark application and the input for it ( at console) P.P.S. I AM aware that doing stuff this way is asking for trouble ;) ___ 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 for some obscure cases in Dictionary (small)
OK I found some way to unit-test this. Unfortunately it only tests the incompatibility but not the problems that result because of it. Happy Hacking Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] Im Auftrag von Andreas Nahr Gesendet: Freitag, 13. Juni 2008 17:17 An: 'Juraj Skripsky' Cc: 'mono-devel-list' Betreff: Re: [Mono-dev] Patch for some obscure cases in Dictionary (small) Thanks for testing. If nobody from the maintainers objects I'll commit. I've been looking for a testcase, but the error is not easily reproducible without unmanaged code. Greetings Andreas -Ursprüngliche Nachricht- Von: Juraj Skripsky [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 13. Juni 2008 14:32 An: Andreas Nahr Cc: 'mono-devel-list' Betreff: Re: [Mono-dev] Patch for some obscure cases in Dictionary (small) Hi Andreas, Your changes look good to me, it makes the code cleaner and leaner. I was the one who wrote (or rather re-wrote) the code you're changing, but I guess you need the okay-to-commit from one of the corlib maintainer(s). - Juraj On Thu, 2008-06-12 at 09:50 +0200, Andreas Nahr wrote: Re-sent without input file. Please test the patch and tell me if it is ok to apply. Does not seem to break anything for me, but did not test very extensively. You can get the input file from http://shootout.alioth.debian.org/download/knucleotide-input.txt Andreas While trying to optimize the k-nucleotide benchmark from Computer Language Shootout (or whatever) I stumbled across a corner case in Dictionary. Situation is: We are behaving different from MS.Net and current Mono behavior is somewhat illogical. But the case itself is surely outside of the spec ;) We are changing the indexer itself in the indexer (base problem, concrete is a bit more complex). Anyways this could be patched (it's slightly faster, too). Happy Hacking P.S. Am attaching the benchmark application and the input for it ( at console) P.P.S. I AM aware that doing stuff this way is asking for trouble ;) ___ 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 DictionaryTest.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for some obscure cases in Dictionary (small)
Re-sent without input file.
Please test the patch and tell me if it is ok to apply. Does not seem to
break anything for me, but did not test very extensively.
You can get the input file from
http://shootout.alioth.debian.org/download/knucleotide-input.txt
Andreas
While trying to optimize the k-nucleotide benchmark from Computer
Language Shootout (or whatever) I stumbled across a corner case in
Dictionary.
Situation is: We are behaving different from MS.Net and current Mono
behavior is somewhat illogical. But the case itself is surely outside
of the spec ;) We are changing the indexer itself in the indexer (base
problem, concrete is a bit more complex).
Anyways this could be patched (it's slightly faster, too).
Happy Hacking
P.S. Am attaching the benchmark application and the input for it ( at
console)
P.P.S. I AM aware that doing stuff this way is asking for trouble ;)
Dictionary.patch
Description: Binary data
/* The Computer Benchmarks Game
* http://shootout.alioth.debian.org/
*
* contributed by Isaac Gouy
* modified by Antti Lankila for generics
* modified by A.Nahr for performance and throwing unneccesary stuff out
*/
using System;
using System.IO;
using System.Collections.Generic;
using System.Text;
public class program
{
public static void Main (string[] args)
{
string line;
StreamReader source = new StreamReader
(Console.OpenStandardInput ());
StringBuilder input = new StringBuilder (10240);
while ((line = source.ReadLine ()) != null)
{
if (line[0] == '' line.Substring (1, 5) == THREE)
break;
}
while ((line = source.ReadLine ()) != null)
{
char c = line[0];
if (c == '')
break;
if (c != ';')
input.Append (line);
}
KNucleotide kn = new KNucleotide (input.ToString
().ToUpperInvariant ());
input = null;
kn.WriteFrequencies (1);
kn.WriteFrequencies (2);
kn.WriteCount (GGT);
kn.WriteCount (GGTA);
kn.WriteCount (GGTATT);
kn.WriteCount (GGTAAATT);
kn.WriteCount (GGTAAATTTATAGT);
}
}
public class KNucleotide
{
private Dictionarystring, int frequencies = new Dictionarystring,
int ();
private string sequence;
public KNucleotide (string s)
{
sequence = s;
}
public void WriteFrequencies (int nucleotideLength)
{
GenerateFrequencies (nucleotideLength);
ListKeyValuePairstring, int items = new
ListKeyValuePairstring, int (frequencies);
items.Sort (SortByFrequencyAndCode);
int sum = sequence.Length - nucleotideLength + 1;
foreach (KeyValuePairstring, int each in items)
{
double percent = each.Value * 100.0 / sum;
Console.WriteLine ({0} {1:f3}, each.Key, percent);
}
Console.WriteLine ();
}
public void WriteCount (string nucleotideFragment)
{
GenerateFrequencies (nucleotideFragment.Length);
int count = 0;
if (frequencies.ContainsKey (nucleotideFragment))
count = frequencies[nucleotideFragment];
Console.WriteLine ({0}\t{1}, count, nucleotideFragment);
}
private void GenerateFrequencies (int length)
{
frequencies.Clear ();
for (int frame = 0; frame length; frame++)
KFrequency (frame, length);
}
private unsafe void KFrequency (int readingFrame, int k)
{
String knucleo = pre[k];
fixed (char* target = knucleo, source = sequence)
{
int n = sequence.Length - k + 1;
for (int i = readingFrame; i n; i += k)
{
for (int j = 0; j k; j++)
target[j] = source[i + j];
int value;
bool isOld = frequencies.TryGetValue (knucleo,
out value);
if (isOld)
frequencies[knucleo] = value + 1;
else
frequencies[new String (target, 0, k)]
= 1;
}
}
}
private String[] pre = {
, ., .., ..., , , .., , , , , ,
, , , , , , ..};
int
Re: [Mono-dev] Next part of string patch (replace). Please test.
Thanks for testing. Good catch! Fixed and added more testcases to check for that. Happy Hacking Andreas Von: Konstantin Triger [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 3. Juni 2008 13:38 An: Andreas Nahr Cc: mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] Next part of string patch (replace). Please test. Hello all, To my understanding, The following line: if (count = maxValue) should be: if (count maxValue) 2008/6/2 Andreas Nahr [EMAIL PROTECTED]: This time the change is much smaller ;) Adds some additional Unittests and some explanatory LAMESPECS. For additional explanation see the last String patch mail or the original mailing-list discussion. For me all Unittests (including the new ones) pass. Did not observe regressions. Happy Hacking Andreas P.S. After that only split is missing... ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Regards, Konstantin Triger RSS: http://feeds.feedburner.com/ktriger StringReplace.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Next part of string patch (replace). Please test.
This time the change is much smaller ;) Adds some additional Unittests and some explanatory LAMESPECS. For additional explanation see the last String patch mail or the original mailing-list discussion. For me all Unittests (including the new ones) pass. Did not observe regressions. Happy Hacking Andreas P.S. After that only split is missing... StringReplace.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Decimal performance
There are massive regressions in System.Data that seem to come from the changes in decimal.c Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] Im Auftrag von Zoltan Varga Gesendet: Montag, 2. Juni 2008 22:15 An: Leszek Ciesielski Cc: mono-devel-list Betreff: Re: [Mono-dev] System.Decimal performance Hi, The next mono release (2.0) will have better decimal performance, especially when doing divisions. Zoltan 2008/5/29 Leszek Ciesielski [EMAIL PROTECTED]: Hi, the company I work for builds finance-related software, so we use the Decimal type a lot. And in any computation-heavy program we find that the Mono implementation of the decimal type... well... let's just say it's not on par with MS.Net performance ;-) . Addition, substraction and multiplication lag a bit (2-4 times slower). However, division is at least 10 times slower, in some cases even 50x! I don't have any complex tests at hand right now, but a simple performance-measuring program is attached to the mail. There's also a java version (although BigDecimal is not a simple equivalent of System.Decimal as it has no upper bound on available precision). From my simple test the results are as follows: MS.Net 3.5 addition 2375 ms : 2354,156132 substraction 2140,625 ms : 2337,043868 multiplication 1734,375 ms : 189,08461995264 division 8468,75 ms : 29097,233616240416508043573961 Mono 1.9 Windows 2.0 profile addition 4812 ms : 2354,156132 substraction 4781 ms : 2337,043868 multiplication 3407 ms : 189,08461995264 division 61390 ms : 29097,233616240416508043573961 Mono svn-linux 2.0 profile addition 4201.837 ms : 2354.156132 substraction 4413.458 ms : 2337.043868 multiplication 4489.036 ms : 189.08461995264 division 61303.573 ms : 29097.233616240416508043573961 Java 1.6.0_06 addition 4640 ms : 2354.156132 substraction 3969 ms : 2337.043868 multiplication 2219 ms : 189.08461995264 division 33376 ms : 29097.233616240416508043573961 Has anyone done any performance tunining with the decimal type? Regards, Leszek 'skolima' Ciesielski -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ResourceReader patch
Is there any reason for not using structs? No sense in needlessly torturing the GC ;) Happy Hacking Andreas ResourceReader.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for String.cs
Attached are two versions of a patch for String. The one is the pure patch, the other also cleans up some unused stuff in related classes. Already mailed this to Miguel a few days ago, but did not get any feedback yet. Happy Hacking Andreas String.patch Description: Binary data String+FirstCleanup.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for String.cs
Sorry, but after working s long on this (series of) patches you somehow assume other people know the story, too. Obviously that was a misconception on my part ;) Just as a brief info: This patch is a part of a big patch that has been discussed for two? years on and off. And it was accepted by Miguel some time (months?) ago. However there were some regressions so it had to be reverted. The idea now is/was to commit smaller parts of it to get a better overview of where problems occurred. This is the 3rd last of those parts (the others are already committed). However as it affects really core parts I thought it would be better for some more people to try, especially as this was one of the two parts that actually caused the regressions back then (the cause has hopefully been fixed by now). Other parts in text. generic rant/ To make it easier (and this almost always means faster to) to review please keep an *updated* history with your patch (not everyone remembers every email he reads, it's easier for googling later and anyway it's likely some things have changed since then). Important things (from the reviewer point of view) is explaining: * Why the patch exists ? * to fix things ? Partly. It is part of the bigger string patch. It restructures string and replaces C implementation where left with managed code. It also concentrates the relevant code that is currently spread out though the corlib classlib and the runtime in string.cs. As part (sideeffect) of this it also fixes bugs in the current implementation. (String is/was in a really miserable state, especially when it comes to the 2.0 profile) * where are the bug number(s) ? * where are the unit tests ? Unit tests are already commited. I've added quite a load of them ;). Some of them are currently disabled because they fail against current mono. I'll add a patch to this post that removes the comment status from those. * NOTE: you can save time by including this, inside the patch, into the **required** ChangeLog entry * Why there is no new unit test part of the patch * even if you're adding new exceptions See above * Why you introduce unsafe code * performance ? * where's the data ? and I don't mean just numbers! where's the code ? how was it measured? on which architecture ? This has been discussed and posted to this list a long time ago. * moving stuff from icalls ? * what will be removed ? i.e. do we get more or less unsafe (C or C#) code to review ? Well basically it replaces unmanaged unsafe C with managed unsafe C# or managed safe C#. Once all parts are committed string-icall.c is mostly obsolete. The complete amount of unsafe code will be somewhat less because only parts are actually unsafe. On the other hand some new implementations are far more advanced than the old C code and thus a little bit longer. Also *clearly* state if you have executed the existing unit tests (and for each profile you did). For highly used code (like String) please state if you did a full bootstrap and execute unit tests (for all assemblies, all profiles). Without answers it's fairly likely most of them will be interpreted as a *negative*, so a job for the reviewer. I did test them on my machine in a bootstap and corlib unittest as far as possible with my setup (x86, Cygwin). Already mailed this to Miguel a few days ago, but did not get any feedback yet. He's likely busy with a lot of other things. Anyway mono-devel is the right place to post patches. I was somewhat unsure if he got the mail at all because there seemed to be some problem with our mail-contact shortly before that as he couldn't reach me. Note that most people able to review this already have a TODO plan for the next week and large patches often don't fit within them. Even less if the gains are unclear (e.g. no bug fixed) or the potential problems high (e.g. is it tested ?). Keep in mind that all the previous unanswered question are something that a reviewer would need to answer by himself (i.e. the more questions the more time it takes, the less likely someone has the time to review it). Anyway that's my own story on why some patches takes longer than others to be reviewed - or at least how you can help make it faster ;-) Thanks for the patch :) Sebastien StringTest.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch for String.cs
I had a look at the patches and I am happy to see these improvements in
String code.
Thanks
I have found several issues:
@@ -765,11 +732,13 @@
if (idx1 == idx2 len1 == len2
Object.ReferenceEquals (s1, s2))
return 0;
- if (options == CompareOptions.Ordinal)
- return CompareOrdinal (s1, idx1, len1, s2,
idx2, len2);
+ if (options == CompareOptions.Ordinal) {
+ return String.CompareOrdinalCaseInsensitive
(s1, idx1, s2, idx2, System.Math.Min (len1, len2));
+ }
#if NET_2_0
- if (options == CompareOptions.OrdinalIgnoreCase)
- return CompareOrdinalIgnoreCase (s1, idx1,
len1, s2, idx2, len2);
+ if (options == CompareOptions.OrdinalIgnoreCase) {
+ return String.CompareOrdinal (s1, idx1, s2,
idx2, System.Math.Min (len1, len2));
+ }
#endif
I think that CompareOrdinalCaseInsensitive and CompareOrdinal should be
switched.
Switched that. SimpleCollator was also just added as preview of possible
connected changes. It's not tested very well.
+ public int LastIndexOf (String value, int startIndex)
+ {
+ int max = startIndex;
+ if (max this.Length)
Others reference .length so this is inconsistent.
Length and length are completely mixed in String.cs. However as
public int Length {
get {
return length;
}
}
should get inlined anyways the difference shouldn't be noticeable. Maybe it
makes sense to unify that once the changes are complete. Maybe not ;)
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] JIT and Inlining - why doesn't it happen?
I just checked the R01/R02 methods and they both have 20 IL instructions
with 22 bytes of IL code, so this is pretty much a corner case. However the
Ch method that you mention has a mere 9 IL instructions and only 9 bytes of
IL code, so this does not explain why it doesn't get inlined if the
threshold is 20 bytes of IL.
Greetings
Andreas
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Alan
McGovern
Gesendet: Donnerstag, 1. Mai 2008 10:26
An: Rodrigo Kumpera
Cc: mono-devel
Betreff: Re: [Mono-dev] JIT and Inlining - why doesn't it happen?
Hi,
That makes sense. I was just quite surprised at the time that the methods
were not being inlined as they were only simple maths operations. I checked
monodis for one of the methods and it turned out to be 8 IL instructions,
which is probably 24 bytes, which would explain why it wasn't inlined.
Alan.
On Thu, May 1, 2008 at 12:24 AM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Well, the inliner basically eliminates the penalty from using properties and
empty constructors.
Increasing the inline threshold is tricky and might now be worthy as there
are too many situations that abort inlining. So it would significantly
increase JIT time for diminishing gains.
On Wed, Apr 30, 2008 at 6:38 PM, Alan McGovern [EMAIL PROTECTED]
wrote:
This method does not get inlined:
private uint Ch (uint u, uint v, uint w)
{
return (uv) ^ (~uw);
}
If that isn't inlined then don't ask me what kind of method *could* be
inlined by the JIT.
Alan.
On Wed, Apr 30, 2008 at 11:32 PM, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Mono only inline very short methods. Right now methods must have a body at
most 20 bytes long.
2008/4/30 Alan McGovern [EMAIL PROTECTED]:
I recently started doing a bit of optimisation work on the
hashing/cryptography classes in mono. When working on the managed SHA256
class[1], i noticed that mono isn't inlining what i'd consider some *very*
simple methods.
The helper methods which do the bitshifting (Ro0, Ro1, Ch, Maj etc) aren't
inlined! Each of these methods is only called once in the code. By manually
inlining those method calls, performance increased significantly - about
70%. Why isn't mono inlining these methods? Can mono be made inline these?
Alan.
[1]http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Sec
urity.Cryptography/SHA256Managed.cs?rev=46462
http://anonsvn.mono-project.com/viewcvs/trunk/mcs/class/corlib/System.Secur
ity.Cryptography/SHA256Managed.cs?rev=46462view=markup view=markup
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on wine redux
2008 at 11:07 AM, Michael Hutchinson [EMAIL PROTECTED] wrote: Actually, only managed C++ produces mixed mode assemblies, and only if it's not running in pure mode. Today, Mono can directly run a very large subset of .NET apps that were built on Windows with no or very few modifications. Got a list of commercial software which was written without any thought of portability to Mono, and which runs well on Mono? I see http://www.mono-project.com/Software, but that all seems to be apps that were specifically ported to Mono or written with Mono originally. Thanks, Dan It would likely be more fitting to have a list of pure .Net Applications that do NOT run on MONO. Afaik if there are any problems left they are most likely based on WinForms apps graphical glitches. 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] Somebody please test this String patch
I lost my SSH Key some while ago, so I don't have write access anymore to svn. Probably the most simple solution is to commit yourself. Happy Hacking Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Miguel de Icaza Gesendet: Sonntag, 23. März 2008 18:12 An: Andreas Nahr Cc: 'mono-devel' Betreff: Re: [Mono-dev] Somebody please test this String patch Hello, I have been running this for a few weeks, and I think this code can go in; Miguel On Fri, 2008-02-15 at 17:05 +0100, Andreas Nahr wrote: Tiny update for a wrong #if that prevented v1.0 classlibs from building Happy hacking Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andreas Nahr Gesendet: Mittwoch, 13. Februar 2008 21:56 An: 'Miguel de Icaza'; 'mono-devel' Betreff: Re: [Mono-dev] Somebody please test this String patch Thanks for testing Miguel, attached is a new patch (potentially the functional final version). It fixes the one remaining issue with Split (I doubt anybody would have hit this anyways :) Moreover it replaces the remaining internalcalls with managed code. Sometimes in a much more optimized way. It also adds some more unit tests for corner cases (some failing with current mono). The changes make lots of code in string-icall.c locale.c, TextInfo.cs and SimpleCollator.cs (and potentially other places) useless, however the code is currently not yet removed. Some raw performance numbers from internal tests: Unmanaged - Managed Concat/Join: 3946 - 3786 4216 - 4055 4076 - 4056 12989 - 12636 Replace (String, String): 17165 - 4617 (Important function for Regexes) IndexOf (Ordinal): 1482 - 1653 12690 - 9543 2443 - 1181 1262 - 651 Compare (Ordinal): 16333 - 5648 19277 - 3104 Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Miguel de Icaza Gesendet: Sonntag, 10. Februar 2008 19:07 An: Andreas Nahr Cc: 'mono-devel' Betreff: Re: [Mono-dev] Somebody please test this String patch Hello Andreas, Anybody? Apart from a very small issue this could be applied to mono and no feedback at all? I have applied this to my tree, and will be using it on my desktop computer all week. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Regression in r99253 trunk/mcs/class/System.Design/System.ComponentModel.Design?
If I understand the changes correctly with the patch the list will now repopulate with any change. This makes the class unusable in a lot of situations (every situation where population is slow in the first place). Moreover this is not the case in .Net. Is there any special goal why the existing code is changed? (changelog is unspecific) Greetings Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Possible bug in r97246 - trunk/mcs/class/System.Drawing/System.Drawing
The change in r97246 is likely buggy, because the comparison is now done on the current locale but should likely be ordinalIgnoreCase or InvariantIgnoreCase. Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with national character set on ODBC connection
Don't use mkbundle in the first place.
I doubt that it is able to magically embedd just the I18N resources you
want (because I18N uses heavy reflection and the needed ones are not
specified).
If it is possible to change your database/datasource to return Unicode it
might work, though.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag
von Torello Querci
Gesendet: Mittwoch, 13. Februar 2008 18:01
An: Mono-devel-list@lists.ximian.com
Betreff: [Mono-dev] Problem with national character set on
ODBC connection
Hi to all .
I try to make an ODBC connection on windows environment.
Using normal ascii character that code work fine, but if
there is some national character, the result is wrong.
The result is wrong only if I make a bundle, not if I use
mono program_name.exe or if I use .NET.
I tried both the 1.2.6 and the 1.9 preview and the result is the same.
Is there a bug or I wrong something when generate the bundle
To generate the bundle I simply use this command:
mkbundle2 --deps -o odbx2xml.exe program.exe
Best Regards, Torello.
The testing database is an access file with one table named users
with 3 column: name, surname, description with only one row
Here you can find the code:
--
using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;
using System.Data.Odbc;
namespace test_odbc
{
class testOdbc : IDisposable
{
private System.Data.Odbc.OdbcConnection connection = null;
public testOdbc(string connectionString)
{
connection=new OdbcConnection(connectionString);
try
{
connection.Open();
}
catch (Exception ex)
{
connection = null;
System.Console.Out.WriteLine(Exception
opening the database connection: + ex.Message);
}
return;
}
public System.Data.Common.DbDataReader
getRawData(string sqlQuery)
{
System.Data.Odbc.OdbcCommand
command=connection.CreateCommand();
command.CommandText = sqlQuery;
command.CommandType = System.Data.CommandType.Text;
OdbcDataReader reader = command.ExecuteReader();
return reader;
}
public System.Collections.ArrayList
getListOfFields(System.Data.Common.DbDataReader reader)
{
ArrayList fieldNameList = new ArrayList();
System.Data.DataTable dataTable = reader.GetSchemaTable();
foreach (System.Data.DataRow row in dataTable.Rows)
{
if
(!fieldNameList.Contains(row[Co6lumnName].ToString())) {
fieldNameList.Add(row[ColumnName].ToString());
}
}
dataTable.Dispose();
return fieldNameList;
}
public void Dispose()
{
if (connection != null)
{
connection.Close();
}
}
static void Main(string[] args)
{
testOdbc odbc = new testOdbc(Dsn=test);
System.Data.Common.DbDataReader reader =
odbc.getRawData(select * from users);
while (reader.Read())
{
for (int i = 0; i reader.FieldCount; i++)
{
object obj = reader.GetValue(i);
System.Console.Out.WriteLine(column + i +
data: + reader.GetValue(i).ToString());
}
System.Console.Out.WriteLine(-);
}
}
}
}
___
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] Somebody please test this String patch
Anybody? Apart from a very small issue this could be applied to mono and no feedback at all? Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andreas Nahr Gesendet: Donnerstag, 31. Januar 2008 22:42 An: 'mono-devel' Betreff: Re: [Mono-dev] Somebody please test this String patch Attached is a new version. As far as I can tell with a cygwin setup it passes all relevant unittests and is able to compile mono without any problems. It also adds a few unittest for cases that are currently incorrectly implemented in the string class. Happy Hacking Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andreas Nahr Gesendet: Montag, 28. Januar 2008 01:52 An: 'mono-devel' Betreff: [Mono-dev] Somebody please test this String patch This patch tries to get string a little bit out of its miserable shape: It fixes several bugs, and implements the majority of the remaining internalcalls with optimized managed code, giving performance increases for the most cases (sometimes quite a lot). Fixed is: Bugs in parameterchecks for StartsWith, IndexOf, LastIndexOf Marked possible bug in: Compare Managed Implementations of: PadRight, PadLeft, LastIndexOfAny, StringCopy, Trim, TrimStart, TrimEnd, Split (Char versions), ToCharArray It is not yet completely tested, but it would be nice if somebody else could help a little bit - it's an important class after all ;) The patch also makes most of the String-icall.c file obsolete. Some raw perfomance numbers for tests I did: Trim: 1813 - 1290 631 - 550 1332 - 421 7441 - 2754 6319 - 9303 Split: 10174 - 5718 982 - 871 7921 - 7170 26809 - 7980 18506 - 11290 Pad: 8021 - 8100 1612 - 1663 841 - 861 1642 - 1682 821 - 71 LastIndexOfAny: 2253 - 2243 1773 - 1362 6990 - 6470 1883 - 2240 831 - 2240 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Somebody please test this String patch
Attached is a new version. As far as I can tell with a cygwin setup it passes all relevant unittests and is able to compile mono without any problems. It also adds a few unittest for cases that are currently incorrectly implemented in the string class. Happy Hacking Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Andreas Nahr Gesendet: Montag, 28. Januar 2008 01:52 An: 'mono-devel' Betreff: [Mono-dev] Somebody please test this String patch This patch tries to get string a little bit out of its miserable shape: It fixes several bugs, and implements the majority of the remaining internalcalls with optimized managed code, giving performance increases for the most cases (sometimes quite a lot). Fixed is: Bugs in parameterchecks for StartsWith, IndexOf, LastIndexOf Marked possible bug in: Compare Managed Implementations of: PadRight, PadLeft, LastIndexOfAny, StringCopy, Trim, TrimStart, TrimEnd, Split (Char versions), ToCharArray It is not yet completely tested, but it would be nice if somebody else could help a little bit - it's an important class after all ;) The patch also makes most of the String-icall.c file obsolete. Some raw perfomance numbers for tests I did: Trim: 1813 - 1290 631 - 550 1332 - 421 7441 - 2754 6319 - 9303 Split: 10174 - 5718 982 - 871 7921 - 7170 26809 - 7980 18506 - 11290 Pad: 8021 - 8100 1612 - 1663 841 - 861 1642 - 1682 821 - 71 LastIndexOfAny: 2253 - 2243 1773 - 1362 6990 - 6470 1883 - 2240 831 - 2240 String.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Somebody please test this String patch
This patch tries to get string a little bit out of its miserable shape: It fixes several bugs, and implements the majority of the remaining internalcalls with optimized managed code, giving performance increases for the most cases (sometimes quite a lot). Fixed is: Bugs in parameterchecks for StartsWith, IndexOf, LastIndexOf Marked possible bug in: Compare Managed Implementations of: PadRight, PadLeft, LastIndexOfAny, StringCopy, Trim, TrimStart, TrimEnd, Split (Char versions), ToCharArray It is not yet completely tested, but it would be nice if somebody else could help a little bit - it's an important class after all ;) The patch also makes most of the String-icall.c file obsolete. Some raw perfomance numbers for tests I did: Trim: 1813 - 1290 631 - 550 1332 - 421 7441 - 2754 6319 - 9303 Split: 10174 - 5718 982 - 871 7921 - 7170 26809 - 7980 18506 - 11290 Pad: 8021 - 8100 1612 - 1663 841 - 861 1642 - 1682 821 - 71 LastIndexOfAny: 2253 - 2243 1773 - 1362 6990 - 6470 1883 - 2240 831 - 2240 String.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug in todays WebBrowser commit
There is a bug in the todays commit to Windows Forms Webbrowser:
+ // from http://www.w3.org/TR/html401/index/elements.html
+ public bool CanHaveChildren {
+ get {
+ string tag = this.TagName;
+ switch (tag.ToLower ()) {
+ case area:
+ case base:
+ case basefont:
+ case br:
+ case col:
+ case frame:
+ case hr:
+ case img:
+ case input:
+ case isindex:
+ case link:
+ case meta:
+ case param:
+ return false;
+ break;
+ default:
+ return true;
+ break;
+ }
+ }
+ }
It should be tag.ToLowerInvariant () because HTML-Tags are not dependent on
the current system locale ;)
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for String.Trim
Hi,
The attached patch implements String.Trim and the related methods in pure
managed code. It also contains a few optimizations that will speed up the
calls by a considerable amount. A big goal was to optimize common cases
(like the Trim call without parameters).
From some testing:
H .Trim(): 7441 - 2754 (+170%)
Test.Trim(null) : 1332 - 421 (+216%)
HAAHAH.Trim( new Char[] { 'A', 'B', 'C', 'D', 'E', 'F', 'G', '
' }): 631 - 550 (+14%)
HAAHAH.TrimEnd(): 1820 - 1290 (+41%)
tests with custom trims AND lots of characters that get trimed like:
H .Trim( new Char[] { 'A', 'B', 'C', 'D', 'E', 'F', 'G', '
' }): 6350 - 9303 (-46%)
got slower. The reason for that is obviously that the c-code gets better
optimization than the c# code and the overhead of the managed impl. is a
little bit higher.
Please review and commit the patch.
Other small changes:
* Added MonoTodos to some methods that are currently incorrectly implemented
* Added a CharCopy
* Slightly optimized the Concat Methods
The patch does not remove the unused code from mono itself as I'm not really
comfortable hacking inside the runtime, feel free to remove the now-unused
ves_icall_System_String_InternalTrim in string-icalls.
Greetings
Andreas
String.patch
Description: Binary data
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
I like the patch a lot and am looking forward to see some final speed results. On the other hand when taking into account the importance and size of the patch several people should look over it ;) Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Mittwoch, 9. Januar 2008 10:03 An: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited Hi, Miguel. Can I go ahead and commit this important patch? Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyal Alaluf Sent: 06 January 2008 16:34 To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace inMono revisited Hi, all. I have attached a patch following Andreas suggestions below. Please review, especially the metadata part. I saw once that Mono checks compatibility of Mscorlib with the runtime, is this happenening automatically whenever an internal call is added? BTW, since now the numberFormatter tables become arrays of magic numbers in mono/metadata, is there a place where I should put the program that generates these numbers? Thanks, Eyal. -Original Message- From: Andreas Nahr [mailto:[EMAIL PROTECTED] Sent: 04 January 2008 00:26 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 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/metada ta/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] [SPAM] Re: Tests failures when running on MS.NET
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Gert Driesen Gesendet: Mittwoch, 9. Januar 2008 18:06 An: Atsushi Eno; Eyal Alaluf Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] Tests failures when running on MS.NET - Original Message - From: Atsushi Eno [EMAIL PROTECTED] To: Eyal Alaluf [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Wednesday, January 09, 2008 2:38 PM Subject: Re: [Mono-dev] Tests failures when running on MS.NET Hello, Agreed. If there's no objection I'd welcome such a change (or will do if no one does but not sure when). Having it in managed code (where it's easier to have different tables for each profile) is not an option I assume? Imho the problem is that this option would need a lot of research from somebody very familiar with the core OS level. We had that discussion quite a few year back and this were some results (as far as I can remember): Embedding will give you: * Automatic memmapping through the OS without any additional work to do (So we don't (have to) care about which part of tables to load into memory and which not) OSs are usually good at doing that. * No hassle with endianess. The Runtime is Arch dependent anyways, so you get the correct endianess with embedded tables. * Source code visibility. You can change/inspect (by hand) individual values. * Does not add any additional complexity to the build process. * Already existing and implemented Disadvantages are potentially: * No easy way for different versions. * You may include things in the runtime which are not needed for a specific application that would better be included in a specific assembly. * Bloats the runtime size. * To add a new/change a table you always have to touch both runtime and classlibrary. One of the solutions I found back then that MAY be possible (did not have the time to completely research it): Embed the data tables into the specific assembly (Into the manifest) as a binary data blob. This removes the disadvantages above however will come with a host of new problems: * The data would have to be binary. Which means you need toolapps to create it (this is already true for some/most of the tables anyways) * You would need a way to get a pointer to the data fast without a lot of overhead (Current overhead is just one internalcall and a single line of C code) * Unclear if you still get free memmapping (showstopper if you need to preload all table data manually) * The class library (potentially) becomes arch-dependent because the embedded binary data is arch-dependent (No good way to solve: Either include both doubling size or live with the fact and ship arch-dependent libraries) * More complicated build process that needs additional steps to create/embed the binary data. * Somebody has to do it 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] [SPAM] Re: [PATCH] ToString() performace in Mono revisited
Are you sure? Besides the potential KB/MBs of memory wasted for that we pay a startup performance penalty so that it is probably at least 500% slower than now (Yes that is 5 Mio). Imho for ANYTHING but running on the server this would be completely useless. In that situation I'd actually prefer the original code any time. Greetings Andreas -Ursprüngliche Nachricht- Von: Zoltan Varga [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Januar 2008 23:09 An: Andreas Nahr Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list@lists.ximian.com Betreff: Re: [Mono-dev] [SPAM] Re: [PATCH] ToString() performace in Mono revisited Hi, I like the original version which contained managed arrays better. The new version might use less memory, but it contains lots of unsafe code using pointers, and this will become a problem when we want to do a security audit for moonlight. Zoltan On Jan 9, 2008 7:45 PM, Andreas Nahr [EMAIL PROTECTED] wrote: I like the patch a lot and am looking forward to see some final speed results. On the other hand when taking into account the importance and size of the patch several people should look over it ;) Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Mittwoch, 9. Januar 2008 10:03 An: Miguel de Icaza Cc: mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] [PATCH] ToString() performace in Mono revisited Hi, Miguel. Can I go ahead and commit this important patch? Thanks, Eyal. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eyal Alaluf Sent: 06 January 2008 16:34 To: Andreas Nahr; Prakash Punnoor; mono-devel-list@lists.ximian.com Cc: Atsushi Eno; Miguel de Icaza; Juraj Skripsky Subject: Re: [Mono-dev] [SPAM] Re: [SPAM] Re: ToString() performace inMono revisited Hi, all. I have attached a patch following Andreas suggestions below. Please review, especially the metadata part. I saw once that Mono checks compatibility of Mscorlib with the runtime, is this happenening automatically whenever an internal call is added? BTW, since now the numberFormatter tables become arrays of magic numbers in mono/metadata, is there a place where I should put the program that generates these numbers? Thanks, Eyal. -Original Message- From: Andreas Nahr [mailto:[EMAIL PROTECTED] Sent: 04 January 2008 00:26 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 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/metada ta/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 ___ Mono-devel
Re: [Mono-dev] [SPAM] [PATCH] Simplifying/optimizing CodeGenerator.cs
Is there any specific reason for the patch? My assumption would be that your patch has a *much* higher memory overhead AND is probably considerably slower than the current implementation. Also I personally find the original code simpler than your code (despite being a little bit longer - this is probably also only true for source lines but not for generated IL bytes). The changes in GeneratePrimitiveExpression are probably ok (saves the typeof's). Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Juraj Skripsky Gesendet: Sonntag, 6. Januar 2008 22:30 An: mono-devel-list@lists.ximian.com Betreff: [SPAM] [Mono-dev] [PATCH] Simplifying/optimizing CodeGenerator.cs Hi, Attached you'll find a patch for CodeGenerator.cs (in System.CodeDom.Compiler). It simplifies two methods considerably and might also bring a small performance improvement (perf. tests pending). All unit tests pass. May I commit? - Juraj ___ 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
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] [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] [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. Otherwise a single Console.WriteLine (1.ToString()); will get an EXTREMELY slow operation when you need to init a whole array just for a (potentially) single conversion. Greetings Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Eyal Alaluf Gesendet: Montag, 31. Dezember 2007 13:24 An: Juraj Skripsky; Atsushi Eno Cc: Miguel de Icaza; mono-devel-list@lists.ximian.com Betreff: [SPAM] Re: [Mono-dev] ToString() performace in Mono revisited Hi, all. Thanks for the feedback. The amount of used memory is indeed not appropriate for small devices and is not economic enough. The 'DblExpTab' is essential in order for the double ToString to be efficient. As for the other two arrays they cache a simple arithmetic caclcualtion. I'll therefore eliminate the '_decHexLen' array and use static readonly int[] _decHexDigits = new int [100]; I'll make DblRep into a struct and remove one member out of it (and slightly improve the double.ToString() perf along the way). This will change the allocation size to 100 * 4 + 2048 * (3 * 4) = ~25K. The performance impact is betweek 3-10% overall for simple ToString() depending on the hardware. Eyal. -Original Message- From: Juraj Skripsky [mailto:[EMAIL PROTECTED] Sent: 30 December 2007 19:34 To: Atsushi Eno Cc: Eyal Alaluf; Miguel de Icaza; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] ToString() performace in Mono revisited Hello, I think the following two arrays account for most of those 300KB: static readonly int[] _decHexDigits = new int [1]; static readonly int[] _decHexLen = new int [0x1]; The first one consumes almost 40KB, the second one 256KB... The DblExpTab array uses 2048 * 4 = 8KB and its referenced DblRep objects 2048 * (8 + 4 * 4) = 48KB. This means a total of 56KB. Turning DblExbTab into a struct would reduce this to 2048 * (4 * 4) = 32KB. - Juraj On Mon, 2007-12-31 at 00:19 +0900, Atsushi Eno wrote: Hello, Kazuki pointed out that the static initialization part of NumberFormatter allocates 300KB. It is probably here: public static readonly DblRep[] DblExpTab = new DblRep [ExponentMax + 1]; It does not look good. Atsushi Eno Eyal Alaluf wrote: With the attchments zipped to reduce size. * From: * [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Eyal Alaluf *Sent:* 27 December 2007 17:28 *To:* mono-devel-list@lists.ximian.com *Cc:* Miguel de Icaza *Subject:* [Mono-dev] ToString() performace in Mono revisited I got complaints that the font color within the table is white so this is a resent J Hi, all. Attached is a redesigned implementation of the NumberFormatter class. The patch includes a new algorithm for float and double ToString implementation that improves performance by a factor of 25(!) and upto 440(!!!). The patch includes further improvements to integer /ToString/ as well as Andreas suggestion of avoiding calling /NumberFormatInfo.CurrentInfo/ in the case of integer types default /ToString()/ implementation. This patch should improve Mono's performance in important use cases such as web-services where primitive /ToString/ performance is an important factor. The following is a table showing the improvements for the different primitive types using the patch. All the results are in milliseconds and for a run of 10,000,000 iterations with warm-up of 10,000,000 iterations as well. Mono 1.2.6 Patch Improvement 12345.ToString(G) 10079 7328 1.37 12345L.ToString(G) 13203 7297 1.81 0.12345.ToString(G) 323750 13047 24.8(!) 1.2345E-200.ToString(G) 6376500 14328 445(!!!) 0.12345m.ToString(G) 51078 9875 5.2 12345.ToString() 12406/7781 5687 2.2/1.37 12345L.ToString() 281090 4006 3897 72.1(!!) 1.03 1.2345E-200.ToString(G) 5686000 12345.ToString(G)/!) and the second is after applying Andreas suggestion on top of Mono 1.2.6. The following are the results of the new algorithm compared
Re: [Mono-dev] [SPAM] Re: [PATCH] Implement support for .emitbyte directive onilasm
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: 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] [U-SPAM] Re: String.GetHashCode()
Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean to store if the hash is already computed (as e.g. 0 is a valid hash, too). You could assume that any string over N would contain the precomputed hashcode immediately after the string in a sizeof(IntPtr) aligned 32-bit location. I don't think precomputing (a.k. non-lazy init) may be a good thing. I for one have quite some applications that handle enormous amount of strings. However none of these Strings ever needs to compute the hashcode. I'd rather pay 1 (or 4) additional bytes and not precompute it. However for other projects things will be different... 5) GetHashCode should never be called for a string that is not yet fully built (like in StringBuilder), so there is no worry aout the string changing after the hash code field has been set Well string at least contains: internal unsafe void InternalSetChar (int idx, char val) internal unsafe void InternalSetLength (int newLength) Which may be usefull for more advanced optimizations in case they aren't already used. 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] [U-SPAM] Re: String.GetHashCode()
Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean to store if the hash is already computed (as e.g. 0 is a valid hash, too). And then you would need one additional check for this boolean per call. And don't forget that strings within the corelib ARE mutable to some extent. Greetings Andreas _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Alan McGovern Gesendet: Samstag, 1. Dezember 2007 17:22 An: Robert Jordan Cc: mono-devel-list@lists.ximian.com Betreff: [U-SPAM] Re: [Mono-dev] String.GetHashCode() Also, just looking at the string source a bit more closely, it has a GetCaseInsensitiveHashcode method too, so i'd assume that would need to be cached too which would mean 8 bytes would be needed. This wouldn't scale well. Fair enough. Twas just an idea. Alan. On Dec 1, 2007 4:09 PM, Robert Jordan [EMAIL PROTECTED] wrote: Tinco Andringa wrote: (Woops, only replied to kamil) If Jerome is right and the overhead is only 4 bytes, then overhead shouldn't be a problem at all. The worst case size of a string would be 1 character, of 2 bytes + something to end it with, like an int containing its length, 2 bytes, or a terminating character, probably 2 bytes too. Making it at least 4 bytes. A worst case scenario of Look at a heavy string consumer: [g]mcs. The average string length it has to process is probably only 4-5 chars long. That's roundabout 12 bytes. Adding 4 bytes for the hash code is a huge overhead that only pays out if GetHashCode is called frequently, but this is definitely not a common scenario for most of the strings. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ToString() performace in Mono
Forgot to post some numbers about memory use (100 iterations):
New:
29MB StringBuilder
23MB NumberFormatter
21MB Byte[]
=
73MB Total
Old:
76MB StringBuilder
25MB Strings
23MB NumberFormatter
21MB Byte[]
=
146MB Total
So nearly exactly 50% saved Memory allocations ;)
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Andreas
Nahr
Gesendet: Montag, 26. November 2007 19:21
An: 'Kazuki Oikawa'; 'pablosantosluac'
Cc: mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] ToString() performace in Mono
The following code (add to NumberFormatter) and redirect the ToStrings
improves performance even more:
Old Formatter: 1266
New Formatter with negative number: 953
New Formatter with positive number: 750
Tested on Windows XP, Mono 1.2.5
internal static string FormatInteger (ref NumberStore ns)
{
// Add one additional char for default sign, one for
potential 0-padding
StringBuilder cb = new StringBuilder
(ns.IntegerDigits + 2);
if (!ns.Positive !ns.CheckZeroOnlyInteger ())
cb.Append
(NumberFormatInfo.CurrentInfo.NegativeSign);
ns.AppendIntegerString (ns.IntegerDigits 0 ?
ns.IntegerDigits : 1, cb);
return cb.ToString ();
}
The additional performance in Comparison to Kazuki Oikawa suggestion is
mainly gained through not retrieving NumberFormatInfo.CurrentInfo in cases
where it's not needed (and other small things like ref struct).
NumberFormatInfo.CurrentInfo should be optimized anyways. It just shouldn't
be as slow as it is as it is likely used in other situations, too.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Kazuki
Oikawa
Gesendet: Samstag, 24. November 2007 06:02
An: pablosantosluac
Cc: mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] ToString() performace in Mono
Hi.
This patch improves ToString performance (30% faster).
Running on Opteron 270 (2GHz), Gentoo Linux 2007.0 x86_64 $ mono hoge.exe
val is 599 and time 7008 (before) $ mono hoge.exe val is 599 and
time 5078 (after)
Current code is use G format but this equals D format when precision is
not defined and value is integer.
Best regards.
--
Kazuki Oikawa
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ToString() performace in Mono
The following code (add to NumberFormatter) and redirect the ToStrings
improves performance even more:
Old Formatter: 1266
New Formatter with negative number: 953
New Formatter with positive number: 750
Tested on Windows XP, Mono 1.2.5
internal static string FormatInteger (ref NumberStore ns)
{
// Add one additional char for default sign, one for
potential 0-padding
StringBuilder cb = new StringBuilder
(ns.IntegerDigits + 2);
if (!ns.Positive !ns.CheckZeroOnlyInteger ())
cb.Append
(NumberFormatInfo.CurrentInfo.NegativeSign);
ns.AppendIntegerString (ns.IntegerDigits 0 ?
ns.IntegerDigits : 1, cb);
return cb.ToString ();
}
The additional performance in Comparison to Kazuki Oikawa suggestion is
mainly gained through not retrieving NumberFormatInfo.CurrentInfo in cases
where it's not needed (and other small things like ref struct).
NumberFormatInfo.CurrentInfo should be optimized anyways. It just shouldn't
be as slow as it is as it is likely used in other situations, too.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Kazuki
Oikawa
Gesendet: Samstag, 24. November 2007 06:02
An: pablosantosluac
Cc: mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] ToString() performace in Mono
Hi.
This patch improves ToString performance (30% faster).
Running on Opteron 270 (2GHz), Gentoo Linux 2007.0 x86_64 $ mono hoge.exe
val is 599 and time 7008 (before) $ mono hoge.exe val is 599 and
time 5078 (after)
Current code is use G format but this equals D format when precision is
not defined and value is integer.
Best regards.
--
Kazuki Oikawa
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] ToString() performace in Mono
There seem to be some low-hanging fruit there. Actually I did some
optimizations some years ago, but some were rejected because of possible
code bloat.
Here are some things in the current implementation that could likely be
improved:
1) ToString calls FormatGeneral, which is the most complex Formatting. Is
that really needed for a parameterless call with the Default FormatProvider?
2) internal static string FormatGeneral (NumberStore ns)
{
return FormatGeneral (ns, -1,
NumberFormatInfo.CurrentInfo, true, false);
}
Calls into a more specific FormatGeneral version with a lot of fixed
parameters. It would be possible to drop quite a few of them with a specific
implementation (or not call FormatGeneral at all (see 1))
3) There seem to be some bad magic numbers (assumptions) in FormatGeneral:
StringBuilder cb = new StringBuilder (ns.IntegerDigits + precision + 16);
This means we overallocate for every number (seems like it might be some
kind of max). The problem is that once StringBuilder.ToString() is called it
will throw away and recreate the string if a string is less than half
capacity. With the +16 this is basically guaranteed for any but the most
complex formattings. It would be better to choose a realistic value and then
let StringBuilder expand if neccessary (like ns.IntegerDigits + precision +
1)
4) FormatNumber has the same problem as in 3:
StringBuilder sb = new StringBuilder(ns.IntegerDigits * 3 + precision);
In fact the *3 is even more bogus...
5) another huge CPU-sink is the following: 1062,500
System.Globalization.NumberFormatInfo::get_CurrentInfo()
One of the problems seems to be the following code in Thread:
public CultureInfo CurrentCulture {
get {
if (in_currentculture)
/* Bail out */
return CultureInfo.InvariantCulture;
CultureInfo culture =
GetCachedCurrentCulture ();
if (culture != null)
return culture;
This means we need a call to GetCachedCurrentCulture (an internalcall) once
for retrieving anything up the chain. Perhaps it would be possible to find
another mechanism to do it like adding a bool isChanged that gets modified
by the runtime so we don't need to do that InternalCall every time
if (isChanged)
CultureInfo culture =
GetCachedCurrentCulture ();
if (culture != null)
return culture;
Attached is a profile on Windows/Mono 1.2.5:
val is 59 and time 9047
Total time spent compiling 453 methods (sec): 0,07813
Slowest method to compile (sec): 0,01563:
System.Threading.Thread::GetCachedCurrentCulture()
Time(ms) Count P/call(ms) Method name
9109,375 1 9109,375
compareCompare.Class1::runtime_invoke_void_string[](object,intptr,intptr,int
ptr)
Callers (with count) that contribute at least for 1%:
9109,375 1 9109,375 compareCompare.Class1::Main(string[])
Callers (with count) that contribute at least for 1%:
1 100 %
compareCompare.Class1::runtime_invoke_void_string[](object,intptr,intptr,int
ptr)
8906,250 660,015 System.Int32::ToString()
Callers (with count) that contribute at least for 1%:
60 99 % compareCompare.Class1::Main(string[])
7531,250 660,013
System.NumberFormatter::FormatGeneral(NumberFormatter/NumberStore)
Callers (with count) that contribute at least for 1%:
66 100 % System.Int32::ToString()
5750,000 660,010
System.NumberFormatter::FormatGeneral(NumberFormd
by the runtime int,Number
FormatInfo,bool,bool)
Callers (with count) that contribute at least for 1%:
66 100 %
System.NumberFormatter::FormatGeneral(NumberFormatter/NumberStore)
1609,375 640,003
.NumberStore::AppendIntegerString(int,StringBuilder)
Callers (with count) that contribute at least for 1%:
63 99 %
System.NumberFormatter::FormatGeneral(NumberFormatter/NumberStore,int,Number
FormatInfo,bool,bool)
1109,375 660,002 System.Text.StringBuilder::ToString()
Callers (with count) that contribute at least for 1%:
63 99 %
System.NumberFormatter::FormatGeneral(NumberFormatter/NumberStore,int,Number
FormatInfo,bool,bool)
1062,500 6000150,002
System.Globalization.NumberFormatInfo::get_CurrentInfo()
Callers (with count) that contribute at least for 1%:
66 99 %
System.NumberFormatter::FormatGeneral(NumberFormatter/NumberStore)
890,625 6001760,001
Re: [Mono-list] [Mono-dev] System.CodeDom.Compiler and Debugging
Hi, akaik there is no integrated debugger support in any of the class libraries. Neither through CodeDom, nor through Reflection.Emit. You should be able to attach an external debugger (Mono or .Net) however this is surely a non-trivial task. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Vikas N Kumar Gesendet: Freitag, 26. Oktober 2007 17:35 An: [EMAIL PROTECTED]; mono-list@lists.ximian.com Betreff: [Mono-dev] System.CodeDom.Compiler and Debugging Hi I have written an application in which I write code inside a text box, click a button that compiles the code using System.CodeDom.Compiler, loads the code into memory and executes it. This works fine until there is an error in the code that was written in the text box, and I am not able to debug that using either Visual Studio or Mono's debugger. Do you have any suggestions ? Are there classes that .NET gives that I can use in my application itself so that the application itself can debug the code in the textbox at runtime ? System.Diagnostics doesn't seem to do that though. Is it possible for me to embed Mono's debugger inside an application and get the debugger to debug the code that is typed in at runtime ? Any help will be appreciated. Thanks and Regards Vikas Kumar -- http://www.vikaskumar.org/ ___ Mono-devel-list mailing list [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] System.CodeDom.Compiler and Debugging
Hi, akaik there is no integrated debugger support in any of the class libraries. Neither through CodeDom, nor through Reflection.Emit. You should be able to attach an external debugger (Mono or .Net) however this is surely a non-trivial task. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Vikas N Kumar Gesendet: Freitag, 26. Oktober 2007 17:35 An: mono-devel-list@lists.ximian.com; [EMAIL PROTECTED] Betreff: [Mono-dev] System.CodeDom.Compiler and Debugging Hi I have written an application in which I write code inside a text box, click a button that compiles the code using System.CodeDom.Compiler, loads the code into memory and executes it. This works fine until there is an error in the code that was written in the text box, and I am not able to debug that using either Visual Studio or Mono's debugger. Do you have any suggestions ? Are there classes that .NET gives that I can use in my application itself so that the application itself can debug the code in the textbox at runtime ? System.Diagnostics doesn't seem to do that though. Is it possible for me to embed Mono's debugger inside an application and get the debugger to debug the code that is typed in at runtime ? Any help will be appreciated. Thanks and Regards Vikas Kumar -- http://www.vikaskumar.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] Managed Web Browser
Everybody (well some people ;) would love to see a managed browser. Not just for the integration into mono, but also as a standalone product. But when you look at the time it took to develop the existing browsers then it is save to assume that this would be an undertaking that could take years, even for a really large team of developers. And don't forget that in that time the others are also evolving. Are you going to finance that effort? Btw. I know several attempts have already been started. But none got far. Andreas Btw. An alternative for mono would be a minimalist browser simply based on a richtextbox. This would at least make situations work in which e.g. the webbrowser control was just used to display some static html for an Aboutbox or something like that. No Css, scripting, dom or anything similar. It could then be used if no existing browser that can be embedded is available on the system. _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von John Platts Gesendet: Montag, 27. August 2007 03:06 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Managed Web Browser I would like to see an web browser implemented in managed code that would run on Microsoft .NET and Mono, rather than simply having wrappers around unmanaged web browser layout engines. Here are the requirements for the managed web browser: - Must run on the Microsoft .NET Framework version 2.0 or later - Should run on the Microsoft Windows version of Mono (using Mono's Windows Forms implementation) - Should run on the Linux version of Mono (using Mono's Windows Forms implementation) - Browser code should not make any direct calls to managed code (but can make calls to any managed function available in Mono, the Microsoft .NET Framework, the Gtk# library, or the Mono.Cairo library) - Must pass the Acid2 test - Must support cascading style sheets - Must support JavaScript - Must support DOM Levels 1 2 - Must support HTML 4.0 and XHTML - Must have a managed plugin API - Should utilize Code Access Security - Can have optional support for ActiveX controls (requires Microsoft Windows and the Microsoft .NET framework) or NPAPI-based plugins (will require some managed code to support this) - this support will probably require some unmanaged code and can include unmanaged code to provide the support required by ActiveX or NPAPI plugins - There should be an option to build a browser without any unmanaged code included (except for the unmanaged code included in the GTK# library or Mono.Cairo library or their dependencies) - Must be embeddable within Windows Forms applications if implemented using Windows Forms (and also Windows Presentation Foundation applications with the System.Windows.Forms.Integration.WindowsFormsHost class on Version 3.0 and 3.5 of the Microsoft .NET framework) - Must be embeddable within GTK# applications if implemented using GTK# What Mono needs to have in order to support a managed web browser: - a System.Windows.Forms and System.Drawing implementation (or a Gtk# + Mono.Cairo implementation) - Code Access Security - not an absolute requirement for a web browser, but can provide better security, especially for plugins - unmanaged plugins can exploit filesystem, etc. whereas an untrusted managed plugin can be restricted from accessing the filesystem or performing malicious actions if the managed plugin is running under partial trust and both the browser and the unmanaged plugin is running on a runtime with Code Access Security enabled - a functional System.Net.Sockets implementation - should have support for IPv6 _ See what you're getting into.before you go there See it! http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_preview_0507 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How To know in runtime inside a C# program
Just use Path.Combine (FirstPart, SecondPart) It will create the correct path for the system you are running on. Andreas -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von josepascual Gesendet: Donnerstag, 26. Juli 2007 10:30 An: 'Mono devel list' Betreff: [Mono-dev] How To know in runtime inside a C# program Hi Everyone, I'm doing a program in C# using mono. I want to run it in win32 and linux. I have a problem with '/' and '\' for directory in win32 and linux. How Can I know in runtime if I'm in linux (unix) or in Windows to choose '\' for windows and '/' for linux in path for files? thank you, Jose Pascual ___ 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] Some implementation classes for PropertyGrid
Hi,
Had a few minutes of spare time yesterday and just wanted to code a little.
Attached are the results - some classes for System.Design that should help
for the Windows Forms PropertyGrid control to be completely functional.
I currently have to ability to commit myself. So somebody please review and
commit.
Btw. This was mostly developed blindly (against .Net) as the PropertyGrid
has a regression with displaying editors and I currently have no complete
mono devel setup, so please test before. It runs with MS.Net, but may not
with Mono.
They all belong into System.ComponentModel.Design in the System.Design
Assembly.
Changelog is: Implemented ;)
Happy Hacking
Andreas
//
// System.ComponentModel.Design.CollectionEditor.cs
//
// Author:
// Andreas Nahr ([EMAIL PROTECTED])
//
// (C) 2007 Andreas Nahr
//
//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// Software), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
using System;
using System.Reflection;
using System.Collections;
using System.ComponentModel;
using System.Drawing.Design;
using System.Windows.Forms;
using System.Windows.Forms.Design;
namespace System.ComponentModel.Design
{
public class CollectionEditor : UITypeEditor
{
protected abstract class CollectionForm : Form
{
private CollectionEditor editor;
private object editValue;
public CollectionForm (CollectionEditor editor)
{
this.editor = editor;
}
protected Type CollectionItemType
{
get { return editor.CollectionItemType; }
}
protected Type CollectionType
{
get { return editor.CollectionType; }
}
protected ITypeDescriptorContext Context
{
get { return editor.Context; }
}
public object EditValue
{
get { return editValue; }
set {
editValue = value;
OnEditValueChanged ();
}
}
protected object[] Items
{
get { return editor.GetItems (editValue); }
set { editor.SetItems (editValue, value); }
}
protected Type[] NewItemTypes
{
get { return editor.NewItemTypes; }
}
protected bool CanRemoveInstance (object value)
{
return editor.CanRemoveInstance (value);
}
protected virtual bool CanSelectMultipleInstances ()
{
return editor.CanSelectMultipleInstances ();
}
protected object CreateInstance (Type itemType)
{
return editor.CreateInstance (itemType);
}
protected void DestroyInstance (object instance)
{
editor.DestroyInstance (instance);
}
protected virtual void DisplayError (Exception e)
{
MessageBox.Show (e.Message, Cannot construct
object, MessageBoxButtons.OK, MessageBoxIcon.Information);
}
protected override object
Re: [Mono-dev] Using Reflector File Generator Add-Ins
I do not see any use for this at all. Normally a .Net assembly should run unchanged when used on mono, so there is no need to do this. If it doesn't (because of e.g. pinvokes) getting source does not help because you are not allowed to disassemble/change/reassemble 3rd party libraries. And IF you are allowed (because they are OSS or you have the rights to) then you usually have the sourcecode in the first place anyways. _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dimiter Dobrev (Crossroad) Gesendet: Donnerstag, 12. April 2007 16:53 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Using Reflector File Generator Add-Ins Hello. I'd like to ask you if it is possible to to port .NET assemblies to Mono using the .NET Reflector file generator add-ins (http://www.codeplex.com/reflectoraddins), which can generate a project with the full source code from a disassembled assembly. I think it is quite a time saver; it is true that Reflector makes mistakes, btu they could be corrected by using ildasm. Have you ever used this? Thank you in advance for your time. ___ 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 Math.cs and MathTest.cs
Locale.GetText (The value ' + mode + ' is not valid for this usage of the type MidpointRounding.) That is not going to work, because you would have to localize every possible concatenated string combination. Moreover tools wouldn't be able to extract the neccessary string data. If there is no problem with recursive calls you can use String.Format. Greetings Andreas _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dennis Hayes Gesendet: Donnerstag, 15. März 2007 22:55 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Patch for Math.cs and MathTest.cs Math.cs Added Locale.GetText to all strings. Rearranged Rounding with MidPoint to minimize compairs, and to clean up a bit. MathTest.cs Added quite a few new tests for rounding, including test for the 2.0 rounding with midpoint. It also incudes new test for veryfing bad enum execptions. 6 of the test are commented out because they fail. 3 fail because they have not been implmented. 1 fails due to a know rounding error already in bugzilla (new test to exercise bug 60227 63902 should return 3.45, not 3.450... 2 fail for what looks like a different error. //fails. Should return 2.6, but actualy returns 2.5 //AssertEquals(Decmial Rounding toEven, 2.6D , Math.Round(2.55D, 1)); Bug 60227 covers a number of rounding errors, it was not clear of it included this one or not. If these are good, please check them it. Otherwise let me know what is wrong. Thanks, Dennis _ No need to miss a message. Get email http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail on-the-go with Yahoo! Mail for Mobile. Get http://us.rd.yahoo.com/evt=43910/*http://mobile.yahoo.com/mail started. ___ 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 Math.cs and MathTest.cs
Locale.GetText even has a Locale.GetText(String formatString, Object[]
params) convenience overload.
Greetings
Andreas
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Miguel de
Icaza
Gesendet: Freitag, 16. März 2007 17:50
An: Andreas Nahr
Cc: 'Dennis Hayes'; mono-devel-list@lists.ximian.com
Betreff: Re: [Mono-dev] Patch for Math.cs and MathTest.cs
Hello,
Locale.GetText (The value ' + mode + ' is not valid for this usage
of the type MidpointRounding.)
That is not going to work, because you would have to localize every
possible concatenated string combination. Moreover tools wouldn't be
able to extract the neccessary string data.
Yup, the above code should be:
String.Format (Locale.GetText (The value {0} is not valid for this
usage of the type MidpointRounding), mode);
___
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] Stop Garbage Collection for a Codeblock
Using the fixed keyword you can prevent the collection of a memory block, however Im not sure this is what youre looking for. Also I fail to see how this (by itself) could possibly help with time-critical parts. Greetings Andreas _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Back, Michael (ext) Gesendet: Donnerstag, 8. März 2007 10:06 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] Stop Garbage Collection for a Codeblock Hi! Is it possible to stop the GC for garbage collecting for a code block? This would be helpful for time critical parts. I think about something like gc_barrierer_on and gc_barrierer_off. If such possibility doesn't exists, may be it could implemented and improve mono :-) With best regards Michael Back ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] When does JIT reuse memory for new methods
I might be wrong on that one, but afaik method-definitions are only unloaded once the AppDomain gets unloaded (or should be - not sure if mono already does this) Andreas _ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Muath A. Khalaf Gesendet: Montag, 19. Februar 2007 00:43 An: mono-devel-list@lists.ximian.com Betreff: [Mono-dev] When does JIT reuse memory for new methods Hi, I am trying to output some memory map files for mono JITed methods. I have managed to find the place where methods are JITed and output a file with the starting address of each method and the size (was easy). Now I am trying to find the place where a memory chunk allocated for a method by the JIT is reused for another method when JIT runs out of memory. I have seen that all JITing is done in a memory pool temporarily and then a code manager (for each domain) is used to find a chunk with a space for the new code or allocate a new one. One thing I did not get is that code manager always allocates a new chunk and never delete previous filled chunks. Instead they are moved to the full list. So where exactly is the place where JIT starts to free some memory for new methods. Also what about the reJITed methods? what happen to the previous code memory place. This is important for me to decide when should I stop filling a memory map and start with a new one so that I do not mix different methods with the same memory addresses. Thanks Muath _ Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1 NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx Answers. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] JAVA is now GPL..
Well first of all: nice move from Sun. Of the list you named imho the only point that really provides a lot of possible value is for IKVM, because while Classpath got a lot better over time it still isn't complete, so switching to the official libraries could help a lot. Some more comments inline Great, now mono can improve its JIT, AOT compilers and their garbage collectors with cross pollination from Sun's JVM.. I say this because its now possible to access and share code with SUN's JVM, enabling the possibility of things like: - adopting/adapting Java SE garbage collector for mono I'm not very knowledgeable in this field, however the implementation has to take into account things like fixed objects and pointers which aren't uncommon in the CLI, afaik java does not have to deal with this problem in this extent so the GC may be completely unusable for mono. And even if it would be usable this is no simple drop-in component but would still take a lot of work. - adopting/adapting Java SE JIT and AOT compiler technology for mono IMHO highly unlikely. CIL and Bytecode are relatively different and CIL has a lot more unique opcodes than Java. The Java JIT also usually creates applictions with a higher memory-use that mono, so maybe Java should adapt the mono JIT ;) (imho also unlikely) - adapting JAVA JVM to run CIL directly, transforming mono in a framework/wrapper + CIL2javabytecode translator.. imho unlikely due to the reasons above. - adapting JAVA AOT and JIT compiler to produce/read CIL instead of java bytecode I guess you mean javac because the JIT and AOT do not produce bytecode. Possible but I don't really see what would be the advantage of this. - creating a C# front end to JAVA AOT and JIT compiler... C# for the Java JIT? - enhancing mono IKVM.. I say this knowing that CIL and java bytecode probably do not map one2one, nor does java's frameworks or semantics, but besides this, they are similar in many respects, and its not that difficult to adapt a java bytecode compiler to a CIL compiler or vice-versa.. or a java parser to a C# parser.. for that matter... :) What I mean is: in terms of programming language pragmatics/theory, these two technologies/frameworks/languages are very similar, share a lot of problems and solutions.. There is a lot of technology/code that can be shared.. What do you guys think? Do you also see this has a good thing? Will there be any palpable benefits for mono now that sun JDK is GPL ? just for the record: JavaSE: https://openjdk.dev.java.net/source/browse/openjdk/ svn checkout https://openjdk.dev.java.net/svn/openjdk/trunk openjdk --username guest best regards, ps.: keep going strong -- Miguel Sousa Filipe -- Miguel Sousa Filipe ___ 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] Replacing/Removing I18N
To not let our thoughts go wrong way: the reason why existing
I18N.*.dll consist of a bunch of IL code and very few static data
is just because those conversion tables are just made into a bunch
of switch-cases.
And I wrote quite extensively in the original post why this is something
that we definatelly wouldn't want to have.
The encoding conversion tables definitely do not have to reside in
mscorlib.dll. It is a lot of waste of resources.
They could just be other set of resources like per-encoding dlls
(which means that the refactoring is totally meaningless, only
hobbiests' satisfaction) or some kind of tables which have different
loading rules than managed dlls (for example, something like *.nlp
on .NET).
Why would embedding them into corelib be a waste of resources? As far as I
found out this approach should use the minimum amount of resources possible.
It surely uses a LOT less resources than having approx. 150 additional
assemblies that each contain substantial overhead. And it is faster in
loading than external assemblies.
I don't know if mono mmaps external resource files. If it does not then
putting the files into external files (like *.nlp) would be a HUGE waste of
memory resources. If these files are cross-process memory-mapped then it is
just a matter of taste if we want to have 150 externally linked files or
have them embedded (in fact then we could even mix both possibilities
without any additional work needed).
I'm not a fan of this specific restructuring anyways: so niche.
Care to explain? Maybe I don't understand niche? See my original post for
the detailed rationale.
Atsushi Eno
Andreas Nahr wrote:
Hi,
Hello,
* Creating the binary data should be simple when generating from a .Net
VM.
Would it be allowed to gernerate directly from MS.Net? From
Portable.Net?
(obviously from Mono is no problem, but would not allow to ADD data)
I did not understand this question at all.
Well the question is: Is it allowed to extract Data from .Net if it can
be extracted using a normal application (I attached an application that
might be suited for the task)
* Size of a memmaped page?
4k or 8k, depending on the platform.
This would be a perfect size.
* Growth in *file*size for corelib acceptable? Altogether probably
5-10MB
Do we really need to grow corlib? What do you have in mind?
Couldnt we just use static data, and access that as a resource? (Mono
uses mmap for resources in the file)
Do you mean something like: private static readonly byte[]...?
This seems to come with some overhead for me. Also it doesn't seem to
produce shareable memory between processes.
So the idea was (see original mail) to embed the datatables as resources
into the corelib assembly.
Am not sure how much code vs tables lives in the I18N libraries, do you
have details?
Currently the I18N assemblies are about 1MB IL-compiled in size. About
98% is IL-Code, 1-2% is static data.
With the suggested implementation we would have (for single byte
encodings) basically 0% IL and 100% resource-data.
My MS.Net has 145 encodings, mono currently has 95 total.
Each (single-byte (approx. 95 in MS.Net)) encoding would have about 65kb
of tables (the idea is to create one resource per encoding)
* Other sideeffects possible?
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Miguel de Icaza [EMAIL PROTECTED]
using System;
using System.Text;
using System.IO;
class CreateEncodingData
{
private static string path = @c:\st\out\;
public static void Main ()
{
byte[] bytes = new byte[256];
for (int i = 0; i 256; i++)
bytes[i] = (byte)i;
char[] chars = new char[65536];
for (int i = 0; i 65536; i++)
chars[i] = (char)i;
EncodingInfo[] encodings = Encoding.GetEncodings();
Console.WriteLine (Encoding count: + encodings.Length);
foreach (EncodingInfo info in encodings)
{
Encoding e = Encoding.GetEncoding(info.CodePage);
Console.Write (Encoding: + e.CodePage + ( + e.WebName +
; + info.DisplayName + ));
if (e.IsSingleByte)
{
Console.WriteLine ( - single byte);
//byte unusedbyte = (e.GetBytes(new char[] {
(char)3 }))[0];
Stream s = new FileStream (Path.Combine(path, e.CodePage +
.bin), FileMode.Create);
char[] dataChars = e.GetChars(bytes);
byte[] temp = Encoding.Unicode.GetBytes(dataChars);
s.Write(temp, 0, temp.Length);
byte[] dataBytes = e.GetBytes(chars);
//for (int i = 0; i dataBytes.Length;
i++)
//if (dataBytes[i] == unusedbyte)
//dataBytes[i] = 0
Re: [Mono-dev] Replacing/Removing I18N
Additionally:
If the 10MB are too large there could be the option to split the tables into
a lower and upper table (the middle range is unused by single-byte
encodings) reducing the table size to about 12-16kb.
I don't think its worth it though because in 99% of the cases this just
means trading HDD space for speed (for the more complex handling) which IMHO
is no good deal.
To not let our thoughts go wrong way: the reason why existing
I18N.*.dll consist of a bunch of IL code and very few static data
is just because those conversion tables are just made into a bunch
of switch-cases.
The encoding conversion tables definitely do not have to reside in
mscorlib.dll. It is a lot of waste of resources.
They could just be other set of resources like per-encoding dlls
(which means that the refactoring is totally meaningless, only
hobbiests' satisfaction) or some kind of tables which have different
loading rules than managed dlls (for example, something like *.nlp
on .NET).
I'm not a fan of this specific restructuring anyways: so niche.
Atsushi Eno
Andreas Nahr wrote:
Hi,
Hello,
* Creating the binary data should be simple when generating from a
.Net VM.
Would it be allowed to gernerate directly from MS.Net? From
Portable.Net?
(obviously from Mono is no problem, but would not allow to ADD data)
I did not understand this question at all.
Well the question is: Is it allowed to extract Data from .Net if it
can be extracted using a normal application (I attached an application
that might be suited for the task)
* Size of a memmaped page?
4k or 8k, depending on the platform.
This would be a perfect size.
* Growth in *file*size for corelib acceptable? Altogether probably
5-10MB
Do we really need to grow corlib? What do you have in mind?
Couldnt we just use static data, and access that as a resource? (Mono
uses mmap for resources in the file)
Do you mean something like: private static readonly byte[]...?
This seems to come with some overhead for me. Also it doesn't seem to
produce shareable memory between processes.
So the idea was (see original mail) to embed the datatables as resources
into the corelib assembly.
Am not sure how much code vs tables lives in the I18N libraries, do you
have details?
Currently the I18N assemblies are about 1MB IL-compiled in size. About
98% is IL-Code, 1-2% is static data.
With the suggested implementation we would have (for single byte
encodings) basically 0% IL and 100% resource-data.
My MS.Net has 145 encodings, mono currently has 95 total.
Each (single-byte (approx. 95 in MS.Net)) encoding would have about 65kb
of tables (the idea is to create one resource per encoding)
* Other sideeffects possible?
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Miguel de Icaza [EMAIL PROTECTED]
using System;
using System.Text;
using System.IO;
class CreateEncodingData
{
private static string path = @c:\st\out\;
public static void Main ()
{
byte[] bytes = new byte[256];
for (int i = 0; i 256; i++)
bytes[i] = (byte)i;
char[] chars = new char[65536];
for (int i = 0; i 65536; i++)
chars[i] = (char)i;
EncodingInfo[] encodings = Encoding.GetEncodings();
Console.WriteLine (Encoding count: + encodings.Length);
foreach (EncodingInfo info in encodings)
{
Encoding e = Encoding.GetEncoding(info.CodePage);
Console.Write (Encoding: + e.CodePage + ( + e.WebName
+ ; + info.DisplayName + ));
if (e.IsSingleByte)
{
Console.WriteLine ( - single byte);
//byte unusedbyte = (e.GetBytes(new char[] { (char)3
}))[0];
Stream s = new FileStream (Path.Combine(path, e.CodePage
+ .bin), FileMode.Create);
char[] dataChars = e.GetChars(bytes);
byte[] temp = Encoding.Unicode.GetBytes(dataChars);
s.Write(temp, 0, temp.Length);
byte[] dataBytes = e.GetBytes(chars);
//for (int i = 0; i dataBytes.Length; i++)
//if (dataBytes[i] == unusedbyte)
//dataBytes[i] = 0;
s.Write(dataBytes, 0, dataBytes.Length);
}
else
{
Console.WriteLine ();
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono
Re: [Mono-dev] Replacing/Removing I18N
On 10/09/06 Andreas Nahr wrote:
Current situation:
I18N is located in multiple separate assemblies that contain encoding
classes that are autogenerated. The single-byte encodings (my current
focus) use a potentially big CASE-Structure to compute the output.
Problems:
[...]
Considerations for change:
* Data must not be in private memory but shared as much as possible
(currently most is shareable)
* If possible avoid internal-calls and other direct runtime-support
(currently does not need any)
I'm all for dumping the current I18N assemblies, the problems you list
are real, we just need someone to write and test all the code.
What I don't agree with is avoiding internal calls and runtime support.
The reason is simple: the most efficient way to export to the manage
world arrays of data is to have them as C arrays in the mono runtime or
as data files that mono loads and mmaps, returning a pointer for use in
usafe code in the assembly implementation. See the locale data for
examples. I18n tables are best put outside the mono binary, usually
Well this was my first thought also to do it this way. However
internal-calls reduce the maintainability of the code, because you have to
manually ensure it stays in synch and it makes using corelib much harder for
other projects. So I tried to search for another way to archieve the same
goal and my proposal could be the solution (Again: If I'm somewhere making
wrong assumptions, please correct me).
It seems I couldn't make clear enough how this should work, so here is a
simplified pseudocode example about how I imagine this would work:
class Enc
{
byte* table;
public Enc (int codepage)
{
IntPtrStream s = Assembly.GetManifestResourceStream(codepage);
table = s.memStart;
}
public byte GetByte (char char)
{
return table[char];
}
}
The real implementation wouldn't actually be much more complicated than
this.
Also this would obviously be (much) faster than the current solution (I
don't know how Atsushi got to the point that this would be slower than
current code).
Moreover it has the advantage that you could remove resources from the file
in a much simpler than removing code in the c source files...
Assumed benefits:
* Simple solution
* Simple code
* Fast
* Data completely shareable between processes
In fact it seems to be such a simple and good solution that I'm somehow even
waiting some someone to say: Gotcha this doesn't work because...
(except latin1 support). The aim is to optionally move outside also
other tables that are currently hardcoded inside mono.
Note: resources in assemblies are mmapped, but still using datadirectly
from mono is more efficient.
A small comment of your considerations, though: using a 64KB table when
a much smaller one is sufficient would be a waste. We need to keep in
mind also disk-space issues.
Currently my focus was actually trying to find out if this could work at
all, the change to two tables (already wrote about it) would only be a small
change.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Replacing/Removing I18N
Hi,
Hello,
* Creating the binary data should be simple when generating from a .Net
VM.
Would it be allowed to gernerate directly from MS.Net? From Portable.Net?
(obviously from Mono is no problem, but would not allow to ADD data)
I did not understand this question at all.
Well the question is: Is it allowed to extract Data from .Net if it can be
extracted using a normal application (I attached an application that might
be suited for the task)
* Size of a memmaped page?
4k or 8k, depending on the platform.
This would be a perfect size.
* Growth in *file*size for corelib acceptable? Altogether probably 5-10MB
Do we really need to grow corlib? What do you have in mind?
Couldnt we just use static data, and access that as a resource? (Mono
uses mmap for resources in the file)
Do you mean something like: private static readonly byte[]...?
This seems to come with some overhead for me. Also it doesn't seem to
produce shareable memory between processes.
So the idea was (see original mail) to embed the datatables as resources
into the corelib assembly.
Am not sure how much code vs tables lives in the I18N libraries, do you
have details?
Currently the I18N assemblies are about 1MB IL-compiled in size. About 98%
is IL-Code, 1-2% is static data.
With the suggested implementation we would have (for single byte encodings)
basically 0% IL and 100% resource-data.
My MS.Net has 145 encodings, mono currently has 95 total.
Each (single-byte (approx. 95 in MS.Net)) encoding would have about 65kb of
tables (the idea is to create one resource per encoding)
* Other sideeffects possible?
Greetings
Andreas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Miguel de Icaza [EMAIL PROTECTED]
using System;
using System.Text;
using System.IO;
class CreateEncodingData
{
private static string path = @c:\st\out\;
public static void Main ()
{
byte[] bytes = new byte[256];
for (int i = 0; i 256; i++)
bytes[i] = (byte)i;
char[] chars = new char[65536];
for (int i = 0; i 65536; i++)
chars[i] = (char)i;
EncodingInfo[] encodings = Encoding.GetEncodings();
Console.WriteLine (Encoding count: + encodings.Length);
foreach (EncodingInfo info in encodings)
{
Encoding e = Encoding.GetEncoding(info.CodePage);
Console.Write (Encoding: + e.CodePage + ( + e.WebName + ;
+ info.DisplayName + ));
if (e.IsSingleByte)
{
Console.WriteLine ( - single byte);
//byte unusedbyte = (e.GetBytes(new char[] {
(char)3 }))[0];
Stream s = new FileStream (Path.Combine(path, e.CodePage
+ .bin), FileMode.Create);
char[] dataChars = e.GetChars(bytes);
byte[] temp =
Encoding.Unicode.GetBytes(dataChars);
s.Write(temp, 0, temp.Length);
byte[] dataBytes = e.GetBytes(chars);
// for (int i = 0; i dataBytes.Length; i++)
// if (dataBytes[i] == unusedbyte)
// dataBytes[i] = 0;
s.Write(dataBytes, 0, dataBytes.Length);
}
else
{
Console.WriteLine ();
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Replacing/Removing I18N
Hi *, I've been looking into this topic for quite some time now. However my knowledge (especially of the internals of the VM) is potentially not enough, so please correct me if I make wrong statements or assumptions: Current situation: I18N is located in multiple separate assemblies that contain encoding classes that are autogenerated. The single-byte encodings (my current focus) use a potentially big CASE-Structure to compute the output. Problems: * I18N is loaded through Reflection-Mechanisms, which triggers a HUGE amount of other code, so Mono loads/jits and instatiates a considerable portion of the entire corelib when I18N is used. * Initializing the I18N is slow and creates a huge amount of objects. * (At least on windows) I18N is basically ALWAYS used, because a single access to Console (which even the corelib contains a lot for debug output) is enough to instantiate it. I'm assuming this doesn't happen on Linux? * The I18N classes themselves consist of considerable amount of IL-Code making them slow to JIT and using a considerable amount of memory to hold the IL and produced native code. * The I18N classes are potentially slow (especially when assuming that optimization is probably sub-optimal because of the often huge IL-size). * Pressure on the GC because of big number of generated objects. Considerations for change: * Data must not be in private memory but shared as much as possible (currently most is shareable) * If possible avoid internal-calls and other direct runtime-support (currently does not need any) Goals: * Drop additional libraries * Use less memory * Make instantiation faster * Try to limit the needed JITted code to a reasonable amount * Possibly make encoding faster I started with the single-byte encodings, because these are the most simple ones and the most numerous: The idea is to only use a single class for all single-byte encodings that is instantiated with lookuptables suited for the relevant codepage. The lookuptables would be binary data that should be shared. A solution seems to be embedding these as resource-files into corelib and then getting a pointer to the binary data through Assembly.GetManifestResourceStream. The data would be uncompressed and complete for maximum performance and minimal code requirement (about 65kb per encoding). The data should already be memmaped is embedded as a resource (how big would be one of the pages??). Some ballpark figures as rationale (See the attached text-files which show an app using only I18N, one with String and Globalization and one without all): For String and Globalization Mono uses about 15kb memory for code and 7kb for data in 246 objects. With I18N mono uses (Codepage 1250) 140kb for code and 81kb for private data in 1800 objects (potentially putting pressure on the GC) So the 65kb (how much could be saved because of memmapping - ALL single-byte encodings do not use a part of the unicode-range?) we need for an encoding is actually far less than the current overhead for I18N (obviously that may not hold true if a lot of different encodings are used). And obviously the lookup would be faster and we would not need any time spent in the JIT. Open questions: * Creating the binary data should be simple when generating from a .Net VM. Would it be allowed to gernerate directly from MS.Net? From Portable.Net? (obviously from Mono is no problem, but would not allow to ADD data) * Size of a memmaped page? * Growth in *file*size for corelib acceptable? Altogether probably 5-10MB * Other sideeffects possible? Greetings Andreas Mono Jit statistics Compiled methods: 80 Methods from AOT: 0 Methods cache lookup: 70 Method trampolines: 1210 Basic blocks: 482 Max basic blocks: 35 Allocated vars: 372 Analyze stack repeat: 0 Compiled CIL code size: 4895 Native code size: 12278 Max code size ratio:32,00 (Object::.ctor) Biggest method: 1126 (Hashtable::.cctor) Code reallocs: 6 Allocated code size:12278 Inlineable methods: 0 Inlined methods:0 Created object count: 246 Initialized classes:72 Used classes: 43 Static data size: 148 VTable data size: 7460 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 80 methods (sec): 0 Time(ms) Count P/call(ms) Method name Total number of calls: 268 Allocation profiler Total mem Method Total memory allocated: 7 KB Test Mono Jit statistics Compiled methods: 466 Methods from AOT: 0 Methods cache lookup: 511 Method trampolines: Basic blocks: 3939 Max basic blocks: 237 Allocated vars: 3102 Analyze stack repeat: 0 Compiled CIL code size: 40443 Native code size: 93100 Max code size ratio:32,00 (Object::.ctor) Biggest method: 4930 (SimpleCollator::CompareInternal) Code
Re: [Mono-dev] System.dll few patches for review
Care to explain why? I'm aware that Invariant will be (invariant-culture) sensitive, however it IMHO would fix the bug. I also agree that using String.Compare with OrdinalIgnoreCase would be the best option, however unfortunatelly that is .Net 2.0 only. String.CompareOrdinal() is obviously obviously a no-go because it would be case-sensitive and as I already wrote CompareOptions are 2.0 only. Happy hacking Andreas P.S. If I'd design a new .Net Framework the first thing would be to create two Classes: (System)String and LanguageString. You are still wrong :-) InvariantCulture still causes culture sensitive comparison. Use String.CompareOrdinal() or CompareOptions.Ordinal instead. Atsushi Eno Andreas Nahr wrote: Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.dll few patches for review
Sorry if this is already handled, just looked over the list and found this bug: Index: System.Net/DigestClient.cs === --- System.Net/DigestClient.cs (revision 66034) +++ System.Net/DigestClient.cs (working copy) @@ -248,9 +248,9 @@ return false; } - // build the hash object (only MD5 is defined in RFC2617) - if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) - hash = HashAlgorithm.Create (MD5); + // build the hash object (only MD5 is defined in RFC2617) + if ((parser.Algorithm == null) || (parser.Algorithm.ToUpper ().StartsWith (MD5))) + hash = MD5.Create (); return true; } Algorithm.ToUpper ().StartsWith (MD5))) is most likely wrong because the code is doing a culture-sensitive uppercasing. You should use something like ToUpperInvariant or pass the Invariant Culture (or better if possible: one of the case-insensitive compares) I didn't look into the relevant classes, but there may be more similar occurences of that problem. mfg Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug in MonoTorrent
Hi, I tried the MonoTorrent library and found a bug preventing if from working with large torrents or files. The torrent contained a file with 3GB size (Linux DVD image): System.IO.IOException was unhandled Message="An attempt was made to move the file pointer before the beginning of the file.\r\n" Source="mscorlib" StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.SeekCore(Int64 offset, SeekOrigin origin) at System.IO.FileStream.Seek(Int64 offset, SeekOrigin origin) at MonoTorrent.Client.FileManager.Read(Byte[] buffer, Int32 bufferOffset, Int64 offset, Int32 count) at MonoTorrent.Client.FileManager.GetHash(Int32 pieceIndex) at MonoTorrent.Client.TorrentManager.HashCheck(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state) Also some functions like e.g.torrent.DownloadSpeed () seem to be pretty complicated to get right in terms of multithreading use. Happy Hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SavageSVG
Hi Eric, I've started writing a SVG library in VB.Net about5 years ago (about the timeframe of SharpVectorGraphics), however was fed up with the project when the SVG standard changed from nice and cleanvector graphics to something like Flash with complete DOM support, scripting, UI controls, animation and all that stuff. While the project itself is probably not worth looking into it it had some code written in unsafe c# for the filters (far from complete, but better than nothing I'd suppose). AFAIK SharpVectorGraphics 0.3 and even the latest0.4 did not have any support for them. I will see if it is perhaps possible to release that as open-source (but it could take a while) Happy hacking Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Cecil bug report and a question
I also have a question: I have an example of an assembly output by the MS C# compiler that shrinks from 3.072 bytes to 2.048 bytes simply by loading and then saving it using Cecil. How does that happen? Cecil does not preserve the .rsrc (aka Win32 resources) section or the PE file for the moment. So it saves some place. What are the consequences of this other than smaller assemblies? The most visible one: Under Windows the Application will loose it's icon and file information data (Like producer, product name, visible version etc.) A lot more improbable is that the app does not work any longer if it somehow uses this data directly. Greets Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why do we need separate I18N assemblies?
Hello, I think it would be worth it to try to remove the reflection overhead, because it is not just taking some time but also quite some amount of additional memory. Personally I would recommend to put the small encodings directly into corelib and the larger and seldom used ones in one or more additional assemblies that could be referenced without reflection and simply be deleted when not needed. As you point out in one of your emails, I think it is worth fixing the code that triggers the culture-dependent string compares in our class libraries, they are likely not needed. Well, I guess that is more of a sideeffect found in the process looking at it. I just did some simple measuring and at least in CPU-Performance the Globalization stuff is completely negegible (beyond of what the timer of mono --profile can measure). The problem here is more that this code could fail on certain locales (in the examples I wrote my guess would be that the first one would not work on a turkish locale). As for not using reflection, am afraid that even if we removed the use of Reflection for the encodings, reflection will end up being triggered anyways as too much code in Mono (in addition to standard .NET practices) will trigger the reflection bits to be loaded. However this could still save most of the runtime initialization cost, which is usually even more than the JIT-Time. Integrating the most commonly used encodings into corlib sounds like a good idea, someone would have to prototype it and measure it. The overhead actually comes mostly from two places: a) I18N b) Globalisation b is triggered because of String handling mistakes within corelib, however the biggest share in runtime is I18N (see textfile - 78 ms out of 93 ms total app time). Thanks for looking at the problematic sources.I like the idea of fixing these issues, but am not sure that they will have a real effect on applications. I did some more simple measuring and would expect a nice potential for improvement (obviously mostly for small CMD-Apps): 1) I ran mcs.exe --help to display the help of mcs. Virtually 100% of the runtime were spent for the Initialization of I18N (obviously this means that mono cannot do more detailed measuring with --profile, because mcs should need some cycles, too ;) 2) Ran mcs.exe for compiling a simple application. Nearly 25% of the entire runtime were spent only for *Initialization* of I18N. The globalization code will likely be used shortly after, at least for any non-trivial program. You're surely right on this one. Also the Globalization overhead is tiny compared with I18N. Greetings Andreas P.S. All tests done on Athlon 3500+, Mono 1.1.15, XPx64 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why do we need separate I18N assemblies?
I had a few minutes and checked through corelib:
In AppDomainSetup:
private static string GetAppBase(string appBase)
{
if (appBase == null)
{
return null;
}
if ((appBase.Length = 8) appBase.ToLower().StartsWith(file://))
{
...}
This should most likely be:
if ((appBase.Length = 8)
appBase.ToLowerInvariant().StartsWith(file://))
In Module:
private static bool filter_by_type_name_ignore_case(Type m, object
filterCriteria)
{
string text1 = (string) filterCriteria;
if (text1.EndsWith(*))
{
return m.Name.ToLower().StartsWith(text1.Substring(0,
text1.Length - 1).ToLower());
}
return (string.Compare(m.Name, text1, true) == 0);
}
These .ToLower() are most likely incorrect, too.
Others are: RemotingConfiguration.SetCustomErrorsMode(string) and
Microsoft.Win32.UnixRegistryApi.ToUnix(String)
Also lots of stuff in Mono.Security.Uri ist cultural-aware, but probably
shouldn't be (in fact it's pretty much mixed there between cultural aware,
not-aware and usage of InvariantCulture)
System.Security.Site.UrlToSite ist most likely wrong, too.
Several other classes in Mono.Security are actually semantically correct,
but make unneccessary use of the Globalization classes and through that
produce additional unneeded overhead.
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]; Atsushi Eno [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Sent: Saturday, July 01, 2006 12:43 AM
Subject: Re: [Mono-dev] Why do we need separate I18N assemblies?
b meant Option b) from above - the Globalization.
If you look at the profile you will see that a simple Console.WriteLine
(A) results in the usage/compilation of the Globalization classes. This is
very likely from a bug in the code like comparing two non-cultural-aware
strings (are there any cultural-aware string in corelib anyway?) in a
cultural-aware way like this:
if (String1.ToLower () == String2.ToLower ())
By the way what do you exactly mean on b is triggered because of String
handling mistakes within corelib?
Kornél
- Original Message -
From: Andreas Nahr [EMAIL PROTECTED]
To: Kornél Pál [EMAIL PROTECTED]; Atsushi Eno [EMAIL PROTECTED]
Cc: mono-devel-list@lists.ximian.com
Sent: Friday, June 30, 2006 10:26 PM
Subject: Re: [Mono-dev] Why do we need separate I18N assemblies?
Hi,
I think it would be worth it to try to remove the reflection overhead,
because it is not just taking some time but also quite some amount of
additional memory. Personally I would recommend to put the small
encodings
directly into corelib and the larger and seldom used ones in one or more
additional assemblies that could be referenced without reflection and
simply
be deleted when not needed.
I did some simple testing on the potential benefits:
The basic overhead of a Mono Application is a little bit below this:
-
Mono Jit statistics
Compiled methods: 35
Methods from AOT: 0
Methods cache lookup: 12
Method trampolines: 868
Basic blocks: 196
Max basic blocks: 14
Allocated vars: 141
Analyze stack repeat: 0
Compiled CIL code size: 1594
Native code size: 5095
Max code size ratio:32,00 (Object::.ctor)
Biggest method: 1126 (Hashtable::.cctor)
Code reallocs: 3
Allocated code size:5095
Inlineable methods: 0
Inlined methods:0
Created object count: 51
Initialized classes:53
Used classes: 30
Static data size: 96
VTable data size: 5160
Generic instances: 0
Initialized classes:0
Inflated methods: 0 / 0
Inflated types: 0
Generics metadata size: 0
Total time spent compiling 35 methods (sec): 0
-
if you do a single
Console.WriteLine (Test);
It becomes:
-
Test
Mono Jit statistics
Compiled methods: 466
Methods from AOT: 0
Methods cache lookup: 511
Method trampolines:
Basic blocks: 3939
Max basic blocks: 237
Allocated vars: 3102
Analyze stack repeat: 0
Compiled CIL code size: 40443
Native code size: 93100
Max code size ratio:32,00 (Object::.ctor)
Biggest method: 4930 (SimpleCollator::CompareInternal)
Code reallocs: 40
Allocated code size:93100
Inlineable methods: 0
Inlined methods:5
Created object count: 1800
Initialized classes:235
Used classes: 153
Static data size: 510
VTable data size: 24312
Generic instances: 0
Initialized classes:0
Inflated methods: 0 / 0
Inflated types: 0
Generics metadata size: 0
Total time spent compiling 466 methods (sec): 0,0625
Slowest method to compile (sec): 0,01563
Re: [Mono-dev] Why do we need separate I18N assemblies?
Hi, I think it would be worth it to try to remove the reflection overhead, because it is not just taking some time but also quite some amount of additional memory. Personally I would recommend to put the small encodings directly into corelib and the larger and seldom used ones in one or more additional assemblies that could be referenced without reflection and simply be deleted when not needed. I did some simple testing on the potential benefits: The basic overhead of a Mono Application is a little bit below this: - Mono Jit statistics Compiled methods: 35 Methods from AOT: 0 Methods cache lookup: 12 Method trampolines: 868 Basic blocks: 196 Max basic blocks: 14 Allocated vars: 141 Analyze stack repeat: 0 Compiled CIL code size: 1594 Native code size: 5095 Max code size ratio:32,00 (Object::.ctor) Biggest method: 1126 (Hashtable::.cctor) Code reallocs: 3 Allocated code size:5095 Inlineable methods: 0 Inlined methods:0 Created object count: 51 Initialized classes:53 Used classes: 30 Static data size: 96 VTable data size: 5160 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 35 methods (sec): 0 - if you do a single Console.WriteLine (Test); It becomes: - Test Mono Jit statistics Compiled methods: 466 Methods from AOT: 0 Methods cache lookup: 511 Method trampolines: Basic blocks: 3939 Max basic blocks: 237 Allocated vars: 3102 Analyze stack repeat: 0 Compiled CIL code size: 40443 Native code size: 93100 Max code size ratio:32,00 (Object::.ctor) Biggest method: 4930 (SimpleCollator::CompareInternal) Code reallocs: 40 Allocated code size:93100 Inlineable methods: 0 Inlined methods:5 Created object count: 1800 Initialized classes:235 Used classes: 153 Static data size: 510 VTable data size: 24312 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 466 methods (sec): 0,0625 Slowest method to compile (sec): 0,01563: I18N.Common.Handlers::.cctor() - So this means you have about 20 times as much Native Code Size, need 150-200 msec additional time (See attached textfile for JITTime+Runtime, run on a 3500+ Athlon) and more than 100kb additional memory. Moreover the GC has to manage/kill 1800! Objects already, with no single line of Application code run yet. The overhead actually comes mostly from two places: a) I18N b) Globalisation b is triggered because of String handling mistakes within corelib, however the biggest share in runtime is I18N (see textfile - 78 ms out of 93 ms total app time). In terms of memory it is more complicated to estimate, but from looking at the profile one could assume that there are also big potential optimizations. mfg Andreas I once dreamed to change encoding implementation like you but I noticed that it helps few people other than my personal satisfaction and spends too much time just for such a niche (at least for me). When you split conversion map data from I18N.*.dll which is mostly extraneous for people who don't use those them, feel free to try merging it into mscorlib. Otherwise, I don't like your idea. Originally I was thinking of simply moving Encoding classes to corlib but you and Jonathan are right that there are cases when it has advantages if such large data can be excluded. But you are right this would need a lot of time... Why do you quote Microsoft mscorlib size here? It is far from something to do with it. Stop making misleading. To my understanding they have different files for encoding maps (*.nlp). I just tried to glorify the size of our mscorlib.:) If we add the size of I18N assemblies to the size of our mscorlib our is sill smaller than Microsoft's one. (And you are right that it has external dependencies so the difference may be even more.) As long as our mscorlib can do the same as their this only means that ours is better and nothing more.:) Mono should be MS.NET compatible is simply wrong as usual. We have broader supported environment which requires different thinking. From http://www.mono-project.com/FAQ:_General: Its objective is to enable UNIX developers to build and deploy cross-platform .NET Applications. And note that this is why I like Mono.:) This goal cannot be achieved without MS.NET compatibility. Of course I don't mean compatiblitiy at any costs. Or for example I don't like the bug compatibility at any cost
Re: [Mono-dev] Component 1
Actually most components I know of are managed code, so they should run on mono. If you are allowed you can simply take Reflector and look at the references of your assembly and you will instantly see if the component is managed only. mfg Andreas - Original Message - From: Rafael Teixeira [EMAIL PROTECTED] To: Rich Gilson [EMAIL PROTECTED] Cc: Mono-devel-list@lists.ximian.com Sent: Friday, June 30, 2006 9:00 PM Subject: Re: [Mono-dev] Component 1 The problem is, we don't know if the third-party controls/tools were developed with 100% managed and portable code, so you have to try them in Mono. Some years ago, most of the controls I tried were just wrappers to COM/ActiveX controls/components and surely those didn't run on Mono. Since I've being developing in Linux mainly and so without VS.NET and 3rd party components, so I can't say if that has changed. I know, from my friends on that front, that Delphi.NET users are tied to Windows, as the many useful frameworks Borland gave them aren't portable. :) On 6/30/06, Rich Gilson [EMAIL PROTECTED] wrote: I'm working on porting an application at work to .NET and wanted to do it in Mono so that it could be run on both Linux and Windows, but I'm trying to figure out if there is any what to use Third-Party tools in Mono? Or are the tools that work on Visual Studio Windows-only? If they can be used, how would I go about using them and getting everything packaged together when I build it? Rich On 6/27/06, Rich Gilson [EMAIL PROTECTED] wrote: Is it possible to use any of the Component 1 objects in Mono? -- In a world without fences, who needs Gates? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why do we need separate I18N assemblies?
b meant Option b) from above - the Globalization. If you look at the profile you will see that a simple Console.WriteLine (A) results in the usage/compilation of the Globalization classes. This is very likely from a bug in the code like comparing two non-cultural-aware strings (are there any cultural-aware string in corelib anyway?) in a cultural-aware way like this: if (String1.ToLower () == String2.ToLower ()) By the way what do you exactly mean on b is triggered because of String handling mistakes within corelib? Kornél - Original Message - From: Andreas Nahr [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED]; Atsushi Eno [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Friday, June 30, 2006 10:26 PM Subject: Re: [Mono-dev] Why do we need separate I18N assemblies? Hi, I think it would be worth it to try to remove the reflection overhead, because it is not just taking some time but also quite some amount of additional memory. Personally I would recommend to put the small encodings directly into corelib and the larger and seldom used ones in one or more additional assemblies that could be referenced without reflection and simply be deleted when not needed. I did some simple testing on the potential benefits: The basic overhead of a Mono Application is a little bit below this: - Mono Jit statistics Compiled methods: 35 Methods from AOT: 0 Methods cache lookup: 12 Method trampolines: 868 Basic blocks: 196 Max basic blocks: 14 Allocated vars: 141 Analyze stack repeat: 0 Compiled CIL code size: 1594 Native code size: 5095 Max code size ratio:32,00 (Object::.ctor) Biggest method: 1126 (Hashtable::.cctor) Code reallocs: 3 Allocated code size:5095 Inlineable methods: 0 Inlined methods:0 Created object count: 51 Initialized classes:53 Used classes: 30 Static data size: 96 VTable data size: 5160 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 35 methods (sec): 0 - if you do a single Console.WriteLine (Test); It becomes: - Test Mono Jit statistics Compiled methods: 466 Methods from AOT: 0 Methods cache lookup: 511 Method trampolines: Basic blocks: 3939 Max basic blocks: 237 Allocated vars: 3102 Analyze stack repeat: 0 Compiled CIL code size: 40443 Native code size: 93100 Max code size ratio:32,00 (Object::.ctor) Biggest method: 4930 (SimpleCollator::CompareInternal) Code reallocs: 40 Allocated code size:93100 Inlineable methods: 0 Inlined methods:5 Created object count: 1800 Initialized classes:235 Used classes: 153 Static data size: 510 VTable data size: 24312 Generic instances: 0 Initialized classes:0 Inflated methods: 0 / 0 Inflated types: 0 Generics metadata size: 0 Total time spent compiling 466 methods (sec): 0,0625 Slowest method to compile (sec): 0,01563: I18N.Common.Handlers::.cctor() - So this means you have about 20 times as much Native Code Size, need 150-200 msec additional time (See attached textfile for JITTime+Runtime, run on a 3500+ Athlon) and more than 100kb additional memory. Moreover the GC has to manage/kill 1800! Objects already, with no single line of Application code run yet. The overhead actually comes mostly from two places: a) I18N b) Globalisation b is triggered because of String handling mistakes within corelib, however the biggest share in runtime is I18N (see textfile - 78 ms out of 93 ms total app time). In terms of memory it is more complicated to estimate, but from looking at the profile one could assume that there are also big potential optimizations. mfg Andreas I once dreamed to change encoding implementation like you but I noticed that it helps few people other than my personal satisfaction and spends too much time just for such a niche (at least for me). When you split conversion map data from I18N.*.dll which is mostly extraneous for people who don't use those them, feel free to try merging it into mscorlib. Otherwise, I don't like your idea. Originally I was thinking of simply moving Encoding classes to corlib but you and Jonathan are right that there are cases when it has advantages if such large data can be excluded. But you are right this would need a lot of time... Why do you quote Microsoft mscorlib size here? It is far from something to do with it. Stop making misleading. To my
Re: [Mono-dev] JaCIL Project
Nice project, however my guess would be that it will be extremely hard to translate arbitrary CIL to Java bytecode. Thehard partis likelythat CIL has lots of construcs that Java bytecode does not have. Just to name a few common/important ones: Generics, Pointers and Pointer arithmetic, unchecked exceptions, events, delegates, ... How are you planning to solve that problem? mfg Andreas Hi all,I've just released an early version of JaCIL, a .NET assembly to Java class file byte-code compiler. It leverages Mono.Cecil to deal with the concrete PE file format of assemblies and uses ObjectWeb ASM via IKVM.NET to deal with the concrete format of Java class files.This release supports about 50 byte-codes, enough to translate simple methods with arithmetic. Not much, you may think, but a considerable milestone for the project. I plan on getting more of the basic instructions implemented for the next release including method invocation. Also on my list of things to do is a testing harness for the compiler/run-time so I can create a test suite. The 0.3.0.0 release is available at:http://sourceforge.net/project/showfiles.php?group_id=166087package_id=188734release_id=418508 The 0.3.0.0 release notes are available at:http://sourceforge.net/project/shownotes.php?release_id=418508group_id=166087 Project home (project info, online API docs, download links, repository link, etc.):http://jacil.sourceforge.net/Please let me know what you think! Best Regards,Almann-- Almann T. Goo[EMAIL PROTECTED] ___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://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] Using Ilasm parser on other applications
Why not just use Cecil? That would work for any IL, not just (but also) ILAsm source... - Original Message - From: Alejandro Serrano [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Sunday, May 07, 2006 5:13 PM Subject: [Mono-dev] Using Ilasm parser on other applications Is there any way I could use the parser that Ilasm uses to obtain the set of classes, methods, properties, etc... from an IL source file? I don't mind making some rework, although I think this parser could address my needs if I got some way to use it just not for plain code generation. Thanks in advance, Serras __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
