Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux
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 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 > Cc: mono-devel-list > Subject: Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix > reference on Linux > > On Mar 30, 2016, at 8:33 AM, Alan 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
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
Ah, sorry, i meant this commit https://github.com/mono/mono/commit/578a2327b8a216a2b59e9fc430ae5d77af2616bd On 12 February 2016 at 14:58, Alexander Köplinger < alexander.koeplin...@xamarin.com> wrote: > Sorry, turns out I made an error when testing on master. I can actually > see the request timeout there too, so it's not fixed on master. > > I filed a bug with your repro code: > https://bugzilla.xamarin.com/show_bug.cgi?id=38715 > > - Alex > > > > 2016-02-12 15:13 GMT+01:00 Alexander Köplinger < > alexander.koeplin...@xamarin.com>: > >> Happens on mono-4.3.2-branch/9f44a62 as well... >> >> Alan: the PR you linked doesn't seem to be related, did you have another >> PR in mind? >> >> - Alex >> >> 2016-02-12 15:07 GMT+01:00 Alexander Köplinger < >> alexander.koeplin...@xamarin.com>: >> >>> I tried the testcase on master and couldn't reproduce there. I could, >>> however, reproduce it on the 4.3.2 build I had installed >>> (mono-4.3.2-branch/0df254d). I'm downloading a later 4.3.2 build right now >>> to see if it still happens there, if it does then we need to backport >>> something from master. >>> >>> - Alex >>> >>> 2016-02-12 15:04 GMT+01:00 Seif Attar : >>> >>>> Great, I'll try it out. Is the console app in that gist enough for a >>>> test case? >>>> >>>> @Mike @Jonathan we've faced bugs with previous versions of libc and >>>> networking before, also some kernel issues. Update to latest if you can. I >>>> can't reproduce with 3.12. I get timeouts but then it recovers when there >>>> are available threads unlike with 4.x >>>> >>>> On Fri, 12 Feb 2016 13:50 Alan wrote: >>>> >>>>> 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 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 >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>&
Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
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 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 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 (LW
Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
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] mono 4.0.0 xbuild won't build project
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 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 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 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 > 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";>; > > > > > > 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
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 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 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 > > 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";>; >>> >>> >>> >>> >>> >>> 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
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 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";>; > > > > > > 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-2.11.4 on Solaris 11.1
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" 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?
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 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 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
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?)
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 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
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 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 > 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
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 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 > 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
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 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 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 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 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
Re: [Mono-dev] Dictionary implementation + concurrency
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 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 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] Marshal.GetFunctionPointerForDelegate and non-mono threads
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 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 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 >> > 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
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 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?
It's a mistake. We'll get it fixed! Alan On 27 January 2013 01:49, Bang Jun-young 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 > 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 ..." to update what will be committed) >> # (use "git checkout -- ..." 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?
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 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
Have you submitted the change as a pull request on github? Alan On 19 September 2012 13:43, Greg Young 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] Incompatibility
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 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 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 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
>>> 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] ConcurrentQueue
Hey, What version of Mono are you testing against? Alan On 10 August 2012 09:52, Greg Young 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 :0 > at SStable.PTable.GetFileStream () [0x0] in :0 > at SStable.PTable+c__Iterator2.MoveNext () [0x0] in > :0 > at SStable.PTable.TryGetValue (UInt32 stream, UInt32 version, > System.UInt64[]& position) [0x0] in :0 > at SStable.TableIndex.TryGetValueInternal (UInt32 stream, UInt32 > version, System.UInt64[]& position) [0x0] in :0 > at SStable.TableIndex.TryGetValue (UInt32 stream, UInt32 version, > System.UInt64[]& position) [0x0] in :0 > at IndexKiller.Program.ReadItems (SStable.TableIndex index, > System.Threading.AutoResetEvent autoResetEvent) [0x0] in unknown>:0 > at IndexKiller.Program+c__AnonStorey1.<>m__0 (System.Object x) > [0x0] in :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] ConcurrentStack with value type in 2.10
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 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
> 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 ConcurrentStack ();
>>
>> 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
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. 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. > 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`1> Yaaf.SyncLib.IManagedFolder>>) <0x006bb> >> at .$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`2> Microsoft.FSharp.Core.FSharpOption`1>) <0x00022> >> at Microsoft.FSharp.Primitives.Basics.List.iter >> (Microsoft.FSharp.Core.FSharpFunc`2> Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList`1) >> <0x00049> >> at Microsoft.FSharp.Collections.ListModule.Iterate >> (Microsoft.FSharp.Core.FSharpFunc`2> Microsoft.FSharp.Core.Unit>,Microsoft.FSharp.Collections.FSharpList`1) >> <0x0002f> >> at Microsof
Re: [Mono-dev] Should i submit my Winforms queued patches here or github?
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 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
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 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] C# project export to Linux fails - lots of errors
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 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] Restart my fork?
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 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
>>>>>>
>>>>>> 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
>>>>
Re: [Mono-dev] Patches for mono-winforms
It depends on what exactly it is you're testing. If your test is modifying static variables, that can easily cause other tests to fail. Do you know if the test you modified is now altering static state whereas previously it was not? Alan On 16 June 2012 17:32, Steven Boswell II wrote: > I just ran into a puzzler...I was trying to write a unit test for patch #10, > even though I've only seem the bug manifest when running my application > under MonoDevelop. It doesn't manifest outside of MonoDevelop, so it > shouldn't manifest during NUnit, but I was trying anyway. > > Enclosed is a patch for one of the ToolStripItem unit tests. It > succeeds...but it causes another unit test to fail! I thought these tests > ran independently of each other? How could changes to one unit test cause a > different one to fail? > > 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
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 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
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 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] Compiling mono? I give up [not proceeding] - if anything obvious i'm doing wrong let me know
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 wrote: > 2012/5/1 Rob Wilkens : >> [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] Mono Maintainers list
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 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] GSoC 2012 Proposal - WPF
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 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 : > > 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.Json is ready to be replaced
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 wrote: > 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.com<http://aspnetwebstack.codeplex.com> > [*2] https://github.com/mono/mono/**blame/master/mcs/class/System.** > Json/Test/System.Json/**JsonValueTest.cs<https://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 > http://lists.ximian.com/**mailman/listinfo/mono-devel-**list<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
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 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 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 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 >>>> >>>> >>> >> >> >> -- >> 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] System.IO.Packaging throws NullReferenceExeption
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 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
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 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
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 wrote: > 2012/2/1 Alan > >> 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
Is there a mono package available for your distro? If so, just install that.
Alan
On 1 February 2012 09:41, Markku Tavasti wrote:
> 2012/2/1 Markku Tavasti
>
>> 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
"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 wrote: > 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 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] P/Invoking libsmbclient from OSX
I worked through the problem with him yesterday and simply p/invoking a
single native function of the form: "int smb_init (int value)" is enough
to make it crash.
The most likely issue I can think of is that there is a symbol clash which
is causing libsmb to invoke a mono function instead of it's own which then
causes things to blow up. It's unlikely to be a calling convention related
problem because the stack never unwinds and it does successfully call a
bunch of functions and then blows up a dozen or two frames deep. Other than
that, there's very little that could possibly go wrong.
Alan
On 6 December 2011 23:11, Alfred Hall wrote:
> Hi,
>
> This may explain why smbc_init blows up, but does not explain why
> smbc_init2() blows up. In smbc_init2()
> the callback is in the unmanaged code. It still blows up.
>
> Cheers,
> Alfred
>
> On Tue, Dec 6, 2011 at 8:40 PM, Robert Jordan wrote:
> > Hi,
> >
> > On 06.12.2011 20:53, Alfred Hall wrote:
> >> Good afternoon!
> >>
> >> I have been trying to P/Invoke into libsmbclient on OSX 10.6 running
> >> 64 bit kernel. I compile the samba library myself (version 3.6.0) with
> >> -m32 and managed to get a simple stub working in C/C++:
> >>
> >> static void
> >> auth_fn(const char *server, const char *share,
> >> char *workgroup, int wgmaxlen, char *username, int unmaxlen,
> >> char *password, int pwmaxlen)
> >> {
> >> }
> >>
> >> smbc_init(auth_fn, 10);
> >> smbc_opendir("smb://myuser:mypass@192.168.x.x/c$");
> >>
> >> This works fine, then I created the P/Invokes:
> >>
> >> public static void SmbInit()
> >> {
> >> smbc_init(CallBackAuth, 0);
> >
> > You must pin the delegate passed to smbc_init, either using
> > a field or a GCHandle.
> >
> > Robert
> >
> > ___
> > Mono-devel-list mailing list
> > Mono-devel-list@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-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?]
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 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] compiler internal error
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 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] Problem handling more the 1024 file handle
Hi,
Mono itself has no trouble opening 1000's of files. Would you be able to
create an equivalent C program and see if that works as expected? My guess
would be that the equivalent C program will fail in the same way. If it
does not, then it's likely to be a mono bug.
Alan
On 4 November 2011 07:19, Torello Querci 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; ipath = string.Format ("file{0}.out", i);
>try {
>streams[i] = File.Open(path,
> FileMode.Create, FileAccess.Write,
> FileShare.None);
>} catch (Exception ex) {
>Console.WriteLine ("Unable to write
> file {0}", path);
>Console.WriteLine (ex.Message);
>Console.WriteLine (ex.StackTrace);
>return;
>}
>}
>}
>
>const int RLIMIT_NOFILE = 7;
>
>[DllImport ("libc", SetLastError = true)]
>unsafe extern static int setrlimit(int resource, rlimit*
> rlim);
>
>}
> }
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] COM, Threads and Mono
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 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
[Mono-dev] GUI available for heap profiling under mono 2.10+
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] HeapShot like GUI
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" > 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
Hey, On Tue, Apr 12, 2011 at 11:09 AM, Nicklas Overgaard 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 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
Re: [Mono-dev] Performance issue with DataTable.Load on "large" data sets
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 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: >> > > >> > > >> > > 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(); >> > > >> > > >> > > >> > > 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 &g
Re: [Mono-dev] StackOverflow on System.Delegate.Equals
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, wrote:
> On Mon, 2011-04-04 22:41:47 nekresh wrote:
>> On Mon, Apr 4, 2011 at 10:37 PM, wrote:
>> > On Mon, 2011-04-04 22:03:47 Gonzalo Paniagua Javier
>> > 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 EventHandler ItemClicked
> {
> add
> {
> EventHandler handler2;
> EventHandler itemClicked = this.ItemClicked;
> do
> {
> handler2 = itemClicked;
> EventHandler handler3 =
> (EventHandler) Delegate.Combine(handler2, value);
> itemClicked =
> Interlocked.CompareExchange>(ref
> this.ItemClicked, handler3, handler2);
> }
> while (itemClicked != handler2);
> }
> remove
> {
> EventHandler handler2;
> EventHandler itemClicked = this.ItemClicked;
> do
> {
> handler2 = itemClicked;
> EventHandler handler3 =
> (EventHandler) Delegate.Remove(handler2, value);
> itemClicked =
> Interlocked.CompareExchange>(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] StackOverflow on System.Delegate.Equals
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, wrote:
> W dniu 2011-03-30 22:07:45 użytkownik Miguel de Icaza
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] (no subject)
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 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
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 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 : >> 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 :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in >> :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in >> :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 :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in >> :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.Generate () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.Main (System.String[] args) [0x0] in >> :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 :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitModelImplementation () [0x0] in >> :0 >> >> at RabbitMQ.Client.Apigen.Apigen.EmitPrivate () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.GenerateOutput () [0x0] in > unknown>:0 >> >> at RabbitMQ.Client.Apigen.Apigen.Generate ()
[Mono-dev] Automatically generating a C wrapper library for a .NET assembly
Hi there, I have a need (or think I do) to call .NET code from a native C/C++ application. I think that I can do this by creating a C library that hosts the Mono runtime, loads up the desired assembly and wraps the routines I want to call. Ideally though I'd like to be able to generate this C library automatically using reflection coupled with attributes to mark the routines I want to export. My questions are - Is there an open source project out there that does this already? I've done some Googling but can't seem to find anything. - If there isn't any open source code out there is that because it's a rubbish approach? Can anyone think of any problems with the way I want to call managed code? Thanks in advance for your time. Regards Alan ___ 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 SetPropertyItem
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
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
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 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 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 >> > wrote: >> > >> >> Did you check http://www.mono-project.com/Moonlight??? >> >> >> >> Regards, >> >> Kishore. >> >> >> >> On Tue, Nov 9, 2010 at 10:14 AM, Alan wrote: >> >> >> >>> Hey >> >>> >> >>> On Tue, Nov 9, 2010 at 3:08 PM, Sasi Rekha Kristam >> >>> 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] Moonlight basics - Overview
Hey On Tue, Nov 9, 2010 at 3:08 PM, Sasi Rekha Kristam 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] High Traffic Site (for Harry Potter 7) is crashing!
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 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
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" 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 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!
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" 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
I always figured that [Tag] was just a simple thing to help you relate a commit to a very general area. i.e. [corlib] or [debugger] or [wcf]. I don't think we should, or could, define a whitelist of all usable tags. Hackers in each area would settle on a couple which would make sense. Alan. On Tue, Jul 27, 2010 at 11:47 PM, Marek Habersack wrote: > On Tue, 27 Jul 2010 18:41:46 -0400 > Geoff Norton wrote: > > > > > On 2010-07-27, at 6:21 PM, Alan wrote: > > > > > For commit messages, how about gnome style ones? > > > > > > http://live.gnome.org/Git/CommitMessages > > > > This is actually very nice. My only concern is maintaining the list of > [Tag]'s. > My sentiment as well. I think the [Tag] is pretty useless in our case. > > marek > > > > -g > > > > > > > > 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 > wrote: > > > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera > 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 > > > > ___ 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
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 wrote: > On Tue, Jul 27, 2010 at 11:42 PM, Rodrigo Kumpera > 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 ?
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 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 >> 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+c__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
Re: [Mono-dev] Bug 470120 - Socket.EndSend unexpectedly fails with WSAEWOULDBLOCK
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 wrote: > shameless ping... > > On Mon, Jun 7, 2010 at 11:03 AM, yoni shalom 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
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 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 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
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 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
"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 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 > 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.5&profile=2.0&assembly=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 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 >> > 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 comm
Re: [Mono-dev] bug or wrong mono compilation?
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 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)
>
> 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
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 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
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 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
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 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)
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 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 ___ 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!
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 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 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
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] 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
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] 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] Summer of Code / C++ Interop
Hey, Join us in the #monosoc channel on irc (http://www.mono-project.com/IRC). Also, I believe the deadline for proposals is tomorrow so you should probably submit a proposal asap which can be updated/modified later on as required. If you miss that deadline, there's not a chance of the project being selected. Alan. On Thu, Apr 8, 2010 at 10:25 AM, Alex Corrado 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] Mono process crashes after closing client socket
Hey, Firstly, could you try with a newer mono. If there is a bug in 2.0, there's not a chance of a new 2.0 release being made and it's also quite possible that the issue has been fixed since then. If the bug is still there in mono 2.6+ then file a bug report with all relevant info. You could also try running your app in GDB (http://www.mono-project.com/Debugging) to try and catch the place where it blows up. Alan. On Thu, Feb 19, 2009 at 3:46 PM, FirstName LastName 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] Error compiling WebConnection.cs
This is a known issue in our build system. run "make clean" and/or "make distclean" and then autogen and build again. That'll resolve the problem. Alan. On Mon, Mar 1, 2010 at 10:03 PM, Neale Ferguson 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] Socket.BeginReceive never throw Exception
Can you provide a testcase demonstrating the bug or more clearly explain what you mean by using code samples? Thanks, Alan On Wed, Mar 24, 2010 at 1:50 AM, Pigo Chu 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] Threading parameters? Fill a DataGridView via Invoke very slow
Can you provide a testcase demonstrating the issue. Thanks, Alan. On Thu, Mar 25, 2010 at 2:59 PM, Stifu 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] Build Microsoft Visual Studio Solution under Mono
A visual studio compiled binary and mono compiled binary are more or less identical. Just copy/paste the compiled code to a linux system and execute it there. Alan. On Thu, Apr 8, 2010 at 9:17 AM, Matt Dargavel 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] Your help needed for our upcoming release.
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 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
Hey, On Fri, Feb 12, 2010 at 6:52 PM, Matt Dargavel wrote: > 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 > 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#
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 wrote: > 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
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 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
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 wrote:
> 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 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
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 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
Alternatively you could just allocate and retain a 1 byte array inside the BufferedStream class and constantly re-use it. BinaryReader already uses this approach. As BufferedStream is sealed, the exact approach used doesn't particularly matter as the user can't tell the difference. Would any of the other Stream subclasses benefit from similar optimisations? Alan. On Sun, Jan 10, 2010 at 3:35 PM, Tom Philpot wrote: > It looks like the implementation of ReadByte and WriteByte in > BufferedStream follow the default behavior for Stream by allocating a 1-byte > array and then calling Read() or Write(). This is exactly what the MSDN docs > for ReadByte and WriteByte ask implementers NOT to do: > > >From > http://msdn.microsoft.com/en-us/library/system.io.stream.readbyte.aspx > Notes to Implementers: > > The default implementation on Stream creates a new single-byte array and > then calls Read. While this is formally correct, it is inefficient. Any > stream with an internal buffer should override this method and provide a > much more efficient version that reads the buffer directly, avoiding the > extra array allocation on every call. > > Granted, most people don't really ever read one byte at a time from a > Stream, but in our case, we need to. > > In my simple tests, reading 1.5 GB of data using ReadByte from > BufferedStream versus FileStream yielded the following the following results > (Late 2008 MacBook 13.3" 2.0 Ghz, 5400 rpm disk): > Test #1: > Using default BufferedStream ReadByte implementation: 763.814 seconds > Using FileStream ReadByte implementation: 43.53 seconds > > Test #2: > Using default BufferedStream ReadByte implementation: 765.427 seconds > Using FileStream ReadByte implementation: 42.678 seconds > > Obviously the alloc and GC cost of this one byte array is huge. I just > thought I'd throw this out there in case one of the Mono devs (or someone > else) wanted to work on a patch before I got a chance to submit one sometime > on Monday. > > 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
Re: [Mono-dev] LLVM Expectations
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
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 wrote: > 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 : > > 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
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 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!
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 wrote: > 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 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 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
Re: [Mono-dev] Why not build official site on ASP.NET? Mono should enhance server performance and stability!
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 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 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] Problem with PackagePart URI containing spaces
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, 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 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] Problem with PackagePart URI containing spaces
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 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] Should we replace MemoryStream?
Hey, On Mon, Nov 9, 2009 at 6:29 PM, Avery Pennarun wrote: > On Mon, Nov 9, 2009 at 1:10 PM, Miguel de Icaza 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?
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 . 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> > <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] faster than hashtable?
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
