Re: [Mono-dev] mono_add_internal_call to mscorlib method

[Alexander Köplinger]

You're looking at the wrong implementation of Environment.cs. The one we're
using is still Mono's implementation (as opposed to the MS referencesource
one you're looking at):
https://github.com/mono/mono/blob/37bb54b503f3f8c948955c577687d4233e950cb5/mcs/class/corlib/System/Environment.cs#L472

It ends up calling into the runtime to
https://github.com/mono/mono/blob/37bb54b503f3f8c948955c577687d4233e950cb5/mono/metadata/icall.c#L6942-L6949
.

Anyway, this shouldn't matter as you're not supposed to add an icall for
that yourself, it's provided by Mono. From a quick reading of the code
there's no way this can return null so I'm a bit confused, but I'll let the
runtime experts weigh in :)

- Alex

2016-06-08 21:26 GMT+02:00 nicob :

> Hi, I'm trying to use the Skype Sdk in mono embedded. I'm able to load the
> assemblies but when I try to create a instance of a class that internally
> calls System.Environment.GetCommandLineArgs it throws an exception. After
> digging a bit I found out the System.Environment.GetCommandLineArgs
> internally invokes:
>
> private static extern string[] GetCommandLineArgsNative();
>
> this method is returning null therefore it fails. I'm trying to add an
> internal call to the extern method using:
>
> mono_add_internal_call ("System.Environment::GetCommandLineArgsNative",
> (void*)GetCommandLine);
>
> I also tried:
>
> mono_add_internal_call
> ("mscorlib.System.Environment::GetCommandLineArgsNative",
> (void*)GetCommandLine);
>
> but neither of them seem to work as my C++ function is never invoked.
>
> C++ function:
> MonoArray* GetCommandLine()
> {
> MonoDomain* domain = mono_domain_get();
> MonoArray* array = mono_array_new(domain, mono_get_string_class(), 1);
>
> MonoString* ret = mono_string_new(domain, "yeah!");
> mono_array_setref(array, 0, ret);
>
> return array;
> }
>
>
> Am I missing something?
>
> Thanks in advanced.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/mono-add-internal-call-to-mscorlib-method-tp4667951.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> 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] Build failure

[Alexander Köplinger]

Hey Neale,

yes this is because of
https://github.com/mono/mono/commit/a2147aa78a8ec78353b88e52a73c6551051ce5e3#commitcomment-17687281.
We'll get it fixed.

Thanks,
Alex

2016-06-01 0:25 GMT+02:00 Neale Ferguson :

> Anyone seen this:
>
> ReferenceSources/SettingsSectionInternal.cs(24,17): error CS8051:
> Auto-implemented property
> `System.Net.Configuration.SettingsSectionInternal.CheckCertificateName'
> must have set accessor or initializer
> ReferenceSources/SettingsSectionInternal.cs(28,29): error CS8051:
> Auto-implemented property
> `System.Net.Configuration.SettingsSectionInternal.EncryptionPolicy' must
> have set accessor or initializer
>
>
> Just started today, but this is the first time I’ve built since Friday.
>
> Neale
>
>
> ___
> 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] Diagnosing "Invalid IL code"

[Alexander Köplinger]

> I don't get a viable stack trace out [filenames and line numbers are
missing]. It's making it pretty hard to debug some issues; is there a
simple fix for that?

Yes, you can use the pdb2mdb tool to convert Windows debug symbols to the
mdb symbols Mono can read.

- Alex

2016-05-13 19:46 GMT+02:00 Gary Briggs :

> On Thu, May 12, 2016 at 09:06:18PM +0200, Alexander Köplinger wrote:
> > As far as I know there isn't a fully integrated way to use this from
> > monodevelop yet even though the upcoming 6.0 release uses roslyn
> internally
> > for intellisense etc though, but at build time it just calls xbuild which
> > uses the Mono compilers.
>
> I'm not actually wedded to monodevelop at all. Mostly I just want to
> be able to build from a .vbproj
>
> > We do have a preview release on OSX that includes the open sourced
> msbuild
> > with roslyn included, I'm not sure what the Linux plans for that are
> right
> > now (
> >
> https://github.com/Microsoft/msbuild/releases/tag/mono-hosted-msbuild-v0.2
> > should work with current Mono but I know it breaks with the upcoming
> > release).
> >
> > So lots of stuff in the making, but not an easy to use solution right
> now :)
>
> Fair enough. I do have a working toolchain for now [going via a Windows
> system], but my problem is that when binaries from there crashe in mono,
> I don't get a viable stack trace out [filenames and line numbers are
> missing]. It's making it pretty hard to debug some issues; is there a
> simple fix for that?
>
> Gary
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Diagnosing "Invalid IL code"

[Alexander Köplinger]

As far as I know there isn't a fully integrated way to use this from
monodevelop yet even though the upcoming 6.0 release uses roslyn internally
for intellisense etc though, but at build time it just calls xbuild which
uses the Mono compilers.

We do have a preview release on OSX that includes the open sourced msbuild
with roslyn included, I'm not sure what the Linux plans for that are right
now (
https://github.com/Microsoft/msbuild/releases/tag/mono-hosted-msbuild-v0.2
should work with current Mono but I know it breaks with the upcoming
release).

So lots of stuff in the making, but not an easy to use solution right now :)

- Alex

2016-05-12 17:14 GMT+02:00 Gary Briggs :

> On Thu, May 12, 2016 at 02:44:51PM +0200, Alexander Köplinger wrote:
> > And if that doesn't help, you might want to take a look at Roslyn as
> there
> > likely won't be any work on Mono's VB compiler going forward:
> >
> > $ nuget install Microsoft.Net.Compilers -Version 1.2.1
> >
> > $ mono ./Microsoft.Net.Compilers.1.2.1/tools/vbc.exe hello.vb /noconfig
>
> Huh, cool. I'm not wedded to mono compilers at all, really I just want
> to be able to build on Linux.
>
> Is there an easy way to use that compiler with an existing .sln/.vbproj? I
> can't find any settings in monodevelop that would point me to a different
> compiler.
>
> Cheers,
> Gary
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Diagnosing "Invalid IL code"

[Alexander Köplinger]

And if that doesn't help, you might want to take a look at Roslyn as there
likely won't be any work on Mono's VB compiler going forward:

$ nuget install Microsoft.Net.Compilers -Version 1.2.1

$ mono ./Microsoft.Net.Compilers.1.2.1/tools/vbc.exe hello.vb /noconfig


- Alex

2016-05-12 8:05 GMT+02:00 Timotheus Pokorra <
timotheus.poko...@solidcharity.com>:

> Hello Gary,
>
> On 12 May 2016 at 06:52, Gary Briggs  wrote:
> > I have some code that, when compiled with monodevelop [latest in Ubuntu
> > 15.10], throws an invalid IL code exception when run with mono. This same
> > code, when compiled with VS2015, does not throw said exception when run
> > with mono.
>
> I just checked, Ubuntu 15.10 still had Mono 3.2.8.
> You might want to try Ubuntu 16.04, which comes with Mono 4.2.1
> Alternatively, install the latest Mono packages from Xamarin on Ubuntu
> 15.10:
> http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives
>
> I hope this might solve your issues already,
>
> Timothues
> ___
> 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] Build error

[Alexander Köplinger]

It's not fixed in master yet, I sent a tentative fix with
https://github.com/mono/mono/pull/2986, if you could try that one it'd be
awesome.

- Alex

2016-05-11 16:15 GMT+02:00 Neale Ferguson :

> Ah, great. Thanks!
>
> Does that mean you’re getting through to both jenkins servers now without
> error?
>
> Neale
>
> From: Alexander Köplinger 
> Date: Wednesday, May 11, 2016 at 8:23 AM
> To: Neale Ferguson 
> Cc: Mono-Devel 
> Subject: Re: [Mono-dev] Build error
>
> Btw. we're seeing the same issue on the s390x builders on jenkins. We're
> bootstrapping with Mono 3.10 there so maybe it's an issue with mcs in that
> version. I'll talk to Marek.
>
> - Alex
>
> 2016-05-11 3:34 GMTכֿ:00 Neale Ferguson :
>
>> Did the git clean –xdf and rebuilt. Same error. I’ll see if I can clone a
>> copy and try again.
>>
>>
>> Oid was recently imported from the MS referencesources:
>> https://github.com/mono/mono/commit/4a6e5d24e174b9d2860300503b4a79396d7ae96d
>>
>> I don't see why that would happen for you, it is building fine on our
>> bots. Maybe try a "git clean -xdf" to ensure a clean repo?
>>
>>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Build error

[Alexander Köplinger]

Btw. we're seeing the same issue on the s390x builders on jenkins. We're
bootstrapping with Mono 3.10 there so maybe it's an issue with mcs in that
version. I'll talk to Marek.

- Alex

2016-05-11 3:34 GMT+02:00 Neale Ferguson :

> Did the git clean –xdf and rebuilt. Same error. I’ll see if I can clone a
> copy and try again.
>
>
> Oid was recently imported from the MS referencesources:
> https://github.com/mono/mono/commit/4a6e5d24e174b9d2860300503b4a79396d7ae96d
>
> I don't see why that would happen for you, it is building fine on our
> bots. Maybe try a "git clean -xdf" to ensure a clean repo?
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Build error

[Alexander Köplinger]

Oid was recently imported from the MS referencesources:
https://github.com/mono/mono/commit/4a6e5d24e174b9d2860300503b4a79396d7ae96d

I don't see why that would happen for you, it is building fine on our bots.
Maybe try a "git clean -xdf" to ensure a clean repo?

- Alex

2016-05-10 16:56 GMT+02:00 Neale Ferguson :

> Over the last couple of days days I have been encountering an error
> building from master. I did a make clean but it persists:
>
> System.Net.Sockets/SocketAsyncEventArgs.cs(203,34): warning CS0420:
> `System.Net.Sockets.SocketAsyncEventArgs.in_progress': A volatile field
> references will not be treated as volatile
> System.Security.Cryptography.X509Certificates/X509EnhancedKeyUsageExtension
> .cs(71,20): error CS0135: `oid' conflicts with a declaration in a child
> block
> System.Security.Cryptography.X509Certificates/X509EnhancedKeyUsageExtension
> .cs(74,17): (Location of the symbol related to previous error)
> Compilation failed: 1 error(s), 38 warnings
>
>
> I have no local changes in this area.
>
> Neale
>
>
> ___
> 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] Running Mono on 32bits-big endian PowerPC

[Alexander Köplinger]

(sorry, hit send too early...)

FYI --with-gc=sgen doesn't make sense since the --with-gc option only
controls the Boehm GC (see
https://github.com/mono/mono#configuration-options).

- Alex

2016-04-04 16:03 GMT+02:00 Alexander Köplinger <
alexander.koeplin...@xamarin.com>:

> FYI --with-gc=sgen doesn'
>
> 2016-04-04 14:25 GMT+02:00 Mathieu Malaterre :
>
>> As a side note, I can build mono on SMP PowerPC using an easy hack:
>>
>> export MONO_GC_PARAMS=nursery-size=1073741824
>> ./autogen.sh --prefix=$HOME/blah  --with-gc=sgen --disable-boehm
>> --enable-checked-build=all --disable-nls --with-sgen=yes
>> make V=1 PROFILE=basic
>>
>> -M
>> ___
>> 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] Running Mono on 32bits-big endian PowerPC

[Alexander Köplinger]

FYI --with-gc=sgen doesn'

2016-04-04 14:25 GMT+02:00 Mathieu Malaterre :

> As a side note, I can build mono on SMP PowerPC using an easy hack:
>
> export MONO_GC_PARAMS=nursery-size=1073741824
> ./autogen.sh --prefix=$HOME/blah  --with-gc=sgen --disable-boehm
> --enable-checked-build=all --disable-nls --with-sgen=yes
> make V=1 PROFILE=basic
>
> -M
> ___
> 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] Running Mono on 32bits-big endian PowerPC

[Alexander Köplinger]

ASYNC is just a #ifdef symbol which gets defined when the -d option is
passed to the compiler (basic.exe in this case, which is basically the mcs
C# compiler).

You would need to look into the .cs files mentioned
in System.Xml.dll.sources to find out which pieces of the code light up
when that symbol is defined.
>From there on you can try reducing the test case to a small repro sample
that you can debug.

As Jo said in his email, I'd also suggest looking at the 4.4
release/branches since those will be the next stable release in the near
future.

- Alex

2016-04-01 9:37 GMT+02:00 Mathieu Malaterre :

> My initial post was a bit vague. Let me rephrase it.
>
> I am trying to solve the following issue:
>
> https://bugzilla.xamarin.com/show_bug.cgi?id=40037
>
> I would like to know where is the documentation for the '-d:ASYNC'
> documentation ? I've naively tried:
>
> % ./mono basic.exe --help
> [...]
>   -define:S1[;S2]  Defines one or more conditional symbols (short: -d)
> [...]
>
> Which is missing the information for the 'ASYNC' meaning.
>
> Regards.
> ___
> 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] build mono with dynamic sgen library

[Alexander Köplinger]

You should be able to do that by passing --with-static_mono=no to
autogen.sh/configure:
http://www.mono-project.com/docs/compiling-mono/unsupported-advanced-compile-options/#static-vs-dynamic-mono

-- Alex

2016-03-30 14:31 GMT+02:00 Felix Rubio :

> Hi all,
>
>for a little experiment, I am trying to build the library libmonosgen
> as a .so, and to get mono to get linked to it instead of libmonosgen.a. The
> reason is that I want to intercept some of the calls to get some PAPI
> counters, measurements, etc., and to switch on/off this instrumentation
> library on a per execution basis.
>
>After spending 2 hours trying to do it, I have miserably failed (I have
> not worked with autotools before). Does anybody have an idea on how to
> achieve this?
>
>Thank you very much,
>Felix
>
> --
> Felix Rubio
> "Don't believe what you're told. Double check."
> ___
> 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] System.SR

[Alexander Köplinger]

The SR class is autogenerated in the corefx build from
Resources/Strings.resx in each project with an msbuild task:
https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/resources.targets

The referencesources uses a similar pattern although most strings are
stored in a .txt there and we used a tool to turn that into the .cs:
https://github.com/mono/mono/blob/master/mcs/class/System/ReferenceSources/SR.cs
For a library I've ported from corefx I manually added the SR class: (
https://github.com/mono/mono/blob/master/mcs/class/System.Threading.Tasks.Dataflow/SR.cs

- Alex

2016-03-28 18:38 GMT+02:00 Neale Ferguson :

> I am looking at incorporating the CoreFx System.Data.SqlClient into mono
> and in examining the code have come across references to the System.SR
> namespace. I am not familiar with this and it seems not to exist elsewhere
> in either the reference sources or mono sources.
>
> Neale
>
> ___
> 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] Build Broken?

[Alexander Köplinger]

This seems to also be caused by your outdated fork, the problem was fixed
in 2013 by
https://github.com/mono/mono/commit/052ba601f3ed9e7fc5a216407986a89ee0c3296f

- Alex

2016-03-02 18:41 GMT+01:00 Greg Young :

> Ubuntu ubuntu 15.10 Following instructions from
> http://www.mono-project.com/docs/compiling-mono/linux/
>
> autogen fails:
>
> runtime/Makefile.am:2: error: support for Cygnus-style trees has been
> removed
>
>
>
> --
> Studying for the Turing test
> ___
> 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] WebRequest timeouts after ThreadPool exhaustion

[Alexander Köplinger]

Sorry, turns out I made an error when testing on master. I can actually see
the request timeout there too, so it's not fixed on master.

I filed a bug with your repro code:
https://bugzilla.xamarin.com/show_bug.cgi?id=38715

- Alex



2016-02-12 15:13 GMT+01:00 Alexander Köplinger <
alexander.koeplin...@xamarin.com>:

> Happens on mono-4.3.2-branch/9f44a62 as well...
>
> Alan: the PR you linked doesn't seem to be related, did you have another
> PR in mind?
>
> - Alex
>
> 2016-02-12 15:07 GMT+01:00 Alexander Köplinger <
> alexander.koeplin...@xamarin.com>:
>
>> I tried the testcase on master and couldn't reproduce there. I could,
>> however, reproduce it on the 4.3.2 build I had installed
>> (mono-4.3.2-branch/0df254d). I'm downloading a later 4.3.2 build right now
>> to see if it still happens there, if it does then we need to backport
>> something from master.
>>
>> - Alex
>>
>> 2016-02-12 15:04 GMT+01:00 Seif Attar :
>>
>>> Great, I'll try it out. Is the console app in that gist enough for a
>>> test case?
>>>
>>> @Mike @Jonathan we've faced bugs with previous versions of libc and
>>> networking before, also some kernel issues. Update to latest if you can. I
>>> can't reproduce with 3.12. I get timeouts but then it recovers when there
>>> are available threads unlike with 4.x
>>>
>>> On Fri, 12 Feb 2016 13:50 Alan  wrote:
>>>
>>>> It's also worth pointing out that the threadpool implementation has
>>>> changed completely since mono 4.0. I believe the new threadpool
>>>> implementation shipped as the default starting with mono 4.2 (or
>>>> thereabouts). If you're on older Monos the odds are high whatever issue you
>>>> have has been fixed already.
>>>>
>>>> Alan
>>>>
>>>> On 12 February 2016 at 13:48, Alan  wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> We have just fixed some issues in that area. They are expected to ship
>>>>> as part of a the next mono 4.3+ release. If you want to test them out in
>>>>> the meantime you could try building mono with this PR [0] and see if it
>>>>> resolves all your issues. If it doesn't then a testcase and bug report on
>>>>> http://bugzilla.xamarin.com would be awesome!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> [0] https://github.com/mono/mono/pull/2576
>>>>>
>>>>> On 12 February 2016 at 12:33, Mike Horsley 
>>>>> wrote:
>>>>>
>>>>>> we’ve also seen instances of webrequest timeouts that don’t recover
>>>>>> (but curl worked) as well but haven’t got to the bottom of it yet.
>>>>>>
>>>>>>
>>>>>>
>>>>>> we ran your test app and see the same issue with mono 3.12 on
>>>>>> OpenSUSE 13.2 (kernel 3.16.7, libc 2.19).
>>>>>>
>>>>>>
>>>>>>
>>>>>> we’ll add the diagnostics from your test app into ours and this will
>>>>>> tell us whether we are seeing the same issue with the threadpool.
>>>>>>
>>>>>>
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
>>>>>> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Seif Attar
>>>>>> *Sent:* Friday, February 12, 2016 10:43 AM
>>>>>> *To:* mono-devel-list@lists.ximian.com
>>>>>> *Subject:* [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We are running mono 4.2.2 in prod and the VM that the process was
>>>>>> running on had SAN failure and after storage recovered, all outgoing
>>>>>> requests were timing out, even though doing a curl was working fine.
>>>>>>
>>>>>> Theory was that thread pool starved and somehow things didn't recover
>>>>>> properly.
>>>>>>
>>>>>> Managed to reproduce with:
>>>>>>
>>>>>>
>>>>>> https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

[Alexander Köplinger]

Happens on mono-4.3.2-branch/9f44a62 as well...

Alan: the PR you linked doesn't seem to be related, did you have another PR
in mind?

- Alex

2016-02-12 15:07 GMT+01:00 Alexander Köplinger <
alexander.koeplin...@xamarin.com>:

> I tried the testcase on master and couldn't reproduce there. I could,
> however, reproduce it on the 4.3.2 build I had installed
> (mono-4.3.2-branch/0df254d). I'm downloading a later 4.3.2 build right now
> to see if it still happens there, if it does then we need to backport
> something from master.
>
> - Alex
>
> 2016-02-12 15:04 GMT+01:00 Seif Attar :
>
>> Great, I'll try it out. Is the console app in that gist enough for a test
>> case?
>>
>> @Mike @Jonathan we've faced bugs with previous versions of libc and
>> networking before, also some kernel issues. Update to latest if you can. I
>> can't reproduce with 3.12. I get timeouts but then it recovers when there
>> are available threads unlike with 4.x
>>
>> On Fri, 12 Feb 2016 13:50 Alan  wrote:
>>
>>> It's also worth pointing out that the threadpool implementation has
>>> changed completely since mono 4.0. I believe the new threadpool
>>> implementation shipped as the default starting with mono 4.2 (or
>>> thereabouts). If you're on older Monos the odds are high whatever issue you
>>> have has been fixed already.
>>>
>>> Alan
>>>
>>> On 12 February 2016 at 13:48, Alan  wrote:
>>>
>>>> Hey,
>>>>
>>>> We have just fixed some issues in that area. They are expected to ship
>>>> as part of a the next mono 4.3+ release. If you want to test them out in
>>>> the meantime you could try building mono with this PR [0] and see if it
>>>> resolves all your issues. If it doesn't then a testcase and bug report on
>>>> http://bugzilla.xamarin.com would be awesome!
>>>>
>>>> Thanks!
>>>>
>>>> [0] https://github.com/mono/mono/pull/2576
>>>>
>>>> On 12 February 2016 at 12:33, Mike Horsley 
>>>> wrote:
>>>>
>>>>> we’ve also seen instances of webrequest timeouts that don’t recover
>>>>> (but curl worked) as well but haven’t got to the bottom of it yet.
>>>>>
>>>>>
>>>>>
>>>>> we ran your test app and see the same issue with mono 3.12 on OpenSUSE
>>>>> 13.2 (kernel 3.16.7, libc 2.19).
>>>>>
>>>>>
>>>>>
>>>>> we’ll add the diagnostics from your test app into ours and this will
>>>>> tell us whether we are seeing the same issue with the threadpool.
>>>>>
>>>>>
>>>>>
>>>>> regards
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
>>>>> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Seif Attar
>>>>> *Sent:* Friday, February 12, 2016 10:43 AM
>>>>> *To:* mono-devel-list@lists.ximian.com
>>>>> *Subject:* [Mono-dev] WebRequest timeouts after ThreadPool exhaustion
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> We are running mono 4.2.2 in prod and the VM that the process was
>>>>> running on had SAN failure and after storage recovered, all outgoing
>>>>> requests were timing out, even though doing a curl was working fine.
>>>>>
>>>>> Theory was that thread pool starved and somehow things didn't recover
>>>>> properly.
>>>>>
>>>>> Managed to reproduce with:
>>>>>
>>>>>
>>>>> https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a4bad60fa4818ad32d629/timeout.cs
>>>>>
>>>>> Even after ThreadPool finishes the tasks and has available threads, it
>>>>> never recovers and subsequent webrequests all timeout.
>>>>>
>>>>> Running on mono 4.2.2, linux kernel 4.2.0-27 and libc 2.21.
>>>>>
>>>>> Output from gdb is:
>>>>>
>>>>> (gdb) info threads
>>>>>   Id   Target Id Frame
>>>>>   13   Thread 0x7fca903ff700 (LWP 27944) "cli" 
>>>>> pthread_cond_wait@@GLIBC_2.3.2
>>>>> () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>>>&g

Re: [Mono-dev] WebRequest timeouts after ThreadPool exhaustion

[Alexander Köplinger]

I tried the testcase on master and couldn't reproduce there. I could,
however, reproduce it on the 4.3.2 build I had installed
(mono-4.3.2-branch/0df254d). I'm downloading a later 4.3.2 build right now
to see if it still happens there, if it does then we need to backport
something from master.

- Alex

2016-02-12 15:04 GMT+01:00 Seif Attar :

> Great, I'll try it out. Is the console app in that gist enough for a test
> case?
>
> @Mike @Jonathan we've faced bugs with previous versions of libc and
> networking before, also some kernel issues. Update to latest if you can. I
> can't reproduce with 3.12. I get timeouts but then it recovers when there
> are available threads unlike with 4.x
>
> On Fri, 12 Feb 2016 13:50 Alan  wrote:
>
>> It's also worth pointing out that the threadpool implementation has
>> changed completely since mono 4.0. I believe the new threadpool
>> implementation shipped as the default starting with mono 4.2 (or
>> thereabouts). If you're on older Monos the odds are high whatever issue you
>> have has been fixed already.
>>
>> Alan
>>
>> On 12 February 2016 at 13:48, Alan  wrote:
>>
>>> Hey,
>>>
>>> We have just fixed some issues in that area. They are expected to ship
>>> as part of a the next mono 4.3+ release. If you want to test them out in
>>> the meantime you could try building mono with this PR [0] and see if it
>>> resolves all your issues. If it doesn't then a testcase and bug report on
>>> http://bugzilla.xamarin.com would be awesome!
>>>
>>> Thanks!
>>>
>>> [0] https://github.com/mono/mono/pull/2576
>>>
>>> On 12 February 2016 at 12:33, Mike Horsley  wrote:
>>>
 we’ve also seen instances of webrequest timeouts that don’t recover
 (but curl worked) as well but haven’t got to the bottom of it yet.



 we ran your test app and see the same issue with mono 3.12 on OpenSUSE
 13.2 (kernel 3.16.7, libc 2.19).



 we’ll add the diagnostics from your test app into ours and this will
 tell us whether we are seeing the same issue with the threadpool.



 regards

 Mike



 *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
 mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Seif Attar
 *Sent:* Friday, February 12, 2016 10:43 AM
 *To:* mono-devel-list@lists.ximian.com
 *Subject:* [Mono-dev] WebRequest timeouts after ThreadPool exhaustion



 Hi,

 We are running mono 4.2.2 in prod and the VM that the process was
 running on had SAN failure and after storage recovered, all outgoing
 requests were timing out, even though doing a curl was working fine.

 Theory was that thread pool starved and somehow things didn't recover
 properly.

 Managed to reproduce with:


 https://gist.githubusercontent.com/seif/ae2defbfa5afa26fa8f6/raw/bef351eded56c882658a4bad60fa4818ad32d629/timeout.cs

 Even after ThreadPool finishes the tasks and has available threads, it
 never recovers and subsequent webrequests all timeout.

 Running on mono 4.2.2, linux kernel 4.2.0-27 and libc 2.21.

 Output from gdb is:

 (gdb) info threads
   Id   Target Id Frame
   13   Thread 0x7fca903ff700 (LWP 27944) "cli" 
 pthread_cond_wait@@GLIBC_2.3.2
 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
   12   Thread 0x7fca90b34700 (LWP 27945) "Finalizer" 0x7fca911d70c9
 in futex_abstimed_wait (cancel=true, private=, abstime=0x0,
 expected=0, futex=0x948ae0) at sem_waitcommon.c:42
   11   Thread 0x7fca8dfff700 (LWP 27946) "Timer-Scheduler"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   10   Thread 0x7fca91ba1700 (LWP 27947) "cli" __clock_nanosleep
 (clock_id=1, flags=1, req=0x7fca91ba0dc0, rem=0x7fca90f134aa
 <__clock_nanosleep+138>) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
   9Thread 0x7fca8ddfe700 (LWP 27948) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   8Thread 0x7fca8dbfd700 (LWP 27949) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   7Thread 0x7fca8d7fb700 (LWP 27951) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   6Thread 0x7fca8d3f9700 (LWP 27953) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   5Thread 0x7fca8d1f8700 (LWP 27954) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
   4Thread 0x7fca8cff7700 (LWP 27955) "Threadpool work"
 pthread_cond_timedwait@@GLIBC_2.3.2 () at
 ../sy

Re: [Mono-dev] Strange build problem

[Alexander Köplinger]

For the benefit of future readers: this turned out to be gcc compiler bugs
in the versions we were using.

On nealef-s390x-1 we are using gcc 4.4.7. Neale sent
https://github.com/mono/mono/pull/2488 to workaround this problem which
worked fine there.
However, it broke the build on nealef-s390x-2 with gcc 4.3.4 (which was
working fine before!) with the exact same error that the patch fixed on the
other machine. So Neale sent another PR to fix both:
https://github.com/mono/mono/pull/2494

I've now reenabled both s390x Jenkins workers again and the build seems
happy :)

- Alex

2016-01-20 15:02 GMT+01:00 Alexander Köplinger <
alexander.koeplin...@xamarin.com>:

> Hey,
>
> Are you sure you’re running this on the nealef-s390x-2 machine and not
> nealef-s390x-1 ?
> This sounds exactly like the problem with the ancient gcc we ran into on
> the -1 machine, that’s why we’re only using the -2 machine on Jenkins now.
>
> In fact, my IRC log shows we discussed this back in October 2015:
>
>  neale: still no success compiling on nealef-s390x-1, with -O2
> 
> https://jenkins.mono-project.com/job/z/label=centos-s390x/2065/parsed_console/log_content.html#ERROR1
>  System/AndroidPlatform.cs(66,246): error CS1525: Unexpected
> symbol `end-of-file', expecting `end-of-file'
>  ._.
>  directhex: At least it got rid of the inline errors problem ;-)
>  yes this is technically true
>  I've never seen this particular problem before
>  maybe a checkout problem? want to delete the workspace?
>  The z workspace?
>  hmm, it affects all files that are completely #ifdefed out
>  Yup
>  neale: yes
>  z gone\
>  it's renamed to "z" because the same job also handles windows
> builds, and windows has a silly low PATH_MAX
>  which the old name was causing errors for
>  Ah
>  so single-char job names if they run on windows
>  I ran a build in
> /home/jenkins/workspace/test-mono-mainline-communityarchitectures/label/centos-s390x
> (From Sep28) and forced a recompile of Android.cs which has the same ifdef
> situation and the build was clean.
>  that job name is the old "z" job
>  see, very long name, poor windows
>  Understood, just wanted to point out that a build used to work for
> those files
>
> AFAIK we never got past that problem on the -1 machine, so we just stopped
> using it.
>
> - Alex
>
> > Am 20.01.2016 um 03:13 schrieb Neale Ferguson :
> >
> > Re: bugzilla 37781
> >
> > On the same virtual machine in which the Jenkins bot successfully builds
> > mono, I am encountering failures of an unusual type. Thinking it might be
> > a hangover to something in the account’s home directory, I created a
> > completely new account, cloned from master, configured and built. It
> craps
> > out with the following:
> >
> > MCS [build] mscorlib.dll
> > Assembly/AssemblyInfo.cs(33,5): error CS8025: Parsing error
> > System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol
> > `end-of-file', expecting `end-of-file'
> > System/Console.iOS.cs(127,246): error CS1525: Unexpected symbol
> > `end-of-file', expecting `end-of-file'
> > System/Guid.MonoTouch.cs(24,253): error CS1525: Unexpected symbol
> > `end-of-file', expecting `end-of-file'
> > System/TimeZoneInfo.Android.cs(737,246): error CS1525: Unexpected symbol
> > `end-of-file', expecting `end-of-file'
> > System/TimeZoneInfo.MonoTouch.cs(109,246): error CS1525: Unexpected
> symbol
> > `end-of-file', expecting `end-of-file'
> > System.Globalization/RegionInfo.MonoTouch.cs(54,246): error CS1525:
> > Unexpected symbol `end-of-file', expecting `end-of-file'
> > System.IO/LogcatTextWriter.cs(80,246): error CS1525: Unexpected symbol
> > `end-of-file', expecting `end-of-file'
> > System.Security/SecurityManager_mobile.cs(215,246): error CS1525:
> > Unexpected symbol `end-of-file', expecting `end-of-file'
> > System.Security.Cryptography/CryptoConfig.fullaot.cs(239,246): error
> > CS1525: Unexpected symbol `end-of-file', expecting `end-of-file'
> >
> ../../../external/referencesource/mscorlib/system/resources/__hresults.cs(2
> > 6,246): error CS1525: Unexpected symbol `end-of-file', expecting
> > `end-of-file'
> >
> ../../../external/referencesource/mscorlib/system/resources/looselylinkedre
> > sourcereference.cs(89,246): error CS1525: Unexpected symbol
> `end-of-file',
> > expecting `end-of-file'
> > Compilation failed: 12 error(s), 0 warnings
> >
> > I am at a loss to work out WTF is happening. I like the way the error
> > message keeps a straight face when it complains about encountering
> > “end-of-file” symbol when it was really expecting “end-of-file”!
> >
> >
> > Any suggestions about where to look?
> >
> > Neale
> >
> > ___
> > 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] Strange build problem

[Alexander Köplinger]

Hey,

Are you sure you’re running this on the nealef-s390x-2 machine and not 
nealef-s390x-1 ?
This sounds exactly like the problem with the ancient gcc we ran into on the -1 
machine, that’s why we’re only using the -2 machine on Jenkins now.

In fact, my IRC log shows we discussed this back in October 2015:

 neale: still no success compiling on nealef-s390x-1, with -O2
 
https://jenkins.mono-project.com/job/z/label=centos-s390x/2065/parsed_console/log_content.html#ERROR1
 System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol 
`end-of-file', expecting `end-of-file'
 ._.
 directhex: At least it got rid of the inline errors problem ;-)
 yes this is technically true
 I've never seen this particular problem before
 maybe a checkout problem? want to delete the workspace?
 The z workspace?
 hmm, it affects all files that are completely #ifdefed out
 Yup
 neale: yes
 z gone\
 it's renamed to "z" because the same job also handles windows 
builds, and windows has a silly low PATH_MAX
 which the old name was causing errors for
 Ah
 so single-char job names if they run on windows
 I ran a build in 
/home/jenkins/workspace/test-mono-mainline-communityarchitectures/label/centos-s390x
 (From Sep28) and forced a recompile of Android.cs which has the same ifdef 
situation and the build was clean.
 that job name is the old "z" job
 see, very long name, poor windows
 Understood, just wanted to point out that a build used to work for 
those files

AFAIK we never got past that problem on the -1 machine, so we just stopped 
using it.

- Alex

> Am 20.01.2016 um 03:13 schrieb Neale Ferguson :
> 
> Re: bugzilla 37781
> 
> On the same virtual machine in which the Jenkins bot successfully builds
> mono, I am encountering failures of an unusual type. Thinking it might be
> a hangover to something in the account’s home directory, I created a
> completely new account, cloned from master, configured and built. It craps
> out with the following:
> 
> MCS [build] mscorlib.dll
> Assembly/AssemblyInfo.cs(33,5): error CS8025: Parsing error
> System/AndroidPlatform.cs(66,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Console.iOS.cs(127,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/Guid.MonoTouch.cs(24,253): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.Android.cs(737,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System/TimeZoneInfo.MonoTouch.cs(109,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Globalization/RegionInfo.MonoTouch.cs(54,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.IO/LogcatTextWriter.cs(80,246): error CS1525: Unexpected symbol
> `end-of-file', expecting `end-of-file'
> System.Security/SecurityManager_mobile.cs(215,246): error CS1525:
> Unexpected symbol `end-of-file', expecting `end-of-file'
> System.Security.Cryptography/CryptoConfig.fullaot.cs(239,246): error
> CS1525: Unexpected symbol `end-of-file', expecting `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/__hresults.cs(2
> 6,246): error CS1525: Unexpected symbol `end-of-file', expecting
> `end-of-file'
> ../../../external/referencesource/mscorlib/system/resources/looselylinkedre
> sourcereference.cs(89,246): error CS1525: Unexpected symbol `end-of-file',
> expecting `end-of-file'
> Compilation failed: 12 error(s), 0 warnings
> 
> I am at a loss to work out WTF is happening. I like the way the error
> message keeps a straight face when it complains about encountering
> “end-of-file” symbol when it was really expecting “end-of-file”!
> 
> 
> Any suggestions about where to look?
> 
> Neale
> 
> ___
> 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] Bug 10784

[Alexander Köplinger]

Please open multiple pull requests for unrelated commits, it's easier to
keep track that way.

We do the actual code review comments on GitHub, but you can use the
mailing list for discussion if you want.

- Alex

2016-01-06 19:17 GMT+01:00 Jamie Venning <
jamie_venn...@technologyonecorp.com>:

> I'll make those changes and submit the pull request, though it may take a
> day or two for me to be able to sign the CLA.
> As for testing this 'properly' -- I gave it a go and it was just as
> ridiculous as you'd think and I had a hard time making it break.
>
> If I am fixing multiple bugs/issues/etc, is it ok for me to lump them into
> pull requests of 2-3 issues (1 commit per issue) or is it preferred to have
> unrelated commits in separate pull requests? (assume that I don't mind
> commits being held up by a pull request being knocked back for
> revisions/improvements) And forgive me, but I am new to mailing lists --
> should I send an email for every pull request? Is the mailing list the
> preferred place to do things like code-review?
>
> On 7 January 2016 at 02:49, Andi McClure  wrote:
>
>> Jamie:
>>
>> A good place to start would be with running the automated tests to see if
>> there are any new failures. You can quickly run the most relevant tests for
>> this change with:
>> make -C mono/mini check
>> make -C mono/tests check
>> make -C mcs/class/corlib check
>> If you run `make check` at the toplevel, this will run all tests. This
>> will take a pretty long time however (and if you submit a pull request our
>> jenkins bot will do it for you).
>>
>> We normally accept patches through pull requests to mono/mono on Github.
>> When your patch is ready (which it seems to me to basically be, if the
>> tests pass) you should sign the CLA ( https://cla.xamarin.com/ ) and
>> then open a pull request so it can be merged.
>>
>> Two comments I would leave if I saw this as a pull request are:
>> g_assert (iid <= 10);
>> This number is pretty arbitrary. Please make a constant like
>> LOADED_INTERFACES_MAX to hold it instead of just putting it inline the
>> code. Also, I think you might as well bump the value up to 2^31-2, since
>> that's the highest number there's a technical reason not to go above…
>> Also, "however haven't bitset code still uses" seems to be a typo.
>> g_assert(icount < 65535);
>> This can and I think should be <=
>>
>> I wonder if there's a non-ridiculous way to add a new automated test for
>> a program with >65535 interfaces.
>>
>> Thanks
>>
>> On Tue, Jan 5, 2016 at 9:04 PM, Jamie Venning <
>> jamie_venn...@technologyonecorp.com> wrote:
>>
>>> I've gone through and changed interface_id to a guint32, along with
>>> max_interface_id, leaving interface_count (I didn't see the need for it to
>>> be increased).
>>>
>>> I've forked the repo and have it over at
>>> https://github.com/tastywheattasteslikechicken/mono/commit/6e7f1d94eb07822fb7bf5687b67df5076f969818
>>> Are there any other considerations or things that may be missed?
>>>
>>> On Wed, Jan 6, 2016 at 12:51 AM, Jamie Venning <
>>> jamie_venn...@technologyonecorp.com> wrote:
>>>
>>>> Yeah, what I'm chasing are the best ways to cause failures without this
>>>> assertion -- that way as I go through and fix things I can be more
>>>> confident that things haven't been missed.
>>>>
>>>> On Tue, Jan 5, 2016 at 11:45 PM, Alexander Köplinger <
>>>> alexander.koeplin...@xamarin.com> wrote:
>>>>
>>>>> I don't think it's as easy as removing the assert.
>>>>>
>>>>> For one, the interface ID returned by mono_get_unique_iid() is stored
>>>>> as a guint16 (
>>>>> https://github.com/mono/mono/blob/36c7332104eb5250a93079ae77c2e0dbf12c6c9a/mono/metadata/class-internals.h#L344)
>>>>> which means you only have 0-65,535 values there. I'm not familiar enough
>>>>> with the runtime codebase to say which other problems you'll run into if
>>>>> you try to fix this.
>>>>>
>>>>> - Alex
>>>>>
>>>>> 2016-01-05 8:38 GMT+01:00 Jamie Venning <
>>>>> jamie_venn...@technologyonecorp.com>:
>>>>>
>>>>>> Good Morning.
>>>>>>
>>>>>> Bug 10784 (
>>>>>> https://bugzilla.xamarin.com/show_bug.cgi?format=multiple&

Re: [Mono-dev] Bug 10784

[Alexander Köplinger]

I don't think it's as easy as removing the assert.

For one, the interface ID returned by mono_get_unique_iid() is stored as a
guint16 (
https://github.com/mono/mono/blob/36c7332104eb5250a93079ae77c2e0dbf12c6c9a/mono/metadata/class-internals.h#L344)
which means you only have 0-65,535 values there. I'm not familiar enough
with the runtime codebase to say which other problems you'll run into if
you try to fix this.

- Alex

2016-01-05 8:38 GMT+01:00 Jamie Venning :

> Good Morning.
>
> Bug 10784 (
> https://bugzilla.xamarin.com/show_bug.cgi?format=multiple&id=10784) is a
> major blocker for me, and a big obstacle for larger applications moving
> from .NET to Mono. Because I need this fixed, I am prepared to fix it
> myself.
>
> I'm wondering if anyone knowledgeable in this area could answer these few,
> short questions just to confirm a few things.
>
> Removing the offending assertion from class.c, and running generated test
> cases that previously triggered it, I did not notice any incorrect
> behaviour in terms of reflection, the 'is' operator failing, or the wrong
> implementation of functions being used. Is there anywhere that I should be
> looking in particular or any particular type of tests I can use to expose
> an underlying fault that removing this assertion causes?
>
> Is it possible that this assertion is vestigial or unnecessary?
>
> --
>
> James Venning
> Research & Development - Ci2 - Product
> Phone: +61 7 3167 7300 | Fax: +61 7 3167 7301 Address: Level 11,
> TechnologyOne HQ, 540 Wickham Street, Fortitude Valley QLD 4006 (PO Box 96
> Fortitude Valley QLD 4006) Email: jamie_venn...@technologyonecorp.com
> Web: TechnologyOneCorp.com 
>
> 
>
> Financials | Human Resource & Payroll | Supply Chain | Corporate
> Performance Management | Property & Rating | Student Management | Asset
> Management | Enterprise Content Management | Customer Relationship
> Management | Consulting Services
>
> *TechnologyOne (ASX:TNE) is Australia's largest publicly listed software
> company, with offices across six countries including each state and
> territory of Australia, as well as New Zealand, the South Pacific, Asia and
> the United Kingdom. For 25 years, we have been providing powerful and
> deeply integrated enterprise software solutions that are used every day by
> more than 1000 leading corporations, government departments and statutory
> authorities.*
>
> TechnologyOne accepts no liability for any damage caused by this email or
> its attachments. The information in this email is only for the intended
> recipient and may contain confidential and/or privileged material. If you
> received this in error, please kindly notify the sender and delete this
> email and any attachments from your system. Opinions, conclusions and other
> information in this message that do not relate to the official business of
> the company shall be understood as neither given nor endorsed by it. If you
> believe that you have been spammed please email
> stop_s...@technologyonecorp.com .
>
> ___
> 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] Proposal: Change SignCode default from MD5 to SHA1

[Alexander Köplinger]

Ok, there we go: https://github.com/mono/mono/pull/2350 
<https://github.com/mono/mono/pull/2350>

- Alex

> Am 15.12.2015 um 20:37 schrieb Sebastien Pouliot 
> :
> 
> Hey,
> 
> There should not be any issues changing the default to SHA1, that was an 
> already tested configuration. However a change to SHA256 would require some 
> testing, as some constants might be missing (or did not even exists back in 
> 2003 ;-).
> 
> Sebastien
> 
> On Tue, Dec 15, 2015 at 2:28 PM, Eric Lawrence  <mailto:bay...@gmail.com>> wrote:
> As far as I know, all systems that support MD5 Authenticode signatures also 
> support SHA1 signatures, so breakage from this change seems quite unlikely. 
> 
> (Alas, this is not true of SHA256, which is only supported on modern versions 
> of Windows, and not presently supported by signcode.exe at all).
> 
> On Tue, Dec 15, 2015 at 1:12 PM, Alexander Köplinger 
> mailto:alexander.koeplin...@xamarin.com>> 
> wrote:
> I like it. Does changing the default have any backwards compatibility issues?
> 
> Looks like the default comes from 
> https://github.com/mono/mono/blob/b7a308f660de8174b64697a422abfc7315d07b8c/mcs/class/Mono.Security/Mono.Security.Authenticode/AuthenticodeFormatter.cs#L80
>  
> <https://github.com/mono/mono/blob/b7a308f660de8174b64697a422abfc7315d07b8c/mcs/class/Mono.Security/Mono.Security.Authenticode/AuthenticodeFormatter.cs#L80>
>  so we’d need to decide if we should change it there or make a targeted fix 
> just for signcode.
> 
> - Alex
> 
>> Am 15.12.2015 um 20:00 schrieb Eric Lawrence > <mailto:bay...@gmail.com>>:
>> 
>> (resend, as Miguel suggested I should join the list)
>> 
>> Today, the signcode application distributed with Mono defaults to using MD5 
>> for Authenticode signing. This has resulted in vulnerable signatures on at 
>> least two broadly distributed projects (CoPilot and WordPress Desktop; see 
>> http://textslashplain.com/2015/12/15/hashes-and-code-signing/ 
>> <http://textslashplain.com/2015/12/15/hashes-and-code-signing/>).
>>  
>> MD5 signatures are dangerous because the collision attacks against MD5 get 
>> better and cheaper with each passing day, and any MD5 signature is 
>> vulnerable to abuse for the lifetime of the signing certificate—the package 
>> WordPress signed last week could be exploited until 11/21/2018 unless 
>> Automattic is willing to revoke their signing certificate before that time 
>> (costly).
>>  
>> SHA1 is considerably stronger than MD5 and signcode already supports it; it 
>> just needs to be made default. The command line argument (-a md5) could be 
>> used for anyone that really needs an MD5 signature for any reason.
>>  
>> Thanks for your consideration!
>>  
>> -Eric Lawrence
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com <mailto:Mono-devel-list@lists.ximian.com>
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list 
>> <http://lists.ximian.com/mailman/listinfo/mono-devel-list>
> 
> 
> 
> 
> -- 
> Eric Lawrence
> Bayden Systems
> http://www.bayden.com <http://www.bayden.com/>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com <mailto:Mono-devel-list@lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list 
> <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] Proposal: Change SignCode default from MD5 to SHA1

[Alexander Köplinger]

I like it. Does changing the default have any backwards compatibility issues?

Looks like the default comes from 
https://github.com/mono/mono/blob/b7a308f660de8174b64697a422abfc7315d07b8c/mcs/class/Mono.Security/Mono.Security.Authenticode/AuthenticodeFormatter.cs#L80
 

 so we’d need to decide if we should change it there or make a targeted fix 
just for signcode.

- Alex

> Am 15.12.2015 um 20:00 schrieb Eric Lawrence :
> 
> (resend, as Miguel suggested I should join the list)
> 
> Today, the signcode application distributed with Mono defaults to using MD5 
> for Authenticode signing. This has resulted in vulnerable signatures on at 
> least two broadly distributed projects (CoPilot and WordPress Desktop; see 
> http://textslashplain.com/2015/12/15/hashes-and-code-signing/ 
> ).
>  
> MD5 signatures are dangerous because the collision attacks against MD5 get 
> better and cheaper with each passing day, and any MD5 signature is vulnerable 
> to abuse for the lifetime of the signing certificate—the package WordPress 
> signed last week could be exploited until 11/21/2018 unless Automattic is 
> willing to revoke their signing certificate before that time (costly).
>  
> SHA1 is considerably stronger than MD5 and signcode already supports it; it 
> just needs to be made default. The command line argument (-a md5) could be 
> used for anyone that really needs an MD5 signature for any reason.
>  
> Thanks for your consideration!
>  
> -Eric Lawrence
> ___
> 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] Error compiling master - Dynamic does not exist"

[Alexander Köplinger]

I’m not seeing it with monolite and Jenkins seems to be fine as well. Try a 
clean build?

- Alex

> Am 03.12.2015 um 01:50 schrieb Andres G. Aragoneses :
> 
> I'm also getting this, even with the latest monolite.
> 
> Any ideas?
> 
> 
> On 09/02/15 02:03, Martin Thwaites wrote:
>> Hi all,
>> 
>> I'm doing some work on mono, and everything was working fine until I did
>> a rebase against master, and now I'm getting an error when running
>> make.  I haven't touched anything at this level, so I don't think it's
>> something I've done, so thought I'd check first.
>> 
>> Bootstrap compiler: Mono C# compiler version 3.10.1.0
>> MCS [basic] basic.exe
>> dynamic.cs(17,7): error CS0234: The type or namespace name `Dynamic'
>> does not exist in the namespace `System'. Are you missing an assembly
>> reference?
>> cs-parser.jay(144,8): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> assembly.cs(1186,94): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> dynamic.cs(75,12): error CS0246: The type or namespace name
>> `DynamicMetaObject' could not be found. Are you missing an assembly
>> reference?
>> dynamic.cs(77,34): error CS0246: The type or namespace name
>> `DynamicMetaObject' could not be found. Are you missing an assembly
>> reference?
>> dynamic.cs(88,10): error CS0246: The type or namespace name
>> `DynamicMetaObject' could not be found. Are you missing an assembly
>> reference?
>> eval.cs(69,31): error CS0246: The type or namespace name `Tuple' could
>> not be found. Are you missing an assembly reference?
>> eval.cs(849,12): error CS0246: The type or namespace name `Tuple' could
>> not be found. Are you missing an assembly reference?
>> ikvm.cs(234,17): error CS0246: The type or namespace name `Tuple' could
>> not be found. Are you missing an assembly reference?
>> location.cs(506,51): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(512,51): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(518,51): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(524,51): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(414,26): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(417,34): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(422,34): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(428,34): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> location.cs(434,34): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> settings.cs(88,15): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> statement.cs(4716,8): error CS0246: The type or namespace name `Tuple'
>> could not be found. Are you missing an assembly reference?
>> 
>> Thanks,
>> Martin
>> 
>> 
>> ___
>> 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] [Mono-list] Access to (recent) older versions of mono in the download.mono-project.com debian repository

[Alexander Köplinger]

Hi!

We discussed this and agree that there should be a way to get a specific
version from the repositories.
The only problem is that we can't fix it retroactively because the
repository management software doesn't support it.

Going forward and starting with the upcoming Mono 4.2 release, we'll
snapshot each new release using it's 4-part version, i.e. you'll be able to
use the following snapshot repos:

wheezy/snapshots/X.XX.X.XX  <-- specific 4-part version
wheezy/snapshots/X.XX.X <-- symlink to latest 4-part version
wheezy/snapshots/X.XX <-- symlink to latest 4-part version

We're still discussing whether we should also snapshot the ~0xamarinX
pushes. Those are used to correct packaging issues that don't warrant a
separate release. We're currently leaning towards not snapshotting those.

It'd be great to get your feedback on this, does the above work for your
use case?

Thanks!

- Alex


2015-11-13 11:21 GMT+01:00 River Satya :

> Thanks Timotheus, but the issue is not that we're getting unrequested
> upgrades; Ubuntu does not do /that/ fortunately!!
>
> The issue is that when we deploy a new server, I want to know what version
> it is getting. I want the new servers to have the same mono version as the
> existing ones.
>
> Hope this is clear now.
>
> Thanks,
>
> River
>
> On 13 November 2015 at 18:10, Timotheus Pokorra [via Mono] <[hidden email]
> > wrote:
>
>> > out deployment broke again :( ). I'm really happy to see new versions
>> > getting pushed, but we need to be able to make conscious decisions
>> about
>> > if/when to upgrade.
>> You can comment the xamarin repo line in your /etc/apt sources list,
>> so that it will not check for new updates.
>> ___
>> Mono-list maillist  -  [hidden email]
>> 
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://mono.1490590.n4.nabble.com/Access-to-recent-older-versions-of-mono-in-the-download-mono-project-com-debian-repository-tp4666761p4666960.html
>> To unsubscribe from Access to (recent) older versions of mono in the
>> download.mono-project.com debian repository, click here.
>> NAML
>> 
>>
>
>
> --
> View this message in context: Re: Access to (recent) older versions of
> mono in the download.mono-project.com debian repository
> 
> Sent from the Mono - General mailing list archive
>  at
> Nabble.com.
>
> ___
> Mono-list maillist  -  mono-l...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Old version of Entity Framework bundled with Mono

[Alexander Köplinger]

Yep, and that change shipped in Mono 4.0, so it's long gone :)

> To: mono-devel-list@lists.ximian.com
> From: kno...@gmail.com
> Date: Sat, 8 Aug 2015 14:32:47 +0200
> Subject: Re: [Mono-dev] Old version of Entity Framework bundled with Mono
> 
> On 08/08/15 06:52, Daniel Lo Nigro wrote:
> > I recently spend a while debugging an issue I was having with Entity
> > Framework, only to find that it was happening because Mono ships with a
> > beta version in its GAC. Would it be possible to either update this to
> > the latest release build, or stop shipping with it and instead let
> > people use their own version from NuGet? There's some bugs in the
> > bundled beta that were resolved in the final release, and it's lacking
> > some of the classes (for example, DbConfiguration is missing). Shipping
> > an older version in the GAC is problematic as a GAC'd version of an
> > assembly is always preferred over a local copy, so I needed to
> > completely delete it from the GAC to get my site to work properly.
> 
> 
> This has already been done in the master branch:
> 
> https://github.com/mono/mono/commit/c1bbee0b95f300df9d5d2d9e6bb3f3c162d73406
> 
> ___
> 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] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

[Alexander Köplinger]

You can build the MDK with 
https://github.com/mono/bockbuild#the-mono-mac-distribution, but I'm not sure 
if that includes debug symbols (I think it does).
-- Alex

> From: jonat...@mugginsoft.com
> Date: Wed, 5 Aug 2015 18:06:37 +0100
> To: Mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an  
> issue with embedded Mono 4.0.2.5
> 
> 
> > On 5 Aug 2015, at 02:12, jean-michel.perr...@csiro.au wrote:
> > 
> > I am trying to debug C code, mostly to step through the mono runtime itself.
> I too would like to debug the Mono runtime itself and so would really, 
> really, really like to able to build an MDK with debug symbols and source 
> code references.
> 
> Why do I need to debug the runtime?
> I have written an Obj-C > C# bridge utilising the runtime and in some 
> situations I cannot figure out what the correct embedded API function 
> signatures are for more complex generic managed methods. Being able to debug 
> the runtime would give me some insight into what is going on in the method 
> signature search process.
> 
> >  That said, I would not at all refuse a howto guide for mixed mode (C and 
> > C#) debugging on Linux (not possible so far as I know). I may try to give a 
> > try on Windows with Visual Studio, but as a fallback option as this issue 
> > may not be reproducible on it anyway.
> 
> Here is my take on debugging Mono based on working on OS X.
> 
> C
> ==
> 
> On the Obj-C side (Obj-C is a strict superset of C) I should be able to step 
> into the Mono runtime code via the Xcode side if my Mono runtime build 
> supported debug symbols and their source code references. I reckon that most 
> C IDEs should be fit to do the same.
> 
> 
> C#
> ==
> 
> I don’t know of a way to seamlessly debug both C and C# via the same IDE on 
> OS X (perhaps VS can so this on windows).
> To debug the managed code in my OS X app I do roughly the following (more 
> detail follows in the notes below).
> 
> 1. Configure the OS X app embedded Mono code to use the Mono soft debugger 
> (this is a remote capable software debugger that runs over TCP-IP see 
> http://www.mono-project.com/docs/advanced/runtime/docs/soft-debugger/).
> 2. Run my OS X outside of my Xcode IDE. If I don’t do this then the signals 
> generated by the debugee tend to get caught by the IDE debugger rather than 
> the Mono soft debugger.
> 3. Fire up Xamarin Studio (XS) on a Windows machine (in my case a Windows VM 
> on the same physical machine but a networked base PC should work just fine 
> too).
> 4. In XS connect to the remote debugger, set breakpoints etc.
> 5. Exercise the OS X app and trigger breakpoints in XS.
> 
> Getting the soft debugger/Xamarin setup correctly can be fiddly but it does 
> work.
> It may be possible to debug the managed code by Using Xamarin Studio on OS X 
> or Linux but in my case (as I was building the Managed code assemblies on the 
> Windows VM anyway) it was easiest to run XS on Windows.
> 
> Debugging Mono Embedded API
> ===
> 
> The embedded managed code can be debugged (including breakpoints and single 
> stepping) using Xamarin Studio.
> 
> 1. Config OS X app to attach to Mono soft Debugger.
> 
> Xamarin Studio must be running on machine with IP 192.168.1.72 (in this case 
> my windows VM)
>  [DBManagedEnvironment setRuntimeOptions:@{@"address" : @"192.168.1.72", 
> @"port" : @"1", @"loglevel" : @"0"}];
> 
> 2. Call DBManagedEnvironment +setRuntimeOptions: with IP address and port of 
> Windows VM running the Xamarin Studio debugger.
> 
> + (void)setRuntimeOptions:(NSDictionary *)options
> {
> // NOTE: be sure to call this before -initWithDomainName
> 
> // for info on these options see man mono
> // the debugger can be configured either as a client or a server
> NSString *address = options[@"address"]?:@"127.0.0.1";
> NSString *port = options[@"port"]?:@"1";
> NSString *server = options[@"server"]?:@"n";
> NSString *suspend = options[@"suspend"]?:@"y";
> NSString *loglevel = options[@"loglevel"]?:@"1";
> NSString *timeout = options[@"timeout"]?:@"10";
> 
> NSString *agent = [NSString 
> stringWithFormat:@"--debugger-agent=transport=dt_socket,address=%@:%@,server=%@,suspend=%@,loglevel=%@,timeout=%@",
>  address, port, server, suspend, loglevel,timeout];
> const char* jit_options[] = {
> "--soft-breakpoints",
> [agent UTF8String]
> };
> 
> mono_jit_parse_options(2, (char**)jit_options);
> 
> mono_debug_init(MONO_DEBUG_FORMAT_MONO);
> }
> 
> see 
> https://github.com/ThesaurusSoftware/Dubrovnik/blob/master/Framework/XCode/DBManagedEnvironment.m#L167
> 
> 
> 3. Run app outside of Xcode. The app will pause if the remote debugger is not 
> responding.
> 4. Run Xamarin Studio (preconfigure env var to enable the soft debug menu if 
> it is not visible) on the VM and load the solution being debugged on OS X.
> 5. Set start up project as a

Re: [Mono-dev] Update strangeness

[Alexander Köplinger]

Please note that even though that commit was authored on May 12, it only went 
into master with https://github.com/mono/mono/pull/1929 about 9 hours ago.
-- Alex

> From: ne...@sinenomine.net
> To: mono-devel-list@lists.ximian.com
> Date: Thu, 30 Jul 2015 10:46:33 +
> Subject: [Mono-dev] Update strangeness
> 
> 9ffebc9d4e13bebe456b05fad1fd85e4f3c7f0d2 (May 12) introduced this piece of
> code:
> -   else
> -   start = get_delegate_invoke_impl (TRUE, 0, NULL,
> FALSE);
> +   } else
> +   MonoTrampInfo *info;
> +   start = get_delegate_invoke_impl (&info, TRUE, 0,
> FALSE);
> +   mono_tramp_info_register (info);
> +   }
> 
> I have no idea how it's been being built cleanly ever since. I am adding
> the '{' and will commit shortly, but I am puzzled.
> 
> I'm also seeing these failures during make check for the first time:
> 
> Checking unintended native code changes in objects.exe without AOT
> 23c23
> < Method Tests:.cctor () (code length 202) [objects.exe]
> ---
> > Method Tests:.cctor () (code length 196) [objects.exe]
> 40c40
> < Method Tests:int_to_r4_inner (int) (code length 142) [objects.exe]
> —
> 
> 
> Other than that the other tests are passing except for
> delegate-async-exit.exe which is segving in
> major_copy_or_mark_object_no_evacuation during System.Environment.Exit
> processing.
> 
> The reason I am raising these issues to the list is that I note there has
> been a bit of reverting/reapplying that seem to have affected architecture
> dependent code.
> 
> Neale
> 
> ___
> 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] Problem with PNG transparancy on current Debian Unstable

[Alexander Köplinger]

There aren't that many commits for pngcodec.c in the last 4 years (which is 
when 2.10 was tagged), so it's probably one of those: 
https://github.com/mono/libgdiplus/commits/master/src/pngcodec.c . Shouldn't be 
too hard to figure out which one broke your scenario.
-- Alex
 
> To: kno...@gmail.com
> Date: Tue, 9 Jun 2015 12:31:43 +0200
> From: benja...@anderdonau.de
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Problem with PNG transparancy on current Debian   
> Unstable
> 
> Alright, I compiled libgdiplus 2.10 and put it into /opt/libgdiplus2.10/
> I then did the following:
> LD_LIBRARY_PATH=/opt/libgdiplus2.10/lib/
> export LD_LIBRARY_PATH
> ./transparancy.exe
> 
> And it works fine. So I guess there is a regression somewhere in 
> libgdiplus between 2.10 and today.
> 
> 
> Am 2015-06-09 12:17, schrieb Benjamin Schieder:
> > I have this version on squeeze:
> > ii  libgdiplus   2.10-3+b1
> > armelinterface library for System.Drawing of Mono
> > 
> > And this version on unstable:
> > ii  libgdiplus
> > 3.12-0xamarin1+jpeg62.1amd64interface library
> > for System.Drawing of Mono
> > 
> > I'll try to compile a 2.10 version of libgdiplus, but that's a lot of
> > difference and probably way above my head to bisect correctly.
> > 
> > Am 2015-06-09 11:50, schrieb Andres G. Aragoneses:
> >> You could check what version of
> >> libgdiplus(https://github.com/mono/libgdiplus) did Debian Squeeze
> >> include, and try to run a custom new mono built from sources, with an
> >> older libgdiplus, to confirm that it is a libgdiplus regression. If it
> >> is, then after that you could try to bisect the commit that caused it.
> >> 
> >> On 09/06/15 11:40, Benjamin Schieder wrote:
> >>> Hello Alex.
> >>> 
> >>> I have followed those instructions and done a dist-upgrade, but after
> >>> re-compiling with mcs the problem persists unchanged. I have the
> >>> following versions now:
> >>> 
> >>> [11:38:29][blindcoder@flora:~/Downloads/PZ/MapMap]$ mcs --version
> >>> Mono C# compiler version 4.0.1.0
> >>> [11:38:34][blindcoder@flora:~/Downloads/PZ/MapMap]$ mono --version
> >>> Mono JIT compiler version 4.0.1 (tarball Thu May 28 09:08:28 UTC 
> >>> 2015)
> >>> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> >>> www.mono-project.com
> >>>  TLS:   __thread
> >>>  SIGSEGV:   altstack
> >>>  Notifications: epoll
> >>>  Architecture:  amd64
> >>>  Disabled:  none
> >>>  Misc:  softdebug
> >>>  LLVM:  supported, not enabled.
> >>>  GC:sgen
> >>> [11:38:37][blindcoder@flora:~/Downloads/PZ/MapMap]$ cli --version
> >>> Mono JIT compiler version 4.0.1 (tarball Thu May 28 09:08:28 UTC 
> >>> 2015)
> >>> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> >>> www.mono-project.com
> >>>  TLS:   __thread
> >>>  SIGSEGV:   altstack
> >>>  Notifications: epoll
> >>>  Architecture:  amd64
> >>>  Disabled:  none
> >>>  Misc:  softdebug
> >>>  LLVM:  supported, not enabled.
> >>>  GC:sgen
> >>> 
> >>> Kind regards,
> >>> Benjamin
> >>> 
> >>> Am 2015-06-09 11:07, schrieb Alexander Köplinger:
> >>> 
> >>>> It works fine here with latest Mono 4.0.1.44 on Ubuntu. Can you try
> >>>> upgrading to latest Mono from Xamarin by following
> >>>> http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives
> >>>>  
> >>>> ?
> >>>> 
> >>>> I suspect this has something to do with libgdiplus (the native 
> >>>> library
> >>>> most of the System.Drawing code calls into).
> >>>> 
> >>>> -- Alex
> >>>> 
> >>>> > To: mono-devel-list@lists.ximian.com
> >>>> > Date: Tue, 9 Jun 2015 10:15:02 +0200
> >>>> > From: benja...@anderdonau.de
> >>>> > Subject: [Mono-dev] Problem with PNG transparancy on current Debian
> >>>> Unstable
> >>>> >
> >>>> > Hello.
> >>>

Re: [Mono-dev] Problem with PNG transparancy on current Debian Unstable

[Alexander Köplinger]

It works fine here with latest Mono 4.0.1.44 on Ubuntu. Can you try upgrading 
to latest Mono from Xamarin by following 
http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives
 ?
 
I suspect this has something to do with libgdiplus (the native library most of 
the System.Drawing code calls into).
 
-- Alex
 
> To: mono-devel-list@lists.ximian.com
> Date: Tue, 9 Jun 2015 10:15:02 +0200
> From: benja...@anderdonau.de
> Subject: [Mono-dev] Problem with PNG transparancy on current Debian Unstable
> 
> Hello.
> 
> I have a problem with PNG transparancy in mono on current Debian 
> Unstable.
> I created a small example (4 kB download) with minimal code and two 
> example images:
> https://oc.anderdonau.de/index.php/s/VwTAlcjETG6j3XP
> 
> Running this example on a current Debian Unstable results in this - bad 
> - image:
> https://oc.anderdonau.de/index.php/s/AtVtba0tpSk4bn8
> 
> Running the same code on an old Debian Squeeze (on armel) results in 
> this - correct - image:
> https://oc.anderdonau.de/index.php/s/eqhmXh9qpBbg0WW
> 
> Can someone help me with this issue?
> 
> 
> Kind regards,
> Benjamin
> -- 
> Jabber: blindco...@jabber.ccc.de
> Twitter: https://twitter.com/blind_coder
> Web: http://www.benjamin-schieder.de/
> ___
> 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] mono 4.0.0 xbuild won't build project

[Alexander Köplinger]

It's just a simple helloworld as well, but with datetime output:
 
using System;
 
namespace HelloWorld {
public class Program {
public static void Main(string[] args) {
Console.WriteLine("Hello World " + DateTime.Now);
}
}
}
 
If this doesn't work, then there's no point trying to get xbuild working as the 
code above is as basic as it gets.
 
-- Alex 
 
Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
From: chasel...@gmail.com
Date: Fri, 5 Jun 2015 09:43:07 -0500
To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com

Unfortunately the latest build...with ncurses this time...didn't change 
anything.  Same output for xbuild.



Alexander, could you send the code for the Project.exe you sent me?

On June 5, 2015 3:25:42 AM CDT, "Alexander Köplinger" 
 wrote:



Can you try this simple Hello World exe to confirm basic Mono is working and 
it's something specific to xbuild: 
https://dl.dropboxusercontent.com/u/21102229/Program.zip (it just prints the 
current date).
 
I believe there's some terminal requirements, but not sure. Redirecting output 
to a file might work.
 
From: chasel...@gmail.com
Date: Thu, 4 Jun 2015 19:56:01 -0500
To: sushihango...@outlook.com; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] mono 4.0.0 xbuild won't build project

I tried it just now and I get the same result as before, unfortunately.



Is there a terminfo/ncurses requirement for xbuild?  Or for mono in general? 
The rebuild I mentioned earlier was done in order to make sure -lncurses and 
all related headers and libs were included but it's possible I left something 
out and need to re-build again.



Additionally, is there a terminal tyoe requirement for xbuild?  The android 
environment i'm using only comes with two types but I;ve got a working tic and 
sources so I can always install more.

On June 4, 2015 6:51:00 PM CDT, Robert N  wrote:



I realized that my other mail was hosed, outlook in a browser does blow at 
times...
So I was wondering if you were able to run xbuild using the mono option -v, 
since xbuild /verbosity:diagnostic never spills even the first line of the diag 
text: Loading default tasks for ToolsVersion
Using mono_options -v 'should' dump about 6500 lines before even getting to the 
version/copyright notice... assuming something in there is causing a silent 
fault(?) and exit.
Win81Pro:Pash administrator$ MONO_OPTIONS="-v" xbuild Pash.proj |more
converting method System.OutOfMemoryException:.ctor (string)
Method System.OutOfMemoryException:.ctor (string) emitted at 0x4f7d20 to 
0x4f7d44 (code length 36) [xbuild.exe]
converting method (wrapper runtime-invoke) 
:runtime_invoke_void__this___object (object,intptr,intptr,intptr)
Method (wrapper runtime-invoke) :runtime_invoke_void__this___object 
(object,intptr,intptr,intptr) emitted at 0x4f7d60 to 0x4f7e38 (code length 216) 
[xbuild.exe]
converting method System.SystemException:.ctor (string)
Method System.SystemException:.ctor (string) emitted at 0x4f7e38 to 0x4f7e5c 
(code length 36) [xbuild.exe]
converting method System.Exception:.ctor (string)
Method System.Exception:.ctor (string) emitted at 0x4f7e68 to 0x4f7ea1 (code 
length 57) [xbuild.exe]
converting method System.NullReferenceException:.ctor (string)
Method System.NullReferenceException:.ctor (string) emitted at 0x4f7ea8 to 
0x4f7ecc (code length 36) [xbuild.exe]
converting method System.StackOverflowException:.ctor (string)
Method System.StackOverflowException:.ctor (string) emitted at 0x4f7ed0 to 
0x4f7eea (code length 26) [xbuild.exe]
converting method Mono.XBuild.CommandLine.MainClass:Main (string[])
Method Mono.XBuild.CommandLine.MainClass:Main (string[]) emitted at 0x4f7ef0 to 
0x4f7f52 (code length 98) [xbuild.exe]
converting method (wrapper runtime-invoke) :runtime_invoke_void_object 
(object,intptr,intptr,intptr)
Method (wrapper runtime-invoke) :runtime_invoke_void_object 
(object,intptr,intptr,intptr) emitted at 0x4f7f78 to 0x4f8044 (code length 204) 
[xbuild.exe]
converting method (wrapper alloc) object:AllocSmall (intptr,intptr)
Method (wrapper alloc) object:AllocSmall (intptr,intptr) emitted at 0x4f8050 to 
0x4f80b6 (code length 102) [xbuild.exe]
converting method Mono.XBuild.CommandLine.MainClass:.ctor ()
Method Mono.XBuild.CommandLine.MainClass:.ctor () emitted at 0x4f80b8 to 
0x4f8152 (code length 154) [xbuild.exe]
converting method 
Microsoft.Build.Utilities.ToolLocationHelper:GetPathToDotNetFramework 
(Microsoft.Build.Utilities.TargetDotNetFrameworkVersion)
Method Microsoft.Build.Utilities.ToolLocationHelper:GetPathToDotNetFramework 
(Microsoft.Build.Utilities.TargetDotNetFrameworkVersion) emitted at 0x4f8178 to 
0x4f81aa (code length 50) [xbuild.exe]

From: chasel...@gmail.com
Date: Thu, 4 Jun 2015 17:00:01 -0500
To: atsushi...@veritas-vos-liberabit.com; alan.mcgov...@gmail.com
CC: mono-devel-list@lists.ximian.com
Subje

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alexander Köplinger]

Name cannot begin with the 
' ' character, hexadecimal value 0x20. Line 1, position 2.

  0 Warning(s)
  1 Error(s)

Time Elapsed 00:00:00.0105090
-

Once I fixed the extraneous space between '<' and "Project", it printed 
Hello world as expected:


atsushi:~/Desktop$ /usr/bin/xbuild x.proj
XBuild Engine Version 12.0
Mono, Version 3.2.8.0
Copyright (C) 2005-2013 Various Mono authors

Build started 6/5/2015 2:11:17 AM.

Project "/home/atsushi/Desktop/x.proj" (default target(s)):
 Target Build:
 Hello, World!
Done building project "/home/atsushi/Desktop/x.proj".

Build succeeded.
  0 Warning(s)
  0 Error(s)

Time Elapsed 00:00:00.0708910


A precise repro steps would help inspecting possible bugs.

Atsushi Eno


On 2015年06月03日 19:31, Cyd Haselton wrote:
 Thing is xbuild doesn't even complain about the syntax errors in that 
 project. It doesn't do anything except for output version info then exit.

 I'll
pastebin the file ifthe rebuild I;m working on doesn;t resolve 
 the issue.

 Thanks!

 On June 3, 2015 6:18:11 AM CDT, Alan  wrote:

 Can you use a pastebin to attach the actual file you're trying to
 build? The text you attached has two syntax errors in it and would
 not work as-is.

 A slightly modified file works as expected for me:
 https://gist.github.com/alanmcgovern/c2772a9cafd0d6a5b5ee

 Hope that helps!
 Alan

 On 3 June 2015 at 11:54, Cyd Haselton mailto:chasel...@gmail.com>> wrote:

 I did try xbuild /t:Build Pash.proj. Same result.

 I will try the --trace xbuild after I rebuild mono again.


 On June 3, 2015 3:18:34 AM CDT, Alan
mailto:alan.mcgov...@gmail.com>> wrote:

 You didn't tell xbuild to build anything and you didn't
     set a default target in your proj file.

 Try `xbuild /t:Build Pash.proj`

 On 2 June 2015 at 23:29, Alexander Köplinger
 mailto:alex.koeplin...@outlook.com>> wrote:

 Yeah, but it's much easier on another machine since we
 got the official packages for Mono there :)

 Try running xbuild with "MONO_OPTIONS=--trace xbuild"
 to show if/what it does before it exits.




 Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build
 project
 From: chasel...@gmail.com <mailto:chasel...@gmail.com>
 
   Date: Tue, 2 Jun 2015 17:15:14 -0500
 To: alex.koeplin...@outlook.com
 <mailto:alex.koeplin...@outlook.com>;
 mono-devel-list@lists.ximian.com
 <mailto:mono-devel-list@lists.ximian.com>


 Excellent point.

 Then again...i'd have to install mono on another
 machine. Also, I kinda would like to figure out why
 xbuild is misbehaving on this one...

 On June 2, 2015 5:04:07 PM CDT, "Alexander Köplinger"
 mailto:alex.koeplin...@outlook.com>> wrote:

 No idea about the xbuild issue, but you should be
 able to build Pash on another machine and just
 copy over the .exe, it is managed code after
all ;)



 From: chasel...@gmail.com <mailto:chasel...@gmail.com>
 Date: Tue, 2 Jun 2015 16:54:19 -0500
 To: mono-devel-list@lists.ximian.com
 <mailto:mono-devel-list@lists.ximian.com>
 Subject: [Mono-dev] mono 4.0.0 xbuild won't build
 project

 Just built and installed mono 4.0 from sources.
 Basic "Hello World" console program builds and
 runs successfully but basic "Hello World" project
 (hello.proj) won't build; xbuild displays the
 banner and then exits with no errors and without
 building the project.

 Here's the hello.proj
 < Project
 
xmlns="http://schemas.microsoft.com/developer/msbuild/2003";>
 
<http://schemas.microsoft.com/developer/msbuild/2003%22%3e>;
 
 
 
 

 I;ve tried /verbosity:detailed and several other
 flags. I've tried running path/to/mono -v
 /path/to/xbuild.exe proj.proj. Same thing happens
 every time:

 /bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj
 XBuild Engine Version 12.0
 Mono, Version 4.0.0.0

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alexander Köplinger]

> You didn't tell xbuild to build anything and you didn't set a default target 
> in your proj file.
 
FYI, xbuild/msbuild probes for *.proj/*.sln and builds the first it finds when 
you omit the argument.
 
> Can you use a pastebin to attach the actual file you're trying to build?
 
The project is https://github.com/Pash-Project/Pash which builds fine on Linux 
with Mono on TravisCI, so I guess it's something specific to the xbuild on 
android environment, most likely some runtime issue.
-- Alex
 
Date: Wed, 3 Jun 2015 12:18:11 +0100
Subject: Re: [Mono-dev] mono 4.0.0 xbuild won't build project
From: alan.mcgov...@gmail.com
To: chasel...@gmail.com
CC: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com

Can you use a pastebin to attach the actual file you're trying to build? The 
text you attached has two syntax errors in it and would not work as-is.
A slightly modified file works as expected for me: 
https://gist.github.com/alanmcgovern/c2772a9cafd0d6a5b5ee

Hope that helps!
Alan
On 3 June 2015 at 11:54, Cyd Haselton  wrote:
I did try xbuild /t:Build Pash.proj.  Same result.



I will try the --trace xbuild after I rebuild mono again.

On June 3, 2015 3:18:34 AM CDT, Alan  wrote:
You didn't tell xbuild to build anything and you didn't set a default target in 
your proj file.
Try `xbuild /t:Build Pash.proj`
On 2 June 2015 at 23:29, Alexander Köplinger  
wrote:



Yeah, but it's much easier on another machine since we got the official 
packages for Mono there :)
 
Try running xbuild with "MONO_OPTIONS=--trace xbuild" to show if/what it does 
before it exits.


 
Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
From: chasel...@gmail.com
Date: Tue, 2 Jun 2015 17:15:14 -0500
To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com

Excellent point.



Then again...i'd have to install mono on another machine.  Also, I kinda would 
like to figure out why xbuild is misbehaving on this one...

On June 2, 2015 5:04:07 PM CDT, "Alexander Köplinger" 
 wrote:



No idea about the xbuild issue, but you should be able to build Pash on another 
machine and just copy over the .exe, it is managed code after all ;) 

 
From: chasel...@gmail.com
Date: Tue, 2 Jun 2015 16:54:19 -0500
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

Just built and installed mono 4.0 from sources.  Basic "Hello World" console 
program builds and runs successfully but basic "Hello World" project 
(hello.proj) won't build; xbuild displays the banner and then exits with no 
errors and without building the project.



Here's the hello.proj

< Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003";>;

 

  

 





I;ve tried /verbosity:detailed and several other flags.  I've tried running 
path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens every time:



/bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj

XBuild Engine Version 12.0

Mono, Version 4.0.0.0

Copyright (C) 2005-2013 Various Mono authors

/bld/pash/Pash-Project-Pash-bc07215 $



Please help...this is driving me crazy.




-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.

___

Mono-devel-list mailing list

Mono-devel-list@lists.ximian.com

http://lists.ximian.com/mailman/listinfo/mono-devel-list






-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alexander Köplinger]

Yeah, but it's much easier on another machine since we got the official 
packages for Mono there :)
 
Try running xbuild with "MONO_OPTIONS=--trace xbuild" to show if/what it does 
before it exits.

 
Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
From: chasel...@gmail.com
Date: Tue, 2 Jun 2015 17:15:14 -0500
To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com

Excellent point.



Then again...i'd have to install mono on another machine.  Also, I kinda would 
like to figure out why xbuild is misbehaving on this one...

On June 2, 2015 5:04:07 PM CDT, "Alexander Köplinger" 
 wrote:



No idea about the xbuild issue, but you should be able to build Pash on another 
machine and just copy over the .exe, it is managed code after all ;) 
 
From: chasel...@gmail.com
Date: Tue, 2 Jun 2015 16:54:19 -0500
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

Just built and installed mono 4.0 from sources.  Basic "Hello World" console 
program builds and runs successfully but basic "Hello World" project 
(hello.proj) won't build; xbuild displays the banner and then exits with no 
errors and without building the project.



Here's the hello.proj

< Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003";>;

 

  

 





I;ve tried /verbosity:detailed and several other flags.  I've tried running 
path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens every time:



/bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj

XBuild Engine Version 12.0

Mono, Version 4.0.0.0

Copyright (C) 2005-2013 Various Mono authors

/bld/pash/Pash-Project-Pash-bc07215 $



Please help...this is driving me crazy.




-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] mono 4.0.0 xbuild won't build project

[Alexander Köplinger]

No idea about the xbuild issue, but you should be able to build Pash on another 
machine and just copy over the .exe, it is managed code after all ;) 
 
From: chasel...@gmail.com
Date: Tue, 2 Jun 2015 16:54:19 -0500
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] mono 4.0.0 xbuild won't build project

Just built and installed mono 4.0 from sources.  Basic "Hello World" console 
program builds and runs successfully but basic "Hello World" project 
(hello.proj) won't build; xbuild displays the banner and then exits with no 
errors and without building the project.



Here's the hello.proj

< Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003";>;











I;ve tried /verbosity:detailed and several other flags.  I've tried running 
path/to/mono -v /path/to/xbuild.exe proj.proj. Same thing happens every time:



/bld/pash/Pash-Project-Pash-bc07215 $ xbuild Pash.proj

XBuild Engine Version 12.0

Mono, Version 4.0.0.0

Copyright (C) 2005-2013 Various Mono authors

/bld/pash/Pash-Project-Pash-bc07215 $



Please help...this is driving me crazy.



-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
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] mono make install fails with Error 1

[Alexander Köplinger]

You can try "make install V=1" for more output as well. 
 
From: chasel...@gmail.com
Date: Sun, 31 May 2015 11:49:26 -0500
To: sushihango...@outlook.com; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] mono make install fails with Error 1

If I didn't lose you at "no sudo, Android" here's the output from make 
--debug=vv install:



Invoking recipe from ../../build/library.make:197 to update target 
`install-local'.

make[1]: Entering directory `/bld/mono/mono-4.0.0/mcs/class/System'

MONO_PATH="./../../class/lib/build:$MONO_PATH" 
/bld/mono/mono-4.0.0/runtime/mono-wrapper  ./../../class/lib/build/gacutil.exe 
/i ./../../class/lib/net_4_5/System.dll /f /gacdir /usr/mono/lib /root 
/usr/mono/lib /package 4.5

make[1]: *** [install-local] Error 1

make[1]: Leaving directory `/bld/mono/mono-4.0.0/mcs/class/System'

make: *** [do-install] Error 2

On May 31, 2015 11:30:51 AM CDT, Robert N  wrote:
did you try it with sudo?

cd into the mcs/class/System and do a 'gacutil -i System.dll' to see if that is 
really working.

and check the results via : gacutil -l 

Also run make in verbose debug mode and see which step is failing.


 Subject: RE: [Mono-dev] mono make install fails with Error 1 
 From: chasel...@gmail.com 
 Date: Sun, 31 May 2015 11:15:00 -0500 
 To: mono-devel-list@lists.ximian.com 
 CC: sushihango...@outlook.com 
 
 This is going to sound weird, but I think the error is being thrown 
 after the update but before the successful install message. 
 
 Here's the listing of lib/mono/gac and subdirs after running make 
 install in /mcs/class/System: 
 
 /bld/mono/mono-4.0.0 $ ls -al
/usr/mono/lib/mono/gac 
 total 12 
 drwxrwx--- 3 u0_a186 u0_a186 4096 May 31 10:27 . 
 drwxrwx--- 8 u0_a186 u0_a186 4096 May 31 10:27 .. 
 drwxrwx--- 3 u0_a186 u0_a186 4096 May 31 11:06 System 
 /bld/mono/mono-4.0.0 $ ls -al /usr/mono/lib/mono/gac/System/ 
 total 12 
 drwxrwx--- 3 u0_a186 u0_a186 4096 May 31 11:06 . 
 drwxrwx--- 3 u0_a186 u0_a186 4096 May 31 10:27 .. 
 drwxrwx--- 2 u0_a186 u0_a186 4096 May 31 11:06 4.0.0.0__b77a5c561934e089 
 /bld/mono/mono-4.0.0 $ ls -al 
 /usr/mono/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/ 
 total 2856 
 drwxrwx--- 2 u0_a186 u0_a186 4096 May 31 11:06 . 
 drwxrwx--- 3 u0_a186 u0_a186 4096 May 31 11:06 .. 
 -rwxrwx--- 1 u0_a186 u0_a186 2063360 May 30 06:12 System.dll 
 -rw-rwx--- 1 u0_a186 u0_a186 851131 May 30 06:12 System.dll.mdb 
 
 But make install still fails 
 
 
 
 On May 31, 2015 10:53:09 AM CDT, Robert N
 wrote: 
 
 Permissions problem? Looks like you are installing into /usr/mono/lib (FYI: 
I'd be careful, installing builds into system usr is not a good idea usually). 
 
 At that point of the install it is trying to update the gac with System.dll so 
I would assume you do not have permissions, you can always do a 'sudo make 
install'. 
 
 If you cd into /mcs/class/System and do a sudo make install you 
should see the successful gac update like this: 
 
 Installed ./../../class/lib/net_4_5/System.dll into the gac 
(/Users/administrator/playscript-install/lib/mono/gac) 
 
 

 
 From: chasel...@gmail.com 
 Date: Sun, 31 May 2015 09:29:20 -0500 
 To: mono-devel-list@lists.ximian.com 
 Subject: [Mono-dev] mono make install fails with Error 1 
 
 I've finally managed to get mono to 
 build from sources, but make 
 install invoked from
the top build directory fails at the following 
 point: 
 
 make[6]: Entering directory `/bld/mono/mono-4.0.0/mcs/class/System' 
 make install-local 
 WARNING: generic atexit() called from legacy shared library 
 make[7]: Entering directory `/bld/mono/mono-4.0.0/mcs/class/System' 
 MONO_PATH="./../../class/lib/build:$MONO_PATH" 
 /bld/mono/mono-4.0.0/runtime/mono-wrapper 
 ./../../class/lib/build/gacutil.exe /i 
 ./../../class/lib/net_4_5/System.dll /f /root /usr/mono/lib /package 
 4.5 
 make[7]: *** [install-local] Error 1 
 make[7]: Leaving directory `/bld/mono/mono-4.0.0/mcs/class/System' 
 make[6]: *** [do-install] Error 2 
 
 Error 1 is the only error thrown. 
 
 I can run this command without errors 
 
 MONO_PATH="./../../class/lib/build:$MONO_PATH" 
 /bld/mono/mono-4.0.0/runtime/mono-wrapper 
 
 ./../../class/lib/build/gacutil.exe /i 

./../../class/lib/net_4_5/System.dll /f /root /usr/mono/lib /package 
 4.5 
 
 And I can run the final command in mono-wrapper without errors 
 
 /bld/mono/mono-4.0.0 $ /bld/mono/mono-4.0.0/libtool --verbose 
 --mode=execute "mono/mini/mono" --config 
 "/bld/mono/mono-4.0.0/runtime/etc/mono/config" 
 "mcs/class/lib/build/gacutil.exe" /i mcs/class/lib/net_4_5/System.dll 
 /f /root /usr/mono/lib /package 4.5 
 
 But running 'make install' fails. Any ideas? 

 Mono-devel-list mailing 
 list Mono-devel-list@lists.ximian.com 
 http://lists.ximian.com/mailman/listinfo/mono-devel-list 
 
 
 -- 
 Sent from my Android device with K-9 Mail. Please excuse my brevity. 


-- 

Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Mono-devel-lis

Re: [Mono-dev] XmlSerialization Issues

[Alexander Köplinger]

Can you try if it happens with the latest Mono 4.0 release as well 
(http://www.mono-project.com/docs/getting-started/install/linux/)?
 
From: paul.mce...@atlium.com
Date: Wed, 27 May 2015 10:16:36 -0400
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] XmlSerialization Issues

I'm using Mono version 3.2.8 on Ubuntu Linux 14.04.2 LTS, and I'm having a 
strange problem sometimes when calling web services.  I have a C# 2.0 web 
service, and sometimes when I call it, I get the error shown below.  I can 
reproduce it every time, but I can't seem to find what combination of 
parameters is really causing the issue.  Most of the arguments are just simple 
strings and integers.  Can you please tell me how I can debug/workaround this?
"  at System.Xml.Serialization.XmlCustomFormatter.ToXmlString 
(System.Xml.Serialization.TypeData type, System.Object value) [0x0] in 
:0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.GetStringValue 
(System.Xml.Serialization.XmlTypeMapping typeMap, 
System.Xml.Serialization.TypeData type, System.Object value) [0x0] in 
:0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WritePrimitiveValueLiteral
 (System.Object memberValue, System.String name, System.String ns, 
System.Xml.Serialization.XmlTypeMapping mappedType, 
System.Xml.Serialization.TypeData typeData, Boolean wrapped, Boolean 
isNullable) [0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WriteMemberElement 
(System.Xml.Serialization.XmlTypeMapElementInfo elem, System.Object 
memberValue) [0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WriteElementMembers 
(System.Xml.Serialization.ClassMap map, System.Object ob, Boolean isValueList) 
[0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WriteMembers 
(System.Xml.Serialization.ClassMap map, System.Object ob, Boolean isValueList) 
[0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WriteMessage 
(System.Xml.Serialization.XmlMembersMapping membersMap, System.Object[] 
parameters) [0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializationWriterInterpreter.WriteRoot 
(System.Object ob) [0x0] in :0 \n  at 
System.Xml.Serialization.XmlSerializer.Serialize (System.Object o, 
System.Xml.Serialization.XmlSerializationWriter writer) [0x0] in :0 \n  at System.Xml.Serialization.XmlSerializer.Serialize 
(System.Xml.XmlWriter xmlWriter, System.Object o, 
System.Xml.Serialization.XmlSerializerNamespaces namespaces) [0x0] in 
:0 "> 





This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version. Atlium Global Services, 3438 East 
Lake Rd, Ste 14, PMB #664, Palm Harbor, FL  34685 
___
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] Building from Source Fails with mcs: Command not found

[Alexander Köplinger]

build.exe is just managed code, so my guess is something is wrong with the Mono 
runtime. 
You can run the runtime tests ("make check" in the mono/mono folder) and see if 
they pass.
 
> Date: Thu, 21 May 2015 04:26:50 -0700
> From: chasel...@gmail.com
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Building from Source Fails with mcs: Command not  
> found
> 
> Is the issue with something built before build.exe attempts to run, 
> something wrong with build.exe or with build.exe on android?
> 
> 
> akoeplinger wrote
> > The basic.exe in monolite is mcs. I think you're heading down the wrong
> > path, judging from your log it tries a system-wide mcs first (as expected)
> > and then falls back to monolite because Mono isn't installed.
> > Invoking monolite's basic.exe fails though with "Illegal instruction",
> > which points to some runtime issue.
> >  
> > -- Alex
> > 
> >> Date: Thu, 21 May 2015 03:38:02 -0700
> >> From: 
> 
> > chaselton@
> 
> >> To: 
> 
> > mono-devel-list@.ximian
> 
> >> Subject: Re: [Mono-dev] Building from Source Fails with mcs: Command not
> >> found
> >> 
> >> More information:
> >> 
> >> I examined the mcs and mono files in _tmpdir/bin after realizing they
> >> were
> >> created on the fly...they are shell scripts.  The mono script sets up
> >> some
> >> env variables...and does some other stuff I haven't looked to closely at
> >> yet.  The mcs script is this:
> >> 
> >> #! /bin/sh
> >> exec "/bld/mono/mono-4.0.0/runtime/_tmpinst/bin/mono"
> >> "/bld/mono/mono-4.0.0/mcs/class/lib/build/mcs.exe" "$@"
> >> 
> >> That's a space between the shebang and /bin/sh...and the second
> >> directory...mcs/class/lib/build...doesn't exist.  The directory
> >> mcs/class/lib/monolite does...but it doesn't contain mcs.exe...it
> >> contains
> >> build.exe and some other files.
> >> 
> >> Thoughts?  Are the generated scripts incorrect or should monolite include
> >> a
> >> copy of mcs.exe
> >> 
> >> 
> >> 
> >> --
> >> View this message in context:
> >> http://mono.1490590.n4.nabble.com/Building-from-Source-Fails-with-mcs-Command-not-found-tp4666000p4666007.html
> >> Sent from the Mono - Dev mailing list archive at Nabble.com.
> >> ___
> >> Mono-devel-list mailing list
> >> 
> 
> > Mono-devel-list@.ximian
> 
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >   
> > ___
> > Mono-devel-list mailing list
> 
> > Mono-devel-list@.ximian
> 
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Building-from-Source-Fails-with-mcs-Command-not-found-tp4666000p4666009.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> 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] Building from Source Fails with mcs: Command not found

[Alexander Köplinger]

The basic.exe in monolite is mcs. I think you're heading down the wrong path, 
judging from your log it tries a system-wide mcs first (as expected) and then 
falls back to monolite because Mono isn't installed.
Invoking monolite's basic.exe fails though with "Illegal instruction", which 
points to some runtime issue.
 
-- Alex
 
> Date: Thu, 21 May 2015 03:38:02 -0700
> From: chasel...@gmail.com
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Building from Source Fails with mcs: Command not  
> found
> 
> More information:
> 
> I examined the mcs and mono files in _tmpdir/bin after realizing they were
> created on the fly...they are shell scripts.  The mono script sets up some
> env variables...and does some other stuff I haven't looked to closely at
> yet.  The mcs script is this:
> 
> #! /bin/sh
> exec "/bld/mono/mono-4.0.0/runtime/_tmpinst/bin/mono"
> "/bld/mono/mono-4.0.0/mcs/class/lib/build/mcs.exe" "$@"
> 
> That's a space between the shebang and /bin/sh...and the second
> directory...mcs/class/lib/build...doesn't exist.  The directory
> mcs/class/lib/monolite does...but it doesn't contain mcs.exe...it contains
> build.exe and some other files.
> 
> Thoughts?  Are the generated scripts incorrect or should monolite include a
> copy of mcs.exe
> 
> 
> 
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Building-from-Source-Fails-with-mcs-Command-not-found-tp4666000p4666007.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> 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] Build failure on ARMv6/Raspberry Pi with Raspbian/armhf

[Alexander Köplinger]

As far as I understood it, even with an old mcs in the PATH it should first try 
to use that one, detect that it is too old/doesn't work and then fallback to 
the monolite directory.
So it should "just work" :)
 
-- Alex
 
> Date: Fri, 17 Apr 2015 18:23:21 +0200
> From: fab...@canvon.de
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Build failure on ARMv6/Raspberry Pi with 
> Raspbian/armhf
> 
> * Alexander Köplinger (Fri, 17 Apr 2015 17:40:28 +0200):
> >
> > > That worked.  I'd suggest the README.md would be updated, though, as it
> > > specifically says to use monolite with EXTERNAL_MCS for bootstrapping
> > > (under "If you don't have a working Mono installation"). It should say to
> > > remove any existing gmcs from the $PATH, instead.
> >  
> > That came up before already and we updated the readme, looks like you don't
> > have the latest version:
> > https://github.com/mono/mono#if-you-dont-have-a-working-mono-installation
> >  
> > -- Alex
> 
> Yes, I'm using mono-3.12.0-branch (to get a stable version) where it is
> not updated yet.
> 
> 
> Also I'd suggest to change
> 
> | The build will then use the files downloaded by `make get-monolite-latest`.
> 
> to 
> 
> | The build will then use the files downloaded by `make get-monolite-latest`,
> | as long as there is no existing gmcs in $PATH.
> 
> (or something on that lines) so people won't accidentally end up with the 
> wrong
> bootstrap compiler. Or is that no longer correct on the master branch?
> 
> Regards, Fabian
> ___
> 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] Build failure on ARMv6/Raspberry Pi with Raspbian/armhf

[Alexander Köplinger]

> That worked.  I'd suggest the README.md would be updated, though, as it
> specifically says to use monolite with EXTERNAL_MCS for bootstrapping
> (under "If you don't have a working Mono installation"). It should say to
> remove any existing gmcs from the $PATH, instead.
 
That came up before already and we updated the readme, looks like you don't 
have the latest version: 
https://github.com/mono/mono#if-you-dont-have-a-working-mono-installation
 
-- Alex
 
> Date: Fri, 17 Apr 2015 17:08:25 +0200
> From: fab...@canvon.de
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Build failure on ARMv6/Raspberry Pi with 
> Raspbian/armhf
> 
> * Jo Shields (Thu, 16 Apr 2015 13:07:06 +0100):
> > 
> > On 15/04/15 14:21, Fabian Pietsch wrote:
> > > Hi,
> > >
> > > I'm trying to compile Mono GIT mono-3.12.0-branch on the Raspberry
> > > Pi (ARMv6), on Raspbian/armhf (Mono 3.2.8), with monolite-111-latest
> > > 3.6.1.0 as bootstrap compiler.
> > >
> > > I'm building like this:
> > >
> > > mono $ ./autogen.sh --prefix=/usr/local 
> > > EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe"
> > > [...]
> > > mono $ SKIP_AOT=true make 
> > > EXTERNAL_MCS="/home/pi/build/mono/mono/mcs/class/lib/monolite/gmcs.exe" 
> > > V=1
> > > [...]
> > > make[8]: Entering directory '/home/pi/build/mono/mono/mcs/class/corlib'
> > > /bin/sh ./../../mkinstalldirs ../../class/lib/build/
> > > touch ../../class/lib/build//.stamp
> > > MONO_PATH="./../../class/lib/basic:$MONO_PATH" 
> > > /home/pi/build/mono/mono/runtime/mono-wrapper  
> > > ./../../class/lib/basic/basic.exe /codepage:65001 -unsafe -nostdlib 
> > > -nowarn:612,618 -d:INSIDE_CORLIB -d:LIBC  -d:NET_1_1 -d:NET_2_0 
> > > -d:NET_3_0 -d:NET_3_5 -d:NET_4_0 -nowarn:1699 -nostdlib 
> > > -lib:./../../class/lib/build  -optimize  /noconfig 
> > > -resource:resources/collation.core.bin 
> > > -resource:resources/collation.tailoring.bin 
> > > -resource:resources/collation.cjkCHS.bin 
> > > -resource:resources/collation.cjkCHT.bin 
> > > -resource:resources/collation.cjkJA.bin 
> > > -resource:resources/collation.cjkKO.bin 
> > > -resource:resources/collation.cjkKOlv2.bin --runtime:v4 -target:library 
> > > -out:../../class/lib/build/mscorlib.dll  @corlib.dll.sources
> > >
> > > Unhandled Exception:
> > > System.TypeLoadException: Could not load type 
> > > 'Mono.CSharp.CommandLineParser' from assembly 'basic, Version=3.12.1.0, 
> > > Culture=neutral, PublicKeyToken=null'.
> > > [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not 
> > > load type 'Mono.CSharp.CommandLineParser' from assembly 'basic, 
> > > Version=3.12.1.0, Culture=neutral, PublicKeyToken=null'.
> > > ../../build/library.make:275: recipe for target 
> > > '../../class/lib/build/mscorlib.dll' failed
> > > make[8]: *** [../../class/lib/build/mscorlib.dll] Error 1
> > > [...]
> > 
> > Don't specify EXTERNAL_MCS.
> 
> [...]
> 
> > If EXTERNAL_MCS does not exist, and "mcs" does not exist in $PATH, then
> > the build system will use mcs.exe from monolite/ using the just-built
> > mono in mono/mini - this is the scenario you want.
> 
> That worked.  I'd suggest the README.md would be updated, though, as it
> specifically says to use monolite with EXTERNAL_MCS for bootstrapping
> (under "If you don't have a working Mono installation"). It should say to
> remove any existing gmcs from the $PATH, instead.
> 
> So, what I did: I cloned the cloned mono repos (to have a fresh start
> without losing my previous build results if I should still need them),
> then removed all of Raspbian's mono packages from the system.
> 
> Then I built like this:
> 
> mono_ $ ./autogen.sh --prefix=/usr/local
> [...]
> mono_ $ make V=1
> [...]
> make[6]: Entering directory '/home/pi/build/mono/mono_/mcs'
> gmcs /warn:0 /out:build/deps/basic-profile-check.exe 
> build/common/basic-profile-check.cs
> make[6]: gmcs: Command not found
> build/profiles/basic.make:92: recipe for target 
> 'build/deps/basic-profile-check.exe' failed
> make[6]: *** [build/deps/basic-profile-check.exe] Error 127
> make[6]: Leaving directory '/home/pi/build/mono/mono_/mcs'
> *** The compiler 'gmcs' doesn't appear to be usable.
> *** You need Mono version 2.10 or better installed to build MCS
> *** Check mono README for information on how to bootstrap a Mono installation.
> build/profiles/basic.make:60: recipe for target 'do-profile-check' failed
> make[5]: *** [do-profile-check] Error 1
> [...]
> 
> Then:
> 
> mono_ $ make get-monolite-latest
> [...]
> mono_ $ make V=1
> [...]
> make[6]: Entering directory '/home/pi/build/mono/mono_/mcs'
> gmcs /warn:0 /out:build/deps/basic-profile-check.exe 
> build/common/basic-profile-check.cs
> make[6]: gmcs: Command not found
> build/profiles/basic.make:92: recipe for target 
> 'build/deps/basic-profile-check.exe' failed
> make[6]: *** [build/deps/basic-profile-check.exe] Error 127
> make[6]: Leaving directory '/home/pi/build/mono/mono_/mcs'
> make[6]: Entering directory '/home/pi/build/mon

Re: [Mono-dev] Assemblies in the CLR system directory and F# scripting.

[Alexander Köplinger]

EntityFramework was already removed from the upcoming Mono 4.0.
I also just checked and on Windows I have System.Web.Razor.dll (Razor 2.0) in 
the GAC as well, so maybe there's some other issue here?
 
-- Alex
 
> From: matth...@googlemail.com
> Date: Thu, 16 Apr 2015 12:08:54 +0200
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Assemblies in the CLR system directory and F# scripting.
> 
> Hi all,
> 
> TL;DR: We should remove System.Web.Razor.dll, EntityFramework.dll (and
> possibly more) from "/usr/lib/mono/4.5"
> 
> I noticed that some assemblies (namely "EntityFramework" and
> "System.Web.Razor" and possibly more) lead to problems when used within
> a F# script file. The problem is the following:
> 
> Assume you use NuGet to download the latest Razor-3 package and then do
> the following (in an F# script file):
> 
> #I "packages/Microsoft.AspNet.Razor/lib/net45"
> #r "System.Web.Razor.dll"
> 
> Note that this is the usual way of loading assemblies in F# scripting
> and it works fine on Windows/.NET.
> 
> However because this is the same as using
> "/lib:packages/Microsoft.AspNet.Razor/lib/net45
> /reference:System.Web.Razor.dll" on the C# compiler and because mono has
> a "System.Web.Razor.dll" in its CLR system directory (/usr/lib/mono/4.5)
> it will redirect the reference (CLR system directory is always
> preferred, see https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx).
> 
> This already hit me several times:
>  - https://github.com/fsharp/FSharp.Compiler.Service/issues/313
>  - https://github.com/tpetricek/FSharp.Formatting/pull/279
> 
> I'm not really sure why mono actually needs those file to live there.
> For referencing the NuGet package should be fine. To load the correct
> (mono compatible) version on runtime the GAC should do it.
> IMHO we can just remove the System.Web.Razor.dll (and possibly others?)
> from the runtime directory.
> @akoeplinger noted the following in the gitter chat: It would be a
> breaking change for people depending on "/reference:System.Web.Razor" to
> just work.
> But I'm not sure how common that is with the NuGet package in place.
> IIRC xbuild and msbuild always use fully qualified references, so it
> shouldn't be a problem for them.
> 
> So... Is removing those file something we can do? I just wanted to bring
> attention to this issue as it can be *really* hard to debug. The
> workarounds in place for this are required anyway to work with older
> mono versions. The workaround in itself is simple you just need to use
> the fully qualified reference instead:
> 
> #r "packages/Microsoft.AspNet.Razor/lib/net45/System.Web.Razor.dll"
> 
> However this can be a problem if you don't know in advance in which of
> the included directories ("#I") the file is living. (Because F# will
> stop executing if the fully qualified reference doesn't exists).
> 
> Thanks,
>  Matthias
> ___
> 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] Possible bug when using array of unsafe pointers

[Alexander Köplinger]

I tried it on the Mono 4.0 alpha and it didn't repro there (it did crash for me 
on 3.12 as well).
Can you try upgrading to the 4.0 alpha and see if it works for you as well? See 
http://www.mono-project.com/docs/getting-started/install/linux/#alpha-update-channel
-- Alex
 
From: fabian.na...@gmail.com
Date: Mon, 13 Apr 2015 18:44:52 +
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Possible bug when using array of unsafe pointers

Dear Devs,
I tried to port my .NET C# application to run on Linux (Fedora21) through Mono, 
but it crashes somewhere in the runtime's garbage collector code with 
segmentation fault. The minimal code to reproduce the problem is as 
follows:SomeStruct*[] ptrs = new SomeStruct*[1];ptrs[0] = 
(SomeStruct*)Marshal.AllocHGlobal(4);GC.Collect();

Here some further information:
[fabian@localhost Debug]$ mono --versionMono JIT compiler version 3.12.1 
(tarball Fri Mar  6 18:53:33 GMT 2015)Copyright (C) 2002-2014 Novell, Inc, 
Xamarin Inc and Contributors. www.mono-project.com  TLS:   __thread 
SIGSEGV:   altstack Notifications: epollArchitecture:  amd64
Disabled:  none Misc:  softdebugLLVM:  
supported, not enabled.  GC:sgen
Stacktrace:
  at  <0x>  at (wrapper managed-to-native) 
System.GC.InternalCollect (int)   at System.GC.Collect 
() [0x0] in 
/builddir/build/BUILD/mono-3.12.1/mcs/class/corlib/System/GC.cs:51  at 
MMC.Benchmarks.MOT.TestTable (int,bool) [0x00010] in /home/fabian/Documents/New 
folder/MemoryContext/Benchmarks/MemoryOperationsTest.cs:227  at 
MMC.Program.Main (string[]) [0x0050d] in /home/fabian/Documents/New 
folder/MemoryContext/Program.cs:379  at (wrapper runtime-invoke) 
.runtime_invoke_void_object (object,intptr,intptr,intptr) 
Native stacktrace:
mono() [0x4b46c2]   mono() [0x50c893]   mono() [0x42ab73]   
/lib64/libpthread.so.0(+0x100d0) [0x7f9bba5050d0]   
/lib64/libc.so.6(+0x145e42) [0x7f9bba066e42]mono() [0x5dd2f3]   mono() 
[0x5dd581]   mono() [0x5ddd98]   mono() [0x5d2d08]   mono() 
[0x5d2f0f]   mono() [0x5d4715]   mono() [0x5d5212]   mono() 
[0x5d87d0]   mono(mono_gc_collect+0x28) [0x5d9078]   [0x40337eb2]
Debug info from gdb:
warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by 
your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".To enable 
execution of this file add   add-auto-load-safe-path 
/usr/bin/mono-sgen-gdb.pyline to your configuration file 
"/home/fabian/.gdbinit".To completely disable this security protection add 
set auto-load safe-path /line to your configuration file 
"/home/fabian/.gdbinit".For more information about this security protection see 
the"Auto-loading safe path" section in the GDB manual.  E.g., run from the 
shell:  info "(gdb)Auto-loading safe path"[New LWP 27513][Thread debugging 
using libthread_db enabled]Using host libthread_db library 
"/lib64/libthread_db.so.1".0x7f9bba504c6b in waitpid () from 
/lib64/libpthread.so.0  Id   Target Id Frame   2Thread 
0x7f9bb18ec700 (LWP 27513) "Finalizer" 0x7f9bb9f55cc7 in sigsuspend () from 
/lib64/libc.so.6* 1Thread 0x7f9bbb021780 (LWP 27512) "mono" 
0x7f9bba504c6b in waitpid () from /lib64/libpthread.so.0
Thread 2 (Thread 0x7f9bb18ec700 (LWP 27513)):#0  0x7f9bb9f55cc7 in 
sigsuspend () from /lib64/libc.so.6#1  0x005cf99c in suspend_handler 
()#2  #3  0x7f9bba50370e in sem_wait () from 
/lib64/libpthread.so.0#4  0x00625587 in mono_sem_wait ()#5  
0x005a7fcd in finalizer_thread ()#6  0x0058c370 in 
start_wrapper ()#7  0x0062a466 in inner_start_thread ()#8  
0x7f9bba4fc52a in start_thread () from /lib64/libpthread.so.0#9  
0x7f9bba02122d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f9bbb021780 (LWP 27512)):#0  0x7f9bba504c6b in waitpid 
() from /lib64/libpthread.so.0#1  0x004b474f in 
mono_handle_native_sigsegv ()#2  0x0050c893 in 
mono_arch_handle_altstack_exception ()#3  0x0042ab73 in 
mono_sigsegv_signal_handler ()#4  #5  0x7f9bba066e42 
in __memcpy_avx_unaligned () from /lib64/libc.so.6#6  0x005dd2f3 in 
copy_object_no_checks ()#7  0x005dd581 in major_copy_or_mark_object 
()#8  0x005ddd98 in major_scan_object ()#9  0x005d2d08 in 
sgen_drain_gray_stack ()#10 0x005d2f0f in 
job_scan_from_registered_roots ()#11 0x005d4715 in 
major_copy_or_mark_from_roots ()#12 0x005d5212 in major_do_collection 
()#13 0x005d87d0 in sgen_perform_collection ()#14 0x005d9078 in 
mono_gc_collect ()#15 0x40337eb2 in ?? ()#16 0x014ad120 in ?? 
()#17 0x7ffd488929e0 in ?? ()#18 0x in ?? ()
=Got a SIGSEGV 
while executing native code. This usually indicatesa fatal error in the mono 
runtime or one of the native libraries used b

Re: [Mono-dev] Can't run mono-3.12.X on Windows XP (Mono-devel-list Digest, Vol 120, Issue 4)

[Alexander Köplinger]

FYI, I looked briefly into this and I think the only thing that XP doesn't have 
is InterlockedCompareExchange64 win api. msvc supports the 
_InterlockedCompareExchange64 intrinsic we could probably use instead, but I 
couldn't test it since the runtime wouldn't build for me in VS when I tried.
 
I agree that XP is an EOL platform and we shouldn't invest any time in it (but 
it'd be pretty funny nonetheless if I could run asp.net 5 on a decades old OS 
*g*).
 
-- Alex
 
> Date: Thu, 9 Apr 2015 21:43:44 +0100
> From: direct...@apebox.org
> To: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Can't run mono-3.12.X on Windows XP (Mono-devel-list 
> Digest, Vol 120, Issue 4)
> 
> 
> 
> On 09/04/15 18:48, Keedi Kim wrote:
> > Hi, guys.
> >
> > I tried recent version of Mono (3.12.X) on Windows XP machine. I've
> > installed Visual C++ 2013 (x86) redistributable, then installed Mono. But
> > every mono related executables are failed to run. The error message was:
> >
> > "mono.exe is not a valid win32 application"
> >
> > I checked download page ( http://download.mono-project.com/archive/ ) and
> > installed previous older version which is
> > mono-3.2.3-gtksharp-2.12.11-win32-0.exe then all mono binaries are executed
> > well. I wonder if the mono supports Windows XP. Are there extra works to
> > use recent version of mono in XP machine?
> 
> So... The short version is it doesn't work with 3.12+, which
> are built with Visual Studio 2013.
> 
> I tried building with parameters to enable legacy XP support, and it
> should *install* on XP now, with the 4.0.0 alpha release - but it will
> fail to work, due to needing commands in kernel32.dll (one of the most
> fundamental Windows components) which are only available in Vista or above.
> 
> XP stopped having any support whatsoever from Microsoft more than a year
> ago, and is now a massive security risk for anyone running it - I don't
> want to invest any more time than I already have on XP support, until
> management tells me otherwise - at which point it's the runtime team's
> problem to stop relying on basic kernel32.dll functionality.
> 
> ___
> 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] Update on Build System

[Alexander Köplinger]

To be clear, you *can* build the Mono runtime using Visual Studio (Mono for 
Windows is built that way, the class libs are taken from the Mac release).
 
-- Alex
 
From: mig...@xamarin.com
Date: Thu, 9 Apr 2015 16:25:11 -0400
To: cta...@opennetcf.com
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Update on Build System

Hello,
I do not think this work was completed.
Miguel
On Thu, Apr 9, 2015 at 3:12 PM, Chris Tacke  wrote:
It’s been about a year and thought I’d loop back on this thread since it’s 
still something I could really use. Are we yet to a point where we can build 
Mono using the Microsoft compilers only?  If so, I can then start looking at 
modifying those projects to build using the Windows CE compilers. -Chris Tacke 
From: Miguel de Icaza [mailto:mig...@xamarin.com] 
Sent: Monday, May 26, 2014 10:23 AM
To: Chris Tacke
Cc: mono-devel
Subject: Re: [Mono-dev] Update on Build System Hello Chris, That is what I am 
trying to do with this work. There are still a number of problems that I need 
to address:Installing the resulting binariesSigning (currently we are skipping 
this)Ensure the binaries produced are identical with Make and msbuildAdd 
assertions to ensure that flags that we currently ignore are caught, in case we 
add new features in the futureFix the C# compiler build (currently 
disabled)Extend this to other components, so we can have the entire setup in a 
solution.Then we would have something that works. Miguel On Mon, May 26, 2014 
at 11:04 AM, Chris Tacke  wrote:Miguel, This is great 
news. Are there any plans to update the build system to allow us to compile the 
runtime itself using Visual Studio (i.e. a Microsoft compiler)?   Now before 
everyone starts with the eye rolling and “why the hell would you want to do 
that?” questions, let me explain.  As of today, we can create applications in 
C# that will run on Windows and a large array of Linux machines (including 
Android) but Windows CE has been orphaned.  Microsoft is not putting any effort 
into the Compact Framework, but there are still people developing for Windows 
CE devices.  I’d like to put a last nail in the coffin of the Compact Framework 
by getting Mono supported on Windows CE so we can all move into using 
technology from the current decade, not the last one.   I don’t see any real 
path for getting the runtimes to compile for Windows CE  for ARM and 586 (not 
686, since we have new Intel processors now that are 586 based).  There is an 
old (last touch in 2009) CeGCC project that might be a step, but I was hoping 
for something a little simpler.  I’m up for any suggestions. -Chris Tacke 
From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Miguel de Icaza
Sent: Friday, May 23, 2014 9:59 PM
To: mono-devel
Subject: [Mono-dev] Update on Build System Hey guys, #1 Makefile Build System 
Update So the clean staged setup has been added to mono/master and in practice 
most of you will never notice an improvement.Those working on libraries 
that had cross dependencies will enjoy reliable and working builds.   If you 
make a change in say System, and you type "make" in mcs/class/System, it will 
make sure that all the dependencies are properly compiled and the result will 
be stable. #2 MSBuild setup
Based on the work above, I have updated the MSBuild setup, and it is now 
possible to build most of the managed code with xbuild.   This means that you 
can use this from Visual Studio or Xamarin Studio. Since xbuild does not 
support passing /keyfile to the C# compiler, I still have to fix about 6-7 
assemblies that use -keyfile to be signed.Once that happens, you should be 
able to build all of Mono's managed code with: xbuild msvc/scripts/net_4_5.sln 
Currently I disabled generating project files for profiles other than 4.5, just 
because it is easier to debug this way. I am also a bit sad that our xbuild 
does not have any support for parallel builds, it would have been a neat hack 
to make the xbuild-based build system parallel and get this for free. #3 Future 
Parallel Work - Makefiles I tried to implement parallel builds for 
mcs/class/Facades, and while it works, it regressed some of the other standard 
targets that we have (the other -local).   I will have to revisit this later. 
But the principle behind the patch that enabled this could be used for 
mcs/class and parallelize all the builds as well.   We only need to (a) 
generate the assembly dependencies [1] and (b) we need to figure out the -local 
target breakage (same stuff I broke for Facades). [1]  (which we have from the 
xbuild work above)Miguel 


___
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.ximi

Re: [Mono-dev] Overflowed double->int casts on ARM in MS referencesource

[Alexander Köplinger]

Thanks for your response Sebastien!
 
I agree that it's pure luck those edge cases showed up in the unit tests :)
I just wanted confirmation that you guys think it's worthwhile fixing those 
cases nevertheless and let's hope there won't be too many more of them in the 
codebase. I'll wait until my PR is merged and revert your commit as you said.
 
-- Alex
 
Date: Mon, 23 Mar 2015 20:20:28 -0400
Subject: Re: Overflowed double->int casts on ARM in MS referencesource
From: sebastien.poul...@gmail.com
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com

Hey,
On Mon, Mar 23, 2015 at 7:47 PM, Alexander Köplinger 
 wrote:



I just noticed this commit by @spouliot: 
https://github.com/mono/mono/commit/298962b7ddd5e3af33c3177e8523cc36da4de553
 
In my opinion, this isn't the right approach, we should rather fix the cases 
where a cast would overflow in MS referencesource code rather than changing the 
tests.
 
I sent a PR a week or so ago that fixes the particular DateTime tests on ARM by 
explictly checking if the value fits into long, which I think is better: 
https://github.com/mono/referencesource/pull/8
Feel free to revert that commit once you PR lands. It's goal is to clear up 
issues* for the next XI release.
* or non-issue in that case, DateTime works just fine  
There are a couple more of these overflows in MS code that make tests fail and 
I think we should discuss what the best approach is. What are your thoughts?

The real problems with unspecified values (double casted to long) is that:

a) it's unrelated to the feature being tested (i.e. it was not a DateTime 
failure);

b) you can only fix the BCL for the cases we know. It's pure luck that those 
tests exists, i.e. they were not written to test that condition. That means it 
solves one of potentially many cases.

That being said it's still worth fixing the known cases inside the BCL source 
itself - even if it requires a bit more code and is not complete :-)

Sebastien

  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Overflowed double->int casts on ARM in MS referencesource

[Alexander Köplinger]

I just noticed this commit by @spouliot: 
https://github.com/mono/mono/commit/298962b7ddd5e3af33c3177e8523cc36da4de553
 
In my opinion, this isn't the right approach, we should rather fix the cases 
where a cast would overflow in MS referencesource code rather than changing the 
tests.
 
I sent a PR a week or so ago that fixes the particular DateTime tests on ARM by 
explictly checking if the value fits into long, which I think is better: 
https://github.com/mono/referencesource/pull/8
 
There are a couple more of these overflows in MS code that make tests fail and 
I think we should discuss what the best approach is. What are your thoughts?
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Reference assemblies for v2.0/v3.5 profile

[Alexander Köplinger]

Now that Mono 4.0 gets rid of the 2.0 and 3.5 .NET profiles I fear we'll gonna 
break a lot of people that want to compile against those profiles.
Should we put those profiles back into 
https://github.com/mono/reference-assemblies? Or at least make it easier to 
acquire them?
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Switch off the Jenkins ARM builds on PRs for now

[Alexander Köplinger]

I very much agree, but currently when multiple PR builds are scheduled you're 
waiting a couple of hours for the result which is not ideal either.
Jo advised me to bring this up on the mailing list, I'm not really happy with 
my suggestion as well...
-- Alex
 
Date: Thu, 19 Feb 2015 16:53:34 -0500
Subject: Re: [Mono-dev] Switch off the Jenkins ARM builds on PRs for now
From: kump...@gmail.com
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com

Why should we not test changes on ARM?
It's as important as the intel targets and breaking it comes with the same 
issues.
On Thu, Feb 19, 2015 at 4:18 PM, Alexander Köplinger 
 wrote:



The Jenkins ARM builds cause quite some delays in PR building as they are 
slower than an amd64/i386 build and Jenkins can only start the next build when 
the previous one finished on all architectures.
 
What's your opinion on switching off the ARM builds for pull requests for now 
until more workers can be brought online to better handle PR spikes?
 
-- 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] Switch off the Jenkins ARM builds on PRs for now

[Alexander Köplinger]

The Jenkins ARM builds cause quite some delays in PR building as they are 
slower than an amd64/i386 build and Jenkins can only start the next build when 
the previous one finished on all architectures.
 
What's your opinion on switching off the ARM builds for pull requests for now 
until more workers can be brought online to better handle PR spikes?
 
-- Alex
 
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] making mono builds reproducible (xamarin bz #26842)

[Alexander Köplinger]

FYI, roslyn made the switch to being deterministic by default in April last 
year: 
https://github.com/dotnet/roslyn/commit/04462c44e30dfa91267581abdb029f3102796486
 
Quoting from the commit:
"(1) The timestamp in the header is replaced with 0 (which is specifically 
allowed by the spec)
 (2) The module version ID Guid (Mvid) is computed by hashing the contents of 
the generated assembly (with zero
  where the Mvid will go for the purposes of computing the hash)
 
The name of the "private implementation details" class no longer includes the 
Mvid."
-- Alex
 
> From: jer...@sumatra.nl
> To: d...@fifthhorseman.net; mono-devel-list@lists.ximian.com; 
> marek.sa...@gmail.com
> Date: Tue, 17 Feb 2015 11:12:14 +
> CC: hen...@logibit.se; direct...@apebox.org; 
> reproducible-bui...@lists.alioth.debian.org
> Subject: Re: [Mono-dev] making mono builds reproducible (xamarin bz #26842)
> 
> Hello all,
> 
> I'm not a big fan of using an environment variable for this, but I won't 
> oppose it. In the mean time, I've added a new public API 
> (ModuleBuilder.__PEHeaderTimeDateStamp) to specify the time stamp. There is 
> already a public API to specify the module version GUID.
> 
> As Miguel said, hard coding the GUID violates the spec and can lead to weird 
> problems. I think the proper solution is to base the GUID on a SHA1 of the 
> contents of the assembly. However, this is non-trivial, so it will take some 
> time to develop a complete solution. This will be an opt-in feature, so it 
> will also need to be supported by mcs or an environment variable.
> 
> Marek, what do you think about adding an mcs switch to facilitate 
> reproducible builds?
> 
> Regards,
> Jeroen
> 
> > -Original Message-
> > From: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net]
> > Sent: Monday, February 16, 2015 23:20
> > To: mono development list
> > Cc: Jeroen Frijters; Jo Shields; Debian Reproducible Builds; Henrik
> > Feldt
> > Subject: making mono builds reproducible (xamarin bz #26842)
> > 
> > Hi Mono folks--
> > 
> > some good discussion has come up on the xamarin bugtracker about being
> > able to make builds using the mono toolchain reproducible:
> > 
> >https://bugzilla.xamarin.com/show_bug.cgi?id=26842
> > 
> > Jo Shields offered a one-liner fix to PEWriter.cs to allow the use of an
> > environment variable to fix the timestamp epoch, but made it clear that
> > more feedback is needed, so i'm raising it here:
> > 
> > from:
> > 
> >public DWORD TimeDateStamp = (uint)(DateTime.UtcNow - new
> > DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)).TotalSeconds;
> > 
> > to:
> > 
> >public DWORD TimeDateStamp =
> > Environment.GetEnvironmentVariable("IKVM_WRITER_TIMESTAMP_EPOCH") !=
> > null ?
> > 
> > uint.Parse(Environment.GetEnvironmentVariable("IKVM_WRITER_TIMESTAMP_EPO
> > CH")) :
> > (uint)(DateTime.UtcNow - new
> > DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)).TotalSeconds;
> > 
> > (i'm not sure whether the integer number of seconds is the best form for
> > the environment variable, or whether it would be better to parse a
> > standard date string -- from debian's perspective, we can deal with
> > either, of course)
> > 
> > And this still doesn't solve the secondary issue of the assembly GUID,
> > as Jo noted.
> > 
> > Any thoughts about how to best enable binary-reproducible builds from
> > the mono toolchain if the invoker requests them?
> > 
> > Regards,
> > 
> > --dkg
> ___
> 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] 2.0/3.5 targets

[Alexander Köplinger]

Those profiles were removed: 
http://lists.ximian.com/pipermail/mono-devel-list/2014-October/042145.html
(note that the 4.0 reference assemblies were kept contrary to what the email 
says).
 
You should update your build scripts to target 4.0 or better 4.5. Looks like 
there is already a PR in the pipeline which does this for IKVM: 
https://github.com/mono/ikvm-fork/pull/7
 
-- Alex
 
Date: Thu, 5 Feb 2015 11:54:19 -0800
From: manc...@gmail.com
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] 2.0/3.5 targets

Does anybody know what happened to 2.0 and 3.5 DLLs? Were those libraries 
deprecated?

I
 built mono using latest code on GitHub but it seems that the target 
framework is not built anymore. Is there anyway to get them back? 

I'm having trouble to build MonoDevelop because IKVM is depending on 3.5 
targets.

/monodevelop/main/external/ikvm/reflect/IKVM.Reflection.csproj could not import 
"$(MSBuildToolsPath)\Microsoft.CSharp.targets"

And I also got this warning:

warning : Default tasks file /usr/local/lib/mono/3.5/Microsoft.Common.tasks not 
found, ignoring.

Please advice.

Thanks,
-- 
_Manuel EspinosaE-mail: manc...@gmail.com



___
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] Visual Studio project files - update to 2013?

[Alexander Köplinger]

+1, now that the community edition provides easy access to a current VS for 
open source devs I see no reason to keep the old stuff.
-- Alex
 
> Date: Tue, 27 Jan 2015 21:15:46 +
> From: direct...@apebox.org
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Visual Studio project files - update to 2013?
> 
> Dear all,
> 
> We're currently considering upgrading the Visual Studio project files
> for the Mono runtime to require VS2013 as a minimum, rather than 2012.
> 
> This introduces two major features for us - it means C99 compatibility
> so we can clean up the runtime to use standard C99 types throughout, and
> 2013 has a fully-featured gratis "community" edition which would allow
> any Windows-based contributor to hack on the Mono runtime without
> handing thousands of dollars over to Microsoft for Visual Studio Pro.
> 
> How does the rest of the list feel about it? I'm very much pro - I use
> VS2013CE to build the new Windows packages of Mono.
> ___
> 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] Plans for new types/methods in .NET 4.6

[Alexander Köplinger]

Hey, I'm wondering what the current plan for new types and methods (like  
System.Array.Empty) in .NET 4.6 is?
Will Mono stick to the net_4_5 profile or will a new profile be created?
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] cert-sync

[Alexander Köplinger]

I don't have those directories. I just tried a small program with 
SslStream.AuthenticateAsClient() and it indeed fails with the familiar 
"IOException: The authentication or decryption has failed". After running 
mozroots this starts working.
 
Most libraries rely on WebClient/HttpWebRequest under the hood so I guess 
that's why most users never ran into this on OSX. I wonder what the difference 
is to SslStream.
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com
> Subject: RE: [Mono-dev] cert-sync
> Date: Thu, 22 Jan 2015 12:34:18 +
> 
> > From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> > Sent: Thursday, January 22, 2015 7:16 AM
> > 
> > I just tested as well and was able to run a simple new
> > WebClient().DownloadString("https://www.google.com";);  without issues
> > after a fresh install of the Mono MDK on OSX, so I'm not sure why it only
> > works after running mozroots for you?
> 
> Interesting.  Have a look in these directories:
>   ~/.config/.mono/certs/Trust
>   /usr/share/.mono/certs/Trust
> 
> If you have stuff there, it must have been populated by mozroots, or 
> something.  I understand that the latest packages distributed by mono 
> repositories have automated cert-sync in linux during package installation, 
> but that's not yet present on OSX.  So on OSX, mozroots or something is 
> necessary to populate the root Trust.
> 
> If you don't have those directories - or if they're empty - it will raise new 
> questions about differences between WebClient().DownloadString() versus 
> SslStream.AuthenticateAsClient().  I am using the latter, on mono 3.12 MRE 
> for OSX.
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] cert-sync

[Alexander Köplinger]

I just tested as well and was able to run a simple new 
WebClient().DownloadString("https://www.google.com";);  without issues after a 
fresh install of the Mono MDK on OSX, so I'm not sure why it only works after 
running mozroots for you?
 
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com
> Subject: RE: [Mono-dev] cert-sync
> Date: Thu, 22 Jan 2015 02:12:33 +0000
> 
> > From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> > 
> > I always thought OSX used the system cert store anyway and this was just a
> > Linux "issue"?
> 
> Nope.  
> 
> I just tested to make sure, and OSX uses .config/.mono/certs just like linux. 
>  (Must run mozroots)
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] cert-sync

[Alexander Köplinger]

I always thought OSX used the system cert store anyway and this was just a 
Linux "issue"?
 
-- Alex 
 
From: edward.harvey.m...@clevertrove.com
To: mono-devel-list@lists.ximian.com
Date: Tue, 20 Jan 2015 12:01:31 +
Subject: [Mono-dev] cert-sync









> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> boun...@lists.ximian.com] On Behalf Of Jo Shields
> 
> Mono 3.12 will ship with a new tool, cert-sync,
> which populates the root CA store from a static concatenated file.
> This will be executed on package install on Linux
 
Thanks Jo,
 
It looks like it does the same job as mozroots, but pulls from the concatenated 
file instead of downloading from mozilla.  That file should be available on 
most (if not all) linuxes, but ... Any plans to support OSX?  And/or mobile 
devices?
 
If the presence of root certs is not automated on *all* platforms running mono, 
then the application developer is still required to programatically run 
mozroots anyway.
 
Automating the process into the installation package is a really nice 
improvement.  Even if cert-sync won't work on OSX due to having no concatenated 
file available, can mozroots be automated into the OSX mono installer?
 




___
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] Heads up: Elimination of the 2.0 and 4.0 profiles

[Alexander Köplinger]

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,
  Merged this by running the tools themselves.
  Zoltan
On Wed, Oct 22, 2014 at 4:04 PM, akoeplinger  
wrote:
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 refrained from making a PR so far because it is quite huge, do you think

now would be a good time?



-- Alex







--

View this message in context: 
http://mono.1490590.n4.nabble.com/Heads-up-Elimination-of-the-2-0-and-4-0-profiles-tp4664323p4664325.html

Sent from the Mono - Dev mailing list archive at Nabble.com.

___

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] Mono.Posix Cross Compiling

[Alexander Köplinger]

There is a way to set a breakpoint with VS, though it's unsupported: 
http://blogs.msdn.com/b/visualstudio/archive/2010/07/06/debugging-msbuild-script-with-visual-studio.aspx
 
Mono docs about the OS variable:
"The default environment variable ‘OS’ is set to “Windows_NT” on all currently 
supported versions on Windows. xbuild sets this to “Unix” on non-Windows 
platforms, even on MacOS."
 
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: cury...@asme.org
> Date: Tue, 6 Jan 2015 19:57:08 +
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Mono.Posix Cross Compiling
> 
> > From: Dave Curylo [mailto:dacur...@gmail.com] On Behalf Of David Curylo
> > 
> > You're right.I didn't realize that was what's going on.  It looks like 
> > conditional
> > references need some hand holding like this:
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> >   
> 
> Very nice.  I'm going to start using that.
> 
> Previously, you had a value 'Windows_NT' and now you have a value 'Unix' in 
> there.  How do you figure out what values are valid?  I presume there's no 
> such thing as setting a breakpoint inside the .csproj file to see what the 
> variable is set to...
> ___
> 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] Mono.Posix Cross Compiling

[Alexander Köplinger]

Yeah, though you should be able to switch that off with CopyLocal=false in the 
 (haven't tested if you can apply a condition on that).
For me, the burden of having multiple .csproj files would outweigh a simple 
cleanup of undesired DLLs, but that's of course different for everyone :)
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: alex.koeplin...@outlook.com
> Subject: RE: [Mono-dev] Mono.Posix Cross Compiling
> Date: Tue, 6 Jan 2015 19:48:06 +
> 
> > From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> > 
> > Why wouldn't the reference with HintPath compile on Mono?
> > I just tried it out by adding the Mono.Security NuGet package
> > (https://www.nuget.org/packages/Mono.Security/) to a simple console app,
> > i.e. it added the HintPath to the packages folder,  and it compiled fine in 
> > VS
> > and MonoDevelop.
> 
> Oh - My mistake.  Yes it builds, but...  
> 
> The desired behavior is to provide Mono.Security.dll to the windows project, 
> and distribute the dll with the binary release product, while ignoring the 
> Mono.Security.dll in the source directory when built for mac or linux, use 
> the version of Mono.Security.dll that's provided by the target runtime OS.
> 
> When I use the  including , then the dll from my source 
> tree gets copied to the build destination and distributed with the built 
> product.  It might be possible to do something like a post-build script that 
> removes Mono.Security.dll from the build dir if this isn't a windows build... 
>  But if we go that route, we're just trading one hack for another.  The 
> different .sln and .csproj files is a hacky solution, but it's a solution.
> 
> I like Timotheus's solution of generating the .sln and .csproj files 
> dynamically.
  ___
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?

[Alexander Köplinger]

Thanks Miguel, I merged the referencesource PR in and it seems the Mono PR 
which replaces existing implementation is green now on Jenkins: 
https://github.com/mono/mono/pull/1433
Just wanted to confirm you're OK with merging that one in as well :)
 
-- Alex
 
From: mig...@xamarin.com
Date: Mon, 5 Jan 2015 12:10:39 -0200
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,
Sorry, really poor email on my part.
You answered my concern to my satisfaction, so this is good to go.
Miguel
On Mon, Jan 5, 2015 at 12:09 PM, Alexander Köplinger 
 wrote:



Anything left for me to do on this one? :)

-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 13:34:47 -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

Got it.
Miguel
On Wed, Dec 3, 2014 at 11:13 AM, Alexander Köplinger 
 wrote:



To make this 100% clear: .NET implements locale aware number formatting in the 
VM, e.g. for format specifiers like 'e' (exponential) or 'f' (fixed-point)  it 
calls into the VM for formatting.
We don't have this in Mono atm., so the only way is to restrict it to the 
invariant format specifiers (which doesn't hurt existing Mono users, since it 
didn't work before too).

-- Alex
 
From: alex.koeplin...@outlook.com
To: mig...@xamarin.com
Date: Wed, 3 Dec 2014 17:01:42 +0100
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, 
approaches for copying code?




Hey,
we need to ensure we only continue for the format specifiers used in 
decimalFmt. Any other format specifier (i.e. culture-specific ones) would 
result in a call into unmanaged code later on 
(https://github.com/akoeplinger/referencesource/blob/mono/System.Numerics/System/Numerics/BigNumber.cs#L611-L634)
 which we of course don't have implemented.
 
Note that it only throws an exception when decimalFmt == false, i.e. when any 
of the culture-specific specifiers was used (which is *not* a common code 
path). This is exactly what the current Mono code also does: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1470
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 10:52:04 -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

Hello Alex,
I am not sure I am understanding this.
This looks like we are choosing to not bring features that we are missing?   
Why would we want to do that?
Miguel
On Wed, Dec 3, 2014 at 10:33 AM, Alexander Köplinger 
 wrote:



Mono today also only supports the format specifiers used in decimalFmt: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471
 
So using this #if for Mono is the correct way to go.
 
(reposted, seems like the mailing list ate my previous mail) 

-- Alex
 
From: mig...@xamarin.com
Date: Sat, 29 Nov 2014 12:06:20 -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

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 
 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

Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?

[Alexander Köplinger]

Anything left for me to do on this one? :)
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 13:34:47 -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

Got it.
Miguel
On Wed, Dec 3, 2014 at 11:13 AM, Alexander Köplinger 
 wrote:



To make this 100% clear: .NET implements locale aware number formatting in the 
VM, e.g. for format specifiers like 'e' (exponential) or 'f' (fixed-point)  it 
calls into the VM for formatting.
We don't have this in Mono atm., so the only way is to restrict it to the 
invariant format specifiers (which doesn't hurt existing Mono users, since it 
didn't work before too).

-- Alex
 
From: alex.koeplin...@outlook.com
To: mig...@xamarin.com
Date: Wed, 3 Dec 2014 17:01:42 +0100
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, 
approaches for copying code?




Hey,
we need to ensure we only continue for the format specifiers used in 
decimalFmt. Any other format specifier (i.e. culture-specific ones) would 
result in a call into unmanaged code later on 
(https://github.com/akoeplinger/referencesource/blob/mono/System.Numerics/System/Numerics/BigNumber.cs#L611-L634)
 which we of course don't have implemented.
 
Note that it only throws an exception when decimalFmt == false, i.e. when any 
of the culture-specific specifiers was used (which is *not* a common code 
path). This is exactly what the current Mono code also does: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1470
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 10:52:04 -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

Hello Alex,
I am not sure I am understanding this.
This looks like we are choosing to not bring features that we are missing?   
Why would we want to do that?
Miguel
On Wed, Dec 3, 2014 at 10:33 AM, Alexander Köplinger 
 wrote:



Mono today also only supports the format specifiers used in decimalFmt: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471
 
So using this #if for Mono is the correct way to go.
 
(reposted, seems like the mailing list ate my previous mail) 

-- Alex
 
From: mig...@xamarin.com
Date: Sat, 29 Nov 2014 12:06:20 -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

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 
 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 
 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 metho

Re: [Mono-dev] PR 1081: Allow CLR binaries to be passed to Process.Start

[Alexander Köplinger]

Any updates on this? Might be a good review candidate if you have some spare 
time during the holidays :)
 
-- Alex
 
From: mig...@xamarin.com
Date: Thu, 30 Oct 2014 17:38:18 -0400
Subject: Re: [Mono-dev] PR 1081: Allow CLR binaries to be passed to 
Process.Start
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com; kump...@xamarin.com

In general, it looks fine, but I want to review this in more detail.
I'll add it to my list.
On Thu, Oct 30, 2014 at 4:46 PM, Alexander Köplinger 
 wrote:
This PR (https://github.com/mono/mono/pull/1081) has been sitting in the queue 
for some time. @kumpera already gave his +1 to the patch, so I think we could 
merge it?





-- 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] PR 1464/1465: xbuild fixes to allow dotnet/corefx to compile with Mono

[Alexander Köplinger]

Hey, I sent the following xbuild fixes that are necessary so that the .NET Core 
framework projects can be compiled with Mono:
 
https://github.com/mono/mono/pull/1464
https://github.com/mono/mono/pull/1465
 
Please share your feedback :)
 
-- Alex 
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2

[Alexander Köplinger]

We can add it to the website, do you have a suggestion on which page it makes 
the most sense? On the FAQ pages perhaps?
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: e...@sil.org; mono-devel-list@lists.ximian.com
> Date: Mon, 15 Dec 2014 12:06:17 +
> Subject: Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> 
> > From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
> > boun...@lists.ximian.com] On Behalf Of Eberhard Beilharz
> > 
> > Wouldn't
> > #if __MonoCS__
> > do what you want?
> 
> Yeah, that works.  Thanks!  It's funny though, as I search around for 
> __MonoCS__, there's little if any mention of it on any official documentation 
> - it seems to be all institutional knowledge passed down on StackOverflow.
> ___
> 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] Open source .Net, and TLS 1.1 & 1.2

[Alexander Köplinger]

I'm curious: why do you need it to compile with MS.NET if you're testing Mono 
stuff?
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: alex.koeplin...@outlook.com
> CC: mono-devel-list@lists.ximian.com
> Subject: RE: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> Date: Sun, 14 Dec 2014 17:44:52 +
> 
> > From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
> > 
> > You can find out if you run on Mono by checking if Type.GetType
> > ("Mono.Runtime") != null.
> 
> That's helpful, but doesn't quite solve it, because compilation will fail on 
> windows ...
> 
> I'm looking for something like this...
> 
> #ifdef MONO
> 
> Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Import(junkRootCert);
> try
> {
> #endif
> DoStuff();
> #ifdef MONO
> }
> finally
> {
> 
> Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Remove(junkRootCert);
> }
> #endif
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2

[Alexander Köplinger]

You can find out if you run on Mono by checking if Type.GetType 
("Mono.Runtime") != null.
-- Alex
 
> From: edward.harvey.m...@clevertrove.com
> To: monofo...@my2cents.co.uk
> Date: Sun, 14 Dec 2014 17:07:32 +
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2
> 
> > From: mar...@my2cents.co.uk [mailto:mar...@my2cents.co.uk] On Behalf
> > Of Martin Thwaites
> > 
> > Do we not have a flag for if it's compiled for tests, rather than release?
> 
> I don't need a flag to distinguish between tests & release - I need one to 
> determine if the test is being run on mono or windows.
> 
> For now, I'm just commenting out mono-only sections when I run the test on 
> windows.
> ___
> 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] I would like to contribute to mono however it seems things are in flux due to the integration of .NET Core and .NET Framework; where to start?

[Alexander Köplinger]

...N.N.N.N.N.N.N.N.N.N.N.N.N.N..N.N.N.

Tests run: 6229, Failures: 2, Not run: 125, Time: 110.820 seconds




Test Case Failures:

1) MonoTests.System.Net.DnsTest.GetHostByName : Should raise a SocketException 
(assuming that 'unlikely.xamarin.com' does not exist)

at MonoTests.System.Net.DnsTest.GetHostByName () [0x00089] in 
/Users/bernardschoch/MonoSource/mono/mcs/class/System/Test/System.Net/DnsTest.cs:212

at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)

at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags 
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, 
System.Globalization.CultureInfo culture) [0x00054] in 
/Users/bernardschoch/MonoSource/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230




2) MonoTests.System.Net.HttpWebRequestTest.BeginGetRequestStreamNoClose : Test 
hung.

at MonoTests.System.Net.HttpWebRequestTest.DoRequest (System.Action`2 request, 
System.Action`1 processor) [0x000b0] in 
/Users/bernardschoch/MonoSource/mono/mcs/class/System/Test/System.Net/HttpWebRequestTest.cs:2332

at MonoTests.System.Net.HttpWebRequestTest.BeginGetRequestStreamNoClose () 
[0x0] in 
/Users/bernardschoch/MonoSource/mono/mcs/class/System/Test/System.Net/HttpWebRequestTest.cs:1921

at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)

at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags 
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, 
System.Globalization.CultureInfo culture) [0x00054] in 
/Users/bernardschoch/MonoSource/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230







make[3]: *** [run-test-lib] Error 1

make[2]: *** [do-run-test] Error 1

make[1]: *** [run-test-recursive] Error 1

make: *** [do-run-test] Error 1

bernardhochspro:class bernardschoch$ 

On Thu, Dec 11, 2014 at 2:40 PM, Alexander Köplinger 
 wrote:


Yeah, refreshing the contributing guides is on my list, some of them are a bit 
outdated.
 
I'd say you'll have a better experience developing on Mac than Windows (while 
Mono does work there, it's not really a priority). You can use Xamarin Studio 
or your text editor of choice.
The next step would be to fork and clone the code from GitHub and make sure you 
can actually build it (http://www.mono-project.com/docs/compiling-mono/mac/).
This guide is a good read too: 
http://blog.neteril.org/blog/2013/08/11/the-very-basic-guide-to-contribute-to-mono-bcl/
 
Feel free to reach out if you have more questions :)

-- Alex
 
Date: Thu, 11 Dec 2014 13:06:33 -0500
Subject: Re: [Mono-dev] I would like to contribute to mono however it seems 
things are in flux due to the integration of .NET Core and .NET Framework; 
where to start?
From: bpsch...@gmail.com
To: alex.koeplin...@outlook.com

Hey thanks for the response.

As you might imagine, jumping right into a project like this is a bit 
overwhelming in terms of how things are done.  Many of the links for 
contribution are sometimes conflicting or out of date so it's a bit hard to 
know where to start.


I can either develop under windows or mac, is there a preference where?  On 
windows I have the Visual Studio IDE, on the mac I guess I have a choice of 
monodevelop or xamarin (freebie).  What would be the recommendation?  Or is it 
preference? if so I would probably just use visual studio ide.

Comments?

Bernie 

On Thu, Dec 11, 2014 at 11:08 AM, Alexander Köplinger 
 wrote:



I'd recomend reading this page for a background about the .NET Framework code 
integration into Mono: 
http://www.mono-project.com/docs/about-mono/dotnet-integration/
 
WCF seems to be one of the candidates that could be ported almost immediately. 
As you're offering a big chunk of time it might be best to talk directly with 
Miguel de Icaza (mig...@xamarin.com) to make sure your contributions do not 
overlap with work by the Xamarin team.
 
-- Alex

 
Date: Tue, 9 Dec 2014 17:15:12 -0500
From: bpsch...@gmail.com
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] I would like to contribute to mono however it seems things 
are in flux due to the integration of .NET Core and .NET Framework; where to 
start?

For example, I'm looking at say WCF as

Re: [Mono-dev] I would like to contribute to mono however it seems things are in flux due to the integration of .NET Core and .NET Framework; where to start?

[Alexander Köplinger]

Yeah, refreshing the contributing guides is on my list, some of them are a bit 
outdated.
 
I'd say you'll have a better experience developing on Mac than Windows (while 
Mono does work there, it's not really a priority). You can use Xamarin Studio 
or your text editor of choice.
The next step would be to fork and clone the code from GitHub and make sure you 
can actually build it (http://www.mono-project.com/docs/compiling-mono/mac/).
This guide is a good read too: 
http://blog.neteril.org/blog/2013/08/11/the-very-basic-guide-to-contribute-to-mono-bcl/
 
Feel free to reach out if you have more questions :)
-- Alex
 
Date: Thu, 11 Dec 2014 13:06:33 -0500
Subject: Re: [Mono-dev] I would like to contribute to mono however it seems 
things are in flux due to the integration of .NET Core and .NET Framework; 
where to start?
From: bpsch...@gmail.com
To: alex.koeplin...@outlook.com

Hey thanks for the response.

As you might imagine, jumping right into a project like this is a bit 
overwhelming in terms of how things are done.  Many of the links for 
contribution are sometimes conflicting or out of date so it's a bit hard to 
know where to start.


I can either develop under windows or mac, is there a preference where?  On 
windows I have the Visual Studio IDE, on the mac I guess I have a choice of 
monodevelop or xamarin (freebie).  What would be the recommendation?  Or is it 
preference? if so I would probably just use visual studio ide.

Comments?

Bernie 

On Thu, Dec 11, 2014 at 11:08 AM, Alexander Köplinger 
 wrote:



I'd recomend reading this page for a background about the .NET Framework code 
integration into Mono: 
http://www.mono-project.com/docs/about-mono/dotnet-integration/
 
WCF seems to be one of the candidates that could be ported almost immediately. 
As you're offering a big chunk of time it might be best to talk directly with 
Miguel de Icaza (mig...@xamarin.com) to make sure your contributions do not 
overlap with work by the Xamarin team.
 
-- Alex

 
Date: Tue, 9 Dec 2014 17:15:12 -0500
From: bpsch...@gmail.com
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] I would like to contribute to mono however it seems things 
are in flux due to the integration of .NET Core and .NET Framework; where to 
start?

For example, I'm looking at say WCF as a possibility but some questions pop up?
Will WCF be part of .NET Core? if so should we wait until it's in .NET Core?
If not, then obviously it's a move from .NET Framework.  Are unit test 
available for WCF?  Would there be a duplication of work if MS has some 
forthcoming?

BTW I just picked WCF as an example as it seemed high on the list.

I guess I'm saying, where would I be most useful say with contributing 20+ 
hours a week in the near term (I'm between contract/jobs right now)

BTW I've been doing software development for over 30 years on all sorts of 
platforms and languages but specializing in .NET since the initial .NET 
developer conference in 2000.

Bernie Schoch


___
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] I would like to contribute to mono however it seems things are in flux due to the integration of .NET Core and .NET Framework; where to start?

[Alexander Köplinger]

I'd recomend reading this page for a background about the .NET Framework code 
integration into Mono: 
http://www.mono-project.com/docs/about-mono/dotnet-integration/
 
WCF seems to be one of the candidates that could be ported almost immediately. 
As you're offering a big chunk of time it might be best to talk directly with 
Miguel de Icaza (mig...@xamarin.com) to make sure your contributions do not 
overlap with work by the Xamarin team.
 
-- Alex

 
Date: Tue, 9 Dec 2014 17:15:12 -0500
From: bpsch...@gmail.com
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] I would like to contribute to mono however it seems things 
are in flux due to the integration of .NET Core and .NET Framework; where to 
start?

For example, I'm looking at say WCF as a possibility but some questions pop up?
Will WCF be part of .NET Core? if so should we wait until it's in .NET Core?
If not, then obviously it's a move from .NET Framework.  Are unit test 
available for WCF?  Would there be a duplication of work if MS has some 
forthcoming?

BTW I just picked WCF as an example as it seemed high on the list.

I guess I'm saying, where would I be most useful say with contributing 20+ 
hours a week in the near term (I'm between contract/jobs right now)

BTW I've been doing software development for over 30 years on all sorts of 
platforms and languages but specializing in .NET since the initial .NET 
developer conference in 2000.

Bernie Schoch


___
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] monolite URL

[Alexander Köplinger]

Hey Alex,
monolite is built and uploaded automatically by Wrench: 
https://wrench.mono-project.com/Wrench/ViewTable.aspx?host_id=21&lane_id=4&page=0&limit=20,
 the issue I think was that the build was broken there so a new monolite didn't 
get uploaded, this is now fixed.
 
The thing to keep in mind is that the corlib version inside monolite needs to 
match the runtime version or bootstrapping the classlib build won't work, so 
you can't just keep an old monolite and use it to build newer Mono (at least 
that's how I understood it).
If you don't want to rely on monolite, another option is to just install a 
recent Mono release and use that for bootstrapping (e.g. right now the build 
still works with Mono 3.2).
 
-- Alex
 
> Date: Thu, 11 Dec 2014 01:28:44 +0100
> From: ajlen...@dynamicdevices.co.uk
> To: alex.koeplin...@outlook.com; bperry.volat...@gmail.com; gacev...@gmail.com
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] monolite URL
> 
> 
> On 10/12/2014 20:46, Gabriel Acevedo wrote:
> > Thank you all. I built mono-3.8.0 yesterday, and I was able to get
> > monolite-111 from the URL in Makefile without problems. I guess it
> > changed today.
> >
> > Thanks again.
> 
> The Windows Appveyor builds have been broken for some days as when
> mono_corlib_version (I think) changes, the monolite URL dependency
> changes (?), but often the appropriate download isn't available, and
> similarly sometimes old versions aren't available.
> 
> It would be great not to have this external dependency for build. I
> started out trying to work-around this by removing the
> get-monolite-latest step from the Appveyor config in favour of use of
> EXTERNAL_MCS
> 
> I couldn't quite seem to hit the right incantations though and ran out
> of time, but will revisit.
> 
> Cheers, Alex
> 
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Event logging under Mono

[Alexander Köplinger]

I'd just use a proper logging framework like NLog (http://nlog-project.org/) 
instead of using the rather Windows-specific event log implementation.
 
-- Alex
 
From: spy...@microsoft.com
To: mono-devel-list@lists.ximian.com
Date: Mon, 8 Dec 2014 22:38:26 +
Subject: [Mono-dev] Event logging under Mono









[Sorry if duplicate. I think I originally sent to wrong alias]
 
Hi –
 
I am trying to implement logging for a small application running under Mono on 
a Raspberry Pi. Unfortunately I have been unable to create an event log despite 
following guidance that I have found on the Net,
 and am wondering if there is best practice on how to do this. FWIW, the steps 
I have taken are as follows:
 
1.  
On the Raspberry Pi, I created /var/lib/mono and /var/lib/mono/eventlog 
directories, set directory permission on each to 777 per
http://lists.ximian.com/pipermail/mono-devel-list/2006-August/019853.html.

2.  
Ran the following .NET code, based loosely on
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog(v=vs.110).aspx:

 
using System;
using System.Text;
using System.Diagnostics;

namespace Logging
{
class Program
{
static void Main(string[] args)
{
if (!EventLog.SourceExists("MySource"))
{
EventLog.CreateEventSource("MySource", "MyNewLog");
Console.WriteLine("CreatedEventSource");
Console.WriteLine("Exiting, execute the application a second 
time to use the source.");
return;
}
else
Console.WriteLine("Found the EventLog Source.");
return;
}
}
}
 
If I run this twice on a Windows 8 machine, the first time it comes back with 
“CreatedEventSource”, the second time it comes back with “Found the EventLog 
Source”, and the Windows Event Log has a new log entitled
 MyNewLog. However, if I run it on the Raspberry Pi under mono, I get the 
message “CreatedEventSource” no matter how many times I run it, and no files 
are created in /var/lib/mono/eventlog.
 
What am I missing, or what should I try instead?
 
Spyros Sakellariadis
Microsoft Open Technologies, Inc.
spy...@microsoft.com
 
 




___
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?

[Alexander Köplinger]

To make this 100% clear: .NET implements locale aware number formatting in the 
VM, e.g. for format specifiers like 'e' (exponential) or 'f' (fixed-point)  it 
calls into the VM for formatting.
We don't have this in Mono atm., so the only way is to restrict it to the 
invariant format specifiers (which doesn't hurt existing Mono users, since it 
didn't work before too).
-- Alex
 
From: alex.koeplin...@outlook.com
To: mig...@xamarin.com
Date: Wed, 3 Dec 2014 17:01:42 +0100
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Porting System.Numerics from referencesource, 
approaches for copying code?




Hey,
we need to ensure we only continue for the format specifiers used in 
decimalFmt. Any other format specifier (i.e. culture-specific ones) would 
result in a call into unmanaged code later on 
(https://github.com/akoeplinger/referencesource/blob/mono/System.Numerics/System/Numerics/BigNumber.cs#L611-L634)
 which we of course don't have implemented.
 
Note that it only throws an exception when decimalFmt == false, i.e. when any 
of the culture-specific specifiers was used (which is *not* a common code 
path). This is exactly what the current Mono code also does: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1470
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 10:52:04 -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

Hello Alex,
I am not sure I am understanding this.
This looks like we are choosing to not bring features that we are missing?   
Why would we want to do that?
Miguel
On Wed, Dec 3, 2014 at 10:33 AM, Alexander Köplinger 
 wrote:



Mono today also only supports the format specifiers used in decimalFmt: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471
 
So using this #if for Mono is the correct way to go.
 
(reposted, seems like the mailing list ate my previous mail) 

-- Alex
 
From: mig...@xamarin.com
Date: Sat, 29 Nov 2014 12:06:20 -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

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 
 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 
 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 accesse

Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?

[Alexander Köplinger]

Hey,
we need to ensure we only continue for the format specifiers used in 
decimalFmt. Any other format specifier (i.e. culture-specific ones) would 
result in a call into unmanaged code later on 
(https://github.com/akoeplinger/referencesource/blob/mono/System.Numerics/System/Numerics/BigNumber.cs#L611-L634)
 which we of course don't have implemented.
 
Note that it only throws an exception when decimalFmt == false, i.e. when any 
of the culture-specific specifiers was used (which is *not* a common code 
path). This is exactly what the current Mono code also does: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1470
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 3 Dec 2014 10:52:04 -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

Hello Alex,
I am not sure I am understanding this.
This looks like we are choosing to not bring features that we are missing?   
Why would we want to do that?
Miguel
On Wed, Dec 3, 2014 at 10:33 AM, Alexander Köplinger 
 wrote:



Mono today also only supports the format specifiers used in decimalFmt: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471
 
So using this #if for Mono is the correct way to go.
 
(reposted, seems like the mailing list ate my previous mail) 

-- Alex
 
From: mig...@xamarin.com
Date: Sat, 29 Nov 2014 12:06:20 -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

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 
 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 
 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

Re: [Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?

[Alexander Köplinger]

Mono today also only supports the format specifiers used in decimalFmt: 
https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471
 
So using this #if for Mono is the correct way to go.
 
(reposted, seems like the mailing list ate my previous mail) 
-- Alex
 
From: mig...@xamarin.com
Date: Sat, 29 Nov 2014 12:06:20 -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

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 
 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 
 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

h

Re: [Mono-dev] file handle leak in cpu_load

[Alexander Köplinger]

I opened a PR on your behalf: https://github.com/mono/mono/pull/1434 
-- Alex
 
> Date: Tue, 2 Dec 2014 13:02:54 +0100
> From: markus.b...@zkrd.de
> To: alex.koeplin...@outlook.com
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] file handle leak in cpu_load
> 
> Not easily, as I do not have an account on GitHub.
> 
> Am Tue, 2 Dec 2014 12:12:04 +0100
> schrieb Alexander Köplinger :
> 
> > Can you send a pull request on GitHub? 
> >  
> > > Date: Tue, 2 Dec 2014 12:01:29 +0100
> > > From: markus.b...@zkrd.de
> > > To: mono-devel-list@lists.ximian.com
> > > Subject: [Mono-dev] file handle leak in cpu_load
> > > 
> > > Hi all,
> > > 
> > > last week we used the profiler of a mono 3.10.0 installation on 
> > > Linux x86_64 and we found it leaks file handles (for /proc/loadavg).
> > > 
> > > I located the problem in the function cpu_load in 
> > > mono/utils/mono-counters.c. If a premature return is taken, the
> > > FILE pointer f is not fclose()-ed.
> > > 
> > > I propose the following fix:
> > > 
> > > ---
> > >   mono/utils/mono-counters.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/mono/utils/mono-counters.c b/mono/utils/mono-counters.c
> > > index 1e0840c..c669454 100644
> > > --- a/mono/utils/mono-counters.c
> > > +++ b/mono/utils/mono-counters.c
> > > @@ -360,6 +360,7 @@ cpu_load (int kind)
> > >  FILE *f = fopen ("/proc/loadavg", "r");
> > >  if (f) {
> > >  len = fread (buffer, 1, sizeof (buffer) - 1, f);
> > > +   fclose (f);
> > >  if (len > 0) {
> > >  buffer [len < 511 ? len : 511] = 0;
> > >  b = buffer;
> > > @@ -374,7 +375,6 @@ cpu_load (int kind)
> > >  }
> > >  }
> > >  }
> > > -   fclose (f);
> > >  }
> > >   #endif
> > >  return 0;
> > > -- 
> > > 
> > > It applies on master and also (with an offset of -32 lines) on 
> > > mono-3.10.0-branch.
> > > 
> > > What do you think?
> > > 
> > > Regards,
> > > Markus
> > > ___
> > > Mono-devel-list mailing list
> > > Mono-devel-list@lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >   
> 
> 
> -- 
> Markus Beth   ZKRD
> Software DeveloperZentrales Knochenmarkspender-Register
> Fon: +49 731 1507-421 fuer die Bundesrepublik Deutschland
> Fax: +49 731 1507-502 Gemeinnuetzige Gesellschaft mbH
> http://www.zkrd.de/   Helmholtzstraße 10, 89081 Ulm, Germany
> -
> Registergericht: Amtsgericht Ulm, HRB 2566, UID-Nr.: DE269639005
> Geschäftsführer: Dr. Peter Mein und Dr. Dr. Carlheinz Müller
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono for Windows test build (Mono-devel-list Digest, Vol 116, Issue 2)

[Alexander Köplinger]

> > Btw. build.bat could be integrated into the bash files quite easily
> > I think (for consistency), it just invokes msbuild.
> 
> It already is, in the top-level scripts

What I meant was getting rid of build.bat completely and just invoking MSBuild 
directly like you do here: 
https://github.com/directhex/newbuilder/blob/455c8d58774bfb6ecf1dff847c47f4c6eeabec47/defs/mono#L60
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] file handle leak in cpu_load

[Alexander Köplinger]

Can you send a pull request on GitHub? 
 
> Date: Tue, 2 Dec 2014 12:01:29 +0100
> From: markus.b...@zkrd.de
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] file handle leak in cpu_load
> 
> Hi all,
> 
> last week we used the profiler of a mono 3.10.0 installation on 
> Linux x86_64 and we found it leaks file handles (for /proc/loadavg).
> 
> I located the problem in the function cpu_load in 
> mono/utils/mono-counters.c. If a premature return is taken, the FILE 
> pointer f is not fclose()-ed.
> 
> I propose the following fix:
> 
> ---
>   mono/utils/mono-counters.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mono/utils/mono-counters.c b/mono/utils/mono-counters.c
> index 1e0840c..c669454 100644
> --- a/mono/utils/mono-counters.c
> +++ b/mono/utils/mono-counters.c
> @@ -360,6 +360,7 @@ cpu_load (int kind)
>  FILE *f = fopen ("/proc/loadavg", "r");
>  if (f) {
>  len = fread (buffer, 1, sizeof (buffer) - 1, f);
> +   fclose (f);
>  if (len > 0) {
>  buffer [len < 511 ? len : 511] = 0;
>  b = buffer;
> @@ -374,7 +375,6 @@ cpu_load (int kind)
>  }
>  }
>  }
> -   fclose (f);
>  }
>   #endif
>  return 0;
> -- 
> 
> It applies on master and also (with an offset of -32 lines) on 
> mono-3.10.0-branch.
> 
> What do you think?
> 
> Regards,
> Markus
> ___
> 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] How to report bug in mono/monodevelop/nuget?

[Alexander Köplinger]

You can file Mono and MonoDevelop bugs at https://bugzilla.xamarin.com 
-- Alex
 
> Date: Tue, 2 Dec 2014 10:42:23 +0100
> From: f...@dndg.it
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] How to report bug in mono/monodevelop/nuget?
> 
> Hi,
> 
> I think I found a little bug in NuGet when running the package manager
> from inside MonoDevelop, but I don't know where to report it. It is
> obviously a problem related to how authors name files inside packages
> but I have a feeling that it should resolved in the NuGet implementation
> as used in MonoDevelop. So, I'll just report it here and hope someone
> will redirect me to the correct place. :)
> 
> With NuGet you can specify that your package needs to add some tags
> (usually configuration items) to an XML file. You can name it Web.config
> or web.config and under Windows (case insensitive file system)
> everything goes inside the correct, already existing file. But under
> Linux if two package authors use different casing you end up with two
> (or more) files each one containing part of the configuration. I know
> about MONO_IOMAP but it doesn't seem the right answer in this case.
> 
> Any idea?
> 
> federico
> 
> -- 
> Federico Di Gregorio federico.digrego...@dndg.it
> Di Nunzio & Di Gregorio srl   http://dndg.it
>  A desobediência é uma virtude necessária à criatividade. -- Raul Seixas
> ___
> 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] Mono for Windows test build

[Alexander Köplinger]

Hey Jo, I tried it and it installed fine for me.
However, the version is currently set to 3.12.1 in 
https://github.com/directhex/newbuilder/blob/master/resources/build.bat and 
https://github.com/directhex/newbuilder/blob/master/resources/bat/setmonopath.bat,
 I guess we should change that to 3.12.0.
 
Btw. build.bat could be integrated into the bash files quite easily I think 
(for consistency), it just invokes msbuild.
 
The BCL assemblies are taken from the 3.10 MDK installer as far as I can see?
-- Alex
 
> Date: Mon, 1 Dec 2014 17:44:51 +
> From: direct...@apebox.org
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] Mono for Windows test build
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi everyone
> 
> Following on from lots of recent discussion, I've got the first test
> build of Mono for Windows which I'd describe as "usable".
> 
> This is based on the mono-3.12.0-branch branch on github.
> 
> Please report success or failure with it, as I'm not a Windows expert.
> Especially interested in success/failure from Windows embedders.
> 
> I'll get the scripts involved in building this stuff (so you can try
> it locally, developery types) added to github.com/mono/release.git by
> the end of tomorrow.
> 
> https://drive.google.com/open?id=0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU&authuser=0
> 
> == Headlines ==
> 
> * Runtime compiled with Microsoft Visual Studio 2013, for extra speed
> * SGen by default
> * Includes Gtk#, F#, IronPython, Boo, IronRuby (as per Mono MDK for Mac)
> * .lib files for libmono (Boehm) and libmonosgen (SGen)
> * Installs side-by-side with old 3.2.3 installer
> 
> == Known Issues ==
> 
> * No policy files for Gtk# (but who has Gtk#2.10 apps these days?)
> * Works from cmd.exe or Cygwin, but not MSYS
> * FSharp does not run from cmd.exe, fails with a timezone error (works
> in Cygwin)
> * Xamarin Studio does not run from cmd.exe with "mono
> XamarinStudio.exe" (works in Cygwin)
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJUfKkPAAoJEMkPnLkOH60MRjUH/23JvJz6XeEnp8SW1t0IdWLV
> Lkpr1I5KklVlBsw9RaTLoXozIDwrCRf1npMzZI85Q3UUtMXYmzf3V+VM8mbhC0hG
> z1gJY1UXTVVoz1TSGHVQ04l4Kldq0NYJI6h6z2HzrWGq2ball5voM9PqrdcvLKD9
> +iaVGmZQ3u7DbyDO2417wfRbZkebDuastDwKLtpk8Z5L7Hq2RBI8t19elPKS1Cu2
> cqN8PQoXpyylUuxnE4hfkLS09bMutaqGRPNE5+SnwrHqsbAHF6szv4z+iAFQa4j5
> r81N+UhF4t85xZlHGke6w4PC2kjCEFVCj/Qp2Chd2VA1r4WMyk0tphuROvIwpwM=
> =SumB
> -END PGP SIGNATURE-
> ___
> 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] Building Mono on Windows - And Having a Windows Installer again

[Alexander Köplinger]

Hey Alex,
 
Jo Shields is currently working on revamping the Windows Installer in his repo: 
https://github.com/directhex/newbuilder
I contributed the WiX setup files for creating an MSI installer. Jo sent me 
this link for a preview build (the usual caveats apply): 
https://drive.google.com/file/d/0Bz6-k9ELOQf3YTE1RHV3Y0dNaFU/view
 
Btw. while developing the WiX setup I used the binaries from your AppVeyor 
build, it all worked fine :)
 
Can you maybe also make changes to 
http://www.mono-project.com/docs/compiling-mono/windows/ (just click the "edit 
page on github" link), so it reflects what is necessary right now to build Mono 
on Windows? I think that page is pretty outdated right now.
 
-- Alex
 
 
> Date: Fri, 28 Nov 2014 14:29:29 +0100
> From: ajlen...@dynamicdevices.co.uk
> To: monodanm...@yahoo.com
> CC: mono-devel-list@lists.ximian.com
> Subject: Re: [Mono-dev] Building Mono on Windows - And Having a Windows   
> Installer again
> 
> Hi Daniel,
> 
> On 30/11/2014 02:13, Edward Ned Harvey (mono) wrote:
> >> 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.
> >
> 
> As Edward says, I did put a bit of time into this and we do have what I
> think is a reliable automated build process on the Windows platform,
> although as ever there are improvements that can be made,
> 
> Stepping back for a second there's a couple of documents that I've been
> maintaining on building Mono under Windows with Cygwin (prior to being
> introduced to Appveyor CI)
> 
> This covers 3.4.0 - 3.6.0,
> http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows
> 
> And this covers 3.8.0+
> http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows
> 
> It gets you to the point you can just about use Mono but there are some
> remaining issues I have yet to address,
> 
> e.g.
> 
> - understanding how the Mono installer works
> - dealing with hard coded library references in the build (I think the
> installer may do some of this)
> - ensuring that Windows batch files for e.g. mcs, mono, xbuild are
> correcly created (Again I think the installer may do some of this)
> 
> ...
> 
> Further to that I then created a build script for the Appveyor build
> platform, based on work and suggestions from Mladen Mihajlovic, which is
> currently automatically building Mono on commits to the repo
> 
> You can see the build history here:
> https://ci.appveyor.com/project/ajlennon/mono-817
> 
> The output "artifact" from any of these builds is currently a set of
> Mono binaries which you _should_ be able to download and use straight
> away (would love some feedback on any issues here)
> 
> e.g. https://ci.appveyor.com/project/ajlennon/mono-817/build/artifacts
> 
> You should also be able to take the script I created and use this to
> build your own build of Mono, independently of the instruction documents
> I reference above. In particular there's a useful line there that
> automates installation of needed Cygwin packages.
> 
> See here: https://github.com/mono/mono/blob/master/appveyor.yml
> (build_script section)
> 
> What I'd like to do next is to modify this script to take the bones of
> the Windows installer and generate an output artifact which was an MSI
> installer.
> 
> Unfortunately this is not trivial (to me at least!), and also requires
> pulling in some GTK# dependencies and so forth. I want to progress this
> but have not yet had time due to work commitments.
> 
> Also, and perhaps more importantly the Cygwin build may all become
> somewhat deprecated as Jo Shields appears to be doing some excellent
> work to make Mono build under MSVC.
> 
> Once this is achievable, to my mind it will be a vastly superior way to
> build Mono, instead of the 2 hour+ Cygwin build with all the faff.
> 
> >> 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 
> > proces

Re: [Mono-dev] List of cleanup candidates for Mono 4.0

[Alexander Köplinger]

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?

[Alexander Köplinger]

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] List of cleanup candidates for Mono 4.0

[Alexander Köplinger]

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?

[Alexander Köplinger]

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

[Mono-dev] Porting System.Numerics from referencesource, approaches for copying code?

[Alexander Köplinger]

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

Re: [Mono-dev] List of cleanup candidates for Mono 4.0

[Alexander Köplinger]

I agree, breaking users without a very good reason is a no-go. I'm just worried 
that those old scripts would break anyway when they expect a 2.0 profile and 
there suddenly isn't one anymore, so we might as well break with an obvious 
"gmcs not found" instead of harder-to-debug errors.
This obviously needs more discussion/investigation and that's exactly why I 
posted these proposals :)
 
-- Alex
 
> To: mono-devel-list@lists.ximian.com
> From: robe...@gmx.net
> Date: Thu, 27 Nov 2014 19:26:32 +0100
> Subject: Re: [Mono-dev] List of cleanup candidates for Mono 4.0
> 
> On 27.11.2014 19:19, Alexander Köplinger wrote:
> > Hey,
> > * gmcs/dmcs -> they just redirect to mcs now and without the 2.0 etc 
> > profiles it doesn't make sense to still have them
> 
> It doesn't make sense to us, but removing them would just break
> thinks downstream.
> 
> It's really annoying when such changes are done just for the
> sake of OCD, so please stop this.
> 
> 
> ___
> 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

[Alexander Köplinger]

Hey,
* gmcs/dmcs -> they just redirect to mcs now and without the 2.0 etc profiles 
it doesn't make sense to still have them

I like to keep them, to avoid breaking third party build scripts. Good point, 
however aren't they gonna break anyway when they rely on 2.0 SDK which is no 
longer there anymore? Maybe now is the time to make people aware they should 
update the scripts :)  * 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. * Rx -> I'm not really familiar with this one, but I 
think it's also on NuGet+open source

This one I know contains patches that make it work on Mono.   Without these, 
they wont work.  So this might have to wait. Interesting. I had a look at the 
NuGet package and it ships a portable-net45 version, I always thought this was 
compatible with Mono? If not, we could maybe look at upstreaming the patches. 
-- Alex   ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] List of cleanup candidates for Mono 4.0

[Alexander Köplinger]

Judging from the recent version bump in git to 3.99 it looks like the next 
release after 3.12 will be Mono 4.0.
 
As this is a major release it'll allow us to remove some cruft that is no 
longer needed, so I thought I'd start a list of things I'd like to see removed:
 
* net2.0/4.0 profiles -> this is already in progress
* gmcs/dmcs -> they just redirect to mcs now and without the 2.0 etc profiles 
it doesn't make sense to still have them
* EntityFramework -> apart from the fact that we ship a horribly outdated 
version right now, I see no reason to include this hefty 5+MB DLL in Mono given 
that EF is open-source and available on NuGet
* aspnetwebstack (i.e. MVC+WebApi) -> same reasons as for EF, open-source and 
on NuGet, should be used from there
* Rx -> I'm not really familiar with this one, but I think it's also on 
NuGet+open source
 
I'd love to hear your comments/thoughts on this :)
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] State of the Jenkins builds

[Alexander Köplinger]

Great, thanks for the update!
 
Date: Wed, 26 Nov 2014 11:27:13 -0700
Subject: Re: State of the Jenkins builds
From: ale...@thenull.net
To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com

Hi Alex!
I'm sorry for not getting this done earlier, but I'm working on the FSW issues 
right now (fixing failed tests with https://github.com/mono/mono/pull/1386 
right now) If have trouble finishing this week, I will revert the revamp and 
save it for the next release.- Alexis

On Wed, Nov 26, 2014, 11:20 AM Alexander Köplinger 
 wrote:



As far as I can see, the only things preventing us from having a green Jenkins 
build again are as follows:
 
- 69 unit test failures in Microsoft.Build -> those are caused by the recent 
removal of the 2.0 profile
- 5 unit test failures in System.Web.DynamicData -> those failed after the 
integration of System.ComponentModel.DataAnnotations from MS referencesource
- the unhandled exception in the System.Web test suite -> caused by the 
FileWatcher changes
 
The last one is the more significant one, it's been this way since almost a 
month. @alexischr said he would take a look into it: 
https://github.com/mono/mono/commit/717c6de1cc49dabb2ecaa2a844a8b2b162c21440#commitcomment-8373085
 
Alexis, can you give us a quick update on your investigation?
 
-- Alex
  
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] State of the Jenkins builds

[Alexander Köplinger]

As far as I can see, the only things preventing us from having a green Jenkins 
build again are as follows:
 
- 69 unit test failures in Microsoft.Build -> those are caused by the recent 
removal of the 2.0 profile
- 5 unit test failures in System.Web.DynamicData -> those failed after the 
integration of System.ComponentModel.DataAnnotations from MS referencesource
- the unhandled exception in the System.Web test suite -> caused by the 
FileWatcher changes
 
The last one is the more significant one, it's been this way since almost a 
month. @alexischr said he would take a look into it: 
https://github.com/mono/mono/commit/717c6de1cc49dabb2ecaa2a844a8b2b162c21440#commitcomment-8373085
 
Alexis, can you give us a quick update on your investigation?
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, Issue 45)

[Alexander Köplinger]

I beg to differ :)
 
The same argument could be made the other way round: if someone only watches 
GitHub and not the mailing-list, they also miss out.
I filter the notifications from GitHub exactly the same way as I do the mails 
on this list (and the threading option in mail clients really helps here), so 
for me it doesn't make a difference.
 
Anyway, sorry for sidetracking this thread, I can deal with whatever works best 
for the Mono team.
We should take a fresh look at the PRs anyway as soon as the MS referencesource 
integration is done.
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 26 Nov 2014 12:41:21 -0500
Subject: Re: [Mono-dev] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, 
Issue 45)
To: alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com

Hey Alex,
I covered this on this mailing list a few weeks ago.
Discussing in a pull request is a terrible idea, as it keeps the discussion 
away from the various people that might need to weigh on a particular topic.   
The discussion often involves the person submitting, and a couple of curious 
people, but it does not reach all the stake holders.   It requires constant 
monitoring and constant care.  And if someone does not have the time to go and 
click through every discussion on pull request for every project that matters, 
decisions happen in what amounts to closed doors.
Sure, it is open.   Just like having a discussion in a caffe is, and making 
decisions without other stake holders.
So while initially I was lukewarm at the idea of discussing things on pull 
request, now I think it is actively damaging to open source projects.
Miguel 
On Wed, Nov 26, 2014 at 12:34 PM, Alexander Köplinger 
 wrote:



Tip: you can "unwatch" the repo on GitHub, then you only get notifications for 
threads you participated in.

I'm a bit torn about mandating that every PR discussion needs to happen on this 
mailing list, mainly because I really like GitHub's UI and being able to track 
back the PR discussion from the commit.
 
... and I really don't feel comfortable with mailman sending me my plaintext 
password in 2014.
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 26 Nov 2014 12:10:03 -0500
To: direct...@apebox.org
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, 
Issue 45)

Hello,
I think we need to have a deeper discussion on the PR1297.
I do not think that we should have these discussions on the pull requests, this 
is a great example of another pull request discussion that just got lost.   
GitHub is very spammy with notifications, so I personally just filter that out 
(and so do many other people).
Pull requests should be discussed in this mailing list.
On Wed, Nov 26, 2014 at 8:05 AM, Jo Shields  wrote:
-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1







On 25/11/14 23:00, Rodrigo Kumpera wrote:

> Hi ppl,

>

> We're rounding up mono 3.12 as we speak. (y'all probably heard the

> github gossip about such a branch existing ;)

>

> This would be a great opportunity to gather feedback on what

> blocking bugs you've been facing that can be quickly addressed for

> this release.



It'd be great to get PR1297 and PR1319 sorted in time for 3.12, plus a

bunch of recent Windows/MSVC commits so I can work towards a stable

3.12 Windows installer:



9bdd77969a8f9057f3b46994135d39adb3ef216f

1d6b8a75fa31d60e9ddbc0b9eddbf05ed3fb6c12

9f6f6a9ccef9e65adc281b5c0609f79d1dce6fcf

d2b8c8557b90dfaef3d3b582a847fda12630c680

ab61b5c7ad106187b00be32bc356e2e197467745

0279e7dc28c2d25ebe2fb87289b78c891ff84a15

cf4d77d21d2d15f5775a1cf72bfe8486e5a0dff5

67da1215f33fb20fe948402d8aa8e38a82c29598

076e80f725d16d85d74e8aecbe281af53ebc62c2



-BEGIN PGP SIGNATURE-

Version: GnuPG v1



iQEcBAEBAgAGBQJUddAbAAoJEMkPnLkOH60MIfUIAIiPpCFnypB5xjirQ9hyPOZV

clunW3vzrZ6WO/CXxmKQRjyF8P/awXRW1EBMZX+U8rpRdG15tNL1OveLg4e84Su/

NUjdsUykouGLtfwGK7/pM8jZBE4/ewciR1ygaK+fuw9vvvnN95pvJTcqgIJXNi40

1OEusLP9aLwJXOkxYQRlGZMF2S7KfjPXU5vHi5L2YGknlz0u+73I1eT4wdPzWp4K

YVHESxEqcQDzSWYSUib8Jbikcw/hzKkqiQq6kK8rwOY5qXtmqobs1Hlab87FJCdY

niQhZuUcjDYaQb6OMLO0vOu4ckoacVgu2joDl4kcReI/Ygr87/gbmheZGqU73UY=

=G4dc

-END PGP SIGNATURE-

___

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] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, Issue 45)

[Alexander Köplinger]

Tip: you can "unwatch" the repo on GitHub, then you only get notifications for 
threads you participated in.
I'm a bit torn about mandating that every PR discussion needs to happen on this 
mailing list, mainly because I really like GitHub's UI and being able to track 
back the PR discussion from the commit.
 
... and I really don't feel comfortable with mailman sending me my plaintext 
password in 2014.
 
-- Alex
 
From: mig...@xamarin.com
Date: Wed, 26 Nov 2014 12:10:03 -0500
To: direct...@apebox.org
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, 
Issue 45)

Hello,
I think we need to have a deeper discussion on the PR1297.
I do not think that we should have these discussions on the pull requests, this 
is a great example of another pull request discussion that just got lost.   
GitHub is very spammy with notifications, so I personally just filter that out 
(and so do many other people).
Pull requests should be discussed in this mailing list.
On Wed, Nov 26, 2014 at 8:05 AM, Jo Shields  wrote:
-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1







On 25/11/14 23:00, Rodrigo Kumpera wrote:

> Hi ppl,

>

> We're rounding up mono 3.12 as we speak. (y'all probably heard the

> github gossip about such a branch existing ;)

>

> This would be a great opportunity to gather feedback on what

> blocking bugs you've been facing that can be quickly addressed for

> this release.



It'd be great to get PR1297 and PR1319 sorted in time for 3.12, plus a

bunch of recent Windows/MSVC commits so I can work towards a stable

3.12 Windows installer:



9bdd77969a8f9057f3b46994135d39adb3ef216f

1d6b8a75fa31d60e9ddbc0b9eddbf05ed3fb6c12

9f6f6a9ccef9e65adc281b5c0609f79d1dce6fcf

d2b8c8557b90dfaef3d3b582a847fda12630c680

ab61b5c7ad106187b00be32bc356e2e197467745

0279e7dc28c2d25ebe2fb87289b78c891ff84a15

cf4d77d21d2d15f5775a1cf72bfe8486e5a0dff5

67da1215f33fb20fe948402d8aa8e38a82c29598

076e80f725d16d85d74e8aecbe281af53ebc62c2



-BEGIN PGP SIGNATURE-

Version: GnuPG v1



iQEcBAEBAgAGBQJUddAbAAoJEMkPnLkOH60MIfUIAIiPpCFnypB5xjirQ9hyPOZV

clunW3vzrZ6WO/CXxmKQRjyF8P/awXRW1EBMZX+U8rpRdG15tNL1OveLg4e84Su/

NUjdsUykouGLtfwGK7/pM8jZBE4/ewciR1ygaK+fuw9vvvnN95pvJTcqgIJXNi40

1OEusLP9aLwJXOkxYQRlGZMF2S7KfjPXU5vHi5L2YGknlz0u+73I1eT4wdPzWp4K

YVHESxEqcQDzSWYSUib8Jbikcw/hzKkqiQq6kK8rwOY5qXtmqobs1Hlab87FJCdY

niQhZuUcjDYaQb6OMLO0vOu4ckoacVgu2joDl4kcReI/Ygr87/gbmheZGqU73UY=

=G4dc

-END PGP SIGNATURE-

___

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] Mono Posix helper exception

[Alexander Köplinger]

Turn on tracing 
(http://www.mono-project.com/docs/advanced/runtime/logging-runtime-events/) and 
see why it fails to load the library.
 
-- Alex 
 
Date: Tue, 25 Nov 2014 09:58:40 +
From: techi...@gmail.com
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono Posix helper exception

Please find below file command o/p.
#file libMonoPosixHelper.so
libMonoPosixHelper.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), 
dynamically linked, not stripped

I have built mono using --disable-mcs-build --enable-minimal=aot,profiler 
--enable-small-config configure option.
Is this will create issue ?

On Tue, Nov 25, 2014 at 9:49 AM, Rafael Teixeira  wrote:
Turn Mono's tracing on to see where it is trying to find the lib. Also are you 
sure the library matches the architecture? ARM/Intel, 32/64 bits, etc.

On Tue, Nov 25, 2014, 07:29 techi eth  wrote:
I do have the same under /usr/lib.Please find below ls output.
#ls -la | grep Mono-rw-r--r--1 root root797994 Nov 25 08:54 
libMonoPosixHelper.a-rwxr-xr-x1 root root  1049 Nov 25 08:54 
libMonoPosixHelper.la-rwxr-xr-x1 root root514621 Nov 25 08:54 
libMonoPosixHelper.so

On Tue, Nov 25, 2014 at 2:50 PM, Rafael Teixeira  wrote:
You didn't install the native libmonoposixhelper.so library needed to use that 
functionality :(

On Tue, Nov 25, 2014, 07:13 techi eth  wrote:
Hi,
I have found one exception when running test to access serial port on Linux 
.Can anyone suggest what is missing.I have copied test O/P below.
Note : I am having libMonoPosixHelper.so under library 
path.--#mono --config config 
serial.exeEnter port name/dev/ttyS0libMonoPosixHelper.sopress 's' for 
startsprocess failed

Unhandled Exception:System.DllNotFoundException: libMonoPosixHelper.so  at 
(wrapper managed-to-native) System.IO.Ports.SerialPortStream:close_serial (int) 
 at System.IO.Ports.SerialPortStream.Dispose (Boolean disposing) [0x0] in 
:0  at System.IO.Ports.SerialPortStream.Finalize () [0x0] 
in :0--

___

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] Long time Mono devs: share lessons learned for .NET Core

[Alexander Köplinger]

MS is looking for some insights into the early days of Mono for the .NET Core 
effort over at the .NET foundation forums 
(http://forums.dotnetfoundation.org/t/the-early-days-of-mono/497):
 
"I'm working on banging into shape the engineering systems for the Linux ports 
of the .NET Core effort.  I was wondering whether anyone knows about the early 
days of Mono.  What was the engineering system (CI, etc.) like back then?  Was 
there any aspect that was really good or really bad that we can learn from when 
working on .NET Core?"
 
I guess Miguel and the other folks at Xamarin are around the longest, but I 
thought I'd post it here in case someone else has interesting stories to share 
:)
 
-- Alex
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono & .Net difference - handling xs:extension please help

[Alexander Köplinger]

For completeness sake I tested it on Mono 3.10 and latest master, it throws the 
same error there too, so it's definitely a bug in Mono :)
-- Alex
 
Date: Wed, 12 Nov 2014 09:49:34 -0200
From: mono...@gmail.com
To: infoseeker...@gmail.com
CC: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Mono & .Net difference - handling xs:extension  please 
help

Probably is the core System.Xml class library assembly that misses some 
functionality. It is kind of lower priority these days as most people is moving 
to schema-less serialization with either Xml or JSON.Surely nobody needed to 
exercise the extension mechanism before, so that's is why it is still broken, 
that is characteristic of any Open Source project.If you really need it please 
open an issue, and help pinpoint the real cause for the behavior, better yet, 
if you can: fix it and send a Pull Request.
Best regards,
Rafael Teixeira
O..:.)


On Wed, Nov 12, 2014 at 8:51 AM, MarLOne  wrote:
Hello Timotheus,



I have the answer for you.



I have a VM with Mint17 which has Mono runtime 3.2.8 which is one major

version that I reported earlier. So I build a console application to test

using this schema (embedded resource) with this sample instance document.



This also gives me a good test of compatibility that Mono has been

promoting. I then took this console application and run it in my Windows 7

with the most up to date .Net installed. It ran perfectly as expected

verbatim without recompilation.



This therefore indicates the IL code thus generated is not at fault.



I then took this console application and xml document to my Mint 17 and ran

it. As expected, it failed with the same message produced by the old version

of Mono runtime.



Therefore I would dare to claim that the problem exists much further back

and is in the Mono runtime. What I am using is nothing new or even edge

case. In fact, the construct is as old as .Net2.



So what next? If I stay with Mono, to get around this gotcha I have to

abandon a perfectly valid schema (data model). This is placing the cart in

front of the horse.



I opened the instance document in MonoDevelop ver 4.2.2 (yes it is old and

it is because Linux/Mint does not allow me to move to newer version) and

then hit Tools > Xml > Validate. Well the screen lights up like a Christmas

tree and pointing to the same place as I have found.



Even more worryingly, that tool does not even handle the xsi:schemaLocation

hint while Eclipse did that flawlessly.



I appreciate the great work of Open Source in bringing Mono to something

workable. But after falling into holes so many times believing this

"cross-platform development tool", Mono has lost my trust particularly not

knowing where is the next incompatible gotcha! This is no different than a

calculator produces erroneous result with certain expression kind and one

does not know which expression pattern. This problem plus the others that I

have unearthed are seriously matters. I would rather prefer Mono fails to

compile or supporting MS .Net construct (fail early and fail loud) than

slipping in minefield silently like this wasting people's time.



Has this simple scenario been tested?



MarL















--

View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552p4664559.html

Sent from the Mono - Dev mailing list archive at Nabble.com.

___

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] SetThreadPriority patch for mono-3.2.8

[Alexander Köplinger]

I of course meant a PR against master. Older branches are generally never 
touched, except maybe if something serious happens like a big security hole. 
-- Alex
 
Date: Thu, 6 Nov 2014 12:48:29 +0100
From: ajlen...@dynamicdevices.co.uk
To: alex.koeplin...@outlook.com; d...@aasimon.org; 
mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] SetThreadPriority patch for mono-3.2.8


  

  
  


On 06/11/2014 12:37, Alexander
  Köplinger wrote:



  
  There is
  a PR that also claims to implement SetThreadPriority 
(https://github.com/mono/mono/pull/1272),
  but it has many other unrelated changes, so not in a state to
  be merged.

From a quick
  look, your patch seems to be much more focused and thus more
  likely to get merged. Can you open a pull request on GitHub?

 

-- Alex
 



Hi,



Could somebody possibly help me understand the philosophy behind
patching older releases as I have been wondering about this. 



For example would this patch against 3.2.8 be applied against the
mono-3.2.8-branch? Or is master only ever updated?



If the branch is updated would the installers for Mono 3.2.8 be
updated and if they would be updated then how would the versioning
change?



Thanks!



Alex

 
  ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] SetThreadPriority patch for mono-3.2.8

[Alexander Köplinger]

There is a PR that also claims to implement SetThreadPriority 
(https://github.com/mono/mono/pull/1272), but it has many other unrelated 
changes, so not in a state to be merged.
>From a quick look, your patch seems to be much more focused and thus more 
>likely to get merged. Can you open a pull request on GitHub?
 
-- Alex
 
> Date: Thu, 6 Nov 2014 09:12:02 +0100
> From: d...@aasimon.org
> To: mono-devel-list@lists.ximian.com
> Subject: [Mono-dev] SetThreadPriority patch for mono-3.2.8
> 
> Hi mono devs
> 
> I created a patch for SetThreadPriority support in mono-3.2.8 and would 
> very much like som feedback on it.
> It can be found here:
>   https://gist.github.com/aasimon/c8ae6fc3cf5d9b82b6ca
> Comments are welcome both here on the list as well as on the actual gist 
> paste.
> 
> Kind regards
> Bent Bisballe Nyeng
> ___
> 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] Mono and vNext, What is microsoft supporting

[Alexander Köplinger]

Well the issue with the NuGet-based BCL libraries like System.Console is that 
the actual implementation still depends on Windows internals, e.g. a very quick 
peak with a decompiler on the new System.Console NuGet library reveals dozens 
of DllImport("api-ms-win-core-file-l1-1-0.dll") and corresponding P/Invokes. I 
can't see how that would work on other platforms.
 
The things they're testing with Mono is akin to their support for the "full" 
Desktop .NET framework, which is a different story than CoreCLR.
-- Alex
 
From: mono...@gmail.com
Date: Wed, 5 Nov 2014 11:57:11 +
Subject: Re: [Mono-dev] Mono and vNext, What is microsoft supporting
To: monofo...@my2cents.co.uk; alex.koeplin...@outlook.com
CC: mono-devel-list@lists.ximian.com

As I follow the github discussions in some of the asp.net vnext subprojects, I 
see them testing on Mono (in MacOS X) as part of the development process, but 
yet some things are lagging a bit... :)

On Wed Nov 05 2014 at 9:43:28 AM Martin Thwaites  
wrote:
So, after thinking about this further.  The question I have is not really about 
CoreCLR.
What I want to know is, the libraries that Microsoft are making available via 
their nuget (myget at the moment), are these going to be tested again .net, 
mono and CoreCLR? I.e will the libraries be cross platform?
Thanks

Martin



I just asked about CoreCLR on Linux during today's ASP.NET vNext community 
standup and the answer was:
"CoreCLR runs on Windows. On Linux you use Mono." 
(https://www.youtube.com/watch?v=2oafQVI4Lx4#t=706)
 
That should clarify it pretty much :)
 
-- Alex

 
> From: alex.koeplin...@outlook.com
> To: monofo...@my2cents.co.uk; mono-devel-list@lists.ximian.com
> Date: Sat, 25 Oct 2014 21:52:59 +0200
> Subject: Re: [Mono-dev] Mono and vNext, What is microsoft supporting
> 
> Note: the following is based on discussions with David Fowler (one of the MS 
> devs) et.al. in JabbR and other places. I'm not part of MS/vNext team or 
> Xamarin, so I may be totally wrong :)
> 
>  
> 
> >> "CoreCLR is intended to be Windows-only too from what I've heard, as it 
> >> doesn't make much sense for Mono (you can already do side-by-side 
> >> deployment of Mono)."
> > Where have you seen this, do you have a link you can send? This is a major 
> > missing piece of the puzzle for me. I've been hoping that with vNext, 
> > applications would be truely cross platform, but it seems we are still very 
> > much reliant on Mono's class implementations.
> > I've read an article[1] that says the CoreCLR ("Cloud Optimized") is to be 
> > "Cross Platform". If that is the case, and there are no plans to make a 
> > linux compatible version and just use mono, they could easily say the same 
> > about the .NET 4.5 class libraries as they are available in mono.
> 
> 
> You should keep in mind that CoreCLR is just that - another runtime 
> implementation (they based this off of the old Silverlight runtime which was 
> side-by-side deployable). What they now put on top is the class libraries 
> distributed via NuGet, resulting in this self-contained experience. As I 
> said, it's just one of the options alongside .NET CLR and Mono CLR, like this 
> picture from your article shows: 
> http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-84-75-metablogapi/7356.image_5F00_70B63F1D.png
>  (the article never says the CoreCLR is cross-platform, just the vNext 
> application itself)
> 
> 
> > So either, when Microsoft refer to "Cross platform", they are only 
> > referring to applications that rely on no class libraries and only corlib 
> > (is that a thing can an application be purely reliant on no class 
> > libraries?). Alternatively, they are relying on Mono to create a CoreCLR (I 
> > wouldn't be surprised if they've ask for Xamarin's help in doing that).
> 
> 
> The end result should be that you can run your app on .NET, CoreCLR and Mono 
> and the app doesn't care. The problem with the web frameworks like MVC etc. 
> up until now was that they were tightly coupled to System.Web, which is not 
> open-source and very difficult to reimplement in Mono (and to be honest 
> likely also lagged behind because Xamarin's focus is on mobile). The new 
> vNext stacks don't rely on System.Web anymore and just use the basic class 
> libraries that are well implemented on Mono too (like corlib, System.Net etc. 
> as they're important to Xamarin). It should be a much much better experience 
> given that Microsoft actively tests the vNext stack on Mono. Now if **your** 
> application code relies on something that isn't implemented on Mono then 
> that's a problem, sure.
> 
> 
> > I am aware that you can side-by-side in mono, however, I thought that one 
> > of the other big benefits of vNext was the reduction in footprint, 
> > specifically around the memory footprint per request. So you can opt-in/out 
> > of specific features.
> 
> 
> Maybe they'll make this whole CoreCLR/small-footprint - experienc

Re: [Mono-dev] Mono and vNext, What is microsoft supporting

[Alexander Köplinger]

I just asked about CoreCLR on Linux during today's ASP.NET vNext community 
standup and the answer was:
"CoreCLR runs on Windows. On Linux you use Mono." 
(https://www.youtube.com/watch?v=2oafQVI4Lx4#t=706)
 
That should clarify it pretty much :)
 
-- Alex

 
> From: alex.koeplin...@outlook.com
> To: monofo...@my2cents.co.uk; mono-devel-list@lists.ximian.com
> Date: Sat, 25 Oct 2014 21:52:59 +0200
> Subject: Re: [Mono-dev] Mono and vNext, What is microsoft supporting
> 
> Note: the following is based on discussions with David Fowler (one of the MS 
> devs) et.al. in JabbR and other places. I'm not part of MS/vNext team or 
> Xamarin, so I may be totally wrong :)
> 
>  
> 
> >> "CoreCLR is intended to be Windows-only too from what I've heard, as it 
> >> doesn't make much sense for Mono (you can already do side-by-side 
> >> deployment of Mono)."
> > Where have you seen this, do you have a link you can send? This is a major 
> > missing piece of the puzzle for me. I've been hoping that with vNext, 
> > applications would be truely cross platform, but it seems we are still very 
> > much reliant on Mono's class implementations.
> > I've read an article[1] that says the CoreCLR ("Cloud Optimized") is to be 
> > "Cross Platform". If that is the case, and there are no plans to make a 
> > linux compatible version and just use mono, they could easily say the same 
> > about the .NET 4.5 class libraries as they are available in mono.
> 
> 
> You should keep in mind that CoreCLR is just that - another runtime 
> implementation (they based this off of the old Silverlight runtime which was 
> side-by-side deployable). What they now put on top is the class libraries 
> distributed via NuGet, resulting in this self-contained experience. As I 
> said, it's just one of the options alongside .NET CLR and Mono CLR, like this 
> picture from your article shows: 
> http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-84-75-metablogapi/7356.image_5F00_70B63F1D.png
>  (the article never says the CoreCLR is cross-platform, just the vNext 
> application itself)
> 
> 
> > So either, when Microsoft refer to "Cross platform", they are only 
> > referring to applications that rely on no class libraries and only corlib 
> > (is that a thing can an application be purely reliant on no class 
> > libraries?). Alternatively, they are relying on Mono to create a CoreCLR (I 
> > wouldn't be surprised if they've ask for Xamarin's help in doing that).
> 
> 
> The end result should be that you can run your app on .NET, CoreCLR and Mono 
> and the app doesn't care. The problem with the web frameworks like MVC etc. 
> up until now was that they were tightly coupled to System.Web, which is not 
> open-source and very difficult to reimplement in Mono (and to be honest 
> likely also lagged behind because Xamarin's focus is on mobile). The new 
> vNext stacks don't rely on System.Web anymore and just use the basic class 
> libraries that are well implemented on Mono too (like corlib, System.Net etc. 
> as they're important to Xamarin). It should be a much much better experience 
> given that Microsoft actively tests the vNext stack on Mono. Now if **your** 
> application code relies on something that isn't implemented on Mono then 
> that's a problem, sure.
> 
> 
> > I am aware that you can side-by-side in mono, however, I thought that one 
> > of the other big benefits of vNext was the reduction in footprint, 
> > specifically around the memory footprint per request. So you can opt-in/out 
> > of specific features.
> 
> 
> Maybe they'll make this whole CoreCLR/small-footprint - experience available 
> on other OSs as well, but from what I've heard this is targeted at Windows 
> for now.
> 
> 
> -- 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