So, on Mono 2.6.3 it looks like System.Array.Copy does not go the fast route
if the arrays are of type float[,], that is, it copies the arrays
value-by-value, which is very slow. Using a fast version (e.g., memcpy, or
whatever is under the hood) for multi-dimensional arrays looks like
The endian conversion in the property
Mono.Zeroconf.Providers.Bonjour.Service.UPort is wrong; casting
between an int and a ushort doesn't do the right thing —
NetworkToHostOrder will shift the low bytes into the high bytes, but
casting that to a ushort discards the high bytes.
Patch
On Sep 23, 2009, at 2:21 PM, Casey Marshall wrote:
The endian conversion in the property
Mono.Zeroconf.Providers.Bonjour.Service.UPort is wrong; casting
between an int and a ushort doesn't do the right thing —
NetworkToHostOrder will shift the low bytes into the high bytes, but
casting
On Apr 9, 2009, at 2:20 PM, Jonathan Pryor wrote:
On Thu, 2009-04-09 at 12:56 -0700, Casey Marshall wrote:
Nope. At least, it doesn't if I run monodoc like this:
mdoc update --out=generated-docs --import=xmldoc/bar.xml
bin/Debug/bar.dll
...and don't specify all the .dlls that foo.dll
On Apr 7, 2009, at 7:08 PM, Jonathan Pryor wrote:
On Tue, 2009-04-07 at 17:54 -0700, Casey Marshall wrote:
`foo.dll' is an assembly I've built (forgive the obfuscation). It's
typically a very core assembly, i.e., one very high up in the
dependency tree, and most certainly is in the same
On Apr 6, 2009, at 8:56 PM, Jonathan Pryor wrote:
On Mon, 2009-04-06 at 17:06 -0700, Casey Marshall wrote:
Sometime ago, though, it looks like `monodocer' became an alias for
`mdoc update'. I'm having trouble getting mdoc-update to do the right
thing.
This happened with Mono 2.0.
I tried
On Apr 7, 2009, at 4:06 PM, Casey Marshall wrote:
On Apr 6, 2009, at 8:56 PM, Jonathan Pryor wrote:
Also, what is 'foo.dll'? Is it a library that you built, or a
GAC-located assembly? If you're using Mono 2.4, Cecil will only
check
the GAC and the directories of assemblies specified
I'm trying to use mdoc, along with the monodoc asp pages and the
monodoc browser, to deploy some internal API documentation. I'm having
trouble getting it to produce documentation for all our assemblies
(80, which will grow to more than 100).
I had been using `monodocer' in previous
On Mar 28, 2009, at 7:32 PM, Zoltan Varga wrote:
Hi,
This should now be fixed in SVN HEAD and the 2.4 branch.
Was this included in the 2.4 tarball?
Zoltan
On Wed, Mar 25, 2009 at 9:57 PM, Casey Marshall casey.s.marsh...@gmail.com
wrote:
I'm getting an intermittent
I'm getting an intermittent assertion failure on mono 2.4 RC3, x86_64
Ubuntu 8.04, when running NUnit 2.4.7 on an assembly that doesn't have
any unit tests defined in it. It seems like it has something to do
with what is happening when the program is shutting down.
Naturally, since it's
Compiling this: http://github.com/jskeet/dotnet-protobufs/tree/master
With gmcs 2.0.1, I get this:
Unhandled Exception: System.NullReferenceException: Object reference
not set to an instance of an object
at Mono.CSharp.GenericConstraints.get_IsReferenceType () [0x00049]
in
An issue we ran into when embedding mono into another program was that
the configuration file of the application domain wasn't being
initialized, so accessing that later (i.e., stuff in
ConfigurationManager) would cause a null pointer dereference.
I'll attach the patch we're using to fix this; it
On Fri, Sep 19, 2008 at 8:57 AM, GrahamNewton
[EMAIL PROTECTED] wrote:
Hello
I am trying to cross compile mono onto another x86 linux distribution and I
am having a problem with libtool inserting wrong library paths. An example
is in mono/metadata where libtool converts the command line
I'm getting a SEGV in the function `mono_class_is_assignable_from' when
trying to compile some internal code. I can't get the location in my
source code where the error occurs, but I'll add some info from GDB to
this email. Has anyone seen something like this before?
This is with a mono/gmcs
is 'public class XXXT : IComparableXXXT'. These
FindRelevant methods are called in various places in the containing
class, always with an argument of type XXXT[]. Renaming the latter
method fixed this issue, but I'll still try to make a concise test case.
Casey Marshall wrote:
I'm getting a SEGV
Bug filed with test case: https://bugzilla.novell.com/show_bug.cgi?id=423975
This is easy to work around in my case, so it's low priority.
Casey Marshall wrote:
Running gmcs under the mono debugger got me further: I was able to find
the code causing the issue.
There were two methods
Zoltan Varga wrote:
Hi,
Try running the app with G_SLICE=always-malloc. That would force
glib to allocate all
memory using malloc, helping valgrind to produce more meaningful leak reports.
That was immensely helpful! It now looks like it's leaking information
about function
I've been seeing a memory leak -- or, maybe instead, unbounded memory
growth -- while running MonoDevelop (SVN code of MD, mono-2-0 SVN of
Mono). I've been running it under valgrind, and after running it
overnight, I find traces like this in the output:
==7947== 862,223,392 bytes in 1,737,838
narrow it down.
In the mean time, do you mind sending the whole valgrind report?
Thanks,
Rodrigo
On Thu, Aug 14, 2008 at 3:07 PM, Casey Marshall
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
I've been seeing a memory leak -- or, maybe instead, unbounded memory
growth
Rodrigo Kumpera wrote:
Hi Casey,
I have an idea on what might be the cause of the leak, and it only
happens under amd64 and aot.
Under amd64 mono_analyze_liveness2 is called from mono_analyze_liveness
if aot is enabled.
This will set MonoMethodVar::interval for a bunch of vars.
In
Revision 110267 breaks the build for me on x86_64, or wherever
MONO_ARCH_SIGSEGV_ON_ALTSTACK is defined. Is maybe the attached patch
what was intended? Or should the #ifdef around the first jit_tls
declaration be removed?
Thanks.
Index: mono/mini/mini.c
On Wed, 2008-07-16 at 15:00 +0200, Lluis Sanchez Gual wrote:
El dt 15 de 07 de 2008 a les 17:34 -0700, en/na Casey Marshall va
escriure:
I've been tracking the SVN sources of mono and MonoDevelop, and I'm
especially interested in the debugger support in MonoDevelop, and had
some questions
On Wed, 2008-07-16 at 10:30 -0700, Casey Marshall wrote:
On Wed, 2008-07-16 at 15:00 +0200, Lluis Sanchez Gual wrote:
El dt 15 de 07 de 2008 a les 17:34 -0700, en/na Casey Marshall va
escriure:
Some of the views that exist now are pretty neat, but what about things
like, say, visually
On Wed, 2008-07-16 at 20:33 +0200, Lluis Sanchez Gual wrote:
El dc 16 de 07 de 2008 a les 11:19 -0700, en/na Casey Marshall va
escriure:
On Wed, 2008-07-16 at 10:30 -0700, Casey Marshall wrote:
On Wed, 2008-07-16 at 15:00 +0200, Lluis Sanchez Gual wrote:
El dt 15 de 07 de 2008 a les 17
I've been tracking the SVN sources of mono and MonoDevelop, and I'm
especially interested in the debugger support in MonoDevelop, and had
some questions about it:
It's clearly still in development, but what are the plans and timeline?
Some of the views that exist now are pretty neat, but what
On Thu, 2008-07-03 at 10:44 +0200, Gert Driesen wrote:
Hey Casey,
Miguel prepared a fix for this issue (committed by Martin in r107127), and
I've added a unit test based on your repro.
Works fine now, both in the test case and the real app.
Thanks!
With SVN sources as of today (but it's been this way for a while):
using System;
using System.Threading;
public interface xT
{
T Value { get; }
}
public class yT
{
xT[] xs;
int l;
public y(int n, int l)
{
xs = new xT[n];
On Tue, 2008-06-24 at 16:30 -0400, Marek Safar wrote:
Hello Casey,
With SVN sources as of today (but it's been this way for a while):
I believe I have fixed the issue Could you please re-test is with SVN HEAD.
Yeah, both the test and the real code I'm working with compile now.
I've noticed that it recent SVN mono snapshots (r106513) using
HttpListener and WebRequest in the same process hangs. This doesn't hang
with 1.9.1, and didn't with less recent snapshots.
I haven't tried having the client and server in different processes, and
don't know if it reproduces there.
On Mon, 2008-06-16 at 17:38 -0600, M. David Peterson wrote:
Was about to report this to Novell:Bugzilla but after a quick
search[1] it seems there may be plenty of related bugs, so thought it
better to get a quick clarification first.
I filed this bug on this (or a similar) error:
I'm developing an application that will embed Mono, and I'd like to be
able to find classes by name by searching what's installed in the GAC,
instead of specifying the assembly to get the class from.
That is, I'm following the recipe from the embedding mono web page:
- Create a domain.
-
On Mon, 2008-04-21 at 21:44 +0200, Robert Jordan wrote:
Hi,
Casey Marshall wrote:
I'm developing an application that will embed Mono, and I'd like to be
able to find classes by name by searching what's installed in the GAC,
instead of specifying the assembly to get the class from
On Tue, 2008-04-08 at 10:14 +0100, Marek Safar wrote:
Hello Casey,
I've noticed that on a recent SVN build of mono, I get a CS0019 error if
I try to compare a value type against null. E.g.:
DateTime dt;
if (dt != null)
Console.WriteLine(dt);
As far as I can tell, this is
On Tue, 2008-04-08 at 19:26 +0100, Marek Safar wrote:
Hello,
So, my question is, what's going on here? Does anyone know what the
semantics are if the compiler generates a conditional based on a
`valuetype CMP null' test?
This particular comparison is in-lined to false
On Tue, 2008-04-08 at 12:53 +0100, Marek Safar wrote:
Hello Andrés,
Marek Safar wrote:
Hello Casey,
I've noticed that on a recent SVN build of mono, I get a CS0019 error if
I try to compare a value type against null. E.g.:
DateTime dt;
if (dt != null)
On Tue, 2008-04-08 at 20:38 +0100, Marek Safar wrote:
Hello,
I'm working with code that does this:
if (valuetype != null)
{
// Code assuming `valuetype' is initialized.
}
This is correct, and `valuetype' will be always initialized
Yes, but the body of the 'if' is
I've noticed that on a recent SVN build of mono, I get a CS0019 error if
I try to compare a value type against null. E.g.:
DateTime dt;
if (dt != null)
Console.WriteLine(dt);
As far as I can tell, this is the correct behavior, since a value type
can't be null. I'm concerned, though,
On Fri, 2008-03-14 at 17:03 +0100, Paolo Molaro wrote:
On 03/07/08 Casey Marshall wrote:
The attached patches add a partial implementation of DynamicILInfo --
basically enough that you can specify the IL code and locals for a
method, and have that method runnable.
I might work
The attached patches add a partial implementation of DynamicILInfo --
basically enough that you can specify the IL code and locals for a
method, and have that method runnable.
I might work on this more if I have time, *plus* I'm not sure if this
here is too naive, and would need to change a lot
This change seems to break the build for me:
--- mono/metadata/verify.c (revision 97000)
+++ mono/metadata/verify.c (working copy)
@@ -235,6 +235,8 @@
static gboolean
token_bounds_check (MonoImage *image, guint32 token)
{
+ if (image-dynamic)
+ return
Hi,
I'm trying to use F# with mono, and most everything works fine, except
when I try to reference FSharp.Core.dll from a C# assembly. I get this
error:
error CS0433: The imported type `System.Action`2' is defined multiple
times
Hi. The attached patch to mcs seems to fix bug 357047 (which I also
filed). The issue is that the compiler can't tell that:
enumerable.Average(o = op on o that returns a double);
or
enumerable.Average(delegate(T o) { return (op on o that returns a
double); });
Means
42 matches
Mail list logo
