Re: [Mono-dev] Build Microsoft Visual Studio Solution under Mono
Hi, I suggest you start here: http://www.mono-project.com/Main_Page Especially: http://mono-project.com/Start http://mono-project.com/FAQ:_General http://mono-project.com/Moma But to give you a quick answer, .NET binaries produced by Visual Studio will run under Mono depending on the feature set used. MoMA will analyse these binaries and tell you if they use any features that aren't currently supported under Mono. Regards, Matt. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of The87Boy Sent: 25 March 2010 9:34 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Build Microsoft Visual Studio Solution under Mono I have developed a program under Microsoft Visual Studio, but as I have to move the Business and Data-part to the server, I need it to compile to Mono as the server runs Linux. The reason is, that I will only allow DB-Connection on Localhost. My question is now, how do I compile the program? Are there any programs to develop to Mono, I can use under Windows, or how can I do this? I hope you understand my question -- View this message in context: http://n4.nabble.com/Build-Microsoft-Visual- Studio-Solution-under-Mono-tp1691343p1691343.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] System.Core/Test/System.Linq.Expressions/ExpressionTest_Lambda.cs misplaced #endif
Index: class/System.Core/Test/System.Linq.Expressions/ExpressionTest_Lambda.cs === --- class/System.Core/Test/System.Linq.Expressions/ExpressionTest_Lambda.cs (revision 155030) +++ class/System.Core/Test/System.Linq.Expressions/ExpressionTest_Lambda.cs (working copy) @@ -280,6 +280,6 @@ Assert.AreEqual (ExpressionType.Constant, q.NodeType); } +#endif } -#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 Microsoft Visual Studio Solution under Mono
A visual studio compiled binary and mono compiled binary are more or less identical. Just copy/paste the compiled code to a linux system and execute it there. Alan. On Thu, Apr 8, 2010 at 9:17 AM, Matt Dargavel m...@shout-telecoms.com wrote: Hi, I suggest you start here: http://www.mono-project.com/Main_Page Especially: http://mono-project.com/Start http://mono-project.com/FAQ:_General http://mono-project.com/Moma But to give you a quick answer, .NET binaries produced by Visual Studio will run under Mono depending on the feature set used. MoMA will analyse these binaries and tell you if they use any features that aren't currently supported under Mono. Regards, Matt. -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of The87Boy Sent: 25 March 2010 9:34 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Build Microsoft Visual Studio Solution under Mono I have developed a program under Microsoft Visual Studio, but as I have to move the Business and Data-part to the server, I need it to compile to Mono as the server runs Linux. The reason is, that I will only allow DB-Connection on Localhost. My question is now, how do I compile the program? Are there any programs to develop to Mono, I can use under Windows, or how can I do this? I hope you understand my question -- View this message in context: http://n4.nabble.com/Build-Microsoft-Visual- Studio-Solution-under-Mono-tp1691343p1691343.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-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Threading parameters? Fill a DataGridView via Invoke very slow
Can you provide a testcase demonstrating the issue. Thanks, Alan. On Thu, Mar 25, 2010 at 2:59 PM, Stifu st...@free.fr wrote: MonoDevelop on Windows uses .NET by default, not Mono. boolean wrote: Another solution with delegates instead of invoke brings no advantages. It´s curious on Windows and Mono Develop it´s comperable fast like on .NET. -- View this message in context: http://n4.nabble.com/Threading-parameters-Fill-a-DataGridView-via-Invoke-very-slow-tp1680691p1690764.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] Socket.BeginReceive never throw Exception
Can you provide a testcase demonstrating the bug or more clearly explain what you mean by using code samples? Thanks, Alan On Wed, Mar 24, 2010 at 1:50 AM, Pigo Chu pigo_...@hotmail.com wrote: I am designing a simple http server use Async Socket model. And test performance use ab (apache benchmark) Like ab -c 1000 -n 10 -k http://myserver... when ab request end , but my http server never got disconnect signal many times. Why happend this ? because Socket.BeginReceive no throw exception when I have not write try ... catch code But on MS.Net , Socket.BeginReceive will throw exception when I have not write try catch My test os is ubuntu 9.10 , mono version is 2.4.2.3 This bug also happend on mono 2.6.3 with debian 5. -- View this message in context: http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1679973.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] Error compiling WebConnection.cs
This is a known issue in our build system. run make clean and/or make distclean and then autogen and build again. That'll resolve the problem. Alan. On Mon, Mar 1, 2010 at 10:03 PM, Neale Ferguson ne...@sinenomine.net wrote: Just updated to head, did get-monolite-latest and getting this during the build: System.Net/WebConnection.cs(361,82): error CS0246: The type or namespace name `CertificateValidationCallback2' could not be found. Are you missing a using directive or an assembly reference? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono process crashes after closing client socket
Hey, Firstly, could you try with a newer mono. If there is a bug in 2.0, there's not a chance of a new 2.0 release being made and it's also quite possible that the issue has been fixed since then. If the bug is still there in mono 2.6+ then file a bug report with all relevant info. You could also try running your app in GDB (http://www.mono-project.com/Debugging) to try and catch the place where it blows up. Alan. On Thu, Feb 19, 2009 at 3:46 PM, FirstName LastName mousse_...@hotmail.com wrote: Hi, I'm working with mono 2.0 on a ARM. I'm seeing a strange problem. I have a client application that receives a HTTP MJPEG stream from my ARM. Sometimes, when closing the client, the tcp socket is properly handled in mono. But sometimes, the mono process stop instantly with no trace. I noticed that in this situation, every time it happens, the signal SIG_PIPE is raised. So, my question is: 1) Does mono handle gracefully the SIG_PIPE signal? Thanks. Upgrade to Hotmail Plus and share more photos with bigger attachments. Click here to find out how Click here to find out how ___ 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] Threading parameters? Fill a DataGridView via Invoke very slow
Hello, You should try Mono 2.6, because I remember that DataGridView had some performance problems regarding population that I fixed after 2.4.x . Kind Regards, Ivan Zlatev http://ivanz.com On Wed, Mar 24, 2010 at 3:18 PM, boolean patrick.kog...@eads.com wrote: Hello, I use Ubuntu and Mono 2.4.x and want to fill a DataGridView with xml data messages. There above 1000 message lines in xml. The DataGridView element is filled by an invoke call from a background worker which iterate through all messages. On Windows and .NET this needs only seconds to fill, but on Ubuntu and Mono this needs above minutes... What can I do? There perhaps any parameters to optimize threading? Thanks. -- View this message in context: http://n4.nabble.com/Threading-parameters-Fill-a-DataGridView-via-Invoke-very-slow-tp1680691p1680691.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] Summer of Code / C++ Interop
Dear Mr. de Icaza and the Mono Developer Community, First, I would like to salute you for producing an excellent, open platform for software development. Second, I would like to apologize for bothering anyone who is not interested in a student's proposal to improve it. I appreciate your time and any feedback you might give. I am proposing to expand Mono's C++ interop support to enable the creation of managed wrappers directly around native C++ objects. This would make C++ libraries callable directly from managed code without the need for wrapping them in a flat C API, COM interface, or requiring the use of mixed binaries (C++/CLI). In fact, this could also provide a way to implement the C++/CLI language, including IJW, in a cross-platform manner. The first place I read about calling C++ functions directly from managed code was on Mono's Interop with Native Librarieshttp://www.mono-project.com/Interop_with_Native_Libraries#Invoking_Unmanaged_Code page. It suggested setting the EntryPoint of the DllImport attribute to the C++ mangled function name to call that function directly through P/Invoke. However, it wasn't until I read this blog posthttp://blogs.msdn.com/vcblog/archive/2008/12/08/inheriting-from-a-native-c-class-in-c.aspxby Jim Springfield that I realized that, not only could this be a viable technique, but that by messing with virtual tables, native C++ classes could effectively be subclassed by managed code. This technique could allow for seamless managed wrappers around native C++ classes. Jim Springfield's example is tied completely to Microsoft's Visual C++ compiler, and this illustrates the largest problem with this approach: that C++ ABIs are different among different compilers and even between different versions of the same compiler. To help ameliorate this issue, I have taken the basic principles in Springfield's design and abstracted out any ABI-specific components into an abstract class. A different subclass of this CppAbi class can then be implemented to support each compiler's different name mangling schemes and other idiosyncrasies. At runtime, the correct CppAbi instance can be chosen when loading the C++ library depending on platform or other conditions. Reflection.Emit is then used to generate the P/Invoke code and implement trampolines to facilitate virtual method calls. Eventually I hope to support seamless exception handling and other features supported by C++/CLI on Windows. I realize this sounds very ambitious, but I've already implemented a proof-of-concept based on a simple C++ class, similar to the one Jim Springfield uses in his example. It is hosted on Google code at http://code.google.com/p/cppinterop/. Please note that this really is just a proof-of-concept-- I've only implemented the Itanium C++ ABIhttp://www.codesourcery.com/public/cxx-abi/abi.html, and only in part. If you are using a recent version of GCC to compile C++, you should be able to compile the example and call it directly from managed code. I've only tested this on an Intel Mac running OS X 10.4.11. I would include some details about myself, but I feel like this email is already long enough. So if there is anything in particular you would like to know, or any feedback you might have, please feel free to contact me. Thank you very much for your time. Sincerely, Alexander Corrado Undergraduate Student at the University of Oregon alexander.corr...@gmail.com http://code.google.com/p/cppinterop/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
Hi again, I'm just going through my outstanding local changes against the latest CVS. Did you have chance to revisit the AutoResetEvent issue as mentioned below? I've attached a new patch against the latest revision to show the changes. Also, I don't think the properties patch (my version or your version) got applied in the end? I saw it got rolled back due to a regression. If you could point me in the right direction I'd be happy to look in to this in a bit more. Regards, Matt. -Original Message- From: Matt Dargavel Sent: 24 March 2010 12:29 PM To: 'Atsushi Eno' Cc: mono-devel-list@lists.ximian.com Subject: RE: [PATCH] WCF multithreaded and property handling The problem I was trying to fix was that it's possible for wait to be set to null after: if (wait != null) and before: wait.WaitOne(...) causing a null reference exception. Looking at MSDN it sounds like an AutoResetEvent should remain signalled until a thread calls WaitOne? The problem is if another thread sets the event when it is already set. If this happens the second Set has no effect. I don't think that's an issue here as the only place that sets the event is the result of the operation we're starting? You're right that the waiting.Count 0 check should have stayed in there. My thanks to you for all the work you've put in to WCF- in case you're interested in how it's being used we're embedding a WCF web service in to one of our core products (a SIP Switch) and then providing a set of web pages that allow users to manage it. Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 24 March 2010 10:58 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF multithreaded and property handling After examining the patch, I have applied some parts of your patch. -wait = new AutoResetEvent (false); -source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); -if (wait != null) // in case callback is done before WaitOne() here. -return wait.WaitOne (timeout, false); -return waiting.Count 0; +var wait_ = new AutoResetEvent (false); +wait = wait_;// wait can be set to null if HttpContextAcquired runs to completion before we do WaitOne +source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); +var result = wait_.WaitOne (timeout, false); +return result; This change is wrong. Since it is AutoResetEvent, it must not call WaitOne() if it has already finished (SignalAsyncWait). And It it set to null when SignalAsyncWait() is done. Also, it should not depend on specific GetHttpContextAsync() call result, as another async call may receive a context (hence waiting.Count 0). I think I have answered to all non-committed parts of your patch, but further comments are welcome. Thanks again for the patch. You're hero, few people dig in such depth into the WCF core engine :) Atsushi Eno On 2010/03/23 22:33, Matt Dargavel wrote: Ok, no problem. I can break them down more. You're right, I can provide no guarantees about the Thread.Sleep removal! But it could have been related to locking registered_channels instead of pending? I did quite a bit of multithreaded testing, and there were no problems; but I take your point. I implemented new functions rather than overriding Properties for a few reasons. I wanted to be sure that I found everywhere that used the properties mechanism to check there were no unwanted side effects, and to make it more obvious something a little special was going on. Also I thought that using a function hides the implementation from other classes. For example, the .NET documentation states that ChannelListenerBase should search for the property and then delegate down the stack if it can't find it, so I could see a scenario where only certain properties were passed to / from inner channels. But I guess that's refactoring and personal preference rather than a minimum change fix. :-) I can delve in to the test code and come up with some test cases for the properties fix, but unfortunately I think it'll be impossible to write test cases for the multithreading issues. Cheers, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:50 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF multithreaded and property handling Hello, Thanks for the patch. They are looking like a great set of attempts for cool bugfixes :) However
Re: [Mono-dev] BindingList nor BindingSource attach to INotifyPropertyChanged-based child properties' PropertyChanged event
Hey, No reason for this to be, really. That feature is simply missing and is waiting for someone to implement it. I have seen your bug report and had a quick look at the BindingList implementation (e.g. http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/System/System.ComponentModel//BindingList.cs ) and it seems easy to fix. Unfortunately I don't really have the time on my hands at the moment. Alternatively you can do it yourself if you feel like it and contribute a patch, which I can review. Otherwise I might have some time over the weekend to take a look at this but there are also some datagridview bugs I want to fix, so no promises. Let me know if you want to work on this. Kind Regards, Ivan Zlatev http://ivanz.com On Wed, Mar 3, 2010 at 9:10 PM, Kurt Wachowski kwachow...@gmail.com wrote: BindingSource ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Threading parameters? Fill a DataGridView via Invoke very slow
Hello, You should try Mono 2.6, because I remember that DataGridView had some performance problems regarding population that I fixed after 2.4.x . Kind Regards, Ivan Zlatev http://ivanz.com On Wed, Mar 24, 2010 at 3:18 PM, boolean patrick.kog...@eads.com wrote: Hello, I use Ubuntu and Mono 2.4.x and want to fill a DataGridView with xml data messages. There above 1000 message lines in xml. The DataGridView element is filled by an invoke call from a background worker which iterate through all messages. On Windows and .NET this needs only seconds to fill, but on Ubuntu and Mono this needs above minutes... What can I do? There perhaps any parameters to optimize threading? Thanks. -- View this message in context: http://n4.nabble.com/Threading-parameters-Fill-a-DataGridView-via-Invoke-very-slow-tp1680691p1680691.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] Summer of Code / C++ Interop
Hey, Join us in the #monosoc channel on irc (http://www.mono-project.com/IRC). Also, I believe the deadline for proposals is tomorrow so you should probably submit a proposal asap which can be updated/modified later on as required. If you miss that deadline, there's not a chance of the project being selected. Alan. On Thu, Apr 8, 2010 at 10:25 AM, Alex Corrado alexander.corr...@gmail.com wrote: Dear Mr. de Icaza and the Mono Developer Community, First, I would like to salute you for producing an excellent, open platform for software development. Second, I would like to apologize for bothering anyone who is not interested in a student's proposal to improve it. I appreciate your time and any feedback you might give. I am proposing to expand Mono's C++ interop support to enable the creation of managed wrappers directly around native C++ objects. This would make C++ libraries callable directly from managed code without the need for wrapping them in a flat C API, COM interface, or requiring the use of mixed binaries (C++/CLI). In fact, this could also provide a way to implement the C++/CLI language, including IJW, in a cross-platform manner. The first place I read about calling C++ functions directly from managed code was on Mono's Interop with Native Libraries page. It suggested setting the EntryPoint of the DllImport attribute to the C++ mangled function name to call that function directly through P/Invoke. However, it wasn't until I read this blog post by Jim Springfield that I realized that, not only could this be a viable technique, but that by messing with virtual tables, native C++ classes could effectively be subclassed by managed code. This technique could allow for seamless managed wrappers around native C++ classes. Jim Springfield's example is tied completely to Microsoft's Visual C++ compiler, and this illustrates the largest problem with this approach: that C++ ABIs are different among different compilers and even between different versions of the same compiler. To help ameliorate this issue, I have taken the basic principles in Springfield's design and abstracted out any ABI-specific components into an abstract class. A different subclass of this CppAbi class can then be implemented to support each compiler's different name mangling schemes and other idiosyncrasies. At runtime, the correct CppAbi instance can be chosen when loading the C++ library depending on platform or other conditions. Reflection.Emit is then used to generate the P/Invoke code and implement trampolines to facilitate virtual method calls. Eventually I hope to support seamless exception handling and other features supported by C++/CLI on Windows. I realize this sounds very ambitious, but I've already implemented a proof-of-concept based on a simple C++ class, similar to the one Jim Springfield uses in his example. It is hosted on Google code at http://code.google.com/p/cppinterop/. Please note that this really is just a proof-of-concept-- I've only implemented the Itanium C++ ABI, and only in part. If you are using a recent version of GCC to compile C++, you should be able to compile the example and call it directly from managed code. I've only tested this on an Intel Mac running OS X 10.4.11. I would include some details about myself, but I feel like this email is already long enough. So if there is anything in particular you would like to know, or any feedback you might have, please feel free to contact me. Thank you very much for your time. Sincerely, Alexander Corrado Undergraduate Student at the University of Oregon alexander.corr...@gmail.com http://code.google.com/p/cppinterop/ ___ 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] some sysctl fixes for OpenBSD
Robert,
I tried to reach you using your email but I get tons of errors.
Are you able to build latest Mono on OpenBSD now? Are you going to
maintain it?
Thanks,
pablo
On 08/04/2010 10:42, Robert Nagy wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
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] [PATCH] Fix CompareExchange inlining for I8
Hi,
Fixed in SVN HEAD r155039 and mono-2-6 r155040.
Kornél
Miguel de Icaza wrote:
Hello,
Would you mind backporting this to the 2-6 branch as well?
2010/4/7 Kornél Pál kornel...@gmail.com:
Hi,
Currently CompareExchange for I8 is never inlined because of a typo.
Note that other Interlocked methods use SIZEOF_REGISTER while this use the
size of pointer and I don't know which one of these is the right one since
both registers and pointers are involved.
Please review the patch.
Kornél
Index: method-to-ir.c
===
--- method-to-ir.c (revision 154913)
+++ method-to-ir.c (working copy)
@@ -4252,7 +4252,7 @@
size = 4;
else if (is_ref || fsig-params [1]-type ==
MONO_TYPE_I)
size = sizeof (gpointer);
- else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I4)
+ else if (sizeof (gpointer) == 8 fsig-params
[1]-type == MONO_TYPE_I8)
size = 8;
if (size == 4) {
MONO_INST_NEW (cfg, ins, OP_ATOMIC_CAS_I4);
___
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] some sysctl fixes for OpenBSD
Hey
Yeah we have been using it for quiet some time now. Both 2.6.3 and svn HEAD
works just fine now.
On (2010-04-08 12:51), pablosantosl...@terra.es wrote:
Robert,
I tried to reach you using your email but I get tons of errors.
Are you able to build latest Mono on OpenBSD now? Are you going to
maintain it?
Thanks,
pablo
On 08/04/2010 10:42, Robert Nagy wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
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] some sysctl fixes for OpenBSD
Cool! We recently added a FreeBSD box to our collection of test machines
and I've a OpenBSD with an old Mono (a port, which compiled at first
shot) but I had some issues (it doesn't work exactly like the FreeBSD
one for some reason). I'd love to see Plastic SCM running on OpenBSD
soon so I'll definitely will give it a try.
pablo
On 08/04/2010 13:33, Robert Nagy wrote:
Hey
Yeah we have been using it for quiet some time now. Both 2.6.3 and svn HEAD
works just fine now.
On (2010-04-08 12:51), pablosantosl...@terra.es wrote:
Robert,
I tried to reach you using your email but I get tons of errors.
Are you able to build latest Mono on OpenBSD now? Are you going to
maintain it?
Thanks,
pablo
On 08/04/2010 10:42, Robert Nagy wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Android: state of the union?
Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. -- View this message in context: http://n4.nabble.com/Mono-on-Android-state-of-the-union-tp1528216p1774004.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono generates inefficient vectorized code
Hello Rodrigo, Just picking up this conversation we had some time ago. I was asking why JIT does unneeded loads and stores and you answered that this behavior is because of lack of global reg allocator. I understand it so that any vreg which is used in different basic blocks is promoted to memory variable and hence gets loaded and stored each time. Then I asked why bare global 'ints' are treated differently (and more effectively) and you said that there are callee-saved iregs so there is a specialized allocator for them. Can you please point at the relevant place in code? On Altivec we have callee-saved vector registers too. Is it possible to use the same trick with them , in order to remove unnecessary loads/stores? -- Regards, Sergei Dyshel On Fri, Mar 12, 2010 at 02:34, Rodrigo Kumpera kump...@gmail.com wrote: On Thu, Mar 11, 2010 at 9:15 PM, Sergei Dyshel qyron.priv...@gmail.comwrote: Hello Rodrigo, Thanks for the quick answer! But do you mean by it that the only problem is in lack of global register allocator? What if 'temp' was not vector but some bare 'int' temporary, would it be loaded and stored in each iteration? Sorry, I hit reply to early. Ints are treated in a separate way. Since some of the scalar registers don't need to be saved across a call, we have a specialized global register allocator for them. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Build Microsoft Visual Studio Solution under Mono
Την Fri, 26 Mar 2010 00:33:44 +0300,ο(η) The87Boy la...@lsmc.dk έγραψε: I have developed a program under Microsoft Visual Studio, but as I have to move the Business and Data-part to the server, I need it to compile to Mono as the server runs Linux. The reason is, that I will only allow DB-Connection on Localhost. My question is now, how do I compile the program? Are there any programs to develop to Mono, I can use under Windows, or how can I do this? You can compile (most) Visual Studio solutions directly on Mono using xbuild from the terminal or the MonoDevelop IDE. There are Windows versions for both. However, binaries compiled on .Net can run on Mono without issue - and vice versa - provided you don't rely on any unimplemented features and don't use p/invokes. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono generates inefficient vectorized code
Hi Sergei, On Thu, Apr 8, 2010 at 11:59 AM, Sergei Dyshel qyron.priv...@gmail.comwrote: Hello Rodrigo, Just picking up this conversation we had some time ago. I was asking why JIT does unneeded loads and stores and you answered that this behavior is because of lack of global reg allocator. I understand it so that any vreg which is used in different basic blocks is promoted to memory variable and hence gets loaded and stored each time. Then I asked why bare global 'ints' are treated differently (and more effectively) and you said that there are callee-saved iregs so there is a specialized allocator for them. Can you please point at the relevant place in code? Look into liveness.c / linear_scan.c. In liveness.c look for mono_analyze_liveness In linear_scan.c look for mono_linear_scan On Altivec we have callee-saved vector registers too. Is it possible to use the same trick with them , in order to remove unnecessary loads/stores? Yes, it might be possible to do so, not sure how much work it will be thou. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MonoDevelop MonoLight debugger
I was able to compile my Silverlight User Control with MonoLight fairly easily. Now I want to run the debugger. However, the page with any info about how to do line by line debugging in MonoDevelop is blank. http://monodevelop.com/Enabling_the_Debugger Who do we have to poke to finish the wiki? Thanks, ~Tim___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] use sysctl for get_boot_time() on *BSD systems and Mac OS X
Tested on OpenBSD and FreeBSD.
Index: mono/utils/mono-time.c
===
--- mono/utils/mono-time.c (revision 155053)
+++ mono/utils/mono-time.c (working copy)
@@ -57,12 +57,32 @@
#include sys/time.h
#endif
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
defined(__NetBSD__)
+#include sys/param.h
+#include sys/sysctl.h
+#endif
+
#include time.h
static gint64
get_boot_time (void)
{
- /* FIXME: use sysctl (kern.boottime) on OSX */
+#if defined(PLATFORM_MACOSX) || defined(__FreeBSD__) || defined(__OpenBSD__)
|| defined(__NetBSD__)
+ int mib [2];
+ size_t size;
+ time_t now;
+ struct timeval boottime;
+
+ (void)time(now);
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_BOOTTIME;
+
+ size = sizeof(boottime);
+
+ if (sysctl(mib, 2, boottime, size, NULL, 0) != -1)
+ return (gint64)((now - boottime.tv_sec) * MTICKS_PER_SEC);
+#else
FILE *uptime = fopen (/proc/uptime, r);
if (uptime) {
double upt;
@@ -73,6 +93,7 @@
}
fclose (uptime);
}
+#endif
/* a made up uptime of 300 seconds */
return (gint64)300 * MTICKS_PER_SEC;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Bug 494234: XplatUIX11.WorkingArea can segfault if the WM does not support _NET_WORKAREA
Hey, The change seems fine, but we need to test it. Will do that this weekend. Thanks, Carlos. 2010/4/3 Brian Pellin bpel...@gmail.com Is there anything I can do to encourage applying the patch in Bug 494234? [1] I get a segfault every time I run KeePass[2] in the xmonad[3] window manager, because it does not support _NET_WORKAREA. This patch fixes it for me. Thanks, Brian [1] https://bugzilla.novell.com/show_bug.cgi?id=494234 [2] http://downloads.sourceforge.net/keepass/KeePass-2.10.zip [3] http://xmonad.org/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Android: state of the union?
I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Android: state of the union?
Koush responded to my tweet saying that he stopped working on it when Novell announced their own plans for Droid bindings. I don't think he ever committed the binding generator code to his git repository. It's a pity, because as a hobbyist mobile developer I certainly couldn't afford the licensing fee for a commercial monodroid license, but given even basic bindings without the kind of Visual Studio/MonoDevelop tooling support one would expect in the official MonoDroid, I could certainly make due. It would be easy to allow the user to replace the runtime on their phone - just distribute the code for the bindings and the eclipse project to build the android package that installs it. I believe that would satisfy the requirements of the LGPL. Or am I missing something? On Thu, Apr 8, 2010 at 1:15 PM, Joe Dluzen jdlu...@gmail.com wrote: I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Android: state of the union?
Is it a given that MonoDroid won't be free? I know MonoTouch isn't, but Mono for MeeGo is free, for example... JeroMiya wrote: Koush responded to my tweet saying that he stopped working on it when Novell announced their own plans for Droid bindings. I don't think he ever committed the binding generator code to his git repository. It's a pity, because as a hobbyist mobile developer I certainly couldn't afford the licensing fee for a commercial monodroid license, but given even basic bindings without the kind of Visual Studio/MonoDevelop tooling support one would expect in the official MonoDroid, I could certainly make due. It would be easy to allow the user to replace the runtime on their phone - just distribute the code for the bindings and the eclipse project to build the android package that installs it. I believe that would satisfy the requirements of the LGPL. Or am I missing something? On Thu, Apr 8, 2010 at 1:15 PM, Joe Dluzen jdlu...@gmail.com wrote: I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://n4.nabble.com/Mono-on-Android-state-of-the-union-tp1528216p1782206.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] use sysctl for get_boot_time() on *BSD systems and Mac OS X
My previous diffs for the 2.6 branch:
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155084)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result, proclength,
NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2250,6 +2256,40 @@
# endif
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-time.c
===
--- mono/utils/mono-time.c (revision 155084)
+++ mono/utils/mono-time.c (working copy)
@@ -57,12 +57,32 @@
#include sys/time.h
#endif
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
defined(__NetBSD__)
+#include sys/param.h
+#include sys/sysctl.h
+#endif
+
#include time.h
static gint64
get_boot_time (void)
{
- /* FIXME: use sysctl (kern.boottime) on OSX */
+#if defined(PLATFORM_MACOSX) || defined(__FreeBSD__) || defined(__OpenBSD__)
|| defined(__NetBSD__)
+ int mib [2];
+ size_t size;
+ time_t now;
+ struct timeval boottime;
+
+ (void)time(now);
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_BOOTTIME;
+
+ size = sizeof(boottime);
+
+ if (sysctl(mib, 2, boottime, size, NULL, 0) != -1)
+ return (gint64)((now - boottime.tv_sec) * MTICKS_PER_SEC);
+#else
FILE *uptime = fopen (/proc/uptime, r);
if (uptime) {
double upt;
@@ -73,6 +93,7 @@
}
fclose (uptime);
}
+#endif
/* a made up uptime of 300 seconds */
return (gint64)300 * MTICKS_PER_SEC;
}
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155084)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct
Re: [Mono-dev] Summer of Code / C++ Interop
Hi, Am 08.04.2010 um 11:25 schrieb Alex Corrado: I am proposing to expand Mono's C++ interop support to enable the creation of managed wrappers directly around native C++ objects. [...] The first place I read about calling C++ functions directly from managed code was on Mono's Interop with Native Libraries page. It suggested setting the EntryPoint of the DllImport attribute to the C+ + mangled function name to call that function directly through P/ Invoke. However, it wasn't until I read this blog post by Jim Springfield that I realized that, not only could this be a viable technique, but that by messing with virtual tables, native C++ classes could effectively be subclassed by managed code. This technique could allow for seamless managed wrappers around native C+ + classes. Jim Springfield's example is tied completely to Microsoft's Visual C+ + compiler, and this illustrates the largest problem with this approach: that C++ ABIs are different among different compilers and even between different versions of the same compiler. To help ameliorate this issue, I have taken the basic principles in Springfield's design and abstracted out any ABI-specific components into an abstract class. A different subclass of this CppAbi class can then be implemented to support each compiler's different name mangling schemes and other idiosyncrasies. At runtime, the correct CppAbi instance can be chosen when loading the C++ library depending on platform or other conditions. Reflection.Emit is then used to generate the P/Invoke code and implement trampolines to facilitate virtual method calls. Eventually I hope to support seamless exception handling and other features supported by C++/CLI on Windows. I realize this sounds very ambitious, but I've already implemented a proof-of-concept based on a simple C++ class, similar to the one Jim Springfield uses in his example. It is hosted on Google code at http://code.google.com/p/cppinterop/ . Please note that this really is just a proof-of-concept-- I've only implemented the Itanium C++ ABI, and only in part. If you are using a recent version of GCC to compile C++, you should be able to compile the example and call it directly from managed code. I've only tested this on an Intel Mac running OS X 10.4.11. I've recently investigated ways to p/invoke C++ code myself and considered going the name-mangling way, so this sounds interesting! Can't comment on whether it's suitable for GSoC though. CSimpleClass.cs looks as if it was written manually. I see a problem with changing C++ code there: To allow managed code to instantiate such a class, your private struct needs to match exactly the size of the native code. If however someone adds a private field in C++ but does not update the interop code, it will fail. Would it be possible to leave the memory allocation to C++ (the ABI document mentions nw in the name-mangling section) and in C# just map the methods we actually want to call? For your proposed project, would you be focussing on the p/invoke ABI infrastructure only? Any plans for SWIG-like autogeneration of the (C#) proxy interfaces from C++ headers? And what about C++ interop inside Mono's class libraries? Regards, Andreas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Android: state of the union?
There might be a possibility that the core runtime will be free, but not the bindings that would let you use the native Android APIs that would allow you to do anything outside of a hello world console program: Quote from Miquel de Icaza: It seems like you can use Mono on the Android today, but there is no binding to their Java-based APIs. At Novell we are going to offer a commercial product to target the Android with the native APIs, but do not have yet a timeline ready. On Thu, Apr 8, 2010 at 3:07 PM, Stifu st...@free.fr wrote: Is it a given that MonoDroid won't be free? I know MonoTouch isn't, but Mono for MeeGo is free, for example... JeroMiya wrote: Koush responded to my tweet saying that he stopped working on it when Novell announced their own plans for Droid bindings. I don't think he ever committed the binding generator code to his git repository. It's a pity, because as a hobbyist mobile developer I certainly couldn't afford the licensing fee for a commercial monodroid license, but given even basic bindings without the kind of Visual Studio/MonoDevelop tooling support one would expect in the official MonoDroid, I could certainly make due. It would be easy to allow the user to replace the runtime on their phone - just distribute the code for the bindings and the eclipse project to build the android package that installs it. I believe that would satisfy the requirements of the LGPL. Or am I missing something? On Thu, Apr 8, 2010 at 1:15 PM, Joe Dluzen jdlu...@gmail.com wrote: I would think that you could develop your own bindings, as there are at least 3 other implementations that I know of. However, like most of us, IANAL. The MonoDroid and the efforts by Koushik Dutta[1] may be one and the same, but I don't know right now. On Novell's side, there is quite literally no information other than we're working on it and here's the name. I'm eagerly watching Koush's RSS for anything Android + Mono related. It appears that the last part of the puzzle which is still missing, is a tool to generate the C# bindings from the Java API. As for the LGPL, the mono runtime binaries installed on the phone should easily be user replaceable. And if it's an open source app, then there's no problem at all. If anyone has any more info, please reply. I'd imagine that many people are waiting for any information at all. Joe [1] http://www.koushikdutta.com/2010/01/androiddll.html Message: 2 Date: Thu, 8 Apr 2010 05:20:16 -0800 (PST) From: JeroMiya bell.jer...@gmail.com Subject: Re: [Mono-dev] Mono on Android: state of the union? To: mono-devel-list@lists.ximian.com Message-ID: 1270732816608-1774004.p...@n4.nabble.com Content-Type: text/plain; charset=us-ascii Would I be allowed to develop my own java bindings (obviously they wouldn't be as high-quality as Novell's commercial product) for mono on android and deploy mono-based applications without licensing Novell's commercial product? Would I subsequently be able to release said bindings under an appropriate open source license? It seems natural to assume so, but you need to be a lawyer to understand software licensing these days. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- View this message in context: http://n4.nabble.com/Mono-on-Android-state-of-the-union-tp1528216p1782206.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] some sysctl fixes for OpenBSD
Applied.
Please send patches as attachments as mail clients screw up the
whitespace.
Zoltan
On Thu, Apr 8, 2010 at 10:42 AM, Robert Nagy rob...@openbsd.org wrote:
Hey
The following diff removes the XXX hacks from the io-layer OpenBSD
specific code and and support for get_process_name_from_proc() too.
It also makes mono-proclib to use the correct kinfo struct.
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155030)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result,
proclength, NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2248,6 +2254,40 @@
proc_name (pid, buf, sizeof(buf));
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155030)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes = malloc (data_len);
void **buf = NULL;
if (size)
@@ -181,11 +187,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2);
+ struct kinfo_proc2 processi;
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc);
+ struct kinfo_proc processi;
#endif /* KERN_PROC2 */
- struct kinfo_proc processi;
memset (buf, 0, len);
___
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] use sysctl for get_boot_time() on *BSD systems and Mac OS X
Applied to SVN HEAD/2.6.
Zoltan
On Thu, Apr 8, 2010 at 5:28 PM, Robert Nagy rob...@openbsd.org wrote:
Tested on OpenBSD and FreeBSD.
Index: mono/utils/mono-time.c
===
--- mono/utils/mono-time.c (revision 155053)
+++ mono/utils/mono-time.c (working copy)
@@ -57,12 +57,32 @@
#include sys/time.h
#endif
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
defined(__NetBSD__)
+#include sys/param.h
+#include sys/sysctl.h
+#endif
+
#include time.h
static gint64
get_boot_time (void)
{
- /* FIXME: use sysctl (kern.boottime) on OSX */
+#if defined(PLATFORM_MACOSX) || defined(__FreeBSD__) ||
defined(__OpenBSD__) || defined(__NetBSD__)
+ int mib [2];
+ size_t size;
+ time_t now;
+ struct timeval boottime;
+
+ (void)time(now);
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_BOOTTIME;
+
+ size = sizeof(boottime);
+
+ if (sysctl(mib, 2, boottime, size, NULL, 0) != -1)
+ return (gint64)((now - boottime.tv_sec) * MTICKS_PER_SEC);
+#else
FILE *uptime = fopen (/proc/uptime, r);
if (uptime) {
double upt;
@@ -73,6 +93,7 @@
}
fclose (uptime);
}
+#endif
/* a made up uptime of 300 seconds */
return (gint64)300 * MTICKS_PER_SEC;
}
___
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] use sysctl for get_boot_time() on *BSD systems and Mac OS X
Applied.
Zoltan
On Thu, Apr 8, 2010 at 9:48 PM, Robert Nagy rob...@openbsd.org wrote:
My previous diffs for the 2.6 branch:
Index: mono/io-layer/processes.c
===
--- mono/io-layer/processes.c (revision 155084)
+++ mono/io-layer/processes.c (working copy)
@@ -1533,7 +1533,7 @@
name[2] = KERN_PROC_ALL;
name[3] = 0;
name[4] = sizeof(struct kinfo_proc2);
- name[5] = 400; /* XXX */
+ name[5] = 0;
#else
struct kinfo_proc *result;
static const int name[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, 0 };
@@ -1543,7 +1543,7 @@
result = NULL;
done = FALSE;
-
+
do {
proclength = 0;
#if defined(__OpenBSD__)
@@ -1558,7 +1558,11 @@
if (result == NULL)
return FALSE;
-
+
+#if defined(__OpenBSD__)
+ name[5] = (int)(proclength / sizeof(struct
kinfo_proc2));
+#endif
+
err = sysctl ((int *) name, size, result,
proclength, NULL, 0);
if (err == 0)
@@ -2224,10 +2228,12 @@
static gchar *get_process_name_from_proc (pid_t pid)
{
+#if !defined(__OpenBSD__)
+ FILE *fp;
gchar *filename = NULL;
+ gchar buf[256];
+#endif
gchar *ret = NULL;
- gchar buf[256];
- FILE *fp;
#if defined(PLATFORM_SOLARIS)
filename = g_strdup_printf (/proc/%d/psinfo, pid);
@@ -2250,6 +2256,40 @@
# endif
if (strlen (buf) 0)
ret = g_strdup (buf);
+#elif defined(__OpenBSD__)
+ int mib [6];
+ size_t size;
+ struct kinfo_proc2 *pi;
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_PROC2;
+ mib [2] = KERN_PROC_PID;
+ mib [3] = pid;
+ mib [4] = sizeof(struct kinfo_proc2);
+ mib [5] = 0;
+
+retry:
+ if (sysctl(mib, 6, NULL, size, NULL, 0) 0)
+ return(ret);
+
+ if ((pi = malloc(size)) == NULL)
+ return(ret);
+
+ mib[5] = (int)(size / sizeof(struct kinfo_proc2));
+
+ if ((sysctl (mib, 6, pi, size, NULL, 0) 0) ||
+ (size != sizeof (struct kinfo_proc2))) {
+ if (errno == ENOMEM) {
+ free(pi);
+ goto retry;
+ }
+ return(ret);
+ }
+
+ if (strlen (pi-p_comm) 0)
+ ret = g_strdup (pi-p_comm);
+
+ free(pi);
#else
memset (buf, '\0', sizeof(buf));
filename = g_strdup_printf (/proc/%d/exe, pid);
Index: mono/utils/mono-time.c
===
--- mono/utils/mono-time.c (revision 155084)
+++ mono/utils/mono-time.c (working copy)
@@ -57,12 +57,32 @@
#include sys/time.h
#endif
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
defined(__NetBSD__)
+#include sys/param.h
+#include sys/sysctl.h
+#endif
+
#include time.h
static gint64
get_boot_time (void)
{
- /* FIXME: use sysctl (kern.boottime) on OSX */
+#if defined(PLATFORM_MACOSX) || defined(__FreeBSD__) ||
defined(__OpenBSD__) || defined(__NetBSD__)
+ int mib [2];
+ size_t size;
+ time_t now;
+ struct timeval boottime;
+
+ (void)time(now);
+
+ mib [0] = CTL_KERN;
+ mib [1] = KERN_BOOTTIME;
+
+ size = sizeof(boottime);
+
+ if (sysctl(mib, 2, boottime, size, NULL, 0) != -1)
+ return (gint64)((now - boottime.tv_sec) * MTICKS_PER_SEC);
+#else
FILE *uptime = fopen (/proc/uptime, r);
if (uptime) {
double upt;
@@ -73,6 +93,7 @@
}
fclose (uptime);
}
+#endif
/* a made up uptime of 300 seconds */
return (gint64)300 * MTICKS_PER_SEC;
}
Index: mono/utils/mono-proclib.c
===
--- mono/utils/mono-proclib.c (revision 155084)
+++ mono/utils/mono-proclib.c (working copy)
@@ -22,8 +22,13 @@
#include sys/user.h
#endif
#ifdef HAVE_STRUCT_KINFO_PROC_KP_PROC
-#define kinfo_pid_member kp_proc.p_pid
-#define kinfo_name_member kp_proc.p_comm
+# ifdef KERN_PROC2
+#define kinfo_pid_member p_pid
+#define kinfo_name_member p_comm
+# else
+#define kinfo_pid_member kp_proc.p_pid
+#define kinfo_name_member kp_proc.p_comm
+# endif
#else
#define kinfo_pid_member ki_pid
#define kinfo_name_member ki_comm
@@ -46,11 +51,12 @@
#ifdef KERN_PROC2
int mib [6];
size_t data_len = sizeof (struct kinfo_proc2) * 400;
+ struct kinfo_proc2 *processes = malloc (data_len);
#else
int mib [4];
size_t data_len = sizeof (struct kinfo_proc) * 400;
+ struct kinfo_proc *processes = malloc (data_len);
#endif /* KERN_PROC2 */
- struct kinfo_proc *processes =
[Mono-dev] sh#
What does everyone think about making a new dlr script language that is compatible with sh or bash? Maybe called sh#? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Proposed updates to s390x
Hi, I think these are ok. The throw_exception_by_name stuff is obsolete, it was only kept because s390 continued to use it, so it can be completely removed, along with the definition of MONO_ARCH_HAVE_THROW_EXCEPTION_BY_NAME in mini-s390.h/mini-s390x.h. About exception17, I can't really help with that, maybe unwinding of the stack when an exception is thrown in a finally clause is broken, because the unwinder thinks catcher2 () is called by Main, but it is called by the code generated by mono_arch_get_call_filter (). Zoltan On Thu, Mar 11, 2010 at 4:52 PM, Neale Ferguson nealefergu...@verizon.netwrote: Usually I just svn commit my s390/s390x changes to the repository, but it¹s been awhile since I¹ve committed so I thought it might be safer to publish them for review first before committing. Only one bit of common code is affected and that change is trivial; the rest has to do (mainly) with implementing IMT and fixing some exception handling stuff. I do, however, continue to fail the exception17 test and would appreciate advice on how to track this bugger down (it appears that an exception in catcher1 which had been called by catcher2 is not being caught). ___ 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] Finding the invoked object in a profiler
Hi, This is unfortunately not supported by the current profiler interface. Zoltan On Mon, Apr 5, 2010 at 9:50 PM, Ruben Vermeersch ru...@savanne.be wrote: Hi everyone, I'm currently writing a tool to track the correct disposal of resources in my application. Am doing this by writing a custom profiler using mono's profiling API. As part of this, I need to track when Dispose is called on an object. So I figured I could hook into the enter/leave profiling and evaluate whether we're calling Dispose on each enter. So far so good (that's doable). When this happens, I need to be able to get a reference to the MonoObject on which the Dispose method is invoked (basically this in C#). Haven't found a way to do this though. Is this possible? Anyone want to give me a hint for the right direction? Cheers, Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ 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] sh#
Yes that takes advantage of the dlr to speed things up. Drop it in /bin and speeds up *nix scripts and possibly boot time. John Feminella wrote: That sounds like an interesting idea. By compatible with (sh|bash) do you just mean that it has a shebang-compatible interpreter? ~ jf -- John Feminella Principal Consultant, Distilled Brilliance On Thu, Apr 8, 2010 at 20:29, Jerry Maine - KF5ADY crashfou...@gmail.com wrote: What does everyone think about making a new dlr script language that is compatible with sh or bash? Maybe called sh#? ___ 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
