Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Alan]

I had vague recollections that there were some ifdefs in the managed code
which made it platform specific, but I could be wrong or they could just be
gone nowadays. Jonp probably knows best ;)

Either way, if you deploy it without the matching native lib you can hit
crashes, so the simplest option all round is to just rely on the system
one, if at all possible :)

Alan

On 30 March 2016 at 13:06, Chris Swiedler <cswied...@trionworlds.com> wrote:

> To Alan's point, we did see crashes when we (unintentionally) deployed
> Mono.Posix.dll along with our app. Our solution was, like he said, to Not
> Do That, and use our Mono.Posix as a compile-time library only.
>
> I do think it's much easier to do it this way than to have different
> compile targets, which (if I'm understanding correctly) is what the other
> suggestions all require.
>
> chris
>
> -Original Message-
> From: mono-devel-list-boun...@lists.ximian.com [mailto:
> mono-devel-list-boun...@lists.ximian.com] On Behalf Of Jonathan Pryor
> Sent: Wednesday, March 30, 2016 7:04 AM
> To: Alan McGovern <alan.mcgov...@gmail.com>
> Cc: mono-devel-list <mono-devel-list@lists.ximian.com>
> Subject: Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix
> reference on Linux
>
> On Mar 30, 2016, at 8:33 AM, Alan <alan.mcgov...@gmail.com> wrote:
> > If you package Mono.Posix.dll your app *will crash* on different systems.
>
> Not necessarily.
>
> > This binary is platform specific and is not safe to copy between OS’s.
>
> Mono.Posix.dll *itself* contains no platform-specific code and is
> perfectly safe to copy between operating systems.
>
> Mono.Posix.dll contains P/Invokes into “MonoPosixHelper”
> (libMonoPosixHelper.dylib on OS X, MonoPosixHelper.dll on Windows, etc.),
> and MonoPosixHelper contains operating system-specific code. It *cannot* be
> copied between operating systems; it’s a native library.
>
> > It's fine to have a copy of Mono.Posix.dll used purely for compilation
> purposes. But at runtime you have to use the system provided one, which
> typically means the one provided by the system's mono installation.
>
> It’s entirely fine to include Mono.Posix.dll with your app, SO LONG AS you
> *also* copy and distribute MonoPosixHelper with your app.
>
> Additionally, Mono.Posix.dll also P/Invokes other native libraries such as
> INTL.DLL (Mono.Unix.Catalog) and MSVCRT.DLL (Mono.Unix.Native.Stdlib),
> which should be usable on Windows (so long as you also distribute INTL.DLL,
> etc.).
>
>  - Jon
>
> ___
> 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] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Alan]

Heya,

If you package Mono.Posix.dll your app *will crash* on different systems.
This binary is platform specific and is not safe to copy between OS's. It
is also matched with a platform specific native binary,
libmonoposixhelper.[dll|dylib|so], which cannot be copied/pasted across
platforms either. If you have a Mono.Posix.dll from one version of mono and
a libmonoposixhelper.[dylib|so|dll] from another mono installation, that
will crash too every time p/invoke signatures change, or other
implementation details change.

It's fine to have a copy of Mono.Posix.dll used purely for compilation
purposes. But at runtime you have to use the system provided one, which
typically means the one provided by the system's mono installation.

Hope that helps!
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

[Alan]

Hey,

We have just fixed some issues in that area. They are expected to ship as
part of a the next mono 4.3+ release. If you want to test them out in the
meantime you could try building mono with this PR [0] and see if it
resolves all your issues. If it doesn't then a testcase and bug report on
http://bugzilla.xamarin.com would be awesome!

Thanks!

[0] https://github.com/mono/mono/pull/2576

On 12 February 2016 at 12:33, Mike Horsley  wrote:

> we’ve also seen instances of webrequest timeouts that don’t recover (but
> curl worked) as well but haven’t got to the bottom of it yet.
>
>
>
> we ran your test app and see the same issue with mono 3.12 on OpenSUSE
> 13.2 (kernel 3.16.7, libc 2.19).
>
>
>
> we’ll add the diagnostics from your test app into ours and this will tell
> us whether we are seeing the same issue with the threadpool.
>
>
>
> regards
>
> Mike
>
>
>
> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Seif Attar
> *Sent:* Friday, February 12, 2016 10:43 AM
> *To:* mono-devel-list@lists.ximian.com
> *Subject:* [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
>
>
>
> Hi,
>
> We are running mono 4.2.2 in prod and the VM that the process was running
> on had SAN failure and after storage recovered, all outgoing requests were
> timing out, even though doing a curl was working fine.
>
> Theory was that thread pool starved and somehow things didn't recover
> properly.
>
> Managed to reproduce with:
>
>
> https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a4bad60fa4818ad32d629/timeout.cs
>
> Even after ThreadPool finishes the tasks and has available threads, it
> never recovers and subsequent webrequests all timeout.
>
> Running on mono 4.2.2, linux kernel 4.2.0-27 and libc 2.21.
>
> Output from gdb is:
>
> (gdb) info threads
>   Id   Target Id Frame
>   13   Thread 0x7fca903ff700 (LWP 27944) "cli" pthread_cond_wait@@GLIBC_2.3.2
> () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>   12   Thread 0x7fca90b34700 (LWP 27945) "Finalizer" 0x7fca911d70c9 in
> futex_abstimed_wait (cancel=true, private=, abstime=0x0,
> expected=0, futex=0x948ae0) at sem_waitcommon.c:42
>   11   Thread 0x7fca8dfff700 (LWP 27946) "Timer-Scheduler"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   10   Thread 0x7fca91ba1700 (LWP 27947) "cli" __clock_nanosleep
> (clock_id=1, flags=1, req=0x7fca91ba0dc0, rem=0x7fca90f134aa
> <__clock_nanosleep+138>) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
>   9Thread 0x7fca8ddfe700 (LWP 27948) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   8Thread 0x7fca8dbfd700 (LWP 27949) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   7Thread 0x7fca8d7fb700 (LWP 27951) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   6Thread 0x7fca8d3f9700 (LWP 27953) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   5Thread 0x7fca8d1f8700 (LWP 27954) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   4Thread 0x7fca8cff7700 (LWP 27955) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   3Thread 0x7fca8cdf6700 (LWP 27956) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>   2Thread 0x7fca8cbf5700 (LWP 27957) "Threadpool work"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
> * 1Thread 0x7fca91cf0780 (LWP 27942) "cli" 0x7fca911d7e0d in read
> () at ../sysdeps/unix/syscall-template.S:81
>
> Could not reproduce on mono 3.12, but it happens on 4.0.3 and 4.2.2
>
> Is this a known issue? any workarounds? Tried setting MONO_DNS=1 to use
> the clr dns, but that didn't help.
>
> Let me know if there is any more info I need to provide.
>
> Thanks,
>
> Seif
>
> ___
> 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] WebRequest timeouts after ThreadPool exhaustion

[Alan]

It's also worth pointing out that the threadpool implementation has changed
completely since mono 4.0. I believe the new threadpool implementation
shipped as the default starting with mono 4.2 (or thereabouts). If you're
on older Monos the odds are high whatever issue you have has been fixed
already.

Alan

On 12 February 2016 at 13:48, Alan <alan.mcgov...@gmail.com> wrote:

> Hey,
>
> We have just fixed some issues in that area. They are expected to ship as
> part of a the next mono 4.3+ release. If you want to test them out in the
> meantime you could try building mono with this PR [0] and see if it
> resolves all your issues. If it doesn't then a testcase and bug report on
> http://bugzilla.xamarin.com would be awesome!
>
> Thanks!
>
> [0] https://github.com/mono/mono/pull/2576
>
> On 12 February 2016 at 12:33, Mike Horsley <mhors...@vqcomms.com> wrote:
>
>> we’ve also seen instances of webrequest timeouts that don’t recover (but
>> curl worked) as well but haven’t got to the bottom of it yet.
>>
>>
>>
>> we ran your test app and see the same issue with mono 3.12 on OpenSUSE
>> 13.2 (kernel 3.16.7, libc 2.19).
>>
>>
>>
>> we’ll add the diagnostics from your test app into ours and this will tell
>> us whether we are seeing the same issue with the threadpool.
>>
>>
>>
>> regards
>>
>> Mike
>>
>>
>>
>> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
>> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Seif Attar
>> *Sent:* Friday, February 12, 2016 10:43 AM
>> *To:* mono-devel-list@lists.ximian.com
>> *Subject:* [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
>>
>>
>>
>> Hi,
>>
>> We are running mono 4.2.2 in prod and the VM that the process was running
>> on had SAN failure and after storage recovered, all outgoing requests were
>> timing out, even though doing a curl was working fine.
>>
>> Theory was that thread pool starved and somehow things didn't recover
>> properly.
>>
>> Managed to reproduce with:
>>
>>
>> https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a4bad60fa4818ad32d629/timeout.cs
>>
>> Even after ThreadPool finishes the tasks and has available threads, it
>> never recovers and subsequent webrequests all timeout.
>>
>> Running on mono 4.2.2, linux kernel 4.2.0-27 and libc 2.21.
>>
>> Output from gdb is:
>>
>> (gdb) info threads
>>   Id   Target Id Frame
>>   13   Thread 0x7fca903ff700 (LWP 27944) "cli" pthread_cond_wait@@GLIBC_2.3.2
>> () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>>   12   Thread 0x7fca90b34700 (LWP 27945) "Finalizer" 0x7fca911d70c9
>> in futex_abstimed_wait (cancel=true, private=, abstime=0x0,
>> expected=0, futex=0x948ae0) at sem_waitcommon.c:42
>>   11   Thread 0x7fca8dfff700 (LWP 27946) "Timer-Scheduler"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   10   Thread 0x7fca91ba1700 (LWP 27947) "cli" __clock_nanosleep
>> (clock_id=1, flags=1, req=0x7fca91ba0dc0, rem=0x7fca90f134aa
>> <__clock_nanosleep+138>) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
>>   9Thread 0x7fca8ddfe700 (LWP 27948) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   8Thread 0x7fca8dbfd700 (LWP 27949) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   7Thread 0x7fca8d7fb700 (LWP 27951) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   6Thread 0x7fca8d3f9700 (LWP 27953) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   5Thread 0x7fca8d1f8700 (LWP 27954) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   4Thread 0x7fca8cff7700 (LWP 27955) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>>   3Thread 0x7fca8cdf6700 (LWP 27956) "Threadpool work"
>> pthread_cond_timedwait@@GLIBC_2.3.2 () at
>> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
>&

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alan]

Can you use a pastebin to attach the actual file you're trying to build?
The text you attached has two syntax errors in it and would not work as-is.

A slightly modified file works as expected for me:
https://gist.github.com/alanmcgovern/c2772a9cafd0d6a5b5ee

Hope that helps!
Alan

On 3 June 2015 at 11:54, Cyd Haselton chasel...@gmail.com wrote:

 I did try xbuild /t:Build Pash.proj. Same result.

 I will try the --trace xbuild after I rebuild mono again.


 On June 3, 2015 3:18:34 AM CDT, Alan alan.mcgov...@gmail.com wrote:

 You didn't tell xbuild to build anything and you didn't set a default
 target in your proj file.

 Try `xbuild /t:Build Pash.proj`

 On 2 June 2015 at 23:29, Alexander Köplinger alex.koeplin...@outlook.com
  wrote:

 Yeah, but it's much easier on another machine since we got the official
 packages for Mono there :)

 Try running xbuild with MONO_OPTIONS=--trace xbuild to show if/what it
 does before it exits.



 --
 Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 17:15:14 -0500
 To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com


 Excellent point.

 Then again...i'd have to install mono on another machine. Also, I kinda
 would like to figure out why xbuild is misbehaving on this one...

 On June 2, 2015 5:04:07 PM CDT, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 No idea about the xbuild issue, but you should be able to build Pash on
 another machine and just copy over the .exe, it is managed code after all
 ;)


 --
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 16:54:19 -0500
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

 Just built and installed mono 4.0 from sources. Basic Hello World
 console program builds and runs successfully but basic Hello World
 project (hello.proj) won't build; xbuild displays the banner and then exits
 with no errors and without building the project.

 Here's the hello.proj
  Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003;;
 Target Name=Build
 Message Importance=High Text=Hello, World! /
 /Target
 /Project

 I;ve tried /verbosity:detailed and several other flags. I've tried
 running path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens
 every time:

 /bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj
 XBuild Engine Version 12.0
 Mono, Version 4.0.0.0
 Copyright (C) 2005-2013 Various Mono authors
 /bld/pash/Pash-Project-Pash-bc07215 $

 Please help...this is driving me crazy.


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alan]

You didn't tell xbuild to build anything and you didn't set a default
target in your proj file.

Try `xbuild /t:Build Pash.proj`

On 2 June 2015 at 23:29, Alexander Köplinger alex.koeplin...@outlook.com
wrote:

 Yeah, but it's much easier on another machine since we got the official
 packages for Mono there :)

 Try running xbuild with MONO_OPTIONS=--trace xbuild to show if/what it
 does before it exits.



 --
 Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 17:15:14 -0500
 To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com


 Excellent point.

 Then again...i'd have to install mono on another machine. Also, I kinda
 would like to figure out why xbuild is misbehaving on this one...

 On June 2, 2015 5:04:07 PM CDT, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 No idea about the xbuild issue, but you should be able to build Pash on
 another machine and just copy over the .exe, it is managed code after all
 ;)


 --
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 16:54:19 -0500
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

 Just built and installed mono 4.0 from sources. Basic Hello World
 console program builds and runs successfully but basic Hello World
 project (hello.proj) won't build; xbuild displays the banner and then exits
 with no errors and without building the project.

 Here's the hello.proj
  Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003;;
 Target Name=Build
 Message Importance=High Text=Hello, World! /
 /Target
 /Project

 I;ve tried /verbosity:detailed and several other flags. I've tried running
 path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens every
 time:

 /bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj
 XBuild Engine Version 12.0
 Mono, Version 4.0.0.0
 Copyright (C) 2005-2013 Various Mono authors
 /bld/pash/Pash-Project-Pash-bc07215 $

 Please help...this is driving me crazy.


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 ___
 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 4.0.0 xbuild won't build project

[Alan]

In the file you linked, a default target is set:
https://github.com/Pash-Project/Pash/blob/master/Pash.proj#L2

That means if you don't specify a target, 'Build' will be executed (in this
case). In the original email i would expect the output to be empty because
no target was specified and no default target was set.

So if there is a bug we will need the actual output (with
/verbosity:diagnostic passed to xbuild) when trying to build the actual
proj file.

Alan

On 3 June 2015 at 12:29, Alexander Köplinger alex.koeplin...@outlook.com
wrote:

  You didn't tell xbuild to build anything and you didn't set a default
 target in your proj file.

 FYI, xbuild/msbuild probes for *.proj/*.sln and builds the first it finds
 when you omit the argument.

  Can you use a pastebin to attach the actual file you're trying to build?

 The project is https://github.com/Pash-Project/Pash which builds fine on
 Linux with Mono on TravisCI, so I guess it's something specific to the
 xbuild on android environment, most likely some runtime issue.

 -- Alex

 --
 Date: Wed, 3 Jun 2015 12:18:11 +0100
 Subject: Re: [Mono-dev] mono 4.0.0 xbuild won't build project
 From: alan.mcgov...@gmail.com
 To: chasel...@gmail.com
 CC: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com


 Can you use a pastebin to attach the actual file you're trying to build?
 The text you attached has two syntax errors in it and would not work as-is.

 A slightly modified file works as expected for me:
 https://gist.github.com/alanmcgovern/c2772a9cafd0d6a5b5ee

 Hope that helps!
 Alan

 On 3 June 2015 at 11:54, Cyd Haselton chasel...@gmail.com wrote:

 I did try xbuild /t:Build Pash.proj. Same result.

 I will try the --trace xbuild after I rebuild mono again.


 On June 3, 2015 3:18:34 AM CDT, Alan alan.mcgov...@gmail.com wrote:

 You didn't tell xbuild to build anything and you didn't set a default
 target in your proj file.

 Try `xbuild /t:Build Pash.proj`

 On 2 June 2015 at 23:29, Alexander Köplinger alex.koeplin...@outlook.com
 wrote:

 Yeah, but it's much easier on another machine since we got the official
 packages for Mono there :)

 Try running xbuild with MONO_OPTIONS=--trace xbuild to show if/what it
 does before it exits.



 --
 Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 17:15:14 -0500
 To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com


 Excellent point.

 Then again...i'd have to install mono on another machine. Also, I kinda
 would like to figure out why xbuild is misbehaving on this one...

 On June 2, 2015 5:04:07 PM CDT, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 No idea about the xbuild issue, but you should be able to build Pash on
 another machine and just copy over the .exe, it is managed code after all
 ;)


 --
 From: chasel...@gmail.com
 Date: Tue, 2 Jun 2015 16:54:19 -0500
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

 Just built and installed mono 4.0 from sources. Basic Hello World
 console program builds and runs successfully but basic Hello World
 project (hello.proj) won't build; xbuild displays the banner and then exits
 with no errors and without building the project.

 Here's the hello.proj
  Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003;;
 Target Name=Build
 Message Importance=High Text=Hello, World! /
 /Target
 /Project

 I;ve tried /verbosity:detailed and several other flags. I've tried running
 path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens every
 time:

 /bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj
 XBuild Engine Version 12.0
 Mono, Version 4.0.0.0
 Copyright (C) 2005-2013 Various Mono authors
 /bld/pash/Pash-Project-Pash-bc07215 $

 Please help...this is driving me crazy.


 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono-2.11.4 on Solaris 11.1

[Alan]

Before submitting pull requests you should check to see if the issue still
exists in the latest code. Mono 2.11.4 was released about 18 months ago.

Alan


On 12 January 2014 01:12, Andrés G. Aragoneses kno...@gmail.com wrote:

 On 11/01/14 22:00, Grüninger, Andreas (LGL Extern) wrote:
  Hi all
 
 
 
  I compiled mono-2.11.4 on Solaris 11.1 and after excluding some tests
  the other tests succeeded. Only 2 failures. I prepared an upstream
  branch with the patches at
  https://github.com/grueni/mono/commits/upstream-mono-2.11.4.

 Why such an old version and not master?


  Should I
  create pull requests?

 Yes.


 ___
 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] Anyone taking care of TPL dataflow?

[Alan]

The BCL is an integral part of the products xamarin provide, of course it
will be maintained! As for TPL Dataflow, it's not a commonly used library
so it doesn't receive as much attention as other libraries. However patches
are always welcome.

The existence of 'bugs' in the 'new' state doesn't mean a tremendous amount
unless that specific bug is affecting you. 'mono' is millions of lines of
code so it's quite likely you will never encounted 99% of the bugs in
bugzilla.

Alan


On 26 December 2013 14:50, Rafael Teixeira mono...@gmail.com wrote:

 I think that starting some bounties at BountySource (
 https://www.bountysource.com/trackers/36297-mono) or some other place may
 yield better results, as I really think Xamarin is focused on mobile...

 Rafael Teixeira
 O..:.)


 On Tue, Dec 24, 2013 at 4:26 AM, Karl He karld...@gmail.com wrote:

 Hi,

 I know Mono is getting its second life due to the brilliant Mobile idea
 (Android/iOS). But it seems that the bcl/server stuff needs some love now.

 We bumped into an issue of TPL dataflow library and submitted an issue
 here:
 https://bugzilla.xamarin.com/show_bug.cgi?id=16940

 After that, I browsed some other 'class library' bugs on
 https://bugzilla.xamarin.com/. Unfortunately there are a huge amount of
 bugs there, and most of them have been there for months with status
 'NEW'... These bugs makes me feel frustrated and weakened the possibility
 of our Mono adoption.

 So,
 1) Specifically, who is taking care of TPL dataflow? What is the expected
 time when such a bug will be fixed?
 2) Any comments on Mono bcl stuff quality? Will Xamarin continue to
 invest on it?

 Thanks a lot,
 Karl He


 ___
 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] Contributing to xbuild

[Alan]

Hey,

The correct thing to do is probably to build the entire mono class
libraries first using the normal procedure for building mono on your OS.
Once that's done you should not need to modify assembly references in the
csproj files. You may need to add missing cs files to the csproj though.

I'm looking forward to your contributions!

Alan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Using profiler in mono 3.0.x (is this still a working feature?)

[Alan]

I believe the GC related profiling options, like allocation tracking
or heap-shot, only work with sgen. The performance related options
work irrespective of the GC being used.

Alan

On 18 March 2013 23:17, Andres G. Aragoneses kno...@gmail.com wrote:
 On 18/03/13 22:57, Esben Laursen wrote:

 Den 18-03-2013 20:59, Jonathan Shore skrev:

 Hi,

 I've used mono --profile… in the past with 2.10.x and did not have
 problems in being able to run.I was trying to run profiling on an
 app again, this time with 3.0.x.   On both osx and linux, I get:

 The 'log' profiler wasn't found in the main executable nor could it be
 loaded from 'mono-profiler-log'.

 I am using a standard build of mono 3.0.x on OSX and then my own build
 on linux.   In the linux build configuration I saw that there is an
 option to remove profiling from the build, but seemed that profiling
 should be there by default.

 Has profiling been removed as a default in the build?  And is there a
 switch I can use to add this in?


 I have used it with a default build (on Linux though), but afaik is only
 availble with sgen, did you try with mono-sgen or mono --gc=sgen

 See http://www.mono-project.com/Profiler


 I've used it with the Boehm collector successfully.


 ___
 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] New GSoC projects

[Alan]

There is support for that already, though it may need to be tweaked
slightly to improve it's behaviour. You need to enable 'on the fly
formatting' in the text editor options.

This would be a good task for GSoC, but it would only be part of a
larger project. By itself it would probably take less than 2 weeks to
fix issues and add tests to verify the behaviour.

Alan

On 26 February 2013 06:06, quandary quandar...@hailmail.net wrote:
 I don't know how good it is for a student project,
 but one of the things that have annoyed me quite a bit in the past
 is the lack of automatic indentation in MonoDevelop.

 If you copy-paste code from one place to another
 (e.g. stackoverflow post to your program),
 you have a horrible mess afterwards.
 And while it's trivial to clean up the mess,
 it's relatively time-consuming and highly annoying.
 In Visual Studio, if you put the closing brace },
 it automatically indents the code for you.

 I find this feature immensely useful,
 yet profoundly lacking in MonoDevelop. ;)

 The bad thing is, that when I work on Linux and copy a lot
 (for example when I wrote a C# mount wrapper,
 for which I copy-pasted and then converted a lot of C-code) ,
 I have to occasionally switch over to Visual Studio to clean up the mess,
 because I cannot work anymore in that mess.
 This means I have to copy the MonoDevelop project
 from the Linux machine to the windows machine,
 and then back again, over a not that fast wireless network,
 not to mention the long startup time of windows.

 Now that debugging and IntelliSense in MonoDevelop work great,
 the moment that automatic indentation arrives would be the moment
 I'd dump Visual Studio more or less completely.

 One of the nicest features in Visual Studio is,
 that you can choose to customize the indent formatting,
 e.g. you can have it indent not only like  K  R, but also like ANSI.
 For example I like ANSI indentation, like in the C# code,
 but the default indentation for JavaScript is K  R,
 but you can choose to have newlines before opening braces in
 Tools- Options -SourceCode Editor - JScript
 which then effectively indents like ANSI.



 On 02/25/2013 03:53 AM, Udesh Liyanaarachchi wrote:

 Hi all,

 Thanks Arthur pointing out this.
 I'm a student and I would like to start work on adding an enhancement for
 MonoDevelop.
 If anyone can suggest an idea it would be great.

 thanks...!!!




 On Mon, Feb 25, 2013 at 2:42 AM, Arthur Grimnirsen grimnir...@gmail.com
 wrote:

 Hi List,

 saw the sign on StudentProjects page, saying that proposals haven't been
 updated yet, but I'm wondering - are there any long awaited changes that are
 surely to be proposed?

 Also, are you ready to discuss students' own ideas at moment? I remember
 having some ideas on MonoDevelop user experience - is this list a right
 place to submit them?

 Regards,
 Arthur.

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list




 --

 Udesh Liyanaarachchi
 B.sc. Eng (Undergraduate)
 Department of Computer Science  Engineering
 University Of Moratuwa
 Sri Lanka.



 ___
 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] New GSoC projects

[Alan]

We still have to organise ourselves for this year, but feel free to
start thinking about projects and talking to us about ideas you might
have. Join our IRC channels:

Server: irc.gimp.net
Channels:
  #mono
  #monodev
  #monodevelop
  #monosoc

Alan

On 25 February 2013 02:53, Udesh Liyanaarachchi la.udesh1...@gmail.com wrote:
 Hi all,

 Thanks Arthur pointing out this.
 I'm a student and I would like to start work on adding an enhancement for
 MonoDevelop.
 If anyone can suggest an idea it would be great.

 thanks...!!!




 On Mon, Feb 25, 2013 at 2:42 AM, Arthur Grimnirsen grimnir...@gmail.com
 wrote:

 Hi List,

 saw the sign on StudentProjects page, saying that proposals haven't been
 updated yet, but I'm wondering - are there any long awaited changes that are
 surely to be proposed?

 Also, are you ready to discuss students' own ideas at moment? I remember
 having some ideas on MonoDevelop user experience - is this list a right
 place to submit them?

 Regards,
 Arthur.

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list




 --

 Udesh Liyanaarachchi
 B.sc. Eng (Undergraduate)
 Department of Computer Science  Engineering
 University Of Moratuwa
 Sri Lanka.


 ___
 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] Dictionary implementation + concurrency

[Alan]

Hey,

As per the 'thread safety' section of the documentation, your code is
invalid: http://msdn.microsoft.com/en-us/library/xfhwa508.aspx. This
kind of change will not make it safe to use the dictionary in a
read/write way from multiple threads, especially not when you have
multiple cores and multiple unshared caches for those CPU cores.

Hashtable is documented to support multiple readers with at most 1
writer. If you require those semantics, you should use a hashtable not
a Dictionary. If you require a threadsafe dictionary class, you either
need to roll your own or use ConcurrentDictionary. This is the only
realistic way of having thread safe code.

Alan


On 4 February 2013 10:18, Rafael Teixeira mono...@gmail.com wrote:
 Yes, please.

 Rafael Monoman Teixeira
 ---
 The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'
 Isaac Asimov
 US science fiction novelist  scholar (1920 - 1992)


 On Sun, Feb 3, 2013 at 5:15 PM, Greg Young gregoryyou...@gmail.com wrote:

 The .NET dictionary implementation is thread safe on reads/updates so
 long as the internal collection does not grow and size is of reference
 type or smaller. eg: if you set size to 1m items and had 100k with a
 fill factor that did not cause an internal growth it would be
 threadsafe. This assurance has been brought over from Hashtable (well
 documented) and is relatively not well documented but many take a
 dependency on it. The current mono implementation does not meet this
 assurance.

 int cur = table [(hashCode  int.MaxValue) %
 table.Length] - 1;

 // walk linked list until right slot is found or
 end is reached
 while (cur != NO_SLOT) {
 // The ordering is important for
 compatibility with MS and strange
 // Object.Equals () implementations
 if (linkSlots [cur].HashCode == hashCode
  hcp.Equals (keySlots
 [cur], key)) {
 value = valueSlots [cur];
 return true;
 }
 cur = linkSlots [cur].Next;
 }

 seems fine when accessing. However when adding...

 // find an empty slot
 cur = emptySlot;
 if (cur == NO_SLOT)
 cur = touchedSlots++;
 else
 emptySlot = linkSlots [cur].Next;

 // store the hash code of the added item,
 // prepend the added item to its linked list,
 // update the hash table
 linkSlots [cur].HashCode = hashCode;
 linkSlots [cur].Next = table [index] - 1;
 table [index] = cur + 1;

 // store item's data
 keySlots [cur] = key;
 valueSlots [cur] = value;

 Can cause null reads of a key as its in linkSlots but the value slot
 has not yet been updated. Setting keySlots after valueSlots would seem
 to solve this. Pull request wanted?

 Cheers,

 Greg

 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 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] Dictionary implementation + concurrency

[Alan]

It's not documented so you're relying on a quirk which may or may not
actually work on multi-core systems under heavy load. I'm just saying
that it's not worth relying on this as a guarantee as you will break
when run on different implementations of the BCL because you're
relying on something which is not a guarantee.

Alan

On 4 February 2013 10:46, Greg Young gregoryyou...@gmail.com wrote:
 The .NET version does support it for types or reference size or smaller.

 My guess the reason its not explicitly documented is that its only for
 types reference or smaller.

 On Mon, Feb 4, 2013 at 12:40 PM, Alan alan.mcgov...@gmail.com wrote:
 Hey,

 As per the 'thread safety' section of the documentation, your code is
 invalid: http://msdn.microsoft.com/en-us/library/xfhwa508.aspx. This
 kind of change will not make it safe to use the dictionary in a
 read/write way from multiple threads, especially not when you have
 multiple cores and multiple unshared caches for those CPU cores.

 Hashtable is documented to support multiple readers with at most 1
 writer. If you require those semantics, you should use a hashtable not
 a Dictionary. If you require a threadsafe dictionary class, you either
 need to roll your own or use ConcurrentDictionary. This is the only
 realistic way of having thread safe code.

 Alan


 On 4 February 2013 10:18, Rafael Teixeira mono...@gmail.com wrote:
 Yes, please.

 Rafael Monoman Teixeira
 ---
 The most exciting phrase to hear in science, the one that heralds new
 discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'
 Isaac Asimov
 US science fiction novelist  scholar (1920 - 1992)


 On Sun, Feb 3, 2013 at 5:15 PM, Greg Young gregoryyou...@gmail.com wrote:

 The .NET dictionary implementation is thread safe on reads/updates so
 long as the internal collection does not grow and size is of reference
 type or smaller. eg: if you set size to 1m items and had 100k with a
 fill factor that did not cause an internal growth it would be
 threadsafe. This assurance has been brought over from Hashtable (well
 documented) and is relatively not well documented but many take a
 dependency on it. The current mono implementation does not meet this
 assurance.

 int cur = table [(hashCode  int.MaxValue) %
 table.Length] - 1;

 // walk linked list until right slot is found or
 end is reached
 while (cur != NO_SLOT) {
 // The ordering is important for
 compatibility with MS and strange
 // Object.Equals () implementations
 if (linkSlots [cur].HashCode == hashCode
  hcp.Equals (keySlots
 [cur], key)) {
 value = valueSlots [cur];
 return true;
 }
 cur = linkSlots [cur].Next;
 }

 seems fine when accessing. However when adding...

 // find an empty slot
 cur = emptySlot;
 if (cur == NO_SLOT)
 cur = touchedSlots++;
 else
 emptySlot = linkSlots [cur].Next;

 // store the hash code of the added item,
 // prepend the added item to its linked list,
 // update the hash table
 linkSlots [cur].HashCode = hashCode;
 linkSlots [cur].Next = table [index] - 1;
 table [index] = cur + 1;

 // store item's data
 keySlots [cur] = key;
 valueSlots [cur] = value;

 Can cause null reads of a key as its in linkSlots but the value slot
 has not yet been updated. Setting keySlots after valueSlots would seem
 to solve this. Pull request wanted?

 Cheers,

 Greg

 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 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




 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Marshal.GetFunctionPointerForDelegate and non-mono threads

[Alan]

A simple way to diagnose if you're delegates have been GC'ed is to
export MONO_DEBUG=keep-delegates. This instructs the GC to not collect
delegates and instead rewrite them so that if they're invoked after
they would normally have been GC'ed you get a nice diagnostic error
message and then the runtime aborts. This is much easier to debug than
a random crasher.

Alan

On 29 January 2013 07:49, Yuriy Solodkyy y.solod...@gmail.com wrote:
 Do you keep a reference to your delegate while using the pointer? I suspect
 GC just collect your delegate and function pointer becomes invalid.

 -yuriy


 On Tuesday, January 29, 2013, wrote:

 We are not using the debugger.

 We're not sure how the library in question creates its threads. We
 don't have access to its source code and it's proprietary. Putting
 together a full repro would be hard.

 The callback is a simple function which picks up a logged string and
 sends it to NLog by way of an Rx Subject. That's a lot of moving
 parts, but they all work fine when the callback comes from one of our
 threads.

 Am I correct in assuming that the GetFunctionPointerForDelegate should
 automatically register the thread it's called on with mono? I have
 enough facts at hand to call the registration function manually if
 need be, but it would be awkward indeed.

 On Jan 28, 2013, at 6:34 PM, Alan alan.mcgov...@gmail.com wrote:

  Do you see these issues when running with the soft debugger attached?
  If so, that was a bug which was fixed a few days ago. If you're seeing
  the issue without the debugger, a small testcase would be great for
  figuring this out.
 
  Alan
 
  On 28 January 2013 18:42, sebastian sebast...@palladiumconsulting.com
  wrote:
  We run a program under mono which uses a 3rd party C++ library. Mono is
  responsible for running the application, that is, we are not using the
  mono_embed API, but rather just PInvoke to talk to the C++ library.
 
  This library has some callbacks which we subscribe to using
  Marhsal.GetFunctionPointerForDelegate. However we get exotic
  concurrency
  problems (seg faults, inexplicable stacktraces) when we use it. We only
  get
  these errors when the callback is made from a thread which was not
  started
  by us.
 
  I know that when embedding mono, i.e. with C++ in the driver's seat,
  threads
  must be registered with mono using mono_thread_attach. However that
  would be
  a funny thing for us to do, since we're not launching mono ourselves
  and
  would have to do some exploration to find all the right pointers.
 
  Does the code in GetFunctionPointerForDelegate emit a managed wrapper
  that
  takes care of this detail? Once we are called back on this foreign
  thread,
  there's no telling what or how much .NET code will run on it, and it
  presumably needs to be properly registered with the garbage collector.
  I
  looked at the code in mono_marshal_get_managed_wrapper and didn't see
  anything obviously related to threading, but I imagine it'd be taken
  care of
  at a lower level in any case.
 
  We could easily be convinced the bugs we saw were GC or threading
  related,
  as they could only be explained by corruption of things that shouldn't
  be
  corruptible, like reflection and array bounds.
 
  Or is there additional code or attributes we should be using to ensure
  correct operation?
 
  Thanks,
  Sebastian
 
 
  ___
  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



 --
 Yuriy Solodkyy
 (y.solod...@gmail.com)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Marshal.GetFunctionPointerForDelegate and non-mono threads

[Alan]

Do you see these issues when running with the soft debugger attached?
If so, that was a bug which was fixed a few days ago. If you're seeing
the issue without the debugger, a small testcase would be great for
figuring this out.

Alan

On 28 January 2013 18:42, sebastian sebast...@palladiumconsulting.com wrote:
 We run a program under mono which uses a 3rd party C++ library. Mono is
 responsible for running the application, that is, we are not using the
 mono_embed API, but rather just PInvoke to talk to the C++ library.

 This library has some callbacks which we subscribe to using
 Marhsal.GetFunctionPointerForDelegate. However we get exotic concurrency
 problems (seg faults, inexplicable stacktraces) when we use it. We only get
 these errors when the callback is made from a thread which was not started
 by us.

 I know that when embedding mono, i.e. with C++ in the driver's seat, threads
 must be registered with mono using mono_thread_attach. However that would be
 a funny thing for us to do, since we're not launching mono ourselves and
 would have to do some exploration to find all the right pointers.

 Does the code in GetFunctionPointerForDelegate emit a managed wrapper that
 takes care of this detail? Once we are called back on this foreign thread,
 there's no telling what or how much .NET code will run on it, and it
 presumably needs to be properly registered with the garbage collector. I
 looked at the code in mono_marshal_get_managed_wrapper and didn't see
 anything obviously related to threading, but I imagine it'd be taken care of
 at a lower level in any case.

 We could easily be convinced the bugs we saw were GC or threading related,
 as they could only be explained by corruption of things that shouldn't be
 corruptible, like reflection and array bounds.

 Or is there additional code or attributes we should be using to ensure
 correct operation?

 Thanks,
 Sebastian


 ___
 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] names differing only by case in git repo?

[Alan]

It's a mistake. We'll get it fixed!

Alan

On 27 January 2013 01:49, Bang Jun-young junyo...@mogua.com wrote:
 I have the same problem on Windows. Two of those files have invisible
 trailing spaces in their names. I'm curious how they could have been
 committed in the first place. A bug in Git?

 On Sat, Jan 26, 2013 at 3:53 AM, sebastian
 sebast...@palladiumconsulting.com wrote:
 I cloned the mono/mono repo to a Windows machine, and no matter what I do,
 my git status reports thusly:

 $ git status
 # On branch master
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working
 directory)
 #
 #   modified:   mcs/class/monodoc/monodoc.dll.sources
 #   modified:   mcs/class/monodoc/monodoc_test.dll.sources
 #
 no changes added to commit (use git add and/or git commit -a)

 Signs suggest this is due to files which differ only by case, which can make
 Windows  OS X unhappy. I can commit the bogus change locally, but it
 reappears when moving to a tag.

 ___
 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] gtk-sharp on android possible?

[Alan]

There's no known port of Gtk+ and it's dependencies for Android. If
such a thing were to exist, it may be possible to then run regular
gtk# applications, but you would still need to completely rewrite the
UI to account for the significantly smaller screen available on
handheld devices. It is highly unlikely for it to be worth your while
investing in a Gtk+ port and then rewriting your UI anyway.

Alan

On 3 December 2012 09:00, Elmar Haneke el...@haneke.de wrote:

 I have been developing applications for linux/windows by using
 mono and gtk-sharp.

 Once you have GTK+ libs for Android it should be not to complicated to
 use GTK# binding there.

 I don't know any Android-port of GTK+ perhaps you should ask on an
 Gnome-list about that.

 Elmar

 ___
 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] TCP + async

[Alan]

Have you submitted the change as a pull request on github?

Alan

On 19 September 2012 13:43, Greg Young gregoryyou...@gmail.com wrote:
 We have had a patch for a while related to a problem we ran into with TCP

  https://github.com/ysw/mono-socket-problem/blob/master/Patches/cb_fix.patch

 Its still not in trunk. We have provided tests of TCP not calling back
 async (breaks async loop) under load without this fix. As of now our
 instructions are for people to download sources and apply patch (not
 the nicest).

 Would it be possible for this patch to make its way into trunk?

 Cheers,

 Greg

 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 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] ConcurrentQueue

[Alan]

Hey,

What version of Mono are you testing against?

Alan

On 10 August 2012 09:52, Greg Young gregoryyou...@gmail.com wrote:
 We regularly can cause problems with ConcurrentQueue such as

 System.NullReferenceException: Object reference not set to an instance
 of an object
   at 
 System.Collections.Concurrent.ConcurrentQueue`1[System.IO.FileStream].TryDequeue
 (System.IO.FileStream result) [0x0] in filename unknown:0
   at SStable.PTable.GetFileStream () [0x0] in filename unknown:0
   at SStable.PTable+GetRangec__Iterator2.MoveNext () [0x0] in
 filename unknown:0
   at SStable.PTable.TryGetValue (UInt32 stream, UInt32 version,
 System.UInt64[] position) [0x0] in filename unknown:0
   at SStable.TableIndex.TryGetValueInternal (UInt32 stream, UInt32
 version, System.UInt64[] position) [0x0] in filename unknown:0
   at SStable.TableIndex.TryGetValue (UInt32 stream, UInt32 version,
 System.UInt64[] position) [0x0] in filename unknown:0
   at IndexKiller.Program.ReadItems (SStable.TableIndex index,
 System.Threading.AutoResetEvent autoResetEvent) [0x0] in filename
 unknown:0
   at IndexKiller.Program+Mainc__AnonStorey1.m__0 (System.Object x)
 [0x0] in filename unknown:0

 We have posted up repros before but basically just pound on it with
 five threads (each thread add and removes 1 item)

 It seems object pool is still buggy.

 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 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] Incompatibility

[Alan]

If you want, you could implement the correct behaviour and then submit
the patch with that unit test attached as a github pull request. We
will easily and quickly be able to merge the new behaviour in then.

Alan

On 10 August 2012 18:10, Greg Young gregoryyou...@gmail.com wrote:
 I'm fine by that. Is there a list of these incompatibilities that is
 being maintained?

 On Fri, Aug 10, 2012 at 8:09 PM, Jonathan Chambers jonc...@gmail.com wrote:
 Historically, mono has done what .Net does rather than what it says.

 - Jonathan

 On Fri, Aug 10, 2012 at 1:07 PM, Greg Young gregoryyou...@gmail.com wrote:

 bizarre, their docs say it should throw but they don't.
 http://msdn.microsoft.com/en-us/library/system.io.file.setattributes.aspx

 Not sure which is better, what they say they do or what they do?

 On Fri, Aug 10, 2012 at 10:01 AM, Greg Young gregoryyou...@gmail.com
 wrote:
  [Test]
  public void does_not_throw_exception_on_non_existing_file() {
 Assert.DoesNotThrow(() = File.SetAttributes(DOESNOTEXIST,
  FileAttributes.ReadOnly));
  }
 
  Cheers,
 
  Greg
 
  --
  Le doute n'est pas une condition agréable, mais la certitude est
  absurde.



 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list





 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.
 ___
 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] ConcurrentStack with value type in 2.10

[Alan]

I cannot reproduce the problem either. What exact version of 2.10 did
you test against? It's possible the bug has already been fixed in a
newer release of the 2.10 series.

Alan

On 23 July 2012 13:32, Rodrigo Kumpera kump...@gmail.com wrote:
 Hi Yuriy,

 With how many cores and on what CPU did managed to reproduce this?
 I'm running this on my 4 cores nehalem mac without any luck. I'll diff
 ConcurrentStack
 between 2.8 and 2.10 to see what could be.

 On Sun, Jul 22, 2012 at 5:10 AM, Yuriy Solodkyy yu...@couldbedone.com
 wrote:

 Hi,

 It looks like the ConcurrentStack does not work with big enough
 structures anymore.  12 bytes struct is enough to reproduce the
 problem occasionally, 16 bytes structure to reproduce it immediately.
 It worked fine in mono 2.8.  The following code shows that we may pop
 inconsistent structure from the stack from time to time.

 using System;
 using System.Collections.Concurrent;
 namespace CocurrentTest {
 class MainClass {
 struct Data {
 public int A; public int B; public int C; public
 int D;
 public Data(int v) {
 A = v; B = -v; C = v; D = -v;
 }
 }

 public static void Main (string[] args) {
 Console.WriteLine (Hello World!);
 var data = new byte[1024 * 1024];
 var stack = new ConcurrentStackData ();

 for (var i = 0; i  50; i++) {

 var thread = new System.Threading.Thread
 (v = {

 var rnd = new Random ();
 while (true) {
 int pushCount = rnd.Next
 (50);
 int popCount = rnd.Next
 (50);

 for (var k = 0; k 
 pushCount; k++) {


 var sample =
 new Data (rnd.Next(Int32.MaxValue));
 CheckSample
 (sample);

 stack.Push
 (sample);
 }

 for (var k = 0; k 
 popCount; k++) {
 Data
 retrievedSample = new Data();
 if
 (stack.TryPop (out retrievedSample)) {

 CheckSample (retrievedSample);
 }
 }
 }
 }
 );

 thread.Start ();
 }
 }

 static void CheckSample (Data sample){
 if (sample.A != -sample.B || sample.A !=
 sample.C || sample.B != sample.D)
 throw new Exception (string.Format
 (Invalid sample detected));
 }
 }
 }


 --
 Yuriy Solodkyy
 ___
 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] Mono 2.10.8 SIGSEGV

[Alan]

Gtk is not a thread-safe toolkit. Once you start accessing it in a
multi-threaded way you run the risk of corrupting state so badly that
the entire application blows up. A regular gtk error is converted to a
regular .NET exception, but memory corruption such as this will always
lead to your app terminating in a random way at a random time.

Alan

On 17 July 2012 12:26, Matthias D. matth...@googlemail.com wrote:
 Hi,

 it was a Gtk# threading issue, which is now resolved. Everything works
 surprisingly good now on the mono side.
 I'm wondering, gtk is a native api, but it would make sense to encapsulate
 errors in exceptions.
 Is this just missing or by design?

 Thanks,
 Matthias

 On Sat, Jul 14, 2012 at 2:33 PM, Matthias D. matth...@googlemail.com
 wrote:

 Hey,

 like I said I'm trying to port a Application to mono, now I'm experiencing
 a mono SIGSEGV:

 To reproduce the issue type (mono installed and in PATH):

 git clone git://github.com/matthid/synclib.git

 cd synclib
 git checkout -b devel remotes/origin/devel
 export FSC=mono `pwd`/lib/FSharp-4.0/fsc.exe
 export FSI=mono `pwd`/lib/FSharp-4.0/fsi.exe
 ./build_mono.sh

 cd build/bin
 $FSI --exec --nologo RunApplication.fsx


 On my system I get:

 reddragon@reddragon-PC ~/projects/synclib/build/bin $ $FSI --exec --nologo
 RunApplication.fsx


 /home/reddragon/projects/synclib/build/bin/RunApplication.fsx(7,1):
 warning FS0211: The search directory
 '/home/reddragon/projects/synclib/build/bin/bin\Debug\lib' could not be
 found

 (fsi:25023): Gtk-WARNING **: Failed to set text from markup due to error
 parsing markup: Fehler in Zeile 2, Zeichen 33: »StartupCode$Yaaf-SyncLib«
 ist kein gültiger Name: »$«

 (fsi:25023): Gtk-WARNING **: Failed to set text from markup due to error
 parsing markup: Fehler in Zeile 2, Zeichen 33: »StartupCode$Yaaf-SyncLib«
 ist kein gültiger Name: »$«

 (fsi:25023): Pango-CRITICAL **: No modules found:
 No builtin or dynamically loaded modules were found.
 PangoFc will not work correctly.
 This probably means there was an error in the creation of:
   '/etc/pango/pango.modules'
 You should create this file by running:
   pango-querymodules  '/etc/pango/pango.modules'
 Stacktrace:

   at (wrapper managed-to-native) Gtk.Application.gtk_main () 0x
   at Gtk.Application.Run () 0xb
   at Yaaf.SyncLib.Ui.Scripting.RunGui
 (Microsoft.FSharp.Collections.FSharpList`1System.Tuple`2Yaaf.SyncLib.ManagedFolderInfo,
 Yaaf.SyncLib.IManagedFolder) 0x006bb
   at StartupCode$FSI_0001.$FSI_0001.main@ () 0x0024b
   at (wrapper runtime-invoke) object.runtime_invoke_void
 (object,intptr,intptr,intptr) 0x
   at (wrapper managed-to-native)
 System.Reflection.MonoMethod.InternalInvoke
 (System.Reflection.MonoMethod,object,object[],System.Exception)
 0x
   at System.Reflection.MonoMethod.Invoke
 (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo)
 0x00193
   at System.MonoType.InvokeMember
 (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Reflection.ParameterModifier[],System.Globalization.CultureInfo,string[])
 0x005a5
   at System.Reflection.Emit.TypeBuilder.InvokeMember
 (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Reflection.ParameterModifier[],System.Globalization.CultureInfo,string[])
 0x00069
   at System.Type.InvokeMember
 (string,System.Reflection.BindingFlags,System.Reflection.Binder,object,object[],System.Globalization.CultureInfo)
 0x0005a
   at
 Microsoft.FSharp.Compiler.AbstractIL.ILRuntimeWriter/execEntryPtFun@2113-1.Invoke
 (Microsoft.FSharp.Core.Unit) 0x00097
   at Microsoft.FSharp.Compiler.Interactive.Shell/clo@982-32.Invoke
 (Microsoft.FSharp.Core.FSharpFunc`2Microsoft.FSharp.Core.Unit,
 Microsoft.FSharp.Core.FSharpOption`1System.Exception) 0x00022
   at Microsoft.FSharp.Primitives.Basics.List.iterT
 (Microsoft.FSharp.Core.FSharpFunc`2T,
 Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Collections.FSharpList`1T)
 0x00049
   at Microsoft.FSharp.Collections.ListModule.IterateT
 (Microsoft.FSharp.Core.FSharpFunc`2T,
 Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Collections.FSharpList`1T)
 0x0002f
   at Microsoft.FSharp.Compiler.Interactive.Shell.arg10@981
 (Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompiler,Microsoft.FSharp.Collections.FSharpList`1Microsoft.FSharp.Core.FSharpFunc`2Microsoft.FSharp.Core.Unit,
 Microsoft.FSharp.Core.FSharpOption`1System.Exception,Microsoft.FSharp.Core.Unit)
 0x00033
   at
 Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompiler.ProcessInputsint
 (int,Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompilerState,Microsoft.FSharp.Collections.FSharpList`1Microsoft.FSharp.Compiler.Ast/Input,bool,bool,bool,Microsoft.FSharp.Collections.FSharpList`1Microsoft.FSharp.Compiler.Ast/Ident)
 0x0091f
   at
 Microsoft.FSharp.Compiler.Interactive.Shell/FsiDynamicCompiler.EvalDefns
 (Microsoft.FSharp.Compiler.Interactive.Shell

Re: [Mono-dev] Should i submit my Winforms queued patches here or github?

[Alan]

A pull request on github would probably be simplest. We can review,
comment and merge from the web interface which simplifies the workflow
and ensures the commit doesn't get lost. I assume you're familiar with
how to do pull requests, but in case you aren't you just have to:

1) Fork mono on github
2) Create a new branch in your fork with all the change you want in
your pull request
3) Submit a pull request for that branch

Alan

On 20 June 2012 14:06, Rob Wilkens robwilk...@gmail.com wrote:
 Now that I have all of the Winforms patches (for Datagrid and Idle)
 extracted into individual patches -- which i did for the earlier e-mail,
 I can clean them up and submit them one at a time, to github, if that
 would be preferred?  OR I could submit them, one at a time (i.e. as we
 get to them), to this mailing list, if that would be preferred?  I
 suggest one at a time, because i noticed earlier that a change in one
 commit will break the application of the other patches to the same
 file(s).  When i say one at a time, i mean one datagrid patch at a time,
 and one idle patch at a time (if not just one idle patch altogether,
 since they are essentially one patch).

 There is absolutely no rush either way, these patches in most cases have
 been in the problem report database for years.  I just want to make the
 job as easy as possible for whomever winds up reviewing them, whenever
 they get to them, whether it's stifu or someone else if he genuinely
 does decide to quit because of me :-( .

 -Rob
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] C# project export to Linux fails - lots of errors

[Alan]

Banshee uses gstreamer as a cross platform media playback framework.
What you need to do is look at Banshees source code to see how they
use gstreamer and then port your app to use that on Linux/MacOS. You
can continue using WMP on windows if you wish.

Alan

On 19 June 2012 11:16, Achim123 achim.sk...@googlemail.com wrote:
 The problem is that Banshee seems to be a really big project, and I couldn't
 find a tutorial on how to implement Banshee in my C# project :-|

 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/C-project-export-to-Linux-fails-lots-of-errors-tp4649979p4650073.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] Restart my fork?

[Alan]

Generally speaking every time you want to fix something new which is
unrelated to existing patches which have not been upstreamed you can
simply do:

# Lets assume this step is already done and the mono repository is
called 'mono_repo' in your fork
git remote add mono_repo git://github.com/mono/mono.git

# Pull all the latest commits from mono_repo
git fetch mono_repo

# Create a new branch based on the latest commit in mono_repo in the
master branch
git checkout -b NEW_BRANCH_TO_FIX_FOOBAR mono_repo/master

That's the simplest way to get a 100% clean and up-to-date branch
every time you want to make a new fix. When you are done you can push
the new local branch to your fork using the syntax:

git push origin NEW_BRANCH_TO_FIX_FOOBAR

That pushes the curreny branch to a remote branch of the specified name.

Hope that helps,
Alan

On 17 June 2012 15:29, Stifu st...@free.fr wrote:
 One fix = one patch + one test (if possible).
 As for the lock you added, just merge that with your earlier patch, so that
 the patch really fully fixes the problem.

 If some patch requires another patch first, just specify that here. I'll
 probably review the easiest patches first, to get them out of the way. If
 you want to suggest a certain review order, go ahead.


 Rob Wilkens wrote

 I was going to plan to break this up into individual commits, but
 instead when i get to this i may break it up into each file's worth of
 changes (or in the case of some commits, set of files) and document what
 fixes what in each, if that is ok with you?  i.e. i'll try to document
 what was changed line by line or set of lines, and specifically when
 documenting it cover the 'why'.

 The reason for this is that i have some changes i made in earlier
 commits which 'worked' but every so often crashed while adding an idle
 handler i later found, and i fixed this with a lock (this) {} in a later
 commit around a very small section of code (2-4 lines).. But that was
 after i made unrelated changes elsewhere (the datagrid changes).

 Or if you prefer i get it commit by commit i'll do that, but in that
 cases, at least some of the commits will have to be applied in the same
 order because they have a dependency on a previous commit going through.

 -Rob

 On 06/17/2012 09:34 AM, Stifu wrote:
 Alright, I'm not in a hurry.


 Rob Wilkens wrote
 I won't have time to do that right now, but will later, please be
 patient..   I wouldn't wait around the keyboard right now for an e-mail
 because i'm next in line for the shower then we're heading out for
 morning.

 The bug reports are listed on the pull page, but i will try to separate
 the changes out into what fixes what.

 -Rob


 On 06/17/2012 09:26 AM, Stifu wrote:
 Please separate each patch, so I can review them one by one. This is
 just
 too
 big to review, and I don't know even know what it's trying to fix.
 Also, please give me the concerned bug reports, if any.


 Robert Wilkens wrote
 Ok, if you are willing to look at it, i've attached it if i did it
 right...

 I did a git diff commit just before first commit last commit

 That should have the whole range of changes of all the commits,
 hopefully i've attached the right file too.

 This should align with the following pull request on github.com:
 https://github.com/mono/mono/pull/322
 Which originally was a closed pull request which i cancelled when i
 needed to make additional changes:
 https://github.com/mono/mono/pull/312

 I'm probably not going to be home all day today, so if you have
 questions, i am willing to answer them but i may be delayed.  I'll try
 to bring my laptop if i do go out.

 -Rob

 On 06/17/2012 08:21 AM, Stifu wrote:
 Can't really give Git-related advices, I suck at it, but I can easily
 review
 WinForms patches if you simply attach them to your messages the
 old-school
 way.


 Robert Wilkens wrote
 My master branch contains two unrelated winforms changes (one change
 for
 idle, one change for DataGrid - not DataGridView don't worry i'm not
 duplicating work), it's becoming clear that they are not going to
 receive priority and i have no problem with that.

 But i do have at least one non-winforms fix which i'd like to at
 least
 get reviewed.  That's not going to happen since the winforms changes
 have to go thru first.

 Is it considered a safe thing to:
 1) Backup the files that i changed for each fix
 2) Delete my fork
 3) Create a new fork
 4) Create branches for each change and submit them separately

 I think this would help me get past my current state of 'i can't
 really
 do anything until my master branch is approved or rejected'...

 I probably won't do this today, but if I don't hear back i might do
 that
 sometime this week.

 -Rob

 ___
 Mono-devel-list mailing list
 Mono-devel-list@.ximian
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Restart-my-fork-tp4650004p4650006.html
 Sent

Re: [Mono-dev] C# project export to Linux fails - lots of errors

[Alan]

Whoops, include the list

The root of your problem is that windows media player does not exist
on linux (for obvious reasons ;) ). If you want an application which
can play media files on different platforms, you'll either have to
write a platform specific media playing backend or use a cross
platform backend and ensure it's available on all systems your app is
run on.

For example on windows you could use WMP. On Linux you could use
gstreamer. On MacOS you could probably use CoreAudio or CoreVideo, or
maybe something else. I'm not sure what'd be appropriate.

Alan

On 17 June 2012 18:02, Steven Boswell II ulat...@yahoo.com wrote:
 Indeed, that's the problem, Achim -- just because you can compile C# under
 Linux/Mac doesn't mean you wrote cross-platform C#.
 In this case, you're using a COM/ActiveX control that only exists under MS
 Windows.

 Steven Boswell


 ___
 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] MonoWrench Windows builds

[Alan]

Hi,

I'll get in touch with the right people internally and see if we can
get this fixed.

Thanks,
Alan

On 11 June 2012 12:11, Filip Lundgren fi...@inkdev.net wrote:
 Does anyone have any clue why MonoWrench is queuing, but not building any
 Windows builds at the moment? We are looking into upgrading to a newer
 build, but can't due to this issue.

 We've attempted to build this ourselves before, however we're not sure of
 the ideal setup for doing it on Windows. (Barring building mono itself)

 Cheers,
 Filip
 Ink Studios Ltd. - CryMono Programmer

 ___
 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] Compiling mono? I give up [not proceeding] - if anything obvious i'm doing wrong let me know

[Alan]

The problem you seem to be hitting is that mono has built and
installed successfully, but you haven't installed all the required
support libraries for your project into the GAC of that new mono. This
is why you cannot find Mono.Addins, or gtk, or anything.

The simplest way to fix this is to build and install all required
support libraries with the same prefix as your custom mono
(/usr/local).

The not-so-fast-but-quite-safe way is to use the gacutil app to
install libraries into the /usr/local gac. For example, you'd do
something like:  /usr/local/bin/gacutil -i
/usr/lib/mono/gac/gtk-sharp/2.0.0_2342342/gtk-sharp.dll for every
library you need in your new mono.

The fastest (and most likely to cause problems) way is to just type
this in your terminal before executing an app with your new mono in
/usr/local: export MONO_GAC_PREFIX=/usr. This will make the mono in
/usr/local/ look for a GAC in /usr/lib/mono/gac. You may get strange
type load exceptions using this method.

I should also point out that the core libraries that are part of mono
itself are not always shareable between different builds of mono.
mscorlib never is. Any library which invokes native functions in the
mono native library (libmono.so) is not safe to share. Any pure .NET
library which does not invoke functions in libmono.so is potentially
safe, but it is completely unsupported and if you try it and it
breaks, we will just recommend you compile a clean version and don't
copy assemblies between different versions of mono.

Alan

On 1 May 2012 09:53, Oskar Berggren oskar.bergg...@gmail.com wrote:
 2012/5/1 Rob Wilkens robwilk...@gmail.com:
 [apologies if duplicated - i sent from wrong account at first and don't
 think it went through]

 I hate trying to get other people's program's to build properly on a
 different computer than it was originally built on/for, but i gave building
 mono an honest effort before giving up.  I've been trying different


 Have you seen this:
 http://www.mono-project.com/Parallel_Mono_Environments

 It's what I've been following repeatedly with different mono versions
 over the last couple of years. Building from released source tar
 balls.

 I think one of the key differences compared to how I understand what
 you've been doing is that you should redirect the install path
 completely to not mix with any directory commonly used. I.e. för Mono
 2.10.8 I used

 ./configure --prefix=/usr/local/mono-2.10.8

 Repeat the --prefix clause on every configure script in the same set
 of packages. It will then all install neatly and not corrupt anything.
 Couple that with a helper script as detailed on the page to setup the
 correct environment variables, and things seems to work out rather
 nicely.

 Also, remember that for everything except libgdiplus and mono itself,
 you need to be inside the environment created by the script in order
 for the builds of the remaining packages to build against the intended
 mono version.


 I've attached some notes from when I last built mono 2.10, with the
 configure invocations and expected output I used. At the top a list a
 number of native dependencies that I was able to satisfy using regular
 apt-get. I also attach the helper scripts I use to execute mono for
 this environment - these two files are the only ones that go in
 /usr/local/bin. After having installed libgdiplus and mono you should
 be able to do:

 $ mono210 mono --version

 and

 $ source mono210env
 [mono210]$ mono --version


 When that is working, you can have a look at remaining packages if you
 like. Remember to do this from inside source mono210env.

 /Oskar

 ___
 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] Compiling mono? I give up [not proceeding] - if anything obvious i'm doing wrong let me know

[Alan]

What version of gtk+ do you have and what version of gtk-sharp did you
build? The odds are you built gtk-sharp for gtk2 and you have gtk3
installed on your system. There is an experimental branch of gtk-sharp
which does work with gtk3 which might get around this problem for you.
I think this is just a different branch in the regular gtk-sharp
repository.

Alan

On 1 May 2012 13:45, Rob Wilkens robwilk...@gmail.com wrote:
 Ok, I've managed to get rid of most of my errors via using the
 parallel build environment configuration...

 But I've got one more error preventing me from proceeding with what i
 wanted to work on, and i think it's related to gtk-sharp, in which
 case i'm either asking on the wrong mailing list (probably) or maybe i
 should find another version of gtk-sharp(?) to try to build.

 Here's the problem copied/pasted directly from command line of both programs:
 mono: symbol lookup error:
 /home/robwilkens/mono/lib/libglibsharpglue-2.so: undefined symbol:
 g_thread_supported

 Oddly enough, i tried googling the error message (copy/paste) from
 libglibsharpglue to the end of the line, and nothing came up..  I
 guess i'm the first one to run across this particular problem, or at
 least the first to ask publicly.

 I get the same error from both programs that i was trying to test
 before (namely: monodevelop and GhettoGtkAdmin)...

 Is this mono or should i look for a gtk-sharp mailing list and ask there?

 Thanks,
 Rob
 ___
 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 Maintainers list

[Alan]

Was this stored in git in a 'MAINTAINERS' file? If not, why not? This
would be the ideal place for it to be located as it'd be simple for
people to find and update it as all maintainers have write access to
there :)

Alan

On 16 April 2012 08:57, Jb Evain jbev...@gmail.com wrote:
 Hey,

 On Apr 10, 2012, at 11:54 PM, Alex Rønne Petersen wrote:
 So, in order to put together an initial list, I'm writing to the
 various dev lists. If you are willing to take maintainership of a
 particular part of Mono's source base, please reply to this email with
 a description of the parts of Mono you wish to take maintainership of
 and your IRC nickname (if any). Essentially, doing this just means
 that people will be able to go to you when they need patch reviews.


 mcs/class/Mono.Cecil
 mcs/class/Mono.Cecil.Mdb
 mcs/class/dlr
 mcs/class/System.Core/System.Linq
 mcs/class/System.Core/System.Linq.Expressions
 mcs/tools/linker
 mcs/tools/cil-strip
 mcs/tools/pdb2mdb
 mcs/tools/tuner

 Jb

 ___
 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] System.Json is ready to be replaced

[Alan]

Hey,

I wonder if we'd be better off deleting the actual code from our repository
and pulling it directly from the microsoft one via a git submodule. It
should be an easier way to keep things up to date and also simpler to
maintain patches/modifications (should any be required).

Alan

On 28 March 2012 13:30, Atsushi Eno atsushi...@veritas-vos-liberabit.comwrote:

 Hello,

 As many of you guys already know, Microsoft did a huge ASP.NET source
 release at codeplex[*1]. Since this includes System.Json, I ported this to
 our class libs to replace existing stuff.

 There are only a few concerns.

 - There was some weird test that expects *invalid* JSON syntax.
  I'm totally inclined to kill it, but since this says as if
  .NET allowed such broken JSON (this actually fails with this
  Microsoft implementation), I'd wait for inputs regarding this one
  for a few days. Looks like it was from Miguel [*2]
 - I haven't verified builds other than net_2_0, net_4_0 and net_4_5.
  I have excluded DLR stuff with NET_4_0 so this should build on
  other profiles though.
 - The new dll is binary incompatible. I believe that in general
  Microsoft implementation makes more sense though (lots of explicit
  operators instead of implicit, Save() only on JsonValue, no
  TimeSpan support).

 The new sources are in mcs/class/System.Json-new so the existing
 System.Jsoncan be easily replaced with it.

 [*1] http://aspnetwebstack.**codeplex.comhttp://aspnetwebstack.codeplex.com
 [*2] https://github.com/mono/mono/**blame/master/mcs/class/System.**
 Json/Test/System.Json/**JsonValueTest.cshttps://github.com/mono/mono/blame/master/mcs/class/System.Json/Test/System.Json/JsonValueTest.cs

 Atsushi Eno

 __**_
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://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] GSoC 2012 Proposal - WPF

[Alan]

Hey,

The short of it is, the scope of the project would be far too long for the
SoC regardless of how feasible it is. It'd probably be one summers work to
make moonlight run with a backend other than GTK in moonlights desktop
mode, which'd be a requirement for your purposes. The other big issue is
that the majority of all moonlight unit tests are no longer accessible by
anyone as only Novell employees working on Moonlight had the right to
access them. If future development were to take place, this test suite
would have to be built up again, though that could be done as the new
changes are implemented.

Nothing is stopping anyone from beginning this work. However the Mono
Project itself does have a lot of projects which would be significantly
higher priority to both us and the community. As such, it is unlikely this
would be accepted as a SoC project.

Alan

On 28 March 2012 20:14, Lucas Zawacki lfzawa...@gmail.com wrote:

 Thanks for the detailed explanation Vincent! Keep us posted on the
 advances you make and maybe let's get in touch if you think that this
 could be better resolved in the Wine side (even if it's a project
 outside gsoc).

 2012/3/28 Vincent Povirk madewokh...@gmail.com:
  I do remember asking about the possibility of porting parts of WPF in
  Moonlight to work in plain Mono, and I was told it would be difficult
  to separate them from Moonlight.

 That's too bad, if someone is more familiar with the situation please
 enlighten me.
 ___
 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] System.IO.Packaging throws NullReferenceExeption

[Alan]

Hi,

For every testcase which fails, could you create a bug report on
http://bugzilla.xamarin.com, attach the testcase and assign it to 
a...@xamarin.com. I will look at them when I get a chance and fix the
underlying issues where possible. If you could also attach the resulting
'out.zip' created from the microsoft framework, that would make it faster
for me to ensure things are generated correctly.

Thanks!
Alan

On 9 February 2012 13:03, CikaPero1 cika.pe...@gmail.com wrote:

 Hi,

 Does anyone know why the code below throws an exception?

 The code below works with MS Visual Studio but simply won't work with Mono
 2.8.

 using System;
 using System.IO;
 using System.IO.Packaging;
 using System.Text;
 using System.Xml;

 namespace ConsoleApplication
 {
class Program
{
static void Main(string[] args)
{
using (Package Package = Package.Open(out.zip,
 FileMode.Create))
{
Uri partUri = new Uri(/_rels/.rels, UriKind.Relative);
PackagePart packagePart = Package.CreatePart(partUri,
 application/vnd.openxmlformats-package.relationships+xml);

using (Stream str = packagePart.GetStream())
{
using (var writer = new XmlTextWriter(str, new
 UTF8Encoding(false)))
{
writer.WriteStartDocument(true);
writer.WriteStartElement(Relationships);
writer.WriteAttributeString(xmlns,
 http://schemas.openxmlformats.org/package/2006/relationships;);
writer.WriteStartElement(Relationship);
writer.WriteAttributeString(Type,
 
 http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties
 );
writer.WriteEndElement();
writer.WriteEndElement();
}
}
}
}
}
 }

 Strangely, it works when I change some strings:
 a) /_rels/.rels - /rels/.rels
 b) or xmlns - x
 c) or http://schemas.openxmlformats.org/package/2006/relationships; -
 http://schemas.openxmlformats.org/package/2007/relationships;
 d) or http://schemas.openxmlformats.org/package/2006/relationships; -
 http://schemas.openxmlformats.org/package/2007/relationships; and
 
 http://schemas.openxmlformats.org/package/2006/relationships/metadata/core-properties
 
 -
 
 http://schemas.openxmlformats.org/package/2007/relationships/metadata/core-properties
 

 This will bring me to insanity!

 Thanks for any help,
 Cika Pero

 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/System-IO-Packaging-throws-NullReferenceExeption-tp4372735p4372735.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] Mono[CoreCLR] security attributes in Platform assembly

[Alan]

The best documentation for this is:
http://www.mono-project.com/CoreClrHowTo#Profiles and the other pages it
links to.

Alan

On 9 February 2012 06:11, Anshya Aggarwal anshya.aggar...@gmail.com wrote:

 Hi Alan,

 As you said I am already embedding mono in my framework, enabling core-clr
 and also registering all function callbacks to determine platform code.
 Here my requirements are to restrict access to FileIO and system calls. I
 am able to achieve a part of it by enabling core-clr but not the FileIO
 part.
 Can you provide some information on how to go about the FileIO
 restrictions.

 On Thu, Feb 9, 2012 at 11:41 AM, Anshya Aggarwal 
 anshya.aggar...@gmail.com wrote:



 On Wed, Feb 8, 2012 at 8:00 PM, Alan alan.mcgov...@gmail.com wrote:

 These attributes are only generated as part of the moonlight build.
 There is no way to create them unless you modify the Makefiles to allow
 them to be generated in an alternate way. This is also not something which
 we should enable by default because it increases build time significantly
 and is useless unless you are also embedding mono and do all necessary
 function calls when loading libmono to enable coreclr.
 http://www.mono-project.com/CoreClrHowTo

 Alan

 On 8 February 2012 09:20, Anshya Aggarwal anshya.aggar...@gmail.comwrote:

 Hi All,

 I am building the mono with --with-moonlight=no, as per my knowledge
 mono dont have core-clr security
 attributes(safecritical/critical/transparent)
 enabled by default in mscorlib.dll or system.dll etc if moonlight flag
 is not enabled at compilation. So, I want to know that is there a way to
 have all
 the security attributes in my assembly without enabling moonlight flag.


 --
 Regards,
 Anshya


 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list





 --
 Regards,
 Anshya Aggarwal




 --
 Regards,
 Anshya Aggarwal


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono[CoreCLR] security attributes in Platform assembly

[Alan]

These attributes are only generated as part of the moonlight build. There
is no way to create them unless you modify the Makefiles to allow them to
be generated in an alternate way. This is also not something which we
should enable by default because it increases build time significantly and
is useless unless you are also embedding mono and do all necessary function
calls when loading libmono to enable coreclr.
http://www.mono-project.com/CoreClrHowTo

Alan

On 8 February 2012 09:20, Anshya Aggarwal anshya.aggar...@gmail.com wrote:

 Hi All,

 I am building the mono with --with-moonlight=no, as per my knowledge mono
 dont have core-clr security attributes(safecritical/critical/transparent)
 enabled by default in mscorlib.dll or system.dll etc if moonlight flag is
 not enabled at compilation. So, I want to know that is there a way to have
 all
 the security attributes in my assembly without enabling moonlight flag.


 --
 Regards,
 Anshya


 ___
 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] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist

[Alan]

Perfect. That is what i meant. Once you have any kind of system mono
package you will be able to build from git.

I don't think anyone pasted this link earlier, so apologies if you've
already read it, but this has great info on how to set up a second mono
from git without breaking your system:
http://www.mono-project.com/Parallel_Mono_Environments

Alan


On 3 February 2012 12:16, Markku Tavasti tava...@seravo.fi wrote:

 2012/2/1 Alan alan.mcgov...@gmail.com

 Is there a mono package available for your distro? If so, just install
 that.

 For latest release, no. I Installed latest packages available for SLE,
 and with them I could build git version.

 --Tavasti


 ___
 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] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist

[Alan]

Is there a mono package available for your distro? If so, just install that.

Alan

On 1 February 2012 09:41, Markku Tavasti tava...@seravo.fi wrote:

 2012/2/1 Markku Tavasti tava...@seravo.fi

  make[5]: Entering directory `/home/tavasti/build/mono/mcs'
 /bin/sh .//mkinstalldirs build/deps
 mkdir -p -- build/deps
 touch build/deps/.stamp

 make[6]: Entering directory `/home/tavasti/build/mono/mcs'
  /home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe:
 /home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot execute
 binary file
 make[6]: *** [build/deps/basic-profile-check.exe] Error 126


 Installed wine, and tried:
  tavasti@susesrv:~/build/mono  ${PWD}/mcs/class/lib/monolite/gmcs.exe
 bash: /home/tavasti/build/mono/mcs/class/lib/monolite/gmcs.exe: cannot
 execute binary file
 tavasti@susesrv:~/build/mono wine
 ${PWD}/mcs/class/lib/monolite/gmcs.exewine: Install Mono for Windows to run
 .NET 2.0 applications.
 tavasti@susesrv:~/build/mono err:ntdll:RtlDeleteResource Deleting active
 MRSW lock (0x1124e4), expect failure
 wine: Unhandled page fault on write access to 0x1100f849 at address
 0x7bc48c62 (thread 0017), starting debugger...
 err:seh:start_debugger Couldn't start debugger (winedbg --auto 14 48)
 (1115)
 Read the Wine Developers Guide on how to set up winedbg or another debugger




 ___
 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] We should add Novice bugs tag in bugzill to new contributer

[Alan]

To attact contributors it might be helpful to write down directions to parts
of code with an lower learning barrier

The solution we use for this is for contributors to show up in the channel
and ask around. No area of the code is 'simple' really so you just have to
choose a bug you hate and then start asking questions until you're able to
solve it.

Alan

On 18 January 2012 17:12, Sharique uddin Ahmed Farooqui saf...@gmail.comwrote:

 Sharique uddin Ahmed Farooqui
 http://safknw.blogspot.com/
 Peace is the Ultimate desire of mankind.



 On Wed, Jan 18, 2012 at 9:00 PM, Elmar Haneke el...@haneke.de wrote:
 
  It would be
  easier for him if we put novice tag to bugs which are of low
  complexity bug so he can start from it.
 
  Who should decide about the difficulty of an bug?
 I think Mono Core team can decide. I think they are in perfect
 position to do it.
 
  I would expect that this decision can be made mostly if the bug is
 resolved.
 
  To attact contributors it might be helpful to write down directions to
  parts of code with an lower learning barrier.
 
 I agree.
 Also we do not have sufficient documentation for most of the
 components of components, specially from point of new contributor. A
 lot of documentations are spread across the blogs of team members. We
 need to bring it to one place. We also need to up date existing docs
 as well.

 
  Elmar
 
 
 ___
 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] compiler internal error

[Alan]

Hi,

I don't know if anyone in Novell monitors bugzilla, would you be able to
re-file the bug at http://bugzilla.xamarin.com ?

Thanks,
Alan

On 16 November 2011 17:56, Giacomo Tesio giac...@tesio.it wrote:

 Hi, I reported this bug that is preventing me to work on my Debian box:
 https://bugzilla.novell.com/show_bug.cgi?id=730565

 Is there anyone looking at the problem?


 Giacomo

 ___
 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] implementation of BitConverter [possible perf improvements?]

[Alan]

Hi,

You probably still need the null check and you definitely still need the
array bounds checking. Both of these will slow things down a bit. Other
than that there's no reason not to do things as you describe, i'm surprised
it's not done already. If you want to create a patch on github which passes
the regression tests (and any new ones which may be required), I'd be happy
to merge it.

Alan

On 17 November 2011 23:44, Jonathan Shore jonathan.sh...@gmail.com wrote:


 I was looking at the code for the mono implementation of BitConverter and
 was surprised to see that common types (such as long) are converted by
 writing to a byte* a byte at a time.   I don't  know why it was done this
 way unless this was done to avoid a temporary pin of the byte[].

 The current code is:

   unsafe static void PutBytes (byte *dst, byte[] src, int 
 start_index, int count)
   {
   if (src == null)
   throw new ArgumentNullException (value);

   if (start_index  0 || (start_index  src.Length - 1))
   throw new ArgumentOutOfRangeException 
 (startIndex, Index was
   +  out of range. Must be non-negative 
 and less than the
   +  size of the collection.);

   // avoid integer overflow (with large pos/neg 
 start_index values)
   if (src.Length - count  start_index)
   throw new ArgumentException (Destination array 
 is not long
   +  enough to copy all the items in the 
 collection.
   +  Check array index and length.);

   for (int i = 0; i  count; i++)
   dst[i] = src[i + start_index];
   }

   unsafe public static long ToInt64 (byte[] value, int startIndex)
   {
   long ret;

   PutBytes ((byte *) ret, value, startIndex, 8);

   return ret;
   }



 The above code does avoid pinning the byte[] buffer, however is 3-4x
 slower than, say doing this:

 unsafe public static long ToLong (byte[] buffer, int offset)
 {
 fixed (byte* pbuf = buffer)
 {
 long* vlong = (long*)(pbuf + offset);
 return *vlong;
 }
 }


 Any reason why we would not want to do the above?

 Jonathan



 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Problem handling more the 1024 file handle

[Alan]

Hi,

Mono itself has no trouble opening 1000's of files. Would you be able to
create an equivalent C program and see if that works as expected? My guess
would be that the equivalent C program will fail in the same way. If it
does not, then it's likely to be a mono bug.

Alan

On 4 November 2011 07:19, Torello Querci tque...@gmail.com wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024) = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

struct rlimit {
public IntPtr rlimit_cur;
public IntPtr rlimit_max;
}

class MainClass
{
public static unsafe void Main (string[] args)
{
FileStream[] streams;
string path;
if (args.Length == 0) {
Console.WriteLine (You need to specify the
 number of files that
 needs to be created.);
return;
}

int nFiles = Int32.Parse (args[0]);

streams = new FileStream[nFiles];

rlimit data = new rlimit ();
data.rlimit_cur = (IntPtr) 2;
data.rlimit_max = (IntPtr) 2;

int result = setrlimit (RLIMIT_NOFILE, data);
if (result != 0) {
throw new Exception (Cannot change limit
 on open files);
}

for (int i=0; inFiles; ++i) {
path = string.Format (file{0}.out, i);
try {
streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
} catch (Exception ex) {
Console.WriteLine (Unable to write
 file {0}, path);
Console.WriteLine (ex.Message);
Console.WriteLine (ex.StackTrace);
return;
}
}
}

const int RLIMIT_NOFILE = 7;

[DllImport (libc, SetLastError = true)]
unsafe extern static int setrlimit(int resource, rlimit*
 rlim);

}
 }
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] GUI available for heap profiling under mono 2.10+

[Alan]

The HeapShot GUI has been updated to work with the new profiler in Mono 2.10
and higher. Detailed information on how to use it and where to get the code
can be found here:  http://www.mono-project.com/HeapShot . Patches are
welcome if anyone finds bugs or wants to add new and interesting features.
It is good enough to be considered a beta application - not completely bug
free but more than good enough to work with.

Alan.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] COM, Threads and Mono

[Alan]

The System.Windows.Forms sync context runs stuff on the winforms main loop,
so wouldn't it be prone to exactly the message pumping related deadlocks
that were already described?

Alan

On 2 September 2011 18:30, Robert Jordan robe...@gmx.net wrote:

 Hi Jonathan,

 How about relying on System.Threading.SynchronizationContext.Current?
 This could work w/out exposing any internal calls/env vars.

 This way we offload the burden of implementing a suitable
 SynchronizationContext on the COM consumer. Done ;)

 The necessary runtime changes are as simple as this:

 ~__ComObject ()
 {
SynchronizationContext.Current.Post(delegate {
 ReleaseInterfaces ();
});
 }

 Consumers publish their own SynchronizationContext with
 SynchronizationContext.SetSynchronizationContext(
new MySuperCoolSyncContext());

 Robert

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] HeapShot like GUI

[Alan]

Yes!

It's called 'HeapShot' :D Information on how to use the mono log profiler in
heap shot mode and view the information in the HeapShot GUI is here:
http://mono-project.com/HeapShot

I'm not 100% sure if the new code has been merged into mainline yet, I'll
check. If it hasn't been, just check the code out from here:
https://github.com/slluis/heap-shot . All you need to build is the HeapShot
GUI and related tooling, so just open the project in MonoDevelop or use
xbuild.

Alan

2011/8/31 Konrad M. Kruczyński konrad.kruczyn...@gmail.com

 Hi,
  is there some kind of HeapShot like GUI for Mono profiler?

 --
 Regards,
  Konrad Kruczynski
 ___
 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] Performance issue with DataTable.Load on large data sets

[Alan]

Hey,

On Tue, Apr 12, 2011 at 11:09 AM, Nicklas Overgaard nick...@isharp.dk wrote:
 Hey Alan,

 Thanks for picking it up :)

 Firstly the simple change of moving the BeginLoad/EndLoad out of the
 loop could easily be committed as a separate patch. If it's possible
 to verify this change with an additional unit test, all the better! It
 means it can never regress again.

 Well, the thing is that the simple move of Begin/End load actually
 breaks four of the tests. However, after reviewing the test code, i'm
 seriously doubting that the test is correct - hence the question about
 having verified it on windows :)

In that cast running those 4 tests on the microsoft implementation
would be the way forward. If they pass there then you know the change
requires further modifications to be correct. If they fail, then you'd
just have to update them so that they pass. Note that in that case
you'll have to run the tests under the 2.0, 3.0 and 4.0 frameworks in
case it was a behavioural change between newer and older runtimes. The
perf improvement is definitely worth the time this will take :)

Alan


 The patch along with a little graph showing the performance improvement
 has been attached.

 I hope that someone with more insigt in System.Data can shed some light
 on the now-broken unit tests.

 I will get back when i have fixed the remaining issues, which also
 gives more performance.

 And thanks for the tips about testing it on windows. I will figure
 something out.

 Best regards,

 Nicklas

 On Tue, 2011-04-12 at 10:38 +0100, Alan wrote:
 Hey,

 Firstly the simple change of moving the BeginLoad/EndLoad out of the
 loop could easily be committed as a separate patch. If it's possible
 to verify this change with an additional unit test, all the better! It
 means it can never regress again.

 As for the failing tests, the simplest thing to do would be to
 copy/paste the test assembly from linux to windows and execute it
 there to see if all the tests pass. If that doesn't work you could try
 copying/pasting the individual tests you want to verify, compiling
 them on windows and executing that. The complicated way of testing
 would be to check out mono from git, build it on windows and then run
 the tests. Either way, a commit which regresses tests can't be
 accepted unless those tests can be proven to be incorrect (i.e. the
 fail under MS .NET). It's also possible that these are behavioural
 differences between .NET 3 and .NET 4, in which case the modifications
 would have to be conditionally built.

 Alan

 On Tue, Apr 12, 2011 at 9:41 AM, Nicklas Overgaard nick...@isharp.dk wrote:
  Hi again,
 
  I have now made further optimizations, which brings the Load method up
  to speed with the .net implementation. However, 5 of the
  regression-tests are now failing.
 
  Have all these System.Data regression tests been verified on a windows
  machine with .net? I just don't want to chase bugs / regressions that
  does not exist/are not valid :)
 
  Best regards,
 
  Nicklas
 
  On Thu, 2011-04-07 at 20:13 +0200, Nicklas Overgaard wrote:
  Hi again,
 
  Sorry for the spamming.
 
  Moving out the Begin and End load methods reduced DataTable.Load
  time to 1.7 seconds on my test machine, so we are getting there!
 
  /Nicklas
 
  On Thu, 2011-04-07 at 19:29 +0200, Nicklas Overgaard wrote:
   Hi again,
  
   I now have a profile log, created with the new mono profiler. It shows,
   that the method EndLoadData is using up almost all of the time (16
   minutes of the 17 minutes it took to create the dump).
  
   When looking in the file DbDataAdapter.cs line 355 in current GIT
   head, the BeginLoadData and EndLoadData methods are called for each
   iteration in the DataReader's data.
  
   This means that for each row we add to the DataTable, the DataSet is
   begin asked to enforce constraints and other stuff in the datatable.
  
   According to MSDN:
   http://msdn.microsoft.com/en-us/library/system.data.datatable.beginloaddata.aspx
  
   BeginLoadData Turns off notifications, index maintenance, and
   constraints while loading data.
  
   So would'nt it make sense to move BeginLoad.. and EndLoad.. out of
   the loop?
  
   Well, I'm trying it out :)
  
   Best regards,
  
   Nicklas Overgaard
  
   On Thu, 2011-04-07 at 14:58 +0200, Nicklas Overgaard wrote:
Hi mono-devers!
   
I'm currently working on a rather large webproject, where we are 
using a
combination of mono 2.10.1 and MySQL.
   
Over the past week, I have observed that loading large datasets 
(5000+
rows) from mysql into a DataTable takes a very long time.
   
It's done somewhat like this:
code
   
comm.CommandText = query;
comm.CommandTimeout = MySQLConnection.timeout;
MySqlDataReader reader = (MySqlDataReader)comm.ExecuteReader();
DataTable dt = new DataTable();
dt.Load(reader); // - this is killing mono
reader.Close();
   
/code
   
I have created a small testprogram, compiled it on my linux

Re: [Mono-dev] Performance issue with DataTable.Load on large data sets

[Alan]

Hey,

Firstly the simple change of moving the BeginLoad/EndLoad out of the
loop could easily be committed as a separate patch. If it's possible
to verify this change with an additional unit test, all the better! It
means it can never regress again.

As for the failing tests, the simplest thing to do would be to
copy/paste the test assembly from linux to windows and execute it
there to see if all the tests pass. If that doesn't work you could try
copying/pasting the individual tests you want to verify, compiling
them on windows and executing that. The complicated way of testing
would be to check out mono from git, build it on windows and then run
the tests. Either way, a commit which regresses tests can't be
accepted unless those tests can be proven to be incorrect (i.e. the
fail under MS .NET). It's also possible that these are behavioural
differences between .NET 3 and .NET 4, in which case the modifications
would have to be conditionally built.

Alan

On Tue, Apr 12, 2011 at 9:41 AM, Nicklas Overgaard nick...@isharp.dk wrote:
 Hi again,

 I have now made further optimizations, which brings the Load method up
 to speed with the .net implementation. However, 5 of the
 regression-tests are now failing.

 Have all these System.Data regression tests been verified on a windows
 machine with .net? I just don't want to chase bugs / regressions that
 does not exist/are not valid :)

 Best regards,

 Nicklas

 On Thu, 2011-04-07 at 20:13 +0200, Nicklas Overgaard wrote:
 Hi again,

 Sorry for the spamming.

 Moving out the Begin and End load methods reduced DataTable.Load
 time to 1.7 seconds on my test machine, so we are getting there!

 /Nicklas

 On Thu, 2011-04-07 at 19:29 +0200, Nicklas Overgaard wrote:
  Hi again,
 
  I now have a profile log, created with the new mono profiler. It shows,
  that the method EndLoadData is using up almost all of the time (16
  minutes of the 17 minutes it took to create the dump).
 
  When looking in the file DbDataAdapter.cs line 355 in current GIT
  head, the BeginLoadData and EndLoadData methods are called for each
  iteration in the DataReader's data.
 
  This means that for each row we add to the DataTable, the DataSet is
  begin asked to enforce constraints and other stuff in the datatable.
 
  According to MSDN:
  http://msdn.microsoft.com/en-us/library/system.data.datatable.beginloaddata.aspx
 
  BeginLoadData Turns off notifications, index maintenance, and
  constraints while loading data.
 
  So would'nt it make sense to move BeginLoad.. and EndLoad.. out of
  the loop?
 
  Well, I'm trying it out :)
 
  Best regards,
 
  Nicklas Overgaard
 
  On Thu, 2011-04-07 at 14:58 +0200, Nicklas Overgaard wrote:
   Hi mono-devers!
  
   I'm currently working on a rather large webproject, where we are using a
   combination of mono 2.10.1 and MySQL.
  
   Over the past week, I have observed that loading large datasets (5000+
   rows) from mysql into a DataTable takes a very long time.
  
   It's done somewhat like this:
   code
  
   comm.CommandText = query;
   comm.CommandTimeout = MySQLConnection.timeout;
   MySqlDataReader reader = (MySqlDataReader)comm.ExecuteReader();
   DataTable dt = new DataTable();
   dt.Load(reader); // - this is killing mono
   reader.Close();
  
   /code
  
   I have created a small testprogram, compiled it on my linux machine and
   executed it.
  
   It takes 15 seconds to do such operation under mono - but on windows it
   takes only 0.4 seconds (with the same executable, fetching the same
   data). I have profiled the application on windows, and it seems that
   the .net framework is using specialized methods for loading data from a
   datareader.
  
   I have been looking through the implementation in mono, in regard to
   DataTable.Load, and I can see that a lot of validation and other stuff
   is going on, which could explain the huge difference. I'm also working
   on a mono log profile trace, to dig a little deeper.
  
   Would it be OK, if I tried to patch the current mono implementation to
   gain the same speeds as .net? The reason for asking, is that I know that
   I cannot contribute to Mono if I have seen the actual code in .NET (but
   does a profile result count as seeing the code?)
  
   Best regards,
  
   Nicklas Overgaard
  
   ___
   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

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] StackOverflow on System.Delegate.Equals

[Alan]

Aren't event handler methods emitted with a [synchronized] attribute by
default which would prevent this issue? You can check by disassembling the
IL and seeing if its there.

Alan

On 4 Apr 2011 14:55, kr...@poczta.onet.pl wrote:
 W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza mig...@novell.com
napisał:

 While another one is doing an equality test, the state is half-built.
 The way you could instrument this is to rewrite that routine to not be
 recursive, but instead to be iterative, and have a maximum count,
 something like:

 MulticastDelegate track_this = this;
 MulticastDelegate track_other = d;

 for (int i = 0; i  1; i++){
 object this_prev = track_this.prev;
 object other_prev = d.prev;

 if (this_prev != other_prev)
 return false;
 }
 if (i == 1)
 Console.WriteLine (The corrupted instance is {0}, this.GetType ());

 return true;

 Thanks for your reply. I'm not sure but it seems that your snippet will
put a text on a screen always when the delegates are equal. Anyway, I've
rewrote that routine as you suggested and here's the result:
http://monobin.com/__mb1963e9

 I've also just added a lines like below to the end of original equals
method.

 if (this == this.prev)
 Console.WriteLine (The corrupted instance is {0}, this.GetType ());
 return this.prev.Equals(d.prev);

 ...and I'm waiting for a crush.
 I'd appreciate any other hints or advices. Thanks in advance.
 Best regards,
 Marcin

 ___
 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] StackOverflow on System.Delegate.Equals

[Alan]

Hey,

Well the other thing is that the delegate class is supposed to be
immutable. Therefore it should be impossible to produce a corrupt
delegate through multithreaded access as any modification to a
delegate instance results in a new copy of the delegate (with
modification) being created, just like for string operations. If what
we're seeing is truly a corrupt delegate instance then it's a bug in
mono that this is able to occur.

Alan

On Mon, Apr 4, 2011 at 10:54 PM,  kr...@poczta.onet.pl wrote:
 On Mon, 2011-04-04 22:41:47 nekresh nekr...@gmail.com wrote:
 On Mon, Apr 4, 2011 at 10:37 PM,  kr...@poczta.onet.pl wrote:
  On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier 
  gonzalo.m...@gmail.com wrote:
  On Mon, 2011-04-04 at 20:48 +0100, Alan wrote:
   Aren't event handler methods emitted with a [synchronized] attribute
   by default which would prevent this issue? You can check by
   disassembling the IL and seeing if its there.
 
  They are synchronized as long as you don't replace the default
  add/remove with your own code.
 
  AFAIK you cannot inherit from the Delegate/MulticastDelegate class. So how 
  can I replace the default add/remove code? Anyway I'm almost sure that 
  case has no place in my code but I have to take a look on 3rd part 
  libraries.  Thanks in advance for any help.
 
 public event MyType MyEvent {
   add { }
   remove { }
 }

 Ok, thanks. I found in Telerik's code a few places where code looks like:
                public event XmlHttpPanelEventHandler ServiceRequest
                {
                        add
                        {
                                base.Events.AddHandler(WebServiceRequestEvent, 
 value);
                        }
                        remove
                        {
                                
 base.Events.RemoveHandler(WebServiceRequestEvent, value);
                        }
                }

 The base.Events is a property of the WebControl class. Maybe that's the 
 problem?
 I've also took a look on a code generated for a default event handler (from 
 my class):

 internal event EventHandlerMenuItemClickedEventArgs ItemClicked
 {
    add
    {
        EventHandlerMenuItemClickedEventArgs handler2;
        EventHandlerMenuItemClickedEventArgs itemClicked = this.ItemClicked;
        do
        {
            handler2 = itemClicked;
            EventHandlerMenuItemClickedEventArgs handler3 = 
 (EventHandlerMenuItemClickedEventArgs) Delegate.Combine(handler2, value);
            itemClicked = 
 Interlocked.CompareExchangeEventHandlerMenuItemClickedEventArgs(ref 
 this.ItemClicked, handler3, handler2);
        }
        while (itemClicked != handler2);
    }
    remove
    {
        EventHandlerMenuItemClickedEventArgs handler2;
        EventHandlerMenuItemClickedEventArgs itemClicked = this.ItemClicked;
        do
        {
            handler2 = itemClicked;
            EventHandlerMenuItemClickedEventArgs handler3 = 
 (EventHandlerMenuItemClickedEventArgs) Delegate.Remove(handler2, value);
            itemClicked = 
 Interlocked.CompareExchangeEventHandlerMenuItemClickedEventArgs(ref 
 this.ItemClicked, handler3, handler2);
        }
        while (itemClicked != handler2);
    }
 }


 Kind regards,
 Marcin




 ___
 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] (no subject)

[Alan]

Hi,

If I understand you correctly you wish to take some existing classes
from the core Java framework and simply re-implement them in C# even
if similar classes already exist in the .NET framework. If so this is
definitely not something that would qualify as a GSoC project as it
would provide no benefit to anyone. A better task would be to take
some unimplemented or poorly implemented APIs and either implementing
or improving them as appropriate. Alternatively you could look at our
list of available projects.

Alan.

On Sun, Mar 20, 2011 at 8:21 PM, Adam Balan a-k...@hotmail.com wrote:
  I am a novice to c# so  I thought I would convert the java core writer and
 reader and there associated class files to c# to learn about  interfaces,
 class files, constructing methods and more.

 I understand that c# has such class files already but I wanted to know what
 it would be like to convert java to c# and see where the core differences
 are in the languages.

 Anyways i still have some testing and commenting to do and I am wondering
 what this communities policies are if I wanted to share this under the same
 license as the java license with the community.


 This message was sent from:

 Adam Balan's iPhone
 Phone: 403-465-4776
 Email: a-k...@hotmail.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] Unable to build neither Mono 2.10.1 nor 2.10

[Alan]

The rabbitmq issue should be fixed as of a couple of weeks ago. If you
hit any other issues with parallel builds do let us know. I normally
build with -j8 and occasionally hit build breakages but I haven't been
able to track down the issue.

Alan.

On Sat, Mar 19, 2011 at 8:21 PM, Leszek Ciesielski skol...@gmail.com wrote:
 I've been building Mono with 'make -j5' for a long time (at least 2
 years), and if anything breaks - it's always the RabbitMQ. Wouldn't it
 be possible to improve the dependencies for it so that a parallel
 build is usable? It's a massive speed-up on any modern CPU.

 (I know, talk is cheap, but I'm really terrible with autotools.)

 Regards,

 Leszek

 2011/3/12 Marek Safar marek.sa...@gmail.com:
 Hello,

 You cannot use parallel build (usually make -j) with Mono 2.10

 Marek

 Hi,

 I’m trying to build Mono both 2.10.1 and 2.10 from source archive downloaded
 from http://ftp.novell.com/pub/mono/sources/mono/

 OS Debian 6

 $ uname -a

 Linux debian 2.6.32-5-686 #1 SMP Wed Jan 12 04:01:41 UTC 2011 i686 GNU/Linux



 but with equal errors in both archives:



 * Generating code into 'autogenerated-api-0-9.cs'

 Missing method System.Type::op_Inequality(Type,Type) in assembly
 /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in
 assembly
 /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe



 Unhandled Exception: System.MissingMethodException: Method not found:
 'System.Type.op_Inequality'.

   at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod
 (System.Reflection.MethodInfo method) [0x0] in filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in
 filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in
 filename unknown:0

 Missing method System.Type::op_Inequality(Type,Type) in assembly
 /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in
 assembly
 /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe

 Missing method System.Type::op_Inequality(Type,Type) in assembly
 /usr/src/mono/mono-2.10/mcs/class/lib/net_2_0/mscorlib.dll, referenced in
 assembly
 /usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/src/apigen/RabbitMQ.Client.Apigen.exe

 make[9]: *** [autogenerated-api-qpid-0-8.cs] Error 1

 make[9]: *** Waiting for unfinished jobs

 MONO_PATH=./../../../../class/lib/net_4_0:$MONO_PATH
 /usr/src/mono/mono-2.10/runtime/mono-wrapper
 ../../src/apigen/RabbitMQ.Client.Apigen.exe /n:v0_8 /apiName:AMQP_0_8
 amqp0-8.stripped.xml autogenerated-api-0-8.cs



 Unhandled Exception: System.MissingMethodException: Method not found:
 'System.Type.op_Inequality'.

   at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod
 (System.Reflection.MethodInfo method) [0x0] in filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in
 filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in
 filename unknown:0

 make[9]: *** [autogenerated-api-0-9.cs] Error 1



 Unhandled Exception: System.MissingMethodException: Method not found:
 'System.Type.op_Inequality'.

   at RabbitMQ.Client.Apigen.Apigen.MaybeEmitModelMethod
 (System.Reflection.MethodInfo method) [0x0] in filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in
 filename unknown:0

   at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in filename
 unknown:0

   at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in
 filename unknown:0

 make[9]: *** [autogenerated-api-0-8.cs] Error 1

 make[9]: Leaving directory
 `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs'

 make[8]: *** [do-all] Error 2

 make[8]: Leaving directory
 `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client/docs/specs'

 make[7]: *** [all-recursive] Error 1

 make[7]: Leaving directory
 `/usr/src/mono/mono-2.10/mcs/class/RabbitMQ.Client'

 * Loading spec from 'amqp0-8.stripped.xml'

 make[6]: *** [all-recursive] Error 1

 * Parsing spec

 make[6]: Leaving directory `/usr/src/mono/mono-2.10/mcs/class'

 * Generating code into 'autogenerated-api-0-8.cs'

 make[5]: *** [all-recursive] Error 1

 make[5]: Leaving directory `/usr/src/mono/mono-2.10/mcs

Re: [Mono-dev] Implementation of SetPropertyItem

[Alan]

Simplest thing to do is run a git blame on the file and see when the
lines were changed last. The code was commented out in rev  83c90e2.
The commit message is:

Image.cs: throw NotImplementedException in SetPropertyItem instead
of executing broken code. See #406307 for test case.

So check out http://bugzilla.novell.com for that bug number and you'll
see why the code is disabled.

Alan.

On Tue, Nov 23, 2010 at 6:41 PM, Patrick Kowalzick
patrick.kowalz...@web.de wrote:
 Dear List,

 I found that System.Drawing.Image::SetPropertyItem throws a
 NotImplementedException.

 The code from
 https://github.com/mono/mono/blob/master/mcs/class/System.Drawing/System.Drawing/Image.cs
 looks like

 public void SetPropertyItem(PropertyItem propitem)
 {
   throw new NotImplementedException ();
   /*
     GdipPropertyItem pi = new GdipPropertyItem ();
     GdipPropertyItem.MarshalTo (pi, propitem);
     unsafe {
       Status status = GDIPlus.GdipSetPropertyItem (nativeObject, pi);
       GDIPlus.CheckStatus (status);
     }
   */
 }

 On a first glance the code inside the comment doesn't look that bad, and
 I do not understand why it is commented out.

 The Implementation of GdipSetPropertyItem in libgdiplus could work as well:
 [https://github.com/mono/libgdiplus/blob/master/src/image.c]


 I have two questions concerning this issue:

 1.) How do I find out, why the code is disabled?

 2.) If the libgdiplus code is incorrect, couldn't the SetPropertyItem
 check for Windows, then using the commented code? Something like:

 public void SetPropertyItem(PropertyItem propitem)
 {
   if (!IsWindows())
     throw new NotImplementedException ();
   else
   {
     GdipPropertyItem pi = new GdipPropertyItem ();
     GdipPropertyItem.MarshalTo (pi, propitem);
     unsafe {
       Status status = GDIPlus.GdipSetPropertyItem (nativeObject, pi);
       GDIPlus.CheckStatus (status);
     }
   }
 }


 Thanks and kind regards,
 Patrick

 ___
 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] Moonlight basics - Overview

[Alan]

Hey

On Tue, Nov 9, 2010 at 3:08 PM, Sasi Rekha Kristam
sasirekha.kris...@gmail.com wrote:
 Hi,
 I am starting up with moonlight with a very minimal knowledge of
 Silverlight. Could somebody let me know where I can find detailed
 information on the below topics?
 - What is Moonlight?
Moonlight is silverlight for Linux (and more, potentially).

 - Why Moonlight?
 - Architecture
 - Pros and Cons
 - Sample websites
Any documentation on silverlight applies equally to moonlight as they
are the same thing just on different platforms.

Hope that helps,
Alan.


 Regards,
 Sasi Rekha.


 ___
 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] Moonlight basics - Overview

[Alan]

http://en.wikipedia.org/wiki/Mono_%28software%29

That should help at least partially.

Alan.

On Tue, Nov 9, 2010 at 4:17 PM, Sasi Rekha Kristam
sasirekha.kris...@gmail.com wrote:
 I wouldn't have got this mailing list id unless i have searched the web.
 Reply to the e-mail only if u can help with the relevant information.

 On Tue, Nov 9, 2010 at 4:59 PM, Stifu st...@free.fr wrote:

 How do I search the web? would be a better question, as it'd let you
 find
 answers for everything else. :)


 Sasi Rekha Kristam wrote:
 
  Thank you for the quick reply. How does the compilation and other stuff
  happens for Moonlight and what is Mono?
 
  On Tue, Nov 9, 2010 at 4:19 PM, Krishna Kishore
  kishorekan...@gmail.comwrote:
 
  Did you check http://www.mono-project.com/Moonlight???
 
  Regards,
  Kishore.
 
  On Tue, Nov 9, 2010 at 10:14 AM, Alan alan.mcgov...@gmail.com wrote:
 
  Hey
 
  On Tue, Nov 9, 2010 at 3:08 PM, Sasi Rekha Kristam
  sasirekha.kris...@gmail.com wrote:
   Hi,
   I am starting up with moonlight with a very minimal knowledge of
   Silverlight. Could somebody let me know where I can find detailed
   information on the below topics?
   - What is Moonlight?
  Moonlight is silverlight for Linux (and more, potentially).
 
   - Why Moonlight?
   - Architecture
   - Pros and Cons
   - Sample websites
  Any documentation on silverlight applies equally to moonlight as they
  are the same thing just on different platforms.
 
  Hope that helps,
  Alan.
 
  
   Regards,
   Sasi Rekha.
  
  
   ___
   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
 
 
 
 
 
  --
  Regards,
  Sasi Rekha.
 
  ___
  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://mono.1490590.n4.nabble.com/Moonlight-basics-Overview-tp3034420p3034517.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



 --
 Regards,
 Sasi Rekha.


 ___
 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] High Traffic Site (for Harry Potter 7) is crashing!

[Alan]

Did you read through the docs here?
http://www.mono-project.com/Mod_mono#Limiting_the_number_of_concurrent_requests
. It covers increasing the concurrent users in a variety of different
ways.

Alan.

On Tue, Oct 26, 2010 at 9:59 PM, Matthew Urbano
matthew.urb...@trailerpark.com wrote:
 I've created a site for the new Harry Potter movie which is expected to get
 a high volume of traffic, and on launch day we are now crashing.



 We are getting the following errors on the webservers due to traffic:

 Maximum number of concurrent mod_mono requests to
 /tmp/mod_mono_dashboard_default_2.lock reached (20 active, 20 waiting).
 Request dropped.

 I have the following config:

 User nobody

 Group nobody

 include /etc/httpd/conf/mod_mono.conf

 MonoSetEnv MONO_THREADS_PER_CPU=500



 And have also added this:



 MonoMaxActiveRequests 0

 MonoMaxWaitingRequests 0



 These settings do not seem to be taking affect.  What other steps should we
 take to allow mono to handle the traffic?



 --
 Matthew Urbano | Web Developer
 Trailer Park Interactive
 6922 Hollywood Blvd., 7th floor
 Hollywood, CA  90028
 T: 310-845-3021
 M: 305-790-1805
 matthew.urb...@trailerpark.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] mono.simd

[Alan]

I think you missed the important part of that last email. If wanted you to
state the license of the patch, then commit it :)

Alan.

On 27 Aug 2010 02:10, Jerry Maine - KF5ADY crashfou...@gmail.com wrote:

 Please, I found this bug to be very annoying as it hampers the use of
dynamic languagues with Mono.Simd. I found this bug trying to use mono.simd
in ironpython.




On 08/25/2010 09:56 PM, Rodrigo Kumpera wrote:



 a

 On Mon, Aug 23, 2010 at 7:01 PM, Robert Jordan robe...@gmx.net wrote:

 On 23.08.20...


___
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] Migration to GitHub completed!

[Alan]

Hey,

On Wed, Jul 28, 2010 at 10:21 AM, pablosantosl...@terra.es 
pablosantosl...@terra.es wrote:

 Hi all,

 So, now instead of a svn checkout, in order to build from sources,
 should we type something like the following?

 git clone git://github.com/mono/mono.git

 Is that correct?


Yes, this is correct. The download size is a bit bigger than with svn but
not significantly so. Note that this single repo is the combination of the
old 'mono' and 'mcs' modules which were in SVN. You don't have to make two
separate checkouts anymore.

Alan



 I guess not really since it's downloading the entire mono repo, which is
 a terrible overkill, isn't it??

 Thanks,

 pablo


 On 23/07/2010 8:38, Raja R Harinath wrote:
  Hi,
 
  pablosantosl...@terra.es pablosantosl...@terra.es writes:
 
  Congrats Gonzalo!!!
 
  Question: how long did the import take??
 
  The actual import run takes about 2-3 hours.  The whole process of
  debugging and fixing the import tool, fine-tuning the import, figuring
  out mappings between SVN committers and GitHub accounts, etc. took about
  a month.
 
  - Hari
 
  ___
  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] github workflow proposals

[Alan]

For commit messages, how about gnome style ones?

http://live.gnome.org/Git/CommitMessages

We'll end up with messages like this:
http://github.com/mono/moon/commit/feadf070d237c1227ff2709cf1d0131d267118e2:)

Alan.

On Tue, Jul 27, 2010 at 11:16 PM, Mark Probst mark.pro...@gmail.com wrote:

 On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera kump...@gmail.com
 wrote:
  I have another proposition to make. Can we stop using Changelog files?
 Those
  can be generated from the commit logs for tarballs and releases without
  losing anything at all. Commit messages would still have to be at least
 as
  informative as they currently are.
  Not having Changelog files resolve 90%+ of our sources of conflicts and
 make
  the forkqueue much more useful. If we are to move to a DVCS style of
  development, this will be a big barrier otherwise.

 I totally agree with this.  A few days ago I wanted to merge a simple
 commit Sanjoy made, and the fork queue would have been perfect for
 this.  Unfortunately it didn't grok the ChangeLog conflict, so I had
 to pull the change myself, rebase it on master and then push it by
 hand.

 I also agree with the one-line summaries and work branches in private
 repositories.

 Mark
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Problem in SvcHttpHandler.cs ?

[Alan McGovern]

The reason why there are no synchronous calls in silverlight is (I  
believe) because you can easily deadlock the plugin by attempting a  
synchronous call when using the browser http stack. For the web  
request to be completed, the browser has to be able to iterate and if  
a plugin is blocking, there's nothing the browser can do.

If I remeber correctly there is an explanation of this on msdn  
somewhere.

Alan

On 6 Jul 2010, at 05:08, Atsushi Eno atsushi...@veritas-vos-liberabit.com 
  wrote:

 Hello Thiago,

 Thanks, there's a lot of major and minor missing functionalities all
 around. Our class status
 describes large part of those missing stuff (primarily in
 System.ServiceModel.dll):
 http://go-mono.com/status/

 Right now we have no plan to build mono specific WCF libraries. IMO
 libraries like
 what you said should be released cross platform, at places like  
 codeplex.
 Instead you might have some useful code that could be used in our own
 core WCF
 assemblies (imagine if you have implemented WS-AtomicTransaction aside
 TransactionFlowBindingElement, and we don't have working code now.)

 Atsushi Eno

 On 2010/07/05 21:27, Thiago Padilha wrote:
  Hi Atsushi,

  I have started messing with WCF last week but I'm very interested in
 learning, If you need help with anything just send me a message.
  Also, today I'm starting to develop an http binding/channel to allow
 REST syncronous programming of WCF Services/Clients(compatible with
 moonlight/silverlight 2/3). I know syncronous service calls aren't
 officially supported by Silverlight, but(correct me if I'm wrong) I
 don't see why that should'nt work if I extend at channel level. If  
 you
 want to integrate my source code in the Mono specific libraries I'd  
 be
 happy to send you.

 On Fri, Jul 2, 2010 at 3:54 PM, Atsushi Eno
 atsushi...@veritas-vos-liberabit.com  wrote:

 Hi,

 Right, thanks for the analysis, that should be fixed, and I have  
 an idea.
 Though I am now rewriting ASP.NET channel support based on our new  
 HTTP
 (non-ASP.NET) channel stack and it does not use the code path you  
 mentioned,
 I'd rather finish the rewrite first and then fix the actual issue.

 The idea above is to use Uri comparison using UriComponents based on
 HostNameComparisonMode value (which is ignored so far).

 Atsushi Eno

 On 2010/06/29 21:46, Thiago Padilha wrote:

Hi,

I'm hosting a WCF service using asp.net/mono from trunk  
 (r159644)
 but encountered a problem when accessing the service from a virtual
 machine :

 
   The argument HTTP context did not match any of the registered
 listener manager (could be mismatch in URL, method etc.)
 http://172.16.122.2:8080/Person.svc

 Description: HTTP 500. Error processing request.

 Stack Trace:

 System.InvalidOperationException: The argument HTTP context did not
 match any of the registered listener manager (could be mismatch in
 URL, method etc.) http://172.16.122.2:8080/Person.svc
   at  
 System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
 (System.Web.HttpContext ctx) [0x00120] in

 /home/thiago/monotrunk/mcs/class/System.ServiceModel/ 
 System.ServiceModel.Channels/SvcHttpHandler.cs:141
   at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
 (System.Web.HttpContext context) [0xd] in

 /home/thiago/monotrunk/mcs/class/System.ServiceModel/ 
 System.ServiceModel.Channels/SvcHttpHandler.cs:156
   at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext ()
 [0x00ce5] in
 /home/thiago/monotrunk/mcs/class/System.Web/System.Web/ 
 HttpApplication.cs:1344
   at System.Web.HttpApplication.Tick () [0x0] in

 /home/thiago/monotrunk/mcs/class/System.Web/System.Web/ 
 HttpApplication.cs:914
 

  I think this happened because I tried to access the service trough
 the 172.16.122.0 network which is the virtual network for my VMs.
 The service works well if I access it on the local machine using  
 the
 http://127.0.0.1:8080/Person.svc; Url, but fails with the same  
 error
 if I use http://localhost:8080/Person.svc;. After looking into the
 source code I think the problem may be on the following  
 conditionals
 (method 'FindBestMatchListener') :

 
 if (l.Uri.Equals (ctx.Request.Url)) {
best = l;
break;
}
 //
 if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
 StringComparison.Ordinal))
continue;
 

 Maybe it should check the Uris for all the network interfaces?(I  
 have
 no idea on how to do that).
 ___
 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

Re: [Mono-dev] Bug 470120 - Socket.EndSend unexpectedly fails with WSAEWOULDBLOCK

[Alan McGovern]

So the patch fixes the Begin/EndSend issue but breaks BeginConnect?
Maybe that's a good reason to not commit the patch until the issue
with BeginConnect is fixed. Would you be capable of diagnosing andor
fixing the issue or do we need another OSX guy to look at it? You
should probably add information about exactly what's broken to the bug
report.

Alan.

On Thu, Jun 10, 2010 at 3:01 PM, yoni shalom silve...@gmail.com wrote:
 shameless ping...

 On Mon, Jun 7, 2010 at 11:03 AM, yoni shalom silve...@gmail.com wrote:
 Does anyone know the status of this bug ?
 It was found in 2.4.x, theres a patch there but it hasn't seen its way
 into trunk, can someone take a look please ?

 https://bugzilla.novell.com/show_bug.cgi?id=470120

 Thanks.

 ___
 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] Compiler bug in foreach

[Alan McGovern]

There was a regression in trunk about 2 weeks ago which was fixed
about 4 days ago which was very similar to this. However your testcase
appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
file a bug report with this testcase?

Thanks!
Alan.

On Sat, May 29, 2010 at 2:11 AM, Robert Jordan robe...@gmx.net wrote:
 On 29.05.2010 01:44, Mehrdad Reshadi wrote:
 I found the following bug, wondering if others have seen this, or anything
 is being done to solve it. foreach is too common to have such a bug!

          public static void Main(string[] args)
          {
              var o = new Y();
              foreach (var c in new A[3] { new A(), new B(), new C() })
                  c.f(o);
              new B().f(o);
          }

 foreach is obviously not the culprit, because the issue can
 be reproduced with an unrolled loop:

         public static void Main(string[] args)
         {
             var o = new Y();
             var a = new A[3] { new A(), new B(), new C() };
            a[0].f(o);
            a[1].f(o);
            a[2].f(o);
             new B().f(o);
         }

 Please visit http://mono-project.com/Bugs and file a bug.

 Robert

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiler bug in foreach

[Alan McGovern]

Hey,

I filed a bug and then realised you had already filed it. I marked
mine as a duplicate of yours and changed the severity of yours to a
more appropriate level. Generally speaking we reserve 'critical' for
bugs which affect a large proportion of applications ( 50%) and cause
major issues or security holes in those applications.

Thanks for filing the bug and hopefully it'll get sorted soon. If you
need a workaround *right now* then the easiest thing to do would be to
compile using the microsoft compiler and then run the resulting
assembly under mono. This is purely a compile time bug.

Alan.

On Sun, May 30, 2010 at 4:53 PM, Alan McGovern alan.mcgov...@gmail.com wrote:
 There was a regression in trunk about 2 weeks ago which was fixed
 about 4 days ago which was very similar to this. However your testcase
 appears to fail on both mono 2.6.4 and svn trunk. Would you be able to
 file a bug report with this testcase?

 Thanks!
 Alan.

 On Sat, May 29, 2010 at 2:11 AM, Robert Jordan robe...@gmx.net wrote:
 On 29.05.2010 01:44, Mehrdad Reshadi wrote:
 I found the following bug, wondering if others have seen this, or anything
 is being done to solve it. foreach is too common to have such a bug!

          public static void Main(string[] args)
          {
              var o = new Y();
              foreach (var c in new A[3] { new A(), new B(), new C() })
                  c.f(o);
              new B().f(o);
          }

 foreach is obviously not the culprit, because the issue can
 be reproduced with an unrolled loop:

         public static void Main(string[] args)
         {
             var o = new Y();
             var a = new A[3] { new A(), new B(), new C() };
            a[0].f(o);
            a[1].f(o);
            a[2].f(o);
             new B().f(o);
         }

 Please visit http://mono-project.com/Bugs and file a bug.

 Robert

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration

[Alan McGovern]

I am thinking of a Java/.NET split if you will where we keep what we
can that WILL run under Mono and port the rest to Java. That assumes
we can get the two to play nicely together.

Depending on what it is that doesn't work, it's possible that it'd
only take you a couple of days could fix your issue. That'd be
significantly less time than porting to java. You'd have to way up the
pros and cons of rewriting in java. The biggest con is that you have
doubled your maintainance burden if you have the same code in two
languages.

Alan.

On Tue, May 25, 2010 at 9:09 PM, Greg Robinson gregarobin...@gmail.com wrote:
 Matt,

  it looks like most of the ClientCredentials class is done so you might be
 able to configure the necessary ClientCredentials in code rather than using
 .config files. 

 So are you stating Mono is not app.config file friendly? So it's possible
 if we hard code these bits will run under Mono?



 On Tue, May 25, 2010 at 3:40 PM, Matt Dargavel m...@shout-telecoms.com
 wrote:

 Hi Greg,



 Have you tried running MoMA (http://www.mono-project.com/MoMa) against
 your application?  This should give you an idea of how much is missing from
 Mono.



 With respect to WCF and the specific problem you saw, I’ve not used the
 security stuff at all but it looks like most of the ClientCredentials class
 is done so you might be able to configure the necessary ClientCredentials in
 code rather than using .config files.  I don’t think the
 System.ServiceModel.Configuration namespace is as complete as some of the
 other bits.  You can find information on the implementation status at the
 links below.




 http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel

 http://www.mono-project.com/WCF



     Regards,



     Matt.





 From: mono-devel-list-boun...@lists.ximian.com
 [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Greg Robinson
 Sent: 25 May 2010 7:09 PM
 To: Stifu
 Cc: mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] System.NotImplementedException: The
 requestedfeature is not implemented.
 atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration



 Understood, and that was my first thought. Was just wondering if there
 were alternative solutions.

 I am thinking of a Java/.NET split if you will where we keep what we can
 that WILL run under Mono and port the rest to Java. That assumes we can get
 the two to play nicely together.

 Is there a way to see if someone is already working on the bits in Mono we
 need?


 On Tue, May 25, 2010 at 2:05 PM, Stifu st...@free.fr wrote:

 The obvious answer: contribute to Mono and help implement it. Or pay
 someone
 to do it.
 That's what some companies do. If you can afford it, that's an option
 (which
 might turn out to be cheaper than rewriting everything in Java; that said,
 I
 have no idea how much work is needed here).

 Greg Robinson wrote:
 
  I am new to Linux, new to Mono. I am really hoping we can use Mono for
  our
  .NET application to Linux port/migration.
 
  The other option on the table is to totally re-write in Java.
 
  So what do folks usually do at this point; the point where they find
  that
  something they need, our .NET Server application calling a WCF Service
  using
  System.ServiceModel bits, not implemented in Mono? It seems a shame to
  just
  give up and do a port to Java; is that my only solution though?
 
 
 
  On Tue, May 25, 2010 at 12:45 PM, Miguel de Icaza mig...@novell.com
  wrote:
 
 
   When I go to:
  
   http://mono-project.com/DistroPackages/Ubuntu
  
   it tells me Mono comes installed by default. We are running Ubuntu
   10.04.
  
   What do I need to do to upgrade to Mono 2.6 on Ubuntu 10.04?
 
  I am told that there are no 2.6 packages available for Ubuntu by the
  Debian/Ubuntu community.
 
  The bad news is that you need to compile from source code;   The good
  news is that this is a trivial process (as long as you use released
  tarballs):
 
  http://www.mono-project.com/Parallel_Mono_Environments
 
  Migue.
 
  
  
  
   On Mon, May 24, 2010 at 8:50 AM, Oskar Berggren
   oskar.bergg...@gmail.com wrote:
           2.2 is fairly old. Have you checked with 2.4 or 2.6?
  
           Try searching for moma and mono class library status.
  
           /Oskar
  
  
           2010/5/24 Greg Robinson gregarobin...@gmail.com:
  
             I have been making good progress on moving our .NET server
           application over
            to Mono 2.2 running on Ubuntu 2.2.
           
             Friday, I ported the WCF pieces over where all the server
           application does
            is make calls to a WCF service running on a windows server
           outside of our
            office.
           
             I am getting the following, which suggests to me these
           pieces of client
            side WCF are not implemented in Mono 2.2

Re: [Mono-dev] bug or wrong mono compilation?

[Alan McGovern]

It works fine with r156922 from SVN. When building from trunk, always
give the svn revision that you built with.

Alan.

On Sat, May 22, 2010 at 5:36 PM, xplicit s...@ngs.ru wrote:

 I have compiled mono 2.7 from trunk and try to use C# 4.0 features. I wrote
 simple program:

 using System;

 namespace test2
 {
        class MainClass
        {
                public static void Main (string[] args)
                {
                        dynamic a=new object();

                        Console.WriteLine(a.ToString());
                }
        }
 }

 and run it. I expect System.Object instead of it the exception occurs:

 Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException:
 `string' does not contain a definition for `WriteLine'
 at (wrapper dynamic-method) object.CallSite.Target
 (System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,object)
 IL 0x0004e, 0x000a6
 at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1
 (System.Runtime.CompilerServices.CallSite,object) 0x00365
 at test2.MainClass.Main (string[]) [0x0005d] in
 /home/sergey/Projects/test2/test2/Main.cs:11

 What is this: bug in the mono, or I have wrongly compiled mono?

 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/bug-or-wrong-mono-compilation-tp2227282p2227282.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] mono debugger

[Alan McGovern]

You're installing a trunk build of mono with a 2.6.3 release of the
debugger. This is a mismatch. As Michael said, SDB is built into the
runtime these days so could more than likely just use that.

Alan.

On Wed, May 12, 2010 at 7:03 PM, sberryman sh...@golfsigma.com wrote:

 I don't have a parallel environment though. The trunk build is the only copy
 of mono running on the box.
 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/mono-debugger-tp2196491p2196512.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] mono debugger

[Alan McGovern]

Follow this guide:
http://www.mono-project.com/Parallel_Mono_Environments  and enter your
parallel environment before compiling the debugger.

Also don't mix SVN versions of mono with released versions of the
debugger. You need to keep everything in sync. Either use 2.6.3 of
both mono and the debugger or svn of both mono and the debugger.

Alan.

On Wed, May 12, 2010 at 6:53 PM, sberryman sh...@golfsigma.com wrote:

 I've got the trunk build of mono running:

 Mono JIT compiler version 2.7 (/trunk/mono r157252 Wed May 12 05:23:59 UTC
 2010)
 Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
        TLS:           normal
        GC:            Included Boehm (with typed GC and Parallel Mark)
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          debugger softdebug
        LLVM supported

 I'm trying to get the debugger built and I've tried using
 http://ftp.novell.com/pub/mono/sources/mono-debugger/mono-debugger-2.6.3.tar.bz2
 and from the svn trunk
 (http://anonsvn.mono-project.com/viewvc/trunk/debugger/)

 When I try and use ./configure or autogen.sh I get the following error:

 checking Whether your Mono is working... no
 configure: error: *** Your Mono is too old for this version of the debugger.


 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/mono-debugger-tp2196491p2196491.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] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode

[Alan McGovern]

Why would a c-cast be so much slower than an 'as' cast? Surely they
should be equivalent or the c-cast should be faster.

Alan.

On Mon, May 10, 2010 at 7:24 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
 Well, it wasn't really internal, but that does not affect my statement.

 Atsushi Eno

 On 2010/05/11 2:55, Atsushi Eno wrote:
 Hi,

 Thanks Tom, it looks like a good catch. The interface is internal, and
 cast exceptions should not happen there anyways. Once the build got
 fixed, I'll verify the patch and apply it unless it regresses.

 Atsushi Eno


 On 2010/05/11 2:09, tom hindle wrote:

 Hi,

 While performance profiling our code, with mono's nice profiling
 tools :), I noticed System.Xml.XmlNode::SelectSingleNode was taking 23ms
 a call while the sum of the methods it was calling took   5ms.
 SelectSingleNode is a very simple method however it contains a (dynamic)
 down cast. I replaced the (Cstyle/prefix) cast with a 'as' cast and this
 seem to reduce the method time by about 7ms.


 // With 'Cstyle' cast
    39672.303    1717   23.106
 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager)
     Callers (with count) that contribute at least for 1%:
           1717  100 % System.Xml.XmlNode::SelectSingleNode(string)

 // With 'as' cast
    29238.117    1880   15.552
 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager)
     Callers (with count) that contribute at least for 1%:
           1880  100 % System.Xml.XmlNode::SelectSingleNode(string)


 I read that this is because 'as' cast generates IL instr 'isinst' while
 'cstyle' cast generates 'castclass'.

 The msdn documentation about XmlNode.SelectSingleNode doesn't state that
 an InvalidCastException, can/could be thrown.

 Is this a sensible thing to do? If so could someone review/commit my
 patch as I believe it will make a fairly major difference for
 applications that make much use of SelectSingleNode.


 Thanks
 Tom



 ___
 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

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] GroupBy Bug (Bug 601101)

[Alan McGovern]

Hey

More than 50% of your patch is whitespace noise which makes it hard to  
see what exactly it is you're fixing. Could you submit a patch without  
all the extra whitespace changes?


Secondly, I'd personally view any code which relies on the element  
ordering in a dictionary as being a bug and should be fixed.


As for the actual patch, I have no comments ;)

Alan

On 29 Apr 2010, at 22:18, Richard Kiene richard.ki...@logos.com wrote:

I have filed Bug 601101 https://bugzilla.novell.com/show_bug.cgi?id=601101 
 for this issue. In addition; I have attached a patch which resolves  
the issue. That said, I'm not really sure this patch is the most  
desirable way to fix the bug. If you would like to use the patch I  
release it under the MIT/X11 License.


Also worth noting is that a Dictionary is used to create the groups,  
but Dictionary as defined by MSDN does not preserve element  
ordering. It appears that the mono implementation of Dictionary does  
and that is why it is used, is this correct?


Thanks,

Richard Kiene
GroupBy.patch.txt
ATT1..htm
___
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 demo examples do not work!

[Alan McGovern]

Hey,

As per error message, you're missing libgdiplus. If you install that  
everything should work fine.


Alan

On 19 Apr 2010, at 06:12, Lyndon Lu lyndon...@gmail.com wrote:


Hi All,

I have installed mono 2.6.3 from source files in CentOS 5. I can  
see that test web page  Welcome to Mono XSP by running http://hostname/demo 
. While clicking Authtest-index.aspx, I got the error The web page  
cannot be found. If clicking Authtest-login.aspx, I got the error  
message:



Server Error in '/demo' Application

gdiplus.dll

Description: HTTP 500. Error processing request.

Stack Trace:

System.DllNotFoundException: gdiplus.dll
  at (wrapper managed-to-native)  
System.Drawing.GDIPlus:GdiplusStartup  
(ulong 
,System.Drawing.GdiplusStartupInput 
,System.Drawing.GdiplusStartupOutput)
  at System.Drawing.GDIPlus..cctor () [0x0] in filename  
unknown:0
Version information: Mono Runtime Version: 2.6.3 (tarball Thu Mar 25  
14:31:21 EST 2010); ASP.NET Version: 2.0.50727.1433



  The example Webcontrol-calendar also does not work. Other  
examples seem working. Does anyone know how to get them working?

   Thanks in advance.

Cheers,
Lyndon.
___
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

[Alan McGovern]

Hey,

It really does look like a valid issue but as it stands there's no
testcase to reproduce the issue. I do this *all* the time in the
testcases for MonoTorrent and my callbacks are always invoked. I
explicitly test for this in some of my testcases. There are times when
EndReceive is not supposed to throw an exception even though the
socket is not connected. Maybe you're hitting this case. It's just
impossible for me to see this bug happening so it's impossible for us
to fix it.

I'm not asking you to defend your bug report, i'm just asking you to
make it easy for us to fix it. You have a testcase which can reproduce
the bug 100% of the time. If that testcase could be supplied as part
of the bug report, it would be so much easier to resolve the issue.
All you need to do is put the testcase in a console app so that we can
just compile and run it to see the issue.

Thanks,
Alan.

On Mon, Apr 12, 2010 at 9:22 AM, Stefan [At] swieser1...@gmail.com wrote:

 Is there a testcase for this? This works fine for me, I'm inclined to
 believe there's a bug in the testcase.

 My code relying on the callback on disconnect works fine with Microsoft's
 .NET and it doesn't work with Mono because the callback never occurs. Thus,
 the behaviour from both frameworks deviate. I think my original message
 never posted to the mailing list, so essentially, this is the code I'm
 using:

 Socket socket = server.AcceptSocket();
 socket.NoDelay = true;
 socket.Blocking = false;

 [...]

 socket.BeginReceive(receive_buffer, 0, buffer_size, 0, new
 AsyncCallback(ReceiveDone), socket);

 [...]

 public void ReceiveDone(IAsyncResult result) {
    Socket socket = (Socket)result.AsyncState;
    int bytes_read = socket.EndReceive(result);

 [...]

 }

 The workaround to run through all Sockets and check for the Connected
 property being set to false works with Mono and isn't needed for Microsoft's
 .NET (as the event properly fires). Sockets are set into NoDelay,
 NonBlocking mode and then use asynchronous calls with BeginReceive and
 EndReceive. Maybe it is that particular constellation, or maybe the g++
 compiler, or maybe the host system.

 bash-3.2# mono --version
 Mono JIT compiler version 2.6.1 (tarball Thu Apr  8 13:02:55 UTC 2010)
 Copyright (C) 2002-2008 Novell, Inc and Contributors. www.mono-project.com
        TLS:           __thread
        GC:            Included Boehm (with typed GC and Parallel Mark)
        SIGSEGV:       altstack
        Notifications: epoll

 I know, this is not the most recent version ATM, but the OP replied that
 this behaviour occurs with 2.6.3 as well and I do trust their judgement.

 I've never gotten into the notion on having to defend my bug reports. I do
 my own test cases and testing, but you are welcome to put it down as a bug
 in my code. As I only need Mono for a quick internal use case in two weeks'
 time, I'll get away using a workaround. Good luck getting this fixed (should
 you decide to treat it as a valid issue), and take care ;)
 --
 View this message in context: 
 http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1836801.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

[Alan McGovern]

Is there a testcase for this? This works fine for me, I'm inclined to
believe there's a bug in the testcase.

Alan.

On Fri, Apr 9, 2010 at 4:21 PM, Stefan [At] swieser1...@gmail.com wrote:

 socket.BeginReceive(receive_buffer, 0, FlockNode.buffer_size, 0,
 new AsyncCallback(ReceiveDone), socket);

 If the Socket gets disconnected by the remote host,
 ReceiveDone is called, and EndReceive will throw a SocketException;
 thus you know that your socket is now disconnected without having
 to poll it. With Mono, no exception is thrown.

 Just to be a bit more clear about this, not only no exception is thrown,
 ReceiveDone isn't called either.
 --
 View this message in context: 
 http://n4.nabble.com/Socket-BeginReceive-never-throw-Exception-tp1679973p1819481.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] Build Microsoft Visual Studio Solution under Mono

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

[Alan McGovern]

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

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

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

[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
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] Summer of Code / C++ Interop

[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
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] Your help needed for our upcoming release.

[Alan McGovern]

This bug was fixed for 2.4.3 but has regressed again.

https://bugzilla.novell.com/show_bug.cgi?id=583451

Would it be possible to get this fixed for 2.4.4+ ? It does work in the 2.6
branch as of r151801, so no need to prioritise this one now ;)

Alan.

On Tue, Feb 23, 2010 at 11:04 PM, Miguel de Icaza mig...@novell.com wrote:

 Hello guys,

I changed the subject of this email, since Andrew's call to action
 is important and it applies to everyone:

  Just a reminder: If you've been assigned a bug or you know of a bug
  that's been fixed and needs to be backported please do so before the end
  of this week.  There's a good chance we'll try to release 2.6.3 from the
  2.6 branch early next week.  The QA team is still testing this branch
  but testing doesn't fix bugs, it can only find them.  Please do your
  part.
 
  On Tue, 2010-02-02 at 10:57 -0700, Andrew Jorgensen wrote:
   Hello Happy Coders,
  
  
   We are planning to make a new release from the 2.6 branch in the near
   future (probably before the end of the month?).  If there are bugs that
   you know ought to be backported (customer issues, regressions, and
   embarrassments especially) please do so in the next week or so.
  
   As you backport please keep in mind that we are trying to stabilize the
   2.6 branch.  Be conscientious and thorough and use your own best
   judgment in your area of expertise and consult your colleagues where
 you
   have doubts.  Also don't neglect other platforms like Mac, Windows, and
   Linux s390x.  2.6.x will eventually be used as a Novell-supported
   release for the Mono Extension for SLE and other products.
  
   We will be doing some testing of the 2.6 branch during this time.  If
 QA
   approaches you regarding a bug please remember that we will also need
   time to verify the fix after you check it in.  In other words: please
   give us any priority you can.  And don't forget to close bugs as you
 fix
   them and file them as you find them.
  
   Hmm, I should get someone to fix the booc crasher on x86_64...  Oh and
   thanks so much to those who pitched in to get our Xen x86_64 crasher
   fixed!
  
  
   Best Regards,
  
   Andrew Jorgensen
   Release / Packaging Guy
   Novell, Inc.
 
 
  ___
  Ximian-mono-list mailing list
  ximian-mono-l...@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/ximian-mono-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] Custom Uri Parsing

[Alan McGovern]

Hey,

On Fri, Feb 12, 2010 at 6:52 PM, Matt Dargavel m...@shout-telecoms.comwrote:

  Thanks for the info Alan.



 At the moment I’ve put together a very quick and dirty version that uses
 IsPredefinedScheme to decide whether to use the existing parsing code or use
 the registered Parser class when the Uri is first created (and parsed).

That might be the best way to get started alright.

 I was wondering whether something along the lines of moving the existing
 parsing routine in to DefaultUriParser and use this for the predefined
 schemes might be possible.  You might then be able to replace this with the
 proper Parser classes for the built in schemes one by one.  This would allow
 people to write parsers for unsupported schemes, and would hopefully pass
 the existing tests.

It's quite possible that this will be the easiest (and best) way to start
off. I'm interested in any progress you make on this as  I'll be able to fix
some long-standing issues with the System.IO.Packaging API in the
WindowsBase assembly when this is implemented. It needs a proper UriParser
subclass which isn't possible right now.

Thanks,
Alan.



 Anyway, I’ll look in to it a bit more and see if I can come up with a more
 definite suggestion.



 Cheers,



 Matt.





 *From:* Alan McGovern [mailto:alan.mcgov...@gmail.com]
 *Sent:* 11 February 2010 11:45 PM
 *To:* Miguel de Icaza
 *Cc:* Matt Dargavel; mono-devel-list@lists.ximian.com
 *Subject:* Re: [Mono-dev] Custom Uri Parsing



 Hey,

 The main reason why I didn't actually do any work on this at the time is
 that it would probably take 1 man month to do the rewrite, pass the existing
 tests and write more tests for the new behaviours and I didn't have a month
 free to do it ;) Proper support for the new parser API is required to
 properly support System.IO.Packaging, so I'd be willing to offer any advice
 if you want to take on the task.

 The biggest problem (as I saw it at the time) is that this is an all or
 nothing kind of patch. It might be impossible to do this one uri scheme at a
 time without making things ridiculously complicated internally. While the
 existing code will be useful as a guide, you will end up chopping it up into
 tiny pieces and moving it around into the different parser subclasses.

 Alan.

 p.s. The above should be mostly accurate, but the last time I looked at
 this was when I sent the original email ;)

 On Thu, Feb 11, 2010 at 5:09 AM, Miguel de Icaza mig...@novell.com
 wrote:

 Hello,



 Some searching also threw up this post to the list back in October 2008:
 http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg18617.html .
 I’ve looked in to the Mono implementation in svn, and it still appears that
 most of the Uri class decodes specific Uri content itself rather than
 delegating to Uri parsers.



 I do not believe we ever moved to that scheme of Uri parsing.



   I was wondering if anyone knew if the post above was ever followed up,
 or whether the suggestion wasn’t implemented for some reason?  I guess this
 should probably be filed as a bug, as the functionality was added in .NET 2?
  If you’d welcome a patch I could probably submit something based on Alan’s
 suggestion.



 I would love to see a patch based on Alan's patch.



 It should be simpler these days since Mono trunk has dropped support for
 1.0 compatibility


 ___
 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] Questions about csharp-sqlite - port of the SQLite library from C to C#

[Alan McGovern]

Hey,

Questions 1-3 would be best directed at the developer of csharp-sqlite. He
is not affiliated with mono in any way (that I know of).

As for the final question, I'm not aware of anyone writing an
ADO.NETwrapper for csharp-sqlite. If someone were interested in
creating one, i'm
sure it'd be appreciated by the community though.

Alan.

On Sat, Feb 13, 2010 at 9:22 PM, Daniel Morgan monodanm...@yahoo.comwrote:

 I have asked some questions at the FAQ for csharp-sqlite.

 http://code.google.com/p/csharp-sqlite/wiki/FrequentlyAskedQuestions

 csharp-sqlite is a C# port of the SQLite library.  This is NOT a wrapper to
 a native library.  It is a 100% port of the C library to C#.

 http://code.google.com/p/csharp-sqlite/

 1. Can you provide the source zipped up in a .zip file or tarball as
 .tar.gz please?

 2. Is there a online forum or mailing list for this project? I have a
 feeling my questions here are not in the appropriate place.  Is there a
 Google Group for these questions?

 3. Can you provide a Download link and Download page listing packages that
 are zipped up or tarballs of sources and/or binaries please?

 I really want to try csharp-sqlite out, but I do not want to install HG
 (Mercurial).

 4. Is anyone working on an ADO.NET wrapper of csharp-sqlite where you have
 only one assembly that is a class library? Preferably based on .NET
 Framework 2.0.

 I have did an internet search, but I have not found anyone. The closest
 thing is what Tim did for Silverlight, but it does not use System.Data. All
 the incarnations of Mono's Sqlite libraries do not work for me because they
 still use native code. And I do not think System.Data.SQLite from
 http://sqlite.phxsoftware.com/ has support for csharp-sqlite. Does anyone
 know if phxsoftware will add support for csharp-sqlite?





 ___
 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] Custom Uri Parsing

[Alan McGovern]

Hey,

The main reason why I didn't actually do any work on this at the time is
that it would probably take 1 man month to do the rewrite, pass the existing
tests and write more tests for the new behaviours and I didn't have a month
free to do it ;) Proper support for the new parser API is required to
properly support System.IO.Packaging, so I'd be willing to offer any advice
if you want to take on the task.

The biggest problem (as I saw it at the time) is that this is an all or
nothing kind of patch. It might be impossible to do this one uri scheme at a
time without making things ridiculously complicated internally. While the
existing code will be useful as a guide, you will end up chopping it up into
tiny pieces and moving it around into the different parser subclasses.

Alan.

p.s. The above should be mostly accurate, but the last time I looked at this
was when I sent the original email ;)

On Thu, Feb 11, 2010 at 5:09 AM, Miguel de Icaza mig...@novell.com wrote:

 Hello,


 Some searching also threw up this post to the list back in October 2008:
 http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg18617.html
  .  I’ve looked in to the Mono implementation in svn, and it still appears
 that most of the Uri class decodes specific Uri content itself rather than
 delegating to Uri parsers.


 I do not believe we ever moved to that scheme of Uri parsing.

 I was wondering if anyone knew if the post above was ever followed up, or
 whether the suggestion wasn’t implemented for some reason?  I guess this
 should probably be filed as a bug, as the functionality was added in .NET 2?
  If you’d welcome a patch I could probably submit something based on Alan’s
 suggestion.


 I would love to see a patch based on Alan's patch.

 It should be simpler these days since Mono trunk has dropped support for
 1.0 compatibility

 ___
 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] BufferedStream.ReadByte and WriteByte are extremely inefficient

[Alan McGovern]

Hey,

This patch does three things:

1) Optimises away some allocations - good
2) Added extra checks which throw exceptions - without providing testcases -
bad
3) A fair few whitespace changes - bad

Would you be able to submit two patches instead? The first should do the
optimisation, the second should add the test+exception for CanRead and
CanWrite as well as adding some nunit test cases which show that this is
required.

Also:

+   if (1 = m_buffer.Length) {
+   return m_stream.ReadByte ();

That should really be: if m_buffer.Length == 0 as the case where the Length
is = 0 is already handled. It makes things easier to understand.

Thanks,
Alan.

On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot tom.phil...@logos.com wrote:

 Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
 support turned my This is contributed under the MIT/X11 license into an
 attachment.

 For the record, the code in this patch is contributed under the MIT/X11
 license


 ___
 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] BufferedStream.ReadByte and WriteByte are extremely inefficient

[Alan McGovern]

Actually, ignore the part about the 1 = m_buffer.Length. On second reading
that's fine ;)

Alan.

On Mon, Jan 11, 2010 at 11:24 PM, Alan McGovern alan.mcgov...@gmail.comwrote:

 Hey,

 This patch does three things:

 1) Optimises away some allocations - good
 2) Added extra checks which throw exceptions - without providing testcases
 - bad
 3) A fair few whitespace changes - bad

 Would you be able to submit two patches instead? The first should do the
 optimisation, the second should add the test+exception for CanRead and
 CanWrite as well as adding some nunit test cases which show that this is
 required.

 Also:

 + if (1 = m_buffer.Length) {
 + return m_stream.ReadByte ();

 That should really be: if m_buffer.Length == 0 as the case where the Length
 is = 0 is already handled. It makes things easier to understand.

 Thanks,
 Alan.

 On Mon, Jan 11, 2010 at 10:53 PM, Tom Philpot tom.phil...@logos.comwrote:

 Sorry, for double posting this patch. Snow Leopard's Mail.app w/ Exchange
 support turned my This is contributed under the MIT/X11 license into an
 attachment.

 For the record, the code in this patch is contributed under the MIT/X11
 license


 ___
 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] LLVM Expectations

[Alan McGovern]

Hey,

1) Is the LLVM back-end intended to be a long term solution to code
 optimization for performance sensitive code in mono?

 2) How confident are you that the issues described can be resolved without
 kludge?

 3) Would success with the LLVM back-end necessarily curtail efforts to
 improve code optimization in the pure mono JIT engine?


Apart from any issues mentioned in that page, LLVM is (currently) just too
slow to be used as a JIT. This is why it's limited to AOT only at the
moment. To the best of my knowledge, monos standard jit is still the primary
target for optimisations and will be for a long time.

Alan.

--
 View this message in context:
 http://old.nabble.com/LLVM-Expectations-tp26930912p26930912.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] Announcing the release of Mono 2.4.3

[Alan McGovern]

There were two commits to SVN with regards to this bug so it looks like it
was accidently not closed. CC'ing the guy who committed those fixes as he'd
be the one to know whether it should be closed or not.

Alan.

On Wed, Dec 9, 2009 at 10:41 PM, Oskar Berggren oskar.bergg...@gmail.comwrote:

 The release notes lists the following issue as fixed:
 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView
 in VirtualMode uses too much memory and is slow

 But the bug report is still marked as NEW and there is no comment
 indicating that a fix has been checked in. What is the interpretation
 of this?

 /Oskar



 2009/12/9 Andrew Jorgensen ajorgen...@novell.com:
  Yesterday we released Mono 2.4.3.  This release contains a large number
  of bug fixes, including fixes for security bugs.
 
  The release notes are here:
 http://go-mono.com/archive/2.4.3
 
  and downloads are available here:
 http://go-mono.com/mono-downloads/
 
  We have not released LiveCD or Appliance images because we are working
  toward a 2.6 release in the near future.
 
  Thanks to all those who contributed to this release!
 
 
 
  ___
  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] StyleCop incompatibility

[Alan McGovern]

According to the rule - any using statement starting with System. should
be sorted first. It's nothing to do with the assembly that the namespace
comes from.

Alan.

On Tue, Dec 8, 2009 at 11:27 AM, Andrew Mikhailov and...@vitche.com wrote:

  The MS defines a code-style rule for the order in which the “usings” must
 be sorted:
 http://www.thewayithink.co.uk/stylecop/sa1208.htm

 The MonoDevelop application’s “Sort Usings” functionality simply sorts
 using in the alphabetical order but does not consider this rule.

 Related problems: How does Mono know which assemblies are system-ones? The
 question appears because the ported project’s source code may include
 unknown assemblies.

 ___
 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] Why not build official site on ASP.NET? Mono should enhance server performance and stability!

[Alan McGovern]

Hey,

MonoTorrent uses the standard .NET threadpool for all asynchronous sockets.
It's all standard Socket.BeginReceive/Socket.EndReceive calls. I've run it
with ~150 open connections in the past with no issues, though it's worth
noting that 150 open connections != 150 actively transferring connections.

If you're seeing issues with running out of threads and connections being
dropped as a result, just export MONO_THREADS_PER_CPU=100 to increase the
maximum number of allowed threads and see if that helps. Feel free to vary
the number up or down as appropriate.

Alan.

On Mon, Dec 7, 2009 at 5:12 PM, Rafael Teixeira mono...@gmail.com wrote:

 You could look at the source of MonoTorrent, and also of XSP that does
 use a separate ThreadPool AFAIR.

 Rafael Monoman Teixeira
 ---
 To be creative means to be in love with life. You can be creative
 only if you love life enough that you want to enhance its beauty, you
 want to bring a little more music to it, a little more poetry to it, a
 little more dance to it.
 Osho



 On Sun, Dec 6, 2009 at 11:21 PM, Laser Lu laser...@163.com wrote:
  Thanks for your reply ;-)
 
  I’m now using the latest version 2.4.2.3.
 
 
 
  This is the program I’m developing: http://linktalk.net. In this
 program,
  IHttpAsyncHandler, ThreadPool, and TCP Sockets are heavily used.
 
  I tried to host my program under Apache/XSP, but it had a really poor
  performance. So, I tried the HttpListener class, but still not good, and
 had
  lots of SocketExceptions thrown compared to the Windows counterpart.
 
  Lastly, I implemented a simple web server by myself, using Socket
 listening
  and parsing directly. It works better, however, async requests usually
  become unresponsive. It seems the ThreadPool is not as good as the .NET
  implementation, or maybe there needs some special configuration I don’t
  know.
 
 
 
  Under Windows/.NET the program can handle more than 2000 online IM users
  concurrently, but on Linux/Mono less than 100 conrrent users, and usually
  become unresponsive…
 
 
 
  
 
  From: Miguel de Icaza [mailto:mig...@novell.com]
  Sent: Monday, December 07, 2009 9:03 AM
  To: Laser Lu
  Cc: mono-devel-list@lists.ximian.com
  Subject: Re: [Mono-dev] Why not build official site on ASP.NET? Mono
 should
  enhance server performance and stability!
 
 
 
  Hello,
 
 
 
   The problem is that we would have to migrate the contents.   We
 tried
  once to move to MindTouch's Deki, but we lost too much in the translation
  and there were too many problems with the translation so we abandoned
 that
  plan.
 
 
 
   We are doing the new web sites using Mono though,
  http://monodevelop.com, http://wiki.monotouch.net, http://monotouch.net,
 and
  http://forums.monotouch.net are all running with Mono powered software.
 
 
 
   As for stability and performance, which version of Mono are you
  running?
 
  I was just wondering, why the mono official site was not built
  on ASP.NET/C#? That would be a good demonstration.
 
  Currently, I’m developing a Web IM program, and it works fine on
  Windows/.NET. However, the same code had a poor performance on
 Linux/Mono,
  and seems very unstable.
 
  So I doubt whether Mono is suitable for developing server programs which
  should be able to handle a huge amount of concurrent requests.
 
  I wish the Mono team would pay much more attentions to server
 applications,
  and enhance the server stability or just concentrate on server
 applications,
  not just catching up with Microsoft’s new cool features. Because
 Linux/Unix
  is used as server under 90% circumstances, performance and stability is
 the
  most import thing!
 
 
 
  ___
  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

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Why not build official site on ASP.NET? Mono should enhance server performance and stability!

[Alan McGovern]

Just to add, while MonoTorrent doesn't use it's on threadpool, it doesn't
hog ThreadPool threads by blocking inside the async callbacks. As soon as a
message is received and my callback is invoked, I queue the message to be
processed and allow thread to return to the ThreadPool. As such, even with a
large number of actively transferring connections ( 50) I only need a
handful of threadpool threads. If you starve the threadpool, your
performance will suffer accordingly ;)

Alan.

On Mon, Dec 7, 2009 at 8:17 PM, Alan McGovern alan.mcgov...@gmail.comwrote:

 Hey,

 MonoTorrent uses the standard .NET threadpool for all asynchronous sockets.
 It's all standard Socket.BeginReceive/Socket.EndReceive calls. I've run it
 with ~150 open connections in the past with no issues, though it's worth
 noting that 150 open connections != 150 actively transferring connections.

 If you're seeing issues with running out of threads and connections being
 dropped as a result, just export MONO_THREADS_PER_CPU=100 to increase the
 maximum number of allowed threads and see if that helps. Feel free to vary
 the number up or down as appropriate.

 Alan.


 On Mon, Dec 7, 2009 at 5:12 PM, Rafael Teixeira mono...@gmail.com wrote:

 You could look at the source of MonoTorrent, and also of XSP that does
 use a separate ThreadPool AFAIR.

 Rafael Monoman Teixeira
 ---
 To be creative means to be in love with life. You can be creative
 only if you love life enough that you want to enhance its beauty, you
 want to bring a little more music to it, a little more poetry to it, a
 little more dance to it.
 Osho



 On Sun, Dec 6, 2009 at 11:21 PM, Laser Lu laser...@163.com wrote:
  Thanks for your reply ;-)
 
  I’m now using the latest version 2.4.2.3.
 
 
 
  This is the program I’m developing: http://linktalk.net. In this
 program,
  IHttpAsyncHandler, ThreadPool, and TCP Sockets are heavily used.
 
  I tried to host my program under Apache/XSP, but it had a really poor
  performance. So, I tried the HttpListener class, but still not good, and
 had
  lots of SocketExceptions thrown compared to the Windows counterpart.
 
  Lastly, I implemented a simple web server by myself, using Socket
 listening
  and parsing directly. It works better, however, async requests usually
  become unresponsive. It seems the ThreadPool is not as good as the .NET
  implementation, or maybe there needs some special configuration I don’t
  know.
 
 
 
  Under Windows/.NET the program can handle more than 2000 online IM users
  concurrently, but on Linux/Mono less than 100 conrrent users, and
 usually
  become unresponsive…
 
 
 
  
 
  From: Miguel de Icaza [mailto:mig...@novell.com]
  Sent: Monday, December 07, 2009 9:03 AM
  To: Laser Lu
  Cc: mono-devel-list@lists.ximian.com
  Subject: Re: [Mono-dev] Why not build official site on ASP.NET? Mono
 should
  enhance server performance and stability!
 
 
 
  Hello,
 
 
 
   The problem is that we would have to migrate the contents.   We
 tried
  once to move to MindTouch's Deki, but we lost too much in the
 translation
  and there were too many problems with the translation so we abandoned
 that
  plan.
 
 
 
   We are doing the new web sites using Mono though,
  http://monodevelop.com, http://wiki.monotouch.net, http://monotouch.net,
 and
  http://forums.monotouch.net are all running with Mono powered software.
 
 
 
   As for stability and performance, which version of Mono are you
  running?
 
  I was just wondering, why the mono official site was not built
  on ASP.NET/C#? That would be a good demonstration.
 
  Currently, I’m developing a Web IM program, and it works fine on
  Windows/.NET. However, the same code had a poor performance on
 Linux/Mono,
  and seems very unstable.
 
  So I doubt whether Mono is suitable for developing server programs which
  should be able to handle a huge amount of concurrent requests.
 
  I wish the Mono team would pay much more attentions to server
 applications,
  and enhance the server stability or just concentrate on server
 applications,
  not just catching up with Microsoft’s new cool features. Because
 Linux/Unix
  is used as server under 90% circumstances, performance and stability is
 the
  most import thing!
 
 
 
  ___
  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



___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono

Re: [Mono-dev] Problem with PackagePart URI containing spaces

[Alan McGovern]

Hi,

Thanks for the bug report. Would you be able to file the issue on bugzilla
(with the testcase) and assign it to me (amcgov...@novell.com). That way I
can fix it and have the paper trail to verify the fix works.

If you come across any other issues, just assign them directly to me on
bugzilla.

Thanks,
Alan.

On Mon, Nov 23, 2009 at 11:53 AM, mhartmann mhartm...@vr-web.de wrote:


 Hi,

 I'm trying to read packages that were created with System.IO.Packaging on a
 Windows machine using .NET.

 It seems that that there is a problem with PackageParts that contain spaces
 in the specified package URI.

 Using the following code produces different results on .NET / Mono:

 string fileName = Test.zip;
 Uri uri = PackUriHelper.CreatePartUri(new Uri(/My Folder/Test.txt,
 UriKind.Relative));

 using (Package package = Package.Open(fileName, FileMode.Create))
 {
PackagePart part = package.CreatePart(uri,
 System.Net.Mime.MediaTypeNames.Text.Plain);
using (StreamWriter sw = new StreamWriter(part.GetStream()))
{
sw.WriteLine(Hello World);
}
 }

 On Linux using Mono the ZIP file contains a folder My Folder, but with
 Windows and .NET the name of the folder is escaped (My%20Folder).

 Best regards
 Martin
 --
 View this message in context:
 http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26476712.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] Problem with PackagePart URI containing spaces

[Alan McGovern]

You want to file it under Mono: Class Libaries product. Unfortunately
there's no component for the WindowsBase dll, so for the moment just use
'System'. I'm going to get in touch with our bugzilla guy and try to get a
WindowsBase component put up there. If you are filing bugs, do look out for
it as it should be there within a day or so.

Thanks,
Alan.

p.s. You forgot to hit 'reply-all' with your last email. I've added the
mailing list back into the CC but just look out for that in future.

On Mon, Nov 23, 2009 at 2:51 PM, mhartm...@vr-web.de wrote:

 Hi,

 can you give me a hint which Product / Component shall I use when I'm
 entering a new bug?

 Thanks,
 Martin

 Alan McGovern-2 wrote:
 
  Hi,
 
  Thanks for the bug report. Would you be able to file the issue on
 bugzilla
  (with the testcase) and assign it to me (amcgov...@novell.com). That way
 I
  can fix it and have the paper trail to verify the fix works.
 
  If you come across any other issues, just assign them directly to me on
  bugzilla.
 
  Thanks,
  Alan.
 
  On Mon, Nov 23, 2009 at 11:53 AM, mhartmann mhartm...@vr-web.de wrote:
 
 
  Hi,
 
  I'm trying to read packages that were created with System.IO.Packaging
 on
  a
  Windows machine using .NET.
 
  It seems that that there is a problem with PackageParts that contain
  spaces
  in the specified package URI.
 
  Using the following code produces different results on .NET / Mono:
 
  string fileName = Test.zip;
  Uri uri = PackUriHelper.CreatePartUri(new Uri(/My Folder/Test.txt,
  UriKind.Relative));
 
  using (Package package = Package.Open(fileName, FileMode.Create))
  {
 PackagePart part = package.CreatePart(uri,
  System.Net.Mime.MediaTypeNames.Text.Plain);
 using (StreamWriter sw = new StreamWriter(part.GetStream()))
 {
 sw.WriteLine(Hello World);
 }
  }
 
  On Linux using Mono the ZIP file contains a folder My Folder, but with
  Windows and .NET the name of the folder is escaped (My%20Folder).
 
  Best regards
  Martin
  --
  View this message in context:
 
 http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26476712.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
 
 
 Quoted from:

 http://old.nabble.com/Problem-with-PackagePart-URI-containing-spaces-tp26476712p26478275.html


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Should we replace MemoryStream?

[Alan McGovern]

Hey,

On Mon, Nov 9, 2009 at 6:29 PM, Avery Pennarun apenw...@gmail.com wrote:

 On Mon, Nov 9, 2009 at 1:10 PM, Miguel de Icaza mig...@novell.com wrote:
 I just blogged about a memory fragmentation issue here:
 
 http://tirania.org/blog/archive/2009/Nov-09.html
 
 And I am wondering: since MemoryStream is one of these sources of
  problems, we could replace this implementation with MindTouch's
  ChunkedStream.

 Probably stupid question: why is a compacting garbage collector
 actually needed?  C programs have survived for a *long* time without
 any ability whatsoever to compact memory, simply by carefully
 optimizing their allocation algorithms to avoid fragmentation.  Is the
 mono allocator very non-optimal in this respect?


One of the causes is that in a garbage collected language you allocate when
you need something and discard it when you're done. If you do this with
large buffers which are pinned in memory and have just the wrong allocation
pattern, you can bloat your memory usage. There's nothing mono can do in
this case as essentially it's the user causing the bloat.

One thing you can do is keep a cache of buffers yourself and re-use them.
For example if your application allocates 10 chunked memory streams a second
and Dispose () them when you're done, you could add/remove the 'chunks' from
a cache. This way you'd only ever allocate 10xsizeof (chunked stream) bytes
of memory and you'd constantly re-use them.

Alan.



 Like I said, I feel like this is a stupid question.  But I'm curious
 about the answer, and neither your blog post nor the linked page on
 the sgen collector addresses it.

 Thanks,

 Avery
 ___
 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] faster than hashtable?

[Alan McGovern]

If the key is random, a hashtable is the fastest way. You may be able to eke
some extra speed out of the DictionaryK, V class by ripping all the code
to support generic keys and instead hardcode the key to always be a long.
That should save a bit of time, though whether it'd be noticable or not I
don't know.

Alan.

On Wed, Oct 28, 2009 at 8:25 AM, Tom Spink tsp...@gmail.com wrote:

 2009/10/27 psant...@codicesoftware.com psant...@codicesoftware.com:
  Hi,
 
  If you need to store key/value pairs, where the key will be ALWAYS a
  unique long (no collisions), is there anything better than a Hashtable?
 
  Thanks
 
 pablo

 Presumably, though, the key can span the entire range of a long?  If
 it's an acceptably small range, you could use an array.

 --
 Tom Spink
 ___
 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] faster than hashtable?

[Alan McGovern]

Really what you need to do is benchmark all of the different options using
your expected workload. It's near useless us telling you X is faster or Y is
better without knowing the workload involved.

Alan.

On Wed, Oct 28, 2009 at 2:40 PM, pablosantosl...@terra.es 
pablosantosl...@terra.es wrote:

 Excellent. Is there a wrapper for C#? Is it worth?

 Felipe Lessa wrote:
  On Tue, Oct 27, 2009 at 11:58:31PM +0100, psant...@codicesoftware.comwrote:
  If you need to store key/value pairs, where the key will be ALWAYS a
  unique long (no collisions), is there anything better than a Hashtable?
 
  There are always Judy arrays, see http://judy.sourceforge.net/.
 
  --
  Felipe.
  ___
  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] faster than hashtable?

[Alan McGovern]

Hey,

On Wed, Oct 28, 2009 at 4:30 PM, pablosantosl...@terra.es 
pablosantosl...@terra.es wrote:

 Sure Alan!

 So, basically, the options are:

 - Use a sorted ArrayList and a binary search

For this option the same story applies as for Dictionary K,V. If you write
a strongly typed sorted list where the key is hardcoded as long, you might
be able to gain a few % in performance. It depends on whether the extra %'s
(if any) are worth the increased maintainer burden. If this is a
super-critical lookup, then it might be worth it.

 - Reimplement hashtable focusing on long keys
 - Write a wrapper to Judy


Alan.

Alan McGovern wrote:
  Really what you need to do is benchmark all of the different options
  using your expected workload. It's near useless us telling you X is
  faster or Y is better without knowing the workload involved.
 
  Alan.
 
  On Wed, Oct 28, 2009 at 2:40 PM, pablosantosl...@terra.es
  mailto:pablosantosl...@terra.es pablosantosl...@terra.es
  mailto:pablosantosl...@terra.es wrote:
 
  Excellent. Is there a wrapper for C#? Is it worth?
 
  Felipe Lessa wrote:
   On Tue, Oct 27, 2009 at 11:58:31PM +0100,
  psant...@codicesoftware.com mailto:psant...@codicesoftware.com
 wrote:
   If you need to store key/value pairs, where the key will be ALWAYS
 a
   unique long (no collisions), is there anything better than a
  Hashtable?
  
   There are always Judy arrays, see http://judy.sourceforge.net/.
  
   --
   Felipe.
   ___
   Mono-devel-list mailing list
   Mono-devel-list@lists.ximian.com
  mailto: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
  mailto: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] Why system.net.webresponse not implemented?

[Alan McGovern]

What makes you think it's not implemented? If you're attempting to subclass
WebResponse and are seeing NotImplemented exceptions, it's because you must
override those particular methods (and not call the base method!) and you
have not done so. The behaviour is the same on MS.NET.

Alan.

On Fri, Oct 23, 2009 at 10:38 AM, APS dev.ma...@apsystems.it wrote:

 Hi,

 just a curiosity. Trying to interface with an Axis web service I
 found that System/System.Net/WebResponse is not implemented.
 Why so? I think it's a useful library, there's some particular issue
 on implementing it?


 ___
 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] Big performance gaps between .NET, Mono (Suse/Debian) ?

[Alan McGovern]

Calling 'ToString' is just a GC benchmark. Yes, the current mono GC is
slower than the .NET GC in this scenario. Your other tests also do a fair
bit of allocating, so it's quite possible the entire performance loss you're
seeing is just from the GC kicking in. If you want to test how fast you can
add elements to a Dictionary, pre-allocate all the objects first and then
time just the addition.

Alan.

On Tue, Oct 6, 2009 at 10:15 AM, Lionel Cuir lionel_em...@aulofee.comwrote:

  Hello,

 Can anybody help me to understand why, on simple performance tests, I see
 so different results between .NET and Mono on various Linux platforms? Are
 my tests incorrect? Did I have no luck and simply fall on some
 methods/functionality better implemented by MS? And why is there such a
 difference between Suse and Debian for the IPAddress dictionary?

 Any help appreciated (please, no trolling, no political debate - just ideas
 about how to improve things or ideas to point out methodology errors I would
 have made in my tests)

 Regards,
 Lionel



 A few hints on how I did my tests:
 - the OS are: a bare XP SP3, a bare OpenSuse (kernel 2.6.27), a Debian with
 a lightened kernel (2.6.30) - bare = the OS is up-to-date but no other
 software installed
 - all OS were running as vmware guest (in vm workstation 6.5) with two
 cpus (dual-core T7200) and 512Mo of RAM
 - Mono version was 2.4.2.3 on Suse, and 2.5 (compiled from SVN r140059) on
 Debian. .NET version is 3.5
 - On Suse and Debian, I both run the tests with the exe compiled with csc
 (.net) and with the exe compiled with gmcs - the results were the same.

 You'll find attached the sample code I used - I test basically adictionary of 
 int,
 a dictionary of IPAddress and the IPAddress.ToString method. The duration
 of the test (in millisec are:

 int32 Dictionary test
 4812 DotNet
 9493 Mono on light Debian
 9815 Mono on Suse


 IPAddress Dictionary test
 13500 DotNet
 29533 Mono on light Debian
 41732 Mono on Suse


 IPAddress.ToString test
 2453 DotNet
 16665 Mono on light Debian
 17747 Mono on Suse


 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] 2.6 preview 1

[Alan McGovern]

Hey,

On Thu, Oct 1, 2009 at 6:56 PM, LKeene lionel.ke...@gmail.com wrote:


 Has the Task Parallel Library been performance tested on OSX? I've been
 having a tough time getting any kind of performance out of my threads on
 the
 Mac+Mono platform. Maybe this is the solution?

 Unlikely. I mean this in a constructive way, but the problem is more likely
just a bad threading implementation. Altering how you split data up between
threads and/or how you manage the threads would likely be the best way of
improving performance. Performance of Mac + Mono should be very close to
Linux + Mono. If you're seeing a huge difference in the exact same code it
might be worth filing a bug.

Alan.

 -L



 Andrew Jorgensen-4 wrote:
 
  The first preview build of 2.6 has been published to
  http://mono.ximian.com/monobuild/preview/download-preview/
 
  The windows installer in this build is known to contain a number of
  problems, including but not limited to:
  * Has an older build (2.4.x) of gluezilla
  * Does not contain mono-tools (monodoc browser, gsharp, gendarme, etc.)
 or
  gnome-sharp
  * Is larger than it was previously despite missing mono-tools, etc.
 
  We are working through these problems but felt that it was more important
  to get the build (and the preview tarballs) out into your hands.
 
  SLE_10 and openSUSE_10.3 binary packages have been dropped (mono-tools
 now
  requires a more recent gtk than available in SLE_10 and 10.3 will be
  end-of-life around the time we publish 2.6-final).
 
  The DRAFT release notes are here:
  http://www.mono-project.com/Release_Notes_Mono_2.6
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 

 --
 View this message in context:
 http://www.nabble.com/2.6-preview-1-tp25692276p25703738.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] .NET / Mono runtime multi-cast differences.

[Alan McGovern]

Hi,

Unless I'm missing something, you haven't actually described what the
problem is. Nor have you mentioned what exactly happens on windows, what
happens on linux and what you actually expected to happen. Your example also
appears to be missing information which might help figure out what issue it
is you're seeing, what are listenChannel and listenEndpoint?

Alan.

On Mon, Aug 24, 2009 at 3:20 AM, James P Michels III 
james.p.mich...@gmail.com wrote:

 I have observed a difference in behavior between the Mono runtime and
 .NET runtime with respect to multi-cast support.

 Unless the Socket.Bind operation is modified to bind to a different end
 point based on the runtime, no packets will be received. The workaround
 that I am using is shown in the attached code section.

 I took a look at Mono's source code. Additionally, I wrote a short C
 program with the equivalent functionality. The C version for Linux
 exhibits the same behavior. It is my impression that the behavior is due
 to differences between the Windows socket implementation and the Linux
 socket implementation. It is also my impression that these differences
 are being realized by both the .NET and Mono runtime which ultimately
 consume them.

 I have 2 questions.

 1) Am I wrong? Is there a runtime agnostic way to do this? (Binding to
 IPAddress.Any does not work on Windows to my knowledge)

 2) If I am not wrong, what steps, if any, should be taken to resolve
 these differences?

 Thanks
 Jim

 -begin code sample

listenSocket = new Socket(AddressFamily.InterNetwork,
 SocketType.Dgram, ProtocolType.Udp);
listenSocket.SetSocketOption(SocketOptionLevel.Socket,
 SocketOptionName.ReuseAddress, true);

if (IsMonoRuntime())
{
listenSocket.Bind(listenChannel);
}
else
{
listenSocket.Bind(listenEndpoint);
}

listenSocket.SetSocketOption(SocketOptionLevel.IP,
 SocketOptionName.MulticastInterface, listenInterface.GetAddressBytes());
listenSocket.SetSocketOption(SocketOptionLevel.IP,
 SocketOptionName.AddMembership, new
 MulticastOption(listenChannel.Address, listenInterface));


 -end code sample
 ___
 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] ParallelFx initial code drop

[Alan McGovern]

Hey,

On 28 Jul 2009, at 18:36, Miguel de Icaza mig...@novell.com wrote:

 Hello Jérémie,

Why are the files in System.Core, could we not put the files in
 their final location (which seems to be mscorlib) from the start?

Fromyalkibg to jeremie earlier, i think it's partially because of  
legacy reasons. Some of the parallel fx files already exist in that  
location and it'd be a pain to move them all to the 'correct' location  
now.

Alan.


 Miguel seems to have the same idea as me apart that I commit the new
 types directly instead of providing a patch.

 The new types can be added directly to SVN, and we can review them
 asynchronously;   Since you own the feature, there is no need to  
 do a
 review since it is not going to touch code that already exists.

 The only review that we need is for cases where you touch an existing
 class, modify an existing class, or provide your own class, or modify
 the behavior of an existing class.

 So I say: start committing the code to the real location (mscorlib)  
 and
 adding it to the build as long as it does not modify existing code.

 For anything that modifies existing code, post a patch for discussion.


 ___
 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