[Mono-dev] Interest in GSoC .NET and Mono integration

[Nishant Gupta]

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 <luhenry at microsoft.com>
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 <luhenry at microsoft.com> 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 <nishantg2108 at gmail.com> 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 <nishantg2108 at gmail.com>
> 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 <luhenry at microsoft.com>
>> 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/mon
>>> o/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=file
>>> name%3Aw32file&type=Code
>>> <https://github.com/mono/mono/search?utf8=%E2%9C%93&q=filename:w32file&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%3Aw32p
>>> rocess&type=Code&utf8=%E2%9C%93
>>> <https://github.com/mono/mono/search?p=1&q=filename:w32process&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 [mailto:nishantg2108 at gmail.com
>>> <nishantg2108 at gmail.com>]
>>> *Sent:* Tuesday, March 14, 2017 12:22 AM
>>> *To:* Xamarin FW Summer of Code <xafwsoco at microsoft.com>; mono
>>> -devel-list at lists.dot.net
>>> *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 <nishantg2108 at gmail.com>
>>> 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
>>>
>>>
>>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170322/20a4a7f4/attachment-0001.html>