[Mono-dev] On what platform|cpu-arch|mono-version does full AOT actually work?
I downloaded a openSUSE 11.0 image with Mono 2.2 and tried the following in a terminal window... sudo mono --aot=full /usr/lib/1.0/mscorlib.dll The end result is that an assert in the code triggers a halt. The specific assert message is: ** ERROR: (mini-x86.c:5314): mono_arch_get_patch_offset: code should not be reached. I have been working with enabling AOT on the Mac and I get the same message there... looks like it doesn't recognize certain opcodes and then the assert halts the program. Anyone know on what platform/cpu combination and Mono version the full AOT actually works? I have been trying to debug the code and see if I could figure out what was wrong but as I said..it just looks like certain opcodes that Mono generates don't sit well with the code generator. If it is not the code but rather that I am not invoking the tools correctly then please let me know as well... Thanks -- View this message in context: http://www.nabble.com/On-what-platform%7Ccpu-arch%7Cmono-version-does-full-AOT-actually-work--tp21988583p21988583.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
Re: [Mono-dev] Generic Variance
This patch syncs with SVN.
Index: mono/metadata/ChangeLog
===
--- mono/metadata/ChangeLog (revision 126792)
+++ mono/metadata/ChangeLog (working copy)
@@ -1,3 +1,17 @@
+2009-02-13 Scott Peterson
+
+ This adds runtime generic variance support for reference types.
+ This patch is contributed under the MIT/X11 license.
+
+ * class.c: Added mono_class_has_variant_generic_params which determins
+ if a generic class has a variant type parameter. Added
+ mono_class_is_variant_of which determins if the first class is a legal
+ variant of the second. Added mono_class_interface_offset_with_variance
+ to look for interfaces in a variance-aware fashion. Modified
+ mono_class_is_assignable_from to use the two new methods.
+
+ * class-internals.h: Added mono_class_interface_offset_with_variance.
+
2009-02-13 Zoltan Varga
* cominterop.c icall-def.h: Fix the DISABLE_COM build.
Index: mono/metadata/class-internals.h
===
--- mono/metadata/class-internals.h (revision 126792)
+++ mono/metadata/class-internals.h (working copy)
@@ -407,6 +407,7 @@
#define MONO_CLASS_IMPLEMENTS_INTERFACE(k,uiid) (((uiid) <= (k)->max_interface_id) && ((k)->interface_bitmap [(uiid) >> 3] & (1 << ((uiid)&7
int mono_class_interface_offset (MonoClass *klass, MonoClass *itf);
+int mono_class_interface_offset_with_variance (MonoClass *klass, MonoClass *itf) MONO_INTERNAL;
typedef gpointer MonoRuntimeGenericContext;
Index: mono/metadata/class.c
===
--- mono/metadata/class.c (revision 126792)
+++ mono/metadata/class.c (working copy)
@@ -67,6 +67,7 @@
static void setup_generic_array_ifaces (MonoClass *class, MonoClass *iface, MonoMethod **methods, int pos);
static MonoMethod* mono_class_get_virtual_methods (MonoClass* klass, gpointer *iter);
+static gboolean mono_class_has_variant_generic_params (MonoClass *klass);
void (*mono_debugger_class_init_func) (MonoClass *klass) = NULL;
void (*mono_debugger_class_loaded_methods_func) (MonoClass *klass) = NULL;
@@ -2128,6 +2129,36 @@
return (key->interface_id - element->interface_id);
}
+static gboolean
+mono_class_is_variant_of (MonoClass *klass, MonoClass *vklass) {
+ int i;
+ MonoClass *generic = klass->generic_class->container_class;
+ MonoClass *vgeneric = vklass->generic_class->container_class;
+ MonoGenericContainer *container = vgeneric->generic_container;
+
+ if (generic != vgeneric)
+ return FALSE;
+
+ for (i = 0; i < container->type_argc; i++) {
+ MonoClass *param_class = mono_class_from_mono_type (klass->generic_class->context.class_inst->type_argv [i]);
+ MonoClass *vparam_class = mono_class_from_mono_type (vklass->generic_class->context.class_inst->type_argv [i]);
+
+ // FIXME this is incorrect
+ if (param_class->valuetype || vparam_class->valuetype)
+ return FALSE;
+
+ if (container->type_params [i].flags & GENERIC_PARAMETER_ATTRIBUTE_VARIANCE_MASK) {
+ if ((container->type_params [i].flags & GENERIC_PARAMETER_ATTRIBUTE_CONTRAVARIANT) && !mono_class_is_assignable_from (param_class, vparam_class))
+return FALSE;
+ if ((container->type_params [i].flags & GENERIC_PARAMETER_ATTRIBUTE_COVARIANT) && !mono_class_is_assignable_from (vparam_class, param_class))
+return FALSE;
+ } else if (param_class != vparam_class)
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
int
mono_class_interface_offset (MonoClass *klass, MonoClass *itf) {
MonoClass **result = bsearch (
@@ -2143,6 +2174,21 @@
}
}
+int
+mono_class_interface_offset_with_variance (MonoClass *klass, MonoClass *itf) {
+ int i = mono_class_interface_offset (klass, itf);
+ if (i >= 0) {
+ return i;
+ } else if (mono_class_has_variant_generic_params (itf)) {
+ for (i = 0; i < klass->interface_offsets_count; i++) {
+ if (mono_class_is_variant_of (klass->interfaces_packed[i], itf)) {
+return klass->interface_offsets_packed [i];
+ }
+ }
+ }
+ return -1;
+}
+
static void
print_implemented_interfaces (MonoClass *klass) {
GPtrArray *ifaces = NULL;
@@ -5952,38 +5998,8 @@
if ((container_class2->interfaces_packed [i] == container_class1) || (container_class2->interfaces_packed [i]->generic_class && (container_class2->interfaces_packed [i]->generic_class->container_class == container_class1)))
match = TRUE;
-if (match) {
- MonoGenericContainer *container;
-
- container = klass->generic_class->container_class->generic_container;
-
- match = TRUE;
- for (i = 0; i < container->type_argc; ++i) {
- MonoClass *param1_class = mono_class_from_mono_type (klass->generic_class->context.class_inst->type_argv [i]);
- MonoClass *param2_class = mono_class_from_mono_type (oklass->generic_class->context.class_inst->type_argv [i]);
-
- if (param1_class->valuetype != param2_class->valuetype) {
- match = FALSE;
- break;
- }
- /*
- * The _VARIANT
Re: [Mono-dev] Developing using Mono/Gtk# Vs Mono.WinForms (Windows & Linux)
2009/2/12 Daniel Espinosa : > The GUI must works on Linux/Windows among other OSs and both libraries will > be free software. > > What could be better to use Gtk# or Winforms? The rule of thumb would use: if the majority of users are Windows, use WinForms. If Linux, use GTK#. Of course, this is assuming that you're equally skilled in both. -- http://www.opgenorth.net ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0
Ok, but I am not a committer. Can someone commit this for me? -- Jay From: Nagappan A Sent: Thursday, February 12, 2009 2:51 PM To: Jay R. Wren Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0 Hello Wren, I think +#if NET_2_0 +: System.Data.Common.DbException +#elif NET_1_1 +: SystemException +#elif NET_1_0 +: SystemException +#endif the above can be +#if NET_2_0 +: System.Data.Common.DbException +#else +: SystemException +#endif The patch is ok to commit. Thanks Nagappan 2009/2/12 Jay R. Wren System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0 This is required to build NHibernate using mono gmcs. This patch is built from Revision: 126355 -- Jay R. Wren ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Developing using Mono/Gtk# Vs Mono.WinForms (Windows & Linux)
2009/2/12 Daniel Espinosa > We are working on a project using Mono/C# for a GUI independent library, > but in parallel one library to use GUI objects (the presentation layer) > witch will use the first library as a data provider. > > The GUI must works on Linux/Windows among other OSs and both libraries will > be free software. > > What could be better to use Gtk# or Winforms? I'd personally prefer GTK#, though it can look out of place on windows. Similarly Winforms definitely looks out of place on linux. It's a tradeoff. The ideal option would be for you to create a UI using both toolkits so it looks native on both platforms, but this may not be an option due to limited resources etc. > How to allow other users to contribute to the project if they will work on > Windows and others (me) on Linux? > On windows, use VS/SharpDevelop. On linux use MonoDevelop. > > I know projects' format diferencies between MS Visual Studio, SharpDevelop > and MonoDevelop. How help this IEDs to work with the same project and code > base? All three IDEs support the Visual Studio project format, so just use that. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
The AddField method is called from cs-parser.cs class twice. But for
some reason, nothing gets printed on the console when I use
Console.WriteLine() in AddField.
Also, I am using VS 2008. How can I debug the code because when I try to
use the debug feature, I get the following on output window
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities.Sync\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Users\MICROSOFT\Desktop\mono-2.0.1\mono-2.0.1\mcs\mcs\mcs.vshost.exe',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_32\System.Data\2.0.0.0__b77a5c561934e089\System.Data.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
'mcs.vshost.exe' (Managed): Loaded
'C:\Windows\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll',
Skipped loading symbols. Module is optimized and the debugger option
'Just My Code' is enabled.
The thread 0xc0c has exited with code 0 (0x0).
The thread 0x13b4 has exited with code 0 (0x0).
'mcs.vshost.exe' (Managed): Loaded
'C:\Users\MICROSOFT\Desktop\mono-2.0.1\mono-2.0.1\mcs\mcs\mcs.exe',
Symbols loaded.
The thread 0x1680 has exited with code 0 (0x0).
The thread 0x1704 has exited with code 0 (0x0).
The thread 0x11b4 has exited with code 0 (0x0).
The program '[2952] mcs.vshost.exe: Managed' has exited with code 0 (0x0).
Any help appreciated
Thanks
Mudit Vaidya wrote:
> I could find the AddField method in class.cs. I just put a simple
> "hello" output statement in the AddField method but that was not
> printed on the console.
> Who calls the AddField method ?
>
>
>
> Marek Safar wrote:
>> Hi,
>>> I am using the following code to access the variables of class
>>> compiled by mcs but I get no output on the console.
>>>
>>>
>> It depends when you are accessing those fields, but they should be
>> available for most of compilation time.
>>
>> Look how it works in TypeContainer::AddField (FieldBase field)
>>
>>> ArrayList ad = new ArrayList();
>>>ad.Add(tc.Fields);
>>> String[] ia = (String[])ad.ToArray(typeof(String));
>>> Console.WriteLine(ia[0]);
>>> for (int k = 0; k < ia.Length; k++)
>>>Console.WriteLine("ia.count"+ia.Length+ia.GetValue(k));
>>>
>>> what is the reason for tc.Fields not having any values ?
>>>
>> This code does not make a sense. TypeContainer::Fields returns a
>> collection and you are adding this collection into another collection
>> and then expecting to get string values, isn't that strange?
>>
>> Marek
>>
>>> Marek Safar wrote:
>>>
Hi,
> I am trying to find out what variables were contained in the c#
> file parsed by mcs. I am looking in RootContext.cs where the whole
> structure is created but I am unable to access the variables of
> the class.
> Any help appreciated.
>
>
I don't know what information you need but type fields are stored
in TypeContainer::Fields
Marek
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>
>>
>>
>
__
[Mono-dev] Developing using Mono/Gtk# Vs Mono.WinForms (Windows & Linux)
We are working on a project using Mono/C# for a GUI independent library, but in parallel one library to use GUI objects (the presentation layer) witch will use the first library as a data provider. The GUI must works on Linux/Windows among other OSs and both libraries will be free software. What could be better to use Gtk# or Winforms? How to allow other users to contribute to the project if they will work on Windows and others (me) on Linux? I know projects' format diferencies between MS Visual Studio, SharpDevelop and MonoDevelop. How help this IEDs to work with the same project and code base? -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] cruisecontrol.net on mono.
Hey, I mentioned to Miguel that we're running cruisecontrol.net on mono on osx, to produce Unity3D generated builds of our game. Miguel insisted I write to mono-devel and tell a bit more about it. Unsure why, as I'd rather talk about how nice it is that I can run mono in Unity3D in a browser, and have it communicate with a server built on mono on the backend, how we can use visualstudio to write & debug c#, how we get to use continuations, and how the switch to mono has been such a breath of fresh air for us. But none of that :-), Cruisecontrol.net. This what often gets referred to as a Continous Integration server. Which is fancy talk for something that builds your project on every commit, and maybe or maybe not does something with the results. Usually people use it to check up on themselves and teammembers to make sure nobody broke any unit tests, makes sure the project still builds on all the platforms it is supposed to build on, etc. (you'd have a seperate CI server per platform for that scenario in most cases). Anyway, CruiseControl.net is written in c#. I just tried to run it on mono, and it ran out of the box. The parts we've tried work as advertised. I haven't used the webinterface part of the tool. We use CCNet.Tray to control it. It's a windows only system tray application that you can use to make it start a build, and that turns red if something is wrong with a build. We're happy with how it works. It's mono running cruisecontrol.net, which is running mono to run gmcs, which is compiling our c# code to CIL. then it runs mono to run nunit on our unit tests. it tells unity3d to make a build, and uses a custom rsync setup to distribute the results in an easy way for our teammembers to quickly get the results of the build. Ironically enough, if you google for stackTraceString, the #3 thing you find is somebody who was unable to run cc.net on mono because of the stackTraceString thing. . It got properly fixed upstream. :-) Bye, Lucas -- Lucas Meijer | GameDev & Unity3D Consulting -- Blog: http://lucasmeijer.com/blog -- twitter: lucasmeijer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hello, I added some comments to the bug, we can apply Robert's patch and encourage developers in the meantime to use the graceful fallback setup for now as it will be needed for anyone trying to run the software on any Mono versions pre-2.6 (as this fix wont make it into Mono until Mono 2.6) Miguel. > Hey Miguel, > > It seems to me that talking to upstream developers and get them to > > provide a more robust implementation from the get-go would be a much > > better outcome. Have them probe for .NET version, fall back to Mono > > and if none of those are available, gracefully degrade the functionality. > This should defenitely happen, and we're talking to the upstream > developers to deal with this situation in a better way. > > The main theme of my message is not how to get these 3 projects from > running on mono, but if we can make the N others > that we do not know about run on mono as well. > > I'm not advocating for _not_ implementing more proper behaviour upstream. > > I did not get the feeling (or maybe it is part of my lost email) that > > I have heard the "againsts" yet. > So far I think it can be summarized as: > > 1) It takes nonzero time, and there are a zillion more important things > to do. > 2) It could break projects that are mono-only and rely on the same hack. > 3) In the original comment on the bugzilla issue, it was noted that the > "field is shared with the runtime", and that > that would make a fix ugly. > > I actually think #1 is a good argument against, #2 is not very likely, > but not totally impossible either, and to what extent #3 is a problem, > I don't know. > > Bye, Lucas > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
For what it's worth, you could argue that devs who added hacks to target .NET or Mono are more likely to react and update their app to match a new Mono behavior... Which, on the other hand, means that'd make like harder for people who actually care about targeting Mono (but then, they're relying on unreliable hacks in the first place). StApostol wrote: > > #2 is more likely than you think. > -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21985364.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
Re: [Mono-dev] UnixGroupInfo patch
On Mon, 2009-02-09 at 17:16 +0100, Daniel Peñalba wrote > Attached is a patch file. Please confirm if this patch can be included > to the next Mono release. This patch has been applied to svn-trunk. Alas, it won't make it into Mono 2.4, but instead will land in Mono 2.6. Thanks, - Jon ___ 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
Thank you! I'll test it ASAP. On Thu, Feb 12, 2009 at 4:17 PM, Bill Seurer wrote: > Carlos Ruiz Diaz wrote on 02/12/2009 11:49:55 > AM: > > > Oh, that is great! > > > > > We had a > > > multi-CPU system with two partitions (Linux and iSeries) and was > running > > > Mono on both. > > > > Could you please talk more about that? > > We have here two AS400 running OS400 v5r4. Do you think it will work? > > > > Thanks in advance. > > I really don't know how the systems we used were configured as someone else > set them up. I think we were on v6r1 but I know we have v5r4 partitions > now so I don't see any fundamental problem. You can set up Linux however > you want on its partition(s). > > Here's a reference about it. > > > http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/index.jsp?topic=/rzahc/rzahcblade5osvirtualpartitionsoverview.htm&tocNode=toc:rzahg/i5os/7/0/ > > Yeek, I hope that is usable. > -- > Bill Seurer > > ___ > 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
Carlos Ruiz Diaz wrote on 02/12/2009 11:49:55 AM: > Oh, that is great! > > > We had a > > multi-CPU system with two partitions (Linux and iSeries) and was running > > Mono on both. > > Could you please talk more about that? > We have here two AS400 running OS400 v5r4. Do you think it will work? > > Thanks in advance. I really don't know how the systems we used were configured as someone else set them up. I think we were on v6r1 but I know we have v5r4 partitions now so I don't see any fundamental problem. You can set up Linux however you want on its partition(s). Here's a reference about it. http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/index.jsp?topic=/rzahc/rzahcblade5osvirtualpartitionsoverview.htm&tocNode=toc:rzahg/i5os/7/0/ Yeek, I hope that is usable. -- Bill Seurer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono: Link error on shm_unlink and shm_open
FirstName LastName wrote: > Anybody has any idea why this is happening? If someone can help me, it would > be appreciated. This is fixed in SVN. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0
Hello Wren, I think +#if NET_2_0 +: System.Data.Common.DbException +#elif NET_1_1 +: SystemException +#elif NET_1_0 +: SystemException +#endif the above can be +#if NET_2_0 +: System.Data.Common.DbException +#else +: SystemException +#endif The patch is ok to commit. Thanks Nagappan 2009/2/12 Jay R. Wren > System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and > OracleException derives from System.Data.Common.DbException in 2.0 > > This is required to build NHibernate using mono gmcs. > > This patch is built from Revision: 126355 > -- > Jay R. Wren > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org http://nagappanal.blogspot.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono: Link error on shm_unlink and shm_open
Anybody has any idea why this is happening? If someone can help me, it would be appreciated. From: mousse_...@hotmail.comto: mono-devel-l...@lists.ximian.comdate: Wed, 11 Feb 2009 22:55:06 +Subject: [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. _ So many new options, so little time. Windows Live Messenger. 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
Re: [Mono-dev] Mono: Link error on shm_unlink and shm_open
Anybody has any idea why this is happening? If someone can help me, it would be appreciated. From: mousse_...@hotmail.comto: mono-devel-l...@lists.ximian.comdate: Wed, 11 Feb 2009 22:55:06 +Subject: [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. _ Twice the fun—Share photos while you chat with Windows Live Messenger. 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
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
On Thu, Feb 12, 2009 at 7:40 PM, Lucas Meijer wrote: > > I'm not advocating for _not_ implementing more proper behaviour upstream. > > I did not get the feeling (or maybe it is part of my lost email) that > > I have heard the "againsts" yet. > So far I think it can be summarized as: > > 1) It takes nonzero time, and there are a zillion more important things > to do. > 2) It could break projects that are mono-only and rely on the same hack. > 3) In the original comment on the bugzilla issue, it was noted that the > "field is shared with the runtime", and that > that would make a fix ugly. > > I actually think #1 is a good argument against, #2 is not very likely, > but not totally impossible either, and to what extent #3 is a problem, > I don't know. > > Bye, Lucas > > #2 is more likely than you think. There are applications out there that employ such hacks with proper safeguards. Such a change would make 2-3 improperly coded applications work, but it would risk breaking n other applications that are correctly written to check for .Net and Mono! (though "correctly" is a bit stretched when talking about such hacks). Another issue is that such a change invites the wrong mentality: "My application relies on undocumented .Net internals and does not run on Mono. I blame Mono." This is just plain wrong. A fifth issue is that undocumented .Net behavior may change at any time. If Mono is patched, these applications will remain open to future breakage. If the applications are patched, no such danger exists. This bug should be taken to the developers of the original application. ___ 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
Oh, that is great! > We had a > multi-CPU system with two partitions (Linux and iSeries) and was running > Mono on both. Could you please talk more about that? We have here two AS400 running OS400 v5r4. Do you think it will work? Thanks in advance. On Thu, Feb 12, 2009 at 12:23 PM, Bill Seurer wrote: > Carlos Ruiz Diaz wrote on 02/12/2009 08:19:15 > AM: > > > > I was talking about running mono in a non-x86 platform. I'll have > > performance issues for sure but I don't know if it will be > > catastrophic or ignorable. > > > On Wed, Feb 11, 2009 at 6:24 PM, Bill Seurer wrote: > > 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 > > It was a couple of years ago but it ran well when we tried it. We had a > multi-CPU system with two partitions (Linux and iSeries) and was running > Mono on both. > > We didn't get to performance testing, though, so I can't say for sure. > -- > Bill Seurer > > ___ > 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] Arguing for reconsideration of WONTFIX status of 425512
Hey Miguel, > It seems to me that talking to upstream developers and get them to > provide a more robust implementation from the get-go would be a much > better outcome. Have them probe for .NET version, fall back to Mono > and if none of those are available, gracefully degrade the functionality. This should defenitely happen, and we're talking to the upstream developers to deal with this situation in a better way. The main theme of my message is not how to get these 3 projects from running on mono, but if we can make the N others that we do not know about run on mono as well. I'm not advocating for _not_ implementing more proper behaviour upstream. > I did not get the feeling (or maybe it is part of my lost email) that > I have heard the "againsts" yet. So far I think it can be summarized as: 1) It takes nonzero time, and there are a zillion more important things to do. 2) It could break projects that are mono-only and rely on the same hack. 3) In the original comment on the bugzilla issue, it was noted that the "field is shared with the runtime", and that that would make a fix ugly. I actually think #1 is a good argument against, #2 is not very likely, but not totally impossible either, and to what extent #3 is a problem, I don't know. Bye, Lucas -- -- Game Development Blog: http://lucasmeijer.com/blog ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hello, > It depends on what the mono team sees as the goal of mono. > If it is to provide a nice programming environment for linux > programmers > to make linux applications, then no reason to change. > If it also is to make it easy for .net applications to run on linux, > and > to have windows .net developers try mono, and adopt mono as one of > their > platforms, > then it would make sense to cahnge. It is a bit of both. We have made concessions in the past for this sort of thing, and I do not see why this would be any different. Now, this is a horrid hack that nobody should be using. And I am surprised about the kind of projects using this hack, as it seems that them of all people would have written some robust features into it to future proof the code against changes in the framework, into different editions of the framework (Mono, CF, XNA, Micro) and would not depend on this sort of hacks. I have not researched this problem in particular, and I do not know what negative impact it might have on Mono so I do not have a strong position against changing it, but I do not know enough about it to just OK the change. It seems to me that talking to upstream developers and get them to provide a more robust implementation from the get-go would be a much better outcome. Have them probe for .NET version, fall back to Mono and if none of those are available, gracefully degrade the functionality. > > They are all opensource, and I have submitted patches (except for > xunit, > upcomig). The reason I bring this up is not to make my life easier. > I can > make all these tools work for me and move on. I bring it up because I > feel mono is a really great project, and I would love to make it > work more > out of the box, even for programs that sometimes cross the line of > what > they "are allowed" to be doing. I agree, it is a worthy goal, and we are willing to make some changes, even something as gross as this. I just need more information myself. > Anyway, I think most arguments for and against have been made, and > from > this point the mono team should just do what it > feels is right. I did not get the feeling (or maybe it is part of my lost email) that I have heard the "againsts" yet. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
Hi, I don't know If I'm saying something with sense, but in the source tree of mono 2.2 there's a folder called mcs/Classes/IBM.Data.DB2, If you install db2 express c you get a folder with the file libcdb2.so: /opt/ibm/.../lib32/libcdb2.so and if you edit sudo vim /usr/local/etc/mono/config adding this line: ... ... the "links" sould be ok, and you sould have the same as in IBM.Data.DB2.dll, am I right? Daniel Morgan-3 wrote: > > IBM does not provide an IBM.Data.DB2.dll assembly for Linux. IBM only > provides IBM.Data.DB2.dll for Windows. This goes the same with other > proprietary database management systems out there, such as, Oracle and > Sybase. These companies only support Microsoft .net framework - they do > not even acknowledge Mono. > > Mono provides a homemade IBM.Data.DB2.dll assembly, but it is not > maintained. > > I cannot see what is available on Linux right now, but I can see what the > Mono Windows installer installs. Mono only installs IBM.Data.DB2.dll for > the 1.0 profile. The assembly is not built for the 2.0 profile. > > I suggest using System.Data.Odbc instead. Novell does maintain > System.Data.Odbc, and IBM does have an ODBC driver for DB2 on Linux. > > --- On Thu, 2/12/09, Carlos Ruiz Diaz wrote: > >> From: Carlos Ruiz Diaz >> Subject: Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate >> statement handle >> To: "Bartolomeo Nicolotti" >> Cc: mono-devel-list@lists.ximian.com >> Date: Thursday, February 12, 2009, 10:46 AM >> After failing trying to connect with the native driver I >> switched to >> unixODBC and it works fine for me. It is stable and I >> currently have a large >> program using ODBC as its connector. >> I use openSuse as my major OS. I installed the db2 express >> C but I was >> unable to find the required library to make IBM.DB2 dll to >> work. Bad for me. >> >> >> >> >> On Thu, Feb 12, 2009 at 4:20 AM, Bartolomeo Nicolotti >> wrote: >> >> > >> > I'd like to use the webservice "As is" >> so that we can switch easyly... >> > >> > if I won't be able to do it with IBM.Data.DB2 in a >> few days I'll consider >> > using other way to connect. >> > >> > Do you know if with these providers you can connecto >> to AS/400? >> > >> > Many thanks >> > >> > Best regards >> > >> > >> > >> > Bartolomeo Nicolotti wrote: >> > > >> > > Da: Daniel Morgan >> > > >> > > Have you considered using ODBC provider instead? >> > > >> > > System.Data.Odbc namespace is included in >> System.Data assembly. >> > > >> > > You can use iodbc or unixodbc on linux. >> There's commercial odbc >> > solutions >> > > for linux too. >> > > >> > > http://mono-project.com/ODBC >> > > >> > > http://www.unixodbc.com/doc/db2.html >> > > >> > > Novell maintains System.Data.Odbc; however, I do >> not think anyone is >> > > maintaining IBM.Data.DB2 in Mono. >> > > >> > > >> > > --- On Wed, 2/11/09, Bartolomeo Nicolotti >> wrote: >> > > >> > > >> > > >> > > Bartolomeo Nicolotti wrote: >> > >> >> > >> 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 l
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
I'm talking about bugs opened *against* the frameworks, not against Mono, because it's not a Mono bug. Andrés Stifu wrote: > Hm yeah, he gave the link to the bug report (in the message you quoted), and > it's obvious it's not been closed by mistake. And it's not about removing > workarounds or hacks from Mono, the hacks would be in the programs working > around the difference between .NET and Mono. :| > > > knocte wrote: >> >> Have you opened bugs on their bug tracking systems? If yes, this >> discussion should be placed there. If not, you should open them, and >> provide patches (maybe they didn't do it on purpose, and would be very >> grateful of someone trying to remove workarounds/hacks from their code). >> >> Regards, >> >> Andrés >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
I could find the AddField method in class.cs. I just put a simple
"hello" output statement in the AddField method but that was not printed
on the console.
Who calls the AddField method ?
Marek Safar wrote:
> Hi,
>> I am using the following code to access the variables of class
>> compiled by mcs but I get no output on the console.
>>
>>
> It depends when you are accessing those fields, but they should be
> available for most of compilation time.
>
> Look how it works in TypeContainer::AddField (FieldBase field)
>
>> ArrayList ad = new ArrayList();
>>ad.Add(tc.Fields);
>> String[] ia = (String[])ad.ToArray(typeof(String));
>> Console.WriteLine(ia[0]);
>> for (int k = 0; k < ia.Length; k++)
>>Console.WriteLine("ia.count"+ia.Length+ia.GetValue(k));
>>
>> what is the reason for tc.Fields not having any values ?
>>
> This code does not make a sense. TypeContainer::Fields returns a
> collection and you are adding this collection into another collection
> and then expecting to get string values, isn't that strange?
>
> Marek
>
>> Marek Safar wrote:
>>
>>> Hi,
>>>
I am trying to find out what variables were contained in the c#
file parsed by mcs. I am looking in RootContext.cs where the whole
structure is created but I am unable to access the variables of the
class.
Any help appreciated.
>>> I don't know what information you need but type fields are stored in
>>> TypeContainer::Fields
>>>
>>> Marek
>>>
>>>
>> ___
>> 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] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
IBM does not provide an IBM.Data.DB2.dll assembly for Linux. IBM only provides IBM.Data.DB2.dll for Windows. This goes the same with other proprietary database management systems out there, such as, Oracle and Sybase. These companies only support Microsoft .net framework - they do not even acknowledge Mono. Mono provides a homemade IBM.Data.DB2.dll assembly, but it is not maintained. I cannot see what is available on Linux right now, but I can see what the Mono Windows installer installs. Mono only installs IBM.Data.DB2.dll for the 1.0 profile. The assembly is not built for the 2.0 profile. I suggest using System.Data.Odbc instead. Novell does maintain System.Data.Odbc, and IBM does have an ODBC driver for DB2 on Linux. --- On Thu, 2/12/09, Carlos Ruiz Diaz wrote: > From: Carlos Ruiz Diaz > Subject: Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate > statement handle > To: "Bartolomeo Nicolotti" > Cc: mono-devel-list@lists.ximian.com > Date: Thursday, February 12, 2009, 10:46 AM > After failing trying to connect with the native driver I > switched to > unixODBC and it works fine for me. It is stable and I > currently have a large > program using ODBC as its connector. > I use openSuse as my major OS. I installed the db2 express > C but I was > unable to find the required library to make IBM.DB2 dll to > work. Bad for me. > > > > > On Thu, Feb 12, 2009 at 4:20 AM, Bartolomeo Nicolotti > wrote: > > > > > I'd like to use the webservice "As is" > so that we can switch easyly... > > > > if I won't be able to do it with IBM.Data.DB2 in a > few days I'll consider > > using other way to connect. > > > > Do you know if with these providers you can connecto > to AS/400? > > > > Many thanks > > > > Best regards > > > > > > > > Bartolomeo Nicolotti wrote: > > > > > > Da: Daniel Morgan > > > > > > Have you considered using ODBC provider instead? > > > > > > System.Data.Odbc namespace is included in > System.Data assembly. > > > > > > You can use iodbc or unixodbc on linux. > There's commercial odbc > > solutions > > > for linux too. > > > > > > http://mono-project.com/ODBC > > > > > > http://www.unixodbc.com/doc/db2.html > > > > > > Novell maintains System.Data.Odbc; however, I do > not think anyone is > > > maintaining IBM.Data.DB2 in Mono. > > > > > > > > > --- On Wed, 2/11/09, Bartolomeo Nicolotti > wrote: > > > > > > > > > > > > Bartolomeo Nicolotti wrote: > > >> > > >> 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'. > > >> Mon
Re: [Mono-dev] Qt anyone?
On Wednesday 11 February 2009 23:12:52 you wrote: > 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. We will definitely put up stuff on techbase.kde.org, but I don't know if we'll relaunch a full blown website. Maybe something on sourceforge, we'll see. > - 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. Yes, we'll do that once we have time to build it on windows and os x. > 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 > > > > wrote: > From: pablosantosl...@terra.es > Subject: Re: [Mono-dev] Qt anyone? > To: "SE1" > 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@l
Re: [Mono-dev] [PATCH] Marshaling bools native->managed
Hi, Looks good. Zoltan On Thu, Feb 12, 2009 at 5:13 PM, Bill Holmes wrote: > Hi, > > After discussing this patch with Zoltan last night on IRC we decided > to make two variations of this patch. One for the trunk and one for > the 2.4 branch. The reasoning being that we should not change the > default behavior of marshaling bools from native to managed this close > to the branch release. For the trunk patch we will now marshal bools > as 32-bit integers by default and for the branch we will continue to > marshal bools as bytes as it has been done in the past. In both > patches if a MarshalAs attribute is specified it will now be > processed. > > This patch does affect all calls from native to managed that include > bool arguments and is not exclusive to COM. > > -bill > > trunk: > 2009-02-13 Bill Holmes > > * 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. > > branch: > 2009-02-13 Bill Holmes > > Backport of r(fill in later). This is a safer variant of the > trunk for the 2.4 branch. The default in emit_marshal_boolean > for this version is I1. > > * 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. > > On Wed, Feb 11, 2009 at 7:29 PM, Zoltan Varga wrote: >> 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 : >>> 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 >>> >>> * 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
Re: [Mono-dev] Mono and IBM
Carlos Ruiz Diaz wrote on 02/12/2009 08:19:15 AM: > > I was talking about running mono in a non-x86 platform. I'll have > performance issues for sure but I don't know if it will be > catastrophic or ignorable. > On Wed, Feb 11, 2009 at 6:24 PM, Bill Seurer wrote: > 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 It was a couple of years ago but it ran well when we tried it. We had a multi-CPU system with two partitions (Linux and iSeries) and was running Mono on both. We didn't get to performance testing, though, so I can't say for sure. -- Bill Seurer ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Marshaling bools native->managed
Hi, After discussing this patch with Zoltan last night on IRC we decided to make two variations of this patch. One for the trunk and one for the 2.4 branch. The reasoning being that we should not change the default behavior of marshaling bools from native to managed this close to the branch release. For the trunk patch we will now marshal bools as 32-bit integers by default and for the branch we will continue to marshal bools as bytes as it has been done in the past. In both patches if a MarshalAs attribute is specified it will now be processed. This patch does affect all calls from native to managed that include bool arguments and is not exclusive to COM. -bill trunk: 2009-02-13 Bill Holmes * 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. branch: 2009-02-13 Bill Holmes Backport of r(fill in later). This is a safer variant of the trunk for the 2.4 branch. The default in emit_marshal_boolean for this version is I1. * 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. On Wed, Feb 11, 2009 at 7:29 PM, Zoltan Varga wrote: > 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 : >> 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 >> >>* 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 >> >> > Index: mono/metadata/ChangeLog === --- mono/metadata/ChangeLog (revision 126719) +++ mono/metadata/ChangeLog (working copy) @@ -1,3 +1,25 @@ +2009-02-13 Bill Holmes + + * 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_MANAGE
Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
Hi, I think I've the same problem: 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 s...@lxpc54:~/src/test$ mono helloDB2.exe You must tell me your name! s...@lxpc54:~/src/test$ mono helloDB2.exe bart Hello, bart Unhandled Exception: System.DllNotFoundException: db2_36 at (wrapper managed-to-native) IBM.Data.DB2.DB2CLIWrapper/StaticWrapper36:SQLAllocHandle (int16,intptr,intptr&) at IBM.Data.DB2.DB2CLIWrapper.SQLAllocHandle (Int16 handleType, IntPtr inputHandle, System.IntPtr& outputHandle) [0x0] at IBM.Data.DB2.DB2CLIWrapper.Initialize (System.IntPtr& pEnvHandle) [0x0] at IBM.Data.DB2.DB2Environment..ctor () [0x0] at IBM.Data.DB2.DB2Environment.get_Instance () [0x0] at IBM.Data.DB2.DB2ConnectionPool.FindConnectionPool (System.String connectionString) [0x0] at IBM.Data.DB2.DB2ConnectionSettings.GetConnectionSettings (System.String connectionString) [0x0] at IBM.Data.DB2.DB2Connection.SetConnectionString (System.String connectionString) [0x0] at IBM.Data.DB2.DB2Connection..ctor (System.String conString) [0x0] at (wrapper remoting-invoke-with-check) IBM.Data.DB2.DB2Connection:.ctor (string) at HelloWorldDb2.Main (System.String[] args) [0x0] Then I've tried to edit /etc/mono/config: sudo vim /etc/mono/config adding this line (not target="libdb2.so", because the mono loader adds the .so extension itself): and it Loaded the right library, as you can see from below, but then I realized that the ADO.net namespace we use is: IBM.Data.DB2.iSeries so we have to use unixODBC, because this namespace is not implemented in Mono, is it? For the connection and the data could you please tell me which namespace are you using in you application? Many thanks Best regards castord wrote: > > After failing trying to connect with the native driver I switched to > unixODBC and it works fine for me. It is stable and I currently have a > large > program using ODBC as its connector. > I use openSuse as my major OS. I installed the db2 express C but I was > unable to find the required library to make IBM.DB2 dll to work. Bad for > me. > > > > > On Thu, Feb 12, 2009 at 4:20 AM, Bartolomeo Nicolotti > wrote: > >> >> I'd like to use the webservice "As is" so that we can switch easyly... >> >> if I won't be able to do it with IBM.Data.DB2 in a few days I'll consider >> using other way to connect. >> >> Do you know if with these providers you can connecto to AS/400? >> >> Many thanks >> >> Best regards >> >> >> >> Bartolomeo Nicolotti wrote: >> > >> > Da: Daniel Morgan >> > >> > Have you considered using ODBC provider instead? >> > >> > System.Data.Odbc namespace is included in System.Data assembly. >> > >> > You can use iodbc or unixodbc on linux. There's commercial odbc >> solutions >> > for linux too. >> > >> > http://mono-project.com/ODBC >> > >> > http://www.unixodbc.com/doc/db2.html >> > >> > Novell maintains System.Data.Odbc; however, I do not think anyone is >> > maintaining IBM.Data.DB2 in Mono. >> > >> > >> > --- On Wed, 2/11/09, Bartolomeo Nicolotti wrote: >> > >> > >> > >> > Bartolomeo Nicolotti wrote: >> >> >> >> 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-IN
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hm yeah, he gave the link to the bug report (in the message you quoted), and it's obvious it's not been closed by mistake. And it's not about removing workarounds or hacks from Mono, the hacks would be in the programs working around the difference between .NET and Mono. :| knocte wrote: > > > Have you opened bugs on their bug tracking systems? If yes, this > discussion should be placed there. If not, you should open them, and > provide patches (maybe they didn't do it on purpose, and would be very > grateful of someone trying to remove workarounds/hacks from their code). > > Regards, > > Andrés > -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21978879.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
Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
After failing trying to connect with the native driver I switched to unixODBC and it works fine for me. It is stable and I currently have a large program using ODBC as its connector. I use openSuse as my major OS. I installed the db2 express C but I was unable to find the required library to make IBM.DB2 dll to work. Bad for me. On Thu, Feb 12, 2009 at 4:20 AM, Bartolomeo Nicolotti wrote: > > I'd like to use the webservice "As is" so that we can switch easyly... > > if I won't be able to do it with IBM.Data.DB2 in a few days I'll consider > using other way to connect. > > Do you know if with these providers you can connecto to AS/400? > > Many thanks > > Best regards > > > > Bartolomeo Nicolotti wrote: > > > > Da: Daniel Morgan > > > > Have you considered using ODBC provider instead? > > > > System.Data.Odbc namespace is included in System.Data assembly. > > > > You can use iodbc or unixodbc on linux. There's commercial odbc > solutions > > for linux too. > > > > http://mono-project.com/ODBC > > > > http://www.unixodbc.com/doc/db2.html > > > > Novell maintains System.Data.Odbc; however, I do not think anyone is > > maintaining IBM.Data.DB2 in Mono. > > > > > > --- On Wed, 2/11/09, Bartolomeo Nicolotti wrote: > > > > > > > > Bartolomeo Nicolotti wrote: > >> > >> 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 > >> InternalExecu
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Have you opened bugs on their bug tracking systems? If yes, this
discussion should be placed there. If not, you should open them, and
provide patches (maybe they didn't do it on purpose, and would be very
grateful of someone trying to remove workarounds/hacks from their code).
Regards,
Andrés
Lucas Meijer wrote:
> Hey,
>
> Our team has been busy porting some unit testing related frameworks to mono.
> porting is probably not the right word, it's mostly creating repro cases
> of mono bugs,
> reporting them, and waiting for them to be fixed. (Which happens fast by
> the way. Thanks!)
>
> So far we're looking at NInject, Moq and xUnit.
>
> There are / have been bugs in mono that prevent all of these projects
> from running.
> Most of them are valid mono bugs, nothing special here.
>
> In addition to real mono bugs, there's also the fact that many of these
> frameworks, use this
> commonly used "trick":
>
> FieldInfo remoteStackTraceString =
> typeof(Exception).GetField("_remoteStackTraceString",
> BindingFlags.Instance | BindingFlags.NonPublic);
>
> This doesn't work on mono, since in mono the private field storing the
> stacktrace is called "remote_stack_trace".
>
> This issue has been reported before as issue 425512 (
> https://bugzilla.novell.com/show_bug.cgi?id=425512 )
>
> One could argue, and the reason for the wontfix status of the issue does
> so, that these folks rely on undocumented internals.
> They shouldn't do it, and Mono shouldn't rename it's own private field
> to match that of the CLR.
>
> However, in the real world(tm), this prevents many projects from
> running on Mono unmodified.
>
> I would like to argue that in this specific case, where the (percieved
> by me, maybe incorrectly) amount of work for mono to change it's private
> fieldname to
> match that of the CLR, is a reasonable cost for enabling this quite
> frequently found in the wild trick of grabbing the internal stack trace
> of an exception.
>
> Maybe I'm underestimating the amount of work to rename the mono
> fieldname to match the clr one. If that's the case, please consider this
> message
> as another datapoint of three useful .net frameworks unable to run on
> mono unmodified.
>
> Here's a bit more info on the trick:
>
> Here is a bit more background on the trick:
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
>
> Bye, Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
Hi,
> I am using the following code to access the variables of class compiled
> by mcs but I get no output on the console.
>
>
It depends when you are accessing those fields, but they should be
available for most of compilation time.
Look how it works in TypeContainer::AddField (FieldBase field)
> ArrayList ad = new ArrayList();
>
> ad.Add(tc.Fields);
> String[] ia = (String[])ad.ToArray(typeof(String));
> Console.WriteLine(ia[0]);
> for (int k = 0; k < ia.Length; k++)
>Console.WriteLine("ia.count"+ia.Length+ia.GetValue(k));
>
> what is the reason for tc.Fields not having any values ?
>
>
This code does not make a sense. TypeContainer::Fields returns a
collection and you are adding this collection into another collection
and then expecting to get string values, isn't that strange?
Marek
> Marek Safar wrote:
>
>> Hi,
>>
>>> I am trying to find out what variables were contained in the c# file
>>> parsed by mcs. I am looking in RootContext.cs where the whole
>>> structure is created but I am unable to access the variables of the
>>> class.
>>> Any help appreciated.
>>>
>>>
>>>
>> I don't know what information you need but type fields are stored in
>> TypeContainer::Fields
>>
>> Marek
>>
>>
> ___
> 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] Arguing for reconsideration of WONTFIX status of 425512
Hey. > Take the reverse situation, why would Mono devs care on supporting > application X because some users would like to run X on Mono ? It depends on what the mono team sees as the goal of mono. If it is to provide a nice programming environment for linux programmers to make linux applications, then no reason to change. If it also is to make it easy for .net applications to run on linux, and to have windows .net developers try mono, and adopt mono as one of their platforms, then it would make sense to cahnge. > Also, all of the applications cited are open-source AND free software > which allow you to patch them freely. They are all opensource, and I have submitted patches (except for xunit, upcomig). The reason I bring this up is not to make my life easier. I can make all these tools work for me and move on. I bring it up because I feel mono is a really great project, and I would love to make it work more out of the box, even for programs that sometimes cross the line of what they "are allowed" to be doing. You could also say that from the 3 projects I would like to use on mono, 100% of them didn't work because of this. That means there are probably a lot of other projects out there using this as well, that don't know about mono, and didn't receive a patch for me to provide mono compatibility. Anyway, I think most arguments for and against have been made, and from this point the mono team should just do what it feels is right. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] RootContext.cs
I am using the following code to access the variables of class compiled
by mcs but I get no output on the console.
ArrayList ad = new ArrayList();
ad.Add(tc.Fields);
String[] ia = (String[])ad.ToArray(typeof(String));
Console.WriteLine(ia[0]);
for (int k = 0; k < ia.Length; k++)
Console.WriteLine("ia.count"+ia.Length+ia.GetValue(k));
what is the reason for tc.Fields not having any values ?
Marek Safar wrote:
> Hi,
>> I am trying to find out what variables were contained in the c# file
>> parsed by mcs. I am looking in RootContext.cs where the whole
>> structure is created but I am unable to access the variables of the
>> class.
>> Any help appreciated.
>>
>>
> I don't know what information you need but type fields are stored in
> TypeContainer::Fields
>
> Marek
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
About taking developer time: point taken. No matter how small the change is,
if there are 50 such demands, things get different quickly. Unless, of
course, the patch is submitted by a 3rd party, in which case the it's only
reviewing time, which in most cases should be negligible.
And although forking is possible and a good point of FOSS, I have to
reiterate that I think it's a bad idea in such a case. Forking a certain
little app to fit your needs or to do new things is usually good, but if
it's a whole framework, it's really a different thing to me. Deployment just
wouldn't work. I can't see myself telling my users "Please install my 100 KB
app, but also my own 400 MB version of the framework"... Assuming the user
is okay with that, that'd be like opening the gates of hell (big download,
possible incompatibilities with other Mono apps, or installing Mono twice,
etc... I can't imagine that).
The only way it could possibly work, I think, is if it was a slimmed down
version of the framework (as is possible easily enough, from what I read),
or a static compilation of the classes I need or something like that... and
then again, updating your own framework as new Mono versions come out may be
an annoyance, and not something you want to do, especially for a tiny change
you wanted on Mono... and your users wouldn't be able to update the Mono
version themselves without breaking your app, and so on. Just not worth it,
no matter how I look at it. I'd rather just do if(IsMono()) { DoThat(); }
and go on with life.
Jérémie LAVAL wrote:
>
> Take the reverse situation, why would Mono devs care on supporting
> application X because some users would like to run X on Mono ?
>
> The only difference here is that, in your case, the developer has to take
> care of one platform with minimal change involved where Mono would get ton
> of request preventing them to focus on coding real things.
>
> Also, all of the applications cited are open-source AND free software
> which
> allow you to patch them freely. Then if the main developer is stubborn
> enough to refuse your patch, just make it available or fork the project,
> that's one of the advantage of FOSS.
>
> --
> Jérémie Laval
> jeremie.la...@gmail.com
> http://garuma.wordpress.com
>
>
> On Thu, Feb 12, 2009 at 3:23 PM, Stifu wrote:
>
>>
>> What about developers who don't care about Mono, but some of their users
>> being interested in running their app in Mono?
>> Sure, they could contact the devs to insist on supporting Mono, but then,
>> first, the app must still be under development, which is not obviously
>> the
>> case, and second, the devs must be willing to listen and act... It'd just
>> be
>> much easier and more convenient if it just worked right away, if there is
>> no
>> downside involved.
>>
>>
>> Jérémie LAVAL wrote:
>> >
>> > There is a difference between implementing a public API used by lot of
>> > people and implementing low-level internals that 1/ you aren't supposed
>> to
>> > know in the first place, 2/ are used by 2-3 projects that could fix the
>> > bug
>> > with a two lines change if they cared about Mono.
>> >
>> > --
>> > Jérémie Laval
>> > jeremie.la...@gmail.com
>> > http://garuma.wordpress.com
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977064.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
>>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
--
View this message in context:
http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977704.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
[Mono-dev] System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0
System.Data.DbType adds DateTime2 and DateTimeOffset in 3.5 and OracleException derives from System.Data.Common.DbException in 2.0 This is required to build NHibernate using mono gmcs. This patch is built from Revision: 126355 -- Jay R. Wren DbType3.5andOracleException2.0.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] signal.c cross-thread access
Hi Jon, Here's the changes you suggested. I'm now using poll() rather than select() as discussed on Tuesday. The test reproducing multiple select() on the same fd for the same operation that's working under poll is included in mcs.diff. This is contributed under MIT/X11 Cheers -Tim > -Original Message- > From: Jonathan Pryor [mailto:jonpr...@vt.edu] > Sent: 09 February 2009 14:08 > To: Tim Jenks > Subject: RE: [Mono-dev] signal.c cross-thread access > > On Mon, 2009-02-09 at 12:31 +, tim.je...@realtimeworlds.com wrote: > > Here we can see one select is returning after the first char is sent > to > > the pipe (and reads 1 byte). The second char is then sent to the > pipe, > > but the second select() call does not unblock. > > > > I am assuming this is undefined behaviour when multiple threads > select() > > on the same fd for the same operation, although I cannot find any > > documentation proving this. > > > > Having looked at epoll, this appears to be addressed. > > Is there any other mechanism? epoll(2) doesn't seem to be supported on > Mac OS X (at least, it's not listed at [0]). Would poll(2) work? > > - Jon > > [0] http://developer.apple.com/documentation/Darwin/Reference/ManPages/ > > > > > 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. mcs.diff Description: mcs.diff signal.c.diff Description: signal.c.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libgdiplus pango patch
Sebastien Pouliot wrote:
There are a couple of issues that I've fixed since the patch I submitted
as well (fixed a problem with vertical text and another difference with
how MS GDI+ handles the NoWrap flag). Should I do another patch with
everything again, or just a patch on the patched version for those?
You can issue a new, complete patch.
Here's the new patch. Fixes from the previous one:
* vertical latin text is now drawn with characters in the correct direction
* NoWrap will still wrap on newline now (MS GDI+ does this)
Jonathan Anderson
Index: src/text-pango-private.h
===
--- src/text-pango-private.h(revision 126715)
+++ src/text-pango-private.h(working copy)
@@ -36,17 +36,18 @@
#include "graphics-private.h"
#include "stringformat-private.h"
+#define PANGO_MAX (G_MAXINT / PANGO_SCALE)
+#define MAKE_SAFE_FOR_PANGO(x) ((x) > G_MAXINT/PANGO_SCALE ?
G_MAXINT/PANGO_SCALE : ((x) < G_MININT/PANGO_SCALE ? G_MININT/PANGO_SCALE :
(x)))
#defineGDIP_WINDOWS_ACCELERATOR'&'
-#define GDIP_PANGOHACK_ACCELERATOR ((char)1)
#define text_DrawStringpango_DrawString
#define text_MeasureString pango_MeasureString
#define text_MeasureCharacterRangespango_MeasureCharacterRanges
-PangoLayout* gdip_pango_setup_layout (cairo_t *ct, GDIPCONST WCHAR
*stringUnicode, int length, GDIPCONST GpFont *font,
- GDIPCONST RectF *rc, RectF *box, GDIPCONST GpStringFormat *format);
+PangoLayout* gdip_pango_setup_layout (GpGraphics *graphics, GDIPCONST WCHAR
*stringUnicode, int length, GDIPCONST GpFont *font,
+ GDIPCONST RectF *rc, RectF *box, GDIPCONST GpStringFormat *format, int
**charsRemoved);
GpStatus pango_DrawString (GpGraphics *graphics, GDIPCONST WCHAR
*stringUnicode, int length, GDIPCONST GpFont *font,
GDIPCONST RectF *rc, GDIPCONST GpStringFormat *format, GpBrush *brush)
GDIP_INTERNAL;
Index: src/text-pango.c
===
--- src/text-pango.c(revision 126715)
+++ src/text-pango.c(working copy)
@@ -46,45 +46,151 @@
return list;
}
-static void
-gdip_process_accelerators (gchar *text, int length, PangoAttrList *list)
+void
+gdip_set_array_values (int *array, int value, int num)
{
int i;
- for (i = 0; i < length; i++) {
- if (*(text + i) == GDIP_WINDOWS_ACCELERATOR) {
- /* don't show the prefix character */
- *(text + i) = GDIP_PANGOHACK_ACCELERATOR;
- /* if the next character is an accelerator then skip
over it (&& == &) */
- if ((i < length - 1) && (*(text + i + 1) ==
GDIP_WINDOWS_ACCELERATOR)) {
- i++;
- } else if (list) {
- /* add an attribute on the next character */
+ for (i = 0; i < num; i++)
+ array [i] = value;
+}
+
+static GString *
+gdip_process_string (gchar *text, int length, int removeAccelerators, int
trimSpace, PangoAttrList *list, int **charsRemoved)
+{
+ int i, j;
+ int nonws = 0;
+ gchar *iter;
+ gchar *iter2;
+ gunichar ch;
+GString *res = g_string_sized_new (length);
+
+ /* fast version: just check for final newline and remove */
+ if (!removeAccelerators && !trimSpace) {
+ j = length;
+ if (j > 0 && text [j-1] == '\n') {
+ j--;
+ if (j > 0 && text [j-1] == '\r')
+ j--;
+ }
+ g_string_append_len (res, text, j);
+ if (j == 0 && length > 0) {
+ g_string_append_c (res, ' ');
+ j++;
+ }
+ if (charsRemoved && *charsRemoved) {
+ int prevj = (g_utf8_prev_char (res->str + j) -
res->str);
+ gdip_set_array_values (*charsRemoved + prevj, length -
j, j - prevj);
+ }
+ return res;
+ }
+
+ iter = text;
+ i = 0;
+ j = 0;
+ while (iter - text < length) {
+ ch = g_utf8_get_char (iter);
+ if (ch == GDIP_WINDOWS_ACCELERATOR && removeAccelerators &&
(iter - text < length - 1)) {
+ nonws = 1;
+ iter2 = g_utf8_next_char (iter);
+ i += iter2 - iter;
+ iter = iter2;
+ ch = g_utf8_get_char (iter);
+ /* add an attribute on the next character */
+ if (list && (iter - text < length) && (ch !=
GDIP_WINDOWS_ACCELERATOR)) {
PangoAttribute *attr = pango_attr_underline_new
(PANGO_UNDERLINE_LOW);
- attr->start_index = i + 1;
- attr->end_in
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Take the reverse situation, why would Mono devs care on supporting application X because some users would like to run X on Mono ? The only difference here is that, in your case, the developer has to take care of one platform with minimal change involved where Mono would get ton of request preventing them to focus on coding real things. Also, all of the applications cited are open-source AND free software which allow you to patch them freely. Then if the main developer is stubborn enough to refuse your patch, just make it available or fork the project, that's one of the advantage of FOSS. -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Thu, Feb 12, 2009 at 3:23 PM, Stifu wrote: > > What about developers who don't care about Mono, but some of their users > being interested in running their app in Mono? > Sure, they could contact the devs to insist on supporting Mono, but then, > first, the app must still be under development, which is not obviously the > case, and second, the devs must be willing to listen and act... It'd just > be > much easier and more convenient if it just worked right away, if there is > no > downside involved. > > > Jérémie LAVAL wrote: > > > > There is a difference between implementing a public API used by lot of > > people and implementing low-level internals that 1/ you aren't supposed > to > > know in the first place, 2/ are used by 2-3 projects that could fix the > > bug > > with a two lines change if they cared about Mono. > > > > -- > > Jérémie Laval > > jeremie.la...@gmail.com > > http://garuma.wordpress.com > > > > -- > View this message in context: > http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977064.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 > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libgdiplus pango patch
Stifu wrote: > Considering how complex the whole thing looks, I think it'd be great if you > could turn your test app into automated tests, to make them public, prevent > regressions and make the landing of that patch safer. Thanks for the input! Yeah, I need to make some automated tests for some of that. The problem is that the measurements will depend on the fonts available, the system dpi, system-wide font hinting settings, etc., so it's a bit hard to make any of those tests repeatable on someone else's system. Also it's hard to tell things like if it really did draw the alignment, clipping, character direction, etc. correctly without looking at it. Any ideas on how to do any of that in a reliable sort of way for automatic testing would be greatly appreciated. Jonathan Anderson ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
What about developers who don't care about Mono, but some of their users being interested in running their app in Mono? Sure, they could contact the devs to insist on supporting Mono, but then, first, the app must still be under development, which is not obviously the case, and second, the devs must be willing to listen and act... It'd just be much easier and more convenient if it just worked right away, if there is no downside involved. Jérémie LAVAL wrote: > > There is a difference between implementing a public API used by lot of > people and implementing low-level internals that 1/ you aren't supposed to > know in the first place, 2/ are used by 2-3 projects that could fix the > bug > with a two lines change if they cared about Mono. > > -- > Jérémie Laval > jeremie.la...@gmail.com > http://garuma.wordpress.com > -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977064.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
Re: [Mono-dev] Mono and IBM
I was talking about running mono in a non-x86 platform. I'll have performance issues for sure but I don't know if it will be catastrophic or ignorable. On Wed, Feb 11, 2009 at 6:24 PM, Bill Seurer wrote: > 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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Stifu wrote: > Your opinion makes sense, but then, why bother with Windows.Forms (or other > things like pseudo-Windows registry support), for example? The Mono team You're missing the point. WinForms, Registry are publicly documented APIs. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
There is a difference between implementing a public API used by lot of people and implementing low-level internals that 1/ you aren't supposed to know in the first place, 2/ are used by 2-3 projects that could fix the bug with a two lines change if they cared about Mono. -- Jérémie Laval jeremie.la...@gmail.com http://garuma.wordpress.com On Thu, Feb 12, 2009 at 2:56 PM, Stifu wrote: > > Your opinion makes sense, but then, why bother with Windows.Forms (or other > things like pseudo-Windows registry support), for example? The Mono team > seems a bit torn between adding "hacky" stuff for the sake of compatibility > (note: I'm not bashing, I rely on the Windows.Forms support of Mono > myself), > and not trying to match .NET when easily possible (like this post from > yesterday shows: http://www.go-mono.com/forums/). > > > Jérémie LAVAL wrote: > > > > However, I think Mono isn't meant to be a *reimplementation* of .NET, > > it's > > an implementation of the *specifications* defined at ECMA/ISO. > > > > Now, if developers are using implementation specific details they are > > shooting themselves in the foot and should go fix their mess themselves, > > not > > blame Mono for it. > > > > Again, just my humble opinion. > > > > -- > > Jérémie Laval > > jeremie.la...@gmail.com > > http://garuma.wordpress.com > > > > -- > View this message in context: > http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976573.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 > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
PS: to clear things up, I got the wrong URL at the end of my post... I meant to paste this one: http://go-mono.com/forums/#nabble-td21954562 Paige Thompson wrote: > > All I'm saying is, if "hacky" stuff does not satisfy the business need > then > it's a useless effort. We (well not me I'm not writing for mono yet) have > to > consider who's ultimately going to be using it and what their needs are. > -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976707.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
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
All I'm saying is, if "hacky" stuff does not satisfy the business need then it's a useless effort. We (well not me I'm not writing for mono yet) have to consider who's ultimately going to be using it and what their needs are. On Thu, Feb 12, 2009 at 5:56 AM, Stifu wrote: > > Your opinion makes sense, but then, why bother with Windows.Forms (or other > things like pseudo-Windows registry support), for example? The Mono team > seems a bit torn between adding "hacky" stuff for the sake of compatibility > (note: I'm not bashing, I rely on the Windows.Forms support of Mono > myself), > and not trying to match .NET when easily possible (like this post from > yesterday shows: http://www.go-mono.com/forums/). > > > Jérémie LAVAL wrote: > > > > However, I think Mono isn't meant to be a *reimplementation* of .NET, > > it's > > an implementation of the *specifications* defined at ECMA/ISO. > > > > Now, if developers are using implementation specific details they are > > shooting themselves in the foot and should go fix their mess themselves, > > not > > blame Mono for it. > > > > Again, just my humble opinion. > > > > -- > > Jérémie Laval > > jeremie.la...@gmail.com > > http://garuma.wordpress.com > > > > -- > View this message in context: > http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976573.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 > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Alan McGovern wrote: > But it's the hacks that you added to your program which are causing > the issue in the first place ;) You want a hack to make your hack > work. What you really need is another hack which will work in all > cases. Unfortunately I can't think of a way which will work in all cases. I didn't add these hacks to a program. Consider a new user trying out mono. He tries mono with some useful tool that he uses in .NET Turns out it doesn't work. Yes, maybe it's the tools fault. But the end result is that it doesn't work, and the user thinks "arg, apparenlty mono doesn't run my .net stuff, I'm sticking to clr thank you very much". Bye, Lucas PS Please note that there is no "official" way to do what these programs are doing trough their "hack". ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Your opinion makes sense, but then, why bother with Windows.Forms (or other things like pseudo-Windows registry support), for example? The Mono team seems a bit torn between adding "hacky" stuff for the sake of compatibility (note: I'm not bashing, I rely on the Windows.Forms support of Mono myself), and not trying to match .NET when easily possible (like this post from yesterday shows: http://www.go-mono.com/forums/). Jérémie LAVAL wrote: > > However, I think Mono isn't meant to be a *reimplementation* of .NET, > it's > an implementation of the *specifications* defined at ECMA/ISO. > > Now, if developers are using implementation specific details they are > shooting themselves in the foot and should go fix their mess themselves, > not > blame Mono for it. > > Again, just my humble opinion. > > -- > Jérémie Laval > jeremie.la...@gmail.com > http://garuma.wordpress.com > -- View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976573.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
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Lucas Meijer wrote:
> However, in the real world(tm), this prevents many projects from
> running on Mono unmodified.
How about if, for a change, those projects were finally starting
to perceive mono as a platform with its own internals?
It's a no brainer to add a `if (Type.GetType("Mono.Runtime") != null)'
branch to the already existing hack.
There are chances that some projects are already using a platform
check what will fail after renaming the field. Some mono-only
projects might fail after renaming this field as well, making
a more elaborate patch necessary. Just because of the ignorance of
some library developers...
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
But it's the hacks that you added to your program which are causing the
issue in the first place ;) You want a hack to make your hack work. What you
really need is another hack which will work in all cases. Unfortunately I
can't think of a way which will work in all cases.
Alan.
(p.s. i'm not arguing for or against the change, just pointing out the
above)
On Thu, Feb 12, 2009 at 1:45 PM, Stifu wrote:
>
> I think that'd be a quite bad solution, because it'd add a lot of
> confusion,
> and possibly divide the user base. I can already imagine debugging user
> problems, like "Are you using Mono standard edition or the Mono modded by
> SomeRandomGuy?"
> I'd rather add hacks in the program than having more frameworks to worry
> about.
>
>
> Paige Thompson wrote:
> >
> > maybe field names should be driven off of an XML file at compile time or
> > something instead of hard coded. I mean yeah that dances on the line of
> > still having to modify mono but at least in that case it wouldn't be hard
> > coded. Then everybody could be happy. I guess what I'm trying to say is,
> > perhaps rather than arguing about who's is better and more worth efforts
> > rather have a compatibility layer for the inorite way and the tried and
> > true.
> >
> > -Adele
> >
> > On Thu, Feb 12, 2009 at 5:13 AM, Stifu wrote:
> >
> >>
> >> I have to agree.
> >>
> >> Reverse-engineering complicated algorithms for the sake of matching MS
> >> .NET
> >> perfectly is one thing, and may not be worth the time and efforts, but
> >> simply changing a string to improve compatibility is an easy win.
> >>
> >> Many things in the past of Mono have been done to improve compatibility
> >> with
> >> existing .NET apps and get Windows developers interested (such as
> >> Windows.Forms support, for example). Simply put, it doesn't make much
> >> sense
> >> to me to try that hard to catch high-hanging fruits if you're going to
> >> ignore low-hanging ones.
> >>
> >>
> >> Lucas Meijer-4 wrote:
> >> >
> >> > Hey,
> >> >
> >> > Our team has been busy porting some unit testing related frameworks to
> >> > mono.
> >> > porting is probably not the right word, it's mostly creating repro
> >> cases
> >> > of mono bugs,
> >> > reporting them, and waiting for them to be fixed. (Which happens fast
> >> by
> >> > the way. Thanks!)
> >> >
> >> > So far we're looking at NInject, Moq and xUnit.
> >> >
> >> > There are / have been bugs in mono that prevent all of these projects
> >> > from running.
> >> > Most of them are valid mono bugs, nothing special here.
> >> >
> >> > In addition to real mono bugs, there's also the fact that many of
> these
> >> > frameworks, use this
> >> > commonly used "trick":
> >> >
> >> > FieldInfo remoteStackTraceString =
> >> > typeof(Exception).GetField("_remoteStackTraceString",
> >> > BindingFlags.Instance | BindingFlags.NonPublic);
> >> >
> >> > This doesn't work on mono, since in mono the private field storing the
> >> > stacktrace is called "remote_stack_trace".
> >> >
> >> > This issue has been reported before as issue 425512 (
> >> > https://bugzilla.novell.com/show_bug.cgi?id=425512 )
> >> >
> >> > One could argue, and the reason for the wontfix status of the issue
> >> does
> >> > so, that these folks rely on undocumented internals.
> >> > They shouldn't do it, and Mono shouldn't rename it's own private field
> >> > to match that of the CLR.
> >> >
> >> > However, in the real world(tm), this prevents many projects from
> >> > running on Mono unmodified.
> >> >
> >> > I would like to argue that in this specific case, where the (percieved
> >> > by me, maybe incorrectly) amount of work for mono to change it's
> >> private
> >> > fieldname to
> >> > match that of the CLR, is a reasonable cost for enabling this quite
> >> > frequently found in the wild trick of grabbing the internal stack
> trace
> >> > of an exception.
> >> >
> >> > Maybe I'm underestimating the amount of work to rename the mono
> >> > fieldname to match the clr one. If that's the case, please consider
> >> this
> >> > message
> >> > as another datapoint of three useful .net frameworks unable to run on
> >> > mono unmodified.
> >> >
> >> > Here's a bit more info on the trick:
> >> >
> >> > Here is a bit more background on the trick:
> >> >
> >>
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
> >> >
> >> > Bye, Lucas
> >> > ___
> >> > Mono-devel-list mailing list
> >> > Mono-devel-list@lists.ximian.com
> >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.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
> >>
Re: [Mono-dev] libgdiplus pango patch
Hello Jonathan, On Thu, 2009-02-12 at 18:46 +0700, Jonathan Anderson wrote: > Sebastien, > > Thanks for the reply. > > Sebastien Pouliot wrote: > > Hello Jonathan, > > > > On Tue, 2009-02-10 at 13:53 +0700, Jonathan Anderson wrote: > >> Hi all, > >> > >> I was wondering if anyone has had a chance to look at my patch submitted > >> last week yet. Any and all feedback is appreciated, and if I need to do > >> some more work to get this accepted, I just need to know what to do. > > > > I only had a quick look last week, but will look at it more carefully > > soon. > > > > A quick comment: it needs a ChangeLog ;-) > > I should have done that. Here's a list of what my changes do: > > * improve accelerator handling > * improve end-of-line whitespace trimming (still needs some work, but it > should be about the same as the cairo renderer now) > * vertical text support (needs more work) > * clipping more consistent with MS GDI+ > * better bidi text support > * string trimming closer to MS GDI+ > * tab stops (untested) > * better bounding boxes returned (taking into account ink and logical space) > * support for codepointsFitted in MeasureString > * better linesFilled support in MeasureString Great :) > >> Should I create a bug in the tracker to help track the work on complex > >> script support? > > > > Yes, that would be useful - which brings me to a "long term" comment: > > libgdiplus can't switch to pango output until it becomes a superset of > > the features that it currently (custom text renderer) support - i.e. > > complex script support is awesome but not enough as many people depends > > on other features not yet available in the pango renderer. > > > Yes, I understand that. I mainly want to get some code out there for > complex script support that works better than what's there now. Of we understand each other perfectly :) > course I'd like it to be the default some day, but I know there needs to > be more work and testing done before that can be the case. Even if it > doesn't get to be the default, having a good option for non-roman > scripts when needed is great. > > There are a couple of issues that I've fixed since the patch I submitted > as well (fixed a problem with vertical text and another difference with > how MS GDI+ handles the NoWrap flag). Should I do another patch with > everything again, or just a patch on the patched version for those? You can issue a new, complete patch. > Here's what I know isn't supported and/or needs more work: > * Need to test the tab stop support > * There are a few small differences with the MS GDI+ in string trimming > and wrapping that will be hard to fix unless I use the lower-level pango > API instead of the pango_layout calls. That was my original conclusion too. The high-level pango API is not able to give us everything needed to support the options already present in the custom renderer. The "right" (complete) solution is to use the low level API. > The cairo renderer also has some > differences in these areas as well. Yes, there are a few (4-5) bugs open on some specific cases. Most of them requires *big* changes to the custom renderer (things that was not part of its design) which are unlikely to occur soon* * in fact my original idea was, once the pango version was complete enough to replace the current renderer, to detect the pango library at build time and use it (and the system cairo) if possible - falling back to the old renderer on older systems. > * digit substitution is not implemented > * the DisplayFormatControl flag is not implemented > * MeasureString is significantly slower than the cairo renderer > (DrawString is a little slower, but not that much) That's also what I noticed a while ago - but the output also looked better (e.g. kerning). > I don't think the digit substitution or DisplayFormatControl flag are > implemented in the cairo renderer either. I've built myself a test app > to help see differences between MS GDI+, the cairo renderer, and the > pango renderer, so that's helping a lot in working things out. Yes, I had such a (crude) tool when I looked at "all" the options (which made me realize we were doing very badly on the, thankfully, uncommon StringFormat options). This is something that needs to be turned into "real" tests at some stage. > From a MWF perspective, the only control that I think needs a bit of > work is the TextBox and derivatives. To be able to support non-roman > scripts, it needs to think of text in terms of paragraphs instead of > lines. I have some ideas that I'll be playing with to push down some > more of the rendering/placement functionality into the > TextBoxTextRenderer. I should be able to take the existing code and > abstract it in a way that would allow the TextBox to swap rendering > back-ends using the current code, uniscribe, or pango. Sounds good (even if this is not parts I'm involved with ;-) Thanks!
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
I think that'd be a quite bad solution, because it'd add a lot of confusion,
and possibly divide the user base. I can already imagine debugging user
problems, like "Are you using Mono standard edition or the Mono modded by
SomeRandomGuy?"
I'd rather add hacks in the program than having more frameworks to worry
about.
Paige Thompson wrote:
>
> maybe field names should be driven off of an XML file at compile time or
> something instead of hard coded. I mean yeah that dances on the line of
> still having to modify mono but at least in that case it wouldn't be hard
> coded. Then everybody could be happy. I guess what I'm trying to say is,
> perhaps rather than arguing about who's is better and more worth efforts
> rather have a compatibility layer for the inorite way and the tried and
> true.
>
> -Adele
>
> On Thu, Feb 12, 2009 at 5:13 AM, Stifu wrote:
>
>>
>> I have to agree.
>>
>> Reverse-engineering complicated algorithms for the sake of matching MS
>> .NET
>> perfectly is one thing, and may not be worth the time and efforts, but
>> simply changing a string to improve compatibility is an easy win.
>>
>> Many things in the past of Mono have been done to improve compatibility
>> with
>> existing .NET apps and get Windows developers interested (such as
>> Windows.Forms support, for example). Simply put, it doesn't make much
>> sense
>> to me to try that hard to catch high-hanging fruits if you're going to
>> ignore low-hanging ones.
>>
>>
>> Lucas Meijer-4 wrote:
>> >
>> > Hey,
>> >
>> > Our team has been busy porting some unit testing related frameworks to
>> > mono.
>> > porting is probably not the right word, it's mostly creating repro
>> cases
>> > of mono bugs,
>> > reporting them, and waiting for them to be fixed. (Which happens fast
>> by
>> > the way. Thanks!)
>> >
>> > So far we're looking at NInject, Moq and xUnit.
>> >
>> > There are / have been bugs in mono that prevent all of these projects
>> > from running.
>> > Most of them are valid mono bugs, nothing special here.
>> >
>> > In addition to real mono bugs, there's also the fact that many of these
>> > frameworks, use this
>> > commonly used "trick":
>> >
>> > FieldInfo remoteStackTraceString =
>> > typeof(Exception).GetField("_remoteStackTraceString",
>> > BindingFlags.Instance | BindingFlags.NonPublic);
>> >
>> > This doesn't work on mono, since in mono the private field storing the
>> > stacktrace is called "remote_stack_trace".
>> >
>> > This issue has been reported before as issue 425512 (
>> > https://bugzilla.novell.com/show_bug.cgi?id=425512 )
>> >
>> > One could argue, and the reason for the wontfix status of the issue
>> does
>> > so, that these folks rely on undocumented internals.
>> > They shouldn't do it, and Mono shouldn't rename it's own private field
>> > to match that of the CLR.
>> >
>> > However, in the real world(tm), this prevents many projects from
>> > running on Mono unmodified.
>> >
>> > I would like to argue that in this specific case, where the (percieved
>> > by me, maybe incorrectly) amount of work for mono to change it's
>> private
>> > fieldname to
>> > match that of the CLR, is a reasonable cost for enabling this quite
>> > frequently found in the wild trick of grabbing the internal stack trace
>> > of an exception.
>> >
>> > Maybe I'm underestimating the amount of work to rename the mono
>> > fieldname to match the clr one. If that's the case, please consider
>> this
>> > message
>> > as another datapoint of three useful .net frameworks unable to run on
>> > mono unmodified.
>> >
>> > Here's a bit more info on the trick:
>> >
>> > Here is a bit more background on the trick:
>> >
>> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
>> >
>> > Bye, Lucas
>> > ___
>> > Mono-devel-list mailing list
>> > Mono-devel-list@lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.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
>>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
--
View this message in context:
http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21976367.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
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
However, I think Mono isn't meant to be a *reimplementation* of .NET, it's
an implementation of the *specifications* defined at ECMA/ISO.
Now, if developers are using implementation specific details they are
shooting themselves in the foot and should go fix their mess themselves, not
blame Mono for it.
Again, just my humble opinion.
--
Jérémie Laval
jeremie.la...@gmail.com
http://garuma.wordpress.com
On Thu, Feb 12, 2009 at 2:13 PM, Stifu wrote:
>
> I have to agree.
>
> Reverse-engineering complicated algorithms for the sake of matching MS .NET
> perfectly is one thing, and may not be worth the time and efforts, but
> simply changing a string to improve compatibility is an easy win.
>
> Many things in the past of Mono have been done to improve compatibility
> with
> existing .NET apps and get Windows developers interested (such as
> Windows.Forms support, for example). Simply put, it doesn't make much sense
> to me to try that hard to catch high-hanging fruits if you're going to
> ignore low-hanging ones.
>
>
> Lucas Meijer-4 wrote:
> >
> > Hey,
> >
> > Our team has been busy porting some unit testing related frameworks to
> > mono.
> > porting is probably not the right word, it's mostly creating repro cases
> > of mono bugs,
> > reporting them, and waiting for them to be fixed. (Which happens fast by
> > the way. Thanks!)
> >
> > So far we're looking at NInject, Moq and xUnit.
> >
> > There are / have been bugs in mono that prevent all of these projects
> > from running.
> > Most of them are valid mono bugs, nothing special here.
> >
> > In addition to real mono bugs, there's also the fact that many of these
> > frameworks, use this
> > commonly used "trick":
> >
> > FieldInfo remoteStackTraceString =
> > typeof(Exception).GetField("_remoteStackTraceString",
> > BindingFlags.Instance | BindingFlags.NonPublic);
> >
> > This doesn't work on mono, since in mono the private field storing the
> > stacktrace is called "remote_stack_trace".
> >
> > This issue has been reported before as issue 425512 (
> > https://bugzilla.novell.com/show_bug.cgi?id=425512 )
> >
> > One could argue, and the reason for the wontfix status of the issue does
> > so, that these folks rely on undocumented internals.
> > They shouldn't do it, and Mono shouldn't rename it's own private field
> > to match that of the CLR.
> >
> > However, in the real world(tm), this prevents many projects from
> > running on Mono unmodified.
> >
> > I would like to argue that in this specific case, where the (percieved
> > by me, maybe incorrectly) amount of work for mono to change it's private
> > fieldname to
> > match that of the CLR, is a reasonable cost for enabling this quite
> > frequently found in the wild trick of grabbing the internal stack trace
> > of an exception.
> >
> > Maybe I'm underestimating the amount of work to rename the mono
> > fieldname to match the clr one. If that's the case, please consider this
> > message
> > as another datapoint of three useful .net frameworks unable to run on
> > mono unmodified.
> >
> > Here's a bit more info on the trick:
> >
> > Here is a bit more background on the trick:
> >
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
> >
> > Bye, Lucas
> > ___
> > Mono-devel-list mailing list
> > Mono-devel-list@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.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
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
maybe field names should be driven off of an XML file at compile time or
something instead of hard coded. I mean yeah that dances on the line of
still having to modify mono but at least in that case it wouldn't be hard
coded. Then everybody could be happy. I guess what I'm trying to say is,
perhaps rather than arguing about who's is better and more worth efforts
rather have a compatibility layer for the inorite way and the tried and
true.
-Adele
On Thu, Feb 12, 2009 at 5:13 AM, Stifu wrote:
>
> I have to agree.
>
> Reverse-engineering complicated algorithms for the sake of matching MS .NET
> perfectly is one thing, and may not be worth the time and efforts, but
> simply changing a string to improve compatibility is an easy win.
>
> Many things in the past of Mono have been done to improve compatibility
> with
> existing .NET apps and get Windows developers interested (such as
> Windows.Forms support, for example). Simply put, it doesn't make much sense
> to me to try that hard to catch high-hanging fruits if you're going to
> ignore low-hanging ones.
>
>
> Lucas Meijer-4 wrote:
> >
> > Hey,
> >
> > Our team has been busy porting some unit testing related frameworks to
> > mono.
> > porting is probably not the right word, it's mostly creating repro cases
> > of mono bugs,
> > reporting them, and waiting for them to be fixed. (Which happens fast by
> > the way. Thanks!)
> >
> > So far we're looking at NInject, Moq and xUnit.
> >
> > There are / have been bugs in mono that prevent all of these projects
> > from running.
> > Most of them are valid mono bugs, nothing special here.
> >
> > In addition to real mono bugs, there's also the fact that many of these
> > frameworks, use this
> > commonly used "trick":
> >
> > FieldInfo remoteStackTraceString =
> > typeof(Exception).GetField("_remoteStackTraceString",
> > BindingFlags.Instance | BindingFlags.NonPublic);
> >
> > This doesn't work on mono, since in mono the private field storing the
> > stacktrace is called "remote_stack_trace".
> >
> > This issue has been reported before as issue 425512 (
> > https://bugzilla.novell.com/show_bug.cgi?id=425512 )
> >
> > One could argue, and the reason for the wontfix status of the issue does
> > so, that these folks rely on undocumented internals.
> > They shouldn't do it, and Mono shouldn't rename it's own private field
> > to match that of the CLR.
> >
> > However, in the real world(tm), this prevents many projects from
> > running on Mono unmodified.
> >
> > I would like to argue that in this specific case, where the (percieved
> > by me, maybe incorrectly) amount of work for mono to change it's private
> > fieldname to
> > match that of the CLR, is a reasonable cost for enabling this quite
> > frequently found in the wild trick of grabbing the internal stack trace
> > of an exception.
> >
> > Maybe I'm underestimating the amount of work to rename the mono
> > fieldname to match the clr one. If that's the case, please consider this
> > message
> > as another datapoint of three useful .net frameworks unable to run on
> > mono unmodified.
> >
> > Here's a bit more info on the trick:
> >
> > Here is a bit more background on the trick:
> >
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
> >
> > Bye, Lucas
> > ___
> > Mono-devel-list mailing list
> > Mono-devel-list@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.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
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
I have to agree.
Reverse-engineering complicated algorithms for the sake of matching MS .NET
perfectly is one thing, and may not be worth the time and efforts, but
simply changing a string to improve compatibility is an easy win.
Many things in the past of Mono have been done to improve compatibility with
existing .NET apps and get Windows developers interested (such as
Windows.Forms support, for example). Simply put, it doesn't make much sense
to me to try that hard to catch high-hanging fruits if you're going to
ignore low-hanging ones.
Lucas Meijer-4 wrote:
>
> Hey,
>
> Our team has been busy porting some unit testing related frameworks to
> mono.
> porting is probably not the right word, it's mostly creating repro cases
> of mono bugs,
> reporting them, and waiting for them to be fixed. (Which happens fast by
> the way. Thanks!)
>
> So far we're looking at NInject, Moq and xUnit.
>
> There are / have been bugs in mono that prevent all of these projects
> from running.
> Most of them are valid mono bugs, nothing special here.
>
> In addition to real mono bugs, there's also the fact that many of these
> frameworks, use this
> commonly used "trick":
>
> FieldInfo remoteStackTraceString =
> typeof(Exception).GetField("_remoteStackTraceString",
> BindingFlags.Instance | BindingFlags.NonPublic);
>
> This doesn't work on mono, since in mono the private field storing the
> stacktrace is called "remote_stack_trace".
>
> This issue has been reported before as issue 425512 (
> https://bugzilla.novell.com/show_bug.cgi?id=425512 )
>
> One could argue, and the reason for the wontfix status of the issue does
> so, that these folks rely on undocumented internals.
> They shouldn't do it, and Mono shouldn't rename it's own private field
> to match that of the CLR.
>
> However, in the real world(tm), this prevents many projects from
> running on Mono unmodified.
>
> I would like to argue that in this specific case, where the (percieved
> by me, maybe incorrectly) amount of work for mono to change it's private
> fieldname to
> match that of the CLR, is a reasonable cost for enabling this quite
> frequently found in the wild trick of grabbing the internal stack trace
> of an exception.
>
> Maybe I'm underestimating the amount of work to rename the mono
> fieldname to match the clr one. If that's the case, please consider this
> message
> as another datapoint of three useful .net frameworks unable to run on
> mono unmodified.
>
> Here's a bit more info on the trick:
>
> Here is a bit more background on the trick:
> http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
>
> Bye, Lucas
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
--
View this message in context:
http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21975728.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
[Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Hey,
Our team has been busy porting some unit testing related frameworks to mono.
porting is probably not the right word, it's mostly creating repro cases
of mono bugs,
reporting them, and waiting for them to be fixed. (Which happens fast by
the way. Thanks!)
So far we're looking at NInject, Moq and xUnit.
There are / have been bugs in mono that prevent all of these projects
from running.
Most of them are valid mono bugs, nothing special here.
In addition to real mono bugs, there's also the fact that many of these
frameworks, use this
commonly used "trick":
FieldInfo remoteStackTraceString =
typeof(Exception).GetField("_remoteStackTraceString",
BindingFlags.Instance | BindingFlags.NonPublic);
This doesn't work on mono, since in mono the private field storing the
stacktrace is called "remote_stack_trace".
This issue has been reported before as issue 425512 (
https://bugzilla.novell.com/show_bug.cgi?id=425512 )
One could argue, and the reason for the wontfix status of the issue does
so, that these folks rely on undocumented internals.
They shouldn't do it, and Mono shouldn't rename it's own private field
to match that of the CLR.
However, in the real world(tm), this prevents many projects from
running on Mono unmodified.
I would like to argue that in this specific case, where the (percieved
by me, maybe incorrectly) amount of work for mono to change it's private
fieldname to
match that of the CLR, is a reasonable cost for enabling this quite
frequently found in the wild trick of grabbing the internal stack trace
of an exception.
Maybe I'm underestimating the amount of work to rename the mono
fieldname to match the clr one. If that's the case, please consider this
message
as another datapoint of three useful .net frameworks unable to run on
mono unmodified.
Here's a bit more info on the trick:
Here is a bit more background on the trick:
http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx
Bye, Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] libgdiplus pango patch
Jonathan: I'm no expert or reviewer, but I thought I'd throw in my 2 cents. About this: "I've built myself a test app to help see differences between MS GDI+, the cairo renderer, and the pango renderer, so that's helping a lot in working things out." Considering how complex the whole thing looks, I think it'd be great if you could turn your test app into automated tests, to make them public, prevent regressions and make the landing of that patch safer. -- View this message in context: http://www.nabble.com/libgdiplus-pango-patch-tp21829307p21974545.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
Re: [Mono-dev] libgdiplus pango patch
Sebastien, Thanks for the reply. Sebastien Pouliot wrote: > Hello Jonathan, > > On Tue, 2009-02-10 at 13:53 +0700, Jonathan Anderson wrote: >> Hi all, >> >> I was wondering if anyone has had a chance to look at my patch submitted >> last week yet. Any and all feedback is appreciated, and if I need to do >> some more work to get this accepted, I just need to know what to do. > > I only had a quick look last week, but will look at it more carefully > soon. > > A quick comment: it needs a ChangeLog ;-) I should have done that. Here's a list of what my changes do: * improve accelerator handling * improve end-of-line whitespace trimming (still needs some work, but it should be about the same as the cairo renderer now) * vertical text support (needs more work) * clipping more consistent with MS GDI+ * better bidi text support * string trimming closer to MS GDI+ * tab stops (untested) * better bounding boxes returned (taking into account ink and logical space) * support for codepointsFitted in MeasureString * better linesFilled support in MeasureString >> Should I create a bug in the tracker to help track the work on complex >> script support? > > Yes, that would be useful - which brings me to a "long term" comment: > libgdiplus can't switch to pango output until it becomes a superset of > the features that it currently (custom text renderer) support - i.e. > complex script support is awesome but not enough as many people depends > on other features not yet available in the pango renderer. Yes, I understand that. I mainly want to get some code out there for complex script support that works better than what's there now. Of course I'd like it to be the default some day, but I know there needs to be more work and testing done before that can be the case. Even if it doesn't get to be the default, having a good option for non-roman scripts when needed is great. There are a couple of issues that I've fixed since the patch I submitted as well (fixed a problem with vertical text and another difference with how MS GDI+ handles the NoWrap flag). Should I do another patch with everything again, or just a patch on the patched version for those? Here's what I know isn't supported and/or needs more work: * Need to test the tab stop support * There are a few small differences with the MS GDI+ in string trimming and wrapping that will be hard to fix unless I use the lower-level pango API instead of the pango_layout calls. The cairo renderer also has some differences in these areas as well. * digit substitution is not implemented * the DisplayFormatControl flag is not implemented * MeasureString is significantly slower than the cairo renderer (DrawString is a little slower, but not that much) I don't think the digit substitution or DisplayFormatControl flag are implemented in the cairo renderer either. I've built myself a test app to help see differences between MS GDI+, the cairo renderer, and the pango renderer, so that's helping a lot in working things out. From a MWF perspective, the only control that I think needs a bit of work is the TextBox and derivatives. To be able to support non-roman scripts, it needs to think of text in terms of paragraphs instead of lines. I have some ideas that I'll be playing with to push down some more of the rendering/placement functionality into the TextBoxTextRenderer. I should be able to take the existing code and abstract it in a way that would allow the TextBox to swap rendering back-ends using the current code, uniscribe, or pango. Jonathan Anderson ___ 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
Hi, I don't know whether this is an option for you, but we use Oracle ODP libraries (Oracle.DataAccess.Client) instead of Microsoft ones (System.Data.OracleClient) and we have no problem with Spring.NET/NHibernate. Best regards 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
I'd like to use the webservice "As is" so that we can switch easyly... if I won't be able to do it with IBM.Data.DB2 in a few days I'll consider using other way to connect. Do you know if with these providers you can connecto to AS/400? Many thanks Best regards Bartolomeo Nicolotti wrote: > > Da: Daniel Morgan > > Have you considered using ODBC provider instead? > > System.Data.Odbc namespace is included in System.Data assembly. > > You can use iodbc or unixodbc on linux. There's commercial odbc solutions > for linux too. > > http://mono-project.com/ODBC > > http://www.unixodbc.com/doc/db2.html > > Novell maintains System.Data.Odbc; however, I do not think anyone is > maintaining IBM.Data.DB2 in Mono. > > > --- On Wed, 2/11/09, Bartolomeo Nicolotti wrote: > > > > Bartolomeo Nicolotti wrote: >> >> 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-Una
Re: [Mono-dev] IBM.Data.DB2.DB2Exception: Unable to allocate statement handle
Da: Daniel Morgan Have you considered using ODBC provider instead? System.Data.Odbc namespace is included in System.Data assembly. You can use iodbc or unixodbc on linux. There's commercial odbc solutions for linux too. http://mono-project.com/ODBC http://www.unixodbc.com/doc/db2.html Novell maintains System.Data.Odbc; however, I do not think anyone is maintaining IBM.Data.DB2 in Mono. --- On Wed, 2/11/09, Bartolomeo Nicolotti wrote: Bartolomeo Nicolotti wrote: > > 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-tp21953488p21971654.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
