Re: [Mono-dev] List of cleanup candidates for Mono 4.0
Hello, On 2014年11月28日 02:19, Alexander Köplinger wrote: Hey, * gmcs/dmcs - they just redirect to mcs now and without the 2.0 etc profiles it doesn't make sense to still have them I like to keep them, to avoid breaking third party build scripts. Good point, however aren't they gonna break anyway when they rely on 2.0 SDK which is no longer there anymore? Maybe now is the time to make people aware they should update the scripts :) * aspnetwebstack (i.e. MVC+WebApi) - same reasons as for EF, open-source and on NuGet, should be used from there I am actually not sure about this one, is that really the case? The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, so I think it should be fine to remove. It might not work perfectly until the System.Web from referencesource is integrated, but the same applies to the existing (outdated) copy we ship currently. * Rx - I'm not really familiar with this one, but I think it's also on NuGet+open source This one I know contains patches that make it work on Mono. Without these, they wont work. So this might have to wait. Interesting. I had a look at the NuGet package and it ships a portable-net45 version, I always thought this was compatible with Mono? If not, we could maybe look at upstreaming the patches. Basically I agree that we could remove Rx. Yet some works need to be done. Rx imports can be taken in two different parts: desktop and mobile. For desktop, there is no difference (or almost no difference) in the sources. There could be some not-implemented paths in the dependencies, but IIRC I didn't #ifdef-ed out anything for that. For mobiles there are many changes to build and run. - Rx solution/project structure is quite complicated (most likely manually edited) to share several MSBuild targets fragments, as well as using some features that we don't (or maybe didn't) support. So we generate different project files for mobiles, from within mcs/class. (The same xbuild problem applies to desktop, but within mono we build from dll.sources and our own Makefiles just like other assemblies. And for NuGet packages we wouldn't worry about that anyways.) - We use NUnit for tests. Fortunately Rx tests use MSTest which were mostly compatible with NUnit syntax, we reuse that. Yet we needed several changes to the sources (e.g. using NUnit.Framework;). - And the changes are not committed but rather patched at build time (mcs/class/* has some C# script for that). - To make it build, we had to disable some parts by adding #if-s for iOS and Android, which are only for Xamarin. - I'm actually quite unsure how much of the existing Observables work fine on iOS (due to AOT limitation). For Android it worked almost perfectly. The resulting diffs were already too much at that state, so I didn't send them back to the original project. (For example, new tests could easily miss #if MONO use NUnit.Framework; and it won't just build.) Some changes would make sense to send back. IIRC there were some code paths that depend on WinRT or WPF that always exist on MS platforms but not on mono, and I #ifdef-ed out. All those changes are in rx-oss-v2.2 branch in mono/rx so that anyone can review. Anyways, basically we need patched version for mobiles. And some of those reside in mono tree, so before nuking them out they have to be rewritten to become independent of mono tree. Atsushi Eno -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/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] List of cleanup candidates for Mono 4.0
Let's remove my Commons.Xml.Relaxng. It is really isolated work. Atsushi Eno On 2014年11月28日 00:01, Alexander Köplinger wrote: Judging from the recent version bump in git to 3.99 it looks like the next release after 3.12 will be Mono 4.0. As this is a major release it'll allow us to remove some cruft that is no longer needed, so I thought I'd start a list of things I'd like to see removed: * net2.0/4.0 profiles - this is already in progress * gmcs/dmcs - they just redirect to mcs now and without the 2.0 etc profiles it doesn't make sense to still have them * EntityFramework - apart from the fact that we ship a horribly outdated version right now, I see no reason to include this hefty 5+MB DLL in Mono given that EF is open-source and available on NuGet * aspnetwebstack (i.e. MVC+WebApi) - same reasons as for EF, open-source and on NuGet, should be used from there * Rx - I'm not really familiar with this one, but I think it's also on NuGet+open source I'd love to hear your comments/thoughts on this :) -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/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] List of cleanup candidates for Mono 4.0
Before we go down this path. Mono 4.0 is not about a general call to clean things up. We are only cleaning up removing the must-haves. Please do not turn this into a threat to clean this up. That can be done independently and on its own schedule. Atsushi, I'll follow up later today on relaxng On Wednesday, December 10, 2014, Atsushi Eno atsushi...@veritas-vos-liberabit.com wrote: Let's remove my Commons.Xml.Relaxng. It is really isolated work. Atsushi Eno On 2014年11月28日 00:01, Alexander Köplinger wrote: Judging from the recent version bump in git to 3.99 it looks like the next release after 3.12 will be Mono 4.0. As this is a major release it'll allow us to remove some cruft that is no longer needed, so I thought I'd start a list of things I'd like to see removed: * net2.0/4.0 profiles - this is already in progress * gmcs/dmcs - they just redirect to mcs now and without the 2.0 etc profiles it doesn't make sense to still have them * EntityFramework - apart from the fact that we ship a horribly outdated version right now, I see no reason to include this hefty 5+MB DLL in Mono given that EF is open-source and available on NuGet * aspnetwebstack (i.e. MVC+WebApi) - same reasons as for EF, open-source and on NuGet, should be used from there * Rx - I'm not really familiar with this one, but I think it's also on NuGet+open source I'd love to hear your comments/thoughts on this :) -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/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] Serial Port Reading
I may be answering a simpler question than is asked, but in response to techi eth’s “Do anyone have successfully in reading of serial port with Linux over Mono?” we are using Mono on a Raspberry Pi running Debian GNU/Linux to read data coming in the serial port from an Arduino sensor as part of our IoT project “ConnectTheDots”. The code is on GitHub at http://connecthedots.io , and the Wiki contains instructions on how to set up the environment (from the Arduino to the Raspberry and then up to Azure in our case). Relatively simple, but if anyone has a better way to do this, would love to hear. Spyros Sakellariadis MS Open Technologies, Inc. Office +1(425) 707-7623callto:+14257077623 - Mobile +1(425) 444-1884callto:+14254441884 /ss From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of techi eth Sent: Monday, December 8, 2014 7:52 PM To: mono-devel Subject: Re: [Mono-dev] Serial Port Reading Thanks for input.. Is their any plan or update in Mono available in which event is working with serial port ? Thanks On Mon, Dec 8, 2014 at 4:50 PM, Ivo Smits i...@ufo-net.nlmailto:i...@ufo-net.nl wrote: Hello, I use the serial port class a lot, but always through the synchronous Read and Write methods. This works great. Looking at the mono source code for the SerialPort class, the events seem to exist, but are not called from anywhere, so they are probably not yet implemented (as is stated in the documentation, http://www.mono-project.com/archived/howtosystemioports/). SerialPort source code: https://github.com/mono/mono/blob/master/mcs/class/System/System.IO.Ports/SerialPort.cs -- Ivo techi eth schreef op 8-12-2014 11:24: Hi, I have bit struggle to get reading over Serial port with Mono on Linux. As of now I could not able to get Event working. Do anyone have successfully in reading of serial port with Linux over Mono ? Or Is this bug or not implemented part of Mono ? Thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/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] monolite URL
Hi, I'm trying to build monolite-111, but the URL is broken. Where can I find the latest monolite URL? Is there am archive with the different versions? Google isn't helping much. Resolving storage.bos.xamarin.com (storage.bos.xamarin.com)... 198.0.162.157 Connecting to storage.bos.xamarin.com (storage.bos.xamarin.com)|198.0.162.157|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2014-12-10 11:22:16 ERROR 404: Not Found. Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] I would like to contribute to mono however it seems things are in flux due to the integration of .NET Core and .NET Framework; where to start?
From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list- boun...@lists.ximian.com] On Behalf Of Bernie Schoch I guess I'm saying, where would I be most useful say with contributing 20+ hours a week in the near term (I'm between contract/jobs right now) Huh. I'm surprised nobody answered - If you haven't already, please be sure to see http://www.mono-project.com/community And in particular http://www.mono-project.com/community/contributing Amongst other things, the above tells you where the unit tests are, and bugzilla. It's probably best to develop on mac or linux. Personally I think, that since the latest ubuntu includes a recent-ish version of mono and monodevelop, that's the easiest way to get setup. (But I loves me some sourcetree, so I prefer to work on the mac instead, despite a little more effort required to build.) The source is on github. Fork pull request. Discuss stuff on this mailing list first, so as to avoid wasted effort. Thanks for offering to help. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monolite URL
On 10/12/2014 20:46, Gabriel Acevedo wrote: Thank you all. I built mono-3.8.0 yesterday, and I was able to get monolite-111 from the URL in Makefile without problems. I guess it changed today. Thanks again. The Windows Appveyor builds have been broken for some days as when mono_corlib_version (I think) changes, the monolite URL dependency changes (?), but often the appropriate download isn't available, and similarly sometimes old versions aren't available. It would be great not to have this external dependency for build. I started out trying to work-around this by removing the get-monolite-latest step from the Appveyor config in favour of use of EXTERNAL_MCS I couldn't quite seem to hit the right incantations though and ran out of time, but will revisit. Cheers, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monolite URL
Hey Alex, monolite is built and uploaded automatically by Wrench: https://wrench.mono-project.com/Wrench/ViewTable.aspx?host_id=21lane_id=4page=0limit=20, the issue I think was that the build was broken there so a new monolite didn't get uploaded, this is now fixed. The thing to keep in mind is that the corlib version inside monolite needs to match the runtime version or bootstrapping the classlib build won't work, so you can't just keep an old monolite and use it to build newer Mono (at least that's how I understood it). If you don't want to rely on monolite, another option is to just install a recent Mono release and use that for bootstrapping (e.g. right now the build still works with Mono 3.2). -- Alex Date: Thu, 11 Dec 2014 01:28:44 +0100 From: ajlen...@dynamicdevices.co.uk To: alex.koeplin...@outlook.com; bperry.volat...@gmail.com; gacev...@gmail.com CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] monolite URL On 10/12/2014 20:46, Gabriel Acevedo wrote: Thank you all. I built mono-3.8.0 yesterday, and I was able to get monolite-111 from the URL in Makefile without problems. I guess it changed today. Thanks again. The Windows Appveyor builds have been broken for some days as when mono_corlib_version (I think) changes, the monolite URL dependency changes (?), but often the appropriate download isn't available, and similarly sometimes old versions aren't available. It would be great not to have this external dependency for build. I started out trying to work-around this by removing the get-monolite-latest step from the Appveyor config in favour of use of EXTERNAL_MCS I couldn't quite seem to hit the right incantations though and ran out of time, but will revisit. Cheers, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] monolite URL
Hi Alex, On 11/12/2014 01:47, Alexander Köplinger wrote: Hey Alex, monolite is built and uploaded automatically by Wrench: https://wrench.mono-project.com/Wrench/ViewTable.aspx?host_id=21lane_id=4page=0limit=20, the issue I think was that the build was broken there so a new monolite didn't get uploaded, this is now fixed. Ah that explains a great deal. Thanks for explaining that to me. The thing to keep in mind is that the corlib version inside monolite needs to match the runtime version or bootstrapping the classlib build won't work, so you can't just keep an old monolite and use it to build newer Mono (at least that's how I understood it). This is also news to me and very helpful to know thanks. I am not disagreeing but I am surprised that we have to have an exactly matching build of monolite for this, whereas we don't if using a full-fat Mono. I wonder why that is? Because monolite is very barebones just for bootstrapping purposes ? If you don't want to rely on monolite, another option is to just install a recent Mono release and use that for bootstrapping (e.g. right now the build still works with Mono 3.2). Now I understand that the monolite package is auto-built I'd prefer to use that. Although I've had ongoing issues on and off for long time with missing old monolite archives and so forth. In that case I will leave Appveyor using get-monolite-latest for now, but the use of EXTERNAL_MCS I mentioned was, as you say, to attempt to use the pre-installed Mono image they have on their build worker VM images as standard. Thanks again, much appreciated. Alex -- Alex Date: Thu, 11 Dec 2014 01:28:44 +0100 From: ajlen...@dynamicdevices.co.uk To: alex.koeplin...@outlook.com; bperry.volat...@gmail.com; gacev...@gmail.com CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] monolite URL On 10/12/2014 20:46, Gabriel Acevedo wrote: Thank you all. I built mono-3.8.0 yesterday, and I was able to get monolite-111 from the URL in Makefile without problems. I guess it changed today. Thanks again. The Windows Appveyor builds have been broken for some days as when mono_corlib_version (I think) changes, the monolite URL dependency changes (?), but often the appropriate download isn't available, and similarly sometimes old versions aren't available. It would be great not to have this external dependency for build. I started out trying to work-around this by removing the get-monolite-latest step from the Appveyor config in favour of use of EXTERNAL_MCS I couldn't quite seem to hit the right incantations though and ran out of time, but will revisit. Cheers, Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
