For the lists info
TLA == Thread Local Allocation
For future searchers and seekers.
Russell
From: Rodrigo Kumpera [mailto:kump...@gmail.com]
Sent: 28 May 2009 13:57
To: Russell Kay
Subject: Re: [Mono-dev] gc heap & multi-threading
Yes, exactly that. Sometimes you'll see TLA
Excuse my ignorance... but TLA??? Three Letter Acronym??? Thread Local
Allocation (my best guess so far).
Russell
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Steve
Bjorg
Sent: 27 May 2009 18:22
To: Rodrigo Kumpera
Cc: mon
Can someone please approve / apply this patch... we really need this
functionality within the main codebase (I am uncomfortable building from
svn for all our target machines, not convinced it is all built
correctly).
Russell
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-
Rodrigo,
IntPtr objects are very awkward to use and optimise badly, we unwrap an
IntPtr to an internal type called Ptr, that is an enum based on a long,
as this generates much better code within loops and generally inlines
better (on both Mono and MS.Net) we also keep this as a long so that we
Replying to myself here
Using the output from this small program
using System;
namespace ConsoleApplication4
{
enum Ptr : long
{
}
class Program
{
static unsafe void Main(string[] args)
{
IntPtr test = new IntPtr(0x);
Ptr testL
We get addresses on Linux that are >2Gb from malloc in the native code,
if we go through the conversion from int (i.e.)IntPtr.ToInt64() is not
giving a sign extended value back when this happens and then a cast to
IntPtr will fail. The cast from a pointer i.e. void* or byte* will also
not sign exte
All,
I have encountered a problem with the Oracle Data Client when porting an
application over from Windows, basically we are using NHibernate as a
frontend to the database and we have recently moved the backend from
MySQL (for development) to Oracle (for deployment) and we encountered a
proble
All,
Not sure the best way to submit this, please correct me if there is a
better way to do this (via bugzilla?)
I encountered a problem when casting a long to an IntPtr, which is
something we have ended up doing a lot (we want to keep binary assembly
compatibility between x86 and x64, only
Yes but this is only for a very small class of functions that we know
will work correctly within these constraints... its not for everyone I
know, but it is still a feature that we would like to have.
Russell
-Original Message-
From: Mark Probst [mailto:mark.pro...@gmail.com]
Sent: 04 Fe
Well it was a thought, we are looking for something like this in the
future for our own classes (particularly maths heavy functions), so this
is something that we can overcome ourselves (we are planning on using
something like Cecil to rewrite the assemblies), but if it was available
within the com
I just want the compiler to inline the functions in IL in a similar way
that a C++ compiler would do it, I know that the "correct" way is for
the JIT to do this, but this has other semantic problems that need to be
overcome. In the short term however having the ability to do this easily
through the
Could we please get a __forceinline for the compiler allowing us to make
decisions at compile time to help us with optimisation.
I know that the long term and "correct" answer is to put this sort of
thing in the Jit but in the short term can we please be treated like
grownups and get some way of t
All,
I have recently upgraded to the released version of IronPython 2.0 in
our embedded scripting and I have it all working under windows, but when
I try to run it on Mono I get this error
NUnit version 2.4.8
Copyright (C) 2002-2007 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk,
Rodrigo,
My only problem with this is the language is tied to the x86
architecture, when Altivec or Paired Single etc are added for PowerPC
then these attributes are nonsensical and will mean nothing to the user.
This would be better done in a static location (rather than spread over
the libra
Thanks all... looks like this is working from trunk much nicer.
Russell
From: Rodrigo Kumpera [mailto:[EMAIL PROTECTED]
Sent: 03 November 2008 14:08
To: Russell Kay
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Getting a dissasembly of a function
Russel, run mono --versi
Is this in Trunk? I am currently working from trunk?
Russell
-Original Message-
From: Zoltan Varga [mailto:[EMAIL PROTECTED]
Sent: 03 November 2008 13:46
To: Russell Kay
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Getting a dissasembly of a function
Hi,
In mono 2.2, t
All,
Is there any easy way to get a disassembly of a function that has been
through the JIT. Currently I am running with multiple "verbose" options
on the command line, writing the output through a file and then
searching for the function but that is fairly horrible, is there an
easier way?
Thanks very much, that got me past that stage. I now have a hang during
make the output is
../errors\cs5001.cs
../errors\cs5001.xml
../errors\CSExternAlias-lib.cs
Ignoring file ../errors\CSExternAlias-lib.cs
../errors\CSExternAlias-lib.xml
../errors\CSFriendAssembly-lib.cs
Ignoring file ../errors
All,
I've just done an update from SVN on trunk and I am getting the
following error
CC mono-endian.lo
CC mono-config.lo
make[3]: *** No rule to make target `rawbuffer.c', needed by
`rawbuffer.lo'. Stop.
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Erro
: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Win32 Mono 2.0 compiled from SVN branch - dies
inside mono_get_lmf_addr
Looks like you're not the only one hitting this... See
https://bugzilla.novell.com/show_bug.cgi?id=414159
Andy
russell.kay wrote:
>
> All,
>
>
All,
Does anyone have any ideas why I am seeing my code dying inside
mono_get_lmf_addr at the g_assert_not_reached(), it looks like this code
has something to do with trampolines but there are not a lot of comments
around this function.
I have compiled mono from the 2.0 branch (using cygwin
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 K
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 cannot
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 d
All,
I was just wondering what the plans are for implementing the
System.AddIn namespace, are there any official plans on the horizon for
implementing this and any other core features of .NET 3.x, I could not
see anything on the roadmap
http://www.mono-project.com/Mono_Project_Roadmap or perhap
True,...
In this case I was ripping an example I had that was using a union type
layout, which does need this type of arrangement... Apologies all round.
For simple structures C/C++ is pretty portable these days between
architectures, the main issue is 32bit/64bit and pointers (and any
alignment
The C# version of this Structure would be best expressed as
[StructLayout(LayoutKind.Explicit)]
unsafe struct FrameGrab
{
[FieldOffset(0)]
public int bufferlength;
[FieldOffset(4)]
Public fixed IntPtr buffer[1000]
}
One question are you definitely wanting an array
27 matches
Mail list logo
