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
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
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
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,
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
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-
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
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
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)
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
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
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
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
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
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
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
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.
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
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
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 ([*],
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
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
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
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
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
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
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:
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
, 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
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
-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
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:
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
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
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
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
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);
. 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
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
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
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
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
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
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
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
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
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))
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
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
: 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
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
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
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
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
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
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
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;
+
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:
, 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
-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
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
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
?).
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
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
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
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]
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
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
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
-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
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
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
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
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,
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'
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
Obviously all three might add to that. However I think that number 1 COULD
already be enough for the noticed slowdown of 3 times. It depends a lot on
which Classes/ Methods IronPython is using (And I guess it is now optimized
towards the MS CLR). If you just have pure integer or floating point
1 - 100 of 133 matches
Mail list logo
