[Mono-dev] Problem handling more the 1024 file handle
Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE, data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; } } } const int RLIMIT_NOFILE = 7; [DllImport (libc, SetLastError = true)] unsafe extern static int setrlimit(int resource, rlimit* rlim); } } ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem handling more the 1024 file handle
Hi, Mono itself has no trouble opening 1000's of files. Would you be able to create an equivalent C program and see if that works as expected? My guess would be that the equivalent C program will fail in the same way. If it does not, then it's likely to be a mono bug. Alan On 4 November 2011 07:19, Torello Querci tque...@gmail.com wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE, data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; } } } const int RLIMIT_NOFILE = 7; [DllImport (libc, SetLastError = true)] unsafe extern static int setrlimit(int resource, rlimit* rlim); } } ___ 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] Problem handling more the 1024 file handle
This is the first test that I realized. On the same machine, same kernel same calls Below the source code: = #include linux/resource.h //#include stdlib.h #include stdio.h int main(int argc, char* argv[]) { FILE** fp; int nFiles = atoi(argv[1]); int i; char filename[1024]; if (argc!=2) { printf(Error. You need to specify the number of file that need to create.\n); return -1; } struct rlimit data; data.rlim_cur = 2; data.rlim_max = 2; i = setrlimit (RLIMIT_NOFILE, data); if (i != 0) { printf (Error during changine files limits.\n); return 1; } fp = calloc (nFiles, sizeof(FILE*)); for (i=0; inFiles; ++i) { sprintf (filename, file%i.out, i); fp[i] = fopen (filename, w+); if (fp [i] == NULL) { printf (Error in %s file creation.\n, filename); return -1; } } } = 2011/11/4 Alan alan.mcgov...@gmail.com: Hi, Mono itself has no trouble opening 1000's of files. Would you be able to create an equivalent C program and see if that works as expected? My guess would be that the equivalent C program will fail in the same way. If it does not, then it's likely to be a mono bug. Alan On 4 November 2011 07:19, Torello Querci tque...@gmail.com wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE, data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; } } } const int RLIMIT_NOFILE = 7; [DllImport (libc, SetLastError = true)] unsafe extern static int setrlimit(int resource, rlimit* rlim); } } ___ 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] Problem handling more the 1024 file handle
On 04.11.2011 10:17, Torello Querci wrote: This is the first test that I realized. On the same machine, same kernel same calls You don't say which Mono arch you're using. On 32 bit, the following might not be correct: struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } because rlim_t is 8 byte long whereas IntPtr is 4 bytes. This is because Mono is compiled with LARGEFILE64 support. Robert Below the source code: = #includelinux/resource.h //#includestdlib.h #includestdio.h int main(int argc, char* argv[]) { FILE** fp; int nFiles = atoi(argv[1]); int i; char filename[1024]; if (argc!=2) { printf(Error. You need to specify the number of file that need to create.\n); return -1; } struct rlimit data; data.rlim_cur = 2; data.rlim_max = 2; i = setrlimit (RLIMIT_NOFILE,data); if (i != 0) { printf (Error during changine files limits.\n); return 1; } fp = calloc (nFiles, sizeof(FILE*)); for (i=0; inFiles; ++i) { sprintf (filename, file%i.out, i); fp[i] = fopen (filename, w+); if (fp [i] == NULL) { printf (Error in %s file creation.\n, filename); return -1; } } } = 2011/11/4 Alanalan.mcgov...@gmail.com: Hi, Mono itself has no trouble opening 1000's of files. Would you be able to create an equivalent C program and see if that works as expected? My guess would be that the equivalent C program will fail in the same way. If it does not, then it's likely to be a mono bug. Alan On 4 November 2011 07:19, Torello Quercitque...@gmail.com wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE,data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; } } } const int RLIMIT_NOFILE = 7; [DllImport (libc, SetLastError = true)] unsafe extern static int setrlimit(int resource, rlimit* rlim); } } ___
Re: [Mono-dev] Problem handling more the 1024 file handle
Sorry, You are right I'm on 32bit arch 2011/11/4 Robert Jordan robe...@gmx.net: On 04.11.2011 10:17, Torello Querci wrote: This is the first test that I realized. On the same machine, same kernel same calls You don't say which Mono arch you're using. On 32 bit, the following might not be correct: struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } because rlim_t is 8 byte long whereas IntPtr is 4 bytes. This is because Mono is compiled with LARGEFILE64 support. Robert Below the source code: = #includelinux/resource.h //#includestdlib.h #includestdio.h int main(int argc, char* argv[]) { FILE** fp; int nFiles = atoi(argv[1]); int i; char filename[1024]; if (argc!=2) { printf(Error. You need to specify the number of file that need to create.\n); return -1; } struct rlimit data; data.rlim_cur = 2; data.rlim_max = 2; i = setrlimit (RLIMIT_NOFILE,data); if (i != 0) { printf (Error during changine files limits.\n); return 1; } fp = calloc (nFiles, sizeof(FILE*)); for (i=0; inFiles; ++i) { sprintf (filename, file%i.out, i); fp[i] = fopen (filename, w+); if (fp [i] == NULL) { printf (Error in %s file creation.\n, filename); return -1; } } } = 2011/11/4 Alanalan.mcgov...@gmail.com: Hi, Mono itself has no trouble opening 1000's of files. Would you be able to create an equivalent C program and see if that works as expected? My guess would be that the equivalent C program will fail in the same way. If it does not, then it's likely to be a mono bug. Alan On 4 November 2011 07:19, Torello Quercitque...@gmail.com wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE,data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; } } } const int RLIMIT_NOFILE = 7; [DllImport (libc, SetLastError = true)] unsafe extern static int setrlimit(int resource,
Re: [Mono-dev] Problem handling more the 1024 file handle
Looking in the strace output file this is the setrlimit call: setrlimit(RLIMIT_NOFILE, {rlim_cur=2, rlim_max=2}) = 0 so seems to be correct 2011/11/4 Torello Querci tque...@gmail.com: Sorry, You are right I'm on 32bit arch 2011/11/4 Robert Jordan robe...@gmx.net: On 04.11.2011 10:17, Torello Querci wrote: This is the first test that I realized. On the same machine, same kernel same calls You don't say which Mono arch you're using. On 32 bit, the following might not be correct: struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } because rlim_t is 8 byte long whereas IntPtr is 4 bytes. This is because Mono is compiled with LARGEFILE64 support. Robert Below the source code: = #includelinux/resource.h //#includestdlib.h #includestdio.h int main(int argc, char* argv[]) { FILE** fp; int nFiles = atoi(argv[1]); int i; char filename[1024]; if (argc!=2) { printf(Error. You need to specify the number of file that need to create.\n); return -1; } struct rlimit data; data.rlim_cur = 2; data.rlim_max = 2; i = setrlimit (RLIMIT_NOFILE,data); if (i != 0) { printf (Error during changine files limits.\n); return 1; } fp = calloc (nFiles, sizeof(FILE*)); for (i=0; inFiles; ++i) { sprintf (filename, file%i.out, i); fp[i] = fopen (filename, w+); if (fp [i] == NULL) { printf (Error in %s file creation.\n, filename); return -1; } } } = 2011/11/4 Alanalan.mcgov...@gmail.com: Hi, Mono itself has no trouble opening 1000's of files. Would you be able to create an equivalent C program and see if that works as expected? My guess would be that the equivalent C program will fail in the same way. If it does not, then it's likely to be a mono bug. Alan On 4 November 2011 07:19, Torello Quercitque...@gmail.com wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. Using strace on both this code and no setrlimit version code I have some differences. On the no setrlimit version I have this syscall: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EMFILE (Too many open files) and this seems to be correct. On the setrlimit version code I have this syscalls: open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024 close(1024) = 0 so seems that mono close the file because open return value is 1024. Is this a bug, a feature, or something else? == using System; using System.IO; using System.Text; using System.Runtime.InteropServices; namespace TestFiles { struct rlimit { public IntPtr rlimit_cur; public IntPtr rlimit_max; } class MainClass { public static unsafe void Main (string[] args) { FileStream[] streams; string path; if (args.Length == 0) { Console.WriteLine (You need to specify the number of files that needs to be created.); return; } int nFiles = Int32.Parse (args[0]); streams = new FileStream[nFiles]; rlimit data = new rlimit (); data.rlimit_cur = (IntPtr) 2; data.rlimit_max = (IntPtr) 2; int result = setrlimit (RLIMIT_NOFILE,data); if (result != 0) { throw new Exception (Cannot change limit on open files); } for (int i=0; inFiles; ++i) { path = string.Format (file{0}.out, i); try { streams[i] = File.Open(path, FileMode.Create, FileAccess.Write, FileShare.None); } catch (Exception ex) { Console.WriteLine (Unable to write file {0}, path); Console.WriteLine (ex.Message); Console.WriteLine (ex.StackTrace); return; }
Re: [Mono-dev] Problem handling more the 1024 file handle
On 04.11.2011 10:49, Torello Querci wrote: Sorry, You are right I'm on 32bit arch Then you need this: struct rlimit { public long rlimit_cur; public long rlimit_max; } Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem handling more the 1024 file handle
On 04.11.2011 11:18, Torello Querci wrote: Hy Robert, On 32bit arch IntPtr is 32bit, on 64 bit arch, IntPrt is 64 bit. Yes, this is not the issue here. However I try your suggestion but the setrlimit no more work. Looking inside the strace output this is the setrlimit syscall: setrlimit(RLIMIT_NOFILE, {rlim_cur=2, rlim_max=0}) = -1 EINVAL (Invalid argument) Indeed, the p/invoked symbol setrlimit is always the 32 bit variant on 32 bit systems. C programs can change this with -D_FILE_OFFSET_BITS=64, as Mono does, but this does not affect p/invoke. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem handling more the 1024 file handle
On 04.11.2011 08:19, Torello Querci wrote: Hi al, trying to handle more that 1024 handle file I got an exception even if I increase the max number of file limit using setrlimit. The example source code below. Of course mono have the right pcap permission. This is a bug in Mono's io-layer: https://github.com/mono/mono/blob/master/mono/io-layer/handles.c#L251 getdtablesize() is returning the max count of possible open file descriptors *at start-up*, so any later setrlimit has no effect. Please file a bug at bugzilla.xamarin.com. Meanwhile, you could just increase the open files limit with ulimit -S -H 2, so don't mark the bug as super critical ;) Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem handling more the 1024 file handle
On 04.11.2011 13:26, Robert Jordan wrote: Meanwhile, you could just increase the open files limit with ulimit -S -H 2, so don't mark the bug as super critical ;) I've fat-fingered ulimit's arguments: ulimit -S -H -n 2 Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
Hi, I ran across a perplexing error when calling a C# method in one of my assemblies from C++: System.MissingMethodException: Method not found: 'System.Type.op_Equality'. Searching google, it seems that the MonoTouch folks encounter this as well and the explanation is that MT is not yet fully .NET 4.0 compliant [http://comments.gmane.org/gmane.comp.gnome.mono.monotouch/1538]. I am using the 2.10.6 mono SDK on OS X and not using mono touch, however. Is it the case that I cannot yet call into .NET 4.0 assemblies from C++ (i doubt)? Do I need to somehow tell the CLR to use the .NET 4.0 mscorlib when I call mono_domain_assembly_open()? Note that I am not initializing mono_domain_assembly_open() with an exe, rather with a dll. Perhaps there is some setup I need to do? Also I am able to evaluate into the function until it needs to reference type equality. The function I am evaluating is performing reflection. 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] embedded mono and .NET 4.0 assemblies [peculiar error]
Hi, Note that I am not initializing mono_domain_assembly_open() with an exe, rather with a dll. Perhaps there is some setup I need to do? The dll is probably compiled against an older net version, causing the runtime to load an older mscorlib. Zoltan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
On 04.11.2011 19:32, Jonathan Shore wrote: Note that I am not initializing mono_domain_assembly_open() with an exe, rather with a dll. Perhaps there is some setup I need to do? How are you initializing the runtime exactly (code)? You probably need mono_jit_init_version() or alternatively pass a .NET 4.0 assembly to mono_jit_init(). Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
My assembly is definitely 4.0 and monodis --assemblyref indicates dependency on .NET 4 assemblies. I'll look into mono_jit_init_version() and see whether this helps. AssemblyRef Table 1: Version=4.0.0.0 Name=System Flags=0x Public Key: 0x: B7 7A 5C 56 19 34 E0 89 2: Version=4.0.0.0 Name=mscorlib Flags=0x Public Key: 0x: B7 7A 5C 56 19 34 E0 89 3: Version=4.0.0.0 Name=System.Core Flags=0x Public Key: 0x: B7 7A 5C 56 19 34 E0 89 The initialization part of the C++ code looks like: // create AppDomain _domain = mono_jit_init (api); // load bootstrap assembly string dir (assemblydir); string path = dir + /com.gf.core.dll; _core = mono_domain_assembly_open (_domain, path.c_str()); Where com.gf.core.dll is compiled to .NET 4.0. Thanks___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
On 04.11.2011 20:05, Jonathan Shore wrote: My assembly is definitely 4.0 and monodis --assemblyref indicates dependency on .NET 4 assemblies. I'll look into mono_jit_init_version() and see whether this helps. Yes, but you're not using it for initialization. // create AppDomain This won't initialize a v4 runtime. The default is 2.0: _domain = mono_jit_init (api); // load bootstrap assembly string dir (assemblydir); string path = dir + /com.gf.core.dll; That's too late: _core = mono_domain_assembly_open (_domain, path.c_str()); Where com.gf.core.dll is compiled to .NET 4.0. Thanks Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
I'm working off of http://www.mono-project.com/Embedding_Mono with regard to initialization. I tried a number of possible version #s for the mono_jit_init_version(), but indicated: WARNING: The runtime version supported by this application is unavailable. Using default runtime: v2.0.50727 what is the version # one should use to correspond to .NET 4? The version #s like v2.0.50727 are peculiar (but I think a MS thing). Or is there a way to initialize the domain using the assembly? Is the argument to the domain optionally either its name or the path to the main assembly? I note that in the header have the signature: mono_jit_init (const char *file); Whereas the documentation in the link above indicates that mono_jit_init () is provided with the name for the domain. I guess the docs are not very clear here. Just need one approach that works. Thanks for your help. On Nov 4, 2011, at 3:13 PM, Robert Jordan wrote: On 04.11.2011 20:05, Jonathan Shore wrote: My assembly is definitely 4.0 and monodis --assemblyref indicates dependency on .NET 4 assemblies. I'll look into mono_jit_init_version() and see whether this helps. Yes, but you're not using it for initialization. // create AppDomain This won't initialize a v4 runtime. The default is 2.0: _domain = mono_jit_init (api); // load bootstrap assembly string dir (assemblydir); string path = dir + /com.gf.core.dll; That's too late: _core = mono_domain_assembly_open (_domain, path.c_str()); Where com.gf.core.dll is compiled to .NET 4.0. Thanks Robert ___ 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] embedded mono and .NET 4.0 assemblies [peculiar error]
Thanks all. I solved it by passing the bootstrap assembly into mono_jit_init (). Did not realize this call could take a path to an assembly. On Nov 4, 2011, at 3:13 PM, Robert Jordan wrote: On 04.11.2011 20:05, Jonathan Shore wrote: My assembly is definitely 4.0 and monodis --assemblyref indicates dependency on .NET 4 assemblies. I'll look into mono_jit_init_version() and see whether this helps. Yes, but you're not using it for initialization. // create AppDomain This won't initialize a v4 runtime. The default is 2.0: _domain = mono_jit_init (api); // load bootstrap assembly string dir (assemblydir); string path = dir + /com.gf.core.dll; That's too late: _core = mono_domain_assembly_open (_domain, path.c_str()); Where com.gf.core.dll is compiled to .NET 4.0. Thanks Robert ___ 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] embedded mono and .NET 4.0 assemblies [peculiar error]
On 04.11.2011 20:22, Jonathan Shore wrote: I'm working off of http://www.mono-project.com/Embedding_Mono with regard to initialization. I tried a number of possible version #s for the mono_jit_init_version(), but indicated: WARNING: The runtime version supported by this application is unavailable. Using default runtime: v2.0.50727 what is the version # one should use to correspond to .NET 4? The version #s like v2.0.50727 are peculiar (but I think a MS thing). The version number for mono_jit_init_version() can be one of the the strings that start with v: https://github.com/mono/mono/blob/master/mono/metadata/domain.c#L121 Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]
I'm working on a mapping between R (the statistical language) and C#, so that R can reference and call methods in C# assemblies. R has an implementation for Java and C, but lacks one for C#. On Nov 4, 2011, at 3:44 PM, Slide wrote: Might I ask what you are using embedding for? I've been interested in embedding mono but haven't found any project to use it on. How is it working for you? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem handling more the 1024 file handle
Bug filled: http://bugzilla.xamarin.com/show_bug.cgi?id=1888 Sorry for the delay. 2011/11/4 Robert Jordan robe...@gmx.net: On 04.11.2011 13:26, Robert Jordan wrote: Meanwhile, you could just increase the open files limit with ulimit -S -H 2, so don't mark the bug as super critical ;) I've fat-fingered ulimit's arguments: ulimit -S -H -n 2 Robert ___ 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] linking with lib mono-2.0 on osx (64 bit vs 32 bit)
Hi, I am a bit fuzzy as to whether a 64 bit version of mono exists for osx. According to this page http://www.mono-project.com/Supported_Platforms, it does, or at least the JIT can generate 64 bit code. In this regard, all of the mono libraries in the prebuilt 2.10.6 package are 32 bit. Do I need to do a custom build to get 64 bit or is the 64 bit port not yet completely there? I am wondering whether will get into trouble linking a 64 bit application with 32 bit libs. To be honest don't have experience with this on osx. Thanks Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] moon light plugin
On Fri, Nov 04, 2011 at 08:37:38AM +, Stifu wrote: The Mono team no longer works on Moonlight. So until community members pick it up, it's dead. Oh, crap! I did get a short burst of work before the attachmate thing. I based moonbase ontop of moonlight from github earlier this year. Quite alot of the sl4 stuff worked well. Though I must admit I was more looking at the xaml/control side of things than in a plugin state. blueridge wrote: When will the moonlight plug-in be up date to support more modern sites I tried to use www.ritzpix.com the plugin does not work Chip ___ Mono-list maillist - Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Where-does-Mono-store-user-config-setterings-tp3983422p3989331.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Ubuntu 11.10 configuration problem
It could be that your program is compiled for .net 4.0 but your mono doesnt support it. On Fri, Nov 04, 2011 at 12:29:58AM +, Matthew Fleming wrote: Hi, I'm entirely new to mono so I'd really appreciate help with the following. I am trying to run OpenVista CIS, which is supposed to run with mono under Linux, on Ubuntu 11.10. I get the following errors: mfleming@mgf-desktop:~/openvista/openvistacis-0.9.96-client$ ./OpenVistaCIS.exe Missing method System.Reflection.Assembly::op_Equality(Assembly,Assembly) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/gdk-sharp/2.12.0.0__35e10195dab3c99f/gdk-sharp.dll ---Initial Exception--- Method not found: 'System.Reflection.Assembly.op_Equality'. at Medsphere.OpenVista.CIS.OVMain.Run (System.String[] args) [0x0] in filename unknown:0 at Medsphere.OpenVista.CIS.OVMain.Main (System.String[] args) [0x0] in filename unknown:0 ---Second Exception--- An exception was thrown by the type initializer for Nest at Medsphere.OpenVista.CIS.OVMain.ShowUnhandledException (System.Exception ex) [0x0] in filename unknown:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method not found: 'System.Reflection.Assembly.op_Equality'. at Medsphere.OpenVista.CIS.OVMain.Run (System.String[] args) [0x0] in filename unknown:0 at Medsphere.OpenVista.CIS.OVMain.Main (System.String[] args) [0x0] in filename unknown:0 It appears to me that this is probably a problem with the way mono is configured in this Ubuntu distro, but I have no idea how to fix it. Any assistance would be greatly appreciated. Matthew Fleming ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono not catching this, VS does
I don't know whether to call this a bug, but this code can result in an access of the List list, without assigning to it (in the case b is false): public static void Foo(bool b) { int i; Listint list; if (b !dict.TryGetValue(foo, out list)) { dict[foo] = new Listint(); } else { i = list[0]; } } Visual studio flags this as a compiler error. I am using: $ mono --version Mono JIT compiler version 2.11 ((no/7917753 Wed Mar 30 15:47:09 EDT 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: yes(2.8svn-mono) GC:Included Boehm (with typed GC and Parallel Mark) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono not catching this, VS does
Please file a bug report in http://bugzilla.xamarin.com/ On 11/04/2011 02:02 PM, Matt Calder wrote: I don't know whether to call this a bug, but this code can result in an access of the List list, without assigning to it (in the case b is false): public static void Foo(bool b) { int i; Listint list; if (b !dict.TryGetValue(foo, out list)) { dict[foo] = new Listint(); } else { i = list[0]; } } Visual studio flags this as a compiler error. I am using: $ mono --version Mono JIT compiler version 2.11 ((no/7917753 Wed Mar 30 15:47:09 EDT 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com http://www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: yes(2.8svn-mono) GC:Included Boehm (with typed GC and Parallel Mark) ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list