[Mono-dev] Microsoft .NET and Mono integration - GSOC 2017

Thu Mar 30 20:42:22 UTC 2017

1. If you can submit 2 proposals, then that's perfectly fine by me.

2. Yes you are perfectly right! The steps are going to be the same as you noted, and the end goal will also be to remove our implementation of System.Diagnostics.Process and replace it with the one from CoreFX.

On 30 Mar 2017, at 16:23, Michael Viveros <michaelviveros at gmail.com<mailto:michaelviveros at gmail.com>> wrote:

No problem, thanks for letting me know.

1. Perhaps it’s best for me to submit 2 proposals?
I can still have my current one for System.IO.FileStream (and update it from CoreFX to CoreRT) and then make a new one for System.Diagnostics.Process.

2. Would importing System.Diagnostics.Process involve the same steps as importing System.IO.FileStream?
Ex. adding Process support to corefx for platforms supported by Mono (Haiku, Android, iOS), replacing Mono’s Process with the CoreFX one and removing old dependencies like System.Mono.IO and w32process, …

It looks like CoreFX implements Process in the same way it implemented FileStream with different classes for different platforms like Process.Windows.cs and Process.Unix.cs.
It also looks like Mono implements Process in the same way as it implemented FileStream with different internal calls for different platforms like w32process-win32.c and w32process-unix.c.

On Mar 30, 2017, at 2:00 PM, Ludovic Henry <luhenry at microsoft.com<mailto:luhenry at microsoft.com>> wrote:

Hi Michael,

Small change of plan, I just noticed there has been another student who wanted to work on importing System.IO.FileStream since some time before you. I am very sorry about this late notice, but I can definitely work with you to find another class to import, with for example System.Diagnostics.Process. We are having a lot of issues with this class, so getting it from CoreFX would tremendously help us.

If you decide you still want to work on the System.IO.FileStream, the corefx/corert/coreclr team decided to move System.IO.FileStream out of corefx and into corert. That shouldn’t change much to the actual import, it would just come from a different repo. So, if you still want to work on this project, I would advise you to consider compiling corert successfully.

Sorry about the late change, but, again, that wouldn’t change much to the actual work to be done, as well as the constraints and the expected result. The only change is the class and its dependencies.

Thank you!
Ludovic

From: Michael Viveros <michaelviveros at gmail.com<mailto:michaelviveros at gmail.com>>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <luhenry at microsoft.com<mailto:luhenry at microsoft.com>>
Cc: Ludovic Henry via Mono-devel-list <mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017

Thanks, those answers helped clarify things.

I just shared my proposal, https://docs.google.com/document/d/1It5LfQxi3Xh0tcvaenOdnrhOZBqzS8OHt_gSmWK0SSI/edit?usp=sharing

Could you give me some feedback when you get a chance?

On Mar 29, 2017, at 2:38 PM, Ludovic Henry <luhenry at microsoft.com<mailto:luhenry at microsoft.com>> wrote:

Hi Michael,

1.       Yes those FileStream.Unix.cs and FileStream.Windows.cs are how corefx makes it work across these 2 platforms. We would maybe need to add a FileStream.Haiku.cs for Haiku, but that’s not necessarily needed if the native API is the same as Unix. That is something we do not know yet and that we would need to find out.

2.       First, we would need to add support to Haiku, as it’s an easier platform to test on (compared to Android or iOS), and then explore adding support for Android and iOS.

3.       Yes you would need to setup some VMs, but that’s something we will work on together.

4.       The goal is to replace mono’s implementation of System.IO.FileStream with corefx’s one.
MonoIO and w32file are dependencies of mono’s FileStream, so if we remove mono’s FileStream we can also remove MonoIO and w32file.

I hope I am answering your questions, so if you have any others, please for free to ask.

Thank you,
Ludovic

From: Michael Viveros <michaelviveros at gmail.com<mailto:michaelviveros at gmail.com>>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <luhenry at microsoft.com<mailto:luhenry at microsoft.com>>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017

Yes, I’m definitely interested in the System.IO.Filestream project.
Sorry for not following up earlier, I was working on my other GSOC proposals but now I plan on working on this one.

Below are some more questions I have so that I can make my proposal as clear and detailed as possible.
You might not be able to answer to some of them since perhaps they can only be figured out after starting the project.

1. Would adding support to CoreFX for different platforms supported by Mono just involve adding different FileSteam classes to CoreFX for those platforms?
I was looking at the System.IO part<https://github.com/dotnet/corefx/tree/e927c26d055acc9fbd841fe53366488da237d299/src/System.IO.FileSystem/src/System/IO> of the CoreFX repo and it has different FileStream classes like FileStream.Unix.cs and FileStream.Win32.cs
Obviously if some of the existing CoreFX FileStream classes work with some of the other platforms then no changes would have to be made

2. What platforms specifically need to be added to CoreFX?
You mentioned Android, iOS and Haiku but I didn’t see Haiku or Android on the Mono Supported Platforms page<http://www.mono-project.com/docs/about-mono/supported-platforms/> so I’m a bit confused.

3. How can I test if new FileStream classes for different platforms work? Do you have VMs setup running different platforms I could use?
I found some FileStream tests<https://github.com/dotnet/corefx/tree/e927c26d055acc9fbd841fe53366488da237d299/src/System.IO.FileSystem/tests/FileStream> in the CoreFX repo which I’m assuming I would use but manually installing all those OSs and testing on my machine seems like it might be a lot of work.

4. After adding support to CoreFX for FileStreams for different platforms, would the Mono implementation of System.IO.FileStream just be replaced by the CoreFX one?
You mentioned in an earlier email<http://lists.dot.net/pipermail/mono-devel-list/2017-March/044200.html> that "The end goal is to get rid of most of our mono-specific code both in managed and in the runtime (System.IO.MonoIO, the w32process” files so I’m assuming you can’t simply replace the Mono FileStream implementation with the CoreFX one since it sounds like this project will involve touching other Mono files like System.IO.MonoIO and the w32process files.
But then I don’t understand the point of adding support to CoreFX for different platforms if you’re not going to use the CoreFX FileStream implementation in Mono.

On Mar 29, 2017, at 11:47 AM, Ludovic Henry <luhenry at microsoft.com<mailto:luhenry at microsoft.com>> wrote:

Hi Michael,

Are you still interested in participating to the GSoC on any of these projects? We would love for you to work on the System.IO.FileStream project as it would be of great help for us! :)

Thank you!
Ludovic

On 23 Mar 2017, at 10:20, Ludovic Henry via Mono-devel-list <mono-devel-list at lists.dot.net<mailto:mono-devel-list at lists.dot.net>> wrote:

Hi Michael,

Thank you for your interest in these projects! :)

To answer your questions:

1. Yes, passing tests would be the first goal, and even if some of these tests are 12 years old, they are still very relevant today.

2. Corefx only support a subset of the platforms we support (corefx supports windows, linux, OSX, freebsd and netbsd). So adding support for the different platforms supported by Mono (Android, iOS, Haiku, etc.) means that we need to ensure that the corefx code works just as well on these new platforms, than it does on the platforms that it already supports. As it already support the 3 main platforms (Windows, Linux and BSD - for OSX, FreeBSD and NetBSD), porting it to support the other platforms wouldn't entail a lot of changes, as it would mostly be adaptations to platform-specific behaviours and bugs.

If you have any more questions, please feel free to ask.

Thank you very much,

Ludovic

On 19 Mar 2017, at 10:37, Michael Viveros <michaelviveros at gmail.com<mailto:michaelviveros at gmail.com>> wrote:

Hi,

I’m Michael Viveros and I’m interested in Mono’s GSOC projects<http://www.mono-project.com/community/google-summer-of-code/projects/#microsoft-net-and-mono-integration> related to Microsoft .NET and Mono integration (mentor Ludovic Henry):
Import ThreadPool from CoreRT
Import System.IO.FileStream from CoreFX
Import Process from CoreFX

I have some questions about the project, some of which are follow-up questions to this thread from Wed. March 15th:
http://lists.dot.net/pipermail/mono-devel-list/2017-March/044200.html

1. Would 1 goal of these projects be getting the tests to pass?
For example, getting the tests to pass in https://github.com/mono/mono/tree/master/mcs/class/corlib/Test/System.IO for the System.IO.FileStream project.
Some of the tests there are over 12 years old so I’m not sure if they’re still relevant.

2. What would adding support to CoreFX for different platforms supported by Mono (Android, iOS, Haiku, etc.) entail?
I briefly looked over the mono code for w32file-unix.c<https://github.com/mono/mono/blob/8b671a8c31368e2046aa9546c46f01b99c5c8008/mono/metadata/w32file-unix.c> and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.dot.net<mailto:Mono-devel-list at lists.dot.net>
http://lists.dot.net/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.dot.net<mailto:Mono-devel-list at lists.dot.net>
http://lists.dot.net/mailman/listinfo/mono-devel-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170330/ce1d41f6/attachment-0001.html>