[Mono-dev] my web page cann't access oracle.
My error message as follows: System.DllNotFoundException: clntsh in (wrapper managed-to-native) OciNativeCalls:OCIEnvCreate (intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,intptr,intptr,int,intptr) in 0x0001f System.Data.OracleClient.Oci.OciCalls:OCIEnvCreate (System.IntPtr envhpp, OciEnvironmentMode mode, IntPtr ctxp, IntPtr malocfp, IntPtr ralocfp, IntPtr mfreep, Int32 xtramem_sz, IntPtr usrmempp) in 0x0003c System.Data.OracleClient.Oci.OciEnvironmentHandle:.ctor (OciEnvironmentMode mode) in 0x0006b System.Data.OracleClient.Oci.OciGlue:CreateConnection (OracleConnectionInfo conInfo) in 0x00049 System.Data.OracleClient.OracleConnectionPoolManager:CreateConnection (OracleConnectionInfo info) in 0x0003f System.Data.OracleClient.OracleConnectionPool:CreateConnection () in 0x0010a System.Data.OracleClient.OracleConnectionPool:GetConnection () in 0x000e3 System.Data.OracleClient.OracleConnection:Open () in (wrapper remoting-invoke-with-check) System.Data.OracleClient.OracleConnection:Open () in 0x000e2 SiteView.ServerPage.ExecSql:Button1_Click (System.Object sender, System.EventArgs e) my OS is Redhat Enterprise AS4 and database is 10201_database_linux32 Apache and mono information as follows httpd-2.0.55.tar.gz mono-1.1.13.2.tar.gz mod_mono-1.1.13.tar.gz xsp-1.1.13.tar.gz == 263电子邮件－信赖邮自专业___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoVTable undefined
Hi all, sorry if this is obvious, but it isn't for me The mono/metadata/object.h header file has two convenient macros that i'd like to use #define mono_object_class(obj) (((MonoObject*)(obj))-vtable-klass) #define mono_object_domain(obj) (((MonoObject*)(obj))-vtable-domain) Unfortunately ((MonoObject*)(obj))-vtable points to a MonoVTable structure which is undefined in the public headers. It is actually defined in the class-internals.h header, which is obviously internal. How would i get the class from an object, other than hackily using the knowledge that klass is the first data member of the undefined vtable? best greetings, Thomas -- Thomas Grill http://g.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: MonoVTable undefined
Thomas Grill wrote: Hi all, sorry if this is obvious, but it isn't for me The mono/metadata/object.h header file has two convenient macros that i'd like to use #define mono_object_class(obj) (((MonoObject*)(obj))-vtable-klass) #define mono_object_domain(obj) (((MonoObject*)(obj))-vtable-domain) Unfortunately ((MonoObject*)(obj))-vtable points to a MonoVTable structure which is undefined in the public headers. It is actually defined in the class-internals.h header, which is obviously internal. How would i get the class from an object, other than hackily using the knowledge that klass is the first data member of the undefined vtable? metadata/object.h: mono_object_get_class () mono_object_get_domain () Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MonoVTable undefined
oops, sorry for the noise - there's still MonoDomain* mono_object_get_domain (MonoObject *obj); MonoClass* mono_object_get_class (MonoObject *obj); all the best, Thomas Thomas Grill schrieb: Hi all, sorry if this is obvious, but it isn't for me The mono/metadata/object.h header file has two convenient macros that i'd like to use #define mono_object_class(obj) (((MonoObject*)(obj))-vtable-klass) #define mono_object_domain(obj) (((MonoObject*)(obj))-vtable-domain) Unfortunately ((MonoObject*)(obj))-vtable points to a MonoVTable structure which is undefined in the public headers. It is actually defined in the class-internals.h header, which is obviously internal. How would i get the class from an object, other than hackily using the knowledge that klass is the first data member of the undefined vtable? best greetings, Thomas -- Thomas Grill http://g.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] my web page cann't access oracle.
System.Data.OracleClient uses OCI library. On Linux, this would be something like libclntsh.soIt may even have a version number in the shared library name, for example, libclntsh.so.10.0You need to make sure this library can be found in your PATH. (or LD_LIBRARY_PATH). Basically, its however shared libraries are normally found on Linux (anyone feel free to jump in and correct me).Make sure your ORACLE_HOME is set.I do not have Linux in front of me right now to answer your question fully. zhulijun [EMAIL PROTECTED] wrote: My error message as follows:System.DllNotFoundException: clntsh in (wrapper managed-to-native) OciNativeCalls:OCIEnvCreate (intptr,System.Data.OracleClient.Oci.OciEnvironmentMode,intptr,intptr,intptr,intptr,int,intptr) in 0x0001f System.Data.OracleClient.Oci.OciCalls:OCIEnvCreate (System.IntPtr envhpp, OciEnvironmentMode mode, IntPtr ctxp, IntPtr malocfp, IntPtr ralocfp, IntPtr mfreep, Int32 xtramem_sz, IntPtr usrmempp) in 0x0003c System.Data.OracleClient.Oci.OciEnvironmentHandle:.ctor (OciEnvironmentMode mode) in 0x0006b System.Data.OracleClient.Oci.OciGlue:CreateConnection (OracleConnectionInfo conInfo) in 0x00049 System.Data.OracleClient.OracleConnectionPoolManager:CreateConnection (OracleConnectionInfo info) in 0x0003f System.Data.OracleClient.OracleConnectionPool:CreateConnection () in 0x0010a System.Data.OracleClient.OracleConnectionPool:GetConnection () in 0x000e3 System.Data.OracleClient.OracleConnection:Open () in (wrapper remoting-invoke-with-check) System.Data.OracleClient.OracleConnection:Open () in 0x000e2 SiteView.ServerPage.ExecSql:Button1_Click (System.Object sender, System.EventArgs e)my OS is Redhat Enterprise AS4and database is 10201_database_linux32Apache and mono information as followshttpd-2.0.55.tar.gzmono-1.1.13.2.tar.gzmod_mono-1.1.13.tar.gzxsp-1.1.13.tar.gz==263µç×ÓÓʼþ£ÐÅÀµÓÊ×Ôרҵ___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] New managed code for unmanaged (Win32) resourcehandling (SRE, PEAPI, MCS)
Hello Kornél, Note that SRE and PEAPI parts were not discussed yet so I am waiting comments on those parts from component owners. Well, I would prefer to use the memory solution. 1. It's faster 2. It's easier to implement, no problems with file removing, creating, locking, etc. 3. I don't believe that anyone will link more than 10 MB resource file. I think this is an important feature of my resource handling infrastructure because you can use large resources if you want. But note that FileStream provides it's own buffering over OS file cache, so you will notice no (or little) difference for resource files smaller than 4K as they are retained in memory by FileStream in fact. But note that only SRE is involved in this question as mcs does no actual resource conversion. My concern was not about speed, but about reliability. I just don't believe it is worthwhile to utilize file system when it can be done in memory. Are you sure that the filename will be unique even when you run several instances of mcs simultaneously ? 2. Please provide error tests for as many new error codes as possible. There are a lot of possible errors, but they are mapped to the same error code. BTW can I place invalid .ico and .res files in errors directory where the .cs files are? Yes, you can place there any files which you require for your test case. It's good practice to use same file name as is name of test file, just add some prefix. I prefer this method of code sharing instead of copying all the sources to every file. Please use reflection to get instance of your internal classes. I know you are using several fields, so if you really need them then a solution can be to introduce interface e.g. IResource with all required properties and methods and distribute only this interface file across. Of course, you will need some factory method to create this interface but that is the trivial part. The Resource Table generation code is included only in SRE. Also note that there are at least 7 classes (including DefaultResource that is the only one directly used by mcs) that are not included in SRE as mcs generates different default resource than SRE. And a lot of classes required by resource converter are not included in mcs as resource conversion is performed by SRE rather than mcs. I belive that it's better not to extend SRE with internal methods intended to public use if it can be achieved using public methods available in MS.NET as well. Whats the point of doing what you suggest? You are saying that all these files are not used by corlib ? --- mcs/mcs/mcs.exe.sources(revision 57534) +++ mcs/mcs/mcs.exe.sources(working copy) @@ -36,4 +36,31 @@ ../class/Mono.CompilerServices.SymbolWriter/MonoSymbolTable.cs ../class/Mono.CompilerServices.SymbolWriter/MonoSymbolWriter.cs ../class/corlib/Mono.Security.Cryptography/CryptoConvert.cs +../class/corlib/Mono.UnmanagedResources/BITMAPINFOHEADER.cs +../class/corlib/Mono.UnmanagedResources/DefaultResource.cs +../class/corlib/Mono.UnmanagedResources/IconInfoHeader.cs +../class/corlib/Mono.UnmanagedResources/ICONRESDIR.cs +../class/corlib/Mono.UnmanagedResources/NEWHEADER.cs +../class/corlib/Mono.UnmanagedResources/RESDIR.cs +../class/corlib/Mono.UnmanagedResources/ResInfo.cs +../class/corlib/Mono.UnmanagedResources/ResourceException.cs +../class/corlib/Mono.UnmanagedResources/ResourceFile.cs +../class/corlib/Mono.UnmanagedResources/RESOURCEHEADER.cs +../class/corlib/Mono.UnmanagedResources/ResourceIdentifier.cs +../class/corlib/Mono.UnmanagedResources/ResourceMemoryFlags.cs +../class/corlib/Mono.UnmanagedResources/ResourceName.cs +../class/corlib/Mono.UnmanagedResources/ResourceNode.cs +../class/corlib/Mono.UnmanagedResources/ResourceOrdinal.cs +../class/corlib/Mono.UnmanagedResources/ResourceStream.cs +../class/corlib/Mono.UnmanagedResources/ResourceTypes.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoBlock.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoBlockCollection.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoFileFlags.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoFileOSes.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoFileSubtypes.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoFileTypes.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoResource.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoString.cs +../class/corlib/Mono.UnmanagedResources/VersionInfoWordArray.cs +../class/corlib/Mono.UnmanagedResources/VS_FIXEDFILEINFO.cs +return ((languageId 16) | codePage).ToString(upperCase ? X8 : x8, CultureInfo.InvariantCulture); Please use constants instead of X8, x8 I don't really understand what you mean on using constants. I just don't know what these x8 and X8 strings are. If you declare constant with some explanatory name it will be easier to understand what they are used for. Marek ___ Mono-devel-list mailing list
[Mono-dev] [PATCH] SqliteDataReader should handle getting field type for null values
Hi!
I encountered NullReferenceException from SqliteDataReader, when I
have a query like
select a, b, NULL, c, FROM xxx
and I try to use reader.GetFieldType (2) for fetching info about
columns (actually DataAdapter from MS.NET calls this method for every
column in result)
I attach a patch (test included) for fixing this. It works great in my
app and it would be nice to have it official :)
May I commit?
--
Kamil Skalski
http://nazgul.omega.pl
Index: Mono.Data.SqliteClient/SqliteDataReader.cs
===
--- Mono.Data.SqliteClient/SqliteDataReader.cs (wersja 57661)
+++ Mono.Data.SqliteClient/SqliteDataReader.cs (kopia robocza)
@@ -368,7 +368,12 @@
int row = current_row;
if (row == -1 rows.Count == 0) return typeof(string);
if (row == -1) row = 0;
- return ((object[]) rows[row])[i].GetType();
+ object element = ((object[]) rows[row])[i];
+ if (element != null)
+return element.GetType();
+ else
+return typeof (string);
+
// Note that the return value isn't guaranteed to
// be the same as the rows are read if different
// types of information are stored in the column.
Index: Mono.Data.SqliteClient/ChangeLog
===
--- Mono.Data.SqliteClient/ChangeLog (wersja 57661)
+++ Mono.Data.SqliteClient/ChangeLog (kopia robocza)
@@ -1,3 +1,8 @@
+2006-03-07 Kamil Skalski [EMAIL PROTECTED]
+
+ * SqliteDataReader.cs: Handle null values in result as having
+ string type
+
2006-02-10 Joshua Tauberer [EMAIL PROTECTED]
* SqliteDataReader: Made 64bit clean. Patch from
Index: Test/SqliteDataReaderTest.cs
===
--- Test/SqliteDataReaderTest.cs (wersja 57661)
+++ Test/SqliteDataReaderTest.cs (kopia robocza)
@@ -75,5 +75,26 @@
}
}
}
+
+ [Test]
+ public void TypeOfNullInResultTest ()
+ {
+ _conn.ConnectionString = _connectionString;
+ SqliteDataReader reader = null;
+ using (_conn) {
+_conn.Open ();
+SqliteCommand cmd = _conn.CreateCommand ();
+cmd.CommandText = select null from test;
+reader = cmd.ExecuteReader ();
+try {
+ Assert.IsTrue (reader.Read());
+ Assert.IsNotNull (reader.GetFieldType (0));
+} finally {
+ if (reader != null !reader.IsClosed)
+ reader.Close ();
+ _conn.Close ();
+}
+ }
+ }
}
}
Index: Test/ChangeLog
===
--- Test/ChangeLog (wersja 57661)
+++ Test/ChangeLog (kopia robocza)
@@ -1,3 +1,8 @@
+2006-03-07 Kamil Skalski [EMAIL PROTECTED]
+
+ * SqliteDataReaderTest.cs: Add test for getting field type of null
+ value
+
2006-01-29 Joshua Tauberer [EMAIL PROTECTED]
* Added tests from Thomas Zoechling [EMAIL PROTECTED].
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] SqliteDataReader should handle getting field type for null values
Kamil Skalski wrote: I encountered NullReferenceException from SqliteDataReader, when I have a query like select a, b, NULL, c, FROM xxx and I try to use reader.GetFieldType (2) for fetching info about columns (actually DataAdapter from MS.NET calls this method for every column in result) I attach a patch (test included) for fixing this. It works great in my app and it would be nice to have it official :) May I commit? Please do! I'm wondering, tho, if wherever the adapter would return null, it should return a DBNull instead? Do other data adapters ever return 'null' values? -- - Joshua Tauberer http://taubz.for.net Unfortunately, we're having this discussion. It's too bad, because guess who listens to the discussion: the enemy. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] SqliteDataReader should handle getting field type for null values
Please do! Done. I'm wondering, tho, if wherever the adapter would return null, it should return a DBNull instead? Do other data adapters ever return 'null' values? Your question have a ready answer here http://bugzilla.ximian.com/show_bug.cgi?id=77535 :) So DataReader should throw an exception on null values being fetched. The proper way of dealing with it is IsDBNull method, which is used by MS.NET DataAdapter when it analyse result. GetValue () should probably just return DBNull.Value, though I didn't test this. -- - Joshua Tauberer http://taubz.for.net Unfortunately, we're having this discussion. It's too bad, because guess who listens to the discussion: the enemy. -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] got a SIGSEGV
running mono 1.1.10.1 on gentoo 32bit on an SMP kernel 2.6.15 got the following error, ideas? = Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Stacktrace: in 0x4 (wrapper managed-to-native) System.String:InternalAllocateStr (int) in 0xff56 (wrapper managed-to-native) System.String:InternalAllocateStr (int) in 0x7e System.Text.StringBuilder:InternalEnsureCapacity (int) in 0x28 System.Text.StringBuilder:Append (char) in 0x31b System.Xml.XmlTextReader:ReadAttributeValueTokens (int) in 0xcb System.Xml.XmlTextReader:ReadAttributes (bool) in 0x128 System.Xml.XmlTextReader:ReadStartTag () in 0x14b System.Xml.XmlTextReader:ReadContent () in 0x179 System.Xml.XmlTextReader:ReadContent () in 0x115 System.Xml.XmlTextReader:Read () in 0x27 System.Xml.XmlReader:ReadStartElement () in 0x215 System.Runtime.Serialization.Formatters.Soap.SoapReader:Deserialize (System.IO.Stream,System.Runtime.Serialization.Formatters.ISoapMessage) in 0xaa System.Runtime.Serialization.Formatters.Soap.SoapFormatter:Deserialize ( System.IO.Stream,System.Runtime.Remoting.Messaging.HeaderHandler) in 0x12 System.Runtime.Serialization.Formatters.Soap.SoapFormatter:Deserialize ( System.IO.Stream) in 0x18b System.Runtime.Remoting.Channels.SoapServerFormatterSink:ProcessMessage (System.Runtime.Remoting.Channels.IServerChannelSinkStack,System.Runtime .Remoting.Messaging.IMessage,System.Runtime.Remoting.Channels.ITransport Headers,System.IO.Stream,System.Runtime.Remoting.Messaging.IMessage,Sys tem.Runtime.Remoting.Channels.ITransportHeaders,System.IO.Stream) in 0x4e System.Runtime.Remoting.Channels.Http.HttpServerTransportSink:DispatchRe quest (System.IO.Stream,System.Runtime.Remoting.Channels.ITransportHeaders,Sys tem.IO.Stream,System.Runtime.Remoting.Channels.ITransportHeaders) in 0x45 System.Runtime.Remoting.Channels.Http.HttpServerTransportSink:ServiceReq uest (System.Runtime.Remoting.Channels.Http.RequestArguments,System.IO.Stream ,System.Runtime.Remoting.Channels.ITransportHeaders) in 0x3ff System.Runtime.Remoting.Channels.Http.HttpServer:SendRequestForChannel ( System.Runtime.Remoting.Channels.Http.RequestArguments,System.Collection s.IDictionary,System.Collections.IDictionary,byte[]) in 0x15b System.Runtime.Remoting.Channels.Http.HttpServer:ProcessRequest (System.Runtime.Remoting.Channels.Http.RequestArguments) in 0xa System.Runtime.Remoting.Channels.Http.RequestArguments:Process () in 0xff459c60 (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () in 0x168 System.Runtime.Remoting.Channels.RemotingThreadPool:PoolThread () in 0x1c948 (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () in 0x50e59787 (wrapper runtime-invoke) System.Object:runtime_invoke_void (object,intptr,intptr,intptr) Native stacktrace: mono(mono_handle_native_sigsegv+0xc0) [0x8137cb0] mono [0x8125ff6] /lib/libpthread.so.0 [0xb7ee3fd9] [0xe440] mono [0x8100e32] mono [0x80fc725] mono [0x80fc3ca] mono [0x80fd21c] mono [0x80fd41c] mono [0x80ffae0] mono [0x80ffbe0] mono [0x80ffda2] mono(mono_string_new_size+0x3e) [0x808fece] mono [0x80c552a] [0xb7636c96] [0xb7636bc7] [0xb76389d1] [0xb730b9a4] [0xb730b1f4] [0xb730c629] [0xb730895c] [0xb730898a] [0xb730870e] [0xb679cce0] [0xb62f1e36] [0xb670d953] [0xb670d89b] [0xb670cac4] [0xb670c7af] [0xb670c606] [0xb670bd60] [0xb6709c2c] [0xb6709abb] [0xb72afe28] [0xb6709a59] [0xb72afe28] [0xb72cc741] mono [0x8125ea0] mono(mono_runtime_invoke+0x27) [0x808e1e7] mono(mono_runtime_delegate_invoke+0x38) [0x808e8c8] mono [0x80b40f5] mono [0x80f3500] mono [0x8107be4] /lib/libpthread.so.0 [0xb7ede14d] /lib/libc.so.6(__clone+0x5a) [0xb7e3f05a] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] New managed code for unmanaged (Win32)resourcehandling (SRE, PEAPI, MCS)
Hi,
My concern was not about speed, but about reliability. I just don't
believe it is worthwhile
to utilize file system when it can be done in memory.
Are you sure that the filename will be unique even when you run several
instances of mcs simultaneously ?
Now I understand that we did not understand each other previously regarding
this question.:) I was speaking about .res to resource table conversion
while you were speaking about the resource file generated by mcs.
Several moths ago I wanted to modify GetTempFileName to use a 16-bit suffix
to be fully MS.NET compatible but the result of the debate was to keep the
32-bit one as Linux has a single temp directory while Windows has per-user
temp directories so a 16-bit suffix were possiblie insufficient while a
32-bit is likely to be enough. So I belive that mcs can obtain a unique file
name. If not I think it is GetTempFileName that should be modified.
I prefer using temporary resource files because this way we don't need
non-public Mono-only functionality in SRE as we can use the public
DefineUnmanagedResource method. I think that it's reliable.
Yes, you can place there any files which you require for your test case.
It's good practice to use same file name as is name of test file, just
add some prefix.
OK. Is it OK if I upload some tests for these expected error codes to SVN
before they are available in mcs?
You are saying that all these files are not used by corlib ?
... (file names)
Please have a look at the modified corlib.dll.sources, PEAPI.dll.sources and
mcs.exe.sources and you will see what files are needed by these assemblies.
There are no unnecessary classes included in any of these lists so you can
compare them.
There are some basic, infrastructural classes like ResourceNode and
ResourceStream that are common. PEAPI only uses .res to resource table
conversion classes. mcs only uses .res generation classes with version info
and icon support. SRE is the most compilcated it can convert .res to
resource table and generate version info resource but that version info
resource is a bit different than the one that is generated by mcs. So SRE
has no icon support that means that mcs uses about 7 files that are not used
by SRE. And of course a lot of files used by SRE are not required by mcs
that are about 14 files.
Note that unlike mcs that has a lot of classes in a single file I followed
one class per source file desing in Mono.UnmanagedResources this is why
there are so many source files.
I just don't know what these x8 and X8 strings are. If you declare
constant with some explanatory name
it will be easier to understand what they are used for.
These are standard numeric format strings so I don't think they should be
documented or explained using constants. x8 is the number in hexadecimal
with 8 digits at least (zero padded) in lower case. X8 is the same in upper
case.
As these format strings are passed directly to int.ToString() it isn't
cryptic. I belive that these format strings are self-explanatory. I think
providing some explanation is like providing explanation for {0}in
string.Format(some {0} inserted, text).
For more information please refer to
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconstandardnumericformatstrings.asp
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: [Mono-patches] r57679 - in trunk/mcs/class/corlib: System System.Globalization
I love the BIG FAT WARNING. Maybe should of used an ascii art bomb like this one to REALLY get the point across. ,--.!, __/ -*- ,d08b. '|` 0088MM `9MMP' -- Zac Bowling http://zacbowling.com/ - Message from [EMAIL PROTECTED] - Date: Tue, 7 Mar 2006 18:30:00 -0500 (EST) From: Peter Bartok ([EMAIL PROTECTED]) [EMAIL PROTECTED] Reply-To: Peter Bartok ([EMAIL PROTECTED]) [EMAIL PROTECTED] Subject: [Mono-patches] r57679 - in trunk/mcs/class/corlib: System System.Globalization To: mono-patches@lists.ximian.com, [EMAIL PROTECTED], [EMAIL PROTECTED] Author: pbartok Date: 2006-03-07 18:29:59 -0500 (Tue, 07 Mar 2006) New Revision: 57679 Modified: trunk/mcs/class/corlib/System.Globalization/ChangeLog trunk/mcs/class/corlib/System.Globalization/DateTimeFormatInfo.cs trunk/mcs/class/corlib/System/ChangeLog trunk/mcs/class/corlib/System/Environment.cs Log: 2006-03-07 Peter Dennis Bartok [EMAIL PROTECTED] * Environment.cs: Bumped corlib version to 48 (due to r57532) 2006-03-07 Peter Dennis Bartok [EMAIL PROTECTED] * DateTimeFormatInfo.cs: Restored original field order to allow some automatic locale fu to happen (mono unmanaged code relies on the field order to fill out DateTimeFormatInfo) Modified: trunk/mcs/class/corlib/System/ChangeLog === --- trunk/mcs/class/corlib/System/ChangeLog 2006-03-07 23:29:14 UTC (rev 57678) +++ trunk/mcs/class/corlib/System/ChangeLog 2006-03-07 23:29:59 UTC (rev 57679) @@ -1,3 +1,7 @@ +2006-03-07 Peter Dennis Bartok [EMAIL PROTECTED] + + * Environment.cs: Bumped corlib version to 48 (due to r57532) + 2006-03-07 Martin Baulig [EMAIL PROTECTED] * String.cs (String.FormatHelper): Try getting an `ICustomFormatter' Modified: trunk/mcs/class/corlib/System/Environment.cs === --- trunk/mcs/class/corlib/System/Environment.cs 2006-03-07 23:29:14 UTC (rev 57678) +++ trunk/mcs/class/corlib/System/Environment.cs 2006-03-07 23:29:59 UTC (rev 57679) @@ -59,7 +59,7 @@ * Changes which are already detected at runtime, like the addition * of icalls, do not require an increment. */ - private const int mono_corlib_version = 47; + private const int mono_corlib_version = 48; [MonoTODO] public enum SpecialFolder Modified: trunk/mcs/class/corlib/System.Globalization/ChangeLog === --- trunk/mcs/class/corlib/System.Globalization/ChangeLog 2006-03-07 23:29:14 UTC (rev 57678) +++ trunk/mcs/class/corlib/System.Globalization/ChangeLog 2006-03-07 23:29:59 UTC (rev 57679) @@ -1,3 +1,9 @@ +2006-03-07 Peter Dennis Bartok [EMAIL PROTECTED] + + * DateTimeFormatInfo.cs: Restored original field order to allow + some automatic locale fu to happen (mono unmanaged code relies + on the field order to fill out DateTimeFormatInfo) + 2006-03-02 Peter Dennis Bartok [EMAIL PROTECTED] * DateTimeFormatInfo.cs: Switched (where possible) our internal Modified: trunk/mcs/class/corlib/System.Globalization/DateTimeFormatInfo.cs === --- trunk/mcs/class/corlib/System.Globalization/DateTimeFormatInfo.cs 2006-03-07 23:29:14 UTC (rev 57678) +++ trunk/mcs/class/corlib/System.Globalization/DateTimeFormatInfo.cs 2006-03-07 23:29:59 UTC (rev 57679) @@ -53,6 +53,14 @@ private static DateTimeFormatInfo theInvariantDateTimeFormatInfo; + // + // BIG FAT WARNING: + // + // DO NOT ALTER THE NAME OR ORDER OF THESE FIELDS + // AND DO NOT INSERT ANY VARIABLES ANYWHERE BUT AT THE END + // SINCE MONO RELIES ON THE ORDER AND ON THE NAMES + // see mono/mono/metadata/verify.c + // private bool m_isReadOnly; private string amDesignator; private string pmDesignator; @@ -76,6 +84,18 @@ private string[] monthNames; private string[] abbreviatedMonthNames; + // FIXME: not supported other than invariant + private string [] allShortDatePatterns; + private string [] allLongDatePatterns; + private string [] allShortTimePatterns; + private string [] allLongTimePatterns; + private string [] monthDayPatterns; + private string [] yearMonthPatterns; + + // + // END OF BIG FAT WARNING + // + // MS Serialization needs this private int nDataItem; private bool m_useUserOverride; @@ -90,14 +110,6 @@ private string[] m_dateWords;
Re: [Mono-list] can't inport project from visual studio 2005 to monodevelop
Dnia 06-03-2006, pon o godzinie 22:16 -0500, William Huskey napisał(a): If this is the wrong list please let me know.. I have been porting from visual studio 2003 .net will little to no problems.. but my hsop just upgraded to visual studio 2005 and when I try to inport project I get Importing solution Importing project: /home/huskeyw/Calc/Calc/Calc.csproj ERROR: Could not import project:/home/huskeyw/Calc/Calc/Calc.csproj. Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj if I just try the Calc.csproj file I get Exception occurred: Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj System.IO.IOException: Sharing violation on path /home/huskeyw/Calc/Calc/Calc.csproj in 0x00338 System.IO.FileStream:.ctor (System.String name, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean isAsync, Boolean anonymous) in 0x00053 System.IO.FileStream:.ctor (System.String name, FileMode mode) in (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode) in 0x00127 MonoDevelop.Prj2Make.SlnMaker:CreatePrjxFromCsproj (System.String csprojFileName, IProgressMonitor monitor) I am not sure what this is.. nothing is using these files.. have even rebooted and moved, made copys.. Ive chmoded 777 on them and the directorys.. Thanks That's an unimplemented feature. VS 2005 uses different project file format. Prj2Make needs to be updated and we need rewrite of Microsoft.Build.* assemblies. I'm doing actually the second part. I don't see any chances to finish that before May. (Maybe if someone else help me and if I get lots of free time) -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] can't inport project from visual studio 2005 to monodevelop
Marek Sieradzki wrote: Dnia 06-03-2006, pon o godzinie 22:16 -0500, William Huskey napisał(a): If this is the wrong list please let me know.. I have been porting from visual studio 2003 .net will little to no problems.. but my hsop just upgraded to visual studio 2005 and when I try to inport project I get Importing solution That's an unimplemented feature. VS 2005 uses different project file format. Prj2Make needs to be updated and we need rewrite of Microsoft.Build.* assemblies. I'm doing actually the second part. I don't see any chances to finish that before May. (Maybe if someone else help me and if I get lots of free time) I just did a blog entry yesterday where I allude to an update of prj2make so that it may begin supporting VS 2005 C# projects. :) http://www.mfconsulting.com/blog/archives/000125.html Paco ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Most compatible O/RM framework for Mono?
Hello everyone, I'm currently working on a project and I want to support mono. I'm currently investigating different OR/M packages out there, NHibernate, Gentle.NET, NEO Framework, etc., and I am wondering about the support any of these have for mono. Can anyone shed any light on which of these they've had the best success with? Also, what about mono implementations of some ms projects, like their Data Access Application Block (which I know virtually nothing about at this point) thanks! --ben ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Newbie question: .Net 2.0 vs Mono compatibility
Hi, I'm newbie in Mono and ASP.NET. I'd like to know if I can run my Visual Web Developer 2005 .NET webpage without modifications under Mono and Apache? Does Mono contain the same visual components like .net 2.0? E.g. I use menu and bread crumbs components, and html elements with runat=server attribute. I use c# for scripting and postgres as an rdbms. I know that there is a mod_mono module for Apache. What else I have to do in order to make it work? Thank you very much, -- Csaba Együd -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 2006.03.06. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.2.0/275 - Release Date: 2006.03.06. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] A couple of SWF questions
Hi,
The code attached works fine with Mono. VC# moans like crazy and I'm not
sure why - comments would be welcome.
The code also has 2 problems. The first is that then Address label
doesn't appear and it should (could someone confirm this so that I can
file it in Bugzilla) and the second is the KeyPress event for the
NumberBox is being ignored (from what I can see). Again, if someone can
confirm this, I'd appreciate it.
The code compiles without a hitch under Mono 1.1.13. I'm using the
Fedora Core RPMs over the build from source (don't ask).
Sorry about the length...
using System.Windows.Forms;
using System.ComponentModel;
using System.Collections;
using System.Drawing;
public class testwindow : Form
{
private Label ServerAddress;
private Label Address;
private Label User;
private Label Pass;
private Button Connect;
private TextBox Username;
private TextBox Password;
private ComboBox IPAddress;
private NumberBox[] IP;
private GroupBox box;
private StatusBar StateBar;
private ProgressBar Progress;
private Label Connection;
private System.ComponentModel.Container components = null;
private testwindow()
{
InitializeComponent();
}
protected override void Dispose(bool disposing)
{
if (disposing)
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose(disposing);
}
private void InitializeComponent()
{
this.SuspendLayout();
this.Size = new Size(300, 150);
this.Text = Server connection;
this.ServerAddress = new Label();
this.ServerAddress.Size = new Size(72, 12);
this.ServerAddress.Name = address;
this.ServerAddress.Text = Server Address;
this.ServerAddress.Location = new Point(11, 14);
this.ServerAddress.TabIndex = 0;
this.IPAddress = new ComboBox();
this.IPAddress.DropDownStyle = ComboBoxStyle.DropDownList;
this.IPAddress.BackColor = Color.White;
this.IPAddress.ForeColor = Color.Black;
this.IPAddress.Size = new Size(160, 8);
this.IPAddress.Name = ipaddress;
this.IPAddress.Location = new Point(100, 12);
this.IPAddress.Items.Add(Localhost);
this.IPAddress.Items.Add(Other);
this.IPAddress.SelectedIndex = 0;
this.IPAddress.SelectedIndexChanged += new
System.EventHandler(this.IPAddress_SelectedIndexChanged);
this.IPAddress.TabIndex = 1;
this.Address = new Label();
this.Address.Size = new Size (72, 12);
this.Address.Name = numaddr;
this.Address.Text = IP Address;
this.Address.Enabled = false;
this.Address.Location = new Point(11, 36);
this.Address.TabIndex = 2;
this.IP = new NumberBox[4];
for (int i = 0; i 4; ++i)
{
this.IP[i] = new NumberBox();
this.IP[i].Size = new Size(44, 8);
this.IP[i].Enabled = false;
this.IP[i].Location = new Point(100 + (48 * i), 34);
this.IP[i].TabIndex = 3 + i;
this.IP[i].MaxLength = 3;
}
this.User = new Label();
this.User.Size = new Size(54, 12);
this.User.Name = user;
this.User.Text = Username;
this.User.Location = new Point(11, 64);
this.User.TabIndex = 7;
this.Username = new TextBox();
this.Username.Size = new Size(80, 8);
this.Username.Name = username;
this.Username.Location = new Point(70, 62);
this.Username.TextChanged += new
System.EventHandler(this.Username_TextChanged);
this.Username.TabIndex = 8;
this.Pass = new Label();
this.Pass.Size = new Size(48, 12);
this.Pass.Name = pass;
this.Pass.Text = Password;
this.Pass.Location = new Point(150, 64);
this.Pass.TabIndex = 9;
this.Password = new TextBox();
this.Password.Size = new Size(80, 12);
this.Password.Name = password;
this.Password.PasswordChar = (char)'*';
this.Password.Location = new Point (200, 62);
this.Password.TextChanged += new
System.EventHandler(this.Password_TextChanged);
this.Password.TabIndex = 10;
this.box = new GroupBox();
this.box.SuspendLayout();
this.box.Controls.AddRange(new Control[]
{this.ServerAddress, this.IPAddress, this.Address, this.IP[0],
this.IP[1], this.IP[2], this.IP[3], this.User, this.Username,
this.Pass, this.Password});
this.box.Location = new Point(8, 4);
this.box.Name = groupbox;
this.box.Size = new Size(290, 86);
this.box.Text = Connection details;
this.box.TabIndex = 11;
this.Connect = new Button();
this.Connect.Size = new Size(70, 20);
this.Connect.Name = connect;
this.Connect.Enabled = false;
this.Connect.Text = Connect;
this.Connect.Location = new Point (200, 100);
this.Connect.Click += new System.EventHandler(this.Connect_Click);
this.Connect.TabIndex = 12;
this.StateBar = new StatusBar();
this.StateBar.Location = new Point(0, 130);
this.StateBar.Height = 20;
this.StateBar.Name = status;
this.StateBar.ForeColor = Color.Blue;
this.StateBar.Text = Disconnected;
this.StateBar.TabIndex = 13;
[Mono-list] Re: Most compatible O/RM framework for Mono?
Ben Joldersma wrote: Can anyone shed any light on which of these they've had the best success with? Also, what about mono implementations of some ms projects, like their Data Access Application Block (which I know virtually nothing about at this point) The Data Access Application Block won't work from scratch because it consumes a lot of Windows specific stuff (Performance Counters, Event Log, etc.), but can be easily ported. However, you might run into some license issues, so please check MS' license before doing that. I found the DAAB, besides its integration with other application blocks, quite limited compared to Mono's own small Mono.Data provider and runtime independent DB layer. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Moving from Mono/C# from C/Linux world
Ive been evaluating Mono/C# for a few weeks now and am generally impressed by what I see. My group works currently in the C/Linux world where we develop near real-time scientific application software. Im looking at C#/Mono because: a) Another group at our company uses C# / Windows and they rave about it. b) Id like to bring get my group using something more modern then C. c) It would be nice if the two groups use the same development language to encourage code reuse. I have two questions. The first is what are there any things I need to worry about that would be difficult to do in the Mono/C# world that are fairly easy and standard in the C world? Note we have a distributed environment where most of the programs are fairly small. The programs typically perform a specific function (e.g. ingest the data, or run an algorithm on it) and then pass it on to the next program. Data is passed in a number of ways, but mainly through file sharing and pipes. We often use shell scripts to control the flow of data and the programs to do the actual work. In addition, we have fair number of existing C functions that I wish not to duplicate (at least not initially) but I believe I can incorporate them using SWIG. Secondly, Im slightly concerned that at some point down the road (say 3 5 years) Mono, for whatever reason, will no longer be supported. From what Ive seen so far, Mono is a solid project with a strong following of core programmers supporting it and I see no reason why it might fade away. But I dont have a good feel for how many people are using it and if that number is growing from year to year or if it has started to stagnate, i.e. has Mono hit critical mass? Any feedback to either question would be most appreciated. Steve ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] A couple of SWF questions
Paul,Your program seems to work fine in VisualStudio 2005. Address label appears but is truncated because the size you set is too short (90 rather than 72 displays it all).KeyPress is being entered.
I hope this is helpfull but probably not.BrianOn 3/7/06, Paul F. Johnson [EMAIL PROTECTED]
wrote:Hi,The code attached works fine with Mono. VC# moans like crazy and I'm not
sure why - comments would be welcome.The code also has 2 problems. The first is that then Address labeldoesn't appear and it should (could someone confirm this so that I canfile it in Bugzilla) and the second is the KeyPress event for the
NumberBox is being ignored (from what I can see). Again, if someone canconfirm this, I'd appreciate it.The code compiles without a hitch under Mono 1.1.13. I'm using theFedora Core RPMs over the build from source (don't ask).
Sorry about the length...using System.Windows.Forms;using System.ComponentModel;using System.Collections;using System.Drawing;public class testwindow : Form{private Label ServerAddress;
private Label Address;private Label User;private Label Pass;private Button Connect;private TextBox Username;private TextBox Password;private ComboBox IPAddress;private NumberBox[] IP;
private GroupBox box;private StatusBar StateBar;private ProgressBar Progress;private Label Connection;private System.ComponentModel.Container components = null;private testwindow()
{InitializeComponent();}protected override void Dispose(bool disposing){if (disposing){if (components != null){components.Dispose();}
}base.Dispose(disposing);}private void InitializeComponent(){this.SuspendLayout();this.Size = new Size(300, 150);this.Text = Server connection;
this.ServerAddress = new Label();this.ServerAddress.Size = new Size(72, 12);this.ServerAddress.Name = address;this.ServerAddress.Text
= Server Address;this.ServerAddress.Location = new Point(11, 14);this.ServerAddress.TabIndex = 0;this.IPAddress = new ComboBox();this.IPAddress.DropDownStyle = ComboBoxStyle.DropDownList
;this.IPAddress.BackColor = Color.White;this.IPAddress.ForeColor = Color.Black;this.IPAddress.Size = new Size(160, 8);this.IPAddress.Name = ipaddress;
this.IPAddress.Location = new Point(100, 12);this.IPAddress.Items.Add(Localhost);this.IPAddress.Items.Add(Other);this.IPAddress.SelectedIndex = 0;this.IPAddress.SelectedIndexChanged
+= newSystem.EventHandler(this.IPAddress_SelectedIndexChanged);this.IPAddress.TabIndex = 1;this.Address = new Label();this.Address.Size = new Size (72, 12);
this.Address.Name = numaddr;this.Address.Text = IP Address;this.Address.Enabled = false;this.Address.Location = new Point(11, 36);this.Address.TabIndex = 2;
this.IP = new NumberBox[4];for (int i = 0; i 4; ++i){this.IP[i] = new NumberBox();this.IP[i].Size = new Size(44, 8);this.IP[i].Enabled = false;this.IP[i].Location = new Point(100 + (48 * i), 34);
this.IP[i].TabIndex = 3 + i;this.IP[i].MaxLength = 3;}this.User = new Label();this.User.Size = new Size(54, 12);this.User.Name = user;
this.User.Text = Username;this.User.Location = new Point(11, 64);this.User.TabIndex = 7;this.Username = new TextBox();this.Username.Size = new Size(80, 8);
this.Username.Name = username;this.Username.Location = new Point(70, 62);this.Username.TextChanged += newSystem.EventHandler(this.Username_TextChanged);this.Username.TabIndex = 8;
this.Pass = new Label();this.Pass.Size = new Size(48, 12);this.Pass.Name = pass;this.Pass.Text = Password;this.Pass.Location
= new Point(150, 64);this.Pass.TabIndex = 9;this.Password = new TextBox();this.Password.Size = new Size(80, 12);this.Password.Name = password;
this.Password.PasswordChar = (char)'*';this.Password.Location = new Point (200, 62);this.Password.TextChanged += newSystem.EventHandler(this.Password_TextChanged);this.Password.TabIndex
= 10;this.box = new GroupBox();this.box.SuspendLayout();this.box.Controls.AddRange(new Control[]{this.ServerAddress, this.IPAddress, this.Address, this.IP[0], this.IP[1],
this.IP[2], this.IP[3], this.User, this.Username, this.Pass, this.Password});this.box.Location = new Point(8, 4);this.box.Name = groupbox;
this.box.Size = new Size(290, 86);this.box.Text = Connection details;this.box.TabIndex = 11;this.Connect = new Button();this.Connect.Size = new Size(70, 20);
this.Connect.Name = connect;this.Connect.Enabled = false;this.Connect.Text = Connect;this.Connect.Location = new Point (200, 100);this.Connect.Click += new System.EventHandler
(this.Connect_Click);this.Connect.TabIndex = 12;this.StateBar = new StatusBar();this.StateBar.Location = new Point(0, 130);this.StateBar.Height = 20;
this.StateBar.Name = status;this.StateBar.ForeColor = Color.Blue;this.StateBar.Text = Disconnected;this.StateBar.TabIndex = 13;this.Connection = new Label();
this.Connection.Size = new Size(50, 12);this.Connection.Text = Progress;this.Connection.Enabled = false;this.Connection.Name = connprog;
this.Connection.Location = new Point(11, 106);this.Connection.TabIndex = 14;this.Progress = new ProgressBar();this.Progress.Location = new
Re: [Mono-list] can't inport project from visual studio 2005 to monodevelop
On 3/7/06, Francisco T. Martinez [EMAIL PROTECTED] wrote: Marek Sieradzki wrote: Dnia 06-03-2006, pon o godzinie 22:16 -0500, William Huskey napisał(a): If this is the wrong list please let me know..prj2make I have been porting from visual studio 2003 .net will little to no problems.. but my hsop just upgraded to visual studio 2005 and when I try to inport project I get Importing solution That'san unimplemented feature. VS 2005 uses different project file format. Prj2Make needs to be updated and we need rewrite of Microsoft.Build.* assemblies. I'm doing actually the second part. I don't see any chances to finish that before May. (Maybe if someone else help me and if I get lots of free time)I just did a blog entry yesterday where I allude to an update ofprj2make so that it may begin supporting VS 2005 C# projects. :) http://www.mfconsulting.com/blog/archives/000125.htmlPaco___Mono-list maillist-Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-listThanks, I'll look at prj2make , I'm a c++ and shell programer.. don't know how much help I can give, but will try.. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] A couple of SWF questions
Hi, Your program seems to work fine in VisualStudio 2005. :-) Address label appears but is truncated because the size you set is too short (90 rather than 72 displays it all). KeyPress is being entered. Dang. It looks like there is a problem with Mono and the KeyPress event. TTFN Paul -- Logic, my dear Zoe, is merely the ability to be wrong with authority - Dr Who ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Moving from Mono/C# from C/Linux world
Honey, Steve wrote: I’ve been evaluating Mono/C# for a few weeks now and am generally impressed by what I see. My group works currently in the C/Linux world where we develop near real-time scientific application software. I’m looking at C#/Mono because: a) Another group at our company uses C# / Windows and they rave about it. b) I’d like to bring get my group using something more modern then C. c) It would be nice if the two groups use the same development language to encourage code reuse. I have two questions. The first is what are there any things I need to worry about that would be difficult to do in the Mono/C# world that are fairly easy and standard in the C world? Note we have a distributed environment where most of the programs are fairly small. The programs typically perform a specific function (e.g. ingest the data, or run an algorithm on it) and then pass it on to the next program. Data is passed in a number of ways, but mainly through file sharing and pipes. We often use shell scripts to control the flow of data and the programs to do the actual work. In addition, we have fair number of existing C functions that I wish not to duplicate (at least not initially) but I believe I can incorporate them using SWIG. .Net and therefore Mono is a complete platform/framework whereas it sounds like you use the more traditional C/Unix environment of C as the language, and Unix as the platform. There's no reason you can't use the same development methodology with Mono (small apps, shell ties them together), but I think you'll be disappointed with the performance. IMHO Mono will work much better if you work toward adopting it not just as a language, but as a framework. Use remoting instead of sockets and pipes. Write larger applications, so you don't have to tie them together with shell scripts. And definitely encourage good OO programming techniques so that your entire organization can reuse code and build a common internal framework. This is just my $0.02. I'm not saying Mono won't work as a drop-in replacement for small C apps. I'm just saying thats not where its strengths lie. Secondly, I’m slightly concerned that at some point down the road (say 3 – 5 years) Mono, for whatever reason, will no longer be supported. From what I’ve seen so far, Mono is a solid project with a strong following of core programmers supporting it and I see no reason why it might fade away. But I don’t have a good feel for how many people are using it and if that number is growing from year to year or if it has started to stagnate, i.e. has Mono hit critical mass? This seems to be a pretty common fear, but I think you can be at ease about the longevity of Mono. First of all subscribing to the mono-devel list will give you a good idea of how quickly mono is progressing. Also Mono has a major corporate backer, Novell. While Novell has seen better days, they're not going away anytime soon, and they've completely committed to Linux and Mono as their platform. For the most part, the free and open source software world has accepted Mono after some trepidation. Popular databases distribute Mono specific interfaces, and many popular Java projects have been ported (such as (N)Hibernate or iText#). RedHat's Fedora distribution even includes Mono now, even though RedHat remains very committed to Java in the enterprise (vs. Mono/.Net). Also, the ECMA specifications themselves seem to be constantly improving. There were lots of exciting language and framework improves in .Net 2.0, and lots of interesting work being done for 3.0. The main area I see Mono acceptance as being slow is ISVs, and thats because they're probably using Microsoft .Net, C++, or Java as their development environment. I think as Linux continues to gain market share and the support of ISVs, you'll see more ISVs choosing .Net Mono as their cross platform development framework. However, thats largely speculation, and there's a pretty good argument for Java staying/becoming dominant in the cross platform space. -- Michael Schurter Synthesys Computer Solutions http://www.synthesyssolutions.com/ [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Moving from Mono/C# from C/Linux world
ISV adoption is going to take a while in my opinion. .NET guys are mostly windows guys, and at the moment VS.NET 2005 is considered superior to mono on MS platforms. Most *nix people that would use .NET are already Java guys, and most of them probably see little reason to switch from Java. Personally I would love to be able to use mono on *nix and therefore escape windows-land, however until mono matures some I don't think there's a good reason to use it over .NET2.0 in a production environment. That said, if I ever have a client that needs both MS and *nix support I wouldn't have any problem using mono/.net1.1 -Matt McDonald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schurter Sent: Tuesday, March 07, 2006 10:07 AM To: mono-list@lists.ximian.com Subject: Re: [Mono-list] Moving from Mono/C# from C/Linux world Honey, Steve wrote: I've been evaluating Mono/C# for a few weeks now and am generally impressed by what I see. My group works currently in the C/Linux world where we develop near real-time scientific application software. I'm looking at C#/Mono because: a) Another group at our company uses C# / Windows and they rave about it. b) I'd like to bring get my group using something more modern then C. c) It would be nice if the two groups use the same development language to encourage code reuse. I have two questions. The first is what are there any things I need to worry about that would be difficult to do in the Mono/C# world that are fairly easy and standard in the C world? Note we have a distributed environment where most of the programs are fairly small. The programs typically perform a specific function (e.g. ingest the data, or run an algorithm on it) and then pass it on to the next program. Data is passed in a number of ways, but mainly through file sharing and pipes. We often use shell scripts to control the flow of data and the programs to do the actual work. In addition, we have fair number of existing C functions that I wish not to duplicate (at least not initially) but I believe I can incorporate them using SWIG. .Net and therefore Mono is a complete platform/framework whereas it sounds like you use the more traditional C/Unix environment of C as the language, and Unix as the platform. There's no reason you can't use the same development methodology with Mono (small apps, shell ties them together), but I think you'll be disappointed with the performance. IMHO Mono will work much better if you work toward adopting it not just as a language, but as a framework. Use remoting instead of sockets and pipes. Write larger applications, so you don't have to tie them together with shell scripts. And definitely encourage good OO programming techniques so that your entire organization can reuse code and build a common internal framework. This is just my $0.02. I'm not saying Mono won't work as a drop-in replacement for small C apps. I'm just saying thats not where its strengths lie. Secondly, I'm slightly concerned that at some point down the road (say 3 - 5 years) Mono, for whatever reason, will no longer be supported. From what I've seen so far, Mono is a solid project with a strong following of core programmers supporting it and I see no reason why it might fade away. But I don't have a good feel for how many people are using it and if that number is growing from year to year or if it has started to stagnate, i.e. has Mono hit critical mass? This seems to be a pretty common fear, but I think you can be at ease about the longevity of Mono. First of all subscribing to the mono-devel list will give you a good idea of how quickly mono is progressing. Also Mono has a major corporate backer, Novell. While Novell has seen better days, they're not going away anytime soon, and they've completely committed to Linux and Mono as their platform. For the most part, the free and open source software world has accepted Mono after some trepidation. Popular databases distribute Mono specific interfaces, and many popular Java projects have been ported (such as (N)Hibernate or iText#). RedHat's Fedora distribution even includes Mono now, even though RedHat remains very committed to Java in the enterprise (vs. Mono/.Net). Also, the ECMA specifications themselves seem to be constantly improving. There were lots of exciting language and framework improves in .Net 2.0, and lots of interesting work being done for 3.0. The main area I see Mono acceptance as being slow is ISVs, and thats because they're probably using Microsoft .Net, C++, or Java as their development environment. I think as Linux continues to gain market share and the support of ISVs, you'll see more ISVs choosing .Net Mono as their cross platform development framework. However, thats largely speculation, and there's a pretty good argument for Java staying/becoming dominant in the cross
Re: [Mono-list] Moving from Mono/C# from C/Linux world
Everyone has their opinions .. I use mono in a production environment, for a med sized pizza franchise in Canada, and hopefully soon rolling out a system using mono for one of the largest pizza companies in the world. I find mono rock solid. Regardless of how solid .Net 2.0 is your still running it on a OS i.e. windows 2003 server, etc, that is a alpha/beta version of an OS at best .. so whats better a VS.Net 2005 considered superior to mono as you say (but i dont agree) on a alpha/beta OS, or Mono on a bullit proof OS i.e. Linux end result is mono on linux is going to smoke MS .Net on a MS OS each and every time. -tl On Tue, 7 Mar 2006 14:53:42 -0700 [EMAIL PROTECTED] wrote: ISV adoption is going to take a while in my opinion. .NET guys are mostly windows guys, and at the moment VS.NET 2005 is considered superior to mono on MS platforms. Most *nix people that would use .NET are already Java guys, and most of them probably see little reason to switch from Java. Personally I would love to be able to use mono on *nix and therefore escape windows-land, however until mono matures some I don't think there's a good reason to use it over .NET2.0 in a production environment. That said, if I ever have a client that needs both MS and *nix support I wouldn't have any problem using mono/.net1.1 -Matt McDonald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schurter Sent: Tuesday, March 07, 2006 10:07 AM To: mono-list@lists.ximian.com Subject: Re: [Mono-list] Moving from Mono/C# from C/Linux world Honey, Steve wrote: I've been evaluating Mono/C# for a few weeks now and am generally impressed by what I see. My group works currently in the C/Linux world where we develop near real-time scientific application software. I'm looking at C#/Mono because: a) Another group at our company uses C# / Windows and they rave about it. b) I'd like to bring get my group using something more modern then C. c) It would be nice if the two groups use the same development language to encourage code reuse. I have two questions. The first is what are there any things I need to worry about that would be difficult to do in the Mono/C# world that are fairly easy and standard in the C world? Note we have a distributed environment where most of the programs are fairly small. The programs typically perform a specific function (e.g. ingest the data, or run an algorithm on it) and then pass it on to the next program. Data is passed in a number of ways, but mainly through file sharing and pipes. We often use shell scripts to control the flow of data and the programs to do the actual work. In addition, we have fair number of existing C functions that I wish not to duplicate (at least not initially) but I believe I can incorporate them using SWIG. .Net and therefore Mono is a complete platform/framework whereas it sounds like you use the more traditional C/Unix environment of C as the language, and Unix as the platform. There's no reason you can't use the same development methodology with Mono (small apps, shell ties them together), but I think you'll be disappointed with the performance. IMHO Mono will work much better if you work toward adopting it not just as a language, but as a framework. Use remoting instead of sockets and pipes. Write larger applications, so you don't have to tie them together with shell scripts. And definitely encourage good OO programming techniques so that your entire organization can reuse code and build a common internal framework. This is just my $0.02. I'm not saying Mono won't work as a drop-in replacement for small C apps. I'm just saying thats not where its strengths lie. Secondly, I'm slightly concerned that at some point down the road (say 3 - 5 years) Mono, for whatever reason, will no longer be supported. From what I've seen so far, Mono is a solid project with a strong following of core programmers supporting it and I see no reason why it might fade away. But I don't have a good feel for how many people are using it and if that number is growing from year to year or if it has started to stagnate, i.e. has Mono hit critical mass? This seems to be a pretty common fear, but I think you can be at ease about the longevity of Mono. First of all subscribing to the mono-devel list will give you a good idea of how quickly mono is progressing. Also Mono has a major corporate backer, Novell. While Novell has seen better days, they're not going away anytime soon, and they've completely committed to Linux and Mono as their platform. For the most part, the free and open source software world has accepted Mono after some trepidation. Popular databases distribute Mono specific interfaces, and many popular Java projects have been ported (such as (N)Hibernate or iText#).
RE: [Mono-list] Moving from Mono/C# from C/Linux world
While I also prefer a *nix environment (FreeBSD), I think it's a bit myopic to say that Server 2003 isn't production ready. To me the test of an OS is always how well will it do what I want it to do, and there are times when a .NET 2.0 solution on a MS platform will produce acceptable results the fastest. SQL2005 Reporting Services and CLR integration are good examples of technologies that really are superior on a MS platform. The best platform for your needs is the one you know how to use the best. Any good sysadmin will tell you that. The reason that I'm a fan of mono is because I do think that MS and *nix both have their places. Mono makes it easy to leverage the benefits of these platforms. As I said before, I'm looking forward to watching mono mature. I very much so want to use it in a production environment because I think that there are many advantages to using *nix for many tasks. Currently I would have little problem using the 1.1 features of mono for production. However, I am somewhat addicted to things like generics, which as I understand it are not quite where they need to be yet. There are times when Mono/Linux will smoke VS.NET/MS, and there are times when the reverse it true. I try to come up with a solution that makes sense to my client. These days the most expensive things in computing are people, and as such I try to come up with the solution that minimizes the amount of cost that has to be sunk into development time, employee training, etc. Good development practice involves more than just computers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ted leslie Sent: Tuesday, March 07, 2006 3:31 PM To: mono-list@lists.ximian.com Subject: Re: [Mono-list] Moving from Mono/C# from C/Linux world Everyone has their opinions .. I use mono in a production environment, for a med sized pizza franchise in Canada, and hopefully soon rolling out a system using mono for one of the largest pizza companies in the world. I find mono rock solid. Regardless of how solid .Net 2.0 is your still running it on a OS i.e. windows 2003 server, etc, that is a alpha/beta version of an OS at best .. so whats better a VS.Net 2005 considered superior to mono as you say (but i dont agree) on a alpha/beta OS, or Mono on a bullit proof OS i.e. Linux end result is mono on linux is going to smoke MS .Net on a MS OS each and every time. -tl On Tue, 7 Mar 2006 14:53:42 -0700 [EMAIL PROTECTED] wrote: ISV adoption is going to take a while in my opinion. .NET guys are mostly windows guys, and at the moment VS.NET 2005 is considered superior to mono on MS platforms. Most *nix people that would use .NET are already Java guys, and most of them probably see little reason to switch from Java. Personally I would love to be able to use mono on *nix and therefore escape windows-land, however until mono matures some I don't think there's a good reason to use it over .NET2.0 in a production environment. That said, if I ever have a client that needs both MS and *nix support I wouldn't have any problem using mono/.net1.1 -Matt McDonald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Schurter Sent: Tuesday, March 07, 2006 10:07 AM To: mono-list@lists.ximian.com Subject: Re: [Mono-list] Moving from Mono/C# from C/Linux world Honey, Steve wrote: I've been evaluating Mono/C# for a few weeks now and am generally impressed by what I see. My group works currently in the C/Linux world where we develop near real-time scientific application software. I'm looking at C#/Mono because: a) Another group at our company uses C# / Windows and they rave about it. b) I'd like to bring get my group using something more modern then C. c) It would be nice if the two groups use the same development language to encourage code reuse. I have two questions. The first is what are there any things I need to worry about that would be difficult to do in the Mono/C# world that are fairly easy and standard in the C world? Note we have a distributed environment where most of the programs are fairly small. The programs typically perform a specific function (e.g. ingest the data, or run an algorithm on it) and then pass it on to the next program. Data is passed in a number of ways, but mainly through file sharing and pipes. We often use shell scripts to control the flow of data and the programs to do the actual work. In addition, we have fair number of existing C functions that I wish not to duplicate (at least not initially) but I believe I can incorporate them using SWIG. .Net and therefore Mono is a complete platform/framework whereas it sounds like you use the more traditional C/Unix environment of C as the language, and Unix as the platform. There's no reason you can't use the same development methodology with Mono (small apps, shell ties them
