Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

[Alex Rønne Petersen]

Hi,

Like this:

adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"

(with all of the quotes)

Yes, runtime/JIT section. Thanks!

Regards,
Alex

On Thu, Jul 7, 2016 at 11:20 AM, Petros Douvantzis <petrak...@gmail.com> wrote:
> I ran:
> adb shell setprop debug.mono.env "-O=-intrins"
>
> Is this correct?
>
> There was no difference in the outcome: When volatile keyword is used,
> errors occur. When Volatile class is used, no errors were spotted.
>
> Should I file a bug to the Runtime/JIT section?
>
> Where
>
> On Thu, Jul 7, 2016 at 11:32 AM, Alex Rønne Petersen <a...@alexrp.com>
> wrote:
>>
>> Hi,
>>
>> By the way, I would suggest trying to run the app with something like:
>>
>> MONO_ENV_OPTIONS="-O=-intrins"
>>
>> For Android, see here how to set this:
>> https://developer.xamarin.com/guides/android/advanced_topics/environment/
>>
>> For iOS, you'd need to set this when invoking the AOT compiler. I'm
>> not really familiar with where you'd need to do this, though.
>>
>> This would disable the JIT's intrinsics for the various atomics /
>> memory model methods in the framework. It would be good to know if
>> this makes the test case work or if the result is the same, as we
>> could narrow the problem down to either the JIT's intrinsics or the
>> fallback C code in the runtime.
>>
>> Regards,
>> Alex
>>
>> On Wed, Jul 6, 2016 at 5:13 PM, petrakeas <petrak...@gmail.com> wrote:
>> > According to C#  specification
>> > <https://msdn.microsoft.com/en-us/library/ms228593.aspx>  :
>> >
>> > •   A read of a volatile field is called a volatile read. A volatile
>> > read has
>> > “acquire semantics”; that is, it is guaranteed to occur prior to any
>> > references to memory that occur after it in the instruction sequence.
>> > •   A write of a volatile field is called a volatile write. A
>> > volatile write
>> > has “release semantics”; that is, it is guaranteed to happen after any
>> > memory references prior to the write instruction in the instruction
>> > sequence.
>> >
>> > The spec presents  an example
>> > <https://msdn.microsoft.com/en-us/library/aa645755(v=vs.71).aspx>
>> > where
>> > one thread writes "data" on a non volatile variable and "publishes" the
>> > result by writing on a volatile variable that acts as a flag. The other
>> > thread checks the volatile flag and if set, it accesses the non-volatile
>> > variable that is now *guaranteed* to contain the data.
>> >
>> > It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
>> > semantics or in other words does not prevent memory re-ordering in
>> > Android
>> > and iOS that have relaxed memory models due to their CPU.
>> >
>> > I have created an a test that reproduces the problem in iOS and Android
>> > Program.cs <http://mono.1490590.n4.nabble.com/file/n4668111/Program.cs>
>> > .
>> >
>> > If the access to the volatile field is replaced by Volatile.Read() and
>> > Volatile.Write(), then no-problems occur. It seems that Volatile.Read()
>> > and
>> > Volatile.Write() implement half fences in Mono, but the volatile keyword
>> > does not.
>> >
>> > Is this a bug?
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> > http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.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
>
>
>
>
> --
>
> Petros Douvantzis
>
> Co-founder
>
> Horizon Video Technologies
>
> horizon.camera
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

[Alex Rønne Petersen]

Hi,

By the way, I would suggest trying to run the app with something like:

MONO_ENV_OPTIONS="-O=-intrins"

For Android, see here how to set this:
https://developer.xamarin.com/guides/android/advanced_topics/environment/

For iOS, you'd need to set this when invoking the AOT compiler. I'm
not really familiar with where you'd need to do this, though.

This would disable the JIT's intrinsics for the various atomics /
memory model methods in the framework. It would be good to know if
this makes the test case work or if the result is the same, as we
could narrow the problem down to either the JIT's intrinsics or the
fallback C code in the runtime.

Regards,
Alex

On Wed, Jul 6, 2016 at 5:13 PM, petrakeas <petrak...@gmail.com> wrote:
> According to C#  specification
> <https://msdn.microsoft.com/en-us/library/ms228593.aspx>  :
>
> •   A read of a volatile field is called a volatile read. A volatile read 
> has
> “acquire semantics”; that is, it is guaranteed to occur prior to any
> references to memory that occur after it in the instruction sequence.
> •   A write of a volatile field is called a volatile write. A volatile 
> write
> has “release semantics”; that is, it is guaranteed to happen after any
> memory references prior to the write instruction in the instruction
> sequence.
>
> The spec presents  an example
> <https://msdn.microsoft.com/en-us/library/aa645755(v=vs.71).aspx>   where
> one thread writes "data" on a non volatile variable and "publishes" the
> result by writing on a volatile variable that acts as a flag. The other
> thread checks the volatile flag and if set, it accesses the non-volatile
> variable that is now *guaranteed* to contain the data.
>
> It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
> semantics or in other words does not prevent memory re-ordering in Android
> and iOS that have relaxed memory models due to their CPU.
>
> I have created an a test that reproduces the problem in iOS and Android
> Program.cs <http://mono.1490590.n4.nabble.com/file/n4668111/Program.cs>  .
>
> If the access to the volatile field is replaced by Volatile.Read() and
> Volatile.Write(), then no-problems occur. It seems that Volatile.Read() and
> Volatile.Write() implement half fences in Mono, but the volatile keyword
> does not.
>
> Is this a bug?
>
>
>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.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] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

[Alex Rønne Petersen]

Hi,

Please file it for the Mono runtime, rather, as the vast majority of
our memory model related code lives in the runtime/JIT.

Regards,
Alex

On Thu, Jul 7, 2016 at 10:27 AM, Petros Douvantzis <petrak...@gmail.com> wrote:
> Hi,
>
> I will file a bug.
>
> I think that I should file one bug int the iOS BCL libraries and one for the
> Android BCL, right? I guess the solution will be related to one another
> though.
>
> Best,
>
> On Thu, Jul 7, 2016 at 11:20 AM, Alex Rønne Petersen <a...@alexrp.com>
> wrote:
>>
>> Hi,
>>
>> It is correct that the volatile keyword should result in
>> acquire/release barriers as a result of compiling down to
>> Thread.VolatileRead () / VolatileWrite () calls. In theory, the only
>> difference between the Thread and Volatile methods is that the
>> Volatile methods will actually be atomic for 64-bit quantities on a
>> 32-bit machine, where the Thread methods will not (incidentally, this
>> is why the volatile keyword is not allowed on 64-bit types). But since
>> you're using a 32-bit value, this shouldn't matter. So the fact that
>> switching the code to the Volatile methods makes it work is very
>> strange indeed.
>>
>> Could you file a bug with the test case you provided?
>>
>> Regards,
>> Alex
>>
>> On Wed, Jul 6, 2016 at 5:13 PM, petrakeas <petrak...@gmail.com> wrote:
>> > According to C#  specification
>> > <https://msdn.microsoft.com/en-us/library/ms228593.aspx>  :
>> >
>> > •   A read of a volatile field is called a volatile read. A volatile
>> > read has
>> > “acquire semantics”; that is, it is guaranteed to occur prior to any
>> > references to memory that occur after it in the instruction sequence.
>> > •   A write of a volatile field is called a volatile write. A
>> > volatile write
>> > has “release semantics”; that is, it is guaranteed to happen after any
>> > memory references prior to the write instruction in the instruction
>> > sequence.
>> >
>> > The spec presents  an example
>> > <https://msdn.microsoft.com/en-us/library/aa645755(v=vs.71).aspx>
>> > where
>> > one thread writes "data" on a non volatile variable and "publishes" the
>> > result by writing on a volatile variable that acts as a flag. The other
>> > thread checks the volatile flag and if set, it accesses the non-volatile
>> > variable that is now *guaranteed* to contain the data.
>> >
>> > It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
>> > semantics or in other words does not prevent memory re-ordering in
>> > Android
>> > and iOS that have relaxed memory models due to their CPU.
>> >
>> > I have created an a test that reproduces the problem in iOS and Android
>> > Program.cs <http://mono.1490590.n4.nabble.com/file/n4668111/Program.cs>
>> > .
>> >
>> > If the access to the volatile field is replaced by Volatile.Read() and
>> > Volatile.Write(), then no-problems occur. It seems that Volatile.Read()
>> > and
>> > Volatile.Write() implement half fences in Mono, but the volatile keyword
>> > does not.
>> >
>> > Is this a bug?
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> > http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.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
>
>
>
>
> --
>
> Petros Douvantzis
>
> Co-founder
>
> Horizon Video Technologies
>
> horizon.camera
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

[Alex Rønne Petersen]

Hi,

It is correct that the volatile keyword should result in
acquire/release barriers as a result of compiling down to
Thread.VolatileRead () / VolatileWrite () calls. In theory, the only
difference between the Thread and Volatile methods is that the
Volatile methods will actually be atomic for 64-bit quantities on a
32-bit machine, where the Thread methods will not (incidentally, this
is why the volatile keyword is not allowed on 64-bit types). But since
you're using a 32-bit value, this shouldn't matter. So the fact that
switching the code to the Volatile methods makes it work is very
strange indeed.

Could you file a bug with the test case you provided?

Regards,
Alex

On Wed, Jul 6, 2016 at 5:13 PM, petrakeas <petrak...@gmail.com> wrote:
> According to C#  specification
> <https://msdn.microsoft.com/en-us/library/ms228593.aspx>  :
>
> •   A read of a volatile field is called a volatile read. A volatile read 
> has
> “acquire semantics”; that is, it is guaranteed to occur prior to any
> references to memory that occur after it in the instruction sequence.
> •   A write of a volatile field is called a volatile write. A volatile 
> write
> has “release semantics”; that is, it is guaranteed to happen after any
> memory references prior to the write instruction in the instruction
> sequence.
>
> The spec presents  an example
> <https://msdn.microsoft.com/en-us/library/aa645755(v=vs.71).aspx>   where
> one thread writes "data" on a non volatile variable and "publishes" the
> result by writing on a volatile variable that acts as a flag. The other
> thread checks the volatile flag and if set, it accesses the non-volatile
> variable that is now *guaranteed* to contain the data.
>
> It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
> semantics or in other words does not prevent memory re-ordering in Android
> and iOS that have relaxed memory models due to their CPU.
>
> I have created an a test that reproduces the problem in iOS and Android
> Program.cs <http://mono.1490590.n4.nabble.com/file/n4668111/Program.cs>  .
>
> If the access to the volatile field is replaced by Volatile.Read() and
> Volatile.Write(), then no-problems occur. It seems that Volatile.Read() and
> Volatile.Write() implement half fences in Mono, but the volatile keyword
> does not.
>
> Is this a bug?
>
>
>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.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] Initialize mono on non main thread

[Alex Rønne Petersen]

Yes, this is definitely possible.

I would recommend that you look at the (now open source)
Xamarin.Android Mono glue code:
https://github.com/xamarin/xamarin-android/tree/master/src/monodroid/jni

Regards,
Alex

On Thu, Jun 9, 2016 at 4:10 PM, nicob <nicolasbo...@gmail.com> wrote:
> Hi, I'm initializing Mono using Java JNI. The JNI code doesn't run on the
> main thread, therefore I get segmentation faults. I've tried
> mono_thread_attach (mono_domain_get_root_domain and mono_domain_get) but
> that's the place where the SIGSEGV is generated.
>
> Can Mono be initialized on a non main thread? As I'm using JNI I've
> implemented the signal chaining to avoid segmentation faults.
>
> My code runs perfectly if you have only one thread, otherwise it fails with
> a SIGSEGV.
>
> Thanks!
>
>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/Initialize-mono-on-non-main-thread-tp4667956.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] Profiler: ThreadStart/ThreadEnd

[Alex Rønne Petersen]

Yes, this is guaranteed. We make the same assumption in Mono's own log
profiler to do cleanup.

Regards,
Alex

On Sun, May 29, 2016 at 3:28 PM, Greg Young <gregoryyou...@gmail.com> wrote:
> From running and testing it seems that Start/End are called on the
> thread in question. Can I assume this to be the case in the future?
> Basically I have some thread clean up work I would like to do in
> ThreadEnd and would prefer to just be able to do it here. Are there
> some situations where ThreadStart/ThreadEnd might be called on from a
> thread that is not the target thread?
> --
> 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] PPC_64K_PAGES (Re: Running Mono on 32bits-big endian PowerPC)

[Alex Rønne Petersen]

Yep, it's certainly not ideal; run-time detection would be, and I
think it should be possible to change SGen to do that. But I wouldn't
mind applying that change to Mono if it helps Debian's builds. It
seems like a reasonable enough workaround in the meantime.

On Mon, Apr 11, 2016 at 10:46 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> Actually... that should work. Maybe this will put some more stress on
> some small systems (small memory size).
>
> On Mon, Apr 11, 2016 at 10:32 AM, Alex Rønne Petersen <a...@alexrp.com> wrote:
>> Hi Mathieu,
>>
>> So it would be appropriate to change the #if to
>>
>> #if defined (TARGET_POWERPC) || defined (TARGET_POWERPC64)
>>
>> if I understand the problem correctly?
>>
>> Regards,
>> Alex
>>
>> On Mon, Apr 11, 2016 at 10:18 AM, Mathieu Malaterre <ma...@debian.org> wrote:
>>> # set patch tag at least to get some attention, may need some tweaking
>>> # since pagesize on buildd machine != user installed one
>>> Control: tags -1 patch
>>>
>>> On Thu, Mar 31, 2016 at 2:37 PM, Mathieu Malaterre <ma...@debian.org> wrote:
>>>> Dear all,
>>>>
>>>> I am currently trying to resurrect Mono debian package on PowerPC (32bits 
>>>> BE).
>>>>
>>>> I have two questions:
>>>>
>>>> - Is there a released version I should consider to start with if I
>>>> want to make mono work son PowerPC again ?
>>>>
>>>> - I see some big changes here at:
>>>> 99902cec93dfbc9e18e3fb6fa07b8770a3bd9adc so I am wondering if version
>>>> 4.2.1.102 (current debian package) is not a bit too old so get things
>>>> back in shape.
>>>
>>> Answering my own post.
>>>
>>> So the bug was really within sgen implementation details:
>>> ARCH_MIN_MS_BLOCK* definitions.
>>>
>>> Within debian infrstratucture, our buildd machines are setup using
>>> default debian kernel, and the default kernel logical page size was
>>> changed recently:
>>>
>>> [debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.]
>>> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=aed63a56b189d771116f2d4b8fe10bbec528e6a2
>>>
>>> The ppc32 buildd machine is setup on a ppc64 kernel. For some obscure
>>> details (at least to me), one cannot run a debian ppc32 kernel on
>>> ppc64 arch. Which means that the basic `mono` compiler is compiled
>>> using ppc32 user space, but at C# compile time is executed on ppc64
>>> kernel.
>>>
>>> I am guessing another simple patch would be to run the bootstrap
>>> process with gc=none and keep the default sgen 4K setting for ppc32
>>> machine.
>>>
>>> It would be nice that mono detect any incoherence at runtime, this
>>> would make tracking this bug in the future *so* much easier.
>>>
>>> -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] PPC_64K_PAGES (Re: Running Mono on 32bits-big endian PowerPC)

[Alex Rønne Petersen]

Hi Mathieu,

So it would be appropriate to change the #if to

#if defined (TARGET_POWERPC) || defined (TARGET_POWERPC64)

if I understand the problem correctly?

Regards,
Alex

On Mon, Apr 11, 2016 at 10:18 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> # set patch tag at least to get some attention, may need some tweaking
> # since pagesize on buildd machine != user installed one
> Control: tags -1 patch
>
> On Thu, Mar 31, 2016 at 2:37 PM, Mathieu Malaterre <ma...@debian.org> wrote:
>> Dear all,
>>
>> I am currently trying to resurrect Mono debian package on PowerPC (32bits 
>> BE).
>>
>> I have two questions:
>>
>> - Is there a released version I should consider to start with if I
>> want to make mono work son PowerPC again ?
>>
>> - I see some big changes here at:
>> 99902cec93dfbc9e18e3fb6fa07b8770a3bd9adc so I am wondering if version
>> 4.2.1.102 (current debian package) is not a bit too old so get things
>> back in shape.
>
> Answering my own post.
>
> So the bug was really within sgen implementation details:
> ARCH_MIN_MS_BLOCK* definitions.
>
> Within debian infrstratucture, our buildd machines are setup using
> default debian kernel, and the default kernel logical page size was
> changed recently:
>
> [debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.]
> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=aed63a56b189d771116f2d4b8fe10bbec528e6a2
>
> The ppc32 buildd machine is setup on a ppc64 kernel. For some obscure
> details (at least to me), one cannot run a debian ppc32 kernel on
> ppc64 arch. Which means that the basic `mono` compiler is compiled
> using ppc32 user space, but at C# compile time is executed on ppc64
> kernel.
>
> I am guessing another simple patch would be to run the bootstrap
> process with gc=none and keep the default sgen 4K setting for ppc32
> machine.
>
> It would be nice that mono detect any incoherence at runtime, this
> would make tracking this bug in the future *so* much easier.
>
> -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] Could sgen works with pthread?

[Alex Rønne Petersen]

Hi,

I don't know about 4.2.1, but as far as I can tell, SGen should work
fine with pthreads TLS in master. You just need to make sure that you
either set with_tls=pthread in the relevant section in configure.ac,
or pass --with-tls=pthread to it.

Are you running into any specific issues?

Regards,
Alex

On Wed, Apr 6, 2016 at 5:05 AM, Pin Cheng <pch...@rocketsoftware.com> wrote:
> Hi All,
>
> I am porting mono into old aix host, my platform doesn’t support __thread
>
> Key word. I notice https://bugzilla.novell.com/show_bug.cgi?id=660413
>
> Described that mono doesn’t support sgen with pthread.
>
> I am using Mono 4.2.1, does this release overcome the limitation?
>
> I have research the source code it seems not. But I am not very sure.
>
>
>
> Thank you in advance.
>
> Pin
>
>
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451
> ■ +1 877.328.2932 ■ +1 781.577.4321
> Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
> Manage Your Subscription Preferences -
> http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
> Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential information
> of Rocket Software, Inc. All unauthorized use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please notify Rocket
> Software immediately and destroy all copies of this communication. Thank
> you.
>
>
> ___
> 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] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Alex J Lennon]

On 30/03/2016 12:32, Edward Ned Harvey (mono) wrote:
>> From: Chris Swiedler [mailto:cswied...@trionworlds.com]
>>
>> Why not just include references to Mono.Posix.dll in the Windows build? You
>> don't have to install the full framework.
> Then when you run it on mono, you're using the Mono.Posix.dll that you 
> packaged with your application, instead of using the one that's included in 
> the OS. Although it's arguable which way is better, because each way has pros 
> and cons, the OP specifically said he didn't want to do this (and I 
> personally agree).
>
> It's not difficult to write the abstraction factory, and it's the most 
> elegant solution. I will advocate for this because I've been burned in the 
> past by *not* doing it.
>

I think there was a thread from September 2015 that perhaps touched upon
these issues and use of factory methods? The code snippets in there
might possibly be of use:

http://lists.ximian.com/pipermail/mono-devel-list/2015-September/043234.html

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] Running --profiler=log:coverage

[Alex Rønne Petersen]

Hi,

The "time went backwards" message is harmless and has been removed in
later Mono versions.

Could you have a look at the crash, Iain? (cc)

On Thu, Mar 3, 2016 at 2:00 PM, Antoine Cailliau
 wrote:
> Hello,
>
> I'm trying to measure the code coverage of a test suite. I noticed that
> recently (Apr'15) cov and monocov were removed for log:coverage profiler.
>
> When I'm running that profile on my tests using nunit-console. I got a
> segmentation fault, see below. When using mprof-report, I do not get the
> section related to code coverage.
>
> What I use to run the tests :
> $ MONO_OPTIONS="--profile=log:coverage,covfilter=+MinePumpSystem.Test"
> nunit-console MinePumpSystem.Test.dll
>
> Plus, it is displaying "time went backwards" a lot.
>
> Anyone with any tips on how I could get this to work is welcome :-)
>
> Regards,
>
> Antoine
>
> -- The trace :
>
> tacktrace:
>
>
> Native stacktrace:
>
>
> Debug info from gdb:
>
> (lldb) command source -s 0 '/tmp/mono-gdb-commands.2cpqir'
> Executing commands in '/tmp/mono-gdb-commands.2cpqir'.
> (lldb) process attach --pid 47647
> warning: (i386)
> /Library/Frameworks/Mono.framework/Versions/4.2.2/lib/mono/4.5/mscorlib.dll.dylib
> empty dSYM file detected, dSYM was created with an executable with no debug
> info.
> Process 47647 stopped
> * thread #1: tid = 0x109c479, 0x92bb6d06 libsystem_kernel.dylib`__wait4 +
> 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
> frame #0: 0x92bb6d06 libsystem_kernel.dylib`__wait4 + 10
> libsystem_kernel.dylib`__wait4:
> ->  0x92bb6d06 <+10>: jae0x92bb6d16; <+26>
> 0x92bb6d08 <+12>: calll  0x92bb6d0d; <+17>
> 0x92bb6d0d <+17>: popl   %edx
> 0x92bb6d0e <+18>: movl   0x104be317(%edx), %edx
>
> Executable module set to
> "/Library/Frameworks/Mono.framework/Versions/4.2.2/bin/mono".
> Architecture set to: i386-apple-macosx.
> (lldb) thread list
> Process 47647 stopped
> * thread #1: tid = 0x109c479, 0x92bb6d06 libsystem_kernel.dylib`__wait4 +
> 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   thread #2: tid = 0x109c47a, 0x92bb6402
> libsystem_kernel.dylib`__psynch_cvwait + 10
>   thread #3: tid = 0x109c47b, 0x92baf886
> libsystem_kernel.dylib`semaphore_wait_trap + 10
>   thread #4: tid = 0x109c47c, 0x92bb6d76
> libsystem_kernel.dylib`__workq_kernreturn + 10
>   thread #5: tid = 0x109c47d, 0x92bb7812 libsystem_kernel.dylib`kevent_qos +
> 10, queue = 'com.apple.libdispatch-manager'
>   thread #6: tid = 0x109c47e, 0x0027008d mono`mono_hazard_pointer_get + 13
> at hazard-pointer.c:176
>   thread #7: tid = 0x109c482, 0x92bb6d76
> libsystem_kernel.dylib`__workq_kernreturn + 10
>   thread #8: tid = 0x109c484, 0x92bb6d76
> libsystem_kernel.dylib`__workq_kernreturn + 10
> (lldb) thread backtrace all
> mono was compiled with optimization - stepping may behave oddly; variables
> may not be available.
> * thread #1: tid = 0x109c479, 0x92bb6d06 libsystem_kernel.dylib`__wait4 +
> 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x92bb6d06 libsystem_kernel.dylib`__wait4 + 10
> frame #1: 0x969f07dc libsystem_c.dylib`waitpid$UNIX2003 + 48
> frame #2: 0x000d7f2d mono`mono_handle_native_sigsegv(signal=11,
> ctx=0x007abfe0, info=0x007abfa0) + 541 at mini-exceptions.c:2193 [opt]
> frame #3: 0x00124482
> mono`mono_arch_handle_altstack_exception(sigctx=,
> siginfo=, fault_addr=, stack_ovf=0) + 162 at
> exceptions-x86.c:1097 [opt]
> frame #4: 0x0002540e
> mono`mono_sigsegv_signal_handler(_dummy=, _info=,
> context=) + 446 at mini-runtime.c:2471 [opt]
> frame #5: 0x9aad301b libsystem_platform.dylib`_sigtramp + 43
> frame #6: 0x96973051 libsystem_c.dylib`strlen + 17
> frame #7: 0x00690b48
> libmono-profiler-log.0.dylib`build_assembly_buffer(key=0x79962860,
> value=0x79962860, userdata=) + 216 at proflog.c:3514 [opt]
> frame #8: 0x00277150
> mono`mono_conc_hashtable_foreach(hash_table=,
> func=, userdata=) + 80 at
> mono-conc-hashtable.c:365 [opt]
> frame #9: 0x0068520a libmono-profiler-log.0.dylib`log_shutdown [inlined]
> dump_coverage(prof=0x79960ba0) + 92 at proflog.c:3544 [opt]
> frame #10: 0x006851ae
> libmono-profiler-log.0.dylib`log_shutdown(prof=0x79960ba0) + 46 at
> proflog.c:3851 [opt]
> frame #11: 0x001b7262 mono`mono_profiler_shutdown + 50 at profiler.c:813
> [opt]
> frame #12: 0x0002861a mono`mini_cleanup(domain=0x79863ce0) + 778 at
> mini-runtime.c:3455 [opt]
> frame #13: 0x000a2f61 mono`mono_main(argc=,
> argv=) + 8001 at driver.c:2083 [opt]
> frame #14: 0x0001ab50 mono`main [inlined]
> mono_main_with_options(argc=, argv=) + 768 at
> main.c:94 [opt]
> frame #15: 0x0001a86d mono`main(argc=, argv=)
> + 29 at main.c:125 [opt]
> frame #16: 0x0001a845 mono`start + 53
>
>   thread #2: tid = 0x109c47a, 0x92bb6402
> libsystem_kernel.dylib`__psynch_cvwait + 10
> frame #0: 0x92bb6402 libsystem_kernel.dylib`__psynch_cvwait + 10
> frame 

Re: [Mono-dev] Unix Signal in mono

[Alex Rønne Petersen]

Hi,

In that case, you want the kill () function, which is also provided by
Mono.Posix.

Regards,
Alex

On Mon, Feb 29, 2016 at 2:18 PM, techi eth <techi...@gmail.com> wrote:
> Thanks for quick hint.
> We can receive signal by using signal handler using
> Mono.Unix.Native.Stdlib.signal.
> I am trying to check possibility of sending signal from one process to
> another.
>
> Example : If i have two process (P1 & P2) & P1 want to send SIGTERM to P2.
>
> On Mon, Feb 29, 2016 at 1:11 PM, Miguel de Icaza <mig...@xamarin.com> wrote:
>>
>> You call the "signal" API.
>>
>> Mono wraps that conveniently for you in the Mono.Posix assembly:
>>
>> Mono.Unix.Native.Stdlib.signal
>>
>>
>> Miguel
>>
>>
>> On Mon, Feb 29, 2016 at 7:45 AM, techi eth <techi...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> What is the way by which one process can send Unix Signal to another
>>> process.
>>>
>>> Thanks
>>>
>>> Techi
>>>
>>>
>>> ___
>>> 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] Issue running recent/latest Mono on PPC emulation target

[Alex Rønne Petersen]

Hi,

Could you please try with mono master? I believe this issue was fixed post-4.2.

Regards,
Alex

On Sun, Feb 14, 2016 at 5:41 PM, Alex J Lennon
<ajlen...@dynamicdevices.co.uk> wrote:
> Hi,
>
> I was recently contacted by somebody wishing to run mono on an embedded
> PPC board so have been doing some testing with meta-mono against Yocto
> Poky/Jethro on qemuppc.
>
> 4.0.1.34 builds and runs under emulation, successfully running three
> simple tests I created to check console, Windows Forms and GTK support.
>
> ref: https://github.com/DynamicDevices/mono-helloworld/tree/master/src
>
>
> 4.2.2.30 and 4.2.0.179 both build and successfully execute the console
> and GTK tests but the Windows Forms test fails with:
>
> unknown opcode atomic_add_i4 in mono_arch_output_basic_block()
> * Assertion: should not be reached at mini-ppc.c:4507
>
> The stack trace includes
>
>   at  <0x>
>   at
> System.Runtime.Serialization.Formatters.Binary.ReadObjectInfo.Create
> (System.Type,string[],System.Type[],System.Runtime.Serialization.ISurrogateSelector,System.Runtime.Serialization.StreamingContext,System.Runtime.Serialization.ObjectManager,System.Runtime.Serialization.Formatters.Binary.SerObjectInfoInit,System.Runtime.Serialization.IFormatterConverter,bool)
> <0x0005c>
> ...
>   at System.Windows.Forms.KeyboardLayouts.LoadLayouts () <0x000a4>
>
> Full trace is here:  http://pastebin.com/4bJ173Sa
>
> Can anybody advise?
>
> Thanks,
>
> 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] Issue running recent/latest Mono on PPC emulation target

[Alex J Lennon]

On 14/02/2016 18:32, Alex Rønne Petersen wrote:
> Hi,
>
> Could you please try with mono master? I believe this issue was fixed 
> post-4.2.
>

Will do, 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] Issue running recent/latest Mono on PPC emulation target

[Alex J Lennon]

On 14/02/2016 18:50, Alex J Lennon wrote:
>
> On 14/02/2016 18:32, Alex Rønne Petersen wrote:
>> Hi,
>>
>> Could you please try with mono master? I believe this issue was fixed 
>> post-4.2.
>>
> Will do, thanks Alex.

Thanks for the pointer Alex. That did the trick.

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

[Mono-dev] Issue running recent/latest Mono on PPC emulation target

[Alex J Lennon]

Hi,

I was recently contacted by somebody wishing to run mono on an embedded
PPC board so have been doing some testing with meta-mono against Yocto
Poky/Jethro on qemuppc.

4.0.1.34 builds and runs under emulation, successfully running three
simple tests I created to check console, Windows Forms and GTK support.

ref: https://github.com/DynamicDevices/mono-helloworld/tree/master/src


4.2.2.30 and 4.2.0.179 both build and successfully execute the console
and GTK tests but the Windows Forms test fails with:

unknown opcode atomic_add_i4 in mono_arch_output_basic_block()
* Assertion: should not be reached at mini-ppc.c:4507

The stack trace includes

  at  <0x>
  at
System.Runtime.Serialization.Formatters.Binary.ReadObjectInfo.Create
(System.Type,string[],System.Type[],System.Runtime.Serialization.ISurrogateSelector,System.Runtime.Serialization.StreamingContext,System.Runtime.Serialization.ObjectManager,System.Runtime.Serialization.Formatters.Binary.SerObjectInfoInit,System.Runtime.Serialization.IFormatterConverter,bool)
<0x0005c>
...
  at System.Windows.Forms.KeyboardLayouts.LoadLayouts () <0x000a4>

Full trace is here:  http://pastebin.com/4bJ173Sa

Can anybody advise?

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] Profiler on ARM

[Alex Rønne Petersen]

Hi,

Did you build Mono yourself? If so, did you remember to add /lib to LD_LIBRARY_PATH?

Regards,
Alex

On Tue, Feb 9, 2016 at 5:07 AM, techi eth <techi...@gmail.com> wrote:
> Hi,
>
> I am trying to run mono profiler on ARM target.I am always getting below
> error.
>
> "The 'log' profiler wasn't found in the main executable nor could it be
> loaded from 'mono-profiler-log'"
>
> Is that work on ARM target ?
> Do i need to use any build option to enable profiler ?
>
> Thanks
>
> ___
> 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] Profile with optimizations

[Alex Rønne Petersen]

What *might* work is calling mono_jit_parse_options () from your
mono_profiler_startup () callback. Something like:

mono_jit_parse_options (1, (char*[]) { "-O=-all" });

Replace `-all` with whatever you need. I think your callback should be
called late enough that this'll override user flags (if that's really
what you want to do).

Regards,
Alex

On Tue, Jan 12, 2016 at 12:09 PM, Greg Young <gregoryyou...@gmail.com> wrote:
> but can I disable this behaviour from inside of a profiler?
>
> On Tue, Jan 12, 2016 at 12:04 PM, Alex Rønne Petersen <a...@alexrp.com> wrote:
>> Well, here's a simple test: 
>> https://gist.github.com/alexrp/9d4ee5b488f9ee57c297
>>
>> If you run this with `MONO_VERBOSE_METHOD=Main mono --profile=log`,
>> you'll see: https://gist.github.com/alexrp/d90e73bfdd0469f5f6c0
>>
>> Looking at the DUMP BLOCK output, you can see that Add was inlined and
>> constant folded as expected.
>>
>> Regards,
>> Alex
>>
>> On Fri, Jan 8, 2016 at 10:02 PM, Greg Young <gregoryyou...@gmail.com> wrote:
>>> Hmm I have yet to see in any test runs the behaviour of optimizations
>>> like inlining enabled. I would assume a simple test case should
>>> produce it? If optimizations are enabled (and I can reproduce it) is
>>> there any way to disable them as a profiler?
>>>
>>> On Fri, Jan 8, 2016 at 8:47 PM, Alex Rønne Petersen <a...@alexrp.com> wrote:
>>>> Hey Greg,
>>>>
>>>> Do you have a test case that demonstrates what you're seeing? From
>>>> what I can see, the runtime should not be disabling optimizations just
>>>> because the profiler is attached. However, if you're running with
>>>> --debug or some such option, all optimizations will be off.
>>>>
>>>> Regards,
>>>> Alex
>>>>
>>>> On Fri, Jan 8, 2016 at 1:25 PM, Greg Young <gregoryyou...@gmail.com> wrote:
>>>>> It may be in the new profiling API changes that are there but I can't
>>>>> seem to find it in the older profiling api. Is there a way to enable
>>>>> JIT optimizations such as inlining and profile? It seems enabling
>>>>> profiler always disables optimizations.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Greg
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> Studying for the Turing test
>
>
>
> --
> 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

Re: [Mono-dev] Profile with optimizations

[Alex Rønne Petersen]

Hey Greg,

Do you have a test case that demonstrates what you're seeing? From
what I can see, the runtime should not be disabling optimizations just
because the profiler is attached. However, if you're running with
--debug or some such option, all optimizations will be off.

Regards,
Alex

On Fri, Jan 8, 2016 at 1:25 PM, Greg Young <gregoryyou...@gmail.com> wrote:
> It may be in the new profiling API changes that are there but I can't
> seem to find it in the older profiling api. Is there a way to enable
> JIT optimizations such as inlining and profile? It seems enabling
> profiler always disables optimizations.
>
> Cheers,
>
> Greg
>
> --
> 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] Profiler Loading Issues

[Alex Rønne Petersen]

IIRC we just use dlopen(3) to load the profiler. So as far as Mono is
concerned, the best you'll get is the dlerror(3) output. You might be
able to get more detailed information with tools like strace(1),
file(1), etc, though.

Regards,
Alex

On Mon, Nov 2, 2015 at 8:13 AM, Greg Young <gregoryyou...@gmail.com> wrote:
> Just in general. As an example if someone copies over a 64 bit build
> for a 32 bit installation.
>
> Or if someone has copied files into a bad location. Or if a profiler
> is just not being loaded for some unknown reason.
>
> Crashes have been pretty easy to debug so far.
>
> On Mon, Nov 2, 2015 at 7:51 AM, Alex Rønne Petersen <a...@alexrp.com> wrote:
>> Hi,
>>
>> Can you be a bit more specific about the issue? Is it a crash or something 
>> else?
>>
>> Regards,
>> Alex
>>
>> On Sun, Nov 1, 2015 at 12:41 PM, Greg Young <gregoryyou...@gmail.com> wrote:
>>> Is there any good way of debugging profiler loading issues?
>>>
>>> Greg
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: [Mono-dev] mono log profiler

[Alex Rønne Petersen]

Yes, certainly. A lot of work has gone into it lately. It should be
more reliable than ever.

Regards,
Alex

On Sun, Sep 13, 2015 at 1:18 AM, Greg Young <gregoryyou...@gmail.com> wrote:
> Is this supposed to be considered as working code at this point?
> https://github.com/mono/mono/blob/master/mono/profiler/proflog.c
>
> --
> 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] mono log profiler

[Alex Rønne Petersen]

Mono 3.x is missing many of the profiler improvements that have been
made lately. I'd strongly advise upgrading to the latest 4.x if you
plan to use it.

Which assumptions?

Regards,
Alex

On Tue, Sep 15, 2015 at 5:38 PM, Greg Young <gregoryyou...@gmail.com> wrote:
> Thanks for the update I will check out the recent changes. I have been
> looking at 3.12.0 and have found some issues. Mostly I was curious if
> I could rely on many of the assumptions that are being made in it.
>
> Cheers,
>
> Greg
>
> On Tue, Sep 15, 2015 at 6:37 PM, Alex Rønne Petersen <a...@alexrp.com> wrote:
>> Yes, certainly. A lot of work has gone into it lately. It should be
>> more reliable than ever.
>>
>> Regards,
>> Alex
>>
>> On Sun, Sep 13, 2015 at 1:18 AM, Greg Young <gregoryyou...@gmail.com> wrote:
>>> Is this supposed to be considered as working code at this point?
>>> https://github.com/mono/mono/blob/master/mono/profiler/proflog.c
>>>
>>> --
>>> 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
>
>
>
> --
> 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

Re: [Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Alex J Lennon]

ler SignalHandler
{
get { return _signalHandler;  }
}

public ISecurityHandler SecurityHandler
{
get { return _securityHandler; }
}

public ISystemInfo SystemInfo
{
get { return _systemInfo; }
}
}

...

using System;
using System.Threading;
using SensorNetGateway.Core;

using Mono.Unix;
using Mono.Unix.Native;

namespace MyApp.BSP.Mono
{
class MonoSignalHandler : ISignalHandler
{
...

private void Worker()
{
_workerIsRunning = true;

var signalHUP = new UnixSignal(Signum.SIGHUP);
var signalTERM = new UnixSignal(Signum.SIGTERM);
    ...



It works well for me, although as the platform specific DLL references
are decoupled through
use of Activator you do have to make sure you add a reference to the
main project so your needed DLLS
are copied out to the build folder.

Hope that is of some interest.

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] Class built by mono throws FileNotFoundException when run on windows

[Alex J Lennon]

On 02/09/2015 16:32, Edward Ned Harvey (mono) wrote:
> I like the advice I'm getting from Alex and Robert.
>
> Alex, you said you're using
>   Path.Combine(Directory.GetCurrentDirectory(), "foobar.dll")
>
> When I look around, it seems like this might be more reliable?
>   Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "foobar.dll")

Glad it was of some use. Interesting point. Yes what you suggest seems
more correct for the .NET Framework, as the current directory may of
course change.

This is probably a result of me spending too much time over the years
with .NET Compact Framework / Windows CE which as I recall doesn't have
AppDomain.CurrentDomain BaseDirectory. Nevertheless it might be better
for me to grab the base location of the entry executable or something...
Thanks!

> I'm doing pretty well now, but not done yet - I have a base factory class, in 
> a factory assembly, that returns instances of derivative classes from 
> specific assemblies at runtime. The new question is: My main project only 
> needs to reference the factory assembly, and in fact the derivative 
> assemblies must also reference the factory assembly, because they derive from 
> the factory assembly. So by default, the derivative assemblies dll files 
> don't get copied to the build dir of the main project. I cannot reference the 
> derivative assemblies from the factory assembly, because of circular 
> reference. But I can reference the derivative assemblies from the main 
> project, which seems to have the effect of copying their DLL's to the build 
> dir, as desired.
>
> So is it safe for me to reference the derivative assemblies from the main 
> project, even though the main project doesn't actually use anything from 
> those assemblies? Or is it possible that the JIT compiler or something will 
> someday be aggressive and cause crashing? (I think it's good - just want 
> sanity check).

That's pretty much what I do.

fwiw I tend to have a MyApp.Core assembly with a bunch of interface
definitions and helpers in, then have console and/or UI projects
depending on that Core project and the BSP layers also depending on
Core, so I avoid circularity. Then console or UI projects reference Core
to build and I manually add in references to the output executable
projects to reference the BSP projects. This works for deployment even
though as you say the toolchain isn't aware of the dynamic loading
dependencies on the BSP projects.

> And is this a reliable way of getting the dll's to the target directory? Or 
> will the compiler/linker/whatever sometimes exclude those dll's from the 
> build process, because they're referenced but never used? (Again, I think 
> it's good - just want sanity check).

Never seen it happen..  (but who knows...) The other thing I've had to
do sometimes when pushed, and it eliminates any potential compile/link
oddities, is to set library files into the main project as content to be
copied across, although less than ideal. Had to do this with SQLite
libraries for some reason that now escapes me.

Cheers,

Alex

ssarily represent those of the company.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] 4.2.0.179 issue vs 4.0.4.1

[Alex J Lennon]

On 28/08/2015 02:45, Rodrigo Kumpera wrote:
 Fix is already fixed in the 4.2 branch:
 https://github.com/mono/mono/commit/f4de38878981140f12c53d1f1ab5ce46f5c475a3

Thanks Rodridgo. I'll wait for the next release then.

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

[Mono-dev] 4.2.0.179 issue vs 4.0.4.1

[Alex J Lennon]

Hi,

I was adding Yocto/OE meta-mono support for the 4.2.0.179 release.

The 4.0.4.1 release on 26th builds fine for me for a qemux86 target but
I'm getting the following error for 4.2.0.179 today:

| ../../doltlibtool  --tag=CC   --mode=compile i586-poky-linux-gcc  -m32
-march=i586
--sysroot=/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/sysroots/qemux86
-DHAVE_CONFIG_H -I. -I../..  -I../../libgc/include -DGC_LINUX_THREADS
-D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
-Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
-Wno-attributes -D_FILE_OFFSET_BITS=64 -DUSE_COMPILER_TLS -I../..
-I../../eglib/src -I../../eglib/src-fvisibility=hidden -O2 -pipe -g
-feliminate-unused-debug-types -std=gnu99 -fno-strict-aliasing -fwrapv
-DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
-Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
-Wno-attributes -mno-tls-direct-seg-refs
-Werror-implicit-function-declaration -c -o
libmini_static_la-branch-opts.lo `test -f 'branch-opts.c' || echo
'./'`branch-opts.c
| mini-x86.c: In function 'mono_arch_emit_epilog':
| mini-x86.c:5468:23: error: #if with no expression
|  #if MONO_HAVE_FAST_TLS
|^

Can anybody give me a bit of direction on whether this is a
misconfiguration on my part or something new that's needed?

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] condition `class' not met

[Alex J Lennon]

On 29/07/2015 08:43, Daniel Kuhne wrote:
  fwiw. You will likely need to ensure that your build of 'mono-native'
  and 'mono' recipes are both in sync.

 That solved the issue!

Great! Thanks for letting me know. You prompted me to look at the git
support last night as I've been concentrating on other things, like
tracking the Mono releases and refactoring.

There were some problems with the git support, which hopefully I've
addressed in recent commits. Would appreciate any feedback you have on
whether those fixes work for you.

(If you do have comments it might be best to come back via the the Yocto
list so we don't upset the good people here ;)

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] condition `class' not met

[Alex J Lennon]

On 28/07/2015 17:59, Zoltan Varga wrote:
 Hi,

   It is a transient failure when using a mismatching mono runtime and
 mscorlib.dll. Make sure you are using the latest version of both.

  Zoltan

fwiw. You will likely need to ensure that your build of 'mono-native'
and 'mono' recipes are both in sync.

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

[Mono-list] Timeout failure running Mono 4.0.3.19

[Alex J Lennon]

Hi,

I'm running 'make check' on Mono 4.0.3.19, building natively on Ubuntu
14.04.2 using meta-mono. (The Mono build itself is fine)

I get to Running tests: then a couple of F's as the dots progress,
then the test hangs for a while and I get the following.

---

Running tests:
.F..F.

running tests timed out:

430
threadpool-exceptions5.exe
=== threadpool-exceptions5.exe.stdout ===

=== EOF ===
=== threadpool-exceptions5.exe.stderr ===

=== EOF ===

---

The stdout and stderr files are empty.

Can anybody advise why this is occurring - i.e. I understand the test is
failing but it looks like the test runner is failing too instead of just
giving an 'F' and continuing - or where I need to look to address it?

Thanks,

Alex
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Timeout failure running Mono 4.0.3.19

[Alex J Lennon]

On 27/07/2015 16:50, Alex J Lennon wrote:
 Hi,

 I'm running 'make check' on Mono 4.0.3.19, building natively on Ubuntu
 14.04.2 using meta-mono. (The Mono build itself is fine)

 I get to Running tests: then a couple of F's as the dots progress,
 then the test hangs for a while and I get the following.

 ---

 Running tests:
 .F..F.

 running tests timed out:

 430
 threadpool-exceptions5.exe
 === threadpool-exceptions5.exe.stdout ===

 === EOF ===
 === threadpool-exceptions5.exe.stderr ===

 === EOF ===

 ---

 The stdout and stderr files are empty.

 Can anybody advise why this is occurring - i.e. I understand the test is
 failing but it looks like the test runner is failing too instead of just
 giving an 'F' and continuing - or where I need to look to address it?


I think I can see how the problem is arising. The threadpool-exceptions5
test is blocking when the environment variable LC_ALL=C.

This is because calling ToString() on the passed exception object in
OnUnhandledException() results in the instantiation of a default
CultureInfo which in turn then tries to retrieve the locale with
get_posix_locale()

get_posix_locale() returns a null when the LC_ALL=C so
CultureInfo::CreateSpecificCulture throws an ArgumentNullException which
is caught in CultureInfo::ConstructCurrentCulture

Unfortunately even though the exception is caught internally it causes a
problem in call_unhandled_exception_delegate in metadata/object.c
resulting in display of exception inside UnhandledException handler:
and the code blocking

...

A workaround is to instantiate the default CultureInfo  early on in main
so that the ArgumentNullException does not occur in the
UnhandledException handler.

e.g.

   static int Main ()
{
  var c = CultureInfo.InstalledUICulture;
  ...

However this seems a bad solution as it doesn't address the underlying
problem that a caught exception ocurring somewhere within a
OnUnhandledException() code-path causes blocking.

I would have thought that a caught exception should not trigger that
codepath in object.c so it looks to me as though there may be something
in the call_unhandled_exception_delegate code in object.c that might
need to be addressed? I would also have thought that when this code-path
does execute we should eventually drop out of Mono not hang.

Regards,

Alex
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Issue building 4.0.2.4 on F22

[Alex J Lennon]

Chris,

On 24/06/2015 18:54, Chris Morgan wrote:
 Hello.

 I'm building mono here on F22 under Yocto and seeing errors about
 multiple files being installed with the same name. I'm not seeing
 these under F21.

 I haven't tried this with the actual mono release natively so there is
 some possibility that the yocto recipe is doing something bad to the
 mono build, however things do build under F21 with the same recipes.


Chris, is this still an issue or did you find a resolution?

Thanks, Alex
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Building 4.0.1.34 release (Mono-devel-list Digest, Vol 121, Issue 11)

[Alex J Lennon]

On 16/05/2015 14:23, Jo Shields wrote:


 On 16/05/15 12:55, Alex J Lennon wrote:

 On 16/05/2015 13:14, Alex J Lennon wrote:
 Hi,

 Building the 4.0.1.34 release is erroring on the install step

   /usr/bin/install: cannot stat
 'targets/Microsoft.Portable.VisualBasic_4.0.targets': No such file or
 directory


 It seems these two target files are missing from the 4.0.1.34 release
 tarball

 https://github.com/mono/mono/blob/master/mcs/tools/xbuild/targets/Microsoft.Portable.VisualBasic_4.0.targets

 https://github.com/mono/mono/blob/master/mcs/tools/xbuild/targets/Microsoft.Portable.VisualBasic_4.5.targets


 Yep, this is definitely the case.
 https://github.com/mono/linux-packaging-mono/blob/master/debian/patches/add_missing_vb_portable_targets.patch

Thanks Jo.

Has the Mono release process changed as I'm seeing four digits in
versioning now and they seem to be appearing more frequently e.g.
4.0.1.28, 4.0.1.34.

Is this an interim thing as you transition to the 4.x.x series or are
releases likely to be more frequent / more informal?

Thanks, Alex


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



-- 

Dynamic Devices Ltd http://www.dynamicdevices.co.uk/

Alex J Lennon / Director
24 Rue de l'Abbé de l'Épée, Chateau Double - Les Oliviers, 13090
Aix-En-Provence, France

mobile: +44 (0)7478 346120 landline: +44 (0)1513 241374

Linkedin http://www.linkedin.com/in/alexjlennon Skype
skype:alexjlennon?add

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.

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

Re: [Mono-dev] Building 4.0.1.34 release (Mono-devel-list Digest, Vol 121, Issue 11)

[Alex J Lennon]

On 16/05/2015 17:01, Jo Shields wrote:
 We use a 4-part versioning scheme internally, for our Mac builds - our
 build system increments every time a new commit happens on a branch
 after configure.ac has been bumped to a new 3-part version. Some (but
 not all) of our builds go to our customers' Alpha channel after being
 QA'd, then some of those are promoted to beta, then later to stable.

 I'm working on automating our procedures so that *every* product
 release gets a corresponding Open Source release, and 4.0.1.28 and
 4.0.1.34 are the first examples of this - alpha channel releases that
 have happened since  started work on this procedure. As time goes by,
 I'll make sure the website gets automatically updated too, so it'll be
 clear which 4-part versions should be considered stable

Great. Thanks for explaining Jo :)
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Building 4.0.1.34 release

[Alex J Lennon]

On 16/05/2015 13:14, Alex J Lennon wrote:
 Hi,

 Building the 4.0.1.34 release is erroring on the install step

  /usr/bin/install: cannot stat
 'targets/Microsoft.Portable.VisualBasic_4.0.targets': No such file or
 directory



It seems these two target files are missing from the 4.0.1.34 release
tarball

https://github.com/mono/mono/blob/master/mcs/tools/xbuild/targets/Microsoft.Portable.VisualBasic_4.0.targets
https://github.com/mono/mono/blob/master/mcs/tools/xbuild/targets/Microsoft.Portable.VisualBasic_4.5.targets

With these added it builds.

Regards, Alex

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

[Mono-dev] Building 4.0.1.34 release

[Alex J Lennon]

Hi,

Building the 4.0.1.34 release is erroring on the install step

 /usr/bin/install: cannot stat
'targets/Microsoft.Portable.VisualBasic_4.0.targets': No such file or
directory


Is this to be expected?

Thanks,

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

Re: [Mono-list] just installed mono, most basic test failed.

[Alex J Lennon]

Hi Edward, all,

On 11/05/2015 15:51, Edward Ned Harvey (mono) wrote:
 From: cov...@ccs.covici.com [mailto:cov...@ccs.covici.com]

 Why not use vs 2015 and vs code, supposed to work on Windows, OSX or
 Linux, although I don't know what versions of OSX they are supporting.
 I wonder how long mono is for this world?
 Is that just a blatant troll? Even with .Net being open source, you cannot 
 ever expect it to simply compile straight up, on a non-windows platform. Lots 
 of changes are required under the hood to implement things like file and 
 socket operations, which are fundamentally based on different underlying 
 technologies. You should not expect such an effort to ever be done - because 
 it's already been done in mono, and there's no motivation for anyone to 
 repeat all that work in a separate project.


Putting to one side the criticism of Mono, I was looking at some CoreCLR
info the other day and it does look like build on Linux is well on the
way? It also looks as though they plan to have ARM support in there at
some point?

https://github.com/dotnet/coreclr/wiki/Developer-Guide

Cheers, Alex
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Porting Mono to 'asm.js'

[Alex J Lennon]

Sounds interesting. It's the type of thing I'd like to add into
meta-mono for Yocto/Mono based embedded platforms.

On 17/03/2015 06:09, Bob Summerwill wrote:
 No problem!   I think that HTML5-as-a-platform would be a great idea,
 however it comes about.

 Joao would be the best person to answer your questions, I think,
 because I'm not associated with Xamarin or GSoC.   I'm just interested
 in this area of technology.


 Cheers,
 Bob


 Chee

 On Mon, Mar 16, 2015 at 8:25 PM, Nirmal Lankathilaka
 nir3al+...@gmail.com mailto:nir3al+...@gmail.com wrote:

 Thanks Bob for the awesome links and the CC!! I too, would love to
 see that potential achieved.

 I've been doing some reading about porting to asm.js. Is there
 anything you'd suggest that I should read/experiment on? Also, is
 there any idea/suggestions you have in mind about how I should
 continue to work on this project and what I should do (in the
 context of GSoC)?

 On Mon, Mar 16, 2015 at 10:49 PM, Bob Summerwill
 b...@summerwill.net mailto:b...@summerwill.net wrote:


 Corrected link - http://monohtml5.com - sorry.



 On Mon, Mar 16, 2015 at 10:18 AM, Bob Summerwill
 b...@summerwill.net mailto:b...@summerwill.net wrote:


 I started digging into area last year.  
 See https://monohtml5.com/.

 I think there is huge potential for Mono and .NET apps
 targeting the browser, and treating HTML5 as just another
 platform.

 *
 
 https://monohtml5.wordpress.com/2014/05/29/a-vision-html5-can-be-just-another-platform-for-net/
 * 
 https://monohtml5.wordpress.com/2014/06/09/monohtml5-what-are-the-existing-projects-in-this-area/
 * 
 https://monohtml5.wordpress.com/2014/06/14/monohtml5-what-are-you-actually-trying-to-make/

 Joao is in the CC on this mail.


 Cheers,
 Bob

 On Mon, Mar 16, 2015 at 3:31 AM, Nirmal Lankathilaka
 nir3al+...@gmail.com mailto:nir3al+...@gmail.com wrote:

 Thanks for the clarification! Also, sorry for the late
 reply. I've been doing some reading and experimenting
 on asm.js/emscripten between my regular studies.

 Also, could you help me on how to contact João
 Matos, who is stated as the mentor for that project?

 On Sun, Mar 15, 2015 at 8:47 PM, Robert Jordan
 robe...@gmx.net mailto:robe...@gmx.net wrote:

 On 15.03.2015 10:59, Nirmal Lankathilaka wrote:

 I've been using Mono for developing desktop
 apps for a couple of years and
 would love to contribute to the project. Since
 I'm still a student, I think
 GSoC is a splendid opportunity to start.

 Porting Mono to `asm.js`, presented for
 GSoC, caught my attention
 recently. I spent some time researching this
 and I'd like some
 clarification from the community:

 Since Mono-LLVM support does exist[mono-llvm]
 
 http://www.mono-project.com/docs/advanced/mono-llvm/,
 why would the need
 arise for a port? I understand that there are
 limitations
 [mono-llvm#limitations]
 
 http://www.mono-project.com/docs/advanced/mono-llvm/#limitations
 in the
 above approach as LLVM doesn't fully support
 all the needs of Mono; but
 since there is no specifications given which
 would require one to avoid the
 above approach
 (mono-llvm--llvm--emscripten--asm.js), I'm
 a bit confused.


 The proposal assumes a slightly deeper
 understanding of the Mono
 internals.

 
 http://www.mono-project.com/community/google-summer-of-code/projects/#port-mono-to-asmjs

 mono runtime is here the part of Mono that
 provides the OS
 abstraction layer (file, network etc.) and GC.
 It's that minimal
 part of Mono that's needed for running static AOT
 (ahead-of-time
 compilation) assemblies that were compiled to
 native shared objects
 or included into the main executable. Basically,
 it's Mono sans
 code generation, suitable to run on the target.

 The 

Re: [Mono-dev] Proposed endian optimization - s390x

[Alex Rønne Petersen]

Have you checked that GCC doesn't already optimize the functions here
into these instructions? If it doesn't, maybe we could write them in a
way that GCC more easily recognizes.

But if that's not the case, I don't see any particular reason we
couldn't do this.

Regards,
Alex

On Wed, Mar 11, 2015 at 8:05 PM, Neale Ferguson ne...@sinenomine.net wrote:
 Hi,
  I am proposing the following changes to mono-endian.h to optimize
 little-endian to big-endian processing for s390x. The architecture defines
 instructions for just this purpose so instead of doing shifts etc. we can
 just do this:

 --- a/mono/metadata/mono-endian.h
 +++ b/mono/metadata/mono-endian.h
 @@ -14,7 +14,49 @@ typedef union {
 unsigned char cval [8];
  } mono_rdouble;

 -#if NO_UNALIGNED_ACCESS
 +#if defined(__s390x__)
 +
 +#define read16(x)  s390x_read16(*(guint16 *)(x))
 +#define read32(x)  s390x_read32(*(guint32 *)(x))
 +#define read64(x)  s390x_read64(*(guint64 *)(x))
 +
 +static __inline__ guint16
 +s390x_read16(guint16 x)
 +{
 +   guint16 ret;
 +
 +   __asm__ (  lrvr%0,%1\n
 +  sra %0,16\n
 +: =r (ret) : r (x));
 +
 +   return(ret);
 +}
 +
 +static __inline__ guint32
 +s390x_read32(guint32 x)
 +{
 +   guint32 ret;
 +
 +   __asm__ (  lrvr%0,%1\n
 +: =r (ret) : r (x));
 +
 +   return(ret);

 +}
 +
 +static __inline__ guint64
 +s390x_read64(guint64 x)
 +{
 +   guint64 ret;
 +
 +   __asm__ (  lrvgr   %0,%1\n
 +: =r (ret) : r (x));
 +
 +   return(ret);
 +}
 +
 +#else
 +
 +# if NO_UNALIGNED_ACCESS

  guint16 mono_read16 (const unsigned char *x);
  guint32 mono_read32 (const unsigned char *x);
 @@ -24,12 +66,14 @@ guint64 mono_read64 (const unsigned char *x);
  #define read32(x) (mono_read32 ((const unsigned char *)(x)))
  #define read64(x) (mono_read64 ((const unsigned char *)(x)))

 -#else
 +# else

  #define read16(x) GUINT16_FROM_LE (*((const guint16 *) (x)))
  #define read32(x) GUINT32_FROM_LE (*((const guint32 *) (x)))
  #define read64(x) GUINT64_FROM_LE (*((const guint64 *) (x)))

 +# endif
 +
  #endif

  #define readr4(x,dest) \


 Any objections?

 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

[Mono-list] Question about Mono processor architecture reporting on ARM platforms

[Alex J Lennon]

Hi,

I'm trying to determine the processor architecture at runtime on an ARM
platform using the following code snippet, but it reports I386

class Program
{
static ImageFileMachine ProcessorArchitecture
{
get
{

PortableExecutableKinds peKind;
ImageFileMachine machine;
typeof(object).Module.GetPEKind(out peKind, out machine);
return machine;
}
}

static void Main()
{
Console.WriteLine(Processor Architecture is:  +
ProcessorArchitecture);
}
}

It is reporting I386 with the latest Mono 3.12.0 release on qemuarm, and
also with Mono 3.4.0 on ARM hardware (i.MX6-based)

I expected ImageFileMachine.ARM (0x01C4) but get I386

Can anybody advise if this is an implementational issue or if I'm doing
something wrong here?

Thanks,

Alex

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

Re: [Mono-list] Question about Mono processor architecture reporting on ARM platforms

[Alex J Lennon]

On 29/01/2015 14:38, Jonathan Pryor wrote:
 On Jan 29, 2015, at 3:33 AM, Alex J Lennon ajlen...@dynamicdevices.co.uk 
 wrote:
 Can anybody advise if this is an implementational issue or if I'm doing 
 something wrong here?
 You're doing something wrong, *and* there's an implementation issue.

 Module GetPEKind() returns information about the specified module, which can 
 have absolutely no bearing on the actual runtime environment.


Aha - thanks very much for clearing that up for me Jon.

Cheers, Alex

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

Re: [Mono-dev] llvm and mini

[Alex Rønne Petersen]

We don't have such a system in Mono. When you run `mono --llvm`, Mono
will try to use LLVM for all methods.

I could see a system like this being implemented based on the
instrumentation functions we have in the JIT. I think the real
challenge would lie in notifying the rest of the runtime/program that
an already-JITed method has been re-JITed, and in a non-racy way.

Regards,
Alex

On Wed, Jan 28, 2015 at 7:59 PM, Jerry Maine crashfou...@gmail.com wrote:
 I am wondering if mono could have (or already has) a feature that could use
 mini (the current jit) to quickly compiling code and then recompile certain
 critical pieces with llvm if warranted and want would it take to develop it
 if mono does not have it already.

 ___
 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

[Alex J Lennon]

On 11/12/2014 10:51, Robert Jordan wrote:
 On 11.12.2014 07:33, Alex J Lennon wrote:
 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).


 This is also news to me and very helpful to know thanks. I am not
 disagreeing but I am surprised that we have to have an exactly matching
 build of monolite for this, whereas we don't  if using a full-fat
 Mono. I wonder why that is? Because monolite is very barebones just for
 bootstrapping purposes ?

 Monolite (a mcs + basic BCL) does not contain a Mono
 runtime. That's the reason why its corlib must match the
 runtime that you are about to build.

 On the other hand, a full Mono does not have this limitation
 because it comes with its own runtime + BCL + mcs. These are
 by design always in sync.

Thanks for the background Robert.

___
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

[Alex J Lennon]

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

[Alex J Lennon]

Hi Alex,

On 11/12/2014 01:47, Alexander Köplinger wrote:
 Hey Alex,
 monolite is built and uploaded automatically by Wrench:
 https://wrench.mono-project.com/Wrench/ViewTable.aspx?host_id=21lane_id=4page=0limit=20,
 the issue I think was that the build was broken there so a new
 monolite didn't get uploaded, this is now fixed.
  

Ah that explains a great deal. Thanks for explaining that to me.

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


This is also news to me and very helpful to know thanks. I am not
disagreeing but I am surprised that we have to have an exactly matching
build of monolite for this, whereas we don't  if using a full-fat
Mono. I wonder why that is? Because monolite is very barebones just for
bootstrapping purposes ?

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

Now I understand that the monolite package is auto-built I'd prefer to
use that. Although I've had ongoing issues on and off for long time with
missing old monolite archives and so forth.

In that case I will leave Appveyor using get-monolite-latest for now,
but the use of EXTERNAL_MCS I mentioned was, as you say, to attempt to
use the pre-installed Mono image they have on their build worker VM
images as standard.

Thanks again, much appreciated.

Alex

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

[Mono-dev] Appveyor builds failing - corlib v112

[Alex J Lennon]

Hi,

Appveyor builds have been failing on get-monolite-latest since commit
#33861cf3

I believe this is because mono_corlib_version was changed to 112 and
there is no downloadable archive available at

http://storage.bos.xamarin.com/mono-dist-master/latest/monolite-112-latest.tar.gz

Perhaps I misunderstand, but if I'm correct about this would it be
possible for somebody to make that available?

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] Building Mono on Windows - And Having a Windows Installer again

[Alex J Lennon]

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 
 process of ./configure  make  make install usually works.  If it 
 doesn't, then add make get-monolite-latest before make EXTERNAL_MCS=...  
 as below...

 On every redhat-based or debian-based (or even mac) system I've ever used, 
 one of these two variants has always worked.

 OSX
 export BUILDDIR=/Users/whatever/Projects/mono-build
 export NUMPROC=3 ; time ( test -d $BUILDDIR  rm -rf $BUILDDIR ; mkdir -p 
 $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
  make -j $NUMPROC  make install  echo   echo Done  echo )

 Ubuntu 14.04
 export BUILDDIR=/home/whatever/Projects/mono-build
 export NUMPROC=3 ; time ( test -d $BUILDDIR  rm -rf $BUILDDIR ; mkdir -p 
 $BUILDDIR ; ./autogen.sh --prefix=$BUILDDIR --disable-bcl-opt --enable-nls=no 
  make get-monolite-latest  make -j $NUMPROC 
 EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe  make install  echo 
   echo Done  echo )


Possibly a bit off-topic but fwiw I maintain and use Yocto for Embedded
Linux with meta-mono layer. The recipes for building Mono are here,

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/recipes-mono/mono?h=master

Cheers,

Alex

Re: [Mono-dev] Building Mono on Windows - And Having a Windows Installer again

[Alex J Lennon]

Hi Alex

On 30/11/2014 15:09, Alexander Köplinger wrote:
 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

That sounds great. Maybe I will try to bolt that onto the Appveyor
script then. I'd love for the CI builds to just result in an MSI anybody
can grab and use easily.

  
 Btw. while developing the WiX setup I used the binaries from your
 AppVeyor build, it all worked fine :)

Really good to hear that thanks Alex :)

  
 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.


Yes it's definitely on my TODO list. I was hoping to grab the content of
my CodeProject article and massage it into that page. Things have just
been so hectic here I haven't had the chance yet :)

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

[Alex J Lennon]

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

[Alex J Lennon]

On 06/11/2014 12:53, Alexander Köplinger wrote:
 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. 

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

Re: [Mono-dev] Mono 3.2.3 download for Windows replaced by an imposter?

[Alex J Lennon]

Thanks Miguel.

On 03/11/2014 21:05, Miguel de Icaza wrote:
 CCing Duncan.

 On Tue, Oct 21, 2014 at 2:18 PM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk mailto:ajlen...@dynamicdevices.co.uk
 wrote:

 Hi,

 As I continue to try to get on top of the odyssey that is building
 Mono
 for Windows I came across an oddity over at Appveyor.

 It appears the latest Windows Mono 3.2.3 release tarball available
 from
 the mono-project link below is actually 3.3.0/master sneakily
 masquerading as 3.2.3.

 Seems odd. I'm sure it used to be 3.2.3 once upon a time. I have
 double-checked here though with what I think is a reasonably clean 
 tidy VM. Command line reports 3.3.0.

 Maybe somebody could confirm it's not just senility on my part ?

 
 http://download.mono-project.com/archive/3.2.3/windows-installer/mono-3.2.3-gtksharp-2.12.11-win32-0.exe

 C:\Program Files (x86)\Mono-3.2.3mono --version
 Mono JIT compiler version 3.3.0 (master/6cd4ddc)
 Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors.
 www.mono-project.com http://www.mono-project.com
 TLS:   normal
 SIGSEGV:   normal
 Notification:  Thread + polling
 Architecture:  x86
 Disabled:  none
 Misc:  softdebug
 LLVM:  supported, not enabled.
 GC:sgen

 Thanks,

 Alex

 ___
 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



-- 

Dynamic Devices Ltd http://www.dynamicdevices.co.uk/

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374

Linkedin http://www.linkedin.com/in/alexjlennon Skype
skype:alexjlennon?add

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.

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

[Mono-dev] Cygwin build - warnings about arguments gint32 vs LONG

[Alex J Lennon]

Hi,

There seem to be a large number of warnings generated during the
Windows/Cygwin build relating to the type of arguments provided to
various support functions.

The functions seem to be mostly prototyped in platform includes such as

/usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h
/usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h

The warnings are of this flavour

/usr/i686-pc-mingw32/sys-root/mingw/include/winbase.h:1796:24: note:
expected 'PDWORD' but argument is of type 'guint32 *'

I have been experimenting with declaring some of the prototypes within
the build environment instead of in those platform incldues but there's
so much of this I am at a bit of a loss as to how to proceed.

I am now wondering if it is better to pull in winbase.h / winsock2.h and
rewrite them to take the gint* style. I'm not terribly keen on that idea.

That or maybe there's a way to make gint32 and friends appear as LONG
and the equivalents and so forth, although that also seems less than ideal.

Can anybody advise on a sensible way for me to approach this?

Thanks,

Alex

-- 

Dynamic Devices Ltd http://www.dynamicdevices.co.uk/

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374

Linkedin http://www.linkedin.com/in/alexjlennon Skype
skype:alexjlennon?add

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination, distribution,
copying or the taking of any action in reliance on the information
herein is prohibited. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, or contain viruses.
Anyone who communicates with us by e-mail is deemed to have accepted
these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from
the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not
necessarily represent those of the company.

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

[Mono-dev] [eglib] Warning: assertion function returning

[Alex J Lennon]

Hi,

I'm seeing an eglib warning about an assertion handling function with a
G_GNUC_NORETURN attribute that is returning.

goutput.c: In function ‘monoeg_assertion_message’:
goutput.c:135:1: warning: ‘noreturn’ function does return [enabled by
default]

I'm wondering how this should be resolved, ie. whether this function
should block, whether the attribute should be removed, or something else?

If the assertion handler should block then is while(1); sensible, or a
very bad idea?

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] [eglib] Warning: assertion function returning

[Alex J Lennon]

Hi Rodrigo,

On 30/10/2014 17:28, Rodrigo Kumpera wrote:
 Since the noreturn behavior is not verifiable by the compiler (it's
 part of the API contract) we can a hack to silence the warning.


If that's what's wanted that's fine by me of course. Easily done.

But I don't understand: Surely the fact the compiler is complaining
shows that it does know that the function is returning, when it has been
told via the attributing that the function should not?

As a test, if I add a while(1); at the bottom of the function then the
complaint goes away as the compiler knows that the return is unreachable.

I am guessing I am misunderstanding your point?

More importantly, should the assertion handler return or not... ?

Cheers,

Alex

On Thu, Oct 30, 2014 at 12:08 PM, Alex J Lennon
ajlen...@dynamicdevices.co.uk mailto:ajlen...@dynamicdevices.co.uk
wrote:

 Hi,

 I'm seeing an eglib warning about an assertion handling function
 with a
 G_GNUC_NORETURN attribute that is returning.

 goutput.c: In function ‘monoeg_assertion_message’:
 goutput.c:135:1: warning: ‘noreturn’ function does return [enabled by
 default]

 I'm wondering how this should be resolved, ie. whether this function
 should block, whether the attribute should be removed, or
 something else?

 If the assertion handler should block then is while(1); sensible, or a
 very bad idea?

 Thanks,

 Alex


 ___
 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


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

Re: [Mono-dev] Fwd: [eglib] Warning: assertion function returning

[Alex J Lennon]

On 30/10/2014 18:57, Rodrigo Kumpera wrote:
 Forgot to CC dev

 -- Forwarded message --
 From: *Rodrigo Kumpera* kump...@gmail.com mailto:kump...@gmail.com
 Date: Thu, Oct 30, 2014 at 1:57 PM
 Subject: Re: [Mono-dev] [eglib] Warning: assertion function returning
 To: Alex J Lennon ajlen...@dynamicdevices.co.uk
 mailto:ajlen...@dynamicdevices.co.uk




 On Thu, Oct 30, 2014 at 12:34 PM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk mailto:ajlen...@dynamicdevices.co.uk
 wrote:

 Hi Rodrigo,

 On 30/10/2014 17:28, Rodrigo Kumpera wrote:
 Since the noreturn behavior is not verifiable by the compiler
 (it's part of the API contract) we can a hack to silence the warning.


 If that's what's wanted that's fine by me of course. Easily done.

 But I don't understand: Surely the fact the compiler is
 complaining shows that it does know that the function is
 returning, when it has been told via the attributing that the
 function should not?

 As a test, if I add a while(1); at the bottom of the function then
 the complaint goes away as the compiler knows that the return is
 unreachable.

 I am guessing I am misunderstanding your point?

 More importantly, should the assertion handler return or not... ?


 The problem is that the abort happens through the logging callback and
 that can't be verified by the compiler.

 Any well behaved implementation must make sure it does not return. I
 think adding a while (1); at the end is a good enough solution.
 We want the noreturn semantics there.


OK thanks. I agree I tend to think an assertion handler shouldn't
continue execution (if things have blown up to that extent then it's
perhaps better not to try to soldier on...)

I am sort of wondering what that means in real world production systems
though. e.g. Something unexpected happens, Mono outputs an assertion and
hangs with the CPU full on?

That would be less than ideal for the type of use cases I have, with an
black box embedded system possibly running on batteries.

Most simplistic system watchdog / error condition handling probably just
checks for the existence of the process, restarting the process or the
hardware on error, so Mono getting locked into a while(1); look wouldn't
be caught I imagine?

Wouldn't it be better for the process to log an error and exit in some
manner when the assertion handler is called?

(Just some thoughts...)

Cheers, Alex

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

[Mono-dev] [CI] RFC - Mono now building on Cygwin/Windows with Appveyor

[Alex J Lennon]

Hi all,

I've reached a point where we have an Appveyor configuration file which
successfully builds Mono under Cygwin on an Appveyor build worker
(Windows Server 2012 R2 OS image, I believe).

It's taken longer to get to this point than I had expected, doesn't it
always, but I hope this will be of some use to others wishing to build,
use and maintain Mono under Windows.

The logs of the build history are here, with a downloadable Mono 3.10.0
zip file artifact, available from the most recent build, which runs up
on my local machine.

https://ci.appveyor.com/project/ajlennon/mono-817

The configuration file that Appveyor used for this build is in my fork
of mono-3.10.0-branch

   
https://github.com/DynamicDevices/mono/blob/mono-3.10.0-branch/appveyor.yml

All commentary and feedback would be much appreciated.

I'd like to understand what would be involved to get this to a point
where pull-request into master might be accepted. (NB The config file is
entirely independent of other Mono files in the repo).
 
Thanks to Mladen for the Appveyor suggestion and the template
configuration script I used as a starting point.

Also many thanks to Feodor Fitsner at Appveyor who has been very engaged
and supportive in helping me to get this going over the past week or so.
(I am very impressed in general with the Appveyor platform and we will
undoubtedly be using this for commercial work in future).

Some points perhaps worthy of note,

- The build configuration script installs needed dependencies, runs
autogen/configure/make/make install then archives the output installed
files as a zipfile 'artifact'. This can be downloaded or deployed
automatically (e.g. FTP)

- Build testing has shown up a couple of minor issues with
mono-3.10.0-branch and master needing patches to build under Windows

- Following on from this I would like and intend to add to the current
configuration script to package up the output as an installable MSI
similar to that provided on the official site.
  (I think monowiz-win32.nsi could be used with NSIS as a starting point
for this work, although it looks like it might be quite dated in
comparison to the current installer?)

- I'd also like to run the Mono tests as a part of the build
verification. Are they expected to work under Windows/Cygwin?

- The official mono-3.10.0-branch of Mono does not build under Windows.
For this to build a commit would need to be cherry-picked to
mono-3.10.0-branch from master. My fork includes this commit enabling
the build.
  (Vincent Povirk's needed commit is in the forked branch of
mono-3.10.0-branch here
https://github.com/DynamicDevices/mono/commit/ce29c7c567afc4dcc14155d88250ebf6cfbc6718)

- The current master also does not build which looks to be an inclusion
ordering issue in mono/metadata/socket-io.c
   (I think I have addressed this with PR#1366 - for discussion -  as
there may well be better ways to do this:
https://github.com/mono/mono/pull/1366)

- The standard Appveyor plan limits builds to 30 minutes. The Mono build
is currently taking slightly over 3 hours and so will be cut short on
the default plan. Feyodor@Appveyor has very kindly put me onto an
OpenSource build plan which prevents the build being cut short.

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] [CI] RFC - Mono now building on Cygwin/Windows with Appveyor

[Alex J Lennon]

On 26/10/2014 16:05, Alexander Köplinger wrote:
 Very good news!
  
 The windows installer is built by
 https://github.com/mono/release/tree/master/windows-installer as far
 as I know, not the monowiz.win32.nsi in the Mono repo (that looks
 indeed very outdated and should probably be removed).
  

Ah that's great thanks Alex - just what I have been looking for :) I'll
work out how to integrate this as a next step

 It'd be very helpful if you could also send a PR to the Mono website
 (http://www.mono-project.com/docs/compiling-mono/windows/ just click
 the Edit on GitHub link under the page title), it surely misses some
 of the steps you used to get this working.


Will do

Cheers,

Alex

 -- Alex
  
  Date: Sun, 26 Oct 2014 15:14:20 +0100
  From: ajlen...@dynamicdevices.co.uk
  To: mmihajlo...@gmail.com; jonc...@gmail.com;
 bryan.cro...@silvercurve.co.uk
  CC: feo...@appveyor.com; mono-devel-list@lists.ximian.com
  Subject: [Mono-dev] [CI] RFC - Mono now building on Cygwin/Windows
 with Appveyor
 
  Hi all,
 
  I've reached a point where we have an Appveyor configuration file which
  successfully builds Mono under Cygwin on an Appveyor build worker
  (Windows Server 2012 R2 OS image, I believe).
 
  It's taken longer to get to this point than I had expected, doesn't it
  always, but I hope this will be of some use to others wishing to build,
  use and maintain Mono under Windows.
 
  The logs of the build history are here, with a downloadable Mono 3.10.0
  zip file artifact, available from the most recent build, which runs up
  on my local machine.
 
  https://ci.appveyor.com/project/ajlennon/mono-817
 
  The configuration file that Appveyor used for this build is in my fork
  of mono-3.10.0-branch
 
 
 
 https://github.com/DynamicDevices/mono/blob/mono-3.10.0-branch/appveyor.yml
 
  All commentary and feedback would be much appreciated.
 
  I'd like to understand what would be involved to get this to a point
  where pull-request into master might be accepted. (NB The config file is
  entirely independent of other Mono files in the repo).
 
  Thanks to Mladen for the Appveyor suggestion and the template
  configuration script I used as a starting point.
 
  Also many thanks to Feodor Fitsner at Appveyor who has been very engaged
  and supportive in helping me to get this going over the past week or so.
  (I am very impressed in general with the Appveyor platform and we will
  undoubtedly be using this for commercial work in future).
 
  Some points perhaps worthy of note,
 
  - The build configuration script installs needed dependencies, runs
  autogen/configure/make/make install then archives the output installed
  files as a zipfile 'artifact'. This can be downloaded or deployed
  automatically (e.g. FTP)
 
  - Build testing has shown up a couple of minor issues with
  mono-3.10.0-branch and master needing patches to build under Windows
 
  - Following on from this I would like and intend to add to the current
  configuration script to package up the output as an installable MSI
  similar to that provided on the official site.
  (I think monowiz-win32.nsi could be used with NSIS as a starting point
  for this work, although it looks like it might be quite dated in
  comparison to the current installer?)
 
  - I'd also like to run the Mono tests as a part of the build
  verification. Are they expected to work under Windows/Cygwin?
 
  - The official mono-3.10.0-branch of Mono does not build under Windows.
  For this to build a commit would need to be cherry-picked to
  mono-3.10.0-branch from master. My fork includes this commit enabling
  the build.
  (Vincent Povirk's needed commit is in the forked branch of
  mono-3.10.0-branch here
 
 https://github.com/DynamicDevices/mono/commit/ce29c7c567afc4dcc14155d88250ebf6cfbc6718)
 
  - The current master also does not build which looks to be an inclusion
  ordering issue in mono/metadata/socket-io.c
  (I think I have addressed this with PR#1366 - for discussion - as
  there may well be better ways to do this:
  https://github.com/mono/mono/pull/1366)
 
  - The standard Appveyor plan limits builds to 30 minutes. The Mono build
  is currently taking slightly over 3 hours and so will be cut short on
  the default plan. Feyodor@Appveyor has very kindly put me onto an
  OpenSource build plan which prevents the build being cut short.
 
  Cheers,
 
  Alex
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list

-- 

Dynamic Devices Ltd http://www.dynamicdevices.co.uk/

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374

Linkedin http://www.linkedin.com/in/alexjlennon Skype
skype:alexjlennon?add

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any unauthorized disclosure, dissemination

Re: [Mono-dev] [CI] RFC - Mono now building on Cygwin/Windows with Appveyor

[Alex J Lennon]

On 26/10/2014 16:28, Vincent Povirk wrote:
 - I'd also like to run the Mono tests as a part of the build
 verification. Are they expected to work under Windows/Cygwin?
 I was not able to run the tests on Windows/Mono in current master. I
 made this PR to address that: https://github.com/mono/mono/pull/1360

 They should run on Windows/.NET without that patch.

 I don't expect them to pass, even on .NET, and I think it'd be a large
 effort to whip them into shape.



Thanks for letting me know Vincent. I wondered if that might be the
case. I will leave that on the back-burner for now then.

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

[Mono-dev] Replacing missing monolite 110 archive ?

[Alex J Lennon]

Hi,

I'm nearly at the point where I can build mono win32 under Appeyor CI.

I'm trying to understand why there appears to be no mono.exe installed,
as a prelude to packaging up the build.

To do this I am trying to build the latest official release 3.2.3 but
this fails without monolite and I cannot get-monolite-latest as the 110 
archive for corlib 110 has been removed.

Would it be possible to replace the missing monolite-110-latest.tar.gz
on the Xamarin site to facilite building of older Mono versions?

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] Unit Testing process: Community Contributions

[Alex J Lennon]

On 21/10/2014 13:05, Edward Ned Harvey (mono) wrote:
 From: Miguel de Icaza [mailto:mig...@xamarin.com]

 There is no need to presume, the actual issue was just articulated on a
 thread, please read it.

 Pull requests do not work well with Mono.   They need to be discussed in the
 mailing list
 Did I miss something?  Do you not recognize that there's a problem here?

 What are we supposed to do when we do all that stuff - discuss in mailing 
 list, pay for Xamarin, contact Xamarin support, file or find bug in bugzilla, 
 and even write our own patches and submit pull request to solve our own 
 problems, and then *still* nothing happens?


+1

fwiw Mono's great etc. etc. and I would love to be able to run Mono on
Arm hardfp platforms so was really pleased and grateful for the work
that went in to support this around 3.2.7

Unfortunately there were issues, most obviously with an exception trying
to show a textbox.

So I read up on how to file a bug report
(http://www.mono-project.com/community/bugs/make-a-good-bug-report/) and
did so, with a test case that shows the problem in a straightforward manner.

The bug report was filed in May and is here:
https://bugzilla.xamarin.com/show_bug.cgi?id=20239

So, I don't know, maybe I went about this wrongly, but I tried to follow
the procedures laid down for raising this as I understood it.

I also made it clear that I was happy to put some time on and work on
this but could do with some support to get going, so I'm not trying to
freload on others doing the work here.

Yet there was absolutely no response at all. Not redo the report for
this reason, you need to look here, we're looking at this or even
we have no intention of fixing this.

It's really discouraging when you put in the time and try to follow the
procedures laid down but there is absolutely no engagement. I mean - why
bother again if there's no point?

(NB. This issue may or may not be resolved in 3.10.0 but as there was no
response to the bug I have no way of knowing until I have the time to
rebuild and retest on this platform)

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] Unit Testing process: Community Contributions

[Alex J Lennon]

On 21/10/2014 16:18, Miguel de Icaza wrote:

 Unfortunately there were issues, most obviously with an exception
 trying
 to show a textbox.

 So I read up on how to file a bug report
 (http://www.mono-project.com/community/bugs/make-a-good-bug-report/)
 and
 did so, with a test case that shows the problem in a
 straightforward manner.


 Glad you did this.   A good bug report with good information will give
 the person that will look into the bug many more clues as to what is
 wrong.

 The bug report was filed in May and is here:
 https://bugzilla.xamarin.com/show_bug.cgi?id=20239

 So, I don't know, maybe I went about this wrongly, but I tried to
 follow
 the procedures laid down for raising this as I understood it.


 Let me set some expectations here.

 Windows.Forms is not actively developed or maintained.   If you want
 support for Windows.Forms your best bet is to hire a contractor to fix
 Windows.Forms for you.

 The Mono team stopped full time development of that stack sometime
 around 2009 (give or take a year).   While I would like to remove it,
 there are certain dependencies that require it, so we keep it around.


Thanks Miguel - the background helps me to understand the situation.

 I also made it clear that I was happy to put some time on and work on
 this but could do with some support to get going, so I'm not trying to
 freload on others doing the work here.

 Yet there was absolutely no response at all. Not redo the report for
 this reason, you need to look here, we're looking at this or even
 we have no intention of fixing this.


 I can see that this can be frustrating, but filing a bug does not mean
 someone is going to look at it.   

 You might have gotten a *little bit* more engagement if you post to
 the mailing list, as opposed to waiting for the rare case of someone
 accidentally strolling into the bug.   It is a long shot, but worth a try.


I did try that a few times, as I recall, when there was no response :)

 This is not different than any other open source project.   If you
 want to keep a particular port of Linux alive, you have to do the
 work.   You want to maintain some drivers?   You have to do the work.
   People do not respond to your issues?   You must reach out.   There
 is no community around a particular feature you need?   Rally the troops. 


I am happy to do the work, where I can, and where I cannot I do not
expect others to do the work unless I happen to be paying them for their
trouble.

What I'm trying to suggest is that for the idea of community to work
it helps if there's engagement with those who wish to become involved.

It's a pipeline. I believe engagement is a win-win as time spent
fostering no-nothing newbies like myself will (one would hope) result in
a small percentage of those no-nothing newbies turning into useful
contributors, for the betterment of the project.

And that's impossible without some level of time-investment in
engagement - such as having somebody respond to bug reports even if this
is to say sorry this is unmaintained - your problem

 It's really discouraging when you put in the time and try to
 follow the
 procedures laid down but there is absolutely no engagement. I mean
 - why
 bother again if there's no point?


 I agree, do not bother with unmaintained code.   Instead use stacks
 that are actively maintained, like Gtk#.


If only life was that simple :) To reiterate though, I'd have tried to
fix this if I knew where to begin looking, as I have applications here
that need System.Windows.Forms and which I can't simply abandon or rewrite.

Presumably Microsoft still views as System.Windows.Forms as maintained?
Or have they abandoned it too?

Is there a place where I can see a matrix of what components the Mono
project views as unmaintained and therefore what kind of .NET
applications may no longer run under the current release of Mono?

Thanks for the 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] Unit Testing process: Community Contributions

[Alex J Lennon]

On 21/10/2014 16:37, Miguel de Icaza wrote:


 And that's impossible without some level of time-investment in
 engagement - such as having somebody respond to bug reports even
 if this is to say sorry this is unmaintained - your problem


 Seems like you just volunteered to do this for all the bugs that come
 in for Windows.Forms :-)


I have no problem with that Miguel.

Now I know that applications with a dependency on Windows.Forms are no
longer
supported under Mono, when I encounter somebody trying to get suhc an
application working  I'll be pleased to tell them that this isn't
supported nowadays.

I would even have a go at fixing issues such as the one I raised, given
some level of
engagement from those who know, and presumably would vaguely like things to
work, on where they might lie.

Cheers,

Alex

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

[Mono-dev] Mono 3.2.3 download for Windows replaced by an imposter?

[Alex J Lennon]

Hi,

As I continue to try to get on top of the odyssey that is building Mono
for Windows I came across an oddity over at Appveyor.

It appears the latest Windows Mono 3.2.3 release tarball available from
the mono-project link below is actually 3.3.0/master sneakily
masquerading as 3.2.3.

Seems odd. I'm sure it used to be 3.2.3 once upon a time. I have
double-checked here though with what I think is a reasonably clean 
tidy VM. Command line reports 3.3.0.

Maybe somebody could confirm it's not just senility on my part ?

http://download.mono-project.com/archive/3.2.3/windows-installer/mono-3.2.3-gtksharp-2.12.11-win32-0.exe

C:\Program Files (x86)\Mono-3.2.3mono --version
Mono JIT compiler version 3.3.0 (master/6cd4ddc)
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS:   normal
SIGSEGV:   normal
Notification:  Thread + polling
Architecture:  x86
Disabled:  none
Misc:  softdebug
LLVM:  supported, not enabled.
GC:sgen

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] [CI] Building Mono executable under Windows

[Alex J Lennon]

On 20/10/2014 17:08, Rafael Teixeira wrote:
 I would guess at /usr/local/bin which in the Windows world would be
 relative to the cygwin installation directory...


Mmm I would have thought so too - but it doesn't appear to be created,
either by make, or by make install...

e.g. a 'find -name mono.exe' gives nothing either in the source tree or
the install tree.

Maybe I need to go back to 3.2.3 branch to see what used to happen.

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] [CI] Building Mono executable under Windows

[Alex J Lennon]

On 20/10/2014 17:12, Alex J Lennon wrote:

 On 20/10/2014 17:08, Rafael Teixeira wrote:
 I would guess at /usr/local/bin which in the Windows world would be
 relative to the cygwin installation directory...

 Mmm I would have thought so too - but it doesn't appear to be created,
 either by make, or by make install...

 e.g. a 'find -name mono.exe' gives nothing either in the source tree or
 the install tree.

 Maybe I need to go back to 3.2.3 branch to see what used to happen.


I've build this again under Cygwin with mono-3.10.0-branch
autoconf/configure/make/make install

I was wrong about the source tree. There is a mono.exe in mono/mini.
However this is a symlink to mono-sgen.exe
which seems to be a build output from the timestamp.

I suspect this is related to symlinking issues with Cygwin and with the
Mono build as the make install step creates
a mono file in the installation bin directory, rather than the needed
mono.exe.

My reading seems to indicate that unless configured otherwise Cygwin
creates magic cookie shortcuts for
symlinks so it might be that the install process is causing Cygwin to
create that shortcut as mono rather than
mono.exe and that what we really need is either to configure Cygwin to
generate hard links instead of magic
cookies or perhaps preferably just to copy mono-sgen.exe as mono.exe

ref:
http://stackoverflow.com/questions/3648819/how-to-make-symbolic-link-with-cygwin-in-windows-7

There's also a similar thing going on with mcs I think

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] Building mono on Windows issues.

[Alex J Lennon]

Hi Mladen,

On 17/10/2014 16:25, Alex J Lennon wrote:
 On 17/10/2014 16:07, Alex J Lennon wrote:
 On 17/10/2014 09:09, Mladen Mihajlovic wrote:
 Hey Alex

 There's a lot that you can do through their yml settings file.
 Download and setup pretty much anything. Have a look in the root if
 the repo: appveyor.yml.

 Hi Mladen,

 I like the look of Appveyor a lot. Thanks for that.

 I've been getting going with the configuration file and in parallel
 testing the 3.10.0 release builds locally under cygwin
 as a sanity check and because each time I test a build with AppVeyor it
 starts from a clean OS image (not a bad thing)
 which means it takes a long time to clone the Mono repo before the build
 starts.

 Unfortunately the Windows build of release 3.10.0 fails locally:

 libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..
 -I../.. -I../../mono -I../../libgc/include -I../../eglib/src
 -I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502
 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS
 -DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv
 -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall
 -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
 -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
 -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
 -mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT
 sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c  -DDLL_EXPORT -DPIC -o
 .libs/sha1.o
 In file included from sha1.c:20:0:
 ./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
 before 'void'
 sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
 before 'typedef'
 sha1.c: In function 'SHA1Transform':
 sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l'

 It looks like perhaps the mono-3.10.0-branch needs Vincent's commit
 cherry-picking

 Use G_BEGIN_DECLS instead of __BEGIN_DECLS.

 https://github.com/mono/mono/commit/3c920be3e534c8c2d51695f16055e84936fe761e

 How would we go about flagging that up with somebody to ask them to look
 into it?

 Regards,

 Alex

Well I've made a certain amount of progress with Appveyor, and I like it, but 
I'm going around in circles with a strange problem.

When I get to the end of the autoconf stage under Cygwin it kicks off the 
configure script and early on in that I get this every time:

Skipping configure process.
Done running eglib/autogen.sh ...
Running ./configure --enable-maintainer-mode --enable-compile-warnings 
--prefix=/cygdrive/c/monoinstall --with-preview=yes ...
./configure: line 571: 0: Bad file descriptor

I've tried a range of different permutations but the error is always the same.

The Appveyor VM image is locked down from what I can see so I can't get in 
there to work out why it is failing, although it
seems to be on this line in the configure script

test -n $DJDIR || exec 70 /dev/null

After exhausting a range of other options I set up a Windows Server 2012 image 
in Azure, which seems to be what Appveyor is using,
followed the steps to download Cygwin manually, and ran up autoconf.

Annoyingly, when I do this the configure step works.

So I am at a bit of a loss...

The only other funny which might be related is that earlier on at the end of 
the automated Cygwin install step we see the following, and I'm wondering if 
that's somehow related...

setup.exe -qnNdO -R %CYG_ROOT% -s %CYG_MIRROR% -l %CYG_CACHE% -P autoconf 
-P automake -P bison -P gcc-core -P gcc-g++ -P mingw-gcc -P libtool -P make -P 
python  NUL
error: unknown (or unsupported) file type `x'
error: unknown (or unsupported) file type `x'
error: unknown (or unsupported) file type `x'

Any thoughts?

Regards,

Alex



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

[Alex J Lennon]

, there would be some buy-in from whomever
makes decisions on making a release, that before that release it made it
should at least build cleanly on Windows.

Cheers,

Alex
 
On 17/10/2014 03:21, Jonathan Chambers wrote:
 Hello,

 I was maintaining the Visual Studio solution for the runtime and doing
 Windows development for a while but haven't kept up for a number of
 years now. We've had a number of build mono on Windows discussions
 over the years and various attempts at improving it. Breaking the
 discussion into two pieces:

 Release/Install/CI for Windows

 This was done with cygwin and was packaged by an additional installer
 step. The installer step was never very transparent so I can't comment
 on that. 
 As for cygwin, the main issues were:
 - it's an amalgam of tools, which constantly update. There was never
 an easy way to duplicate a working setup from one machine to the next
 - given the size and complexity of the mono build and tests, it was
 generally not robust. Especially for continuous and automated usage
 - it was slow. Slow as in hours on Windows vs minutes on Linux

 Developing on Windows

 As for actually developing mono on Windows, the main issue was that
 you could not easily use Visual Studio to develop mono. The VS support
 for the runtime was put together long ago as a way to develop/debug,
 but it still required the full cygwin build to configure everything,
 build the class libraries, and run the tests. Even if one was brave
 enough to work in this setup, iteration time was slow (see above).
 Miguel and others made efforts to build everything using MSBuild but
 nothing quite materialized for a variety of reasons.


 All that to say, if you just want to get the Windows support back to
 where it was a few years ago via cygwin it can probably be done in a
 few developer weeks. If you actually want to improve the Windows
 development story, allowing for actual development and usage of
 Windows tools like Visual Studio it's much more work. I'd love for the
 latter to happen, but it's would take a lot of effort and
 coordination. Effort like improving xbuild where needed if msbuild is
 the build mechanism of choice. Coordination like making sure any work
 done didn't harm other platforms. 

 - Jonathan



 On Thu, Oct 16, 2014 at 2:16 PM, Alex J Lennon
 ajlen...@dynamicdevices.co.uk mailto:ajlen...@dynamicdevices.co.uk
 wrote:


 On 16/10/2014 16:58, Bryan Crotaz wrote:
  What's the estimation of effort required to get mono buildable in
  windows and debuggable in VS? 6 man months? 18 man months?
 
  I don't have time to donate but I'd be happy to put some money in a
  pot with some of you to hire someone to work on this full time.
 Feels
  like a concerted full time effort would bear more fruit than
  occasional toe-dips in the water.

 Bryan,

 fwiw - and this is merely a view from a bystander - I don't think it
 would take a lot to address the Windows build itself today.

 Mono does build on Windows, but it doesn't just work as people
 tend to
 expect nowadays. It needs some stream-lining imho with some setup
 script
 automation or similar for newbies. There are also some missing
 links in
 how an official Windows release is created versus using make, as
 we end
 up with missing files on install (or I am misunderstanding  something
 that needs doing, which in itself would be a documentation issue).

 To me this isn't a code issue so much as an ownership and release
 management issue. I recognise there is a cost to that and there has to
 be an ROI for that cost to be worth bearing.

 Releases are made with broken Window builds as Vincent says. So imho
 it's a dead work fixing master at any given time as it will just
 become broken again, although some basic setup scripting to pull down
 Cygwin, dependencies, to get the installation step working and such
 would help people to get going, I feel.

 What's more relevant, I believe, is a maintainer who has committed to
 Windows build testing and patching prior to an  offical release of
 Mono,
 a buy-in from other release maintainers that this is worth doing (or
 what's the point?), and perhaps some CI running the Mono tests in the
 background.

 Just my 4 cents,

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



-- 

Dynamic Devices Ltd http://www.dynamicdevices.co.uk/

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178 landline: +44 (0)1513 241374

Linkedin http://www.linkedin.com/in/alexjlennon Skype
skype:alexjlennon?add

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended
recipient(s). Any

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

Hi Mladen,

Sounds good to me. I've not encountered Appveyor before but it looks
good. How do you get the Cygwin dependencies in there? Can it be assumed
that what's happening in the Appveyor build is basically the same as on
a standard Windows box?

Cheers,

Alex

On 17/10/2014 08:53, Mladen Mihajlovic wrote:
 Hi Guys,

 I took it upon myself to try and get a build up and running on
 Appveyor yesterday. Please have a look
 at https://github.com/mika76/mono
 and https://ci.appveyor.com/project/mmihajlovic/mono - so far the only
 thing I've edited is the appveyor.yml file and the actual a[[veyor
 settings. 

 At the moment it is installing cygwin and packages and running the
 visual studio msbuild file - which seems not to work - it fails with
 compiler out of heap space error.

 If the msbuild does not pan out, the cygwin build can always be
 attempted as well.

 If anybody wants to help, let me know and I'll make you a contributor
 on the repository.

 Cheers,
 Mladen

 On 17 October 2014 08:46, Alex J Lennon ajlen...@dynamicdevices.co.uk
 mailto:ajlen...@dynamicdevices.co.uk wrote:

 Hi Jonathan,

 Thanks for taking the time to provide the background.

 I understand/agree that facilitating development on Windows is a
 complex task. I've seen some of the emails over time and can well
 imagine it's complex and invasive to the existing build system.
 People start the work, but I''ve not seen anything come out of it.

 If I take my scope as something much simpler, which is just to
 facilitate building Mono on Windows from scratch, on a vanilla
 Windows platform, perhaps defined as Windows 7/8.1 x32/x64 or
 whatever, then I think that's much more achievable.

 I have been looking at this since 3.4.0 and the main issues I have
 encountered were having the right dependencies, idiosyncracies of
 the build tools, and issues with releases such as missing
 files/problems with Cygwin headers.

 Perhaps very few of us are fit for purpose when it comes to
 actually _contributing_ to Mono, but I can well understand that
 the first step an OpenSource developer wants to make is to compile
 a project from source and run up the results.

 I can also understand the frustration when you've spent a couple
 of days on this and just keep encountering problems. People can
 then give up in frustration.

 Even the longest journey begins with a single step and it strikes
 me that it would be a useful thing to facilitate newbies building
 on Windows to get them going on that journey, even if that's just
 by documenting issues they will encounter.

 The emails I get from individuals show me that when they do have
 the information they need to build Mono, and how to work around
 the gotchas, then they can do it with relative ease.

 - it's an amalgam of tools, which constantly update. There was
 never an easy way to duplicate a working setup from one machine to
 the next

 I agree, but that's an issue with any complex software project
 with build dependencies surely? I work with Yocto Embedded Linux
 builds and I can tell you that it's even more difficult there, but
 they manage it extremely well.

 To address this seems to me a matter of understanding/documenting
 the dependencies and, where necessary, defining the require
 versions of those dependencies to ensure a build works in a
 controlled manner.

 I am making an assumption that the dependencies are all on Cygwin
 (are there any others?). If so then it should be relatively
 straightforward to define the version of Cygwin to use and/or pull
 down specific versioned packages.

 It was suggested to me that a setup script that pulled down
 appropriate dependencies would be useful, and I agree. I have been
 meaning to do something on that as I think it is straightforward
 but haven't yet had the time.

 If this was to be in place do you think there would be any other
 toolchain issues that would need consideration?

 This was done with cygwin and was packaged by an additional
 installer step. The installer step was never very transparent so I
 can't comment on that.

 Somebody somewhere must have been building the Windows installer,
 at least up until 3.2.3. I believe it would be helpful if somebody
 could take time to explain how this works or just provide the
 automation to build the installer.

 When we execute the 'make install' step what results on Windows is
 missing key files such as 'mono.exe' and instead has Linux stubs
 such as 'mono' which causes problems. I would like to understand
 how the install
 step is supposed to work and to try to fix it instead of having to
 manually fix it up each time. Similarly I would like to be able to
 generate a non-official installer in the same way as the official
 installer is built

Re: [Mono-dev] Building mono on Windows issues.

[Alex J Lennon]

On 17/10/2014 16:07, Alex J Lennon wrote:
 On 17/10/2014 09:09, Mladen Mihajlovic wrote:
 Hey Alex

 There's a lot that you can do through their yml settings file.
 Download and setup pretty much anything. Have a look in the root if
 the repo: appveyor.yml.

 Hi Mladen,

 I like the look of Appveyor a lot. Thanks for that.

 I've been getting going with the configuration file and in parallel
 testing the 3.10.0 release builds locally under cygwin
 as a sanity check and because each time I test a build with AppVeyor it
 starts from a clean OS image (not a bad thing)
 which means it takes a long time to clone the Mono repo before the build
 starts.

 Unfortunately the Windows build of release 3.10.0 fails locally:

 libtool: compile:  i686-pc-mingw32-gcc -DHAVE_CONFIG_H -I. -I../..
 -I../.. -I../../mono -I../../libgc/include -I../../eglib/src
 -I../../eglib/src -DWINVER=0x0502 -D_WIN32_WINNT=0x0502
 -D_WIN32_IE=0x0501 -D_UNICODE -DUNICODE -DWIN32_THREADS
 -DFD_SETSIZE=1024 -g -O2 -fno-strict-aliasing -fwrapv
 -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall
 -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
 -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
 -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value
 -mno-tls-direct-seg-refs -Werror-implicit-function-declaration -MT
 sha1.lo -MD -MP -MF .deps/sha1.Tpo -c sha1.c  -DDLL_EXPORT -DPIC -o
 .libs/sha1.o
 In file included from sha1.c:20:0:
 ./sha1.h:25:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
 before 'void'
 sha1.c:46:1: error: expected '=', ',', ';', 'asm' or '__attribute__'
 before 'typedef'
 sha1.c: In function 'SHA1Transform':
 sha1.c:71:2: error: 'CHAR64LONG16' has no member named 'l'


It looks like perhaps the mono-3.10.0-branch needs Vincent's commit
cherry-picking

Use G_BEGIN_DECLS instead of __BEGIN_DECLS.

https://github.com/mono/mono/commit/3c920be3e534c8c2d51695f16055e84936fe761e

How would we go about flagging that up with somebody to ask them to look
into it?

Regards,

Alex

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

[Alex J Lennon]

On 16/10/2014 00:17, Chris Eelmaa wrote:
 Hello all,

 I have question regarding building mono on windows,
 namely I've tried a lot of times, and had a lot of different
 problems(such as missing some dependencies, git converting *.sh files
 to CRLF ending and cygwin not being able to interpret them, etc..)

 however I've reached now to a point where I can run `make` for a little while,
 and then receive the error:

 In file included from socket-io.c:30:0:
 /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:38:2: error:
 #error ws2tcpip.h is not compatible with winsock.h. Include
 winsock2.h instead.
 In file included from socket-io.c:30:0:
 /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:147:8: error:
 redefinition of 'struct ip_mreq'
 In file included from
 /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:93:0,


 As you can see, winsock.h doesn't play well with ws2tcpip.h. I ran a
 grep to look for winsock.h from mono dir, but there's nothing about
 that. That file seems to be crawling in from some arbitrary place?!


 After that, I tried to compile with DISABLE_SOCKETS, and then I
 arrived to this place:

 ./.libs/libmini.a(libmini_la-debugger-agent.o): In function
 `socket_transport_connect':
 /cygdrive/c/GITHUB/mono/mono/mini/debugger-agent.c:1236: undefined
 reference to `mono_network_init'



 At this point, I have no idea what to do. Is mono master branch
 broken, or is it possible to actually build it with Windows from
 there? Can anyone confirm? Do I have messed up Windows SDK or
 something similiar?


Hi Chris,

I put this together precisely because it's such a problem -

http://www.codeproject.com/Articles/815565/How-to-build-Mono-on-Windows

I've tested various iterations and had feedback that others have found
it doesn't work.

Periodically git master doesn't build but I don't have the time to track
that. I will be updating
next time I discover there's a new release.

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] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 08:45, Alex J Lennon wrote:
 On 16/10/2014 00:17, Chris Eelmaa wrote:
 Hello all,

 I have question regarding building mono on windows,
 namely I've tried a lot of times, and had a lot of different
 problems(such as missing some dependencies, git converting *.sh files
 to CRLF ending and cygwin not being able to interpret them, etc..)

 however I've reached now to a point where I can run `make` for a little 
 while,
 and then receive the error:

 In file included from socket-io.c:30:0:
 /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:38:2: error:
 #error ws2tcpip.h is not compatible with winsock.h. Include
 winsock2.h instead.
 In file included from socket-io.c:30:0:
 /usr/i686-pc-mingw32/sys-root/mingw/include/ws2tcpip.h:147:8: error:
 redefinition of 'struct ip_mreq'
 In file included from
 /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:93:0,


 As you can see, winsock.h doesn't play well with ws2tcpip.h. I ran a
 grep to look for winsock.h from mono dir, but there's nothing about
 that. That file seems to be crawling in from some arbitrary place?!


 After that, I tried to compile with DISABLE_SOCKETS, and then I
 arrived to this place:

 ./.libs/libmini.a(libmini_la-debugger-agent.o): In function
 `socket_transport_connect':
 /cygdrive/c/GITHUB/mono/mono/mini/debugger-agent.c:1236: undefined
 reference to `mono_network_init'



 At this point, I have no idea what to do. Is mono master branch
 broken, or is it possible to actually build it with Windows from
 there? Can anyone confirm? Do I have messed up Windows SDK or
 something similiar?

 Hi Chris,

 I put this together precisely because it's such a problem -

 http://www.codeproject.com/Articles/815565/How-to-build-Mono-on-Windows

 I've tested various iterations and had feedback that others have found
 it doesn't work.

 Periodically git master doesn't build but I don't have the time to track
 that. I will be updating
 next time I discover there's a new release.

 Cheers,

 Alex

 ___

*does work

That'll teach me to email before coffee...

Regards,

Alex

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

[Alex J Lennon]

On 16/10/2014 12:38, Edward Ned Harvey (mono) wrote:
 From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]

 Generally
 speaking, the only reasons to build on windows are because you want to
 debug the code, which is generally better done on mac/linux.  Or you're
 trying to accomplish something else, like obtain a specific DLL (such as
 Mono.Data.Sqlite)...  Which usually you can obtain some other way such as
 building on linux and then copying the DLL over to windows.
 Agreed, but the the other reason is that you want to use a current Mono
 yet nobody has gotten around to an official release of Mono for WIndows
 since 3.2.3.
 Agreed, but that's the point - Why would you want to use Mono on windows?  
 The only reasons I know of are (a) you wish to debug the mono sources using 
 Visual Studio, or (b) you wish to use one of Mono's assemblies in windows, 
 such as Mono.Security, Mono.Data.Sqlite, etc.

 For case (a), at least for me, it's been easier to transition to Xamarin 
 Studio or Monodevelop on mac/linux.

 For case (b) I was able to brainlessly copy Mono.Security.dll, and I 
 struggled a little bit to copy Mono.Data.Sqlite.dll, but after a few tries, 
 managed to get it right more easily than getting it to build natively on 
 windows.



I guess different people will have different use-cases but this is ours
(which I don't think is so unique)

We develop software targetting Embedded Linux, Windows desktop/server
and Windows CE/Embedded Compact with .NET CF.

We use Visual Studio (plus Resharper as Bryan so rightly says - couldn't
get along without it) as we find this to be a productive development
environment.
In addition there is a lot of development resource out there with people
who know and are qualified on the VS toolchain.

Ideally we'd be write once and it'd just work whatever the platform or
framework, but the reality is we run into platform dependencies (SQLite
as you say, serial comms in the past), native dependencies and
configuration issues.

From a productivity perspective and for risk management for testing and
deployment I wish to be able to develop and debug under Visual Studio
with Mono as a framework option.

I'd like to be able to do that with Mono on Windows as a check that no
issues come up between running on the .NET framework and running on Mono.

In addition I'd like to be able to remote debug to Embedded Linux with
Visual Studio - which  I used to be able to do with Xamarin's Monotools
Server before it disappeared.

I'm currently investigating a VS plugin to replace Monotools Server
which I've not had much luck with yet, but I'm optimistic:
https://github.com/DynamicDevices/monodebugvs

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] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 15:37, Bryan Crotaz wrote:
 Basically if we could persuade Xamarin to get mono building on Windows
 and VS users able to debug Mono, suddenly there would be a lot more
 developers able to contribute without having to learn a whole new
 stack first.

 Bryan

+1 and I'm happy to put some time in to help in any way I can.

Alex

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

[Alex J Lennon]

 From a productivity perspective and for risk management for testing and
 deployment I wish to be able to develop and debug under Visual Studio
 with Mono as a framework option.

 I'd like to be able to do that with Mono on Windows as a check that no
 issues come up between running on the .NET framework and running on
 Mono.
 You can do that.  Don't need to build mono on windows - just do a normal 
 mono-for-windows install - I haven't done it in a while, but there's a plugin 
 to run your code against the mono runtime instead of .Net.  I'm pretty sure 
 it's free - might even be a standard extension you can find with the 
 Extension manager.


But this is exactly the point. I can't :-/ I wish I could.

I have Mono 3.8.0 built for multiple Embedded Linux platforms out of
Yocto and I want to use 3.8.0 on Windows in the development cycle, not
3.2.3 from September 2013.

I wish to be running the same releases of code for
development/debug/deployment in as far as is possible to catch any
potential problems.

But nobody seems to have ownership of at present of keeping Windows
binary releases in sync with Mono source/binary releases, which surely
isn't a major task?

 In addition I'd like to be able to remote debug to Embedded Linux with
 Visual Studio - which  I used to be able to do with Xamarin's Monotools
 Server before it disappeared.
 Again, you don't need to build mono to do this.  But this feature I'm sure, 
 is not free.  It's included in Xamarin Business.  They offer Visual Studio 
 support as one of the features of Xam Bus.  It allows you to do remote 
 debugging with VS running a mono app on some remote mac or linux mono machine.


If the MonoTools plugin was still available I'd be happy to pay for
it... Perhaps I may investigate Xam Bus but for now if the alternate
OpenSource plugin will do the job for me that would make me very happy :)

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] Building mono on Windows issues.

[Alex J Lennon]

On 16/10/2014 16:58, Bryan Crotaz wrote:
 What's the estimation of effort required to get mono buildable in
 windows and debuggable in VS? 6 man months? 18 man months?

 I don't have time to donate but I'd be happy to put some money in a
 pot with some of you to hire someone to work on this full time. Feels
 like a concerted full time effort would bear more fruit than
 occasional toe-dips in the water.

Bryan,

fwiw - and this is merely a view from a bystander - I don't think it
would take a lot to address the Windows build itself today.

Mono does build on Windows, but it doesn't just work as people tend to
expect nowadays. It needs some stream-lining imho with some setup script
automation or similar for newbies. There are also some missing links in
how an official Windows release is created versus using make, as we end
up with missing files on install (or I am misunderstanding  something
that needs doing, which in itself would be a documentation issue).

To me this isn't a code issue so much as an ownership and release
management issue. I recognise there is a cost to that and there has to
be an ROI for that cost to be worth bearing.

Releases are made with broken Window builds as Vincent says. So imho
it's a dead work fixing master at any given time as it will just
become broken again, although some basic setup scripting to pull down
Cygwin, dependencies, to get the installation step working and such
would help people to get going, I feel.

What's more relevant, I believe, is a maintainer who has committed to
Windows build testing and patching prior to an  offical release of Mono,
a buy-in from other release maintainers that this is worth doing (or
what's the point?), and perhaps some CI running the Mono tests in the
background.

Just my 4 cents,

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

Re: [Mono-dev] Windows builds

[Alex J Lennon]

On 16/10/2014 20:33, Bryan Crotaz wrote:
 I have a Windows CI cloud service running (Elastic Bamboo). If it
 helps get Windows development going so that I can get in and fix mono
 bugs when I find them, I'd be happy to sponsor running a nightly build
 and test of mono on a clean Windows box. Let's say for 12 months to
 start with and see where we go.

 However... I don't have time (or experience - I've tried and failed)
 to get the build running in the first place.

 If someone can get the repo to a point where there's a build script
 that runs as a single step and a separate test script which runs the
 (nunit?) tests, then I can get that set up as a nightly build and get
 it publishing the results out to the web somewhere. It can do all the
 usual which tests broke stuff and report whose changes broke it. If
 we feel flash with cash we can run it against pull requests too.

 Who's with me?

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

Re: [Mono-dev] Parallella Epiphany III

[Alex J Lennon]

On 30/08/2014 10:33, Paul Johnson wrote:
 Hi,

 I've just ordered one of these development boards from RS Components
 in the UK
 (http://uk.rs-online.com/web/p/processor-microcontroller-development-kits/8194709/).
 It's similar to the RPi in many ways, but has the far more powerful
 ARM Cortex 9 processor on it.

 I know the RPi has a version of Mono for it and that Mono is available
 for ARM in general. Is there anything I should be looking out for when
 building Mono for the Parallella with an ARM 9 or should it be
 straight forward.


There seem to be ongoing issues if you're using hardfp

e.g. https://bugzilla.xamarin.com/show_bug.cgi?id=20239

Cheers,

Alex

 The board uses the gcc toolchain and a bog standard Linux distro (not
 sure which flavour though).

 TIA

 Paul
 ___
 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 3.4 Windows Build

[Alex J Lennon]

On 03/08/2014 15:00, Edward Ned Harvey (mono) wrote:
 From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
 boun...@lists.ximian.com] On Behalf Of mika

 I notice that when clicking on the Windows build for mono 3.4 you actually
 get 3.2.3. Is this a mistake?
 Well...  3.2.3 *is* the latest windows build, but yeah you're right, it's 
 misleading that you find the windows 3.2.3 installer under the title of 
 Latest Version 3.4.0

It was the lack of a 3.4.0 download that prompted me to write this.
Perhaps it may help in the absence of an official 3.4.0 release for Windows.

http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows

Regards,

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 3.4 Windows Build

[Alex J Lennon]

On 03/08/2014 20:57, mika wrote:
 Alex, thanks for that - I had actually found your post and am currently using
 your build.

I'm glad they are of some use Mika.

As ever, if you spot problems I'd be grateful if you could feed them
back to me so I can try to keep those instructions reasonably accurate.

 Still, this is the official mono website with the official Windows build
 happening properly. It's not the correct version, and when I installed it
 some of the links didn't even work.

 Is this being done by a third-party? If so, do they need any help? I'm quite
 willing to help out if needed.


I've been asking what the process is regarding test, build and
deployment of Mono on Windows but I haven't yet managed to
connect with anybody who has been able to answer that question.

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] Mono 3.6 release?

[Alex J Lennon]

On 29/07/2014 22:59, Miguel de Icaza wrote:
 Yes, we do make a branch, and then we put it through QA.

 The we fix all the bugs that QA finds, and when we are ready we release.

 What is important is to not regress, so things will take as long as
 they need to, because we are not going to ship a version that breaks
 someone's system, just because someone is in a rush.

 If you are in a rush, use a git checkout.



Miguel,

I can't see any bugs filed against a 3.6.0 runtime here?

https://bugzilla.xamarin.com/enter_bug.cgi?product=Runtime

Where's the best place to go to form a view on outstanding Q/A bugs and
thus rough ETA to release?

Also, is building/installing on Windows tested under the Q/A process ?

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] Mono 3.6 release?

[Alex J Lennon]

On 30/07/2014 16:00, Bob Summerwill wrote:

 I'm not in a rush.   I'm just trying to coordinate release of matching
 Mono-3.6.0 RPMs for Tizen in an information vacuum.

 As Alex says, there appears to be no community-visible way to see what
 the outstanding issues with 3.6 are, and hence judge how close to
 release we may be.

 None of this is a big deal ... I was just wondering whether there
 was a community-visible process which I was unaware of other than It
 will be done when it is done?




fwiw -  Pesonally I am not interested in a fast release or a rushed
release, just a roadmap for a release so I can try to plan my time out.

i.e. When the next official release of Mono 3.6.x is available I plan to
update Yocto meta-mono support, do some testing, and possibly revisit
some build instructions for Windows if necessary.

I would also be very interested to see what is classed as a Q/A bug, and
what is tested by Q/A prior to release. 

For example, I contributed a bug report on Mono failures under ARM
hardfp some time ago and would love some feedback from somebody on what
I might be able to do to fix this.

Surely this is the type of thing Q/A would be looking to resolve prior
to a release?

Mono doesn't work on hard float abi on ARM

ref: https://bugzilla.xamarin.com/show_bug.cgi?id=7938

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] Mono 3.6 release?

[Alex J Lennon]

On 30/07/2014 16:00, Bob Summerwill wrote:

 I'm not in a rush.   I'm just trying to coordinate release of matching
 Mono-3.6.0 RPMs for Tizen in an information vacuum.

 As Alex says, there appears to be no community-visible way to see what
 the outstanding issues with 3.6 are, and hence judge how close to
 release we may be.

 None of this is a big deal ... I was just wondering whether there
 was a community-visible process which I was unaware of other than It
 will be done when it is done?




ref: https://bugzilla.xamarin.com/show_bug.cgi?id=7938

*Correction:

Mono 3.4.0 (and earlier) fails on armhf platforms with Windows Form
including textbox

ref: https://bugzilla.xamarin.com/show_bug.cgi?id=20239

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] Which SQLite?

[Alex J Lennon]

On 17/07/2014 13:33, Edward Ned Harvey (mono) wrote:
 From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
 Sent: Wednesday, July 16, 2014 5:15 AM
 To: Edward Ned Harvey (mono); mono-devel-list@lists.ximian.com

 fwiw - I am currently using System.Data.SQLite, deploying onto both
 .NET/Windows and Mono/Yocto Embedded Linux

 However I have had to rebuild System.Data.SQLite from source for Mono
 use.

 ref:
 http://system.data.sqlite.org/index.html/doc/trunk/www/build.wiki#mono
 Thanks, here is where I'm at right now:

 Mono.Data.Sqlite is reliably available on mac/linux.  And I had the brilliant 
 idea that I would install mono on windows, and then grab the 
 Mono.Data.Sqlite.dll from the mono installation, and distribute it.  However, 
 there's this:
 https://bugzilla.xamarin.com/show_bug.cgi?id=2148

 The latest windows release is mono 3.2.3, which unfortunately includes a bug 
 that kills Mono.Data.Sqlite, that was fixed in 3.2.6 or 3.2.7.

 So if a new windows build is released anytime soon with a functional 
 Mono.Data.Sqlite, it will be the obvious easiest best solution:  Just use 
 Mono.Data.Sqlite natively on systems that have mono (max/linux) and 
 distribute Mono.Data.Sqlite.dll for windows.

 Some guy on the internet managed to build a version of Mono.Data.Sqlite.dll 
 that works on windows, and has it available here:
   http://www.deltasblog.co.uk/2013/12/28/mono-data-sqlite-for-net-4-04-5/ 
   http://www.deltasblog.co.uk/downloads/Mono.Data_.Sqlite.zip

 Naturally, everyone should feel a little uncomfortable with that, but it's 
 very useful for testing purposes, and depending on who you are and what you 
 care about, it might be good enough for distribution.

 BTW, in case you didn't know:  

 Mono.Data.Sqlite and System.Data.Sqlite are *almost* completely compatible, 
 but not exactly.

 You need to global search and replace SQLite with Sqlite  ...  Meaning 
 ... All the same classes, and everything in the API is all the same, except 
 the capitalization of SQL.  By doing this simply text search/replace, I was 
 able to migrate my code from Mono.Data.Sqlite to System.Data.Sqlite and 
 vice-versa.



Hi Ned,

Thanks. That's useful background. My understanding from this list is
that 3.6.x will be released some time quite soon? My hope is that
there'll be a Windows build of that available for download too, although
I don't yet understand who owns and drives that process.

(Somewhat off topic but I am starting to look at vNext which apparently
needs 3.4.1+ so a canonical Windows binary, and indeed Linux binary
would be useful for a number of reasons).

In the meantime I did build up some Windows binaries for 3.4.0, which
you might find it interesting to test with Mono.Data.Sqlite, assuming
you don't already have your own build.

http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows

...

I'm not sure of my opinion on using System.Data.Sqlite vs
Mono.Data.Sqlite Ned.

I guess I'd start by asking - if we have System.Data.Sqlite, and it
works on Mono, then why do we need Mono.Data.Sqlite?

Wouldn't it be better to concentrate on a supporting a single build of
System.Data.Sqlite that is platform agnostic, and/or perhaps build that
into Mono if there's interest?

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] Which SQLite?

[Alex J Lennon]

On 17/07/2014 14:48, Edward Ned Harvey (mono) wrote:
 From: Alex J Lennon [mailto:ajlen...@dynamicdevices.co.uk]
 Sent: Thursday, July 17, 2014 9:12 AM
  
 I guess I'd start by asking - if we have System.Data.Sqlite, and it
 works on Mono, then why do we need Mono.Data.Sqlite?
 I don't care if I use System.Data.Sqlite or Mono.Data.Sqlite.  So far I have 
 not gotten either one of them to work, except by downloading the 
 Mono.Data.Sqlite.dll from some guy on the internet.

 But it now sounds like there are some additional possibilities to try...



OK, in that case my builds of System.Data.SQLite might be of interest -

https://www.dropbox.com/sh/v8vaxvnwq4mzhqi/AADV_qpvrSP6sAEcxZi2Za7Pa

FFx is Windows, Mono is, well... Mono ;)

Both of these, as I recall, built out of the source as per their wiki
instructions.


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] Which SQLite?

[Alex J Lennon]

On 15/07/2014 19:55, Edward Ned Harvey (mono) wrote:

 For cross-platform compatibility with mono on mac/linux, and .NET on
 windows...  What is recommended SQLite?

  

 When I add System.Data.SQLite.Core via NuGet in windows... it seems to
 be incompatible with mono...  It looks like there is SQLite built-in
 to mono via Mono.Data.SQLite, and I could easily enough do something
 like this:

 #if UNIX

 using Mono.Data.SQLite;

 #else

 using System.Data.SQLite;

 #endif

  

 But then there are some API incompatibilities, such as:

 private void InsertIntoSql(SqliteConnection dbConn)

 versus

 private void InsertIntoSql(SQLiteConnection dbConn)

  

 I noticed the existence of csharp-sqlite project...  Which would
 probably work, but no updates in over a year...

  

 I've found other people on the internet asking this same question, but
 nobody coming up with a good answer...



fwiw - I am currently using System.Data.SQLite, deploying onto both
.NET/Windows and Mono/Yocto Embedded Linux

However I have had to rebuild System.Data.SQLite from source for Mono use.

ref: http://system.data.sqlite.org/index.html/doc/trunk/www/build.wiki#mono

This works, but as a result I currently have to switch between the two
DLLs, which is something I'm hoping to address at some point.

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] MAXHINCR or MAX_HEAP_SECTS error

[Alex J Lennon]

On 07/07/2014 19:36, Brandon Perry wrote:
 You need to recompile mono from source. No idea how to do that on windows.

 Sent from a computer

This is a starting point for 3.4.0 on Windows and probably still works
for the upcoming 3.6.x in the repo,

http://www.codeproject.com/Articles/769292/How-to-build-Mono-on-Windows

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] Runtime IL Injection

[Alex Rønne Petersen]

We do not currently have any functionality that allows you to do this.

On Tue, Jul 1, 2014 at 3:46 AM, Drew Crawford d...@sealedabstract.com wrote:
 Hello folks,

 I've got a rather large program that I don't have source to. I believe it 
 runs Mono 3.5.

 I'm trying to modify the behavior of this program; specifically, I'm trying 
 to replace one of its classes. Normally this would be a pretty 
 straightforward Mono.Cecil operation, but it turns out the program verifies 
 its on-disk representation at startup in a way that is difficult to defeat.

 I can, however, convince the program to load an arbitrary managed DLL, so 
 this has got me thinking about the possibility of doing run-time manipulation 
 and code injection of the process using the DLL as an entrypoint. I have seen 
 some code samples of this online for .NET but I can't seem to find anyone 
 doing this for Mono.

 Can anyone point me in the right direction?

 Drew


 ___
 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] Debian CI PPA for Ubuntu/Debian

[Alex J Lennon]

On 16/06/2014 16:13, Chris Tacke wrote:

 Agreed.  My major pain point with the distro right now is in CI.  I'm
 using Jenkins on a Windows machine to build our C# application
 products and installers for both Windows and Linux platforms.  I have
 it all working, including generating tarballs for Linux.  The one
 problem is that I don't have it pulling and rebuilding Mono, because
 my steps for that are done on a separate Ubuntu VM.  That makes it a
 manual (i.e. not done very often because I'm too busy) process.  It
 also seems inefficient because anyone else looking for a scaled down
 (we customize what goes into the build to exclude winforms and a lot
 of crusft that simply isn't needed for a headless embedded device),
 586 device like the Intel Galileo dev system is unlikely to ever find
 our Mono tarball on our public FTP.

  


Chris,

I've been wanting to put together a Mono build variant for Yocto
meta-mono for just such headless devices.

Could you possibly point me to the customisations you do for e.g.
Galileo as that sounds like an excellent starting point?

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] Still seeking contractor to adding Tizen support to Mono

[Alex Rønne Petersen]

Yes, http://monojenkins.cloudapp.net/ is what is used to test the
major projects under the Mono org on Linux, and also to test pull
requests.

We will soon be changing the setup there to accommodate
multi-configuration builds (e.g. x86, amd64, linux, os x, ...) so if
you have machines you'd like to contribute, that can definitely be
arranged.

Note that for each platform, we'd need 4 machines at minimum to be
able to keep up on busy days. The Small (A1) Azure tier seems to work
well enough for this purpose.

On Sat, Jun 14, 2014 at 12:46 AM, Bob Summerwill b...@summerwill.net wrote:

 It looks like it might be https://github.com/alexrp (Alex Rønne Petersen).
 CC-ed.


 On Fri, Jun 13, 2014 at 3:18 PM, Sergey Zhukov s...@ngs.ru wrote:

 Also I've found this link, don't know who maintains it

 http://monojenkins.cloudapp.net/

 On Fri, 2014-06-13 at 15:07 -0700, Bob Summerwill wrote:
  Right, so maybe this is more a case of the website not getting enough
  love?
 
 
  We should still have automation independent of Xamarin, though.
  Mono != Xamarin.
 
 
 
  Cheers,
  Bob
 
 
 
  On Fri, Jun 13, 2014 at 3:04 PM, Sergey Zhukov s...@ngs.ru wrote:
  AFAIK, Xamarin uses this for mono (it's working link)
  https://wrench.mono-project.com/Wrench/
 
  also I've seen travis scripts in the mono tree some time ago
  (some of
  them or even all were removed)
 
 
  On Fri, 2014-06-13 at 14:47 -0700, Bob Summerwill wrote:
  
   But there is no centrally maintained automated build
  instance right
   now, correct?Or incorrect?
  
  
  
  
  
   On Fri, Jun 13, 2014 at 2:44 PM, Sergey Zhukov s...@ngs.ru
  wrote:
   Anybody can use Travis.CI or drone.io as build
  system. They
   can run
   tests on different platforms. For example, here the
  post how
   to run
   tests on ARM platform using Travis.CI.
  
 
  http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html
  
   Also Travis.CI has built-in support for OSX and
  Ubuntu
   operating
   systems. So it's possible to write script, which
  will test
   mono across
   several tizen platforms the only bad thing could be
  a build
   time
   limitation.
  
  
   On Fri, 2014-06-13 at 14:27 -0700, Bob Summerwill
  wrote:
   
Please could somebody confirm that there is no
  existing Mono
   project
automation?
   
Outside of whatever Xamarin do for their own
  needs, I mean?
   Thanks!
   
   
Cheers,
Bob
   
   
   
   
On Fri, Jun 13, 2014 at 2:21 PM, Sergey Zhukov
  s...@ngs.ru
   wrote:
They all do the same things, the only
  difference
   what I see is
a pricing
and limitations for cloud-based
  jenkins/drone/travis
   (don't
know is
there a cloud-based TeamCity services).
  CloudBees
   based on
Jenkins has
100 min/month for free projects while
  drone.io does
   not have
monthly
limitations for open source. But drone.io
  has 30-min
compile-time
limitation which they say can be removed.
  Travis.CI
   site says
that there
are no limitation for open source
  projects, but
   somewhere I
saw that it
has 1 hour limit to compile time.
   
For open-source project it's a good to
  have ability
   to avoid
thinking
about additional infrastructure for CI,
  its cost and
maintenance. So in
this case using cloud-based travis or
  drone can help
   devs to
concentrate
on software itself without spending their
  time and
   money to
supporting

Re: [Mono-dev] Still seeking contractor to adding Tizen support to Mono

[Alex Rønne Petersen]

Nothing much has to be done on slave VMs other than installing
necessary software to build/run Mono. Jenkins connects to slaves via
plain old SSH.

Note that I need an account with sudo access on all VMs hooked up to
http://monojenkins.cloudapp.net/.

On Sat, Jun 14, 2014 at 9:16 AM, Bob Summerwill b...@summerwill.net wrote:
 Great - so for the Tizen test-cases, Damien should probably get an
 equivalent set of automation running on an Azure VM, and then we should work
 out how to incorporate that VM into your Jenkins instance?


 Cheers,
 Bob


 On Sat, Jun 14, 2014 at 12:07 AM, Alex Rønne Petersen a...@alexrp.com
 wrote:

 Xamarin pays for the current infrastructure and the upcoming x86 VMs
 we're going to add to it. That doesn't stop anyone from contributing
 more infrastructure.

 The build automation inside Xamarin for our commercial products is
 based on Wrench.

 On Sat, Jun 14, 2014 at 9:03 AM, Bob Summerwill b...@summerwill.net
 wrote:
  Thanks for the information, Alex.
 
  Is that Xamarin-funded infrastructure?Or something which you set up
  outside of Xamarin prior to your employment?
 
  If there is some way in which we can ensure that non-Xamarin-employees
  working on Mono can contribute to that automation setup, that would be
  splendid.
 
 
  Cheers,
  Bob
 
 
  On Fri, Jun 13, 2014 at 11:23 PM, Alex Rønne Petersen a...@alexrp.com
  wrote:
 
  Yes, http://monojenkins.cloudapp.net/ is what is used to test the
  major projects under the Mono org on Linux, and also to test pull
  requests.
 
  We will soon be changing the setup there to accommodate
  multi-configuration builds (e.g. x86, amd64, linux, os x, ...) so if
  you have machines you'd like to contribute, that can definitely be
  arranged.
 
  Note that for each platform, we'd need 4 machines at minimum to be
  able to keep up on busy days. The Small (A1) Azure tier seems to work
  well enough for this purpose.
 
  On Sat, Jun 14, 2014 at 12:46 AM, Bob Summerwill b...@summerwill.net
  wrote:
  
   It looks like it might be https://github.com/alexrp (Alex Rønne
   Petersen).
   CC-ed.
  
  
   On Fri, Jun 13, 2014 at 3:18 PM, Sergey Zhukov s...@ngs.ru wrote:
  
   Also I've found this link, don't know who maintains it
  
   http://monojenkins.cloudapp.net/
  
   On Fri, 2014-06-13 at 15:07 -0700, Bob Summerwill wrote:
Right, so maybe this is more a case of the website not getting
enough
love?
   
   
We should still have automation independent of Xamarin, though.
Mono != Xamarin.
   
   
   
Cheers,
Bob
   
   
   
On Fri, Jun 13, 2014 at 3:04 PM, Sergey Zhukov s...@ngs.ru wrote:
AFAIK, Xamarin uses this for mono (it's working link)
https://wrench.mono-project.com/Wrench/
   
also I've seen travis scripts in the mono tree some time
ago
(some of
them or even all were removed)
   
   
On Fri, 2014-06-13 at 14:47 -0700, Bob Summerwill wrote:

 But there is no centrally maintained automated build
instance right
 now, correct?Or incorrect?





 On Fri, Jun 13, 2014 at 2:44 PM, Sergey Zhukov
s...@ngs.ru
wrote:
 Anybody can use Travis.CI or drone.io as build
system. They
 can run
 tests on different platforms. For example, here
the
post how
 to run
 tests on ARM platform using Travis.CI.

   
http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html

 Also Travis.CI has built-in support for OSX and
Ubuntu
 operating
 systems. So it's possible to write script, which
will test
 mono across
 several tizen platforms the only bad thing could
be
a build
 time
 limitation.


 On Fri, 2014-06-13 at 14:27 -0700, Bob
Summerwill
wrote:
 
  Please could somebody confirm that there is no
existing Mono
 project
  automation?
 
  Outside of whatever Xamarin do for their own
needs, I mean?
 Thanks!
 
 
  Cheers,
  Bob
 
 
 
 
  On Fri, Jun 13, 2014 at 2:21 PM, Sergey Zhukov
s...@ngs.ru
 wrote:
  They all do the same things, the only
difference
 what I see

Re: [Mono-dev] Still seeking contractor to adding Tizen support to Mono

[Alex Rønne Petersen]

Always running.

On Sat, Jun 14, 2014 at 9:37 AM, Daniel Lo Nigro li...@dan.cx wrote:
 Do the build agents spin up when they're needed, or are they running all the
 time?


 On Fri, Jun 13, 2014 at 11:23 PM, Alex Rønne Petersen a...@alexrp.com
 wrote:

 Yes, http://monojenkins.cloudapp.net/ is what is used to test the
 major projects under the Mono org on Linux, and also to test pull
 requests.

 We will soon be changing the setup there to accommodate
 multi-configuration builds (e.g. x86, amd64, linux, os x, ...) so if
 you have machines you'd like to contribute, that can definitely be
 arranged.

 Note that for each platform, we'd need 4 machines at minimum to be
 able to keep up on busy days. The Small (A1) Azure tier seems to work
 well enough for this purpose.

 On Sat, Jun 14, 2014 at 12:46 AM, Bob Summerwill b...@summerwill.net
 wrote:
 
  It looks like it might be https://github.com/alexrp (Alex Rønne
  Petersen).
  CC-ed.
 
 
  On Fri, Jun 13, 2014 at 3:18 PM, Sergey Zhukov s...@ngs.ru wrote:
 
  Also I've found this link, don't know who maintains it
 
  http://monojenkins.cloudapp.net/
 
  On Fri, 2014-06-13 at 15:07 -0700, Bob Summerwill wrote:
   Right, so maybe this is more a case of the website not getting enough
   love?
  
  
   We should still have automation independent of Xamarin, though.
   Mono != Xamarin.
  
  
  
   Cheers,
   Bob
  
  
  
   On Fri, Jun 13, 2014 at 3:04 PM, Sergey Zhukov s...@ngs.ru wrote:
   AFAIK, Xamarin uses this for mono (it's working link)
   https://wrench.mono-project.com/Wrench/
  
   also I've seen travis scripts in the mono tree some time ago
   (some of
   them or even all were removed)
  
  
   On Fri, 2014-06-13 at 14:47 -0700, Bob Summerwill wrote:
   
But there is no centrally maintained automated build
   instance right
now, correct?Or incorrect?
   
   
   
   
   
On Fri, Jun 13, 2014 at 2:44 PM, Sergey Zhukov s...@ngs.ru
   wrote:
Anybody can use Travis.CI or drone.io as build
   system. They
can run
tests on different platforms. For example, here the
   post how
to run
tests on ARM platform using Travis.CI.
   
  
   http://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html
   
Also Travis.CI has built-in support for OSX and
   Ubuntu
operating
systems. So it's possible to write script, which
   will test
mono across
several tizen platforms the only bad thing could be
   a build
time
limitation.
   
   
On Fri, 2014-06-13 at 14:27 -0700, Bob Summerwill
   wrote:

 Please could somebody confirm that there is no
   existing Mono
project
 automation?

 Outside of whatever Xamarin do for their own
   needs, I mean?
Thanks!


 Cheers,
 Bob




 On Fri, Jun 13, 2014 at 2:21 PM, Sergey Zhukov
   s...@ngs.ru
wrote:
 They all do the same things, the only
   difference
what I see is
 a pricing
 and limitations for cloud-based
   jenkins/drone/travis
(don't
 know is
 there a cloud-based TeamCity services).
   CloudBees
based on
 Jenkins has
 100 min/month for free projects while
   drone.io does
not have
 monthly
 limitations for open source. But drone.io
   has 30-min
 compile-time
 limitation which they say can be removed.
   Travis.CI
site says
 that there
 are no limitation for open source
   projects, but
somewhere I
 saw that it
 has 1 hour limit to compile time.

 For open-source project it's a good to
   have ability
to avoid
 thinking
 about additional infrastructure for CI

Re: [Mono-dev] Still seeking contractor to adding Tizen support to Mono

[Alex Rønne Petersen]

The configure.ac change is arguably not something that should be
upstreamed, fwiw. You should probably instead do:

$ CXX=gcc-c++ ./autogen.sh ...

Or symlink g++ to gcc-c++. Or tell the Tizen engineers to fix their stuff. ;)

On Fri, Jun 13, 2014 at 5:36 PM, xplicit s...@ngs.ru wrote:
 I was able to compile and run mono on tizen(x86) out of the box. Only very
 small change is needed in configure.ac to compile and run mono successfully.

 I even compiled my mono web-server HyperFastCgi v0.4
 (https://github.com/xplicit/HyperFastCgi) and run it behind nginx on the
 Tizen machine with ServiceStack-hosted hello, World! web-application
 (front-end nginx is located on the Ubuntu machine and sends requests to
 tizen machine). Seems that all works fine, I've got Hello, World! message
 in my browser.

 Here are the the sequence of commands I had to do to compile mono
 https://gist.github.com/xplicit/2f8444afe162ac69a5f7
 Here are the change for configure.ac
 https://gist.github.com/xplicit/f3d5d08b3eac836fae38
 I use tizen_20140415.5_ivi-release-mbr-i586-sdb.raw image.



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/Still-seeking-contractor-to-adding-Tizen-support-to-Mono-tp4663022p4663077.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] Still seeking contractor to adding Tizen support to Mono

[Alex Rønne Petersen]

We could probably do something to only require a C++ compiler when we
build with LLVM support. Patches welcome! ;)

On Fri, Jun 13, 2014 at 8:04 PM, Sergey Zhukov s...@ngs.ru wrote:
 You're right setting the CXX variable is the most preferable way to
 compile. By the way, why mono always requires g++ compiler?

 find -name *.cpp

 ./libgc/gc_cpp.cpp
 ./mono/mini/mini-llvm-cpp.cpp
 ./mono/tests/mixed-mode/MixedModeLibrary/MixedModeLibrary.cpp
 ./mono/tests/mixed-mode/MixedModeLibrary/NativeApp.cpp
 ./mono/tests/mixed-mode/MixedModeApp/MixedModeApp.cpp
 ./mono/tests/mixed-mode/PureMsvcrtApp/PureMsvcrtApp.cpp
 ./mono/tests/mixed-mode/MixedModeMsvcrtApp/MixedModeMsvcrtApp.cpp

 tests/mixed-mode are run in windows environment only
 gc_cpp.cpp and gc_cpp.cc look like orphaned files which were added 10
 years ago and have never changed since that

 only mini-llvm-cpp.cpp requires C++ compiler really but if mono is
 building without llvm support why it asks for g++?

 Maybe I missed something.

 On Fri, 2014-06-13 at 19:08 +0200, Alex Rønne Petersen wrote:
 The configure.ac change is arguably not something that should be
 upstreamed, fwiw. You should probably instead do:

 $ CXX=gcc-c++ ./autogen.sh ...

 Or symlink g++ to gcc-c++. Or tell the Tizen engineers to fix their stuff. ;)

 On Fri, Jun 13, 2014 at 5:36 PM, xplicit s...@ngs.ru wrote:
  I was able to compile and run mono on tizen(x86) out of the box. Only very
  small change is needed in configure.ac to compile and run mono 
  successfully.
 
  I even compiled my mono web-server HyperFastCgi v0.4
  (https://github.com/xplicit/HyperFastCgi) and run it behind nginx on the
  Tizen machine with ServiceStack-hosted hello, World! web-application
  (front-end nginx is located on the Ubuntu machine and sends requests to
  tizen machine). Seems that all works fine, I've got Hello, World! message
  in my browser.
 
  Here are the the sequence of commands I had to do to compile mono
  https://gist.github.com/xplicit/2f8444afe162ac69a5f7
  Here are the change for configure.ac
  https://gist.github.com/xplicit/f3d5d08b3eac836fae38
  I use tizen_20140415.5_ivi-release-mbr-i586-sdb.raw image.
 
 
 
  --
  View this message in context: 
  http://mono.1490590.n4.nabble.com/Still-seeking-contractor-to-adding-Tizen-support-to-Mono-tp4663022p4663077.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] field pointer and garbage collection

[Alex Rønne Petersen]

As with any pointer updating during GC, this can only be done with
precise type and liveness information. If any pointer to an object --
whether base or interior -- exists in CPU registers or on the stack,
the object is considered pinned and will not be moved. The exception
to this is when you run SGen with precise stack scanning (which is
somewhat experimental) - in this mode, SGen knows which pointers are
where on the stack and will update accordingly.

Note that CIL only allows interior pointers on the stack - you can't
take an interior pointer and store it on the heap or anything like
that.

On Wed, Jun 11, 2014 at 12:08 PM, serus fabian.na...@gmail.com wrote:
 Dear Devs,

 I would appreciate if someone could make sense out of the following:

 When a field of an object is accessed in C#, the IL code is LDFLD.
 Intuitively, I would assume that the JIT compiler would transform LDFLD into
 the assembler version of the following C code:

 int A = *(int*)(ptr + 24);   // ptr is pointer to object, accessed field is
 int and 24 is offset of field in object

 Now assuming this was true, at some point (ptr + 24) would reside in a CPU
 register, if execution is intercepted by garbage collection and the object
 moved somewhere, this pointer would have to be updated as well, which sounds
 impossible as the forward pointer is installed at the beginning of the
 object and the pointer points to somewhere inside the object.

 What part of my assumption is wrong? How is this solved?



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040.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] field pointer and garbage collection

[Alex Rønne Petersen]

There are 3 relevant functions for this:

1. sgen_ptr_in_nursery ()
2. sgen_safe_get_object_size ()
3. sgen_ptr_is_in_los ()

grep for those in mono/metadata to see how they work and how they're used.

On Wed, Jun 11, 2014 at 2:13 PM, serus fabian.na...@gmail.com wrote:
 Thanks for the info.

 From what I understood, a conventional collector would treat all values
 found on stack / registers as potential pointers. To pin the object, it
 needs to 1) find out if the pointer is pointing to an actual object or to a
 random memory address; and 2) find the base address of the object in case it
 is an interior pointer.

 How does Mono test for (1) and is the assumption that (2) is computed using
 the alignment of sgen-blocks and their slot size correct?



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040p4663042.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] field pointer and garbage collection

[Alex Rønne Petersen]

Well, if you have a non-null object pointer and !sgen_ptr_in_nursery
(obj)  !sgen_los_is_valid_object (obj) it must by necessity be in
the major heap.

On Wed, Jun 11, 2014 at 3:45 PM, serus fabian.na...@gmail.com wrote:
 Thanks for the hints. I looked through all three and while 1. and 3. solve
 (1), they do not deal with the case I am interested in which is if the
 object resides in the major heap (assuming a non-fixed major heap). Would
 you happen to also have pointers for that case?



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040p4663044.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] field pointer and garbage collection

[Alex Rønne Petersen]

Amendment: That being said, if you're actually writing new code,
prefer to check !sgen_ptr_in_nursery (obj) 
sgen_object_safe_get_size (obj) = SGEN_MAX_SMALL_OBJ_SIZE. That's
generally better than sgen_los_is_valid_object () which performs a
pass over all LOS objects.

On Wed, Jun 11, 2014 at 3:55 PM, Alex Rønne Petersen a...@alexrp.com wrote:
 Well, if you have a non-null object pointer and !sgen_ptr_in_nursery
 (obj)  !sgen_los_is_valid_object (obj) it must by necessity be in
 the major heap.

 On Wed, Jun 11, 2014 at 3:45 PM, serus fabian.na...@gmail.com wrote:
 Thanks for the hints. I looked through all three and while 1. and 3. solve
 (1), they do not deal with the case I am interested in which is if the
 object resides in the major heap (assuming a non-fixed major heap). Would
 you happen to also have pointers for that case?



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040p4663044.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] field pointer and garbage collection

[Alex Rønne Petersen]

To know if an arbitrary pointer is a GC'd pointer, conceptually you need to ask:

1. sgen_ptr_in_nursery (ptr) ?
2. major_collector.is_valid_object (ptr) ?
3. sgen_ptr_is_in_los (ptr, base) ?

If all of these are false, you know it's just some random pointer you
don't care about.

On Wed, Jun 11, 2014 at 4:03 PM, serus fabian.na...@gmail.com wrote:
 I think this is the part that I do not understand. Can't the value on the
 stack (assuming the stack is being scanned conventionally and the value is
 not actually a pointer but a long) point to unallocated memory, or to memory
 that is allocated but not for objects but some runtime data structure?



 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040p4663047.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-dev] Mono maintainers: Please publicize your membership on the GitHub organization

[Alex Rønne Petersen]

Hi,

This is necessary so that Jenkins [0] can see your membership and test
any pull requests you open automatically.

You can publicize your membership here: https://github.com/orgs/mono/members

Regards,
Alex

[0] http://monojenkins.cloudapp.net/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono maintainers: Please publicize your membership on the GitHub organization

[Alex Rønne Petersen]

OK. This email was meant for people who are maintaining Mono, i.e.
people who are in the mono organization on GitHub.

On Tue, Jun 10, 2014 at 8:52 PM, Chris Barr ch...@nabor.com wrote:
 I don't want to do a pull request for Mono.

 Chris Barr
 Senior Application Developer
 Naples Area Board of REALTORS® and
 Association of Real Estate Professionals, Inc.
 1455 Pine Ridge Road
 Naples, FL 34109-2139
 Phone: 239-597-1666
 Email: ch...@nabor.com

 ***
 CONFIDENTIALITY NOTE:
 This electronic mail transmission may contain confidential or privileged 
 information. If you believe that you have received this message in error,  
 please notify the sender by reply transmission and delete the message without 
 copying or disclosing it.  All personal messages express views solely of the 
 sender, which are not to be attributed to the Naples Area Board of Realtors.
 **



 -Original Message-
 From: mono-devel-list-boun...@lists.ximian.com 
 [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Alex Rønne 
 Petersen
 Sent: Tuesday, June 10, 2014 2:52 PM
 To: mono-devel-list@lists.ximian.com
 Subject: [Mono-dev] Mono maintainers: Please publicize your membership on the 
 GitHub organization

 Hi,

 This is necessary so that Jenkins [0] can see your membership and test any 
 pull requests you open automatically.

 You can publicize your membership here: https://github.com/orgs/mono/members

 Regards,
 Alex

 [0] http://monojenkins.cloudapp.net/
 ___
 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] Question about adding opcodes

[Alex Rønne Petersen]

Hi,

On Mon, Jun 2, 2014 at 12:24 AM, Steven Bluen sbluen...@yahoo.com wrote:
 Thanks for your response. Would you also care to explain something else 
 please? Because I'm not sure why when I place printf calls inside the switch 
 statement, when I run a program with Mono, all of the output is placed at the 
 beginning, before anything else is printed to the console.

Where did you place the printfs? mono_method_to_ir () is one of the
first things that run when a method is JITed.


 On another note, is there an easy way to read the preprocessor macros when 
 coding or debugging Mono's functions? Because they slow down my understanding 
 of the code by being skipped in the debugger and because my IDE, Eclipse, 
 can't handle some of them very well under its default settings.

I don't know of any easy way to do this. You could look at the
generated config.h, `gcc -dM -E -  /dev/null`, the
mini-{x86,arm,...}.h arch header for your platform, etc.


 Steven Bluen
 
 On Sun, 6/1/14, Alex Rønne Petersen a...@alexrp.com wrote:

  Subject: Re: [Mono-dev] Question about adding opcodes
  To: Steven Bluen sbluen...@yahoo.com
  Cc: mono-devel-list@lists.ximian.com
  Date: Sunday, June 1, 2014, 6:16 AM

  Hi,

  On Sun, Jun 1, 2014 at 2:58 PM, Steven Bluen sbluen...@yahoo.com
  wrote:
   Hello,
  
   I am trying to add an opcode to Mono's JIT compiler and
  its interpreter to allow Mono to compile and run
  applications so that I can make a frequently used operation
  in a C# program run faster. To keep things simple and avoid
  the need for parsing, this opcode is invoked through dynamic
  methods.

  Adding it to the interpreter is not worth it. The
  interpreter is
  bitrotted to the point of obscurity.

  
   I am able to get Mono's JIT compiler to stop at a
  breakpoint in mono/mini/method-to-ir.c at the point where
  the opcode is added to the method's intermediate
  representation. However, it would be much appreciated if
  someone could let me know which component, source code file,
  or function of Mono's interpreter is responsible for
  interpreting the instructions that form the body of a
  dynamic method.

  They're parsed like any other method (from an on-disk CIL
  assembly).
  This parsing is based on the tables in mono/cil/ and is done
  in
  mono_method_to_ir () in mono/mini/method-to-ir.c. The CIL
  stream is
  simply interpreted directly. If you're adding a new CIL
  opcode
  (different from an IR opcode), add it in
  mono/cil/cil-opcodes.xml and
  handle it in mono_method_to_ir (). If you plan to also add
  an IR
  opcode (or several), you may want to consider intercepting
  an
  intrinsic method call instead of using a custom CIL opcode.
  This'll be
  portable to MS.NET as MS.NET will then just use the managed
  fallback.

  Regards,
  Alex

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