Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again
> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Daniel Morgan
>
> I see the latest version of Mono's Windows installer is 3.2.3. Can this be
> used
> to build the latest from git?
>
> I see a link for binaries for 3.4.0, but they are not official binaries.
>
> I am going to try build Mono on Windows using Cygwin. Not sure how web
> the visual studio stuff works.
Search this list for Appveyor. I know Alex Lennon was putting some effort in,
and I think got to the point of having a reliable automated build process - but
check with folks to be sure (I haven't followed very closely and I could be
wrong). At some point, Miguel pulled Duncan Mak into the conversation, so I
would guess maybe Duncan is involved with distributing windows builds... All
of this occurred within the last ~ 1 month or so.
> Also, what is the best Linux distro to build mono? OpenSUSE? Debian,
> Ubuntu? It has been awhile for me. Not starting a flame war here - just
> wanting the easiest route to get the dependencies on linux in order to build
> the latest mono from git.
On basically any system I've seen so far, building is easy. The basic process
of "./configure && make && make install" usually works. If it doesn't, then
add "make get-monolite-latest" before "make EXTERNAL_MCS=..." as below...
On every redhat-based or debian-based (or even mac) system I've ever used, one
of these two variants has always worked.
OSX
export BUILDDIR=/Users/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no
&& make -j $NUMPROC && make install && echo "" && echo "Done" && echo "")
Ubuntu 14.04
export BUILDDIR=/home/whatever/Projects/mono-build
export NUMPROC=3 ; time ( test -d $BUILDDIR && rm -rf $BUILDDIR ; mkdir -p
$BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no
&& make get-monolite-latest && make -j $NUMPROC
EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe" && make install && echo
"" && echo "Done" && echo "")
> And I want to play with MonoDevelop too, but Mono comes first.
Building monodevelop is more difficult. I've never succeeded - but I never
spent a boat load of time on it either. You can install MonoDevelop on the
mac, no problem (they distribute a pre-built binary). Also, the latest ubuntu
includes a recent build of monodevelop. I personally use VS on windows, XS on
mac, and MD on ubuntu 14.04 desktop x86_64.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
Ah that one I agree can go away. On Nov 29, 2014 12:17 PM, "Alexander Köplinger" wrote: > This has nothing to do with .NET Core, in the case of npgsql we only annoy > people by shipping an ancient version with Mono, like a few people > pointed out on this thread. > E.g. a core contributor asking us to remove it from Mono: > https://bugzilla.xamarin.com/show_bug.cgi?id=23119 > > -- Alex > > -- > From: mig...@xamarin.com > Date: Sat, 29 Nov 2014 12:04:12 -0500 > Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 > To: alex.koeplin...@outlook.com > CC: monodanm...@yahoo.com; mono-devel-list@lists.ximian.com > > Hey, > > We want to implement the same .NET Core interface when it becomes > available and to support that scenario. > > But until that world exists and all the components are cross platform, we > are just going to be annoying a bunch of people. > > On Sat, Nov 29, 2014 at 11:05 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > Yeah, I think having something in-box with Mono just for convenience makes > less sense these days given that we have NuGet. > I'd actually advocate removing everything from the Mono distribution that > does not also ship with the .NET BCL (except maybe things like Mono.Simd > which requires specific runtime features). > The world is moving towards a more modular approach and (just like .NET > Core) we should leverage NuGet where we can. > > -- Alex > > -- > Date: Sat, 29 Nov 2014 15:50:05 + > From: monodanm...@yahoo.com > To: monofo...@my2cents.co.uk; alex.koeplin...@outlook.com > CC: mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 > > I agree with removing Npgsql from Mono. Or either convince someone to > commit the latest version of Npgsql to mono. It would have to build with > mono's build system though. Francisco? > > The main reason it was included in mono was so you could have an > out-of-the-box experience with mono connecting to Postgres. > > > On Thursday, November 27, 2014 6:07 PM, Martin Thwaites < > monofo...@my2cents.co.uk> wrote: > > > > > On 27 November 2014 at 18:19, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > > > * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source > and on NuGet, should be used from there > > > I am actually not sure about this one, is that really the case? > > > The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, > so I think it should be fine to remove. It might not work perfectly until > the System.Web from referencesource is integrated, but the same applies to > the existing (outdated) copy we ship currently. > > > > This is something I've been working on. MVC 5.2.2 (the one available on > NuGet) just doesn't work at the moment due to this pull > https://github.com/mono/mono/pull/1349 being required (and I haven't had > chance to fix the things that Miguel wanted). > > In addition, the old notes on getting MVC 3 working on mono, said to > remove the MS supplied versions of the dlls IIRC, so these would stop > working on upgrade (and replacing with the nuget ones for MVC3 probably > won't work). > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Building Mono on Windows - And Having a Windows Installer again
I see the latest version of Mono's Windows installer is 3.2.3. Can this be used to build the latest from git? I see a link for binaries for 3.4.0, but they are not official binaries. I am going to try build Mono on Windows using Cygwin. Not sure how web the visual studio stuff works. If I am successful, I will put up somewhere an un-official Windows Installer for Mono so others can help. The nice thing about the Combined Mono and Gtk# Installer for Windows is that you have something out-of-the box you can create a GUI app with Mono. Very nice to have an C# gui app that can run on Windows and Linux. Also, what is the best Linux distro to build mono? OpenSUSE? Debian, Ubuntu? It has been awhile for me. Not starting a flame war here - just wanting the easiest route to get the dependencies on linux in order to build the latest mono from git. And I want to play with MonoDevelop too, but Mono comes first. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
This has nothing to do with .NET Core, in the case of npgsql we only annoy people by shipping an ancient version with Mono, like a few people pointed out on this thread. E.g. a core contributor asking us to remove it from Mono: https://bugzilla.xamarin.com/show_bug.cgi?id=23119 -- Alex From: mig...@xamarin.com Date: Sat, 29 Nov 2014 12:04:12 -0500 Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 To: alex.koeplin...@outlook.com CC: monodanm...@yahoo.com; mono-devel-list@lists.ximian.com Hey, We want to implement the same .NET Core interface when it becomes available and to support that scenario. But until that world exists and all the components are cross platform, we are just going to be annoying a bunch of people. On Sat, Nov 29, 2014 at 11:05 AM, Alexander Köplinger wrote: Yeah, I think having something in-box with Mono just for convenience makes less sense these days given that we have NuGet. I'd actually advocate removing everything from the Mono distribution that does not also ship with the .NET BCL (except maybe things like Mono.Simd which requires specific runtime features). The world is moving towards a more modular approach and (just like .NET Core) we should leverage NuGet where we can. -- Alex Date: Sat, 29 Nov 2014 15:50:05 + From: monodanm...@yahoo.com To: monofo...@my2cents.co.uk; alex.koeplin...@outlook.com CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 I agree with removing Npgsql from Mono. Or either convince someone to commit the latest version of Npgsql to mono. It would have to build with mono's build system though. Francisco? The main reason it was included in mono was so you could have an out-of-the-box experience with mono connecting to Postgres. On Thursday, November 27, 2014 6:07 PM, Martin Thwaites wrote: On 27 November 2014 at 18:19, Alexander Köplinger wrote: * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source and on NuGet, should be used from thereI am actually not sure about this one, is that really the case? The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, so I think it should be fine to remove. It might not work perfectly until the System.Web from referencesource is integrated, but the same applies to the existing (outdated) copy we ship currently. This is something I've been working on. MVC 5.2.2 (the one available on NuGet) just doesn't work at the moment due to this pull https://github.com/mono/mono/pull/1349 being required (and I haven't had chance to fix the things that Miguel wanted).In addition, the old notes on getting MVC 3 working on mono, said to remove the MS supplied versions of the dlls IIRC, so these would stop working on upgrade (and replacing with the nuget ones for MVC3 probably won't work). ___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Can you explain the rationale for the #if used with the same SILVERLIGHT setting? It seems like it limits the code. On Sat, Nov 29, 2014 at 12:03 PM, Alexander Köplinger < alex.koeplin...@outlook.com> wrote: > Yeah, that was what I was doing. > > I created these PRs: > https://github.com/mono/referencesource/pull/1 > https://github.com/mono/mono/pull/1433 > > -- Alex > > -- > From: mig...@xamarin.com > Date: Sat, 29 Nov 2014 11:23:01 -0500 > > Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, > approaches for copying code? > To: alex.koeplin...@outlook.com > CC: mono-devel-list@lists.ximian.com > > I just realized it might not have been 100% clear what I think we should > do. > > We would in this case replace the references to our > mono/mcs/class/XX/*/*cs source files, with the > "../../external/referencesource/..." files, and then alter the original > referencesource file with the #if statements. > > We have done that already in a couple of places. > > (More to come, last night we got XML working, but needs some work) > > On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza > wrote: > > Thanks Alex. > > I do not think that we will have a strict rule for when to copy and when > to reference. > > There are scenarios where we will want to keep a lot of the code in one of > our files, and pull code from the referencesource. At that point, we will > have to determine whether the use of #ifdefs or partial classes is a better > long-term maintenance approach than copying the source. > > In this particular case, I feel that we can modify the reference source, > and add the #if MONO around it. > > The reason is that the changes are pretty straight forward, it is mostly > about disabling code, and not about picking some specific bits of code and > putting them on our tree. So an #if would be nice, since we can do a few > things (a) we can later find out what code is being disabled by the port > (looking at work we can do in the future to import new versions, or > contribute back to .NET) and (b) the changes are minimal right now. > > Miguel > > On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > Here's the diff between my trimmed version and the original: > http://www.mergely.com/9E70e5Ls/ > > Hmm, I actually think that most of the removed methods don't matter (as > they aren't called anyway). I just wanted to make the file only contain the > code that is necessary. > The only "real" changes I had to make where accesses to internal fields in > NumberFormatInfo, I just replaced them with accesses to the public > properties that read them. > > Maybe it makes more sense to correct those accesses directly in the > referencesource, so we can reference it from there? > As a general guidance, when should we copy something to the Mono tree vs. > editing referencesource? And if we copy, should we keep unneeded methods or > remove them? > > -- Alex > > -- > From: mig...@xamarin.com > Date: Sat, 29 Nov 2014 10:40:10 -0500 > Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, > approaches for copying code? > To: alex.koeplin...@outlook.com > CC: mono-devel-list@lists.ximian.com > > > Hey Alex, > > In general, the approach works. > > I am curious as to what is that you had to remove, and why. Can you > describe the needed changes? (I saw the diff, but it is hard to tell what > happened with it). > > I thought that Numerics was pretty much standalone. > > On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > Hey, I've been trying to port System.Numerics (BigInteger, Complex > classes) from referencesource to see and feel what the process looks like. > It mostly went fine, but there was one file (number.cs) I couldn't > reference directly from the submodule and had to copy to the assembly folder > in the Mono tree. > > I had to remove a bunch of code from that file to trim it down to only > what is needed for System.Numerics to compile (all the tests pass now as > well). > Question: is this a valid approach or is there something better? Note that > ifdefing the file wasn't feasible as it originally sits inside corlib and > has many other unrelated methods in it. > > Here's the commit with the WIP: > https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce > > -- Alex > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
Hey, We want to implement the same .NET Core interface when it becomes available and to support that scenario. But until that world exists and all the components are cross platform, we are just going to be annoying a bunch of people. On Sat, Nov 29, 2014 at 11:05 AM, Alexander Köplinger < alex.koeplin...@outlook.com> wrote: > Yeah, I think having something in-box with Mono just for convenience makes > less sense these days given that we have NuGet. > I'd actually advocate removing everything from the Mono distribution that > does not also ship with the .NET BCL (except maybe things like Mono.Simd > which requires specific runtime features). > The world is moving towards a more modular approach and (just like .NET > Core) we should leverage NuGet where we can. > > -- Alex > > -- > Date: Sat, 29 Nov 2014 15:50:05 + > From: monodanm...@yahoo.com > To: monofo...@my2cents.co.uk; alex.koeplin...@outlook.com > CC: mono-devel-list@lists.ximian.com > Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 > > I agree with removing Npgsql from Mono. Or either convince someone to > commit the latest version of Npgsql to mono. It would have to build with > mono's build system though. Francisco? > > The main reason it was included in mono was so you could have an > out-of-the-box experience with mono connecting to Postgres. > > > On Thursday, November 27, 2014 6:07 PM, Martin Thwaites < > monofo...@my2cents.co.uk> wrote: > > > > > On 27 November 2014 at 18:19, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > > > * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source > and on NuGet, should be used from there > > > I am actually not sure about this one, is that really the case? > > > The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, > so I think it should be fine to remove. It might not work perfectly until > the System.Web from referencesource is integrated, but the same applies to > the existing (outdated) copy we ship currently. > > > > This is something I've been working on. MVC 5.2.2 (the one available on > NuGet) just doesn't work at the moment due to this pull > https://github.com/mono/mono/pull/1349 being required (and I haven't had > chance to fix the things that Miguel wanted). > > In addition, the old notes on getting MVC 3 working on mono, said to > remove the MS supplied versions of the dlls IIRC, so these would stop > working on upgrade (and replacing with the nuget ones for MVC3 probably > won't work). > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Yeah, that was what I was doing. I created these PRs: https://github.com/mono/referencesource/pull/1 https://github.com/mono/mono/pull/1433 -- Alex From: mig...@xamarin.com Date: Sat, 29 Nov 2014 11:23:01 -0500 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code? To: alex.koeplin...@outlook.com CC: mono-devel-list@lists.ximian.com I just realized it might not have been 100% clear what I think we should do. We would in this case replace the references to our mono/mcs/class/XX/*/*cs source files, with the "../../external/referencesource/..." files, and then alter the original referencesource file with the #if statements. We have done that already in a couple of places. (More to come, last night we got XML working, but needs some work) On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza wrote: Thanks Alex. I do not think that we will have a strict rule for when to copy and when to reference. There are scenarios where we will want to keep a lot of the code in one of our files, and pull code from the referencesource. At that point, we will have to determine whether the use of #ifdefs or partial classes is a better long-term maintenance approach than copying the source. In this particular case, I feel that we can modify the reference source, and add the #if MONO around it. The reason is that the changes are pretty straight forward, it is mostly about disabling code, and not about picking some specific bits of code and putting them on our tree. So an #if would be nice, since we can do a few things (a) we can later find out what code is being disabled by the port (looking at work we can do in the future to import new versions, or contribute back to .NET) and (b) the changes are minimal right now. Miguel On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger wrote: Here's the diff between my trimmed version and the original: http://www.mergely.com/9E70e5Ls/ Hmm, I actually think that most of the removed methods don't matter (as they aren't called anyway). I just wanted to make the file only contain the code that is necessary. The only "real" changes I had to make where accesses to internal fields in NumberFormatInfo, I just replaced them with accesses to the public properties that read them. Maybe it makes more sense to correct those accesses directly in the referencesource, so we can reference it from there? As a general guidance, when should we copy something to the Mono tree vs. editing referencesource? And if we copy, should we keep unneeded methods or remove them? -- Alex From: mig...@xamarin.com Date: Sat, 29 Nov 2014 10:40:10 -0500 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code? To: alex.koeplin...@outlook.com CC: mono-devel-list@lists.ximian.com Hey Alex, In general, the approach works. I am curious as to what is that you had to remove, and why. Can you describe the needed changes? (I saw the diff, but it is hard to tell what happened with it). I thought that Numerics was pretty much standalone. On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger wrote: Hey, I've been trying to port System.Numerics (BigInteger, Complex classes) from referencesource to see and feel what the process looks like. It mostly went fine, but there was one file (number.cs) I couldn't reference directly from the submodule and had to copy to the assembly folder in the Mono tree. I had to remove a bunch of code from that file to trim it down to only what is needed for System.Numerics to compile (all the tests pass now as well). Question: is this a valid approach or is there something better? Note that ifdefing the file wasn't feasible as it originally sits inside corlib and has many other unrelated methods in it. Here's the commit with the WIP: https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
I just realized it might not have been 100% clear what I think we should do. We would in this case replace the references to our mono/mcs/class/XX/*/*cs source files, with the "../../external/referencesource/..." files, and then alter the original referencesource file with the #if statements. We have done that already in a couple of places. (More to come, last night we got XML working, but needs some work) On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza wrote: > Thanks Alex. > > I do not think that we will have a strict rule for when to copy and when > to reference. > > There are scenarios where we will want to keep a lot of the code in one of > our files, and pull code from the referencesource. At that point, we will > have to determine whether the use of #ifdefs or partial classes is a better > long-term maintenance approach than copying the source. > > In this particular case, I feel that we can modify the reference source, > and add the #if MONO around it. > > The reason is that the changes are pretty straight forward, it is mostly > about disabling code, and not about picking some specific bits of code and > putting them on our tree. So an #if would be nice, since we can do a few > things (a) we can later find out what code is being disabled by the port > (looking at work we can do in the future to import new versions, or > contribute back to .NET) and (b) the changes are minimal right now. > > Miguel > > On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > >> Here's the diff between my trimmed version and the original: >> http://www.mergely.com/9E70e5Ls/ >> >> Hmm, I actually think that most of the removed methods don't matter (as >> they aren't called anyway). I just wanted to make the file only contain the >> code that is necessary. >> The only "real" changes I had to make where accesses to internal fields >> in NumberFormatInfo, I just replaced them with accesses to the public >> properties that read them. >> >> Maybe it makes more sense to correct those accesses directly in the >> referencesource, so we can reference it from there? >> As a general guidance, when should we copy something to the Mono tree vs. >> editing referencesource? And if we copy, should we keep unneeded methods or >> remove them? >> >> -- Alex >> >> -- >> From: mig...@xamarin.com >> Date: Sat, 29 Nov 2014 10:40:10 -0500 >> Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, >> approaches for copying code? >> To: alex.koeplin...@outlook.com >> CC: mono-devel-list@lists.ximian.com >> >> >> Hey Alex, >> >> In general, the approach works. >> >> I am curious as to what is that you had to remove, and why. Can you >> describe the needed changes? (I saw the diff, but it is hard to tell what >> happened with it). >> >> I thought that Numerics was pretty much standalone. >> >> On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger < >> alex.koeplin...@outlook.com> wrote: >> >> Hey, I've been trying to port System.Numerics (BigInteger, Complex >> classes) from referencesource to see and feel what the process looks like. >> It mostly went fine, but there was one file (number.cs) I couldn't >> reference directly from the submodule and had to copy to the assembly folder >> in the Mono tree. >> >> I had to remove a bunch of code from that file to trim it down to only >> what is needed for System.Numerics to compile (all the tests pass now as >> well). >> Question: is this a valid approach or is there something better? Note >> that ifdefing the file wasn't feasible as it originally sits inside corlib >> and has many other unrelated methods in it. >> >> Here's the commit with the WIP: >> https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce >> >> -- Alex >> >> ___ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Thanks Alex. I do not think that we will have a strict rule for when to copy and when to reference. There are scenarios where we will want to keep a lot of the code in one of our files, and pull code from the referencesource. At that point, we will have to determine whether the use of #ifdefs or partial classes is a better long-term maintenance approach than copying the source. In this particular case, I feel that we can modify the reference source, and add the #if MONO around it. The reason is that the changes are pretty straight forward, it is mostly about disabling code, and not about picking some specific bits of code and putting them on our tree. So an #if would be nice, since we can do a few things (a) we can later find out what code is being disabled by the port (looking at work we can do in the future to import new versions, or contribute back to .NET) and (b) the changes are minimal right now. Miguel On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger < alex.koeplin...@outlook.com> wrote: > Here's the diff between my trimmed version and the original: > http://www.mergely.com/9E70e5Ls/ > > Hmm, I actually think that most of the removed methods don't matter (as > they aren't called anyway). I just wanted to make the file only contain the > code that is necessary. > The only "real" changes I had to make where accesses to internal fields in > NumberFormatInfo, I just replaced them with accesses to the public > properties that read them. > > Maybe it makes more sense to correct those accesses directly in the > referencesource, so we can reference it from there? > As a general guidance, when should we copy something to the Mono tree vs. > editing referencesource? And if we copy, should we keep unneeded methods or > remove them? > > -- Alex > > -- > From: mig...@xamarin.com > Date: Sat, 29 Nov 2014 10:40:10 -0500 > Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, > approaches for copying code? > To: alex.koeplin...@outlook.com > CC: mono-devel-list@lists.ximian.com > > > Hey Alex, > > In general, the approach works. > > I am curious as to what is that you had to remove, and why. Can you > describe the needed changes? (I saw the diff, but it is hard to tell what > happened with it). > > I thought that Numerics was pretty much standalone. > > On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger < > alex.koeplin...@outlook.com> wrote: > > Hey, I've been trying to port System.Numerics (BigInteger, Complex > classes) from referencesource to see and feel what the process looks like. > It mostly went fine, but there was one file (number.cs) I couldn't > reference directly from the submodule and had to copy to the assembly folder > in the Mono tree. > > I had to remove a bunch of code from that file to trim it down to only > what is needed for System.Numerics to compile (all the tests pass now as > well). > Question: is this a valid approach or is there something better? Note that > ifdefing the file wasn't feasible as it originally sits inside corlib and > has many other unrelated methods in it. > > Here's the commit with the WIP: > https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce > > -- Alex > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
Yeah, I think having something in-box with Mono just for convenience makes less sense these days given that we have NuGet. I'd actually advocate removing everything from the Mono distribution that does not also ship with the .NET BCL (except maybe things like Mono.Simd which requires specific runtime features). The world is moving towards a more modular approach and (just like .NET Core) we should leverage NuGet where we can. -- Alex Date: Sat, 29 Nov 2014 15:50:05 + From: monodanm...@yahoo.com To: monofo...@my2cents.co.uk; alex.koeplin...@outlook.com CC: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0 I agree with removing Npgsql from Mono. Or either convince someone to commit the latest version of Npgsql to mono. It would have to build with mono's build system though. Francisco? The main reason it was included in mono was so you could have an out-of-the-box experience with mono connecting to Postgres. On Thursday, November 27, 2014 6:07 PM, Martin Thwaites wrote: On 27 November 2014 at 18:19, Alexander Köplinger wrote: * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source and on NuGet, should be used from thereI am actually not sure about this one, is that really the case? The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, so I think it should be fine to remove. It might not work perfectly until the System.Web from referencesource is integrated, but the same applies to the existing (outdated) copy we ship currently. This is something I've been working on. MVC 5.2.2 (the one available on NuGet) just doesn't work at the moment due to this pull https://github.com/mono/mono/pull/1349 being required (and I haven't had chance to fix the things that Miguel wanted).In addition, the old notes on getting MVC 3 working on mono, said to remove the MS supplied versions of the dlls IIRC, so these would stop working on upgrade (and replacing with the nuget ones for MVC3 probably won't work). ___Mono-devel-list mailing listMono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Here's the diff between my trimmed version and the original: http://www.mergely.com/9E70e5Ls/ Hmm, I actually think that most of the removed methods don't matter (as they aren't called anyway). I just wanted to make the file only contain the code that is necessary. The only "real" changes I had to make where accesses to internal fields in NumberFormatInfo, I just replaced them with accesses to the public properties that read them. Maybe it makes more sense to correct those accesses directly in the referencesource, so we can reference it from there? As a general guidance, when should we copy something to the Mono tree vs. editing referencesource? And if we copy, should we keep unneeded methods or remove them? -- Alex From: mig...@xamarin.com Date: Sat, 29 Nov 2014 10:40:10 -0500 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code? To: alex.koeplin...@outlook.com CC: mono-devel-list@lists.ximian.com Hey Alex, In general, the approach works. I am curious as to what is that you had to remove, and why. Can you describe the needed changes? (I saw the diff, but it is hard to tell what happened with it). I thought that Numerics was pretty much standalone. On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger wrote: Hey, I've been trying to port System.Numerics (BigInteger, Complex classes) from referencesource to see and feel what the process looks like. It mostly went fine, but there was one file (number.cs) I couldn't reference directly from the submodule and had to copy to the assembly folder in the Mono tree. I had to remove a bunch of code from that file to trim it down to only what is needed for System.Numerics to compile (all the tests pass now as well). Question: is this a valid approach or is there something better? Note that ifdefing the file wasn't feasible as it originally sits inside corlib and has many other unrelated methods in it. Here's the commit with the WIP: https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] List of cleanup candidates for Mono 4.0
I agree with removing Npgsql from Mono. Or either convince someone to commit the latest version of Npgsql to mono. It would have to build with mono's build system though. Francisco? The main reason it was included in mono was so you could have an out-of-the-box experience with mono connecting to Postgres. On Thursday, November 27, 2014 6:07 PM, Martin Thwaites wrote: On 27 November 2014 at 18:19, Alexander Köplinger wrote: * aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source and on NuGet, should be used from there I am actually not sure about this one, is that really the case? The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, so I think it should be fine to remove. It might not work perfectly until the System.Web from referencesource is integrated, but the same applies to the existing (outdated) copy we ship currently. This is something I've been working on. MVC 5.2.2 (the one available on NuGet) just doesn't work at the moment due to this pull https://github.com/mono/mono/pull/1349 being required (and I haven't had chance to fix the things that Miguel wanted). In addition, the old notes on getting MVC 3 working on mono, said to remove the MS supplied versions of the dlls IIRC, so these would stop working on upgrade (and replacing with the nuget ones for MVC3 probably won't work). ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Hey Alex, In general, the approach works. I am curious as to what is that you had to remove, and why. Can you describe the needed changes? (I saw the diff, but it is hard to tell what happened with it). I thought that Numerics was pretty much standalone. On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger < alex.koeplin...@outlook.com> wrote: > Hey, I've been trying to port System.Numerics (BigInteger, Complex > classes) from referencesource to see and feel what the process looks like. > It mostly went fine, but there was one file (number.cs) I couldn't > reference directly from the submodule and had to copy to the assembly folder > in the Mono tree. > > I had to remove a bunch of code from that file to trim it down to only > what is needed for System.Numerics to compile (all the tests pass now as > well). > Question: is this a valid approach or is there something better? Note that > ifdefing the file wasn't feasible as it originally sits inside corlib and > has many other unrelated methods in it. > > Here's the commit with the WIP: > https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce > > -- Alex > > ___ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?
Hey, I've been trying to port System.Numerics (BigInteger, Complex classes) from referencesource to see and feel what the process looks like. It mostly went fine, but there was one file (number.cs) I couldn't reference directly from the submodule and had to copy to the assembly folder in the Mono tree. I had to remove a bunch of code from that file to trim it down to only what is needed for System.Numerics to compile (all the tests pass now as well). Question: is this a valid approach or is there something better? Note that ifdefing the file wasn't feasible as it originally sits inside corlib and has many other unrelated methods in it. Here's the commit with the WIP: https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce -- Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
