date:20100408

Re: [Mono-dev] Build Microsoft Visual Studio Solution under Mono

2010-04-08 Thread Matt Dargavel

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] some sysctl fixes for OpenBSD

2010-04-08 Thread Robert Nagy

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 
 #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-dev] System.Core/Test/System.Linq.Expressions/ExpressionTest_Lambda.cs misplaced #endif

2010-04-08 Thread Robert Nagy

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

2010-04-08 Thread Alan McGovern

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  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

2010-04-08 Thread Alan McGovern

Can you provide a testcase demonstrating the issue.

Thanks,
Alan.

On Thu, Mar 25, 2010 at 2:59 PM, Stifu  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

2010-04-08 Thread Alan McGovern

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  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

2010-04-08 Thread Alan McGovern

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  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

2010-04-08 Thread Alan McGovern

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
 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

2010-04-08 Thread Ivan Zlatev

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  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

2010-04-08 Thread Alex Corrado

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
postby
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

Re: [Mono-dev] [PATCH] WCF multithreaded and property handling

2010-04-08 Thread Matt Dargavel

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: m

Re: [Mono-dev] BindingList nor BindingSource attach to INotifyPropertyChanged-based child properties' PropertyChanged event

2010-04-08 Thread Ivan Zlatev

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  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

2010-04-08 Thread Ivan Zlatev

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  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

2010-04-08 Thread Alan McGovern

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
 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

2010-04-08 Thread pablosantosl...@terra.es

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 
>  #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] Threading parameters? Fill a DataGridView via Invoke very slow

2010-04-08 Thread Stifu


As Alan said, a test case would help then.
It would be nice if you could file a bug report along with the test case, so
this bug is not overlooked or forgotten.


boolean wrote:
> 
> Hey,
> 
> after my message I used Mono 2.6.3 to test the performance again. Sadly no
> better performance noticeable.
> 
-- 
View this message in context: 
http://n4.nabble.com/Threading-parameters-Fill-a-DataGridView-via-Invoke-very-slow-tp1680691p1773854.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] [PATCH] Fix CompareExchange inlining for I8

2010-04-08 Thread Kornél Pál

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 :
>> 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

2010-04-08 Thread Robert Nagy

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 
> >  #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

Re: [Mono-dev] some sysctl fixes for OpenBSD

2010-04-08 Thread pablosantosl...@terra.es

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 
>>>  #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 = s

Re: [Mono-dev] Mono on Android: state of the union?

2010-04-08 Thread JeroMiya


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

2010-04-08 Thread Sergei Dyshel

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  wrote:

>
>
> On Thu, Mar 11, 2010 at 9:15 PM, Sergei Dyshel wrote:
>
>> 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

2010-04-08 Thread Stefanos A.

Την Fri, 26 Mar 2010 00:33:44 +0300,ο(η) The87Boy  έγραψε:

>
> 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

2010-04-08 Thread Rodrigo Kumpera

Hi Sergei,

On Thu, Apr 8, 2010 at 11:59 AM, Sergei Dyshel wrote:

> 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

2010-04-08 Thread Timothy Graupmann

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

2010-04-08 Thread Robert Nagy

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 
 #endif
 
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) || 
defined(__NetBSD__)
+#include 
+#include 
+#endif
+
 #include 
 
 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

2010-04-08 Thread Carlos Alberto Cortez

Hey,

The change seems fine, but we need to test it. Will do that this weekend.

Thanks,
Carlos.

2010/4/3 Brian Pellin 

> 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?

2010-04-08 Thread Joe Dluzen

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 
> 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?

2010-04-08 Thread Jeremy Bell

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  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 
> > 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?

2010-04-08 Thread Stifu


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  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 
>> > 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

2010-04-08 Thread Robert Nagy

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 
 #endif
 
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) || 
defined(__NetBSD__)
+#include 
+#include 
+#endif
+
 #include 
 
 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 
 #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_pr

Re: [Mono-dev] Summer of Code / C++ Interop

2010-04-08 Thread Andreas Färber

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?

2010-04-08 Thread Jeremy Bell

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  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  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 
> >> > 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] Improvement to Silverlight/Web-based video editing software project (GSoC)

2010-04-08 Thread Michael Hutchinson

Hi,

The focus of this project is to create the app from scratch - and the
key part is the video editing UI. The distribution ideas you discuss
are interesting, but tangential to the main part of the project. Your
proposal should definitely also explain how you would intend the UI to
work.

- Michael

On Fri, Apr 2, 2010 at 3:53 AM, Adam Walkowski  wrote:
> Hi Everybody,
>
> I have a question about idea of connect the Silverlight/Web-based video
> editing software project proposal (for Google Summer of Code 2010) and some
> of my ideas about distribution media in distracted environment. In general:
> 1. Use automatic compression mechanism to make preview files (considerable
> smaller than original ones) for all media files on server (for example
> builds by FFMpeg libraries).
> 2. Add some metadata to media files (about characters, actors, requisites,
> weather, time of day in record, aspect ratio, bitrate etc.) in XML files.
> 3. Distribute media files in two ways: by streaming compressed (preview)
> files from server to client app (for searching media resources by prepared
> metadata) and by downloading compressed (preview) files to local machine
> (for off-line and faster local montage).
> 4. Render finished projects on server from original media files or by
> downloading original files from server and substitute preview files used
> during montage on local machine.
>
> What do You think about it and this functionality?
>
> I'm fifth year student of Informatics at Faculty of Electronics,
> Telecommunications and Informatics (Specialization: Modeling and Programming
> Informatics Systems at Department of Algorithms and System Modeling) and
> second year student of Management at Faculty of Management and Economics
> (both studies at Gdansk University of Technology, Poland). I have three
> years experience in Java and .NET programming (especially in C#). I have
> participated two times in Microsoft Imagine Cup: in 2009 (category: software
> design, player and editing application for interactive movies) and in 2010
> (two categories, first: game design, strategy game in Silverlight 3
> simulating charity organization; second: Internet Explorer 8 plugin, data
> base of charities and these actions moderate by users). Apart form
> informatics and programming I'm interesting in video montage, computer
> graphics and animations. I try to match my Computer Science studies and
> movie making hobby in my final work at Informatics Faculty. It's connected
> with media distribution (and media data mining) in distracted team work on
> media projects like movies, animations, video and audio commercials, music
> etc.
>
> Cheers,
> Adam Walkowski
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>



-- 
Michael Hutchinson
http://mjhutchinson.com
___
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

2010-04-08 Thread Zoltan Varga

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  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 
>  #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

2010-04-08 Thread Zoltan Varga

Applied to SVN HEAD/2.6.

 Zoltan

On Thu, Apr 8, 2010 at 5:28 PM, Robert Nagy  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 
>  #endif
>
> +#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
> defined(__NetBSD__)
> +#include 
> +#include 
> +#endif
> +
>  #include 
>
>  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

2010-04-08 Thread Zoltan Varga

Applied.

   Zoltan

On Thu, Apr 8, 2010 at 9:48 PM, Robert Nagy  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 
>  #endif
>
> +#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__OpenBSD__) ||
> defined(__NetBSD__)
> +#include 
> +#include 
> +#endif
> +
>  #include 
>
>  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 
>  #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;
> +

[Mono-dev] sh#

2010-04-08 Thread Jerry Maine - KF5ADY

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

2010-04-08 Thread Zoltan Varga

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
wrote:

> 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

2010-04-08 Thread Zoltan Varga

Hi,

  This is unfortunately not supported by the current profiler interface.

Zoltan

On Mon, Apr 5, 2010 at 9:50 PM, Ruben Vermeersch  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#

2010-04-08 Thread Jerry Maine - KF5ADY

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
>  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

40 matches

Mail list logo