Re: [Mono-dev] gmcs and The Future
Doesn't it make more sense to add something like a macro system (see Boo, Nemerle, Scheme, ...) ? That way you would only change the compiler once (for the macro resolution) and then you can extend the language at your wish in external libraries (as with Mono.Rocks). The three main advantages I see with this approach are : 1) it's less burden on compiler maintenance (only one component to care about), 2) people can more properly select the feature they wish to use (simply choosing what to link in their project), 3) it can make contribution easier (no need to know the compiler inner-working). Anyway, my two cents. -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Wed, Feb 11, 2009 at 6:18 AM, Scott Peterson sc...@ssblack.co.nz wrote: This should get things started: http://cheddar.wik.is/ We can move hosts later it we want. ___ 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] gmcs and The Future
Sounds to me like you should suggest that on the wiki ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Thread shutdown hook patch
On 02/09/09 Rodrigo Kumpera wrote: The attached patch adds a new hook to allow threads to shutdown after the GC finalizer has finished. The motivation for it is to improve profiler's reliability at shutdown time. The new callback notifies the thread when regular shutdown starts and gives it a change to not finish at this time. Later on the same callback is used to notify the thread that the last stage in the shutdown sequence has been reached and it must shutdown. The callback is per-thread as I don't want to have tools like the profiler messing up with embedded users. I think this instroduces too much complexity: since the API is public we'd need to end up maintaining the semantics as they happen to be now. It would be much clearer to have a flag on the thread that behaves similarly to critical finalizers: the thread that has it set will be destroyed as late as possible on shutdown. As for the callback, the existing mono_profiler_thread_end () should be enough: if it isn't we need to discuss how we can fix that instead of adding yet another callback. lupus -- - lu...@debian.org debian/rules lu...@ximian.com Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for IntPtr bug
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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. IntPtr.diff Description: IntPtr.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Oracle Data Client issue
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 problem with the System.Data.OracleClient basically not handling the OciDataType.Float and OciDataType.Integer. I have checked with our resident Database experts and they assure me that this is the way it should be, can someone who knows the inner workings of this code please take a look and verify that my patch (which seems to work, for our purposes) is the correct way to go. All contributions under the MIT X11 license. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. OracleParameter.diff Description: OracleParameter.diff ___ 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 IntPtr bug
russell@realtimeworlds.com wrote: 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). The patch is wrong, since casting a long Int32.MaxValue to a 4 byte signed intptr is simply invalid. The current check in IntPtr.cs also matches MS.NET. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Oracle Data Client issue
2009/2/11 russell@realtimeworlds.com: 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 problem with the System.Data.OracleClient basically not handling the OciDataType.Float and OciDataType.Integer. I have checked with our resident Database experts and they assure me that this is the way it should be, can someone who knows the inner workings of this code please take a look and verify that my patch (which seems to work, for our purposes) is the correct way to go. All contributions under the MIT X11 license. Regards Russell Patch looks good, but I no longer have the environment at hand to verify this. ___ 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 IntPtr bug
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 extend the long. The conversion is not sign extending the long (perhaps because it does actually fit)... My patch is correct. Russell -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Robert Jordan Sent: 11 February 2009 15:24 To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Patch for IntPtr bug russell@realtimeworlds.com wrote: 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). The patch is wrong, since casting a long Int32.MaxValue to a 4 byte signed intptr is simply invalid. The current check in IntPtr.cs also matches MS.NET. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ 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 IntPtr bug
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 testLong = (Ptr)test.ToInt64();
Console.WriteLine(test = {0}, testLong={1}, test,
testLong);
IntPtr testAnother = (IntPtr)testLong;
Console.WriteLine(testAnother = {0}, testAnother);
void* p = test.ToPointer();
Console.WriteLine(p = {0}, (long)p);
}
}
}
You will see that under MS.NET the output is
test = 4294967295, testLong=4294967295
testAnother = 4294967295
p = 4294967295
note the complete absence of sign extended values.
The output from Mono on OpenSuse 11.0 Linux
test = -1, testLong=-1
testAnother = -1
p = 4294967295
So the pointer conversion from void* to long is not sign extending under
Mono, and it is different output to MS.NET.
Russell
-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of
russell@realtimeworlds.com
Sent: 11 February 2009 15:45
To: robe...@gmx.net; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Patch for IntPtr bug
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 extend the long.
The conversion is not sign extending the long (perhaps because it does
actually fit)...
My patch is correct.
Russell
-Original Message-
From: mono-devel-list-boun...@lists.ximian.com
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Robert
Jordan
Sent: 11 February 2009 15:24
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Patch for IntPtr bug
russell@realtimeworlds.com wrote:
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 changing the native code on
the
different architectures). We encountered a problem with Mono as there
has been a check introduced into the IntPtr constructor from a long,
this is checking the range of the long to ensure it is in range,
unfortunately the check is incorrect. A long can easily hold from
Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it
currently in there).
The patch is wrong, since casting a long Int32.MaxValue to a
4 byte signed intptr is simply invalid.
The current check in IntPtr.cs also matches MS.NET.
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
This email has been scanned by the MessageLabs Email Security System
DISCLAIMER
This message and any attachments contain privileged and confidential
information intended for the use of the addressee named above. If you
are not the intended recipient of this message, you are hereby notified
that any use, dissemination, distribution or reproduction of this
message is prohibited. Please note that we cannot guarantee that this
message or any attachment is virus free or that it has not been
intercepted and amended. The views of the author may not necessarily
reflect those of Realtime Worlds Ltd.
Realtime Worlds Ltd is registered in Scotland, number 225628. Registered
Office: 152 West Marketgait, Dundee, DD1 1NJ.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
This email has been scanned by the MessageLabs Email Security System
DISCLAIMER
This message and any attachments contain privileged and confidential
information intended for the use of the addressee named above. If you are not
the intended recipient of this message, you are hereby notified that any use,
dissemination, distribution or reproduction of this message is prohibited.
Please note that we cannot guarantee that this message or any attachment is
virus free or that it has not been intercepted and amended. The views of the
author may not necessarily reflect those of Realtime Worlds Ltd.
Realtime Worlds Ltd is registered in Scotland, number 225628. Registered
Office: 152 West Marketgait, Dundee, DD1 1NJ.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
Re: [Mono-dev] Current 'xbuild' status
using today's svn version, .proj file generated with set MSBuildEmitSolution=1 trick: [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. MSBUILD: error MSBUILD: /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. (project is EVEMon, from svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk) On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain radi...@gmail.com wrote: xbuild (svn) can't directly handle .sln files right now. But it can build the temporary .proj that msbuild generates for .sln files. We can build the .sln.proj with multiple projects. Its not complete yet though. Currently, it generates the resources, satellite assemblies, resolves gac/assembly references, compiles, but doesn't deploy the referenced assemblies etc to the right location. But most of this will be work in the .targets . It should be easy to write a sln- proj convertor. List of msbuild features from msdn ( http://msdn.microsoft.com/en-us/library/ms171452.aspx ) • Items ∘ Supported. These are used all over the place, so seems to work fine for current test cases • Properties ∘ Likewise • Targets ∘ Implemented ∘ Including dependency checking, in the form of input/output list, DependsOnTargets etc • Tasks ∘ Implemented ∘ Most of the functionality in msbuild files are based on using tasks. Custom tasks can be loaded • Advanced Concepts ∘ Logging ‣ Implemented. But its not being used throughout the system right now to report errors/warnings. ∘ Batching ( http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx ) ‣ Very important feature ‣ Both task and target batching have been implemented, and seem to be working fine ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx ) ‣ Supported ∘ Using multiple processors ( http://msdn.microsoft.com/en-us/library/bb383805.aspx ) ‣ Nothing has been done for this yet • Building for Specific .NET Frameworks ( http://msdn.microsoft.com/en-us/library/bb397456.aspx ) ∘ I've added some preliminary support for TargetFramework* stuff, but this will need more work ∘ Similar work done in monodevelop should prove useful here • Others ∘ Project references, assembly, gac references are resolved ‣ I committed kinda preliminary code for this, which works fine in the simple test cases (eg. pdn3) that I tried Ofcourse, most of this hasn't been tested extensively. I try to write reasonable number of tests for the stuff that I'm touching, but real testing would happen once the targets files are more complete and we try real world projects. Would be nice to start trying this out and get feedback/bug reports :) I'll be on vacation till end of next week, but will try to reply to mails. -Ankit -- Blog : http://www.ankitjain.org/blog ___ 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] Current 'xbuild' status
Hello, I am guessing xbuild is only supporting 2.0 for now. I am not sure how much effort is needed to support 3.5/2008 projects. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski skol...@gmail.comwrote: using today's svn version, .proj file generated with set MSBuildEmitSolution=1 trick: [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. MSBUILD: error MSBUILD: /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. (project is EVEMon, from svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk ) On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain radi...@gmail.com wrote: xbuild (svn) can't directly handle .sln files right now. But it can build the temporary .proj that msbuild generates for .sln files. We can build the .sln.proj with multiple projects. Its not complete yet though. Currently, it generates the resources, satellite assemblies, resolves gac/assembly references, compiles, but doesn't deploy the referenced assemblies etc to the right location. But most of this will be work in the .targets . It should be easy to write a sln- proj convertor. List of msbuild features from msdn ( http://msdn.microsoft.com/en-us/library/ms171452.aspx ) • Items ∘ Supported. These are used all over the place, so seems to work fine for current test cases • Properties ∘ Likewise • Targets ∘ Implemented ∘ Including dependency checking, in the form of input/output list, DependsOnTargets etc • Tasks ∘ Implemented ∘ Most of the functionality in msbuild files are based on using tasks. Custom tasks can be loaded • Advanced Concepts ∘ Logging ‣ Implemented. But its not being used throughout the system right now to report errors/warnings. ∘ Batching ( http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx ) ‣ Very important feature ‣ Both task and target batching have been implemented, and seem to be working fine ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx ) ‣ Supported ∘ Using multiple processors ( http://msdn.microsoft.com/en-us/library/bb383805.aspx ) ‣ Nothing has been done for this yet • Building for Specific .NET Frameworks ( http://msdn.microsoft.com/en-us/library/bb397456.aspx ) ∘ I've added some preliminary support for TargetFramework* stuff, but this will need more work ∘ Similar work done in monodevelop should prove useful here • Others ∘ Project references, assembly, gac references are resolved ‣ I committed kinda preliminary code for this, which works fine in the simple test cases (eg. pdn3) that I tried Ofcourse, most of this hasn't been tested extensively. I try to write reasonable number of tests for the stuff that I'm touching, but real testing would happen once the targets files are more complete and we try real world projects. Would be nice to start trying this out and get feedback/bug reports :) I'll be on vacation till end of next week, but will try to reply to mails. -Ankit -- Blog : http://www.ankitjain.org/blog ___ 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] Current 'xbuild' status
When I forced msbuild 2.0 and regenerated the project, xbuild bails out on ResolveAssemblyReferences. Log attached. On Wed, Feb 11, 2009 at 5:35 PM, Jonathan Chambers jonc...@gmail.com wrote: Hello, I am guessing xbuild is only supporting 2.0 for now. I am not sure how much effort is needed to support 3.5/2008 projects. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski skol...@gmail.com wrote: using today's svn version, .proj file generated with set MSBuildEmitSolution=1 trick: [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. MSBUILD: error MSBUILD: /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. (project is EVEMon, from svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk) On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain radi...@gmail.com wrote: xbuild (svn) can't directly handle .sln files right now. But it can build the temporary .proj that msbuild generates for .sln files. We can build the .sln.proj with multiple projects. Its not complete yet though. Currently, it generates the resources, satellite assemblies, resolves gac/assembly references, compiles, but doesn't deploy the referenced assemblies etc to the right location. But most of this will be work in the .targets . It should be easy to write a sln- proj convertor. List of msbuild features from msdn ( http://msdn.microsoft.com/en-us/library/ms171452.aspx ) • Items ∘ Supported. These are used all over the place, so seems to work fine for current test cases • Properties ∘ Likewise • Targets ∘ Implemented ∘ Including dependency checking, in the form of input/output list, DependsOnTargets etc • Tasks ∘ Implemented ∘ Most of the functionality in msbuild files are based on using tasks. Custom tasks can be loaded • Advanced Concepts ∘ Logging ‣ Implemented. But its not being used throughout the system right now to report errors/warnings. ∘ Batching ( http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx ) ‣ Very important feature ‣ Both task and target batching have been implemented, and seem to be working fine ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx ) ‣ Supported ∘ Using multiple processors ( http://msdn.microsoft.com/en-us/library/bb383805.aspx ) ‣ Nothing has been done for this yet • Building for Specific .NET Frameworks ( http://msdn.microsoft.com/en-us/library/bb397456.aspx ) ∘ I've added some preliminary support for TargetFramework* stuff, but this will need more work ∘ Similar work done in monodevelop should prove useful here • Others ∘ Project references, assembly, gac references are resolved ‣ I committed kinda preliminary code for this, which works fine in the simple test cases (eg. pdn3) that I tried Ofcourse, most of this hasn't been tested extensively. I try to write reasonable number of tests for the stuff that I'm touching, but real testing would happen once the targets files are more complete and we try real world projects. Would be nice to start trying this out and get feedback/bug reports :) I'll be on vacation till end of next week, but will try to reply to mails. -Ankit -- Blog : http://www.ankitjain.org/blog ___ 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 XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. Build started 02/11/2009 17:50:43. __ Project /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj (Build target(s)): Target ValidateSolutionConfiguration: Tworzenie konfiguracji rozwi?zania Debug|Mixed Platforms. Target Build: Project /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj (EVEMon target(s)): Target EVEMon_Common: Project /root/mono_svn/EVEMon/EVEMon.Common/EVEMon.Common.csproj (Build target(s)): Target PrepareForBuild: Configuration: Debug Platform: AnyCPU Created directory obj/ Target ResolveAssemblyReferences: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an
Re: [Mono-dev] Patch for IntPtr bug
Russel, I think the issue is that you're using long to represent pointers when you should be using IntPtr only. 2009/2/11 russell@realtimeworlds.com 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ 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] Current 'xbuild' status
I have seen this repeatedly and have not been able to figure out why (unless it's just old things lying around). If you look in your GAC, somewhere you will have 2 versions of some assembly that both are 2.0.0.xxx. The current resolve logic chokes on this trying to add a duplicate key to a dictionary. It probably shouldn't fail but I can't figure out why there are two assemblies with similar version numbers. If you modify the code in xbuild where it is populating the dictionary you can output the duplicate assembly. In fact, I'll try and add code that outputs the duplicate assembly and handle the error case better. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:55 AM, Leszek Ciesielski skol...@gmail.comwrote: When I forced msbuild 2.0 and regenerated the project, xbuild bails out on ResolveAssemblyReferences. Log attached. On Wed, Feb 11, 2009 at 5:35 PM, Jonathan Chambers jonc...@gmail.com wrote: Hello, I am guessing xbuild is only supporting 2.0 for now. I am not sure how much effort is needed to support 3.5/2008 projects. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski skol...@gmail.com wrote: using today's svn version, .proj file generated with set MSBuildEmitSolution=1 trick: [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. MSBUILD: error MSBUILD: /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. (project is EVEMon, from svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk) On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain radi...@gmail.com wrote: xbuild (svn) can't directly handle .sln files right now. But it can build the temporary .proj that msbuild generates for .sln files. We can build the .sln.proj with multiple projects. Its not complete yet though. Currently, it generates the resources, satellite assemblies, resolves gac/assembly references, compiles, but doesn't deploy the referenced assemblies etc to the right location. But most of this will be work in the .targets . It should be easy to write a sln- proj convertor. List of msbuild features from msdn ( http://msdn.microsoft.com/en-us/library/ms171452.aspx ) • Items ∘ Supported. These are used all over the place, so seems to work fine for current test cases • Properties ∘ Likewise • Targets ∘ Implemented ∘ Including dependency checking, in the form of input/output list, DependsOnTargets etc • Tasks ∘ Implemented ∘ Most of the functionality in msbuild files are based on using tasks. Custom tasks can be loaded • Advanced Concepts ∘ Logging ‣ Implemented. But its not being used throughout the system right now to report errors/warnings. ∘ Batching ( http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx ) ‣ Very important feature ‣ Both task and target batching have been implemented, and seem to be working fine ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx ) ‣ Supported ∘ Using multiple processors ( http://msdn.microsoft.com/en-us/library/bb383805.aspx ) ‣ Nothing has been done for this yet • Building for Specific .NET Frameworks ( http://msdn.microsoft.com/en-us/library/bb397456.aspx ) ∘ I've added some preliminary support for TargetFramework* stuff, but this will need more work ∘ Similar work done in monodevelop should prove useful here • Others ∘ Project references, assembly, gac references are resolved ‣ I committed kinda preliminary code for this, which works fine in the simple test cases (eg. pdn3) that I tried Ofcourse, most of this hasn't been tested extensively. I try to write reasonable number of tests for the stuff that I'm touching, but real testing would happen once the targets files are more complete and we try real world projects. Would be nice to start trying this out and get feedback/bug reports :) I'll be on vacation till end of next week, but will try to reply to mails. -Ankit -- Blog : http://www.ankitjain.org/blog ___ 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] Patch for IntPtr bug
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 have the same assembly on both x86 and x64 (which limits our testing). IntPtr is also fairly horrible to work with when you are doing any maths when working with memory operations (which we are doing a lot). Now this is not a problem and works very well on both Mono and MS.NET , when this patch is applied. I do not see the objection to this patch as an IntPtr can safely hold values that are over 2Gb and they are valid addresses, also converting from a pointer to a long does not sign extend it, which is perfectly valid and at times you do want to convert back to an IntPtr. This is a perfectly safe and sensible patch. Russell From: Rodrigo Kumpera [mailto:kump...@gmail.com] Sent: 11 February 2009 17:01 To: Russell Kay Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Patch for IntPtr bug Russel, I think the issue is that you're using long to represent pointers when you should be using IntPtr only. 2009/2/11 russell@realtimeworlds.com 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Monitor (lock) profiler patch
Hello,
this patch adds hooks to profile monitor activity.
I already have a profiler that uses it, and it works (I must finish the
post processing part but the event writing and decoding works well).
I only posted the runtime portion to keep the review easier...
I know the MonoProfilerMonitorEvent flags look a bit messy.
I made them that way for various reasons:
- be able to describe both high level meaning (enter, exit, success,
failure) and internal details (which we could change in the future),
- keep the bit count low so the profiler needs just one byte to write it
(even without processing logic), and
- do it with flags so that code that filters out uninteresting events
can be fast with as few branches as possible.
If you have better ideas for those flags propose them :-)
Apart from that I think the patch is straightforward.
Thanks!
Massi
diff --git a/mono/metadata/monitor.c b/mono/metadata/monitor.c
index 022495a..73d5253 100644
--- a/mono/metadata/monitor.c
+++ b/mono/metadata/monitor.c
@@ -23,6 +23,7 @@
#include mono/metadata/debug-helpers.h
#include mono/metadata/tabledefs.h
#include mono/metadata/marshal.h
+#include mono/metadata/profiler-private.h
#include mono/utils/mono-time.h
/*
@@ -391,6 +392,8 @@ mono_monitor_try_enter_internal (MonoObject *obj, guint32 ms, gboolean allow_int
mono_raise_exception (mono_get_exception_argument_null (obj));
return FALSE;
}
+
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER);
retry:
mon = obj-synchronisation;
@@ -403,6 +406,7 @@ retry:
mono_gc_weak_link_add (mon-data, obj);
mono_monitor_allocator_unlock ();
/* Successfully locked */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_SUCCESS);
return 1;
} else {
#ifdef HAVE_MOVING_COLLECTOR
@@ -418,10 +422,12 @@ retry:
mono_gc_weak_link_add (mon-data, obj);
mono_monitor_allocator_unlock ();
/* Successfully locked */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_SUCCESS);
return 1;
} else {
mon_finalize (mon);
mono_monitor_allocator_unlock ();
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY);
goto retry;
}
} else if (lw.lock_word LOCK_WORD_FAT_HASH) {
@@ -457,10 +463,12 @@ retry:
mono_gc_weak_link_add (mon-data, obj);
mono_monitor_allocator_unlock ();
/* Successfully locked */
+mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_SUCCESS);
return 1;
} else {
mon_finalize (mon);
mono_monitor_allocator_unlock ();
+mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY);
goto retry;
}
}
@@ -489,9 +497,11 @@ retry:
if (G_LIKELY (InterlockedCompareExchangePointer ((gpointer *)mon-owner, (gpointer)id, 0) == 0)) {
/* Success */
g_assert (mon-nest == 1);
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_SUCCESS);
return 1;
} else {
/* Trumped again! */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY);
goto retry;
}
}
@@ -499,6 +509,7 @@ retry:
/* If the object is currently locked by this thread... */
if (mon-owner == id) {
mon-nest++;
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_SUCCESS|MONO_PROFILER_MONITOR_ENTER_NEST);
return 1;
}
@@ -508,6 +519,7 @@ retry:
/* If ms is 0 we don't block, but just fail straight away */
if (ms == 0) {
LOCK_DEBUG (g_message (G_GNUC_PRETTY_FUNCTION : (%d) timed out, returning FALSE, id));
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_ENTER_TIMEOUT);
return 0;
}
@@ -588,6 +600,7 @@ retry:
if ((ret == WAIT_TIMEOUT || (ret == WAIT_IO_COMPLETION !allow_interruption)) ms 0) {
/* More time left */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY|MONO_PROFILER_MONITOR_RETRY_MORE_TIME);
goto retry;
}
} else {
@@ -597,21 +610,26 @@ retry:
* We have to obey a stop request even if allow_interruption is
* FALSE to avoid hangs at shutdown.
*/
+mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_ENTER_SHUTDOWN);
return -1;
}
/* Infinite wait, so just try again */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY|MONO_PROFILER_MONITOR_RETRY_INFINITE_WAIT);
goto retry;
}
}
if (ret == WAIT_OBJECT_0) {
/* retry from the top */
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_RETRY|MONO_PROFILER_MONITOR_RETRY_CONTENTION_LOOP);
goto retry;
}
/* We must have timed out */
LOCK_DEBUG (g_message (G_GNUC_PRETTY_FUNCTION : (%d) timed out waiting, returning FALSE, id));
+ mono_profiler_monitor_event (obj, MONO_PROFILER_MONITOR_ENTER|MONO_PROFILER_MONITOR_ENTER_TIMEOUT);
+
if (ret == WAIT_IO_COMPLETION)
return -1;
else
@@ -657,9 +675,11 @@
Re: [Mono-dev] Current 'xbuild' status
Something along this patch? :-) And the problematic assemblies follow: Target ResolveAssemblyReferences: Replacing reference to assembly: /opt/mono/lib/mono/gac/System.Runtime.Serialization/2.0.5.0__7cec85d7bea7798e/System.Runtime.Serialization.dll with /opt/mono/lib/mono/gac/System.Runtime.Serialization/2.0.5.0__b77a5c561934e089/System.Runtime.Serialization.dll Replacing reference to assembly: /opt/mono/lib/mono/gac/System.ServiceModel/2.0.5.0__31bf3856ad364e35/System.ServiceModel.dll with /opt/mono/lib/mono/gac/System.ServiceModel/2.0.5.0__b77a5c561934e089/System.ServiceModel.dll Replacing reference to assembly: /opt/mono/lib/mono/gac/System.ServiceModel.Web/2.0.5.0__31bf3856ad364e35/System.ServiceModel.Web.dll with /opt/mono/lib/mono/gac/System.ServiceModel.Web/2.0.5.0__7cec85d7bea7798e/System.ServiceModel.Web.dll They are different because they are signed with different public keys? It's probably because they graduated from olive into mcs, and those trees use different keys AFAIK? Anyway, the resolver has to handle this - probably by including the public key in version information. 2009/2/11 Jonathan Chambers jonc...@gmail.com: I have seen this repeatedly and have not been able to figure out why (unless it's just old things lying around). If you look in your GAC, somewhere you will have 2 versions of some assembly that both are 2.0.0.xxx. The current resolve logic chokes on this trying to add a duplicate key to a dictionary. It probably shouldn't fail but I can't figure out why there are two assemblies with similar version numbers. If you modify the code in xbuild where it is populating the dictionary you can output the duplicate assembly. In fact, I'll try and add code that outputs the duplicate assembly and handle the error case better. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:55 AM, Leszek Ciesielski skol...@gmail.com wrote: When I forced msbuild 2.0 and regenerated the project, xbuild bails out on ResolveAssemblyReferences. Log attached. On Wed, Feb 11, 2009 at 5:35 PM, Jonathan Chambers jonc...@gmail.com wrote: Hello, I am guessing xbuild is only supporting 2.0 for now. I am not sure how much effort is needed to support 3.5/2008 projects. Thanks, Jonathan On Wed, Feb 11, 2009 at 11:28 AM, Leszek Ciesielski skol...@gmail.com wrote: using today's svn version, .proj file generated with set MSBuildEmitSolution=1 trick: [mono] ~/mono_svn/EVEMon @ xbuild EVEMonCSharp.sln.proj XBuild Engine Version 0.1 Mono, Version 2.5.0.0 Copyright (C) Marek Sieradzki 2005. All rights reserved. MSBUILD: error MSBUILD: /root/mono_svn/EVEMon/EVEMonCSharp.sln.proj: Could not load file or assembly 'Microsoft.Build.Tasks.v3.5' or one of its dependencies. The system cannot find the file specified. (project is EVEMon, from svn://evemon.battleclinic.com/EVEMon/EVEMon/trunk) On Thu, Feb 5, 2009 at 11:23 AM, Ankit Jain radi...@gmail.com wrote: xbuild (svn) can't directly handle .sln files right now. But it can build the temporary .proj that msbuild generates for .sln files. We can build the .sln.proj with multiple projects. Its not complete yet though. Currently, it generates the resources, satellite assemblies, resolves gac/assembly references, compiles, but doesn't deploy the referenced assemblies etc to the right location. But most of this will be work in the .targets . It should be easy to write a sln- proj convertor. List of msbuild features from msdn ( http://msdn.microsoft.com/en-us/library/ms171452.aspx ) • Items ∘ Supported. These are used all over the place, so seems to work fine for current test cases • Properties ∘ Likewise • Targets ∘ Implemented ∘ Including dependency checking, in the form of input/output list, DependsOnTargets etc • Tasks ∘ Implemented ∘ Most of the functionality in msbuild files are based on using tasks. Custom tasks can be loaded • Advanced Concepts ∘ Logging ‣ Implemented. But its not being used throughout the system right now to report errors/warnings. ∘ Batching ( http://msdn.microsoft.com/en-us/library/ms171473(VS.80).aspx ) ‣ Very important feature ‣ Both task and target batching have been implemented, and seem to be working fine ∘ Transforms ( http://msdn.microsoft.com/en-us/library/ms171476.aspx ) ‣ Supported ∘ Using multiple processors ( http://msdn.microsoft.com/en-us/library/bb383805.aspx ) ‣ Nothing has been done for this yet • Building for Specific .NET Frameworks ( http://msdn.microsoft.com/en-us/library/bb397456.aspx ) ∘ I've added some preliminary support for TargetFramework* stuff, but this will need more work ∘ Similar work done in monodevelop should prove useful here • Others ∘ Project references, assembly, gac references
Re: [Mono-dev] Patch for IntPtr bug
IntPtr code should optimize as well as int on 32bits machines and long on 64 bits machine. If it's not the case, report it. Working with ints using long will be a lot slower on 32bits machines for sure. Regarding doing pointer math, the usual way to do it with C# is to use a block of unsafe code and use proper pointer types. On Wed, Feb 11, 2009 at 3:12 PM, russell@realtimeworlds.com wrote: 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 have the same assembly on both x86 and x64 (which limits our testing). IntPtr is also fairly horrible to work with when you are doing any maths when working with memory operations (which we are doing a lot). Now this is not a problem and works very well on both Mono and MS.NET , when this patch is applied. I do not see the objection to this patch as an IntPtr can safely hold values that are over 2Gb and they are valid addresses, also converting from a pointer to a long does not sign extend it, which is perfectly valid and at times you do want to convert back to an IntPtr. This is a perfectly safe and sensible patch. Russell *From:* Rodrigo Kumpera [mailto:kump...@gmail.com] *Sent:* 11 February 2009 17:01 *To:* Russell Kay *Cc:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Patch for IntPtr bug Russel, I think the issue is that you're using long to represent pointers when you should be using IntPtr only. 2009/2/11 russell@realtimeworlds.com 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ 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 IntPtr bug
Russell, The CLI has first class support for IntPtr but C# unfortunately needs to call IntPtr methods instead of using opcodes directly. But I believe that these methods should be inlined by the runtime. (If not this should be tracked in bugzilla.) And as Rodrigo said you should use unsafe code with pointer if you want maximal performance because C# has support for pointers and is using unsigned native int arythmetic for them. Also note that pointers are in fact unsigned so you should convert them to usingned integers to avoid sign related issues. And your patch Russell is incorrect because IntPtr is a signed integer that is 32-bit on 32-bit architectures this it cannot hold UInt32.MaxValue. If you want to hold UInt32.MaxValue you should use UIntPtr. Kornél Rodrigo Kumpera wrote: IntPtr code should optimize as well as int on 32bits machines and long on 64 bits machine. If it's not the case, report it. Working with ints using long will be a lot slower on 32bits machines for sure. Regarding doing pointer math, the usual way to do it with C# is to use a block of unsafe code and use proper pointer types. On Wed, Feb 11, 2009 at 3:12 PM, russell@realtimeworlds.com mailto:russell@realtimeworlds.com wrote: 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 have the same assembly on both x86 and x64 (which limits our testing). IntPtr is also fairly horrible to work with when you are doing any maths when working with memory operations (which we are doing a lot). Now this is not a problem and works very well on both Mono and MS.NET http://MS.NET , when this patch is applied. I do not see the objection to this patch as an IntPtr can safely hold values that are over 2Gb and they are valid addresses, also converting from a pointer to a long does not sign extend it, which is perfectly valid and at times you do want to convert back to an IntPtr. This is a perfectly safe and sensible patch. Russell *From:* Rodrigo Kumpera [mailto:kump...@gmail.com mailto:kump...@gmail.com] *Sent:* 11 February 2009 17:01 *To:* Russell Kay *Cc:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Patch for IntPtr bug Russel, I think the issue is that you're using long to represent pointers when you should be using IntPtr only. 2009/2/11 russell@realtimeworlds.com mailto:russell@realtimeworlds.com 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 changing the native code on the different architectures). We encountered a problem with Mono as there has been a check introduced into the IntPtr constructor from a long, this is checking the range of the long to ensure it is in range, unfortunately the check is incorrect. A long can easily hold from Int32.MinValue to UInt32.MaxValue (and not Int32.MaxValue as it currently in there). See attached patch (contributed under the MIT X11 license) to introduce the one extra character that makes the range check correct. Can I also say that I think the check should really be in a Debug.Assert so that it disappears in non-Debug versions, the check is good for sanity checking but superfluous on released code. Regards Russell DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com
Re: [Mono-dev] Thread shutdown hook patch
On Wed, Feb 11, 2009 at 12:55 PM, Paolo Molaro lu...@ximian.com wrote:
On 02/09/09 Rodrigo Kumpera wrote:
The attached patch adds a new hook to allow threads to shutdown after
the
GC finalizer has finished.
The motivation for it is to improve profiler's reliability at shutdown
time.
The new callback notifies the thread when regular shutdown starts and
gives
it a change to not
finish at this time.
Later on the same callback is used to notify the thread that the last
stage
in the shutdown sequence
has been reached and it must shutdown.
The callback is per-thread as I don't want to have tools like the
profiler
messing up with embedded users.
I think this instroduces too much complexity: since the API is public
we'd need to end up maintaining the semantics as they happen to be now.
It would be much clearer to have a flag on the thread that behaves
similarly to critical finalizers: the thread that has it set will be
destroyed as late as possible on shutdown.
As for the callback, the existing mono_profiler_thread_end () should be
enough: if it isn't we need to discuss how we can fix that instead of
adding yet another callback.
lupus
Let's see, to make what you propose work we would have to do the following
changes:
1) Introduce a flag to signal critical threads, which are only shutdown at
the last possible opportunity;
Together with a mono_thread_set_critical (MonoThread*) public API to set
it, or course.
2) Move the profiler shutdown to mono_runtime_cleanup so it happens before
we wait for critical threads;
This is required because the thread shutdown code has no means to ask
unmanaged code to shutdown.
A critical thread is one that
mono_profiler_thread_end doesn't play any role for this issue because it is
called once the thread has finished or detached,
which is not the issue here.
With this patch the code in the profiler gets simpler and more natural.
Everything is done from the profiler shutdown hook and
not piece by piece scattered around.
There is one issue with this patch, there is no unmanaged mechanism to
inform a thread that it must shutdown. Right now this isn't
an issue because the only user will be the profiller and it does all it's
cleanup from the shutdown hook. But it might not be the case
for embedders attaching critical threads.
I don't think this is an usable API without a well defined mechanism to let
embedders/tools know when it's time for a critical thread
to begin to shutdown.
The attached patch implements this proposal, please review.
Cheers,
Rodrigo
Index: metadata/appdomain.c
===
--- metadata/appdomain.c (revision 126598)
+++ metadata/appdomain.c (working copy)
@@ -302,6 +302,10 @@
/* This ends up calling any pending pending (for at most 2 seconds) */
mono_gc_cleanup ();
+ mono_profiler_shutdown ();
+
+ mono_thread_wait_critical_threads ();
+
mono_thread_cleanup ();
#ifndef DISABLE_SOCKETS
Index: metadata/threads.c
===
--- metadata/threads.c (revision 126598)
+++ metadata/threads.c (working copy)
@@ -93,6 +93,10 @@
MonoHazardousFreeFunc free_func;
} DelayedFreeItem;
+enum {
+ MONO_THREAD_CRITICAL = 0x1
+};
+
/* Number of cached culture objects in the MonoThread-cached_culture_info array
* (per-type): we use the first NUM entries for CultureInfo and the last for
* UICultureInfo. So the size of the array is really NUM_CACHED_CULTURES * 2.
@@ -167,6 +171,7 @@
static gboolean mono_thread_resume (MonoThread* thread);
static void mono_thread_start (MonoThread *thread);
static void signal_thread_state_change (MonoThread *thread);
+static gboolean mono_thread_is_critical (MonoThread *thread);
/* Spin lock for InterlockedXXX 64 bit functions */
#define mono_interlocked_lock() EnterCriticalSection (interlocked_mutex)
@@ -2534,6 +2539,11 @@
return;
}
+ if (mono_thread_is_critical (thread)) {
+ THREAD_DEBUG (g_message (%s: ignoring critical thread %G_GSIZE_FORMAT, __func__, (gsize)thread-tid));
+ return;
+ }
+
handle = OpenThread (THREAD_ALL_ACCESS, TRUE, thread-tid);
if (handle == NULL) {
THREAD_DEBUG (g_message (%s: ignoring unopenable thread %G_GSIZE_FORMAT, __func__, (gsize)thread-tid));
@@ -2571,7 +2581,7 @@
return FALSE;
/* The finalizer thread is not a background thread */
- if (thread-tid != self (thread-state ThreadState_Background) != 0) {
+ if (thread-tid != self (thread-state ThreadState_Background) != 0 !mono_thread_is_critical (thread)) {
handle = OpenThread (THREAD_ALL_ACCESS, TRUE, thread-tid);
if (handle == NULL)
@@ -2768,6 +2778,9 @@
(thread-state ThreadState_Stopped) != 0)
return;
+ if (mono_thread_is_critical (thread))
+ return;
+
if (wait-numMAXIMUM_WAIT_OBJECTS) {
handle = OpenThread (THREAD_ALL_ACCESS, TRUE, thread-tid);
if (handle == NULL)
@@ -3777,3 +3790,64 @@
return ret;
[Mono-dev] Debugger plans
Hi, I'd like to ask you guys the plans for the Mono Debugger in the short/mid term. Are you planning to support debugger on MacOS? How hard would be to port it to other x86 OSs like Solaris? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Qt anyone?
Hi Arno, I think Qyoto is a really great initiative and a really strong point to make Mono shine. But I wonder if you have plans (and resources) to: - Relaunch a website with information/tutorials/downloads. It doesn't matter how good Qyoto is if no one can easily find it. - Publish builds on the different OSs. IMHO what makes Qyoto rock is being able to create native GUIs for Solaris/Linux/Windows/Mac with a single codebase and minor tweaks. If we only have Linux, then sticking to WinForms or GTK# is still better, if only Mac I guess monoobjc is the right solution, and so on. I think monoobjc is the perfect example: they've a solid website, full of samples, which gives a very good feeling when you enter it. You immediately think hey, this is a solid solution. Regards, pablo Arno Rehn escribió: On Linux it's pretty straight forward. Download a recent kde-bindings tarball and extract it somewhere. Build it as every other KDE module with cmake. Create a build directory, do cd build-dir; ccmake src-dir. Disable the stuff you don't want/don't need, like Soprano or Nepomuk bindings. Then just make; make install as usual. We haven't tried building on Solaris yet. On OS X someone got it working, but there seem to be issues with header files not being correctly found. You might have to play a bit to get it working there. On Friday 06 February 2009 20:36:29 pablosantosl...@terra.es wrote: are there tutorials to build on Mac/Linux/Solaris? Daniel Morgan escribió: Qyoto / Kimono Project http://ekarchive.elikirk.com/david/qyoto/ Here is a different project with a similar goal of creating CLR bindings for qt - qt4dotnet http://code.google.com/p/qt4dotnet/ If you google, you might be able to find ancient C# bindings to qt called qt# - but it has been abandoned. On a different subject, I wonder if someone would dare replace the glib and other dependencies in mono with qt. Then create clr bindings to qt. With these bindings, you could re-write mono using the clr bindings to qt. Now, that would be interesting. Please note, I am not saying anything is wrong with glib and its dependencies, I just think it would be neat to re-write mono using qt instead of glib. This way, you could write mono in C++ and have its internals OOP. Changing subject again, I think its good that there are many GUIs you can choose to use on top of mono: qyoto/kimono, asp.net, gtk#, swf, etc... --- On Fri, 2/6/09, pablosantosl...@terra.es pablosantosl...@terra.es wrote: From: pablosantosl...@terra.es pablosantosl...@terra.es Subject: Re: [Mono-dev] Qt anyone? To: SE1 ikr...@gmail.com Cc: mono-devel-list@lists.ximian.com Date: Friday, February 6, 2009, 6:51 AM Ok, great. The problem is exactly what you mentioned: with no website and no info... there's no way developers can get interested on it. SE1 escribió: pablosantosl...@terra.es wrote: Hi there, After reading: http://tech.slashdot.org/article.pl?sid=09/02/05/2138228, and after the announce of the LGPL Qt release, I think it's quite clear there's a lot to gain from a *solid* Qt binding for Mono. I mean, the Qyoto doesn't look like an alive project anymore (not at least a couple of weeks ago) and if I remember correctly it is restricted to Linux (true cross-platform is needed). And... apps! I'd be eager to port plastic GUI to Qt/C#, and maybe we could start from the Qyoto stuff, but not sure about the status. pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Someone brought the same questions up recently. If you read the thread at http://www.nabble.com/Qyoto-project-dead---ts21427284.html you'll see that although the Qyoto website is down, the project is still very much alive. It also works cross-platform, just lacks the building support at the moment. Ilmar ___ 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] Mono and IBM
mono-devel-list-boun...@lists.ximian.com wrote on 01/31/2009 07:43:09 AM: What do you guys think about performance penalization installing the Linux OS in a specially formatted partition inside the AS? What sort of performance penalty are you worried about? One on the overall system on one on the specific partition? I believe you can divvy up partitions using just fractions of CPUs now. -- Bill Seurer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono: Link error on shm_unlink and shm_open
Hi, I'm cross compiling mono 2.2 for the ARM. I'm getting linker errors: ../utils/.libs/libmonoutils.a(mono-mmap.o): In function `mono_shared_area_remove':/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:486: undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): In function `mono_shared_area_for_pid':/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:502: undefined reference to `shm_open'../utils/.libs/libmonoutils.a(mono-mmap.o): In function `mono_shared_area_instances_helper':/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:425: undefined reference to `shm_unlink'../utils/.libs/libmonoutils.a(mono-mmap.o): In function `mono_shared_area':/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:448: undefined reference to `shm_open'/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:460: undefined reference to `shm_unlink'/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:465: undefined reference to `shm_unlink'/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:451: undefined reference to `shm_unlink'/home/ubuntu/Install/cross-arm-mono-2.2/mono/utils/mono-mmap.c:452: undefined reference to `shm_open'collect2: ld returned 1 exit statusmake[3]: *** [pedump] Error 1make[3]: Leaving directory `/home/ubuntu/Install/cross-arm-mono-2.2/mono/metadata' It seems that it expects to find those functions are in librt.so. However, in my case, they are not implemented. Question === If I don't have these functions, what can I do to make mono compile. Thanks. _ The new Windows Live Messenger. You don’t want to miss this. http://www.microsoft.com/windows/windowslive/products/messenger.aspx___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Marshaling bools native-managed
Hi,
The attached patch fixes some problems we are seeing with marshaling
bools and IDspatch types in Native code.
I can split the patch separating the bool changes form the dispatch
changes if needed. I would like to apply this to the 2.4 branch as
well.
-bill
2009-02-12 Bill Holmes billholme...@gmail.com
* object-internals.h : Fixing a typo in the
MonoReflectionComVisibleAttribute struct.
* marshal.c (cominterop_com_visible): Check the implemented
interfaces for ComImport.
* marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls
assume that bools should be treated as VARIANTBOOLs.
* marshal.c (emit_marshal_boolean): Adding cases for
MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT.
* marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to
emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools.
* marshal.c (cominterop_get_ccw): For COM calls assume that bools
should be treated as VARIANTBOOLs.
Code is contributed under MIT/X11 license.
Index: mono/metadata/ChangeLog
===
--- mono/metadata/ChangeLog (revision 126646)
+++ mono/metadata/ChangeLog (working copy)
@@ -1,3 +1,25 @@
+2009-02-12 Bill Holmes billholme...@gmail.com
+
+ * object-internals.h : Fixing a typo in the
+ MonoReflectionComVisibleAttribute struct.
+
+ * marshal.c (cominterop_com_visible): Check the implemented
+ interfaces for ComImport.
+
+ * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls
+ assume that bools should be treated as VARIANTBOOLs.
+
+ * marshal.c (emit_marshal_boolean): Adding cases for
+ MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT.
+
+ * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to
+ emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools.
+
+ * marshal.c (cominterop_get_ccw): For COM calls assume that bools
+ should be treated as VARIANTBOOLs.
+
+ Code is contributed under MIT/X11 license.
+
2009-02-11 Mark Probst mark.pro...@gmail.com
* class.c, class-internals.h: mono_method_get_context_general()
Index: mono/metadata/marshal.c
===
--- mono/metadata/marshal.c (revision 126646)
+++ mono/metadata/marshal.c (working copy)
@@ -495,24 +495,39 @@
{
static MonoClass *ComVisibleAttribute = NULL;
MonoCustomAttrInfo *cinfo;
+ GPtrArray *ifaces;
+ MonoBoolean visible = 0;
/* Handle the ComVisibleAttribute */
if (!ComVisibleAttribute)
ComVisibleAttribute = mono_class_from_name (mono_defaults.corlib, System.Runtime.InteropServices, ComVisibleAttribute);
- cinfo = mono_custom_attrs_from_class (klass);
+ cinfo = mono_custom_attrs_from_class (klass);
if (cinfo) {
MonoReflectionComVisibleAttribute *attr = (MonoReflectionComVisibleAttribute*)mono_custom_attrs_get_attr (cinfo, ComVisibleAttribute);
- if (!attr)
- return FALSE;
+ if (attr)
+ visible = attr-visible;
if (!cinfo-cached)
mono_custom_attrs_free (cinfo);
-
- if (attr-visible)
+ if (visible)
return TRUE;
}
- return FALSE;
+
+ ifaces = mono_class_get_implemented_interfaces (klass);
+ if (ifaces) {
+ int i;
+ for (i = 0; i ifaces-len; ++i) {
+ MonoClass *ic = NULL;
+ ic = g_ptr_array_index (ifaces, i);
+ if (MONO_CLASS_IS_IMPORT (ic))
+visible = TRUE;
+
+ }
+ g_ptr_array_free (ifaces, TRUE);
+ }
+ return visible;
+
}
static void cominterop_raise_hr_exception (int hr)
@@ -3296,6 +3311,10 @@
mspecs[mspec_index] = g_new0 (MonoMarshalSpec, 1);
mspecs[mspec_index]-native = MONO_NATIVE_INTERFACE;
}
+ else if (sig_native-params[i]-type == MONO_NATIVE_BOOLEAN) {
+mspecs[mspec_index] = g_new0 (MonoMarshalSpec, 1);
+mspecs[mspec_index]-native = MONO_NATIVE_VARIANTBOOL;
+ }
}
}
@@ -3315,6 +3334,10 @@
mspecs[0] = g_new0 (MonoMarshalSpec, 1);
mspecs[0]-native = MONO_NATIVE_INTERFACE;
}
+ else if (sig-ret-type == MONO_NATIVE_BOOLEAN) {
+mspecs[0] = g_new0 (MonoMarshalSpec, 1);
+mspecs[0]-native = MONO_NATIVE_VARIANTBOOL;
+ }
}
}
@@ -8489,6 +8512,68 @@
mono_mb_emit_stloc (mb, 3);
break;
+ case MARSHAL_ACTION_MANAGED_CONV_IN: {
+ gint variant_bool = 0;
+ guint8 ldop = CEE_LDIND_I4;
+ if (!t-byref)
+ break;
+
+ conv_arg = mono_mb_add_local (mb, mono_defaults.boolean_class-byval_arg);
+
+ *conv_arg_type = mono_defaults.int32_class-byval_arg;
+
+ if (spec) {
+ switch (spec-native) {
+ case MONO_NATIVE_I1:
+ case MONO_NATIVE_U1:
+*conv_arg_type = mono_defaults.byte_class-this_arg;
+ldop = CEE_LDIND_I1;
+break;
+ case MONO_NATIVE_VARIANTBOOL:
+*conv_arg_type = mono_defaults.int16_class-this_arg;
+variant_bool = 1;
+ldop = CEE_LDIND_I2;
+break;
+ default:
+g_warning (marshalling bool as native type %x is currently not supported,
Re: [Mono-dev] [PATCH] Marshaling bools native-managed
Hi, This looks ok, I'm just concerned that the new code will be run even in non-com situations, and it might cause problems, like it uses CEE_LDIND_I4 to load a bool value. Zoltan 2009/2/12 Bill Holmes billholme...@gmail.com: Hi, The attached patch fixes some problems we are seeing with marshaling bools and IDspatch types in Native code. I can split the patch separating the bool changes form the dispatch changes if needed. I would like to apply this to the 2.4 branch as well. -bill 2009-02-12 Bill Holmes billholme...@gmail.com * object-internals.h : Fixing a typo in the MonoReflectionComVisibleAttribute struct. * marshal.c (cominterop_com_visible): Check the implemented interfaces for ComImport. * marshal.c (cominterop_get_native_wrapper_adjusted): For COM calls assume that bools should be treated as VARIANTBOOLs. * marshal.c (emit_marshal_boolean): Adding cases for MARSHAL_ACTION_MANAGED_CONV_IN and MARSHAL_ACTION_MANAGED_CONV_OUT. * marshal.c (mono_marshal_emit_managed_wrapper): Adding calls to emit_marshal MARSHAL_ACTION_MANAGED_CONV_IN and OUT for bools. * marshal.c (cominterop_get_ccw): For COM calls assume that bools should be treated as VARIANTBOOLs. Code is contributed under MIT/X11 license. ___ 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] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
IBM.Data.DB2.DB2Exception: Unable to allocate statement handle by Bartolomeo Nicolotti :: Rate this Message: Reply | Reply to Author | View Threaded | Show Only this Message Hello, I've installed mono, and xsp (not yet mod_mono) on ubuntu following the instruction here: http://ubuntuforums.org/showthread.php?t=803743 in view of using mod_mono together with php on ubuntu server 8.04, to migrate a web service that access a db2/as400 database. I've also installed db2exc from ubuntu repository as said here: http://www.ubuntu.com/partners/ibm/db2 I can compile a test program that does a query to the db: http://www.nabble.com/file/p21953488/helloDB2.cs helloDB2.cs s...@lxpc54:~/src/test$ gmcs -r:/usr/lib/mono/1.0/IBM.Data.DB2.dll -r:/usr/lib/mono/2.0/System.Data.dll helloDB2.cs but when I execute it: s...@lxpc54:~/src/test$ sudo MONO_LOG_LEVEL=debug mono helloDB2.exe bart Mono-INFO: Assembly Ref addref System.Data 0x8362e10 - System.Xml 0x83719d8: 2 Hello, bart Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLAllocHandle'. Mono-INFO: Probing 'SQLAllocHandle'. Mono-INFO: Found as 'SQLAllocHandle'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLAllocHandle'. Mono-INFO: Probing 'SQLAllocHandle'. Mono-INFO: Found as 'SQLAllocHandle'. Bart not useLibCli Bart not useLibCli Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLDriverConnectW'. Mono-INFO: Probing 'SQLDriverConnectWW'. Mono-INFO: Probing 'SQLDriverConnectWW'. Mono-INFO: Probing 'SQLDriverConnectW'. Mono-INFO: Found as 'SQLDriverConnectW'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLDriverConnectW'. Mono-INFO: Probing 'SQLDriverConnectWW'. Mono-INFO: Probing 'SQLDriverConnectWW'. Mono-INFO: Probing 'SQLDriverConnectW'. Mono-INFO: Found as 'SQLDriverConnectW'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLGetInfoW'. Mono-INFO: Probing 'SQLGetInfoWW'. Mono-INFO: Probing 'SQLGetInfoWW'. Mono-INFO: Probing 'SQLGetInfoW'. Mono-INFO: Found as 'SQLGetInfoW'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLGetInfoW'. Mono-INFO: Probing 'SQLGetInfoWW'. Mono-INFO: Probing 'SQLGetInfoWW'. Mono-INFO: Probing 'SQLGetInfoW'. Mono-INFO: Found as 'SQLGetInfoW'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLGetDiagRec'. Mono-INFO: Probing 'SQLGetDiagRec'. Mono-INFO: Found as 'SQLGetDiagRec'. Mono-INFO: DllImport attempting to load: 'libdb2'. Mono-INFO: DllImport loading location: 'libdb2.so'. Mono-INFO: Searching for 'SQLGetDiagRec'. Mono-INFO: Probing 'SQLGetDiagRec'. Mono-INFO: Found as 'SQLGetDiagRec'. Bart not useLibCli Unhandled Exception: IBM.Data.DB2.DB2Exception: ERROR [08003] [IBM][CLI Driver] CLI0106E Connection is closed. SQLSTATE=08003 InternalExecuteNonQuery: Unable to allocate statement handle. at IBM.Data.DB2.DB2Command.AllocateStatement (System.String location) [0x0] at IBM.Data.DB2.DB2Command.ExecuteNonQueryInternal (CommandBehavior behavior) [0x0] at IBM.Data.DB2.DB2Command.ExecuteReader (CommandBehavior behavior) [0x0] at IBM.Data.DB2.DB2Command.ExecuteReader () [0x0] at (wrapper remoting-invoke-with-check) IBM.Data.DB2.DB2Command:ExecuteReader () at HelloWorldDb2.Main (System.String[] args) [0x0] -- View this message in context: http://www.nabble.com/IBM.Data.DB2.DB2Exception%3A-Unable-to-allocate-statement-handle-tp21953488p21953488.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
