Re: Interest in GSoC .NET and Mono integration

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

Re: Interest in GSoC .NET and Mono integration

Alexander Köplinger via Mono-devel-list
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant


_______________________________________________
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: Interest in GSoC .NET and Mono integration

Nishant Gupta-2
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant



_______________________________________________
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: Interest in GSoC .NET and Mono integration

Nishant Gupta-2
Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant




_______________________________________________
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: Interest in GSoC .NET and Mono integration

Alexander Köplinger via Mono-devel-list
Hi Nishant,

Yes, the end goal is to remove the Mono-specific FileStream, and replace it with the one in corefx. We wouldn't use a nuget package, but would take it directly from the sources of corefx: we have corefx as a git submodule in mono, so we can cherry-pick any source file we need/want, and compile them as part of our build process.

The initial MonoIO purpose was to have a abstraction layer that is usable from managed, and that can be used from FileStream, or anything else that needs it. The managed (C#) methods are very close to the Win32 API, which we have to emulate in the runtime on Unix systems. It serves a very specific purpose, but we would like to replace it with how it is done in corefx (not meaning that we want to modify it, but more that we want to get rid of it)

Mono does have a fork of corefx (https://github.com/mono/corefx), but we try to keep it as close as possible from upstream by regularly upstreaming what we can, and downstreaming every week or two. I am currently working on trying to integrate mono more to upstream corefx, so it's easier for both projects to evolve side by side.

I am on the IRC channel now, so if you want to ask any question feel free to ask them there, but I like email too, because the information I give you is accessible more broadly and is more persistent.

Thank you,
Ludovic


On 21 Mar 2017, at 17:05, Nishant Gupta <[hidden email]> wrote:

Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant





_______________________________________________
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: Interest in GSoC .NET and Mono integration

Alexander Köplinger via Mono-devel-list
Small update, IRC doesn't work from our office in Boston, so I will be using Gitter.

On 22 Mar 2017, at 10:06, Ludovic Henry <[hidden email]> wrote:

Hi Nishant,

Yes, the end goal is to remove the Mono-specific FileStream, and replace it with the one in corefx. We wouldn't use a nuget package, but would take it directly from the sources of corefx: we have corefx as a git submodule in mono, so we can cherry-pick any source file we need/want, and compile them as part of our build process.

The initial MonoIO purpose was to have a abstraction layer that is usable from managed, and that can be used from FileStream, or anything else that needs it. The managed (C#) methods are very close to the Win32 API, which we have to emulate in the runtime on Unix systems. It serves a very specific purpose, but we would like to replace it with how it is done in corefx (not meaning that we want to modify it, but more that we want to get rid of it)

Mono does have a fork of corefx (https://github.com/mono/corefx), but we try to keep it as close as possible from upstream by regularly upstreaming what we can, and downstreaming every week or two. I am currently working on trying to integrate mono more to upstream corefx, so it's easier for both projects to evolve side by side.

I am on the IRC channel now, so if you want to ask any question feel free to ask them there, but I like email too, because the information I give you is accessible more broadly and is more persistent.

Thank you,
Ludovic


On 21 Mar 2017, at 17:05, Nishant Gupta <[hidden email]> wrote:

Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant






_______________________________________________
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: Interest in GSoC .NET and Mono integration

Nishant Gupta-2
Great, I have pinged you on Gitter..I will make sure to be online during office hours tomorrow to catch you there.

Until then, I am going to try and build the mono and corefx repositories on my machine. To get my hands dirty, are there some simple bugs related to FileStream (doesn't necessarily have to be related) that I could start looking at? It will help me get familiar with the code base.

Also, you mentioned that, we would try and replace MonoIO with what CoreFX does for  providing the layer of abstraction to talk to OS - could you provide me more info about where I could look into what CoreFX does exactly?

Thanks,
Nishant



On Wed, Mar 22, 2017 at 10:02 AM, Ludovic Henry <[hidden email]> wrote:
Small update, IRC doesn't work from our office in Boston, so I will be using Gitter.

On 22 Mar 2017, at 10:06, Ludovic Henry <[hidden email]> wrote:

Hi Nishant,

Yes, the end goal is to remove the Mono-specific FileStream, and replace it with the one in corefx. We wouldn't use a nuget package, but would take it directly from the sources of corefx: we have corefx as a git submodule in mono, so we can cherry-pick any source file we need/want, and compile them as part of our build process.

The initial MonoIO purpose was to have a abstraction layer that is usable from managed, and that can be used from FileStream, or anything else that needs it. The managed (C#) methods are very close to the Win32 API, which we have to emulate in the runtime on Unix systems. It serves a very specific purpose, but we would like to replace it with how it is done in corefx (not meaning that we want to modify it, but more that we want to get rid of it)

Mono does have a fork of corefx (https://github.com/mono/corefx), but we try to keep it as close as possible from upstream by regularly upstreaming what we can, and downstreaming every week or two. I am currently working on trying to integrate mono more to upstream corefx, so it's easier for both projects to evolve side by side.

I am on the IRC channel now, so if you want to ask any question feel free to ask them there, but I like email too, because the information I give you is accessible more broadly and is more persistent.

Thank you,
Ludovic


On 21 Mar 2017, at 17:05, Nishant Gupta <[hidden email]> wrote:

Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant







_______________________________________________
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: Interest in GSoC .NET and Mono integration

Alexander Köplinger via Mono-devel-list
To get your hands dirty, I don't think we have any outstanding bug. But the feature you could work on would be to replace the use of the ThreadPool for async operations by the use of the TPL.

The threadpool is used implicitly via `ReadDelegate.BeginInvoke` and `WriteDelegate.BeginInvoke`, and I would like you to explore replacing that by using the TPL (System.Threading.Tasks). You can then create and use a custom TaskScheduler to avoid the use of the ThreadPoolTaskScheduler (which would end up using the threadpool, which we want to avoid).

Also, you should make sure you can compile mono and corefx.

On 22 Mar 2017, at 21:45, Nishant Gupta <[hidden email]> wrote:

Great, I have pinged you on Gitter..I will make sure to be online during office hours tomorrow to catch you there.

Until then, I am going to try and build the mono and corefx repositories on my machine. To get my hands dirty, are there some simple bugs related to FileStream (doesn't necessarily have to be related) that I could start looking at? It will help me get familiar with the code base.

Also, you mentioned that, we would try and replace MonoIO with what CoreFX does for  providing the layer of abstraction to talk to OS - could you provide me more info about where I could look into what CoreFX does exactly?

Thanks,
Nishant



On Wed, Mar 22, 2017 at 10:02 AM, Ludovic Henry <[hidden email]> wrote:
Small update, IRC doesn't work from our office in Boston, so I will be using Gitter.

On 22 Mar 2017, at 10:06, Ludovic Henry <[hidden email]> wrote:

Hi Nishant,

Yes, the end goal is to remove the Mono-specific FileStream, and replace it with the one in corefx. We wouldn't use a nuget package, but would take it directly from the sources of corefx: we have corefx as a git submodule in mono, so we can cherry-pick any source file we need/want, and compile them as part of our build process.

The initial MonoIO purpose was to have a abstraction layer that is usable from managed, and that can be used from FileStream, or anything else that needs it. The managed (C#) methods are very close to the Win32 API, which we have to emulate in the runtime on Unix systems. It serves a very specific purpose, but we would like to replace it with how it is done in corefx (not meaning that we want to modify it, but more that we want to get rid of it)

Mono does have a fork of corefx (https://github.com/mono/corefx), but we try to keep it as close as possible from upstream by regularly upstreaming what we can, and downstreaming every week or two. I am currently working on trying to integrate mono more to upstream corefx, so it's easier for both projects to evolve side by side.

I am on the IRC channel now, so if you want to ask any question feel free to ask them there, but I like email too, because the information I give you is accessible more broadly and is more persistent.

Thank you,
Ludovic


On 21 Mar 2017, at 17:05, Nishant Gupta <[hidden email]> wrote:

Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant








_______________________________________________
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: Interest in GSoC .NET and Mono integration

Alexander Köplinger via Mono-devel-list
Hi Nishant,

Did you have a chance to build mono and corefx? Also, do you need any help to fill up your application on https://summerofcode.withgoogle.com/dashboard/proposals/shared/ ?

We are very much looking forward for your application! :)

Thank you!
Ludovic

On 23 Mar 2017, at 16:08, Ludovic Henry <[hidden email]> wrote:

To get your hands dirty, I don't think we have any outstanding bug. But the feature you could work on would be to replace the use of the ThreadPool for async operations by the use of the TPL.

The threadpool is used implicitly via `ReadDelegate.BeginInvoke` and `WriteDelegate.BeginInvoke`, and I would like you to explore replacing that by using the TPL (System.Threading.Tasks). You can then create and use a custom TaskScheduler to avoid the use of the ThreadPoolTaskScheduler (which would end up using the threadpool, which we want to avoid).

Also, you should make sure you can compile mono and corefx.

On 22 Mar 2017, at 21:45, Nishant Gupta <[hidden email]> wrote:

Great, I have pinged you on Gitter..I will make sure to be online during office hours tomorrow to catch you there.

Until then, I am going to try and build the mono and corefx repositories on my machine. To get my hands dirty, are there some simple bugs related to FileStream (doesn't necessarily have to be related) that I could start looking at? It will help me get familiar with the code base.

Also, you mentioned that, we would try and replace MonoIO with what CoreFX does for  providing the layer of abstraction to talk to OS - could you provide me more info about where I could look into what CoreFX does exactly?

Thanks,
Nishant



On Wed, Mar 22, 2017 at 10:02 AM, Ludovic Henry <[hidden email]> wrote:
Small update, IRC doesn't work from our office in Boston, so I will be using Gitter.

On 22 Mar 2017, at 10:06, Ludovic Henry <[hidden email]> wrote:

Hi Nishant,

Yes, the end goal is to remove the Mono-specific FileStream, and replace it with the one in corefx. We wouldn't use a nuget package, but would take it directly from the sources of corefx: we have corefx as a git submodule in mono, so we can cherry-pick any source file we need/want, and compile them as part of our build process.

The initial MonoIO purpose was to have a abstraction layer that is usable from managed, and that can be used from FileStream, or anything else that needs it. The managed (C#) methods are very close to the Win32 API, which we have to emulate in the runtime on Unix systems. It serves a very specific purpose, but we would like to replace it with how it is done in corefx (not meaning that we want to modify it, but more that we want to get rid of it)

Mono does have a fork of corefx (https://github.com/mono/corefx), but we try to keep it as close as possible from upstream by regularly upstreaming what we can, and downstreaming every week or two. I am currently working on trying to integrate mono more to upstream corefx, so it's easier for both projects to evolve side by side.

I am on the IRC channel now, so if you want to ask any question feel free to ask them there, but I like email too, because the information I give you is accessible more broadly and is more persistent.

Thank you,
Ludovic


On 21 Mar 2017, at 17:05, Nishant Gupta <[hidden email]> wrote:

Is there a faster way of communication than via email? 
@Ludovic - is there any specific time that you hang out on one of the mIRC channels, i would love to talk to you there for sometime to ask all my questions at once.

Thanks,
Nishant Gupta

On Sun, Mar 19, 2017 at 12:23 PM, Nishant Gupta <[hidden email]> wrote:
Hi Ludovic,

Thanks for your reply. So is my understanding correct that the end aim is to remove the Mono-specific FileStream type and replace it with the FileStream class defined in CoreFx (perhaps imported via a nuget package reference) ?

What is the purpose of MonoIO ? And is there an equivalent in CoreFX?

Does mono use a fork of the CoreFX code? Or is it imported directly via nuget?

I think I want to go ahead with the FileStream project and would like to come up with a detailed plan of action that I can put in my proposal.

Thanks,
Rohit

On Wed, Mar 15, 2017 at 9:02 AM, Ludovic Henry <[hidden email]> wrote:
Hi Nishant,

Our current implementation of System.IO.FileStream lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs. It has strong dependencies on System.IO.MonoIO which lives at https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs and which depends on the runtime for the different icalls implemented in https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename%3Aw32file&type=Code.

Out current implementation of System.Diagnostics.Process lives at https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/Process.cs. The runtime implements the different icalls in https://github.com/mono/mono/search?p=1&q=filename%3Aw32process&type=Code&utf8=%E2%9C%93.

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 and the w32file files), but we would first need to add support to CoreFX for the different platforms that we support that they don't (Android, iOS, Haiku, etc.)

I would be the one to look over these 2 projects, so if you have any question, I would be very happy to answer them.

Thank you,
Ludovic

From: Nishant Gupta [[hidden email]] 
Sent: Tuesday, March 14, 2017 12:22 AM
To: Xamarin FW Summer of Code <[hidden email]>; [hidden email]
Subject: Re: Interest in GSoC .NET and Mono integration
 
Hi,
 
Any guidance here would be appreciated!
 
Thanks,
Rohit
 
On Sun, Mar 12, 2017 at 5:39 PM, Nishant Gupta <[hidden email]> wrote:
Hi,
I am a grad student in India and I came across this board from the GSoC idea page for Mono. I would love to help in the Microsoft .NET and Mono integration initiative, as I have plenty of experience in C# and .NET Framework/.NET Core along with other tools like NuGet. Please let me know of a good way to get started!
 
I was hoping to get in touch with Ludovic Henry and talk to him about a plan of action. The projects that catch my eye include:
 
1) Import System.IO.FileStream from CoreFx
2) Import Process from CoreFx
 
I have a few boiling questions that i would love if someone could help answer for me so I can start working on writing the proposal.
 
It would also be great, if to get familiar in this area, someone could point me to a few bugs which I can fix before GSoC to get my hands dirty.
 
 
Thanks,
Nishant









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