Hi,
Merged this by running the tools themselves.
Zoltan
On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com
wrote:
Sounds like a good thing ;-)
I've got a branch in my fork where I removed the NET_2_0 ifdefs:
Thanks, I somehow missed your earlier email that I could open a PR now :)
-- Alex
Date: Tue, 13 Jan 2015 15:34:27 -0500
Subject: Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
From: var...@gmail.com
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com
Hi
On 9 January 2015 at 23:31, Alistair Bush alistair.b...@gmail.com wrote:
Are there any plans on updating monodevelop and its dependent libraries to
build with 4+. Believe i've already seen issues building monodevelop ( or
a submodule) with mono (git)
sorry no details as I didn't really look
Mono.TextTemplating/CompiledTemplate.cs(86,53): error CS1501: No
overload for method `GetValue' takes `1' arguments
PropertyInfo.GetValue(object) method is from 4.5 framework. If you build
with NET 4.5 target framework that's something wrong with NET_4_5 symbol
definition in mono code. Look at
On 10 January 2015 at 15:26, xplicit s...@ngs.ru wrote:
Mono.TextTemplating/CompiledTemplate.cs(86,53): error CS1501: No
overload for method `GetValue' takes `1' arguments
PropertyInfo.GetValue(object) method is from 4.5 framework. If you build
with NET 4.5 target framework that's something
Hi,
It should be ok to do the NET_2_0 define removal now.
Zoltan
On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger alex.koeplin...@outlook.com
wrote:
Sounds like a good thing ;-)
I've got a branch in my fork where I removed the NET_2_0 ifdefs:
Are there any plans on updating monodevelop and its dependent libraries to
build with 4+. Believe i've already seen issues building monodevelop ( or
a submodule) with mono (git)
sorry no details as I didn't really look at it.
On Sat, Jan 10, 2015 at 11:09 AM, Zoltan Varga var...@gmail.com
Hello Sergey,
I'll try to reformulate my question. Do I understand correctly that in
new version of mono it will not be possible to compile assembly for
Mono/.NET 3.5 target and use the compiled assembly in Unity 3D (because
of referencing different corlib libraries in Unity (corlib 2.0) and
Hey,
There is no 3.5 profile. There are currently only 2.0, 4.0 (reference
assemblies), 4.5 and the mobile versions (mobile, android, ios).
What you think is 3.5 are assemblies introduced at 3.5, but we ship with
the above 4.0/4.5 ones.
On Fri, Oct 24, 2014 at 12:33 AM, xplicit s...@ngs.ru
Hi Miguel,
I think my preference would be to have the 3.x.x series continue (as
security fix only) with all the profiles, and essentially have it be a
legacy branch. Then have the 4.x.x series by a .NET 4.5+ only code base.
I think it should continue if people are willing to support it, but the
I'll try to reformulate my question. Do I understand correctly that in
new version of mono it will not be possible to compile assembly for
Mono/.NET 3.5 target and use the compiled assembly in Unity 3D (because
of referencing different corlib libraries in Unity (corlib 2.0) and
compiled assembly
Hello Martin,
There is no such thing as a 3.x.x series. It does not exist. It never
did.
You must be confused.
Miguel
On Fri, Oct 24, 2014 at 12:34 PM, Martin Thwaites monofo...@my2cents.co.uk
wrote:
Hi Miguel,
I think my preference would be to have the 3.x.x series continue (as
I can not answer that question, as I am not familiar with the situation,
and it seems like you are as confused as I am.
There wont be 2.0 reference assemblies anymore.
Miguel
On Fri, Oct 24, 2014 at 2:05 PM, Sergey Zhukov s...@ngs.ru wrote:
I'll try to reformulate my question. Do I understand
To make things clear, I had to make a small adjustment to
https://github.com/fanf2/unifdef so it didn't complain about C# multiline
strings. I had to remove this else if:
https://github.com/fanf2/unifdef/blob/90ca2eee76db715943ec4b7ca2892d155ca64075/unifdef.c#L1216-L1220,
then it ran fine on the
Hi Miguel,
I'm referring to 3.9, 3.10.1, etc. i.e. the current version being 3.10.1.
So I guess it should be considered the 3.x series.
I'm meaning that we shouldn't preclude there being a 3.11, or 3.12, if
there is a critical bug.
Also, do you have an answer to the distro question?
Thanks,
Ah, I see.
Yeah, perhaps we will move to the 4.0 branding, just need to check with
folks around here what they think.
For distros: nobody in the Linux world really ever cared about this.
We kept these profiles with the idea that this was something that actually
mattered, and it turns out, it
Is everything from 4.0 on the correct side currently there? I have seen
this cause confusion in the past for many thinking the version numbers
somehow match up :)
On Friday, October 24, 2014, Miguel de Icaza mig...@xamarin.com wrote:
Ah, I see.
Yeah, perhaps we will move to the 4.0 branding,
Miguel de Icaza-6 wrote
We are going to remove the build for the .NET 2.0 APIs from Mono which are
currently provided for bug/feature-compatibility for .NET 2.0
applications.
Will you save .NET 3.5 or you are going to remove corlib 2.0 at all?
Removing 2.0 profile is a good thing, but without
Hello folks,
We have discussed this internally for a while, and I just want to formalize
this now.
We are going to remove the build for the .NET 2.0 APIs from Mono which are
currently provided for bug/feature-compatibility for .NET 2.0 applications.
We are also going to remove the .NET 4.0
Sounds like a good thing ;-)
I've got a branch in my fork where I removed the NET_2_0 ifdefs:
https://github.com/akoeplinger/mono/compare/remove-net20-ifdefs, @kumpera
told me a while ago that removing the 2.0 profile is on the horizon when I
asked about why the ifdefs are still there.
I
Hey Alex,
It is very repetitive work, so what I wanted to do was to write a perl
script to remove the *obvious* ifdefs. The tool would remove only those
that match the following criteria (more or less):
- Remove toplevel #if NET_2_0 with the final #endif
- Only remove those that contain
My guess is that its probably worth the extra hour to handle the #elif
and #else conditions. I imagine there are a bunch of places with
#ifdef NET_2_0
#else
#endif
I wouldn't go crazy on it but a few days of manually fixing those
would be annoying :)
On Wed, Oct 22, 2014 at 11:10 PM, Miguel de
Oct 2014 16:10:47 -0400
Subject: Re: [Mono-dev] Heads up: Elimination of the 2.0 and 4.0 profiles
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com
Hey Alex,
It is very repetitive work, so what I wanted to do was to write a perl script
to remove the *obvious* ifdefs. The tool
Hi Miguel,
Would you be looking at calling this Mono 4.0? Not that it makes any
difference really, it just seems there's been a lot of improvements in
recently, and an announcement of a new version me give some renewed
interest.
Thanks,
Martin
On 22 October 2014 21:10, Miguel de Icaza
Hey,
Mhm, that is a good idea. Will think about it.
Right now we were just planning on calling the next one Mono 3.12. But
perhaps the time has come for a nice bump!
Miguel
On Wed, Oct 22, 2014 at 4:21 PM, Martin Thwaites monofo...@my2cents.co.uk
wrote:
Hi Miguel,
Would you be looking
I can see another advantage in that the large increment would be an easy way to
remember where the 2.x and 4.0 compatibility break is for writing applications
that need to target the widest set of backwards-compatible platforms.
Of course, there is the question of whether the other features
Wouldn't it be Mono !4.0 since it won't have the 4.0 reference assemblies
any more?
Yeah, that was bad. I'm going back to sleep.
On 23 October 2014 07:18, Miguel de Icaza mig...@xamarin.com wrote:
Hey,
Mhm, that is a good idea. Will think about it.
Right now we were just planning on
27 matches
Mail list logo