Here is the profiler todo list.
If somebody wants to suggest priorities, or propose other
features... ;-)
- Choose a name for the tool, and stick to that.
The two candidates are mprof and monoprof.
I like mprof more, but a simple google search shows that it
has been used by other minor
Zoltan Varga wrote:
[...]
In case anyone wants to revert their tree to before the merge, the before
merge
revision is r108475.
(Just FYI)
It's a shame because, at that revision, there's an mcs bug that prevents
you from compiling MonoDevelop:
Exception caught by the compiler while
Andrés G. Aragoneses wrote:
Zoltan Varga wrote:
[...]
In case anyone wants to revert their tree to before the merge, the before
merge
revision is r108475.
(Just FYI)
It's a shame because, at that revision, there's an mcs bug that prevents
you from compiling MonoDevelop:
Exception
Hello,
Here is the profiler todo list.
If somebody wants to suggest priorities, or propose other
features... ;-)
Would it be possible to show detailed string allocations? What I usually
get is something like 10 byte of string allocations but it would be
helpful to see let say top N
Hello,
Arghh, same issue with gmcs from SVN. Marek, are you already aware of
this issue or do you want me to file a bug..?
No, please fill a bug report.
Thanks
Marek
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Marek Safar wrote:
Hello,
Arghh, same issue with gmcs from SVN. Marek, are you already aware of
this issue or do you want me to file a bug..?
No, please fill a bug report.
Thanks for your reply Marek!:
https://bugzilla.novell.com/show_bug.cgi?id=412595
I'll try to cook a smaller
Andrés G. Aragoneses wrote:
Andrés G. Aragoneses wrote:
Zoltan Varga wrote:
[...]
In case anyone wants to revert their tree to before the merge, the before
merge
revision is r108475.
(Just FYI)
It's a shame because, at that revision, there's an mcs bug that prevents
you from compiling
All,
Can someone help, I have compiled mono and olive for Win32 and it all
seems to be working, but I would like to run nunit with a set of .NET
3.5 assemblies from mono, so looking at the command line help it looks
like I should be able to do
mono -runtime=3.5 nunit-x86.exe
But this
Hey,
On 7/28/08, [EMAIL PROTECTED]
mono –runtime=3.5 nunit-x86.exe
You're mixing runtime versions and .net release versions. Simply run
mono yourassembly.exe
The assembly name containing -x86.exe looks suspicious though, as it
sounds it could contain pieces of native code.
--
Jb Evain
Well the issue is that I need to run nunit on the assembly (it is full
of unit tests) and nunit is marked as a v2.0 assembly so to get it to
load the v3.5 assembly I need to tell mono to use the 3.5 runtime
I know the tests should be using only code that mono implements (within
olive) but I
On 7/28/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Well the issue is that I need to run nunit on the assembly (it is full
of unit tests) and nunit is marked as a v2.0 assembly so to get it to
load the v3.5 assembly I need to tell mono to use the 3.5 runtime
I know the tests should be
OK I see what you saying, what I need to get is we now reference the
WindowsBase.dll assembly to get access to the new ZIP file functionality
and I need to get mono to resolve this.
Russell
-Original Message-
From: Jb Evain [mailto:[EMAIL PROTECTED]
Sent: 28 July 2008 14:45
To: Russell
Mono will allow only pure managed assemblies no matter the version is.
I doubt that WindowsBase.dll is a pure managed assembly.
On Mon, Jul 28, 2008 at 5:01 PM, [EMAIL PROTECTED] wrote:
OK I see what you saying, what I need to get is we now reference the
WindowsBase.dll assembly to get access
On 7/28/08, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
OK I see what you saying, what I need to get is we now reference the
WindowsBase.dll assembly to get access to the new ZIP file functionality
and I need to get mono to resolve this.
The Zip thing in WindowsBase is not implemented yet.
Hello All,
I have a patch for the trunk that gets WInx64 back to a running state
with the new Linear IR code. As Zoltan promised it was mostly
relocating some of my previous commits to a new location.
If this patch is too large and needs to be split into smaller changes
I can do that.
As far
Hi,
This is ok to check in.
Zoltan
2008/7/28 Bill Holmes [EMAIL PROTECTED]:
Hello All,
I have a patch for the trunk that gets WInx64 back to a running state
with the new Linear IR code. As Zoltan promised it was mostly
relocating some of my previous commits to a new
On Mon, 2008-07-28 at 11:23 +0100, Marek Safar wrote:
Would it be possible to show detailed string allocations? What I usually
get is something like 10 byte of string allocations but it would be
helpful to see let say top N strings.
Well, possible, yes, like everything :-)
The profiler
Hello All,
I am sending an update to this patch since there have been some
discussion since the original posting.
The 2 changes since the previous patch are in mono_arch_emit_epilog.
@@ -4186,6 +4192,11 @@
}
}
+ if (MONO_TYPE_ISSTRUCT (mono_method_signature
Hi,
2008/7/28 Bill Holmes [EMAIL PROTECTED]:
Hello All,
I am sending an update to this patch since there have been some
discussion since the original posting.
The 2 changes since the previous patch are in mono_arch_emit_epilog.
@@ -4186,6 +4192,11 @@
}
}
+
Hello Zoltan,
This was a link that was shared with me on IRC.
From http://www.sco.com/developers/devspecs/abi386-4.pdf
A function that returns a structure or union also sets %eax to the
value of the original
address of the caller's area before it returns. Thus when the caller receives
control
Hi guys,
I'm not sure whether my mail from Thursday actually made it to the list
(I lost my entire mono-devel-list archive and parts of x-m-l), so in
case you don't already know:
The debugger will be branched for Mono 2.0 this Friday (August 1st) or
on Saturday afternoon - I'll do that before
21 matches
Mail list logo
