Microsoft .NET and Mono integration - GSOC 2017

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Microsoft .NET and Mono integration - GSOC 2017

Michael Viveros
Hi,

I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:

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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.





_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Alexander Köplinger via Mono-devel-list
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 <[hidden email]> wrote:

Hi,

I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:

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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.




_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Alexander Köplinger via Mono-devel-list

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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

 

Hi,

 

I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:

 

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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.

 

 

 

 

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list

 

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list

 

 


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Michael Viveros
Thanks, those answers helped clarify things.


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

On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
 
Hi, 
 
I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:
 
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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.
 
 
 
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
 


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Alexander Köplinger via Mono-devel-list

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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <[hidden email]>
Cc: Ludovic Henry via Mono-devel-list <[hidden email]>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017

 

Thanks, those answers helped clarify things.

 

 

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

 

On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

 

Hi, 

 

I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:

 

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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.

 

 

 

 

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list

 

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list

 

 

 


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Michael Viveros
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 <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <[hidden email]>
Cc: Ludovic Henry via Mono-devel-list <[hidden email]>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017
 
Thanks, those answers helped clarify things. 
 
 
Could you give me some feedback when you get a chance?
 
On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
 
Hi, 
 
I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:
 
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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.
 
 
 
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
 
 


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Alexander Köplinger via Mono-devel-list
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <[hidden email]>
Cc: Ludovic Henry via Mono-devel-list <[hidden email]>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017
 
Thanks, those answers helped clarify things. 
 
 
Could you give me some feedback when you get a chance?
 
On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
 
Hi, 
 
I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:
 
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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.
 
 
 
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
 
 



_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Michael Viveros
Sounds good.

Just to clarify, the System.IO.FileStream project would still involve making changes to the CoreFX repo, right?

After looking at the repos, my understanding is the FileStream code and tests are in CoreFX.
CoreRT and CoreCLR just have references to the code from CoreFX.
So I think the project would involve adding FileStream support for different platforms to CoreFX (which would cascade to CoreRT and CoreCLR) and then when replacing Mono’s FileStream with the new one you would import the CoreRT FileStream.

On Mar 30, 2017, at 4:42 PM, Ludovic Henry <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <[hidden email]>
Cc: Ludovic Henry via Mono-devel-list <[hidden email]>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017
 
Thanks, those answers helped clarify things. 
 
 
Could you give me some feedback when you get a chance?
 
On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
 
Hi, 
 
I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:
 
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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.
 
 
 
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
 
 




_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Microsoft .NET and Mono integration - GSOC 2017

Michael Viveros
Here are my proposals:



Could you give me some feedback?
The application deadline is very soon.

On Mar 30, 2017, at 6:30 PM, Michael Viveros <[hidden email]> wrote:

Sounds good.

Just to clarify, the System.IO.FileStream project would still involve making changes to the CoreFX repo, right?

After looking at the repos, my understanding is the FileStream code and tests are in CoreFX.
CoreRT and CoreCLR just have references to the code from CoreFX.
So I think the project would involve adding FileStream support for different platforms to CoreFX (which would cascade to CoreRT and CoreCLR) and then when replacing Mono’s FileStream with the new one you would import the CoreRT FileStream.

On Mar 30, 2017, at 4:42 PM, Ludovic Henry <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 21:39
To: Ludovic Henry <[hidden email]>
Cc: Ludovic Henry via Mono-devel-list <[hidden email]>
Subject: Re: [Mono-dev] Microsoft .NET and Mono integration - GSOC 2017
 
Thanks, those answers helped clarify things. 
 
 
Could you give me some feedback when you get a chance?
 
On Mar 29, 2017, at 2:38 PM, Ludovic Henry <[hidden email]> 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 <[hidden email]>
Date: Wednesday, 29 March 2017 at 14:06
To: Ludovic Henry <[hidden email]>
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 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 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 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 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
 
Hi, 
 
I’m Michael Viveros and I’m interested in Mono’s GSOC projects 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:
 
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 and it looked quite massive, porting it over to CoreFX seems like it could be a lot of work.
 
 
 
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
 
 
 





_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Loading...