Re: [Mono-list] The assembly mscorlib.dll was not found or could not be loaded
On 13/05/14 11:28, cocowalla wrote: I've discovered that mono is using mscorlib from `\lib\mono\4.5`, rather than `\lib\mono\4.0`. Now, `xbuild` is in `\lib\mono\4.5`, but my project targets .NET 4.0. Any ideas as to what is going on here? Seems there is a bug in the makefiles. If you ran configure with --with-profile4_5=no then xbuild should end up in lib\mono\4.0 , not lib\mono\4.5. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-aspnet-list] fastcgi-mono-server4 does not answer nor log anything and timeout
On 07/05/14 21:36, sven falempin wrote: i guess some of the patches should be included ins the source tree These seem to be great contributions! But please follow the official workflow for proposing patches: create a pull request in github for each separate issue, explaining in each git commit message not only what you're doing, but why you're doing it (the problem you got before you did the change). Thanks ___ Mono-aspnet-list mailing list Mono-aspnet-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-aspnet-list
Re: [Mono-dev] fastcgi-mono-server4 does not answer nor log anything and timeout
On 07/05/14 21:36, sven falempin wrote: i guess some of the patches should be included ins the source tree These seem to be great contributions! But please follow the official workflow for proposing patches: create a pull request in github for each separate issue, explaining in each git commit message not only what you're doing, but why you're doing it (the problem you got before you did the change). Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Repeat builds of core assemblies
On 23/04/14 04:14, Miguel de Icaza wrote: How about if we simplify this, by using the following strategy: - Move the interdependent types of those assemblies to corlib. - Mark them as internal. - Add InternalsVisibleTo for those assemblies towards mscorlib. - Use type forwarders to bring those types back from mscorlib to the correct places. This way the build would be much simpler, without dependency cycles. The dependency cycles are embedded in the public API contracts. So the libraries must be built with those cycles to match Microsoft's public API. I didn't propose to build binaries without dependency cycles, I just proposed to push the implementation towards a unique assembly (which BTW could be System.dll, no need to push it to mscorlib I guess). The build cycles merely encode the steps that must be taken to bring up those cycles on binaries. I'm guessing that what you mean is that by using the type forwarders to bring the types to the same assembly as they appear in MS, the metadata would be different and therefore the ABI/API would not be the same? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Repeat builds of core assemblies
Hey Miguel, On 22/04/14 21:53, Miguel de Icaza wrote: Hey guys, The problem is that System, System.XML and System.Configuration are each defined in terms of the other assemblies. So we gradually bring up each one of those assemblies up by first compiling a stub System, which we use to build System.XML and System.Configuration. Then we rebuild System, this time referencing System.XML and System.Configuration so we can take a dependency on them, and so on. How about if we simplify this, by using the following strategy: - Move the interdependent types of those assemblies to corlib. - Mark them as internal. - Add InternalsVisibleTo for those assemblies towards mscorlib. - Use type forwarders to bring those types back from mscorlib to the correct places. This way the build would be much simpler, without dependency cycles. HTH, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono builds for Linux
On 03/04/14 18:29, Timotheus Pokorra wrote: Hello Andrés, Here are the links: http://software.opensuse.org/download/package?project=home:tpokorra:monopackage=monodevelop-opt http://software.opensuse.org/download/package?project=home:tpokorra:monopackage=mono-opt Do your packages install somewhere below /opt ? If yes, then I will not recommend them because it's not a standard prefix. AFAIU /opt is an ideal prefix for parallel mono installations. The problem is that I don't want to get into conflict with the mono packages provided by the distribution. Software might depend on an The best way to do this is name one of your core packages in the same way as one core package of the distro (i.e.: mono-runtime), and make it a version higher than the one that the distro provides (and I guess make the other packages depend on the exact version of this core package). That way, as far as I understand, the packages of both your repo and the distro could not be installed in parallel. older version of Mono, or is certified for a specific version of Mono. I chose /opt because I consider my packages a parallel mono installation. But a proper parallel mono installation in /opt/xyz will always require a script to `source` into (like explained http://www.mono-project.com/Parallel_Mono_Environments). Perhaps I should clarify that my target audience are mainly developers, who want to develop with the latest version of MonoDevelop, or run their own software with the latest version of Mono. Alternatively, for just Ubuntu builds, there is the work by Eberhard: https://launchpad.net/~ermshiperete/+archive/monodevelop WRT Ubuntu/Debian builds, I would rather recommend the PPAs and official repositories of the official mono/monobased-apps packagers: directhex and meebey. Good to know! Are these the correct links? https://launchpad.net/~directhex/+archive/monoxide and http://debian.meebey.net/experimental/ Yes. I guess for official packages for a distribution, things need to be very clean and follow many rules, and it takes more time to create a proper package. The advantage of an opt package installed in a parallel environment is that it just needs to work? But I might be wrong with that opinion... Just to make it clear, I don't mind who provides uptodate packages, it is just important to me that they are made available to people by linking from the official website to it. Even if it has a big experimental warning on it... But if they are not maintained by official sources, I don't think it should be linked from the official page. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono builds for Linux
On 03/04/14 18:31, David Curylo wrote: Andrés, On Apr 3, 2014, at 11:16 AM, Andrés G. Aragoneses kno...@gmail.com mailto:kno...@gmail.com wrote: Do your packages install somewhere below /opt ? If yes, then I will not recommend them because it's not a standard prefix. AFAIU /opt is an ideal prefix for parallel mono installations. These effectively are parallel installations. They can be installed alongside the mono from the various distros repositories, which is exactly how I am using them. Maybe what we really need is an official listing of parallel mono distributions. Alternatively, for just Ubuntu builds, there is the work by Eberhard: https://launchpad.net/~ermshiperete/+archive/monodevelop This is indicative of the problem that there aren’t any official packages, parallel or otherwise. Why should people have to dig for mono packages? Because if their distro doesn't provide up-to-date versions of mono, there's always a reason for it. Take in account that there are many mono-based apps in the distributions which need to be tested against the new versions, and sometimes mono regressions hold packagers back (so they prefer not to package some new version until the regression has been fixed). Take in account that official distro packagers care more about the quality and stability of the software packaged by the distro than about providing the latest versions of anything. WRT Ubuntu/Debian builds, I would rather recommend the PPAs and official repositories of the official mono/monobased-apps packagers: directhex and meebey. These packages are consistently out of date, unfortunately. For Yes. And fortunately, you can help to avoid that to happen. For example, in the case of ubuntu/debian, you can go chat with us in the OFTC network, #debian-cli channels. Collaborating with the distro packagers will always be a way to avoid duplication of efforts. example, they are currently at 3.2.4, whereas those produced by Tim seem to follow the release very closely and match what is on the mono website downloads page (currently 3.4.0). But if they are kept up to date responsibly, then it seems like they should become the official releases and maybe Eberhard should be asking the same questions as Tim. Also, these are Debian / Ubuntu only. Fedora, CentOS, and OpenSUSE are left out. It would be very nice to be able to find the latest distributions anytime they are needed instead of having to hunt for them for the various distributions one wants to support for their application. Thanks, Dave ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono builds for Linux
On 04/04/14 21:16, David Curylo wrote: If Eberhard’s package is the official one for Ubuntu It's not, I already said it. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono builds for Linux
Hey Tim, On 03/04/14 11:03, Timotheus Pokorra wrote: Hello, I read this morning that there was a discussion on IRC about Linux and Windows builds last night. The page http://www.go-mono.com/mono-downloads/download.html offers downloads for Windows, Linux and Mac, but only the Mac version seems to be updated quickly. I cannot say anything about Windows builds. But the argument regarding Linux builds went into this direction on IRC: It is too much work to build Mono for every conceivable distribution, and manual steps of uploading are involved, etc. The suggestion was to either use the Mono that is part of the distribution, or build it yourself. I think that is not an option for everyone. Some distributions are slow in building Mono, which means you are stuck with an old version. And people should not be burdened to build their own Mono. I have made good experience with the OpenSUSE build service. The project has been renamed some time ago to Open Build Service, to stop making people think it's OpenSUSE specific, so I don't recommend you to use that name (especially if you're selling us the multi-distro thing ;) ) I have been building the latest stable Mono and MonoDevelop for the past months, for several of the mainstream Linux distributions. The main effort usually was to get the current tarball to build at all. I have had no problems with building for the various distributions, once the package files were in place. Here are the links that I have posted before on this list: http://www.pokorra.de/2013/12/building-the-latest-mono-and-monodevelop-on-obs/ http://www.pokorra.de/2013/12/easy-installation-of-current-mono-and-monodevelop-for-all-major-linux-distributions/ I wonder if someone else wants to do this officially for the Mono team, or if my builds could become somehow official. I am happy to help clarify the process that I use to build the packages. It is already a transparent process, since all parameters are public on the OpenBuild Service. I read in this comment that Xamarin encourages the community to provide support for Linux: http://mikemdblog.blogspot.de/2013/09/how-to-set-up-monodevelop-on-linux.html?showComment=1378643747759#c4019833196943293574 If you would want to put a link from the Mono and MonoDevelop downloads page to my or someone elses Download repository, that would certainly help the Linux community! Here are the links: http://software.opensuse.org/download/package?project=home:tpokorra:monopackage=monodevelop-opt http://software.opensuse.org/download/package?project=home:tpokorra:monopackage=mono-opt Do your packages install somewhere below /opt ? If yes, then I will not recommend them because it's not a standard prefix. AFAIU /opt is an ideal prefix for parallel mono installations. Alternatively, for just Ubuntu builds, there is the work by Eberhard: https://launchpad.net/~ermshiperete/+archive/monodevelop WRT Ubuntu/Debian builds, I would rather recommend the PPAs and official repositories of the official mono/monobased-apps packagers: directhex and meebey. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Mono build bug
On 01/04/14 17:22, Kuba Vaněk wrote: Hello everybody, I cloned mono 897e95954ec2b1bb7bc76572dff6071b3ae4c64b from git. When I try to build Mono, it prints this (yes, I also tried to delete original folder and then reclone): $ ./autogen.sh --prefix=/usr Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Running aclocal -I m4 -I . ... aclocal: error: configure.ac is required **Error**: aclocal failed. This may mean that you have not installed all of the packages you need, or you may need to set ACLOCAL_FLAGS to include -I $prefix/share/aclocal for the prefix where you installed the packages whose macros were not found I think it's because mono is using configure.in instead configure.ac (the former may be finally deprecated). Try to rename the file and see if it works. If it doesn't, you will need the help of some autohell^H^H^H^Htools expert. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono build bug
Great, can you submit a pull request to fix the bug upstream? Please specify the versions of your tools in the commit message, to better document about the failure (i.e. version of your distro, version of aclocal, version of autoconf, version of automake...). Cheers! On 1 April 2014 18:10, Kuba Vaněk vanek.jak...@seznam.cz wrote: Hello, thank you very much. That worked, but I also had to rename libgc/ configure.in to libgc/configure.ac Jakub Vanek -- Original message -- From: Andrés G. Aragoneses kno...@gmail.com For: mono-devel-list@lists.ximian.com Date: 1. 4. 2014 17:59:19 Subject: Re: [Mono-dev] Mono build bug On 01/04/14 17:22, Kuba Vaněk wrote: Hello everybody, I cloned mono 897e95954ec2b1bb7bc76572dff6071b3ae4c64b from git. When I try to build Mono, it prints this (yes, I also tried to delete original folder and then reclone): $ ./autogen.sh --prefix=/usr Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' Running aclocal -I m4 -I . ... aclocal: error: configure.ac is required **Error**: aclocal failed. This may mean that you have not installed all of the packages you need, or you may need to set ACLOCAL_FLAGS to include -I $prefix/share/aclocal for the prefix where you installed the packages whose macros were not found I think it's because mono is using configure.in instead configure.ac (the former may be finally deprecated). Try to rename the file and see if it works. If it doesn't, you will need the help of some autohell^H^H^H^Htools expert. ___ 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-list] ConfigurationManager.ConnectionStrings is NULL
I don't recommend you to patch Mono 2.8.x, I recommend you to upgrade to Mono 3.2.x before doing anything else. On 01/04/14 18:54, weng nanshan wrote: Thank Andrés G. Aragoneses for your replay! The problem I hitting looks similar to the bug you mentioned as https://bugzilla.xamarin.com/show_bug.cgi?id=11972 I modified some code in mono2.8 according to the suggestion in https://github.com/mono/mono/pull/643, there is still the the problem. (Maybe I did not merge the modification correctly, for I did not get the full-version of modified source files,because the network is so so slowly.) Fail to get ConfigurationManager.AppSettings and ConfigurationManager.ConnectionStrings from web.config! My web app is running on CentOS6.2 + nginx + fastcgi-mono-server + mono2.8. Which module of mono would cause the problem, MCS or runtime? What shall I do? Any suggestion is welcome! - Original Message - *From:* Andrés G. Aragoneses mailto:kno...@gmail.com *To:* Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com *Sent:* Sunday, March 30, 2014 7:30 PM *Subject:* Re: [Mono-list] ConfigurationManager.ConnectionStrings is NULL On 28/03/14 15:50, weng nanshan wrote: Hi,all I am runing a web application on mono. There is a strange problem. I define a database connection string in Web.config file, as the following: connectionStrings add name=MySqlConnectionStr connectionString=server=localhost;database=dbmy;password=123456;user=root;port=3306;/ /connectionStrings And I want to get the connection string in program, using ConfigurationManager.ConnectionStrings[MySqlConnectionStr]. It fail! And I find that ConfigurationManager.ConnectionStrings[MySqlConnectionStr] is NULL. So I can't get the connection string. The program is written in .net2.0, and run well on Windows and MS .Net framework. But on CentOS6.2 and Mono, there is the problem above. I test Mono2.6.7, Mono 2.8, Mono2.10.6, there is the same problem. I try many way to solve the problem, but fail! Anyone kind to help me! Any suggestion is welcome! Mono 2.x is very old, upgrade please. If you still hit the problem in Mono 3.2.x, then maybe you're hitting a similar (or same) bug as https://bugzilla.xamarin.com/show_bug.cgi?id=11972 ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] ConfigurationManager.ConnectionStrings is NULL
On 28/03/14 15:50, weng nanshan wrote: Hi,all I am runing a web application on mono. There is a strange problem. I define a database connection string in Web.config file, as the following: connectionStrings add name=MySqlConnectionStr connectionString=server=localhost;database=dbmy;password=123456;user=root;port=3306;/ /connectionStrings And I want to get the connection string in program, using ConfigurationManager.ConnectionStrings[MySqlConnectionStr]. It fail! And I find that ConfigurationManager.ConnectionStrings[MySqlConnectionStr] is NULL. So I can't get the connection string. The program is written in .net2.0, and run well on Windows and MS .Net framework. But on CentOS6.2 and Mono, there is the problem above. I test Mono2.6.7, Mono 2.8, Mono2.10.6, there is the same problem. I try many way to solve the problem, but fail! Anyone kind to help me! Any suggestion is welcome! Mono 2.x is very old, upgrade please. If you still hit the problem in Mono 3.2.x, then maybe you're hitting a similar (or same) bug as https://bugzilla.xamarin.com/show_bug.cgi?id=11972 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] (no subject)
On 20/03/14 18:08, Greg Young wrote: Before go searching for what happening and whether its something odd here can anyone build trunk right now? I can build 3.2.8 no problem Attaching the error message you get might help. (Also putting a subject in your email is not yet old-fashioned AFAIK) PS: I guess you mean 'master' (subversion is no more ;) ) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Debug.Assert - a cross-platform issue
On 09/03/14 06:28, MarLOne wrote: Hi all, I have found out the run time discrepancy of Debug.Assert() in CLR and in Mono. The answer literally is in front of our eyes. The difference is in this property: System.Diagnostics.DefaultTraceListener.AssertUiEnabled. In *CLR* the default value is *true* but in *Mono* the default value is set to *false*. If you disassembly the system assembly, you will see that in By disassembling Microsoft's code, you've rendered yourself unable to contribute to Mono (at least around the area of the API you're talking about). Next time, read this first: http://www.mono-project.com/Contributing#Important_Rules Mono, the DefaultTraceListener.Fail() already contains GUI code to report the failure if the above mentioned property is true. Since the default value is set to false, it does not report any failure condition. Hence there are two ways of fixing it: 1) In code just do this (surround it with conditional compilation control) : (Debug.Listeners[Default] as DefaultTraceListener).AssertUiEnabled = true; 2) In a config file like this: ?xml version=1.0 encoding=utf-8? configuration system.diagnostics assert assertuienabled=true / /system.diagnostics /configuration This setting is superfluous in CLR but is harmless hence the same config file can be used in both platform. If you are performing cross platform checking, make sure you include the configuration setting to avoid the disappointment. This highlights the importance to maintain default values consistence. Hope this will help and may be someone maintaining this part of the code to consider restoring that consistence. MarL -- View this message in context: http://mono.1490590.n4.nabble.com/Debug-Assert-a-cross-platform-issue-tp4662174p4662183.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Debug.Assert - a cross-platform issue
Before getting familiar with mono you should first get familiar with how opensource development works. Read about talk is cheap, easier said than done, etc. (that is, if you think Mono should behave in some way, go ahead and try to make it so). On 07/03/14 15:17, MarLOne wrote: Hi, Why is Debug.Assert(false) not terminating/aborting not a bug and has not been fixed since it was first raised in 2006? I am using MD4.2.2 in Mint-15 and it still fails to behave correctly out of the box and wasting people's effort. Sure, one can register tracelistener into the chain. But if the declaration in mono-projects' web page is serious about Run your applications on all platforms, then Mono has to address all these cross-platform runtime issues and not just being able to compile C# constructs (I have two reported - XmlSerializer and TimeZoneInfo.GetSystemTimeZones). You need to make sure the runtime behaviour is the same as in Windows and other Platform when mono support those constructs. Debug.Assert() is a widely use construct that dated back to .Net 1 to catch violation in debug mode. I have been programming in CLR since if was in beta and it is so disheartening that one cannot take code from Windows/CLR over to Mono with great confidence. It is like playing MineSweeper as you never know when you step on a mine! Anyone contemplating of using Mono as a cross platform tool needs to consider mono as a high risk exercise. Don't just trust it because it can compile your C# constructs as it only produces compiler-happy code. Please fix up the Debug.Assert() as it is definitely a bug. If those that have all these tricks to make it working, why can't they add them as the default behaviour so that if Debug.Assert(false) terminates in CLR, it should do that in Mono out of the box and even running inside MonoDevelop is an improvement. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Library path bug in Makefile?
On 06/03/14 03:09, Edward Ned Harvey (mono) wrote: But I have to say, learning to roll your own packages is difficult. It is not if you use fpm (https://github.com/jordansissel/fpm), instead of a distro-specific build toolchain, as I recommended in a previous message (i.e. simple script to create a mono package: https://github.com/knocte/7digital-mono/blob/master/build-mono-package.bash). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Library path bug in Makefile?
On 04/03/14 17:23, Edward Ned Harvey (mono) wrote: From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Andrés G. Aragoneses As far as I understand, LD_LIBRARY_PATH is a system setting that mono doesn't modify. Thanks for your response - from the link I originally posted (http://www.cc.dtu.dk/?page_id=304) please see this quote: There is the ldd command, that shows you which libraries are needed by a dynamically linked executable, e.g. $ ldd /usr/bin/file linux-vdso.so.1 = (0x7fff9646c000) libmagic.so.1 = /usr/lib64/libmagic.so.1 (0x0030f9a0) libz.so.1 = /lib64/libz.so.1 (0x0030f8e0) libc.so.6 = /lib64/libc.so.6 (0x0030f820) /lib64/ld-linux-x86-64.so.2 (0x0030f7a0) snip If you compile your application(s) yourself, you can solve the problem by specifying the correct location of the shared libraries and tell the linker to add those to the runpath of your executable, specifying the path in the '-rpath' linker option: cc -o myprog obj1.o ... objn.o -Wl,-rpath=/path/to/lib \ -L/path/to/lib -lmylib The linker also reads the LD_RUN_PATH environment variable, The main point here is to say, the library search path is hard-coded into the binary at the time of compile/linking. In fact, you're correct. LD_LIBRARY_PATH is an environment variable, and in fact, mono doesn't modify it. (Rightly so.) Normally, LD_LIBRARY_PATH is actually empty. Completely blank. And rightly so. Because normally it should not be needed, if the binaries are linked properly. Right, LD_LIBRARY_PATH may be simply a fallback. But the thing is, you don't need LD_LIBRARY_PATH when installing libs in standard prefixes like /usr or /usr/local, so as you mention that LD_LIBRARY_PATH is empty, maybe what happens is that PATH is checked before LD_LIBRARY_PATH? (In that case, LD_LIBRARY_PATH is the fallback of the fallback.) In the case of building mono from source, it seems clear, this should come from --libdir=DIR, which is derived from --exec-prefix=EPREFIX, which is derived from --prefix=PREFIX The goal I'm driving toward is to provide a modern version of mono on systems (for example centos) which don't have anything remotely usable available in their standard package repositories. (In the default centos/rhel repositories, there is *no* mono available, but if you add epel, then suddenly mono 2.4.3 becomes available, which is pathetic.) It's very easy to build from source, but without a package manager, you DON'T want to install into default locations, as that makes it very difficult and messy to upgrade to later versions of mono as they're released, with security and bugfixes. The methodology I've described in the original post about building to /usr/local/mono-VERSION and then providing a symlink /usr/local/mono -- mono-VERSION is very easily supportable and sustainable. But even if you symlink /usr/local/mono to /usr/local/mono-3.2.8, that is *not* /usr/local. I mean, its lib folder would be in /usr/local/mono/lib instead of /usr/local/lib, which means that if /usr/local is considered standard for your distro (included in PATH?), that would not apply in this case. If mono is simply the only software you install from sources, you can simply install it in /usr/local, and when you need to uninstall it, you simply wipe /usr/local. If you're worried about mixing different mono versions around the same prefix, then what you could do is dummy packages using fpm (an example of how to create a .deb package is here: https://github.com/knocte/7digital-mono, but you can create an rpm as easily as that, changing a flag). Then uninstalling becomes easy. You can build and install the new 3.2.9 when it's available, test it yourself, and then cutover the symlink when it's ready for general usage by the users of the machine. http://www.mono-project.com/Parallel_Mono_Environments Thank you for the link. In fact, I read it. Fundamentally, they're suggesting you override the LD_LIBRARY_PATH (and some other environment variables.) It also seems, they are in agreement with all the other info about LD_LIBRARY_PATH conventions out there on the internet, they are *not* suggesting that you do this in production. They are operating under the assumption that you are building multiple versions of mono for development and testing purposes. They assume you have some other mono in system default locations, and you don't want the system default mono to interfere with your experimental build (or vice-versa). Yes I know that guide is not meant to help you with your production environment, but by reading it you understand that using non-standard prefixes (like /opt/mono or /usr/local/mono-3.2.9) only really works if you use them along with an isolated environment (a script you 'source' into, etc
Re: [Mono-dev] Library path bug in Makefile?
As far as I understand, LD_LIBRARY_PATH is a system setting that mono doesn't modify. If you want Mono to work out of the box without the need to adjust LD_LIBRARY_PATH you need to install it in a standard prefix. Some distributions consider /usr and /usr/local to be standard (note: /usr/local/mono-3.2.8 != /usr/local), but I've also seen/heard issues about people installing in /usr/local, so the safest bet is /usr (although choosing /usr has the disadvantage that it can clash with your system mono packages if you're not careful). This is also a good read in case you need to use two different versions of mono in the same system at the same time: http://www.mono-project.com/Parallel_Mono_Environments On 03/03/14 03:58, Edward Ned Harvey (mono) wrote: I had a problem, and I figured it out, thanks to this page: http://www.cc.dtu.dk/?page_id=304 I have a system with mono built as follows: ./configure --prefix=/usr/local/mono-3.2.8 make echo echo Done echo followed by sudo make install echo echo Ok Ok Ok echo I would expect, based on the above webpage, that the ./configure make should have built mono using LD_RUN_PATH set to /usr/local/mono-3.2.8/lib, but apparently it doesn't - Should that be considered a bug in the Makefile? The workaround is to specify the LD_LIBRARY_PATH on each call to mono env LD_LIBRARY_PATH=/usr/local/mono-3.2.8/lib /usr/local/mono-3.2.8/bin/mono FunWithFooBar.exe ___ 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] ms .net source updated and license modified
On 25/02/14 18:11, theUser BL wrote: »Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat Microsoft auch die Lizenzbestimmungen klarer gefasst. Denn bisher mussten beispielsweise die Entwickler von Open Source-Klonen aufpassen, dass sie nur Erkenntnisse aus dem Reverse Engineering verwenden und nicht aus dem Studium des originalen Quellcodes. Denn in vielen Fällen würde dann die Gefahr drohen, dass man sich verschiedener Rechteverletzungen schuldig macht. Die Microsoft Reference Source License wurde daher nun so angepasst, dass beispielsweise die Entwickler des Mono-Teams problemlos die .Net-Sourcen anschauen und das Framework dann unter Linux klonen können. « GoogleTranslate output is: To make the work with the source code even easier, Microsoft has also the license terms clarified. Because so far had For example, the developers of open source clones careful that they only use insights from the reverse engineering and not from the study of the original source code. Because in many cases would then the danger threatening that one different in rights violations guilty. The Microsoft Reference Source License was therefore now adapted so that for example, the developer of the mono-teams easily see the. Net sources and the framework then in Linux can clone. If this translation is (kind of) correct, it still is very confusing because that license (MS-RSL [1]) is not opensource. [1] http://en.wikipedia.org/wiki/Shared_source#Microsoft_Reference_Source_License_.28Ms-RSL.29 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] which branch is recent SqlBulkCopy fix in?
On 20/02/14 06:14, doncl wrote: Hi, my apologies if this question is better sent to another list. It's my understanding Miguel recently merged in fixes to SqlBulkCopy. I could really use that for what I'm working on right now; SqlBulkCopy is not working for me in 3.2.6, Ubuntu 13.10. When I checkout Master and build, I get a different error; glad to give full details if desired. Give them. But rather in bugzilla.xamarin.com. It's my hope that I simply have the wrong git branch to get this fix. Any pointers would be greatly appreciated.' git master should be the branch that has the latest. If this post were better sent to the regular mono list, again, my apologies.also, glad to provide a very short program sample that demonstrates the issue, if anyone wants. Yes, that short program is very welcome, please include it in the bug that you file in bugzilla. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Failure to compile Mono 3.2.7-branch from source
AFAIU the fix for this was already in master, and Antonious sent a pull-request to backport the fix to this branch, which has just been committed by Alex: https://github.com/mono/mono/pull/893 On 18/02/14 06:10, jean-michel.perr...@csiro.au wrote: Hi, I am trying to test an app on Mono 3.2.7, but cannot seem to get it to build properly. I can check out the 3.2.3 branch, and build/install it bootstrapped with the prepackaged 3.0.6, but whether I use 3.2.3 or 3.0.6 as a bootstrap the build of 3.2.7 fails. If anyone has a hunch or advice. Cheers Repro information: Linux 3.12-1-amd64 #1 SMP Debian 3.12.9-1 (2014-02-01) x86_64 GNU/Linux (Debian Unstable, just updated all packages) Mono JIT compiler version 3.2.3 (mono-3.2.3-branch/4d8ba16 Tuesday 18 February 15:23:35 EST 2014) Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:sgen git checkout mono-3.2.7-branch git pull ./autogen.sh --prefix=/usr/local make MCS [build] mscorlib.dll Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x001f7 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: /home/xyz/src/mono/mono/mini/mono() [0x4b6398] /home/xyz/src/mono/mono/mini/mono() [0x50d81b] /home/xyz/src/mono/mono/mini/mono() [0x423ae2] /lib/x86_64-linux-gnu/libpthread.so.0(+0xf210) [0x2b284160e210] /lib/x86_64-linux-gnu/libpthread.so.0(pthread_join+0x24) [0x2b2841607f64] /home/xyz/src/mono/mono/mini/mono() [0x5a9e84] /home/xyz/src/mono/mono/mini/mono(mono_runtime_cleanup+0xe) [0x5a1d5e] /home/xyz/src/mono/mono/mini/mono() [0x41b6b6] /home/xyz/src/mono/mono/mini/mono() [0x53d4db] [0x41aed82d] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Recent xbuild fixes causing issues with finding mcs
On 16/02/14 10:15, Michael Hutchinson wrote: ... which automatically executes exe files using Mono. Are you sure that statement applies to all distros? I read somewhere some time ago that the only distro so far that implemented the ability to run .exe files automatically by calling mono under the hood was Debian (and derivatives), by installing some system hook by default when mono packages are installed. Maybe Michael Franz is not using Debian? Or maybe that hook doesn't work for him because he's using a custom mono install (instead of debian packages)? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 3 questions about AOT and the JIT
Hi! Just 3 quick questions: a) This full-AOT limitation about using interfaces with generics (http://www.mono-project.com/AOT#Limitation:_Generic_Interface_Instantiation) is it only a problem when using value types, or any type? b) Why the above limitation is not listed here? http://docs.xamarin.com/guides/ios/advanced_topics/limitations/ c) Would it be possible to instruct the JIT to do a whole compilation of all the methods of all the types of all the assemblies currently loaded by the runtime, at startup? (To prevent them to be lazy loaded.) (I ask the last question because I'm not sure I will be able to achieve FullAOT for certain codebase due to its restrictions, and in this case I would want at least to have the full compilation at startup, which is worse than at compilation time, but better than slowing down the app for all first times that a certain feature is used.) Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TcpListener.AcceptTcpClient leaks a socket at each call
Sounds good, then can the SetTcpClient() method be removed?
(If it can't because other places in the code are using it, you would
need to:
- Either make them use the new ctor.
- Or fix SetTcpClient() to close the previous socket?
)
If it can be removed because there are no more things using it, I say
simply create a pull request with your change.
On 23/01/14 16:59, Jonathan Gagnon wrote:
Here is the proposed change. See attached files.
I'm not too familiar with sending diffs so let me know if I didn't send
it in the expected format.
*Jonathan Gagnon*
Architecte d'application / Application Architect
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
On Wed, Jan 22, 2014 at 5:15 PM, Andrés G. Aragoneses
kno...@gmail.com mailto:kno...@gmail.com wrote:
On 22/01/14 22:32, Jonathan Gagnon wrote:
I found a leak in TcpListener.AcceptTcpClient :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(); // this call creates a socket
even
though we don't need it
// use internal method SetTcpClient to make a
// client with the specified socket
client.SetTcpClient (clientSocket); // This method leaks the socket
created by the default constructor.
return client;
}
The method calls the default TcpClient constructor which creates a new
socket. SetTcpClient is then called to assign the accepted socket to
the TcpClient object. The problem is that the SetTcpClient simply
replaces the old socket reference by the new without closing the old
socket. The result is that the socket created by the default
constructor remains until the GC reclaims it.
The fix would be really easy. Instead of calling the default
TcpClient
constructor, a new constructor could be created taking the socket as
parameter. We would then avoid creating and leaking a socket
every time
the method is called. The fixed method would look like this :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(clientSocket);
return client;
}
I could create a fix with the proposed solution. Any thoughts?
Propose your solution as diff format please, it's much easier to
understand and review.
___
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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] TcpListener.AcceptTcpClient leaks a socket at each call
On 22/01/14 22:32, Jonathan Gagnon wrote:
I found a leak in TcpListener.AcceptTcpClient :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(); // this call creates a socket even
though we don't need it
// use internal method SetTcpClient to make a
// client with the specified socket
client.SetTcpClient (clientSocket); // This method leaks the socket
created by the default constructor.
return client;
}
The method calls the default TcpClient constructor which creates a new
socket. SetTcpClient is then called to assign the accepted socket to
the TcpClient object. The problem is that the SetTcpClient simply
replaces the old socket reference by the new without closing the old
socket. The result is that the socket created by the default
constructor remains until the GC reclaims it.
The fix would be really easy. Instead of calling the default TcpClient
constructor, a new constructor could be created taking the socket as
parameter. We would then avoid creating and leaking a socket every time
the method is called. The fixed method would look like this :
public TcpClient AcceptTcpClient ()
{
if (!active)
throw new InvalidOperationException (Socket is not listening);
Socket clientSocket = server.Accept ();
TcpClient client = new TcpClient(clientSocket);
return client;
}
I could create a fix with the proposed solution. Any thoughts?
Propose your solution as diff format please, it's much easier to
understand and review.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assert: condition `ret == 0' not met
Bassam, I bisected it and I think the culprit is in this commit: https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0 Can you confirm my finding by trying to build the previous commit to this one? Thanks On 14/01/14 02:55, Andrés G. Aragoneses wrote: I confirm the problem, I also get it in Linux64bits On 14/01/14 00:33, Bassam Tabbara wrote: Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com mailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195
Re: [Mono-dev] Assert: condition `ret == 0' not met
I confirm the problem, I also get it in Linux64bits On 14/01/14 00:33, Bassam Tabbara wrote: Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com mailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195 frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216 frame #9: 0x00010935bc1e mono`mono_runtime_cleanup(domain=unavailable) + 14 at appdomain.c:354 frame #10: 0x0001091d900c
Re: [Mono-dev] mono-2.11.4 on Solaris 11.1
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
Re: [Mono-dev] (no subject)
What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- 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] (no subject)
This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- 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] (no subject)
If it still crashes with master, run it with gdb and obtain a backtrace, and attach it to a bug report. On 10/01/14 11:43, James Nugent wrote: Thanks, I'll try this today. Cheers, James On 10 Jan 2014, at 10:42, Andrés G. Aragoneses kno...@gmail.com wrote: This 64bits-only bug could be the culprit: https://bugzilla.xamarin.com/show_bug.cgi?id=14834 It's fixed already in master branch. Try master. On 10/01/14 11:34, Andrés G. Aragoneses wrote: What version of mono, and what architecture are you running this on? On 07/01/14 16:20, Greg Young wrote: Interesting issue came up today. All code works fine when run with mono regularly. However when we statically link mono and put the system under pressure we end up getting a SIGABRT on a fairly innocuous call (not right away). We cannot reproduce this with mono not statically linked. Anyone have any ideas where to start looking? at unknown 0x at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) 0x at System.IO.MemoryStream.set_Capacity (int) 0x00077 at System.IO.MemoryStream.Expand (int) 0x00036 at System.IO.MemoryStream.Write (byte[],int,int) 0x00093 at ProtoBuf.ProtoWriter.Flush (ProtoBuf.ProtoWriter) 0x00034 at ProtoBuf.ProtoWriter.Dispose () 0x0001b at ProtoBuf.ProtoWriter.Close () 0x00023 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object,ProtoBuf.SerializationContext) 0x00087 at ProtoBuf.Meta.TypeModel.Serialize (System.IO.Stream,object) 0x0001b at ProtoBuf.Serializer.SerializeT (System.IO.Stream,T) 0x00037 at EventStore.Core.Services.Transport.Tcp.ProtobufExtensions.SerializeT (T) 0x00073 at EventStore.Core.Services.Transport.Tcp.InternalTcpDispatcher.WrapDataChunkBulk (EventStore.Core.Messages.ReplicationMessage/DataChunkBulk) 0x00153 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messages.ReplicationMessage/DataChunkBulk, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Message s.ReplicationMessage/DataChunkBulk) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher/AddWrapperc__AnonStorey4D`1.m__10A (EventStore.Core.Messaging.Message) 0x00057 at (wrapper delegate-invoke) System.Func`2EventStore.Core.Messaging.Message, EventStore.Core.Services.Transport.Tcp.TcpPackage.invoke_TResult__this___T (EventStore.Core.Messaging.Message) 0x at EventStore.Core.Services.Transport.Tcp.TcpDispatcher.WrapMessage (EventStore.Core.Messaging.Message) 0x000d6 at EventStore.Core.Services.Transport.Tcp.TcpConnectionManager.SendMessage (EventStore.Core.Messaging.Message) 0x0004c at EventStore.Core.Services.TcpSendService.Handle (EventStore.Core.Messages.TcpMessage/TcpSend) 0x0001f at EventStore.Core.Bus.MessageHandler`1.TryHandle (EventStore.Core.Messaging.Message) 0x00094 at EventStore.Core.Bus.InMemoryBus.Publish (EventStore.Core.Messaging.Message) 0x000fe at EventStore.Core.Bus.InMemoryBus.Handle (EventStore.Core.Messaging.Message) 0x00013 at EventStore.Core.Bus.QueuedHandlerThreadPool.ReadFromQueue (object) 0x00137 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: ./clusternode() [0x6215be] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f289d4f2cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f289d159425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f289d15cb8b] ./clusternode() [0x5803dd] ./clusternode() [0x580472] ./clusternode() [0x524a24] ./clusternode() [0x528c0e] ./clusternode() [0x52cf61] ./clusternode() [0x52e541] ./clusternode() [0x51283f] ./clusternode() [0x5186b3] ./clusternode() [0x518c6b] ./clusternode() [0x50b487] ./clusternode() [0x50b6d8] ./clusternode(mono_array_new_specific+0x36) [0x4e4256] [0x41e25187] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Aborted -- 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-list] Why doesn't Mono include full stack trace information into exception?
What version of mono are you using? If 3.0, please upgrade and retest. If = 3.0, please report a bug in http://bugzilla.xamarin.com/ On 30/12/13 14:04, Andrei Faber wrote: it doesn't seem to change anything mono.exe --debug ConsoleApplication2.exe System.ApplicationException: An application exception has occurred. at ConsoleApplication2.Program.Main (System.String[] args) [0x0] in filename unknown:0 If you pass the —debug option to mono, you should get the full stack trace. http://www.mono-project.com/Debugging On Dec 29, 2013, at 11:16 PM, Andrei Faber andrei.fa...@gmail.com wrote: Why doesn't Mono include full stack trace information into exception? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] System.ExecutionEngineException: Failed to create shadow copy (CopyFile).
What version of mono are you running? On 23/12/13 12:57, Alistair Bush wrote: I have be working to get the fubu (mvc) framework and associated tools working on mono/linux. I have gotten most of the way to running a basic app but have sadly come stuck on the following and am running out of ideas. Basically I have setup a 'web' project using fubu new and am attempting to run it by calling fubu run. Sadly i'm getting the output [1] and as you will be able to see this is caused by a ExecutionEngineException when attempting to call Type.IsAssignableFrom. At this particular point in the code it is my understanding that the application is within a separate app domain ( see Bottles.Services.Remote.RemoteServicesProxy ). This is anything which should be stopping mono from inspecting Type information on a Type when within a separate app domain? Also it the moment im a little stuck on how to get more information to debug this issue. Any suggestions would be welcomed. Thanks. [1] $ fubu run --directory src/fubutest Alias is returning '/home/alistair/Projects/fubu/tests/fubutest' Alias is returning 'src/fubutest' Assembly bin path is bin The configuration file is /home/alistair/Projects/fubu/tests/fubutest/src/fubutest/Web.config Started service Fubu.Running.RemoteFubuMvcBootstrapper Trying to start application /home/alistair/Projects/fubu/tests/fubutest/src/fubutest with port number 5500 FubuMode = Development ERROR: System.ExecutionEngineException: Failed to create shadow copy (CopyFile). Server stack trace: at (wrapper managed-to-native) System.Type:type_is_assignable_from (System.Type,System.Type) at System.Type.IsAssignableFrom (System.Type c) [0x0] in filename unknown:0 at FubuCore.TypeExtensions.IsConcreteTypeOf[IApplicationSource] (System.Type pluggedType) [0x0] in filename unknown:0 at Fubu.Running.ApplicationSourceFinder.Findm__1 (System.Type x) [0x0] in filename unknown:0 at System.Linq.Enumerable+CreateWhereIteratorc__Iterator1E`1[System.Type].MoveNext () [0x0] in filename unknown:0 at System.Linq.Enumerable+CreateDistinctIteratorc__Iterator3`1[System.Type].MoveNext () [0x0] in filename unknown:0 at System.Linq.Enumerable.Any[Type] (IEnumerable`1 source) [0x0] in filename unknown:0 at Fubu.Running.ApplicationSourceChooser.Find (Fubu.Running.StartApplication message, System.Action`1 onFound) [0x0] in filename unknown:0 at Fubu.Running.RemoteFubuMvcBootstrapper.Receive (Fubu.Running.StartApplication message) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub+c__DisplayClass3`1[Fubu.Running.StartApplication].Sendb__1 (IListener`1 x) [0x0] in filename unknown:0 at System.Collections.Generic.GenericEnumerableExtensions.Each[IListener`1] (IEnumerable`1 values, System.Action`1 eachAction) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub.Send[StartApplication] (Fubu.Running.StartApplication message) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub+Sender`1[Fubu.Running.StartApplication].Send (System.Object o, Bottles.Services.Messaging.MessagingHub listeners) [0x0] in filename unknown:0 at Bottles.Services.Messaging.MessagingHub.SendJson (System.String json) [0x0] in filename unknown:0 at Bottles.Services.Remote.RemoteServicesProxy.SendJson (System.String json) [0x0] in filename unknown:0 at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices:InternalExecute (System.Reflection.MethodBase,object,object[],object[]) at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage (System.MarshalByRefObject target, IMethodCallMessage reqMsg) [0x0] in filename unknown:0 Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg, System.Exception exc, System.Object[] out_args) [0x0] in filename unknown:0 Shutting down finalizer thread timed out. Failed to destroy mutex 0x965988 error code 16 errno 2 ___ 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-list] Size of thread in Mono (65MB per thread ?)
On 19/12/13 11:09, Nicolas Antoniazzi wrote: Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already consumed without the use of any thread. Is it a normal behavior? Thanks! What version of mono are you using? Have you tried running your program under the .NET framework, to compare? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Size of thread in Mono (65MB per thread ?)
Try finding the limit on the MS.NET platform, to know how it dies in .NET as opposed to Mono. Also, try the new version 3.2.x of mono which comes with a new garbage collector, and post new results. On 19/12/13 15:29, Nicolas Antoniazzi wrote: I installed Visual Studio in a windows virtual machine. On a standard .Net platform, the same program uses 16MB of memory at initialization and adds approximately 20KB for each thread. It looks normal to me since the main goal of threads are to be light. It's like if threads were acting like a fork() for Mono. So, I'm still stuck with this problem at the moment :( 2013/12/19 Nicolas Antoniazzi nico...@codingame.com mailto:nico...@codingame.com I tried with version 2.10.8 and 3.0.6. Both leads to the same behavior. (Maybe gaining few KB with 3.0.6) Unfortunately, I do not have .Net development environment to test. Nicolas Antoniazzi CTO - CodinGame http://www.codingame.com http://www.codingame.com/ +33 (0)4 67 13 00 96 tel:%2B33%20%280%294%2067%2013%2000%2096 2013/12/19 Andrés G. Aragoneses kno...@gmail.com mailto:kno...@gmail.com On 19/12/13 11:09, Nicolas Antoniazzi wrote: Hi, I am using Mono in a virtualized environment with 512MB of RAM. I made a very simple program which starts 10 threads in a loop and apparently, every time that I start a new thread, approximately 65MB of memory is used. In my case, I can run 5 threads, but for the 6th, the program crashes (without any exception). 150MB are already consumed without the use of any thread. Is it a normal behavior? Thanks! What version of mono are you using? Have you tried running your program under the .NET framework, to compare? ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Installing mono via copy
/usr/local is the default prefix if you don't supply one. This is normally the standard in most open source projects and the motivation of it is not to conflict with software installed by packages (which goes to /usr instead). But given that you're in an embedded system I would just use the /usr prefix to prevent incompatibilities that normally arise when integrating software between /usr and /usr/local So to answer your question: yes, you still need to specify the prefix at configure time, but define a DESTDIR at installation time. Maybe this example script can clear any more doubts you have (it's used to create .deb packages): https://github.com/7digital/7digital-mono/blob/master/build-mono-package.bash On 13/12/13 20:08, Chris Tacke wrote: So if I make install DESTDIR /path/to/temp do I still need to install on the target at /usr/local (te default prefix), or will “anywhere” work? I assume the former, but am trying to understand. -Chris *From:*mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Nikita Tsukanov *Sent:* Friday, December 13, 2013 1:06 PM *To:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Installing mono via copy - set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com mailto:cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Installing mono via copy
If you were right, DESTDIR env var would not exist, and one would simply use the --prefix flag at configure time. DESTDIR is used as a prefix to the prefix, that is, if your prefix was /foo and you set DESTDIR to /bar, then the files go to /bar/foo, to let you tar them up easily from /bar/foo but still having built binaries and scripts that are meant to be placed in /foo. After you compress /bar/foo, then you should later untar to /foo to make it work, obviously. This is essentially how deb/rpm packaging works, kinda. On 13/12/13 21:02, Nikita Tsukanov wrote: You should install to the _same_ prefix you configured your sources. ./configure script hardcodes some paths based on prefix value and compiled code will expect to find needed files there. 2013/12/13 Andrés G. Aragoneses kno...@gmail.com mailto:kno...@gmail.com /usr/local is the default prefix if you don't supply one. This is normally the standard in most open source projects and the motivation of it is not to conflict with software installed by packages (which goes to /usr instead). But given that you're in an embedded system I would just use the /usr prefix to prevent incompatibilities that normally arise when integrating software between /usr and /usr/local So to answer your question: yes, you still need to specify the prefix at configure time, but define a DESTDIR at installation time. Maybe this example script can clear any more doubts you have (it's used to create .deb packages): https://github.com/7digital/7digital-mono/blob/master/build-mono-package.bash On 13/12/13 20:08, Chris Tacke wrote: So if I make install DESTDIR /path/to/temp do I still need to install on the target at /usr/local (te default prefix), or will “anywhere” work? I assume the former, but am trying to understand. -Chris *From:*mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Nikita Tsukanov *Sent:* Friday, December 13, 2013 1:06 PM *To:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] Installing mono via copy - set a custom prefix (and other stuff) during configure That's the problem. It tries to look for mscorlib at $prefix/lib/mono/blablablah instead of /usr/lib. Instead of using custom prefix just configure it with normal (i. e. /usr) and use make install DESTDIR=/path/to/temp/dir. It will install all files to that directory, and you'll be able to create your tarball. 2013/12/13 Chris Tacke cta...@opennetcf.com mailto:cta...@opennetcf.com mailto:cta...@opennetcf.com mailto:cta...@opennetcf.com I have an embedded Linux platform on which I need to install Mono. The platform does not have any installer tools like apt or whatever. I have to custom build Mono for the platform for a variety of reasons. I am successfully building Mono from source under an Ubuntu machine. That works just fine. The problem I'm now facing is how to distribute the resulting build. Due to size contraints, I've compiled only the 4.5 stuff, plus I've pulled out a variety of things like System.Drawing, all of the WinForms stuff, etc. I've also stripped the binaries. What I did was: - set a custom prefix (and other stuff) during configure - make make install. - Go into the install folder and trim out stuff I don't need and strip binaries So now I have a set of folders that contain Mono. My hope was that I could tar these up, copy that to the destination, untar it in the /usr directory so that the mono bin files end up in /usr/bin, the mono lib files end up in /usr/lib etc. Doing this I success if I do a mono -V. I get version info. However, if I try to actually run a mono app, it complains about not finding mscorlib.dll. It's looking in the path where I set the prefix back on the build machine. How should I be going about doing an installation like this? What am I missing in my process? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman
Re: [Mono-dev] AppDomain Support
On 11/12/13 03:33, Christian Smith wrote: I was wondering what the current status of AppDomain support is and what the plans for this are? I.e. is it not implemented? 70% implemented etc... AFAIK it's fully implemented. Do you see any problems with it? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Threading.Monitor.IsEntered? Will this be implemented?
Seems very straightforward to implement. If I were you I would just have
a crack at it, and propose it as a pull request. It's the best way to
get unblocked.
On 10/12/13 00:50, vbguy81 wrote:
Hi,
I have a project in .NET 4.5 that utilizes Monitor.IsEntered to check if
there is still a lock on a particular reference. You can lock multiple times
by doing something like the following.
Monitor.Enter(MyLock);
Monitor.Enter(MyLock);
//..Do something..
Monitor.Exit(MyLock);
//there is still a lock.
As a precaution, when an exception is thrown, I'll loop over MyLock with
Monitor.Exit until IsEnter() returns false. In some of my more complicated
Multi-threaded programs the reference and at times these can get locked
twice (Try to avoid this, but it happens). For me, using Monitor.IsEntered
is an easy way to make sure everything gets cleaned up.
In Thread.cs, I found the following:
#if NET_4_5
[MonoTODO]
public static bool IsEntered (object obj)
{
throw new NotImplementedException ();
}
#endif
Does anyone have a timeline when this might be implemented?
Thanks,
Harry
--
View this message in context:
http://mono.1490590.n4.nabble.com/System-Threading-Monitor-IsEntered-Will-this-be-implemented-tp4661494.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Compiling Mono 3.2.3 libraries - Windows/Visual Studio/3264bit
On 07/12/13 10:25, BearishSun wrote: Hello, I have managed to compile Mono 3.2.3. on Windows with Visual Studio 2012 using both 32bit and 64bit configurations but had some issues along the way. As I have found little to none up-to-date information regarding this topic, thought I'd share them with people in case anyone finds them useful. I have only compiled the native libraries (mono-2.0.dll, mono.exe). Here goes: snip / These changes would have been much easier to grok if each of them was in .diff format. Bonus points if you can create a pull request (with 12 commits) in github. Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
Seconded.
On 07/11/13 11:16, Stifu wrote:
I'm in no position to accept or review your patch, but I wanted to thank you
for taking the time and putting in the efforts needed to make Mono better
for everyone.
I hope this pull request gets attention soon.
Alistair Bush wrote
Hi guys,
Please note that I have cleaned this up and bit and submitted a pull
request
https://github.com/mono/mono/pull/800
Feedback welcome.
On Wed, Oct 30, 2013 at 11:51 PM, Alistair Bush lt;
alistair.bush@
gt; wrote:
Ok so firstly this is like the MOST C ive ever written in my life..
and it looks ugly and ive only vagely checked that it doesn't break
the northern hemisphere.
But isn't this a better patch of the method?
(https://github.com/alistair/mono/commit/6912202aab5a424e98bc44d7b988c2791f91)
Any help turning this into an acceptable pull request would be really
appreciated.
diff --git a/mono/metadata/icall.c b/mono/metadata/icall.c
index 618e4da..7f47624 100644
--- a/mono/metadata/icall.c
+++ b/mono/metadata/icall.c
@@ -5930,10 +5930,12 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
struct tm start, tt;
time_t t;
- long int gmtoff;
- int is_daylight = 0, day;
+ long int gmtoff, gmtoff_st, gmtoff_ds;
+ int day, transitioned;
char tzone [64];
+ gmtoff_st = gmtoff_ds = transitioned = 0;
+
MONO_ARCH_SAVE_REGS;
MONO_CHECK_ARG_NULL (data);
@@ -5974,8 +5976,10 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
t += 3600*24;
tt = *localtime (t);
+long int gmtoff_after = gmt_offset(tt, t);
+
/* Daylight saving starts or ends here. */
- if (gmt_offset (tt, t) != gmtoff) {
+ if (gmtoff_after != gmtoff) {
struct tm tt1;
time_t t1;
@@ -5995,36 +5999,37 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
strftime (tzone, sizeof (tzone), %Z, tt);
/* Write data, if we're already in daylight saving, we're done. */
- if (is_daylight) {
- mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 1, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
- return 1;
+ if (tt.tm_isdst) {
+ mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
+ mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff;
+ gmtoff_ds = gmtoff_after;
+ }
+ transitioned++;
} else {
- struct tm end;
time_t te;
+ te = mktime (tt);
- memset (end, 0, sizeof (end));
- end.tm_year = year-1900 + 1;
- end.tm_mday = 1;
-
- te = mktime (end);
-
- mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) *
1000L);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_set ((*data), gint64, 1, ((gint64)te + EPOCH_ADJUST) *
1000L);
- is_daylight = 1;
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff_after;
+ gmtoff_ds = gmtoff;
+ }
+ transitioned++;
}
/* This is only set once when we enter daylight saving. */
- mono_array_set ((*data), gint64, 2, (gint64)gmtoff * 1000L);
- mono_array_set ((*data), gint64, 3, (gint64)(gmt_offset (tt, t) -
gmtoff) * 1000L);
-
+ if (tt1.tm_isdst) {
+ mono_array_set ((*data), gint64, 2, (gint64)gmtoff_st * 1000L);
+ mono_array_set ((*data), gint64, 3, (gint64)(gmtoff_ds - gmtoff_st)
* 1000L);
+ }
gmtoff = gmt_offset (tt, t);
}
}
- if (!is_daylight) {
+ if (transitioned 2) {
strftime (tzone, sizeof (tzone), %Z, tt);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
On Tue, Oct 29, 2013 at 9:13 AM, Alistair Bush lt;
alistair.bush@
gt; wrote:
Well that certainly sucks.
On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan lt;
robertj@
gt; wrote:
On 28.10.2013 07:35, Alistair Bush wrote:
I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.
The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.
To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
___
Mono-devel-list mailing list
Mono-devel-list@.ximian
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fix for using GTK# in mono embedded application
On 03/11/13 15:58, Vardar Sahin wrote:
Environment.GetCommandLineArgs is an internal call and my assumption was
that the internal call is not registered to a C function. But now I see
that I can call Environment.GetCommandLineArgs.
I checked it out and Environment.GetCommandLineArgs returns null if you
embed mono into your application.
So you have to check for a null reference.
Ok thanks, I updated the pull request adding a null check
And and maybe you have to set
GLib.Global.ProgramName to static name in case.
What do you mean? GLib.Global.ProgramName is already static.
Thanks
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
Being not registered means that accessing GetCommandLineArgs throws
an exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will fix the
problem.
I think the problem is that you can not call
Environment.__GetCommandLineArgs() when you embed mono.
Environment.__GetCommandLineArgs() is an internal call and it
seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an
application which
embeds mono. GTK# works just fine if you use mono as a
standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono
is as
fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.SetSynchronizationContext (new
GLib.GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded
in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.GetFileNameWithoutExtension
(Environment.GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs ()
will fail
because
it is not set to anything. When you run the same on
mono as a
standalone
application it will work because mono will pass the
command line
argument via Environment.GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and
return just a
dummy string.
My suggestion would be to do the same in mono when you
embed it
or to
change SetPrgname to not relay on
Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-sharp/pull/90/files
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto:Mono-devel-list@lists.__ximian.com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
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
mailto: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
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/__mailman/listinfo
Re: [Mono-dev] Fix for using GTK# in mono embedded application
Why do you assume that there is a bad consequence if g_set_prgname() is
not called? Please test it, and if you confirm any bad behaviour, come
back with more info.
On 03/11/13 20:50, Vardar Sahin wrote:
I think that GLib.Global.ProgramName has to be set to a value.I am not
sure what will happen when it is not set.
In case args == null and we should set GLib.Global.ProgramName to a
static value like this.
var args = Environment.GetCommandLineArgs ();
if (args != null args.Length 0){
GLib.Global.ProgramName =
System.IO.Path.GetFileNameWithoutExtension (args [0]);
}else
{
GLib.Global.ProgramName = EmbeddedMono;
}
2013/11/3 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
On 03/11/13 15:58, Vardar Sahin wrote:
Environment.GetCommandLineArgs is an internal call and my
assumption was
that the internal call is not registered to a C function. But
now I see
that I can call Environment.__GetCommandLineArgs.
I checked it out and Environment.GetCommandLineArgs returns null
if you
embed mono into your application.
So you have to check for a null reference.
Ok thanks, I updated the pull request adding a null check
And and maybe you have to set
GLib.Global.ProgramName to static name in case.
What do you mean? GLib.Global.ProgramName is already static.
Thanks
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
Being not registered means that accessing
GetCommandLineArgs throws
an exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will
fix the
problem.
I think the problem is that you can not call
Environment.GetCommandLineArgs() when you embed mono.
Environment.GetCommandLineArgs() is an internal
call and it
seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
mailto:kno...@gmail.com mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work
and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an
application which
embeds mono. GTK# works just fine if you use
mono as a
standalone
application eg mono.exe.
The reason why GTK# does not works when you
embed mono
is as
fallowing.
Each GTK# Application has to call
Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.__SetSynchronizationContext (new
GLib.__GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is
embedded
in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.__GetFileNameWithoutExtension
(Environment.__GetCommandLineArgs () [0]);
}
When embedding Mono,
Environment.GetCommandLineArgs ()
will fail
because
it is not set to anything. When you run the
same on
mono as a
standalone
application it will work because mono will
pass the
command line
argument via
Environment.__GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own
fucntion and
return just
Re: [Mono-dev] Fix for using GTK# in mono embedded application
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to contribute this
to the mono project.
Right now it is not possible to use GTK# with an application which
embeds mono. GTK# works just fine if you use mono as a standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono is as fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.SetSynchronizationContext (new
GLib.GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded in an application.
static void SetPrgname ()
{
GLib.Global.ProgramName = System.IO.Path.GetFileNameWithoutExtension
(Environment.GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs () will fail because
it is not set to anything. When you run the same on mono as a standalone
application it will work because mono will pass the command line
argument via Environment.GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and return just a
dummy string.
My suggestion would be to do the same in mono when you embed it or to
change SetPrgname to not relay on Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Fix for using GTK# in mono embedded application
Being not registered means that accessing GetCommandLineArgs throws an
exception? If yes, what kind?
On 02/11/13 22:10, Vardar Sahin wrote:
Hey Andrés,
thanks for the quick replay. I am not sure if this will fix the problem.
I think the problem is that you can not call
Environment.GetCommandLineArgs() when you embed mono.
Environment.GetCommandLineArgs() is an internal call and it seems like
it is not registered when you embed mono.
Best
Sahin
2013/11/2 Andrés G. Aragoneses kno...@gmail.com
mailto:kno...@gmail.com
On 02/11/13 21:42, Vardar Sahin wrote:
Hey monodev fellows,
first of all I appreciate all your hard work and want to
contribute this
to the mono project.
Right now it is not possible to use GTK# with an application which
embeds mono. GTK# works just fine if you use mono as a standalone
application eg mono.exe.
The reason why GTK# does not works when you embed mono is as
fallowing.
Each GTK# Application has to call Application.Init().
This functions is like this.
public static void Init ()
{
SetPrgname ();
IntPtr argv = new IntPtr(0);
int argc = 0;
gtk_init (ref argc, ref argv);
SynchronizationContext.__SetSynchronizationContext (new
GLib.__GLibSynchronizationContext ());}
Init will fail on SetPrgname (); when mono is embedded in an
application.
static void SetPrgname ()
{
GLib.Global.ProgramName =
System.IO.Path.__GetFileNameWithoutExtension
(Environment.__GetCommandLineArgs () [0]);
}
When embedding Mono, Environment.GetCommandLineArgs () will fail
because
it is not set to anything. When you run the same on mono as a
standalone
application it will work because mono will pass the command line
argument via Environment.__GetCommandLineArgs().
I fixed it by registering the internal call for
Environment.GetCommandLineArgs to my own fucntion and return just a
dummy string.
My suggestion would be to do the same in mono when you embed it
or to
change SetPrgname to not relay on
Environment.GetCommandLineArgs ().
Sahin, wouldn't this also fix your use case?
https://github.com/mono/gtk-__sharp/pull/90/files
https://github.com/mono/gtk-sharp/pull/90/files
Thanks
_
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
http://lists.ximian.com/mailman/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-list] WCF knoen types
On 31/10/13 11:41, ZZTop wrote: Hi I try to run my project on Mono 2.10.9 Mono 2.10.x is too old, upgrade to 3.2.x. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] WCF knoen types
You forgot to install https://github.com/mono/libgdiplus/ On 31/10/13 13:33, ZZTop wrote: I did but it looks like there is a problem with 3.2.3 support for WinForms. My app is WinForm app that using WCF for communications. Here is error I get with 3.2.3 System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.WindowsFormsSynchronizationContext --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeEngine --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Windows.Forms.ThemeWin32Classic --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors --- System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus --- System.DllNotFoundException: /tmp/install/lib/libgdiplus.so at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong,System.Drawing.GdiplusStartupInput,System.Drawing.GdiplusStartupOutput) at System.Drawing.GDIPlus..cctor () [0x0] in filename unknown:0 --- End of inner exception stack trace --- at System.Drawing.KnownColors..cctor () [0x0] in filename unknown:0 --- End of inner exception stack trace --- at System.Drawing.Color.get_Black () [0x0] in filename unknown:0 at System.Windows.Forms.ThemeWin32Classic..cctor () [0x0] in filename unknown:0 --- End of inner exception stack trace --- at System.Windows.Forms.ThemeEngine..cctor () [0x0] in filename unknown:0 --- End of inner exception stack trace --- at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined () [0x0] in filename unknown:0 at System.Windows.Forms.Control..ctor () [0x0] in filename unknown:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Control:.ctor () at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor () [0x0] in filename unknown:0 -- View this message in context: http://mono.1490590.n4.nabble.com/WCF-knoen-types-tp4661213p4661219.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Downloading Mono
On 31/10/13 12:57, Edward Ned Harvey (mono) wrote: For all intents and purposes, monodevelop has simply been renamed Xamarin Studio. No. MonoDevelop is fully opensource, XS is not. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Downloading Mono
On 31/10/13 14:54, Edward Ned Harvey (mono) wrote: Have a look here: http://monodevelop.com/Download Try to download Monodevelop, and tell me that it hasn't been renamed Xamarin Studio. The fact that there are no binaries of MonoDevelop for non-Linux platforms in that website doesn't make your statement true. It's called monodevelop in github and Linux. And you won't see XS in github or Linux anytime soon. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Downloading Mono
On 30/10/13 15:03, Edward Ned Harvey (mono) wrote: Monodevelop is a good development tool - but it's superseded by Xamarin. Including Xamarin Studio and so on. XamarinStudio is just MonoDevelop plus the Xamarin plugins to develop on MobileMac. So it is not superseded. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] sgen optimizing
On 28/10/13 15:42, Rodrigo Kumpera wrote: The downside of a larger nursery is the increased pause times for minor collections. The concurrent-garbage-collector announced at the Mono 3.0 release would also be an alternative to avoid the pause times, right? If yes, is the concurrent-garbage-collector the default for multi-core archs? If not, why not? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing NET_2_0 define
On 18/10/13 14:58, Jonathan Pryor wrote: On Oct 16, 2013, at 10:00 AM, Alexander Köplinger alex.koeplin...@outlook.com wrote: Wouldn’t it make sense to remove the #if NET_2_0 checks in the codebase as those are now unnecessary (every profile is now 2.0 or later)? Or are they actually required for something? If not, I’d provide a pull request to clean up those checks. They are not required, but removing them would add extra commit noise, which isn't necessary. Current policy (as it were) is to remove nearby `#if`s when modifying nearby code, so things can be improved in an ongoing basis without littering commit history. WRT git-blame, changing whitespace in existing code clutters commit history, but removing code doesn't. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Fwd: XmlIgnore attribute ignored in SOAP client requests in mono 3.2.1
On 01/10/13 21:33, Dave Curylo wrote: Is this a known issue or is there a workaround or option so it will behave as in previous mono versions? If you're sure that this is a regression, you could try bisecting the problem to the specific commit that introduced it. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] HttpOnly cookies flag supported?
If you grep for HttpOnlyCookies, you get some things which I interpret
as (if I'm not missing anything) the property being there (to not crash
if someone sets it), but no source code using it, so I guess you'll need
to create a pull request if you want it implemented.
For the record, the grep output I got:
knocte@ulises:~/Documents/Code/mono$ grep HttpOnlyCookies -ri ./mcs/class/
./mcs/class/System.Web/Documentation/en/System.Web.Configuration/HttpCookiesSection.xml:
Member MemberName=HttpOnlyCookies
./mcs/class/System.Web/Documentation/en/System.Web.Configuration/HttpCookiesSection.xml:
MemberSignature Language=C# Value=public bool HttpOnlyCookies
{ set; get; } /
./mcs/class/System.Web/Documentation/en/System.Web.Configuration/HttpCookiesSection.xml:
AttributeNameSystem.Configuration.ConfigurationProperty(httpOnlyCookies,
DefaultValue=False)/AttributeName
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
static ConfigurationProperty httpOnlyCookiesProp;
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
httpOnlyCookiesProp = new ConfigurationProperty (httpOnlyCookies,
typeof (bool), false);
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
properties.Add (httpOnlyCookiesProp);
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
[ConfigurationProperty (httpOnlyCookies, DefaultValue = False)]
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
public bool HttpOnlyCookies {
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
get { return (bool) base [httpOnlyCookiesProp];}
./mcs/class/System.Web/System.Web.Configuration_2.0/HttpCookiesSection.cs:
set { base[httpOnlyCookiesProp] = value; }
On 04/10/13 19:35, James Wright wrote:
public static HttpCookie GetAuthCookie (string userName,
bool createPersistentCookie, string strCookiePath)
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Fwd: Tail calls
I hope these two links are useful to you: https://bugzilla.novell.com/show_bug.cgi?id=476785 http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg21820.html On 28/09/13 03:37, mono user wrote: I replied to jmalcom about a week ago but forgot to cc the list. Seeing as no-one else replied to my original post, would it please be at all possible for someone to suggest somewhere else I might try asking? I just want to understand exactly what makes the difference between a tail-call that Mono can eliminate and one it cannot. Many thanks. -- Forwarded message -- From: *mono user* monouse...@gmail.com mailto:monouse...@gmail.com Date: Sat, Sep 21, 2013 at 5:24 AM Subject: Re: [Mono-list] Tail calls To: jmalcolm malcolm.jus...@gmail.com mailto:malcolm.jus...@gmail.com Many thanks for replying. There are four tail calls. i) k [] on the first line of mapk, ii) mapk f ... on the second line of mapk, iii) the call to f passed to the second call to mapk, and iv) the nested call to k also on the second line of mapk. I take it you imply that the code is meant to run out of stack because it is broken. That would in many ways be by far the best outcome from my point of view. But here is a transcript that shows it works fine under .net and f# 3.0. I wonder if you turned tail calls on when compiling? $ c:/Program Files (x86)/Microsoft SDKs/F#/3.0/Framework/v4.0/Fsc.exe --tailcalls+ test.fs Microsoft (R) F# Compiler version 11.0.50727.1 Copyright (c) Microsoft Corporation. All Rights Reserved. Administrator@lab ~ $ ./test.exe Testing depth 1 Testing depth 2 Testing depth 4 Testing depth 8 Testing depth 16 Testing depth 32 Testing depth 64 Testing depth 128 Testing depth 256 Testing depth 512 Testing depth 1024 Testing depth 2048 Testing depth 4096 Testing depth 8192 Testing depth 16384 Testing depth 32768 Testing depth 65536 Testing depth 131072 Testing depth 262144 Testing depth 524288 Testing depth 1048576 Testing depth 2097152 Testing depth 4194304 Testing depth 8388608 Testing depth 16777216 Testing depth 33554432 Administrator@lab ~ $ On Fri, Sep 20, 2013 at 4:56 AM, jmalcolm malcolm.jus...@gmail.com mailto:malcolm.jus...@gmail.com wrote: mono user wrote I wondered if it would be possible to have some advice on how tail recursion elimination works in Mono. I would like to understand under what circumstances Mono can do a tail recursive call without leaving the caller on the stack, and when it cannot. I am afraid I could not find this information anywhere, though I did not try reading the sources. Many thanks in advance. I have a large F# project that I want to run under Mono, and was pleased to see that all 1500+ unit tests passed the first time under 3.2.1. However, my code runs out of stack once applied to non-trivial input, even when I allocate a gigabyte of stack. Here is a cut-down example that started its life as a much larger fold (which would be prohibitively expensive to rewrite in imperative style). Under .net it runs to completion, whereas under Mono it dies after i reaches 17. Is there a way of rewriting the map so that it would not leave anything on the stack when evaluating f? [I cannot just use List.map because it stays on the stack while applying f, and so would cause an overflow e.g. if given a function that uses the same call to map again over and over as it descends down a data structure.] fsharpc --tailcalls+ tailtest.fs mono --optimize=tailc tailtest.exe let rec mapk f xs k = match xs with [] - k [] | x::xs - mapk f xs (fun xs' - f x (fun x' - (x' :: xs') | k)) let test_tail n = printf Testing depth %u\n n let xs = [1..n] let expected = List.map (fun x - x + 1) xs let actual = mapk (fun x k - k (x + 1)) xs id if expected actual then failwithf Something went badly wrong for i=0 to 25 do test_tail (1lt;i) ___ Mono-list maillist - lt;emailgt;Mono-list@.ximian http://lists.ximian.com/mailman/listinfo/mono-list I do not know F# so I must just be missing it but I do not even see the tail call in there. Regardless, I just wanted to throw out there that it fails for me under .NET as well. It only gets to 13 before I get a StackOverflow. -- View this message in context: http://mono.1490590.n4.nabble.com/Tail-calls-tp4660875p4660934.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] WCF via TCP is frightfully slow
On 22/09/13 10:36, mauzik wrote: I tried to remove GC.Collect(). I found simillar problem in topic http://mono.1490590.n4.nabble.com/Mono-WCF-Performance-Issue-td2308250.html and http://mono.1490590.n4.nabble.com/WCF-Performance-issues-on-mono-2-10-td4650668.html. But there are not any replies how to resolve it or if it is limitations. On official mono page is not mentioned comparison between WCF on Mono and on .NET. I supposed that Mono will be a little slower, but this is disaster. I hope I missed important configuration options and performance will be better. What version of mono? If lower than 3.2.x, have you tried running Mono with SGen? ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] open sourcing all of Microsoft .net
opensource != crossplatform Do you think WPF internals are just managed code? On 06/09/13 19:37, Jonathan Lima wrote: There is no reason to use Microsoft code of the BCL. One of the best libraries that could be open sourced is WPF, there isn't any UI framework that works better or that is easier to use than WPF. And with WPF open source, .Net UI could be really cross-platform without needing any modifications. On Fri, Sep 6, 2013 at 2:34 PM, Martin Thwaites monofo...@my2cents.co.uk mailto:monofo...@my2cents.co.uk wrote: There is a specific exclusion in the EULA that says you can't use it port it to a Non-Windows operating system. I think there will always be a slight issue with a Cross Platform .NET as there are too many things that have hook-ins to specific MS Technologies outside of .NET. I agree though, open sourcing the core libraries, holding back some specifics that key into their technologies specifically (IIS comes to mind), would be a big positive move. The reality is though, it would never be termed .NET for Linux or be backed by MS, so major companies will always be apprehensive about running those production sites on Linux. On Sep 6, 2013 6:20 PM, Andrew Clancy n...@achren.org mailto:n...@achren.org wrote: That's not open source, that's readable source, you can't fork it or use it, nor merge it with mono have an official .net framework for linux etc. My thoughts are, if we did have this there'd be more appetite/scope to implement in .net in corporates and environments where linux and/or java rule. Where I work mono isn't an option as there's no other companies of our size using it to the scale we use java, but if a Microsoft backed .net made it to linux it may be an option (and I'm sure if ms open sourced it mono would do most of the work to merge, ms would just need to stamp approval) On 6 Sep 2013 18:10, Mike Christensen m...@kitchenpc.com mailto:m...@kitchenpc.com wrote: I'm pretty sure it already is.. http://referencesource.microsoft.com/netframework.aspx On Wed, Sep 4, 2013 at 11:33 PM, nite n...@achren.org mailto:n...@achren.org wrote: Has the case ever been made to Microsoft to open source all of .net? It's heading that way, now even the asp.net http://asp.net stack is open. Not much to lose, as it isn't part of their core business, and still not part of their core windows stack. Loads to gain, massive kudos from the dev community and the chance to win back the hoards of devs jaded by Microsoft for various reasons. Has anyone from the mono camp ever tried lobbying them, or aware of any efforts? What was the response? -- View this message in context: http://mono.1490590.n4.nabble.com/open-sourcing-all-of-Microsoft-net-tp4660784.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com mailto:Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Thanks, Jonathan ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Unit tests load a different configuration file under mono
This is not related to NUnit. This is exactly bug 11972 which I filed here some months ago: https://bugzilla.xamarin.com/show_bug.cgi?id=11972 The problem lies in the fact that whenever any code inside the System.Web assembly tries to read the configuration, it replaces the System.Configuration infrastructure to the one that is used when a ASP.NET app is run. I have a patch that fixes it, which I proposed in a pull request: https://github.com/mono/mono/pull/725 . However, some time later after I wrote the fix I realized it was based on false assumptions, and I haven't had yet the time to investigate more. Do you mind reading the pull request, subscribe to it, and help? The approach I'm thinking now that may be correct would be replacing all config queries in System.Web that use WebConfigurationManager, to start using ConfigurationManager instead. But I haven't tested it yet. On 10/08/13 03:25, Dave Curylo wrote: Thanks for the reply. I understand how to get the test framework to load a config file, and the first test does just that. It succeeds on both platforms. The second test does the same exact thing, only it makes a call to HttpUtility first, and this seems to trip up the ConfigurationManager, but only under mono. Under MS .NET, both tests succeed in loading the configuration and both pass, but under mono, the first test passes and the second test fails because once a call is made to HttpUtility, the ConnectionStrings are replaced with the defaults from the ASP.NET http://ASP.NET stack. This seems like very odd behavior. On Friday, August 9, 2013, Charlie Poole wrote: Each test framework has it's own requirements for where a config file must be located and how it should be named in order to be loaded and used. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Unit tests load a different configuration file under mono
On 10/08/13 10:40, Andrés G. Aragoneses wrote: ... I have a patch that fixes it, which I proposed in a pull request: https://github.com/mono/mono/pull/725 . Wrong URL, I meant this one: https://github.com/mono/mono/pull/643 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
If you're able to reproduce it with 3.3 and not with 2.10.x, you should
definitely open a bug report for it in http://bugzilla.xamarin.com/
stating [regression] in the bug summary.
Also, I would open a separate bug report for the segfault you're getting
when running with MONO_DISABLE_AIO (pasting the backtrace of the
segfault, with debug symbols installed).
On 07/08/13 14:02, Alfred Hall wrote:
Tried running it with sgen or boehm on 2.10? Worth trying both I think.
Also how about 3.3 (master) ?
-Original message-
*From:* Nikita Tsukanov kek...@gmail.com
*Sent:* Wednesday 7th August 2013 12:54
*To:* mono-devel-list@lists.ximian.com
*Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
locking up on linux
I've rewritten my SCGI server to work with TPL directly instead of
using async/await to make it run on mono 2.10. Then I've tried to
run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
backend and to hammer it with jmeter. 500K requests without any
lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
Server source code is still on GitHub -
https://github.com/kekekeks/scgi-sharp
2013/8/7 Greg Young gregoryyou...@gmail.com
mailto:gregoryyou...@gmail.com
I believe attaching a debugger changes things like optimizations
from occurring (not positive but it does in clr)
On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
Huh, it doesn't require debugger to be _attched_, just
debugging subsystem initialized i. e. if I launch this
program as a debugger it doesn't lock up.
publicstaticvoidMain(string[]args)
{
intport=27042;
if(args.Length !=0)
port=int.Parse(args[0]);
while(true)
{
varvm=
Mono.Debugger.Soft.VirtualMachineManager.Listen(newIPEndPoint(IPAddress.Loopback,port));
vm.Resume();
vm.Detach();
}
}
I'll use running with
--debugger-agent=transport=dt_socket,address=127.0.0.1:27042
http://127.0.0.1:27042 as a temporary workaround since
performance doesn't degrade a lot.
2013/8/7 Nikita Tsukanov kek...@gmail.com
I suspect that the problem is actually with thread pool
itself. I've created socket layer implementation using
libevent (wrapped with Oars) and send/recv that utilizes
thread pool for cases when it's unable to complete
operation synchronously. It survives longer, but still
locks up after a while. Same behavior with debugger -
I'm unable to reproduce the issue when running under it.
I also unable to grab thread stack traces, it prints
Full thread dump: and nothing else.
2013/8/7 Greg Young gregoryyou...@gmail.com
We will see your test then as it will probably
affect us as well
On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
Greg, I've tried running my server with mono
compiled from master (with pull request #703
merged in), still freezes after a while.
2013/8/7 Greg Young gregoryyou...@gmail.com
Do you have our pull req? We are stable
after (and seriously read history of this list)
On Tuesday, August 6, 2013, Nikita Tsukanov
wrote:
https://github.com/kekekeks/scgi-sharp -
here is my SCGI server with host for
NancyFx. If you run Sandbox.exe with
--echo-server it will not use nancy
infrastructure and will respond
directly. It locks up after several
thousands of requests under jmeter.
Simple nginx configuration:
location /
{
include /etc/nginx/scgi_params;
scgi_pass 127.0.0.1:10081
http://127.0.0.1:10081;
}
Now I'm looking for alternative socket
library to use it as a replacement for
System.Net.Sockets.
2013/8/6 Greg Young
gregoryyou...@gmail.com
Actually not that surprised we also
found out file stream.flush(true)
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux
I guess it means that it is a race condition which is not reproducible inside the debugger (as the debugger slows things down). On 06/08/13 21:18, Nikita Tsukanov wrote: Running with mono from master haven't helped. And I'm not sure what the hell is going on, but I cann't reproduce the issue when running under... Monodevelop's debugger. It runs perfectly under it, but when I try to run the same binary from console (even with --debug option) it locks up or segfaults. Does anyone know what does it mean? 2013/8/6 Nikita Tsukanov kek...@gmail.com mailto:kek...@gmail.com Great. It locked up with my more complex logic. Funny fact: NancyFx increases request processing time from 2ms to 70ms with the same echo response. Another funny fact: with MONO_DISABLE_AIO I've got segfault. Now I'll try to use build patched mono. Not sure that it's the same issue, because in my case it never tries to read and write simultaneously on the same socket. 2013/8/6 Greg Young gregoryyou...@gmail.com mailto:gregoryyou...@gmail.com There are many cases the patch we provided does not affect eg no overlap in io between send/receive On Tuesday, August 6, 2013, Nikita Tsukanov wrote: Interesting... I've written a simple server using only Socket.BeginRecieve and Socket.BeginSend. It just reads 100 bytes and then sends hardcoded HTTP response. Now jmeter is working for 5 minutes and it still responds with Lorem ipsum ... perfectly. I'll try to port my SCGI server logic from NetworkStream to Socket and see what will happen. 2013/8/6 Andrés G. Aragoneses kno...@gmail.com On 06/08/13 18:42, Nikita Tsukanov wrote: Ubuntu 13.04, Mono JIT compiler version 3.2.0 (tarball Tue Jul 30 21:08:00 UTC 2013) Mono 3.2.0 does *not* have Yuri's patch. _ 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 -- 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] NancyFX self hosting (HttpListener) locking up on linux
On 04/08/13 03:07, Alfred Hall wrote: Hi there. I'm running the NancyFX web framework in self hosting mode which is using HttpListener which basically means I deploy an executable and run it and it will start a webserver on localhost on a TCP port of choice. I then use nginx to proxy to it. I first ran my executable on my macbook pro and bombarded it with jmeter and it coped fine and no issues. I then deployed on my debian wheezy 64 bit linux box running on top of KVM using mono 3.2.0 and performed the same jmeter experiment. It locks up fairly quickly and wont take any new requests. I've tried using both sgen and boehm but they behave similarly although it seems to lock up faster when using sgen. I also tried enabling MONO_DISABLE_AIO but it doesn't make any difference. Anyone had similar issues? I tried using self hosted ServiceStack which also uses HttpListener and had similar issues so I'm finding it unlikely that the bug is in NancyFX itself. I tried installing mono 2.10.8 to check if this is a regression, but getting exactly the same results. Any idea how I can debug this further or what could be going on. Hey Alfred. Could you try mono master (3.3) instead of 3.2? I mention this because this pull request [1] has been merged recently, which could help in this situation (and wouldn't make much difference in Mac since the problem in this platform is worked-around by avoiding kqueue [2]). [1] https://github.com/mono/mono/pull/703 [2] https://github.com/mono/mono/blob/master/configure.in#L1823 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DataRowCollection.Remove performance
On 01/08/13 06:58, Julian Hamilton wrote: In my own testing this sped up row deletions by approximately 360%, but you can ascertain a more accurate measure for yourself. Good catch! It might be better to provide this contribution in the form of a github pull request. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Mono 3.2.0 Asp.NET MVC Memory Leak
On 31/07/13 22:13, James Wright wrote: I've recently upgraded our web server from Mono 2.10.8 to Mono 3.2.0 (built from source tarball), but I'm noticing a huge difference in memory usage. The old version would startup our ASP.NET MVC 2 website using ~100MB and over approximately two weeks grow to use around 500-600MB. However, the latest version starts up using ~100MB but has grown to use over 1GB+ in just two days under exactly the same load. I might try switching to using the Boehm garbage collector to see if that is any better. Any advice on how to go about diagnosing where this leak is occurring would be greatly appreciated! Our stack is as follows; Amazon Linux x86-64, Apache 2.2, Mono 3.2.0, mod_mono 2.10 And what version of xsp[1]? There have been some memory leak fixes[2] in master which are not in 3.2, so you might want to test with building your own mono. [1] https://github.com/mono/xsp/tree/master/src/Mono.WebServer.Apache [2] https://github.com/mono/mono/commit/c931c463c24ef4f257dc6dc4dafdc2ac81b8a9d3 and https://github.com/mono/mono/commit/76e8c8ba0f5dad4c154b9ab6dd969ef2eb0bec79 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] FIXED: Problems with html in ListItems
On 30/07/13 10:45, APS wrote: I filed a bugreport and suggested a fix https://bugzilla.xamarin.com/process_bug.cgi I removed the html encoding when the text is written on the inner html part of the tag. It seems to work on my app that is pretty large. As I have another wanna-be fix that I described here and on bugreports, what's the best way to have it reviewed? Create a Pull Request on git or keep on describing the fix here? Create a pull request on github, and reference the pullrequest URL in bugzilla. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Building mono 3.0 from source
On 28/07/13 01:39, Brian Vogel wrote: I've been struggling to get a .NET 4.5 site running under Mono 3.0 . The current sites are running on an older Cent OS 5.5 server, and I've since decided to move to Cent OS 6.6 and rebuild the server from scratch to eliminate all possible variables from the equation. I am at the point now where it's looking for a previous version of Mono to install. I definitely don't want to do this since I don't want any added complications. The mono-lite option looks perfect, but the tarball provided by the make script doesn't contain gmcs. Any ideas? AFAIK, the official tarballs (http://download.mono-project.com/sources/mono/) don't need an existing compiler or an external mono-lite. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] error when building libgdiplus
On 26/07/13 09:13, Kostas Cibulskas wrote: Hi, When running make, there is an error in libgdiplus/tests: libtool: link: gcc -g -O2 -pthread -o .libs/testgdi testgdi.o ../src/.libs/libgdiplus.so -lpthread -lfontconfig -pthread /usr/bin/ld: testgdi.o: undefined reference to symbol 'g_print' /usr/bin/ld: note: 'g_print' is defined in DSO /lib/x86_64-linux-gnu/libglib-2.0.so.0 so try adding it to the linker command line I see the missing library added in a Makefile, but for some reason it is not linked. Fix to this is to add -lglib-2.0 and -lX11 to LIBS variable inside Makefile. I cloned libgdiplus from github yesterday, so the problem is new I guess. No idea how could I fix it in a commit, so I though I should let you guys know about this. This is fixed already by this pull request: https://github.com/mono/libgdiplus/pull/7 You could +1 in the PR to ping the maintainers ;) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Random Internal Compiler Error with extension methods on interfaces?
It doesn't compile with Mono 3.0.x. When I said it doesn't throw an error,
I meant that it doesn't throw an exception (internal compiler error), but
it shows the compiler error you describe (ambiguity). So there's no bug
anymore. Upgrade Mono.
On 3 February 2013 19:36, Jordan Earls ea...@lastyearswishes.com wrote:
I'll attempt that. In the mean time, I uncovered the core underlying
cause. It doesn't properly detect an ambiguity I had in my code. This
code shouldn't compile. It should give a compiler error at the `Foo`
constructors
public class Foo
{
public Foo(int? s=null, string m=null)
{
}
public Foo(string m=null, int? s=null)
{
}
public void Get()
{
throw new NotImplementedException();
}
}
class MainClass
{
public static void Main(string[] args)
{
var f=new Foo();
Console.WriteLine(Hello World!);
}
}
The fact that this compiled on latest Mono makes me think it's a bug.
if you replace the `int?` on the Foo constructors with `object`, it'll
throw a compiler error about ambiguous calls. This actually has
nothing to do with extension methods. It's the compiler not detecting
ambiguity where there is some.
On Sun, Feb 3, 2013 at 5:58 AM, Daniel Lo Nigro li...@dan.cx wrote:
I tried comparing Mono 2.10.8 to 3.0.2 in Github but there's 6,566
commits
between them so it's hard to tell exactly which one fixed it :)
If you have time to, you could try a few different Mono versions and
narrow
it down to a release that fixes it. I'd try the last release of 2.10, the
first and last (2.11.4) releases of 2.11, and the first release of 3.0.
It
was probably fixed between 2.10 - 2.11 or 2.11 - 3.0.
On Sun, Feb 3, 2013 at 2:10 PM, Jordan Earls ea...@lastyearswishes.com
wrote:
Awesome.. Is there any reports of bugs that could've caused this? I'd
really like to workaround this issue for compatibility reasons with
older versions of mono
On Sat, Feb 2, 2013 at 9:46 PM, Andres G. Aragoneses kno...@gmail.com
wrote:
On 03/02/13 02:37, Jordan Earls wrote:
If anyone wants to see the bug in action, extract
http://earlz.net/static/repro.tgz
I just tested compiling with Mono 3.0.2 and there is no compiler
error,
so
the bug is fixed in this version.
___
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 on SMARTOS
On 10 October 2012 15:48, Autif Khan autif.ml...@gmail.com wrote: On Tue, Oct 9, 2012 at 3:42 PM, Andres G. Aragoneses kno...@gmail.com wrote: On 09/10/12 14:53, Autif Khan wrote: On Tue, Oct 9, 2012 at 8:11 AM, Fatih Soydan [Personal] fatihsoy...@fatihsoydan.com wrote: Hi; Are there any pre compiled packages for smartos ? SmartOS seems to be catching fire :-) While there are no binaries, there are some tweaks needed to compile mono on SmartOS. Take a look at the following thread from a few weeks ago. http://lists.ximian.com/pipermail/mono-devel-list/2012-August/039520.html If you send a pull request with the change, it will most likely be merged to master so nobody needs tweaks or forks. Will do, I am still trying to get gcc to work on openindiana, will Cool catch you (knocte) up on #mono-dev one of these days - once I am ready. No need, somebody will most likely reply/merge to the pull-request. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] mono-service2 debugging issues
It may be some internal problem on how Mono manages the appdomains of your service. IIRC Mono uses Remoting internally for the communication between them. On 06/12/10 06:56, Abe Gillespie wrote: Yeah, --debug didn't seem to help. However, as luck would have it, Bojan's answer to the JSON.NET thread gave me this little nugget: --trace=E:all However, now that I have the exception stack trace I'm still baffled. Anyone know what's going on below? Does running via mono-service automatically require Remoting? Because my service certainly is not using any Remoting stuff. Now I do have an IMessage interface I use that's defined in my namespace ... could that possibly cause some weird type loading confusion? EXCEPTION handling: System.TypeLoadException: A type load exception has occurred. unnamed thread tid=0x0x7fcbc4cef730 this=0x0x7fcbc0e15e60 thread handle 0x403 state : not waiting owns () at (wrapper remoting-invoke-with-check) Service..ctor ()0x0003a at (wrapper remoting-invoke-with-check) Service..ctor ()0x0003a at Service.Program.Main ()0x0004d at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr)0x0007b at (wrapper managed-to-native) System.AppDomain.ExecuteAssembly (System.AppDomain*,System.Reflection.Assembly,string[])0x00073 at (wrapper managed-to-native) System.AppDomain.ExecuteAssembly (System.AppDomain*,System.Reflection.Assembly,string[])0x00073 at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly,string[])0x00043 at System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[])0x00044 at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[])0x0009a at System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence)0x00028 at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence)0x00088 at MonoServiceRunner.StartService ()0x00500 at (wrapper runtime-invoke)Module.runtime_invoke_int__this__ (object,intptr,intptr,intptr)0x000ad at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices.InternalExecute (System.Reflection.MethodBase,object,object[],object[])0x00064 at (wrapper managed-to-native) System.Runtime.Remoting.RemotingServices.InternalExecute (System.Reflection.MethodBase,object,object[],object[])0x00064 at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage (System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage) 0x0022f at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x000e8 at System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x00086 at System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x00035 at System.Runtime.Remoting.ClientActivatedIdentity.SyncObjectProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x0009c at System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x001b1 at System.Runtime.Remoting.Contexts.CrossContextChannel.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x00126 at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage (System.Runtime.Remoting.Messaging.IMessage)0x0005c at System.AppDomain.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage) 0x000bf at (wrapper remoting-invoke-with-check) System.AppDomain.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage) 0x000a9 at System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage) 0x0006a at (wrapper runtime-invoke) Module.runtime_invoke_CrossAppDomainSink/ProcessMessageRes_object_object (object,intptr,intptr,intptr)0x000ce at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (System.Reflection.MonoMethod*,object,object[],System.Exception) 0x00079 at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (System.Reflection.MonoMethod*,object,object[],System.Exception) 0x00079 at System.AppDomain.InvokeInDomainByID (int,System.Reflection.MethodInfo,object,object[])0x0009c at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage)0x000fb at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (System.Runtime.Remoting.Messaging.IMessage)0x00342 at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke
Re: [Mono-dev] Is there any reason to not add instead a flag?
Ok fair enough, I'll implement your suggestions. You know, it's not that I don't like to document stuff (I'm almost done porting [1] to [2] so we can replace it in [3] ;) ) Regards, Andrés [1] http://www.mono-project.com/Compiling_Mono_From_SVN [2] http://www.mono-project.com/Compiling_Mono_From_Git [3] http://www.mono-project.com/Compiling El 12/08/10 04:39, Miguel de Icaza escribió: Hello, I thought about this, but it would be a bit weird to use a tool called mono-api-info if you don't want the API but the ABI. This is why I thought it would be more intuitive this way. Minor issue. It goes against the If it is not documented, it does not exist rule. Then mono-api-info doesn't exist either :) (there's no man page for it) What we have here is an opportunity. You now get to write the man page and document what both do. I'm thinking I can get it to be the same executable, but can it be a different script called mono-abi-info which internally calls mono-api-info.exe passing the flag? I do not want that, it is a minor aesthetic issue. Just change it to --abi and let us be done. If there's no man page for mono-api-info, I prefer to do it in a wiki page, ok? (Don't know man format enough to not copy-paste the structure ;) ) I realize it is more convenient for you, but it is not more convenient for the user that has to wonder What the hell does this do? Granted, there is no man page, so this is why we are going to turn a negative into a positive. ___ 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-list] Ubuntu
I totally concur with this, and anyway, when someone in the thread said that most Mono users actually come from the usage of Mono applications in Ubuntu, that doesn't mean that the Mono team providing Ubuntu packages would target more users. Why? Because you have to remember that F-Spot (at least) comes by default in Ubuntu, thus Ubuntu comes with all the necessary things to run Mono apps by default. Providing packages would only be for the *advanced* user that installs updated versions of mono apps. Regards, Andres El 12/08/10 03:14, Andreia Gaita escribió: On Thu, Aug 12, 2010 at 12:38 AM, Daniel Hughes tramps...@gmail.com wrote: Quote so my team plays a double role there (OpenSUSE) or distributions where Mono is not included by default So if ubuntu did not support mono by including it by default. Then you would package it. Ubuntu would get first class support from the mono team. We would get new versions of mono as they are released and so mono support on ubuntu would be improved. I could be wrong, but I think you don't understand how packaging works in linux distributions, which is why you're not getting the explanations that have been put forth already. The developer of the application provides the code, and the distribution packages it. Each distro has their own rules and software for packaging, as well as package mantainers and their own schedule for providing new versions of packages. If a distro chooses to not update a package to a more current version, it can be because of many things: 1) they have custom patches that need porting 2) they prefer not to touch system packages until the next major distro release 3) they have long qa/approval cycles for updates 4) a million other reasons, as miguel explained earlier. We do the best we can supporting OSs and distros that don't have package maintainers (or not even a concept of that) or where we're the maintainers ourselves. We're not the Debian or Ubuntu maintainers. Go look at the homepages of pretty much any software available on Ubuntu and note that they don't provide packages, just tarballs. That's how things work in the Linux world. I think we all understand your frustration about this, but insisting on it when everyone has explained it to you repeatedly is not going to make it happen any differently. Ubuntu is extremely well supported, it's dead easy to compile your own Mono if you want, you can use Jo's PPA if you prefer, there's basically a bunch of different ways to update Mono on your system with little effort. You might not like how the Linux packaging process works, but that's how it is, and discussing the pros and cons of particular philosophy is a topic for other mailing lists, I think. andreia gaita ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Ubuntu
El 12/08/10 03:24, Daniel Hughes escribió: Ubuntu does not believe it is its responsibility to update mono between OS releases. If they don't do, and that means that Mono apps (included by default, such as F-Spot) have bugs or even cannot compile, they will be forced to do it. Mono does not believe it is its responsibility to provide ubuntu packages for new mono releases. Users fall into a gap between the two. And must compile from source or use unsupported third party PPA's if and when they are available. Not users, *advanced users*. Normal users just install the CD/DVD, and never update packages except security updates, until they `order` the next set of CD/DVDs when the new Ubuntu version comes out. This is the way it is and this discussion shows that it will not change. Thank you all for explaining this to me. I see no reason for any further discussion here. On Thu, Aug 12, 2010 at 1:14 PM, Andreia Gaita shana.u...@gmail.com wrote: On Thu, Aug 12, 2010 at 12:38 AM, Daniel Hughes tramps...@gmail.com wrote: Quote so my team plays a double role there (OpenSUSE) or distributions where Mono is not included by default So if ubuntu did not support mono by including it by default. Then you would package it. Ubuntu would get first class support from the mono team. We would get new versions of mono as they are released and so mono support on ubuntu would be improved. I could be wrong, but I think you don't understand how packaging works in linux distributions, which is why you're not getting the explanations that have been put forth already. The developer of the application provides the code, and the distribution packages it. Each distro has their own rules and software for packaging, as well as package mantainers and their own schedule for providing new versions of packages. If a distro chooses to not update a package to a more current version, it can be because of many things: 1) they have custom patches that need porting 2) they prefer not to touch system packages until the next major distro release 3) they have long qa/approval cycles for updates 4) a million other reasons, as miguel explained earlier. We do the best we can supporting OSs and distros that don't have package maintainers (or not even a concept of that) or where we're the maintainers ourselves. We're not the Debian or Ubuntu maintainers. Go look at the homepages of pretty much any software available on Ubuntu and note that they don't provide packages, just tarballs. That's how things work in the Linux world. I think we all understand your frustration about this, but insisting on it when everyone has explained it to you repeatedly is not going to make it happen any differently. Ubuntu is extremely well supported, it's dead easy to compile your own Mono if you want, you can use Jo's PPA if you prefer, there's basically a bunch of different ways to update Mono on your system with little effort. You might not like how the Linux packaging process works, but that's how it is, and discussing the pros and cons of particular philosophy is a topic for other mailing lists, I think. andreia gaita ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Is there any reason to not add instead a flag?
Hey Miguel, sorry for the small delay to reply:
El 10/08/10 21:41, Miguel de Icaza escribió:
In your recent commit, you added a new command to mcs/tools/corcompare,
the mono-abi-info tool. I do not know what this tool does, and I do
not know why we could not just have used mono-api-info with a new flag
--abi instead of installing another executable.
I thought about this, but it would be a bit weird to use a tool called
mono-api-info if you don't want the API but the ABI. This is why I
thought it would be more intuitive this way.
It goes against the If it is not documented, it does not exist rule.
Then mono-api-info doesn't exist either :) (there's no man page for it)
So can we:
(a) get this merged into mono-api-info
I'm thinking I can get it to be the same executable, but can it be a
different script called mono-abi-info which internally calls
mono-api-info.exe passing the flag?
(b) document this on the wiki or the relevant man pages?
If there's no man page for mono-api-info, I prefer to do it in a wiki
page, ok? (Don't know man format enough to not copy-paste the structure ;) )
I'll work on it tomorrow. Thanks for the feedback.
Andres
miguel
Branch: refs/heads/master
Home: http://github.com/mono/mono
Commit: c508a786c106ceff274b9b985919368b6b404342
Author: Andrés G. Aragoneses kno...@gmail.com
Date: 08/10/2010 14:36:27
URL:
http://github.com/mono/mono/commit/c508a786c106ceff274b9b985919368b6b404342
Added new ABI mode to mono-api-info tool, wrapped in a mono-abi-info script.
2010-08-05 Andrés G. Aragoneses and...@lindenlab.com
* mcs/tools/corcompare/mono-api-info.cs: Implemented new mode to show ABI.
* mcs/tools/corcompare/Makefile: added mono-abi-info autofoo.
* scripts/.gitignore: added mono-abi-info.
* scripts/Makefile.am: added mono-abi-info autofoo.
Changed paths:
M ChangeLog
M mcs/tools/corcompare/ChangeLog
M mcs/tools/corcompare/Makefile
M mcs/tools/corcompare/mono-api-info.cs
M scripts/.gitignore
M scripts/Makefile.am
Modified: ChangeLog
===
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2010-08-05 Andr??s G. Aragoneses and...@lindenlab.com
+
+* scripts/.gitignore: added mono-abi-info.
+* scripts/Makefile.am: added mono-abi-info autofoo.
+
2010-07-16 Zoltan Varga var...@gmail.com
* configure.in: Remove the 'LLVM backend is experimental' warning.
Modified: mcs/tools/corcompare/ChangeLog
===
--- a/mcs/tools/corcompare/ChangeLog
+++ b/mcs/tools/corcompare/ChangeLog
@@ -1,3 +1,8 @@
+2010-08-05 Andr??s G. Aragoneses and...@lindenlab.com
+
+* mono-api-info.cs: Implemented new mode to show ABI.
+* Makefile: added mono-abi-info autofoo.
+
2010-04-16 C.J. Adams-Collier c...@colliertech.org
* mono-api-diff.cs: revived from the mono-2-2 branch and applied
Modified: mcs/tools/corcompare/Makefile
===
--- a/mcs/tools/corcompare/Makefile
+++ b/mcs/tools/corcompare/Makefile
@@ -2,7 +2,7 @@ thisdir = tools/corcompare
SUBDIRS =
include ../../build/rules.make
-ALL_PROGRAMS = mono-api-info.exe
+ALL_PROGRAMS = mono-api-info.exe mono-abi-info.exe
CECIL = ../../class/lib/net_2_0/Mono.Cecil.dll
@@ -43,3 +43,6 @@ dist-local: dist-default
mono-api-info.exe: $(APIINFO_SOURCES)
$(CSCOMPILE) -r:$(CECIL) -out:$@ $^
+
+mono-abi-info.exe: $(APIINFO_SOURCES)
+$(CSCOMPILE) -r:$(CECIL) -d:ABI -out:$@ $^
Modified: mcs/tools/corcompare/mono-api-info.cs
===
--- a/mcs/tools/corcompare/mono-api-info.cs
+++ b/mcs/tools/corcompare/mono-api-info.cs
@@ -29,6 +29,9 @@ namespace CorCompare
if (args.Length == 0)
return 1;
+AbiMode = false;
+SetAbiMode ();
+
AssemblyCollection acoll = new AssemblyCollection ();
foreach (string fullName in args) {
@@ -45,6 +48,14 @@ namespace CorCompare
doc.WriteTo (writer);
return 0;
}
+
+[System.Diagnostics.Conditional (ABI)]
+private static void SetAbiMode ()
+{
+AbiMode = true;
+}
+
+internal static bool AbiMode { get; private set; }
}
public class Utils {
@@ -211,7 +222,7 @@ namespace CorCompare
if (string.IsNullOrEmpty (t.Namespace))
continue;
-if ((t.Attributes
TypeAttributes.VisibilityMask) != TypeAttributes.Public)
+if (!Driver.AbiMode ((t.Attributes
TypeAttributes.VisibilityMask) != TypeAttributes.Public
[Mono-dev] [PATCH] Fix mono-2-6 build
Hello.
I would like to propose this 2 patches for review, to fix the mono-2-6
branch. In LindenLab we use Debian Etch, and were having 2 issues
building mono 2.6.7:
1) Fix for first patch: avoiding the use of 'var' (Etch has mono 1.9):
http://monobin.com/__m138c04d6
2) Fix for TimeZoneInfo.cs in the NET_2_1 profile:
http://monobin.com/__m73a1fc74
Ok to push?
Thanks,
Andres
--
diff --git a/mcs/mcs/decl.cs b/mcs/mcs/decl.cs
index dc790d8..cd59d49 100644
--- a/mcs/mcs/decl.cs
+++ b/mcs/mcs/decl.cs
@@ -625,7 +625,7 @@ namespace Mono.CSharp {
// Both are private and share same parent
//
if (al == AccessLevel.Private) {
- var decl = mc.Parent;
+ DeclSpace decl = mc.Parent;
do {
same_access_restrictions = TypeManager.IsEqual (decl.TypeBuilder, p_parent);
} while (!same_access_restrictions !decl.IsTopLevel (decl = decl.Parent) != null);
diff --git a/mcs/class/System.Core/System/TimeZoneInfo.cs b/mcs/class/System.Core/System/TimeZoneInfo.cs
index 632227e..3206430 100644
--- a/mcs/class/System.Core/System/TimeZoneInfo.cs
+++ b/mcs/class/System.Core/System/TimeZoneInfo.cs
@@ -133,7 +133,7 @@ namespace System
#endif
private AdjustmentRule [] adjustmentRules;
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
static RegistryKey timeZoneKey = null;
static bool timeZoneKeySet = false;
static RegistryKey TimeZoneKey {
@@ -309,7 +309,7 @@ namespace System
//FIXME: this method should check for cached values in systemTimeZones
if (id == null)
throw new ArgumentNullException (id);
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
if (TimeZoneKey != null)
{
RegistryKey key = TimeZoneKey.OpenSubKey (id, false);
@@ -350,7 +350,7 @@ namespace System
}
#endif
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
private static TimeZoneInfo FromRegistryKey (string id, RegistryKey key)
{
byte [] reg_tzi = (byte []) key.GetValue (TZI);
@@ -518,7 +518,7 @@ namespace System
{
if (systemTimeZones == null) {
systemTimeZones = new ListTimeZoneInfo ();
-#if !MONOTOUCH
+#if !MONOTOUCH !NET_2_1
if (TimeZoneKey != null) {
foreach (string id in TimeZoneKey.GetSubKeyNames ()) {
try {
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Preview 2.6.6
El 06/07/10 20:07, Andrew Jorgensen escribió: We have pushed a preview release of Mono (actually sort of a release). Find your files, installers, and repos here: http://mono.ximian.com/monobuild/preview/download-preview/ Major differences here are in the Mac and Windows GTK+ stacks, which have been updated to the latest stable releases. Also very important: We are dropping support for Mac OSX 10.4 (Tiger). This is due to problems compiling recent GTK+ on 10.4 as well a general feeling that most of our users are on 10.5 and above by now. This means that 2.6.4 is the last version for 10.4. Compiling your own newer versions of mono on 10.4 is still considered supported. And a note about version numbers: We are trying to be more disciplined about releasing only one release per version number. And since we are running beta versions of fine products like Mono Tools for Visual Studio those betas will occasionally eat up a version number. That is why you don't see 2.6.5 anywhere (except MonoTools 2.0 beta 1) and 2.6.6 (originally for MonoTools 2.0 beta 2) is a preview and the next official release will be 2.6.7. We hope to release 2.6.7 sometime this week, so please let us know http://www.mono-project.com/Bugs if you find any problems! Hello. We tried to build 2.6.6 today and we had the following compilation error: http://pastebin.com/qfVCP8UQ AFAIK mono from SVN needs a system mono to build, but a tarball should be able to bootstrap fine, right? This is the result of the compilation in a system where Mono is not installed. Any idea? Thanks, Andres -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode
El 10/05/10 21:06, tom hindle escribió: On Mon, 2010-05-10 at 19:28 +0100, Alan McGovern wrote: 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. sorry bad terminology... I meant syntactically c-style cast not an actual c-cast. I wasn't sure the C# name for it, maybe it called a prefix cast? I think the correct terminology is static cast vs dynamic cast because this is the way it's called in C++ (some time ago I liked to called the latter safe cast). That being said, I second Alan statement (or, question, to be more correct). And I think a dynamic cast shouldn't be used ever if you're not checking for null later (otherwise you're replacing the InvalidCastException chance with a NullReferenceException chance, which is much worse, uglier, and more incorrect). Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono trunk on FreeBSD
So the configure script is missing the check for Bash? Maybe we should add something like http://lists.freedesktop.org/archives/xorg/2008-March/033417.html Regards El 10/02/10 12:27, pablosantosl...@terra.es escribió: Up and running! :-) On 10/02/2010 10:28, Robert Jordan wrote: On 10.02.2010 00:29, pablosantosl...@terra.es wrote: Using gmake it went much further but... Creating the per profile list ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources ... ./../../tools/gensources.sh net_2_0_System.ServiceModel.Web.dll.sources ../../build/deps/net_2_0_System.ServiceModel.Web.dll.sources env: bash: No such file or directory You need bash. Look at /mcs/tools/gensources.sh. 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] Version bump
Ok to commit?: http://monobin.com/__m15732ad4 (People using the latest 2-4 branch should be able to run apps which require mono = 2.4.2 , such as MonoDevelop.) Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Building NHibernate trunk on Mono
Steve Strong wrote: (...) am I doing something wrong or is there some setting that I need to tweak, or is this a compiler bug? If the latter, where's the correct place to log it? Seems like the latter. Then go to http://www.mono-project.com/Bugs . Regards, Andres -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] [PATCH] Uri.LocalPath is not correct when path contains an '@' character
Can any System.Uri author/maintainer take a look at my patches in: https://bugzilla.novell.com/show_bug.cgi?id=533572 Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coding guidelines nitpicks
Miguel de Icaza wrote: Hello, 1) Casting: which one is correct? a) x = ((int)GetPropertyValue ()).ToString (); b) x = ((int) GetPropertyValue ()).ToString (); No strong opinion on the space after the cast. 2) Generics: which one is correct? a) x = new Listint (); b) x = new List int (); No space before the generic Would you mind updating the Wiki? Done. Any other opinions on casts? Andrés -- ___ 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.4 Preview Packages for Debian/Unstable (now also for AMD64)
Grzegorz Sobanski wrote: * Mirco Bauer mee...@debian.org [2009-05-22 21:36]: I still lack positive feedback btw! Do the packages work for you? As in does the upgrade work without any issues and does your software still work with the new packages? Ubuntu jaunty, no problems upgrading. All software seems to work fine. Although those packages were removed: libmono-corlib2.1-cil libmono-system2.1-cil mono-2.0-runtime mono-common mono-jit mono-smcs because they are only in 2.0.1 in repository. So no smcs is available in those pacages. Is it delayed for a later packages? I think that now smcs is built in the moonlight tree, so I believe it will evolve to a moonlight-devel-sdk package... Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Coding guidelines nitpicks
I've found two cases which are not mentioned in the Mono Coding Guidelines [1]: 1) Casting: which one is correct? a) x = ((int)GetPropertyValue ()).ToString (); b) x = ((int) GetPropertyValue ()).ToString (); 2) Generics: which one is correct? a) x = new Listint (); b) x = new List int (); Thanks, Andres [1] http://www.mono-project.com/Coding_Guidelines -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Andrés -- Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -92,3 +92,12 @@ [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] #endif + +#if NET_2_1 + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading + MOON_A11Y_INTERNAL_HACK + + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] +#endif ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. Index: class/corlib/Makefile === --- class/corlib/Makefile (revision 131333) +++ class/corlib/Makefile (working copy) @@ -25,6 +25,12 @@ corlib_flags = -unsafe -nostdlib LOCAL_MCS_FLAGS = -nowarn:612,618 -d:INSIDE_CORLIB +# this hack will be dropped once we get this working: +# http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +ifdef MOON_A11Y_INTERNAL_HACK + MCS_FLAGS += -define:MOON_A11Y_INTERNAL_HACK +endif + # System.IO/DirectoryInfoTest.cs needs Mono.Posix TEST_MCS_FLAGS = -debug+ -debug:full -nowarn:168,219,618,672 -unsafe -r:$(topdir)/class/lib/$(PROFILE)/Mono.Posix.dll -define:MONO_DATACONVERTER_STATIC_METHODS Index: class/corlib/Assembly/AssemblyInfo.cs === --- class/corlib/Assembly/AssemblyInfo.cs (revision 131333) +++ class/corlib/Assembly/AssemblyInfo.cs (working copy) @@ -91,4 +91,12 @@ [assembly: InternalsVisibleTo (System.Windows, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Net, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] [assembly: InternalsVisibleTo (System.Runtime.Serialization, PublicKey=00240480940006020024525341310004010001008D56C76F9E8649383049F383C44BE0EC204181822A6C31CF5EB7EF486944D032188EA1D3920763712CCB12D75FB77E9811149E6148E5D32FBAAB37611C1878DDC19E20EF135D0CB2CFF2BFEC3D115810C3D9069638FE4BE215DBF795861920E5AB6F7DB2E2CEEF136AC23D5DD2BF031700AEC232F6C6B1C785B4305C123B37AB)] + +// this hack will be dropped once we get this working: +// http://www.mono-project.com/Moonlight/SecurityStatus#Assembly_Loading +#if MOON_A11Y_INTERNAL_HACK + [assembly: InternalsVisibleTo (MoonAtkBridge, PublicKey=002404809400060200245253413100040100010071eb6c5575529cbf7244f7a6ea056284f9eae03bcff2cc132c9c490ab309eab0b56bce449df503d9c0a81e520585cdbe70e2fb90434bac04fa6222a80098b7a1a7b3af991a412324bb4325f6b865bb64ebf6d1c206d5732ddfbc70a7389ee53e0c246e3279741ad00503e49842e19bf37b198b402126cb3689c2ea6496a47cb4)] #endif + +#endif + ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] InternalsVisibleTo for MoonAtkBridge
Andrés G. Aragoneses wrote: Andrés G. Aragoneses wrote: This patch adds InternalsVisibleTo on the 2_1 profile, but using an env var for now until we assure that this is not a security threat. May I commit? Thanks. Patch updated. As already explained in moon-list, this is needed because glib-sharp and atk-sharp (which will now be merged in one assembly called MoonAtkBridge) access some Marshaling API which is not public anymore in the 2.1 profile. We're also looking at generating spec files for the monolinker to consume, in order for it to not strip the API we need, but this will come later. Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Diva
Abe Gillespie wrote: What ever happened to the Diva Video Editor project? It looked really promising. http://ubuntuforums.org/showthread.php?p=4582591 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-dev] [PATCH] LinkedList fix for Remove()
Hey, I attached a patch to this bug: https://bugzilla.novell.com/show_bug.cgi?id=481621 Could someone review? Thanks, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] Embedded Databases in .NET/Mono
Sienna wrote: WATYF wrote: I'm just looking into mono right now, so I don't really know anything about it, but I use an embedded database called VistaDB, which is written entirely in managed code, so I would think it would have a decent chance of working with mono. Just thought I'd throw that out there. Thanks for that suggestion. Unfortunately, it is a proprietary product (US$279/license), hence not compatible with my GPL'ed project. :-( I think I will have to actually provide different versions for .NET and Mono, and just use the different SQLite APIs then... Have you looked at DB4O? It's GPL, although it's not SQL ;) Andrés -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
Have you opened bugs on their bug tracking systems? If yes, this discussion should be placed there. If not, you should open them, and provide patches (maybe they didn't do it on purpose, and would be very grateful of someone trying to remove workarounds/hacks from their code). Regards, Andrés Lucas Meijer wrote: Hey, Our team has been busy porting some unit testing related frameworks to mono. porting is probably not the right word, it's mostly creating repro cases of mono bugs, reporting them, and waiting for them to be fixed. (Which happens fast by the way. Thanks!) So far we're looking at NInject, Moq and xUnit. There are / have been bugs in mono that prevent all of these projects from running. Most of them are valid mono bugs, nothing special here. In addition to real mono bugs, there's also the fact that many of these frameworks, use this commonly used trick: FieldInfo remoteStackTraceString = typeof(Exception).GetField(_remoteStackTraceString, BindingFlags.Instance | BindingFlags.NonPublic); This doesn't work on mono, since in mono the private field storing the stacktrace is called remote_stack_trace. This issue has been reported before as issue 425512 ( https://bugzilla.novell.com/show_bug.cgi?id=425512 ) One could argue, and the reason for the wontfix status of the issue does so, that these folks rely on undocumented internals. They shouldn't do it, and Mono shouldn't rename it's own private field to match that of the CLR. However, in the real world(tm), this prevents many projects from running on Mono unmodified. I would like to argue that in this specific case, where the (percieved by me, maybe incorrectly) amount of work for mono to change it's private fieldname to match that of the CLR, is a reasonable cost for enabling this quite frequently found in the wild trick of grabbing the internal stack trace of an exception. Maybe I'm underestimating the amount of work to rename the mono fieldname to match the clr one. If that's the case, please consider this message as another datapoint of three useful .net frameworks unable to run on mono unmodified. Here's a bit more info on the trick: Here is a bit more background on the trick: http://www.dotnetjunkies.com/WebLog/chris.taylor/archive/2004/03/03/8353.aspx Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Arguing for reconsideration of WONTFIX status of 425512
I'm talking about bugs opened *against* the frameworks, not against Mono, because it's not a Mono bug. Andrés Stifu wrote: Hm yeah, he gave the link to the bug report (in the message you quoted), and it's obvious it's not been closed by mistake. And it's not about removing workarounds or hacks from Mono, the hacks would be in the programs working around the difference between .NET and Mono. :| knocte wrote: Have you opened bugs on their bug tracking systems? If yes, this discussion should be placed there. If not, you should open them, and provide patches (maybe they didn't do it on purpose, and would be very grateful of someone trying to remove workarounds/hacks from their code). Regards, Andrés ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: Any word on a wiki? If we don't use the mono-project one, on http://wik.is/ you can create one easily, and it turns out it's using Deki (powered by Mono) ;) Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] gmcs and The Future
Scott Peterson wrote: It sounds like the general reaction is cautiously favorable. New language features would be nice, but they would require a commitment to maintenance. As I see it, whether we are willing to invest ongoing effort in a feature depends on the strength of the feature. A sufficiently killer feature will motivate its own upkeep. So what is (are) the killer feature(s)? I would be interested in organizing a forum for proposing and discussing language features. If for no other reason than as an excuse to talk about language design with smart people. This forum could start as an informal bake-off of ideas and brainstorms. If momentum builds behind a particular feature, we could formalize a proposal for its inclusion in the compiler. This allows the exploration of many ideas without the looming specter of feature-creep. If other people are interested in geeking out over language features, I suggest we get ourselves a little organized. We could hold forth right here, on this list, or we could create our own Google Group. Bugzilla is maybe another option. Maybe. Thoughts? I really like this proposal. (Although I see why the people is worried about maintaining the features, this may be worth it because it may be an interesting incubator of proposals to Anders H. for next versions, no?). I have a big pile of ideas that I was gathering in order to blog as a 'C# wishlist', so I could contribute them to this discussion. My suggestion is to use the wiki hosted in mono-project. We could create a page with an index with links to all ideas (sub-pages). Every idea could be voted up (+1) or down (-1) by the community, giving comments or feedback about the vote, maybe causing the idea to mutate. And after some time, the best ideas could be then created in Bugzilla and tracked there... Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 2.4 Preview - problem with reproducing a regression
Leszek Ciesielski wrote: On Wed, Feb 4, 2009 at 11:09 AM, Leszek Ciesielski skol...@gmail.com wrote: Hi, I'm getting a ERROR:mini-trampolines.c:122:mono_magic_trampoline: assertion failed: (vt) when running my NUnit tests on Mono 2.4 Preview 1 on Windows XP 32bit. However, there's not additional output to help pin down the problem, and the fact that the code that breaks uses an obfuscated external library (CoreLab.Oracle.dll) does not make things easier. What can I do to track down the regression (yes, this does work on 2.0, and on 2.4 Preview (and svn head) on Linux)? This no longer happens with Preview 2 :-) It's random: https://bugzilla.novell.com/show_bug.cgi?id=472654 Regards, Andrés -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing Mono 2.4 Preview 1...
Hey Thomas, This one is a regression because the workaround is to use the old RegExp engine: https://bugzilla.novell.com/show_bug.cgi?id=470827 Sorry, we haven't had time yet to isolate the issue into a testcase. But it's easy to reproduce with the steps mentioned in the bug. Regards, Andrés Thomas Wiest wrote: Hey Everyone, We've just released Mono 2.4 Preview 1 today! Please help us out by giving it a try with your applications. As always, you can get the preview/RC releases here: http://mono.ximian.com/monobuild/preview/download-preview/ Please report any bugs that you may find using our Bugs page, AND reply to this thread with the bug numbers so we can track them: http://www.mono-project.com/Bugs You can see the bugs we're tracking for Mono 2.4 here: https://bugzilla.novell.com/buglist.cgi?query_format=advancedclassification=Monotarget_milestone=2.4.xorder=bugs.bug_status%2Cbugs.bug_severity The earlier you file the bugs and reply to this message, the more likely your bugs will get fixed. Special attention is given to regressions, so if you can tell us a version of Mono where the bug worked and you add [Regression] to the beginning of the summary of the bug, then it is much more likely your bug will get fixed. Please help the Mono team to make 2.4 the best ever. Thanks! Mono QA ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-list] GAC and gmcs problem
k1Ll5w1tcH wrote: Sandy Armstrong wrote: On 01/27/2009 12:00 AM, k1Ll5w1tcH wrote: Hi Forgive me if this has been asked before... When compiling in mono 2.2 I get the following error: error CS0234: The type or namespace name `Data' does not exist in the namespace `System'. Are you missing an assembly reference? I've checked the GAC and the assembly is present. System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Are you compiling with -r:System.Data ? You may need to read the man page to learn how to use the compiler correctly. It is very similar to csc on Windows. Sandy ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list I'm currently not compiling with -r: When I compile with -r:System.Data.dll it seems like compilation is successful, but when I execute I get the following: cannot execute binary file How are you executing? You have to use the syntax mono MyBinary.exe. Regards, Andrés -- ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] how to get relative path
This would be a good inclusion to Mono.Rocks.
Andrés
Charlie Poole wrote:
Right, but beware that you have to do some post-processing
on the Codebase return value to get it to work as a
local path, especially if you want it to work on both
Linux and Windows. Here's what I use, in case it's helpful
to anyone:
public static string GetAssemblyPath(Assembly assembly)
{
string path = assembly.CodeBase;
Uri uri = new Uri(path);
// If it wasn't loaded locally, use the Location
if (!uri.IsFile)
return assembly.Location;
if (uri.IsUnc)
return path.Substring(Uri.UriSchemeFile.Length + 1);
int start = Uri.UriSchemeFile.Length +
Uri.SchemeDelimiter.Length;
if (path[start] == '/' path[start + 2] == ':')
++start;
return path.Substring(start);
}
Charlie
-Original Message-
From: Andrus [mailto:kobrule...@hot.ee]
Sent: Monday, January 12, 2009 12:33 PM
To: Charlie Poole; 'Chris Howie'; 'YyYo'
Cc: mono-list@lists.ximian.com
Subject: Re: [Mono-list] Re: how to get relative path
This will break if the program is loaded from the shadow copy cache.
You can use CodeBase instead which works with shadow assemblies also:
String strAppDir = Path.GetDirectoryName(
Assembly.GetExecutingAssembly().GetName().CodeBase);
Andrus.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
