[Mono-dev] Monoco update
Hi, I updated Monoco (http://www.bat.org/~tomba/monoco.html) to work with svn head of Mono. Behaviour of GC had changed a bit and it broke the continuations (GC didn't follow an IntPtr in a managed object). I also updated the naive benchmarks on the web page. While fixing the bug I started to think about how the continuations would work with the new precice GC. I've understood that in the first phase the new GC will scan stack conservatively. Is precise stack scanning something that may happen in the distant future, or something that will definitely come? The same information that the GC uses to do a precise stack scan could possibly be used to serialize continuations. Also currently the whole area reserved for continuation's stack is scanned, even if it is known that only part of the area contains real data. This is also something that I hope I will get fixed with the new GC. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] File accesses in ported applications
Wed May 02 11:32:40 @grendel Dick: do you think it would be possible to write a file analyzer? Wed May 02 11:32:43 @grendel file access analyzer Wed May 02 11:33:18 @Dick how about an aspx-lint that checks for this sort of thing? Wed May 02 11:33:37 @grendel Dick: the lint would have to be either a monitor app or inside Mono Wed May 02 11:33:42 @grendel it's not aspx-specific, IMHO Wed May 02 11:33:48 @Dick i was thinking separate app Wed May 02 11:33:52 @grendel it can affect WF apps too Wed May 02 11:33:59 @Dick anyway, what would your file access analyzer do? Wed May 02 11:34:26 @grendel it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name Wed May 02 11:34:35 @grendel e.g. someFile.txt, somefIle.txt etc Wed May 02 11:34:41 @Dick hmm Wed May 02 11:34:46 @Dick that could be handy Wed May 02 11:34:46 @grendel and would warn about the method, file, line where it happened Wed May 02 11:34:52 @grendel and output a report Wed May 02 11:34:59 @grendel it would be a great aid in porting Wed May 02 11:35:08 @Dick yeah Wed May 02 11:35:21 @grendel it could also look at the disk and check if there are files of the same flatten names in the same dir Wed May 02 11:35:22 @Dick i wonder if it would fit inside gendarme? Wed May 02 11:35:26 @grendel and make that a critical working Wed May 02 11:35:27 @Dick or moma Wed May 02 11:35:42 @grendel hm, moma would be a better choice I think Wed May 02 11:36:02 @grendel Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime Wed May 02 11:36:08 @grendel and enable it along with IOMAP Wed May 02 11:36:22 @Dick yeah, thats definitely possible Wed May 02 11:36:30 @grendel it would take care of all the cases Wed May 02 11:36:50 @grendel you could output the diags to console on *nix and to the event sink on windows Wed May 02 11:36:54 @Dick the problem would be noticing the output if its was stuck there Wed May 02 11:37:22 @grendel yeah, but you can't do much about it Wed May 02 11:37:29 @grendel people must know the feature exists and where to find it Wed May 02 11:37:35 @grendel we put it in the docs and that's it Wed May 02 11:37:56 @Dick personally i'd put it in moma first and the runtime second Wed May 02 11:37:57 @grendel you could even enable it conditionally Wed May 02 11:38:08 @grendel Dick: that might be a good idea for testing, yeah Wed May 02 11:38:19 @Dick it would have to be conditional, saving all the filenames would be time and memory consuming Wed May 02 11:38:30 @grendel true Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this Wed May 02 11:39:13 @grendel Dick: cut-n-paste and mail to them? :) Wed May 02 11:39:26 @Dick hopefully they might notice their names light up :) Wed May 02 11:39:41 @Dick sending it to xml or mono-devel would be good though Wed May 02 11:39:50 @grendel miguel: read what's above this line :) Wed May 02 11:39:56 @grendel jpobst|gone: read what's above this line :) Wed May 02 11:40:21 @grendel Dick: that's true signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File accesses in ported applications
I think that both MoMa and Gendarme could benefit from the idea. What if MoMa ships with the Gendarme framework and a subset of useful rules? Jb On 5/2/07, Dick Porter [EMAIL PROTECTED] wrote: Wed May 02 11:32:40 @grendel Dick: do you think it would be possible to write a file analyzer? Wed May 02 11:32:43 @grendel file access analyzer Wed May 02 11:33:18 @Dick how about an aspx-lint that checks for this sort of thing? Wed May 02 11:33:37 @grendel Dick: the lint would have to be either a monitor app or inside Mono Wed May 02 11:33:42 @grendel it's not aspx-specific, IMHO Wed May 02 11:33:48 @Dick i was thinking separate app Wed May 02 11:33:52 @grendel it can affect WF apps too Wed May 02 11:33:59 @Dick anyway, what would your file access analyzer do? Wed May 02 11:34:26 @grendel it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name Wed May 02 11:34:35 @grendel e.g. someFile.txt, somefIle.txt etc Wed May 02 11:34:41 @Dick hmm Wed May 02 11:34:46 @Dick that could be handy Wed May 02 11:34:46 @grendel and would warn about the method, file, line where it happened Wed May 02 11:34:52 @grendel and output a report Wed May 02 11:34:59 @grendel it would be a great aid in porting Wed May 02 11:35:08 @Dick yeah Wed May 02 11:35:21 @grendel it could also look at the disk and check if there are files of the same flatten names in the same dir Wed May 02 11:35:22 @Dick i wonder if it would fit inside gendarme? Wed May 02 11:35:26 @grendel and make that a critical working Wed May 02 11:35:27 @Dick or moma Wed May 02 11:35:42 @grendel hm, moma would be a better choice I think Wed May 02 11:36:02 @grendel Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime Wed May 02 11:36:08 @grendel and enable it along with IOMAP Wed May 02 11:36:22 @Dick yeah, thats definitely possible Wed May 02 11:36:30 @grendel it would take care of all the cases Wed May 02 11:36:50 @grendel you could output the diags to console on *nix and to the event sink on windows Wed May 02 11:36:54 @Dick the problem would be noticing the output if its was stuck there Wed May 02 11:37:22 @grendel yeah, but you can't do much about it Wed May 02 11:37:29 @grendel people must know the feature exists and where to find it Wed May 02 11:37:35 @grendel we put it in the docs and that's it Wed May 02 11:37:56 @Dick personally i'd put it in moma first and the runtime second Wed May 02 11:37:57 @grendel you could even enable it conditionally Wed May 02 11:38:08 @grendel Dick: that might be a good idea for testing, yeah Wed May 02 11:38:19 @Dick it would have to be conditional, saving all the filenames would be time and memory consuming Wed May 02 11:38:30 @grendel true Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this Wed May 02 11:39:13 @grendel Dick: cut-n-paste and mail to them? :) Wed May 02 11:39:26 @Dick hopefully they might notice their names light up :) Wed May 02 11:39:41 @Dick sending it to xml or mono-devel would be good though Wed May 02 11:39:50 @grendel miguel: read what's above this line :) Wed May 02 11:39:56 @grendel jpobst|gone: read what's above this line :) Wed May 02 11:40:21 @grendel Dick: that's true ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Jb ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] File accesses in ported applications
While it wouldn't be too hard to make a Gendarme rule, it would not give results as good as a runtime-based solution. The main reason being that all string/Path API being used to construct a file + user input would make any rule miss *a lot* of cases and also reports some (but probably not much) false positives. Of course the best is to have both (rule runtime support ;-) On Wed, 2007-05-02 at 13:17 +0100, Dick Porter wrote: Wed May 02 11:32:40 @grendel Dick: do you think it would be possible to write a file analyzer? Wed May 02 11:32:43 @grendel file access analyzer Wed May 02 11:33:18 @Dick how about an aspx-lint that checks for this sort of thing? Wed May 02 11:33:37 @grendel Dick: the lint would have to be either a monitor app or inside Mono Wed May 02 11:33:42 @grendel it's not aspx-specific, IMHO Wed May 02 11:33:48 @Dick i was thinking separate app Wed May 02 11:33:52 @grendel it can affect WF apps too Wed May 02 11:33:59 @Dick anyway, what would your file access analyzer do? Wed May 02 11:34:26 @grendel it would check for cases when an app is inconsistently accessing a file with the same case-insensitive name Wed May 02 11:34:35 @grendel e.g. someFile.txt, somefIle.txt etc Wed May 02 11:34:41 @Dick hmm Wed May 02 11:34:46 @Dick that could be handy Wed May 02 11:34:46 @grendel and would warn about the method, file, line where it happened Wed May 02 11:34:52 @grendel and output a report Wed May 02 11:34:59 @grendel it would be a great aid in porting Wed May 02 11:35:08 @Dick yeah Wed May 02 11:35:21 @grendel it could also look at the disk and check if there are files of the same flatten names in the same dir Wed May 02 11:35:22 @Dick i wonder if it would fit inside gendarme? Wed May 02 11:35:26 @grendel and make that a critical working Wed May 02 11:35:27 @Dick or moma Wed May 02 11:35:42 @grendel hm, moma would be a better choice I think Wed May 02 11:36:02 @grendel Dick: although I'm inclined to think it would just as well be a good thing to put in the runtime Wed May 02 11:36:08 @grendel and enable it along with IOMAP Wed May 02 11:36:22 @Dick yeah, thats definitely possible Wed May 02 11:36:30 @grendel it would take care of all the cases Wed May 02 11:36:50 @grendel you could output the diags to console on *nix and to the event sink on windows Wed May 02 11:36:54 @Dick the problem would be noticing the output if its was stuck there Wed May 02 11:37:22 @grendel yeah, but you can't do much about it Wed May 02 11:37:29 @grendel people must know the feature exists and where to find it Wed May 02 11:37:35 @grendel we put it in the docs and that's it Wed May 02 11:37:56 @Dick personally i'd put it in moma first and the runtime second Wed May 02 11:37:57 @grendel you could even enable it conditionally Wed May 02 11:38:08 @grendel Dick: that might be a good idea for testing, yeah Wed May 02 11:38:19 @Dick it would have to be conditional, saving all the filenames would be time and memory consuming Wed May 02 11:38:30 @grendel true Wed May 02 11:38:55 * Dick wonders if miguel or jpobst|gone is going to notice this Wed May 02 11:39:13 @grendel Dick: cut-n-paste and mail to them? :) Wed May 02 11:39:26 @Dick hopefully they might notice their names light up :) Wed May 02 11:39:41 @Dick sending it to xml or mono-devel would be good though Wed May 02 11:39:50 @grendel miguel: read what's above this line :) Wed May 02 11:39:56 @grendel jpobst|gone: read what's above this line :) Wed May 02 11:40:21 @grendel Dick: that's true ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Sebastien Pouliot [EMAIL PROTECTED] Blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] System:HybridDictionary should make ordinal string comparison
Hello all, Please review the attached patch. Regards, Konstantin Triger hdordinal.patch Description: hdordinal.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch
Hello,
Attached is patch to add 2.0 overload of Configure method in
System.Runtime.Remoting.RemotingConfiguration. This was done the same way as
System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel.
Thanks,
Jonathan
Index: System.Runtime.Remoting/RemotingConfiguration.cs
===
--- System.Runtime.Remoting/RemotingConfiguration.cs (revision 76569)
+++ System.Runtime.Remoting/RemotingConfiguration.cs (working copy)
@@ -98,20 +98,29 @@
// public methods
- public static void Configure (string filename)
+#if NET_2_0
+ [MonoTODO (Implement ensureSecurity)]
+ public
+#else
+ internal
+#endif
+ static void Configure (string filename, bool ensureSecurity)
{
- lock (channelTemplates)
- {
-if (!defaultConfigRead)
-{
+ lock (channelTemplates) {
+if (!defaultConfigRead) {
ReadConfigFile (Environment.GetMachineConfigPath ());
defaultConfigRead = true;
}
-
+
if (filename != null)
ReadConfigFile (filename);
}
}
+
+ public static void Configure (string filename)
+ {
+ Configure (filename, false);
+ }
private static void ReadConfigFile (string filename)
{
Index: System.Runtime.Remoting/ChangeLog
===
--- System.Runtime.Remoting/ChangeLog (revision 76569)
+++ System.Runtime.Remoting/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2007-05-02 Jonathan Chambers [EMAIL PROTECTED]
+
+ * RemotingConfiguration.cs: Added Configure overload for 2.0
+ with MonoTODO for security.
+
2006-12-18 Lluis Sanchez Gual [EMAIL PROTECTED]
* RemotingServices.cs: FieldSetter and FieldGetter methods need
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Windows/x64
Another eglib issue in SVN head: It appears g_error has been modified to take two arguments, which unfortunately breaks mono-logger.c. Building with glib works fine. Any thoughts on how to fix this? Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Runtime.Remoting.RemotingConfiguration Configure Patch
Please commit. Thanks! Lluis. El dc 02 de 05 del 2007 a les 13:52 -0400, en/na Jonathan Chambers va escriure: Hello, Attached is patch to add 2.0 overload of Configure method in System.Runtime.Remoting.RemotingConfiguration. This was done the same way as System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Threading.Thread.ApartmentState Patch
Hello,
Here is a patch to implement Thread.ApartmentState related
methods/properties. The methods/properties behave correctly on all
platforms, but only call CoInitialize on Windows. I will also commit the
change detailed in bug 80798 before/with this patch else the error described
in the bug becomes much more frequent on windows (the change may fix bug
77075). Please review.
All changes contributed under MIT/X11 license.
Thanks,
Jonathan
Index: mono/mono/metadata/threads.c
===
--- mono/mono/metadata/threads.c (revision 76569)
+++ mono/mono/metadata/threads.c (working copy)
@@ -289,6 +289,8 @@
mono_profiler_thread_start (tid);
+ mono_thread_set_apartment_state ();
+
if(thread-start_notify!=NULL) {
/* Let the thread that called Start() know we're
* ready
@@ -384,6 +386,7 @@
thread-handle=thread_handle;
thread-tid=tid;
+ thread-apartment_state=ThreadApartmentState_Unknown;
MONO_OBJECT_SETREF (thread, synch_lock, mono_object_new (domain, mono_defaults.object_class));
@@ -2921,3 +2924,22 @@
{
return thread_interruption_requested;
}
+
+void mono_thread_set_apartment_state ()
+{
+ MonoThread* thread;
+ thread = mono_thread_current ();
+
+ if (thread-apartment_state == ThreadApartmentState_STA) {
+#ifdef PLATFORM_WIN32
+ CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
+#endif
+ }
+ else {
+#ifdef PLATFORM_WIN32
+ CoInitializeEx(NULL, COINIT_MULTITHREADED);
+#endif
+ /* Set explicitly since state might have been Unknown */
+ thread-apartment_state = ThreadApartmentState_MTA;
+ }
+}
Index: mono/mono/metadata/object.c
===
--- mono/mono/metadata/object.c (revision 76569)
+++ mono/mono/metadata/object.c (working copy)
@@ -2387,6 +2387,7 @@
MonoDomain *domain;
gpointer pa [1];
int rval;
+ MonoCustomAttrInfo* cinfo;
g_assert (args);
@@ -2406,6 +2407,22 @@
g_free (str);
}
+ cinfo = mono_custom_attrs_from_method (method);
+ if (cinfo) {
+ static MonoClass *stathread_attribute = NULL;
+ MonoThread* thread = mono_thread_current ();
+ MonoObject* stathread_object;
+ if (!stathread_attribute)
+ stathread_attribute = mono_class_from_name (mono_defaults.corlib, System, STAThreadAttribute);
+ mono_custom_attrs_get_attr (cinfo, stathread_attribute);
+ stathread_object = mono_custom_attrs_get_attr (cinfo, stathread_attribute);
+ if (!cinfo-cached)
+ mono_custom_attrs_free (cinfo);
+
+ thread-apartment_state = stathread_object ? ThreadApartmentState_STA : ThreadApartmentState_MTA;
+ mono_thread_set_apartment_state ();
+ }
+
/* FIXME: check signature of method */
if (mono_method_signature (method)-ret-type == MONO_TYPE_I4) {
MonoObject *res;
Index: mono/mono/metadata/object-internals.h
===
--- mono/mono/metadata/object-internals.h (revision 76569)
+++ mono/mono/metadata/object-internals.h (working copy)
@@ -274,7 +274,7 @@
MonoBoolean thread_dump_requested;
gpointer end_stack; /* This is only used when running in the debugger. */
MonoBoolean thread_interrupt_requested;
- gpointer unused4;
+ guint32 apartment_state;
gpointer unused5;
gpointer unused6;
gpointer unused7;
Index: mono/mono/metadata/threads-types.h
===
--- mono/mono/metadata/threads-types.h (revision 76569)
+++ mono/mono/metadata/threads-types.h (working copy)
@@ -29,8 +29,15 @@
ThreadState_Suspended = 0x0040,
ThreadState_AbortRequested = 0x0080,
ThreadState_Aborted = 0x0100
-} MonoThreadState;
+} MonoThreadState;
+/* This is a copy of System.Threading.ApartmentState */
+typedef enum {
+ ThreadApartmentState_STA = 0x,
+ ThreadApartmentState_MTA = 0x0001,
+ ThreadApartmentState_Unknown = 0x0002
+} MonoThreadApartmentState;
+
#define SPECIAL_STATIC_NONE 0
#define SPECIAL_STATIC_THREAD 1
#define SPECIAL_STATIC_CONTEXT 2
@@ -122,4 +129,6 @@
void mono_thread_free_local_slot_values (int slot, MonoBoolean thread_local) MONO_INTERNAL;
extern void mono_thread_current_check_pending_interrupt (void) MONO_INTERNAL;
+extern void mono_thread_set_apartment_state () MONO_INTERNAL;
+
#endif /* _MONO_METADATA_THREADS_TYPES_H_ */
Index: mcs/class/corlib/System.Threading/Thread.cs
===
--- mcs/class/corlib/System.Threading/Thread.cs (revision 76569)
+++ mcs/class/corlib/System.Threading/Thread.cs (working copy)
@@ -95,14 +95,14 @@
private IntPtr serialized_ui_culture_info;
private int serialized_ui_culture_info_len;
private ExecutionContext _ec;
+ private bool thread_dump_requested;
+ private IntPtr end_stack;
+ private bool thread_interrupt_requested;
+ private ApartmentState apartment_state = ApartmentState.Unknown;
/*
* These fields are used to avoid having to increment corlib versions
* when a new field
Re: [Mono-dev] Mono on Windows/x64
Another eglib issue in SVN head: It appears g_error has been modified [...] which unfortunately breaks mono-logger.c. Building with glib works fine. Any thoughts on how to fix this? http://bugzilla.ximian.com/show_bug.cgi?id=81520 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Threading.Thread.ApartmentState Patch
Jonathan, Does this mean we can enable the fix for bug #78455, and remove the extra check in WaitHandle.IsSTAThread ? Gert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Chambers Sent: woensdag 2 mei 2007 21:58 To: mono-devel Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch Hello, Here is a patch to implement Thread.ApartmentState related methods/properties. The methods/properties behave correctly on all platforms, but only call CoInitialize on Windows. I will also commit the change detailed in bug 80798 before/with this patch else the error described in the bug becomes much more frequent on windows (the change may fix bug 77075). Please review. All changes contributed under MIT/X11 license. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Threading.Thread.ApartmentState Patch
Gert, Yes, with this patch you should be able to just check Thread.CurrentThread.ApartmentState. Jonathan On 5/2/07, Gert Driesen [EMAIL PROTECTED] wrote: Jonathan, Does this mean we can enable the fix for bug #78455, and remove the extra check in WaitHandle.IsSTAThread ? Gert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Chambers Sent: woensdag 2 mei 2007 21:58 To: mono-devel Subject: [Mono-dev] System.Threading.Thread.ApartmentState Patch Hello, Here is a patch to implement Thread.ApartmentState related methods/properties. The methods/properties behave correctly on all platforms, but only call CoInitialize on Windows. I will also commit the change detailed in bug 80798 before/with this patch else the error described in the bug becomes much more frequent on windows (the change may fix bug 77075). Please review. All changes contributed under MIT/X11 license. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Reflection: invoking an unsafe constructor/method that declares pointer parameter types
hello,
on the windows platform, building a .NET facade to a complex SDK coded
in C, i once had good reasons to use reflection in order to invoke an
unsafe constructor that takes a void* parameter:
public unsafe class SomeClass
{
public SomeClass(void* handle)
{
this.handle = handle;
}
private void* handle;
}
public static void Main(string[] args)
{
ConstructorInfo constructor =
SomeClass.GetConstructor(BindingFlags.Instance|BindingFlags.ExactBinding,null,new
Type[]{typeof(void*)},null);
SomeClass instance = constructor.Invoke(new Object[]{(IntPtr)0});
}
to achieve that, as you can see, i used to use the IntPtr class when
creating the Object[] parameter array that has to be passed to the
ConstructorInfo::Invoke method.
now, i'm trying to achieve the same behavior in Mono: and i get an
ArgumentException because the constructor parameter's do not match;
indeed it seems that IntPtr differs too much from void*.
i know that declaring the constructor as SomeClass(IntPtr handle) would
be an acceptable workaround/solution. however, i was wondering whether
or not Mono should be able to handle such a code, since Microsoft's .NET
accepts it.
more generally, i tried to use google but did not find much information
related to using reflection to invoke unsafe methods that declare
pointers as parameters. how is it supposed to be achieved ? is this
legal ? etc ...
regards,
thanks in advance for any help.
gregory.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Sybase ASA Odbc, timestamp, fractional seconds, possible bug in mono Odbc stack?
mandag 30 april 2007 13:23 skrev Mads Bondo Dydensborg: tirsdag 24 april 2007 08:36 skrev Mads Bondo Dydensborg: Hi there Hi again. Just a repost - does nobody know anything about these issues? And another one :-) Is there a person doing the ODBC work, that I should talk directly to? Regards, Mads Regards, Mads I am using Linux/Mono to access a Sybase ASA server (on Windows), using Unixodbc (and possibly FreeTDS - I am actually not quite sure). Most things appear to work fine, however, when retrieving DateTimes/Timestamps from the sybase server, it seems that it returns the fractional value of a second, as _billonths_ of a second. Mono appears to expect this in milliseconds: ENTER: System.DateTime:.ctor (int,int,int,int,int,int,int) (value:0xbf8b53b0, 2007, 4 , 17, 14, 10, 50, 34000, ) . ENTER: System.DateTime:DaysInMonth (int,int)(2007, 4, ) . . ENTER: System.DateTime:IsLeapYear (int)(2007, ) . . LEAVE: System.DateTime:IsLeapYear (int)FALSE . LEAVE: System.DateTime:DaysInMonth (int,int)result=30 EXCEPTION handling: ArgumentOutOfRangeException The value 34000 should be in milliseconds (says DateTime constructor), but apperantly is in billionths of a second (nanoseconds, says ODBC). Looking at OdbcDataReader.GetValue, I find the following code: case OdbcType.Timestamp: case OdbcType.DateTime: case OdbcType.Date: case OdbcType.Time: OdbcTimestamp ts_data = new OdbcTimestamp(); ret = libodbc.SQLGetData (hstmt, ColIndex, col.SqlCType, ref ts_data, 0, ref outsize); if (outsize!=-1) // This means SQL_NULL_DATA DataValue = new DateTime(ts_data.year,ts_data.month,ts_data.day,ts_data.hour, ts_data.minute,ts_data.second,Convert.ToInt32(ts_data.fraction)); break; OdbcTimestamp.fraction is declared as a long. SQLGetData is an extern method - looks like it is just supposed to fill in the binary values? I find it a bit puzzling, perhaps even suspiciuos, that ts_data.fraction is converted to an int 32 from a long in the call to DateTime - disregarding (perhaps?) the scale of the fraction? I am a bit confused about this. Before looking into it further, I would appreciate a comment on wheter this could potentially be a bug in the Mono ODBC stack? Also, where values are set, that is, if wanting to update a timestamp from mono - where the conversion takes place (there are quite many Odbc related files :-). The same code runs without problems under Windows/MS. Of course, that is not to say it is correct, only that the data returned is as expected. Regards, Mads -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Med venlig hilsen/Regards Systemudvikler/Systemsdeveloper cand.scient.dat, Ph.d., Mads Bondo Dydensborg Dansk BiblioteksCenter A/S, Tempovej 7-11, 2750 Ballerup, Tlf. +45 44 86 77 34 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
