[Mono-dev] System.Management.ObjectQuery class
Hi all, I have a Server machine which is a windows machine and a client machine which is OpenSuse. I am using System.Management.ObjectQuery class in C# code to make a management query to server machine from the client machine. But i am getting System.NotImplementedException. Also when i use System.Management.ConnectionOptions.set_Username and set_PassWord, it gives the same error. What is the problem, can someone help me? Am i missing out some library or these classes are not supported by mono. -- View this message in context: http://www.nabble.com/System.Management.ObjectQuery-class-tp21558447p21558447.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Management.ObjectQuery class
Yes. those libraries based on Windows-ism, such as System.Management, are not supported in Mono. In case you are unsure about mono limitation, MoMA is your friend. http://mono-project.com/MoMA Atsushi Eno Atoka wrote: Hi all, I have a Server machine which is a windows machine and a client machine which is OpenSuse. I am using System.Management.ObjectQuery class in C# code to make a management query to server machine from the client machine. But i am getting System.NotImplementedException. Also when i use System.Management.ConnectionOptions.set_Username and set_PassWord, it gives the same error. What is the problem, can someone help me? Am i missing out some library or these classes are not supported by mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Management.ObjectQuery class
But I installed Mono 2.0 for linux and in /usr/lib/mono/2.0/ and /usr/lib/mono/gac/ folders it has System.Management.dll lib. Also in my c# code i am able to use some of the System.Management lib's class like System.Management.ManagementScope, System.Management.ManagementObject etc. The problem i am facing is in System.Management.ObjectQuery class. Does it support only some classes of System.Management? Where do i get the list of Mono supported System.Management's classes? Atsushi Eno wrote: Yes. those libraries based on Windows-ism, such as System.Management, are not supported in Mono. In case you are unsure about mono limitation, MoMA is your friend. http://mono-project.com/MoMA Atsushi Eno Atoka wrote: Hi all, I have a Server machine which is a windows machine and a client machine which is OpenSuse. I am using System.Management.ObjectQuery class in C# code to make a management query to server machine from the client machine. But i am getting System.NotImplementedException. Also when i use System.Management.ConnectionOptions.set_Username and set_PassWord, it gives the same error. What is the problem, can someone help me? Am i missing out some library or these classes are not supported by mono. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://www.nabble.com/System.Management.ObjectQuery-class-tp21558447p21561376.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Management.ObjectQuery class
We *have* those assemblies that *throws* NotImplementedException all around, as the exception message you got exactly shows. Again, MoMA is with you, he (or she, I dunno) is your good friend. Atsushi Eno Atoka wrote: But I installed Mono 2.0 for linux and in /usr/lib/mono/2.0/ and /usr/lib/mono/gac/ folders it has System.Management.dll lib. Also in my c# code i am able to use some of the System.Management lib's class like System.Management.ManagementScope, System.Management.ManagementObject etc. The problem i am facing is in System.Management.ObjectQuery class. Does it support only some classes of System.Management? Where do i get the list of Mono supported System.Management's classes? Atsushi Eno wrote: Yes. those libraries based on Windows-ism, such as System.Management, are not supported in Mono. In case you are unsure about mono limitation, MoMA is your friend. http://mono-project.com/MoMA Atsushi Eno Atoka wrote: Hi all, I have a Server machine which is a windows machine and a client machine which is OpenSuse. I am using System.Management.ObjectQuery class in C# code to make a management query to server machine from the client machine. But i am getting System.NotImplementedException. Also when i use System.Management.ConnectionOptions.set_Username and set_PassWord, it gives the same error. What is the problem, can someone help me? Am i missing out some library or these classes are not supported by mono. ___ 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] Managed javascript
Hi, I am trying to find a way to add javascript entry points into my app... I have found Microsoft.Vsa namespace (with JScript and VB) on windows, and mjs for mono... Microsoft's Vsa is deprecated, and mjs seems to be inactive since a long time... Rhino + IKVM seems heavy and hard to use... Does anyone know if there exists a javascript compiler/interpreter (opensource if possible) I can use to add javascript scripting into my app ? Thanks. Damien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Managed javascript
I'm totally unsure if it fits your need, but a friend of mine has a C++ based Javascript compiler for embedded use. It chooses CIL as its intermediate byte code representation (with some extension for its own use, but I heard that it can be removed), so it might be reusable for Mono. Though it is still in development and lacks some features such as closure support. http://criscript.com/trac Atsushi Eno Damien wrote: Hi, I am trying to find a way to add javascript entry points into my app... I have found Microsoft.Vsa namespace (with JScript and VB) on windows, and mjs for mono... Microsoft's Vsa is deprecated, and mjs seems to be inactive since a long time... Rhino + IKVM seems heavy and hard to use... Does anyone know if there exists a javascript compiler/interpreter (opensource if possible) I can use to add javascript scripting into my app ? Thanks. Damien ___ 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] Managed javascript
Hi Damien, some time ago I took the rhino source code (Rhino 1.6R5) and transformed it into c# (no compiler, just the runtime and the interpreter). The result is available in a public google repository at http://code.google.com/p/ecmascript-net/. You can give it a shot, perhaps it fits into your app. Although it's kind of stable (runs JS code up to version 1.5 pretty well), it misses a lot of patches made to the rhino repository since its initial creation and isn't actively developed. If you are not tied to javascript, perhaps boo, a python inspired language (http://boo.codehaus.org/) may be a valid choice. Christian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Threading.Thread.CurrentPrincipal.Identity.Name
Should this return something on Linux (OpenSuse 11.0)?
Thanks,
Vlad
using System;
class Eg
{
static void Main()
{
Console.WriteLine(Environment.UserName);
//This works
Console.WriteLine(System.Threading.Thread.CurrentPrincipal.Identity.Name
); //this returns empty string
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] C++, COM interop
Hello Mono users and developers! I have a native C++ class library , a COM wrapper written in ATL and a .NET wrapper written in C++/CLI. Now, I'm thinking how it would be possible to write a mono wrapper that runs mainly in LINUX. Basically I see two suggested ways: - Write a flatten C version on the library and use P/Invoke - Use SWIG to do such a thing I don't like neither of these, since the wrapper has many functions and classes. I see a better in using a sort of COM / XPCOM interfaces. I have no problems in making the wrapper based on interfaces (like I did for the COM one). The only thing that I can not use are class factories since COM is not available in Windows. Hoever , I've got no problem in eventually writing a custom factory for required COM Classes. I see that there is a main difference between COM and XPCOM interop. (?) In com you can write CClass c = new cClass () and the COM layer will call the relative class factory. In XPCOm you have to call manually a function to create the class. The question is : is there a way to redirect the new for a COM class (in linux) so I can directly call a custom class factory function (this time internal) ? I.e. COMClass C = new COMClass; i.e. instead of calling CoCreateObject should call an internal function CreateCOMClass ? I don't know if I made it clear... I'll continue trying, and I'll share my experience, so maybe users can find an additional way to wrap C++ classes. Thank you. QbProg -- View this message in context: http://www.nabble.com/C%2B%2B%2C-COM-interop-tp21539294p21539294.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] FUTEX_WAIT with svn 123775 winforms
Hi, I've noticed this sometimes with the svn releases. While everything works fine for console apps and gtksharp apps, when it comes to winforms applications, some releases seem to have problems with FUTEX_WAIT. They just don't do anything! I can't put it down to anything, but I've seen it happen on some svn releases, but not all (svn 123775 is one such release). Is there a reason for this is or is it some random ass kind of thing? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] XIM problem with Winforms (svn)
Hi, I have a number of winforms applications which are failing to start correctly. They work fine until about 123650 under svn. Under 123775, I had problems with FUTEX_WAIT (and it never completed). Under 123860, when I run using mono -v filename.exe, I get at the end (sorry for any mistakes, I'm on a different machine to the one the code is on) Method System.Windows.Forms.X11Keyboard:SetupXIM() emitted at 0x5e7560 to 0x5e765e (code length 254) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSupportLocale () emitted 0x5e7688 to 0x5e76cc (code length 68) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSetLocaleModifiers (string) emitted at 0x5e76d0 to 0x5e773b (code length 107) [colourmixer.exe] Method (wrapper to native) System.Windows.Forms.X11Keyboard:XOpenIM (intptr, intptr, intptr, intptr) emitted at 0x5e7740 to 0x5e7793 (code length 83) [colourmixer.exe] strace suggests something is either in an endless loop (I get a (time(NULL) = 1232452591, 4 semops, waitpid(3977, 0x3f8294, WNOHANG)=0, nanosleep((10, 0), null) = 0) continually) Is there a simple fix for this or something I can look at to see if it is mono at fault or my X server? Using Fedora rawhide, x86 TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XIM problem with Winforms (svn)
You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled Jonathan Paul wrote: Hi, I have a number of winforms applications which are failing to start correctly. They work fine until about 123650 under svn. Under 123775, I had problems with FUTEX_WAIT (and it never completed). Under 123860, when I run using mono -v filename.exe, I get at the end (sorry for any mistakes, I'm on a different machine to the one the code is on) Method System.Windows.Forms.X11Keyboard:SetupXIM() emitted at 0x5e7560 to 0x5e765e (code length 254) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSupportLocale () emitted 0x5e7688 to 0x5e76cc (code length 68) [colourmixer.exe] Method (wrapper managed-to-native) System.Windows.Forms.X11Keyboard:XSetLocaleModifiers (string) emitted at 0x5e76d0 to 0x5e773b (code length 107) [colourmixer.exe] Method (wrapper to native) System.Windows.Forms.X11Keyboard:XOpenIM (intptr, intptr, intptr, intptr) emitted at 0x5e7740 to 0x5e7793 (code length 83) [colourmixer.exe] strace suggests something is either in an endless loop (I get a (time(NULL) = 1232452591, 4 semops, waitpid(3977, 0x3f8294, WNOHANG)=0, nanosleep((10, 0), null) = 0) continually) Is there a simple fix for this or something I can look at to see if it is mono at fault or my X server? Using Fedora rawhide, x86 TTFN Paul ___ 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] 2.2 broken for solaris
Hi, I'm currently building Mono 2.0.1 correctly on Solaris (using the blastwave boxes to create a solaris release *right now*). But, I *can't* build mono 2.2. Here's the error: mv -f .deps/mini.Tpo .deps/mini.Plo /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DGC_SOLARIS_THREADS -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -I../.. -I../../libgc/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -Wno-char-subscripts -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c -o driver.lo driver.c mv -f .deps/driver.Tpo .deps/driver.Plo /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DGC_SOLARIS_THREADS -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -I../.. -I../../libgc/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -Wno-char-subscripts -MT aot-compiler.lo -MD -MP -MF .deps/aot-compiler.Tpo -c -o aot-compiler.lo aot-compiler.c In file included from ../../mono/utils/freebsd-elf32.h:32, from aot-compiler.c:67: ../../mono/utils/freebsd-elf_common.h:46: error: syntax error before u_int32_t ../../mono/utils/freebsd-elf_common.h:46: warning: no semicolon at end of struct or union ../../mono/utils/freebsd-elf_common.h:47: warning: type defaults to `int' in declaration of `n_descsz' ../../mono/utils/freebsd-elf_common.h:47: warning: data definition has no type or storage class ../../mono/utils/freebsd-elf_common.h:48: error: syntax error before n_type ../../mono/utils/freebsd-elf_common.h:48: warning: type defaults to `int' in declaration of `n_type' ../../mono/utils/freebsd-elf_common.h:48: warning: data definition has no type or storage class ../../mono/utils/freebsd-elf_common.h:49: warning: type defaults to `int' in declaration of `Elf_Note' ../../mono/utils/freebsd-elf_common.h:49: warning: data definition has no type or storage class In file included from aot-compiler.c:67: ../../mono/utils/freebsd-elf32.h:144: error: syntax error before Elf32_Nhdr ../../mono/utils/freebsd-elf32.h:144: warning: type defaults to `int' in declaration of `Elf32_Nhdr' ../../mono/utils/freebsd-elf32.h:144: warning: data definition has no type or storage class In file included from aot-compiler.c:68: ../../mono/utils/freebsd-elf64.h:162: error: syntax error before Elf64_Nhdr ../../mono/utils/freebsd-elf64.h:162: warning: type defaults to `int' in declaration of `Elf64_Nhdr' ../../mono/utils/freebsd-elf64.h:162: warning: data definition has no type or storage class gmake[4]: *** [aot-compiler.lo] Error 1 gmake[4]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono/mini' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono/mini' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/psantosl/monosrc/mono-2.2' gmake: *** [all] Error 2 Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XIM problem with Winforms (svn)
Hi, You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled Doesn't look like a XIM problem Interestingly, if I rebuild the application via monodevelop, I can sometimes get it to work, but when it does, the app comes back with Unable to change Locale modifiers (or something similar). When I've googled that error, there seems to have been a patch put in around May last year that seems to be no longer in the svn builds. No idea if it would fix this problem though... TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] C++, COM interop
- Original Message - From: QbProg tho...@gmail.com To: mono-devel-list@lists.ximian.com Sent: Wednesday, January 21, 2009 7:22 AM Subject: [Mono-dev] C++, COM interop Hello Mono users and developers! I have a native C++ class library , a COM wrapper written in ATL and a .NET wrapper written in C++/CLI. Now, I'm thinking how it would be possible to write a mono wrapper that runs mainly in LINUX. Basically I see two suggested ways: - Write a flatten C version on the library and use P/Invoke - Use SWIG to do such a thing I don't like neither of these, since the wrapper has many functions and classes. I see a better in using a sort of COM / XPCOM interfaces. I have no problems in making the wrapper based on interfaces (like I did for the COM one). The only thing that I can not use are class factories since COM is not available in Windows. Hoever , I've got no problem in eventually writing a custom factory for required COM Classes. I see that there is a main difference between COM and XPCOM interop. (?) In com you can write CClass c = new cClass () and the COM layer will call the relative class factory. In XPCOm you have to call manually a function to create the class. The question is : is there a way to redirect the new for a COM class (in linux) so I can directly call a custom class factory function (this time internal) ? I.e. COMClass C = new COMClass; i.e. instead of calling CoCreateObject should call an internal function CreateCOMClass ? I don't know if I made it clear... I'll continue trying, and I'll share my experience, so maybe users can find an additional way to wrap C++ classes. I am not sure if others would agree here, but personally I feel a much better approach (or, at least it avoids COM...) would be to write an autowrapper tool to automatically generate either a plain C-based API, or a JNI-based API, and another tool to emit the code needed to import all of this back into .NET (via P/Invoke) or similar... in such a tool, each class is converted to a raw/incomplete pointer, and each method is converted into a function with a mangled name accepting the class as the first argument. the whole mass would be C++, but all functions are declared with extern C. a pair tool would generate all the interface code in C++/CLI or C# or similar (treating the C++ classes as unmanaged pointers and calling the wrapper functions via P/Invoke...). of course, this would be fairly similar to what SWIG does, assuming SWIG does not do this already (I have not looked into SWIG that much personally...). but, in any case, assuming the C++ headers are fairly clean, the tool need not even fully understand C++ syntax to pull this off (AKA: a dumb tool representing a state machine and processing 1 line at a time, ignoring anything it doesn't recognize). although not for C++ (mostly I use C for various reasons, mainly that it is much easier to tool than C++ ...), a few of the major tools in my codebase work similar to this (mostly because I am too lazy to bother with keeping headers up to date, I find it more convinient to just write the code and make use of a special tool to write many of the headers for me...). I had also decided long ago I would not make use of a language which I could not within reasonable effort implement automated tools for, and so I stick mostly to C. OTOH many people use C++ for most things, and end up with codebases which are not easily ammended to the use of automated tools, is not exactly standardized at the level of generated machine code, object layout, ... (2 independent C++ compilers tending to produce code which will not link, ...). (actually, if such a tool were implemented, would it be reasonable to package it with Mono?...). or, maybe this already exists and I missed it (I don't have this problem, so I didn't look...). actually, this kind of a thing is a major reason why I use C-based APIs for all my libs (even if internally they use C++). as such, any C++ based API is then implemented as a wrapper over the C-based one (a library can be written in C++, and there is an external C++ - based API as well, but they do not directly communicate as such, which also helps promote abstraction between the frontend and the library internals...). or such... Thank you. QbProg -- View this message in context: http://www.nabble.com/C%2B%2B%2C-COM-interop-tp21539294p21539294.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 2.2 broken for solaris
Hi, This is now fixed in the 2.2 branch: http://lists.ximian.com/pipermail/mono-patches/2009-January/138782.html Zoltan On Wed, Jan 21, 2009 at 12:54 AM, pablosantosl...@terra.es pablosantosl...@terra.es wrote: Hi, I'm currently building Mono 2.0.1 correctly on Solaris (using the blastwave boxes to create a solaris release *right now*). But, I *can't* build mono 2.2. Here's the error: mv -f .deps/mini.Tpo .deps/mini.Plo /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DGC_SOLARIS_THREADS -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -I../.. -I../../libgc/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -Wno-char-subscripts -MT driver.lo -MD -MP -MF .deps/driver.Tpo -c -o driver.lo driver.c mv -f .deps/driver.Tpo .deps/driver.Plo /bin/bash ../../libtool --quiet --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DGC_SOLARIS_THREADS -DGC_SOLARIS_PTHREADS -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DUSE_MMAP -DUSE_MUNMAP -DPLATFORM_SOLARIS -D_FILE_OFFSET_BITS=64 -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -D_XOPEN_SOURCE_EXTENDED=1 -I../.. -I../../libgc/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -mno-tls-direct-seg-refs -Wno-char-subscripts -MT aot-compiler.lo -MD -MP -MF .deps/aot-compiler.Tpo -c -o aot-compiler.lo aot-compiler.c In file included from ../../mono/utils/freebsd-elf32.h:32, from aot-compiler.c:67: ../../mono/utils/freebsd-elf_common.h:46: error: syntax error before u_int32_t ../../mono/utils/freebsd-elf_common.h:46: warning: no semicolon at end of struct or union ../../mono/utils/freebsd-elf_common.h:47: warning: type defaults to `int' in declaration of `n_descsz' ../../mono/utils/freebsd-elf_common.h:47: warning: data definition has no type or storage class ../../mono/utils/freebsd-elf_common.h:48: error: syntax error before n_type ../../mono/utils/freebsd-elf_common.h:48: warning: type defaults to `int' in declaration of `n_type' ../../mono/utils/freebsd-elf_common.h:48: warning: data definition has no type or storage class ../../mono/utils/freebsd-elf_common.h:49: warning: type defaults to `int' in declaration of `Elf_Note' ../../mono/utils/freebsd-elf_common.h:49: warning: data definition has no type or storage class In file included from aot-compiler.c:67: ../../mono/utils/freebsd-elf32.h:144: error: syntax error before Elf32_Nhdr ../../mono/utils/freebsd-elf32.h:144: warning: type defaults to `int' in declaration of `Elf32_Nhdr' ../../mono/utils/freebsd-elf32.h:144: warning: data definition has no type or storage class In file included from aot-compiler.c:68: ../../mono/utils/freebsd-elf64.h:162: error: syntax error before Elf64_Nhdr ../../mono/utils/freebsd-elf64.h:162: warning: type defaults to `int' in declaration of `Elf64_Nhdr' ../../mono/utils/freebsd-elf64.h:162: warning: data definition has no type or storage class gmake[4]: *** [aot-compiler.lo] Error 1 gmake[4]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono/mini' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono/mini' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/psantosl/monosrc/mono-2.2/mono' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/psantosl/monosrc/mono-2.2' gmake: *** [all] Error 2 Thanks, pablo www.plasticscm.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XIM problem with Winforms (svn)
Hi, You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled D'oh! It is a XIM problem. It's still there in 123918 as well. Do I need to put it into the Novell BZ? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XIM problem with Winforms (svn)
We have bug #436000. If this is different, please create a new bug for it. Thanks! Jonathan Paul wrote: Hi, You can see if it is a XIM problem by disabling XIM and trying it: MONO_WINFORMS_XIM_STYLE=disabled D'oh! It is a XIM problem. It's still there in 123918 as well. Do I need to put it into the Novell BZ? TTFN Paul ___ 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] C++, COM interop
Hi, Look at the ExtensibleClassFactory.RegisterObjectCreationCallback method. http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.extensibleclassfactory.registerobjectcreationcallback.aspx -bill On Tue, Jan 20, 2009 at 4:22 PM, QbProg tho...@gmail.com wrote: Hello Mono users and developers! I have a native C++ class library , a COM wrapper written in ATL and a .NET wrapper written in C++/CLI. Now, I'm thinking how it would be possible to write a mono wrapper that runs mainly in LINUX. Basically I see two suggested ways: - Write a flatten C version on the library and use P/Invoke - Use SWIG to do such a thing I don't like neither of these, since the wrapper has many functions and classes. I see a better in using a sort of COM / XPCOM interfaces. I have no problems in making the wrapper based on interfaces (like I did for the COM one). The only thing that I can not use are class factories since COM is not available in Windows. Hoever , I've got no problem in eventually writing a custom factory for required COM Classes. I see that there is a main difference between COM and XPCOM interop. (?) In com you can write CClass c = new cClass () and the COM layer will call the relative class factory. In XPCOm you have to call manually a function to create the class. The question is : is there a way to redirect the new for a COM class (in linux) so I can directly call a custom class factory function (this time internal) ? I.e. COMClass C = new COMClass; i.e. instead of calling CoCreateObject should call an internal function CreateCOMClass ? I don't know if I made it clear... I'll continue trying, and I'll share my experience, so maybe users can find an additional way to wrap C++ classes. Thank you. QbProg -- View this message in context: http://www.nabble.com/C%2B%2B%2C-COM-interop-tp21539294p21539294.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Rounded corners on Mac OSX
Hi there, we are devloping a crossplatform app. and have run into a little problem on OSX. We belive it has to do with rounded corsers, as we get the following error : System.Windows.Forms.XplatUICarbon.SetClipRegion not implemented We'v also found a bug report from Mono 1.9 , back in august 2008 describing this problem - so our question is when can we expect this issue to be solved, or is there a workaround for it ? ( Beside not using round corner) Best Wishes /ThomasBF -- View this message in context: http://www.nabble.com/Rounded-corners-on-Mac-OSX-tp21521467p21521467.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to mono-mman.c to accommodate Android, bug report for Arm thunk handling
Hello again! Android's libc has an implementation of mmap, but does not implement shmem functions. Instead Android uses a different implementation of memory sharing called ashmem. mono-mman.c assumes that if mmap is available/implemented, so is shm_open. This change further reorganizes the code so that mmap and and shm_open are uncoupled (as they are not really dependent on each other). This allows Mono on Android to use mmap instead of malloc. Incidentally, this change came out of necessity: if mmap is not available, Mono falls back to using the malloc based implementation of mono_valloc. The problem with malloc is that it exposed a bug in the Arm thunk handling: If the delta between the of a branch-and-link and the target's instruction pointer is greater than 0x1ff, it will attempt to utilize a thunk to explicitly set the program counter to the target. The problem with this is that the number of entries in the thunk table is hard coded to (code chunk length / 8). So if the intended thunk table fills up due to numerous thunks, it will check the other tables that are available. This is where malloc and mmap seem to behave differently: * mmap seems to provide sequential memory addresses with every successive call to the function. This works out well, since then the original branch-and-link that is being modified is in branch range of thunk tables that were created for other code chunks. * malloc , at least on Android, seems to provide wildly different addresses with each successive call (in a deterministic manner it seems). In my case, it starts out providing addresses in the 0x0070 range. Then the addresses jump up into the 0x4000 range. This is where if a thunk table fills up, and Mono can't find a suitable thunk slot (one that is in branch range), it fails at the assert in mini-arm.c:handle_thunk:~2035. So, although this bug exists for any Arm build, this patch just keeps it from surfacing on Android (for now). I looked into actually fixing this properly, because it is possible that it could occur with mmap (it is just very unlikely). But from my investigation, the changes would be too deep (changes to arm_patch, and more). And I'm not familiar enough with the code... yet. :) Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ androidmono.patch Description: androidmono.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch to mono-mman.c to accommodate Android, bug report for Arm thunk handling
Hi, This is now in SVN. Zoltan 2009/1/21 Koushik K. Dutta ko...@koushikdutta.com: Hello again! Android's libc has an implementation of mmap, but does not implement shmem functions. Instead Android uses a different implementation of memory sharing called ashmem. mono-mman.c assumes that if mmap is available/implemented, so is shm_open. This change further reorganizes the code so that mmap and and shm_open are uncoupled (as they are not really dependent on each other). This allows Mono on Android to use mmap instead of malloc. Incidentally, this change came out of necessity: if mmap is not available, Mono falls back to using the malloc based implementation of mono_valloc. The problem with malloc is that it exposed a bug in the Arm thunk handling: If the delta between the of a branch-and-link and the target's instruction pointer is greater than 0x1ff, it will attempt to utilize a thunk to explicitly set the program counter to the target. The problem with this is that the number of entries in the thunk table is hard coded to (code chunk length / 8). So if the intended thunk table fills up due to numerous thunks, it will check the other tables that are available. This is where malloc and mmap seem to behave differently: · mmap seems to provide sequential memory addresses with every successive call to the function. This works out well, since then the original branch-and-link that is being modified is in branch range of thunk tables that were created for other code chunks. · malloc , at least on Android, seems to provide wildly different addresses with each successive call (in a deterministic manner it seems). In my case, it starts out providing addresses in the 0x0070 range. Then the addresses jump up into the 0x4000 range. This is where if a thunk table fills up, and Mono can't find a suitable thunk slot (one that is in branch range), it fails at the assert in mini-arm.c:handle_thunk:~2035. So, although this bug exists for any Arm build, this patch just keeps it from surfacing on Android (for now). I looked into actually fixing this properly, because it is possible that it could occur with mmap (it is just very unlikely). But from my investigation, the changes would be too deep (changes to arm_patch, and more). And I'm not familiar enough with the code… yet. J Koushik Dutta www.koushikdutta.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Build break for PPC64 mono
A resent change to mini/mini-trampoline.c committed in revision 123914 causes the following build failure while build mono for PPC64: MCS [net_1_1] mcs.exe cp mcs.exe.config ./../class/lib/net_1_1/mcs.exe.config ecore.cs(2111,31): warning CS0169: The private field `Mono.CSharp.ClassCast.forced' is assigned but its value is never used expression.cs(5264,22): warning CS0649: Field `Mono.CSharp.New.is_type_parameter' is never assigned to, and will always have its default value `false' Unhandled Exception: System.ExecutionEngineException: SIGILL this failure does not occur in the PPC32 build. The attached patch reverts the change and fixes this build break: diff -urN mono-svn-rx123914/mono/mono/mini/mini-trampolines.c mono-svn-rx123913/mono/mono/mini/mini-trampolines.c --- mono-svn-rx123914/mono/mono/mini/mini-trampolines.c 2009-01-20 21:04:23.0 -0600 +++ mono-svn-rx123913/mono/mono/mini/mini-trampolines.c 2009-01-20 21:22:18.0 -0600 @@ -645,7 +645,7 @@ delegate-invoke_impl = mono_get_addr_from_ftnptr (code); mono_debugger_trampoline_compiled (m, delegate-invoke_impl); - return code; + return mono_get_addr_from_ftnptr (code); } #endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build break for PPC64 mono
Hi, That change was reverted because it was breaking the ia64 build. I asked Mark to solve this by modifying the ppc trampoline code. Until that happens, I put back the change inside an #ifdef ppc64, so the build should work now. Zoltan 2009/1/21 Steven Munroe munro...@us.ibm.com: A resent change to mini/mini-trampoline.c committed in revision 123914 causes the following build failure while build mono for PPC64: MCS [net_1_1] mcs.exe cp mcs.exe.config ./../class/lib/net_1_1/mcs.exe.config ecore.cs(2111,31): warning CS0169: The private field `Mono.CSharp.ClassCast.forced' is assigned but its value is never used expression.cs(5264,22): warning CS0649: Field `Mono.CSharp.New.is_type_parameter' is never assigned to, and will always have its default value `false' Unhandled Exception: System.ExecutionEngineException: SIGILL this failure does not occur in the PPC32 build. The attached patch reverts the change and fixes this build break: ___ 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] [PATCH] verifier vs literal/init-only fields
Hi Rodrigo,
This small patch add a few checks to the verifier about literal/init-only
fields :
- checks that literal field never stsfld/ldsflda.
- checks that instance init-only field do not stfld outside constructor of
declaring type.
- checks that no static field stfld.
(I'm not sure how the verifier testsuite builds/runs so I may need some info
about that if you'd like me to add tests to the patch;)
Cheers,
commit 52d6eb7a54a45064dd12592c18296b6db162733b
Author: Cedric Vivier cedr...@neonux.com
Date: Wed Jan 21 13:38:27 2009 +0800
2009-01-21 Cedric Vivier cedr...@neonux.com
* verify.c: Check a literal field is never stored or address loaded.
Also check that a instance init-only field not stored from outside constructor.
---
mono/metadata/ChangeLog |5 +
mono/metadata/verify.c | 28 +++-
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/mono/metadata/ChangeLog b/mono/metadata/ChangeLog
index c0705c2..5e19b73 100644
--- a/mono/metadata/ChangeLog
+++ b/mono/metadata/ChangeLog
@@ -1,5 +1,10 @@
+2009-01-21 Cedric Vivier cedr...@neonux.com
+
+ * verify.c: Check a literal field is never stored or address loaded.
+ Also check that a instance init-only field not stored from outside constructor.
+
2009-01-21 Mark Probst mark.pro...@gmail.com
* reflection.c (resolve_object): For fields, inflate the class and
then get the field in the inflated class.
diff --git a/mono/metadata/verify.c b/mono/metadata/verify.c
index 047f69f..d3481fb 100644
--- a/mono/metadata/verify.c
+++ b/mono/metadata/verify.c
@@ -3295,10 +3295,16 @@ do_push_static_field (VerifyContext *ctx, int token, gboolean take_addr)
if (!(field-type-attrs FIELD_ATTRIBUTE_STATIC)) {
ADD_VERIFY_ERROR (ctx, g_strdup_printf (Cannot load non static field at 0x%04x, ctx-ip_offset));
return;
}
+
+ if (field-type-attrs FIELD_ATTRIBUTE_LITERAL) {
+ ADD_VERIFY_ERROR (ctx, g_strdup_printf (Cannot take the address of a literal field at 0x%04x, ctx-ip_offset));
+ return;
+ }
+
/*taking the address of initonly field only works from the static constructor */
if (take_addr (field-type-attrs FIELD_ATTRIBUTE_INIT_ONLY)
!(field-parent == ctx-method-klass (ctx-method-flags (METHOD_ATTRIBUTE_SPECIAL_NAME | METHOD_ATTRIBUTE_STATIC)) !strcmp (.cctor, ctx-method-name)))
CODE_NOT_VERIFIABLE (ctx, g_strdup_printf (Cannot take the address of a init-only field at 0x%04x, ctx-ip_offset));
@@ -3326,12 +3332,22 @@ do_store_static_field (VerifyContext *ctx, int token) {
if (!(field-type-attrs FIELD_ATTRIBUTE_STATIC)) {
ADD_VERIFY_ERROR (ctx, g_strdup_printf (Cannot store non static field at 0x%04x, ctx-ip_offset));
return;
}
+ if ((field-type-attrs FIELD_ATTRIBUTE_LITERAL)) {
+ ADD_VERIFY_ERROR (ctx, g_strdup_printf (Cannot store literal field at 0x%04x, ctx-ip_offset));
+ return;
+ }
+
+ /*storing an initonly field only works from the static constructor */
+ if ((field-type-attrs FIELD_ATTRIBUTE_INIT_ONLY)
+ !(field-parent == ctx-method-klass (ctx-method-flags (METHOD_ATTRIBUTE_SPECIAL_NAME | METHOD_ATTRIBUTE_STATIC)) !strcmp (.cctor, ctx-method-name)))
+ CODE_NOT_VERIFIABLE (ctx, g_strdup_printf (Cannot store init-only field at 0x%04x, ctx-ip_offset));
+
if (field-type-type == MONO_TYPE_TYPEDBYREF) {
- ADD_VERIFY_ERROR (ctx, g_strdup_printf (Typedbyref field is an unverfiable type in store static field at 0x%04x, ctx-ip_offset));
+ ADD_VERIFY_ERROR (ctx, g_strdup_printf (Typedbyref field is an unverifiable type in store static field at 0x%04x, ctx-ip_offset));
return;
}
if (!IS_SKIP_VISIBILITY (ctx) !mono_method_can_access_field_full (ctx-method, field, NULL))
CODE_NOT_VERIFIABLE2 (ctx, g_strdup_printf (Type at stack is not accessible at 0x%04x, ctx-ip_offset), MONO_EXCEPTION_FIELD_ACCESS);
@@ -3428,10 +3444,20 @@ do_store_field (VerifyContext *ctx, int token)
obj = stack_pop_safe (ctx);
if (!check_is_valid_type_for_field_ops (ctx, token, obj, field, stfld))
return;
+ if ((field-type-attrs FIELD_ATTRIBUTE_STATIC)) {
+ ADD_VERIFY_ERROR (ctx, g_strdup_printf (Cannot store static field at 0x%04x, ctx-ip_offset));
+ return;
+ }
+
+ /*storing an initonly field only works from a constructor of declaring type*/
+ if ((field-type-attrs FIELD_ATTRIBUTE_INIT_ONLY)
+ !(field-parent == ctx-method-klass mono_method_is_constructor (ctx-method)))
+ CODE_NOT_VERIFIABLE (ctx, g_strdup_printf (Cannot store init-only field at 0x%04x, ctx-ip_offset));
+
if (!verify_stack_type_compatibility (ctx, field-type, value))
CODE_NOT_VERIFIABLE (ctx, g_strdup_printf (Incompatible type %s in field store at 0x%04x, stack_slot_get_name (value), ctx-ip_offset));
}
/*TODO proper handle for NullableT*/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
