Re: [Mono-dev] Race condition in named mutex

[Miguel de Icaza]

Hello Mikhail,

Please file a bug report so we can properly track this issue.

http://bugzilla.xamarin.com

Miguel

On Thu, Jun 16, 2016 at 5:04 AM, Mikhail Filippov 
wrote:

> I found problem in Mono in named mutex I have repro program:
> using System;
> using System.Threading;
>
> namespace Crasher
> {
> internal class Program
> {
> public static void Main (string[] args)
> {
> var a = "";
> for (var i = 0; i < 100; i++)
> {
> new Thread(Crasher).Start();
> }
> Console.WriteLine(a);
> Console.ReadLine();
> }
>
> private static void Crasher(){
> var rnd = new Random();
> while (true)
> {
> Thread.Sleep(rnd.Next(100, 1));
> using (var mutex = new Mutex(false,
> "Global\\TEST"))
> {
> var owner = false;
> try
> {
> owner =
> mutex.WaitOne(TimeSpan.FromMinutes(1));
> }
> finally
> {
> if (owner)
> {
>
> mutex.ReleaseMutex();
> }
> }
> Console.WriteLine ("PING");
> }
> Thread.Sleep(rnd.Next(100, 1));
> }
> }
> }
> }
>
> It program crached mono after few seconds.
> I see namedmutex_create and namedmutex_release use different locks.
> First time I found it problem when run Nuget client on mono.
> I verify repro on mono 4.2, 4.4, and master.
> Anybody can help me resolve this issue?
> On 4.4.0 native crash:
> namedmutex_create: error creating mutex handle
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> PING
> _wapi_handle_unref_full: Attempting to unref unused handle 0x4e0
> PING
> PING
> namedmutex_create: error creating mutex handle
> PING
> PING
> PING
> PING
> PING
> PING
> _wapi_handle_ref: Attempting to ref unused handle 0x4e3
> * Assertion at ../../mono/utils/mono-os-mutex.h:135, condition `res !=
> EINVAL' not met
>
> Stacktrace:
>
>   at  <0x>
>   at (wrapper managed-to-native)
> System.Threading.WaitHandle.WaitOne_internal
> (System.Threading.WaitHandle,intptr,int,bool) <0x00073>
>   at System.Threading.WaitHandle.WaitOne (System.TimeSpan,bool) <0x0009b>
>   at System.Threading.WaitHandle.WaitOne (System.TimeSpan) <0x0001d>
>   at Crasher.Program.Crasher () <0x000f0>
>   at System.Threading.ThreadHelper.ThreadStart_Context (object) <0x0009a>
>   at System.Threading.ExecutionContext.RunInternal
> (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
> <0x001c6>
>   at System.Threading.ExecutionContext.Run
> (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
> <0x00020>
>   at System.Threading.ExecutionContext.Run
> (System.Threading.ExecutionContext,System.Threading.ContextCallback,object)
> <0x00059>
>   at System.Threading.ThreadHelper.ThreadStart () <0x0002e>
>   at (wrapper runtime-invoke) object.runtime_invoke_void__this__
> (object,intptr,intptr,intptr) <0x000e0>
>
> Native stacktrace:
>
> 0   mono0x000103f9b0ca
> mono_handle_native_sigsegv + 271
> 1   libsystem_platform.dylib0x7fff854c252a
> _sigtramp + 26
> 2   mono0x0001042036a4 tmp_dir
> + 5316
> 3   libsystem_c.dylib   0x7fff935536e7 abort +
> 129
> 4   mono0x00010410d1f0
> monoeg_g_log + 0
> 5   mono0x00010410d175
> monoeg_g_logv + 83
> 6   mono0x00010410d31a
> monoeg_assertion_message + 143
> 7   mono0x0001040e453d
> _wapi_handle_timedwait_signal_handle + 1153
> 8   mono0x0001040f4aec
> wapi_WaitForSingleObjectEx + 606
> 9   mono0x00010406c01c
> mono_wait_uninterrupted + 130
> 10  mono0x00010406c1ff
> ves_icall_System_Threading_WaitHandle_WaitOne_internal + 73
> 11  ??? 0x000108130b54 0x0 +
> 

Re: [Mono-dev] Mono crashes on copying of running profiler

[Miguel de Icaza]

You should not do that.

You are replacing the code behind the scenes.   You might as well poke
random values in memory.

On Unix, if you really cannot resist the urge of replacing a binary that is
in active use, you must first delete the file, then copy over.

On Sun, May 29, 2016 at 9:18 AM, Greg Young  wrote:

> Mono JIT compiler version 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16
> 13:19:08 UTC 2016)
>
> ~/src/EventStore on  release-v3.6.0! ⌚ 11:09:02
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: Ubuntu 15.10
> Release: 15.10
> Codename: wily
>
>
> When running mono with a profiler running and I copy a new version of
> the profiler over the old version it immediately crashes the mono
> process.
>
> I can't see anything at all in my code which would cause this (but I
> don't rule out that its a possibility).
>
> Any ideas?
>
> 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] Unexpected Delays in P/Invoke

[Miguel de Icaza]

Time the C calls, it is possible that close is flushing the data and is not
returning until that happebs
On Sat, Apr 23, 2016 at 9:33 AM Jason Curl  wrote:

> I've tested the latest snapshot of Mono and the problem remains:
>
> Mono JIT compiler version 4.5.0 (Nightly 4.5.0.421/c5789eb Thu Mar 24
> 18:42:59 UTC 2016)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
>  TLS:   __thread
>  SIGSEGV:   altstack
>  Notifications: epoll
>  Architecture:  amd64
>  Disabled:  none
>  Misc:  softdebug
>  LLVM:  supported, not enabled.
>  GC:sgen
>
> nUnit-gui now works properly (4.2.3.4 would hang when trying to close)
> and using MONO debug variables (MONO_LOG_MASK="dll";
> MONO_LOG_LEVEL="debug", I can see that the method "serial_close" is
> called at the correct time, but I don't see any other activity while
> blocked.
>
> Mono: DllImport searching in: 'nserial' ('libnserial.so').
> Mono: Searching for 'serial_close'.
> Mono: Probing 'serial_close'.
> Mono: Found as 'serial_close'.
>
> PAUSE FOR 6 SECONDS
>
> Mono: DllImport searching in: 'nserial' ('libnserial.so').
> Mono: Searching for 'serial_read'.
> Mono: Probing 'serial_read'.
> Mono: Found as 'serial_read'.
> Mono: DllImport searching in: 'nserial' ('libnserial.so').
> Mono: Searching for 'serial_terminate'.
> Mono: Probing 'serial_terminate'.
> Mono: Found as 'serial_terminate'.
>
> Any help is appreciated.
>
> On 22.04.2016 23:37, Jason Curl wrote:
> > I've generally got my library working
> > (github.com/jcurl/serialportstream) on Linux with Mono 4.2.3.4 from
> > the Xamarin repositories on Ubuntu 16.04, with one small problem.
> >
> > One new test case (ClosedWhenBlocked) takes 6923ms for a simple
> > close() function using marshalling, where the function in C only needs
> > 22ms. It's called twice (there's two instances), the second is
> > effectively instantaneous. On my machine, the issue is 100%
> > reproducible. My C code and .NET is OK (as far as I can tell) and
> > appears to be some blocking behaviour in the Marshalling code of the
> > .NET framework. How can I debug further if it's me or .NET?
> >
> > Note, I can't compare on Windows as it's Linux specific code.
> >
> >
> > Closing serialSource
> > ...
> > --> serial_close(140601190288768)   => 0x7FE044008D80
> > ...
> > -->  serial_close(140601190288768) took 6916 ms
> > IO.Ports.SerialPortStream Verbose: 0 : -->
> > serial_close(140601190288768) took 6916 ms
> > ...
> > Closed serialSource after 6923 ms
> > ...
> > --> serial_close(140601190278688)  => 0x7FE044006620
> > -->  serial_close(140601190278688) took 0 ms
> > -->  serial_close(140601190278688) took 0 ms
> >
> >
> >
> > The code in question is
> > [DllImport("nserial", EntryPoint="serial_close",
> > SetLastError=true)]
> > private static extern int nserial_close(IntPtr handle);
> > public int serial_close(IntPtr handle)
> > {
> > System.Diagnostics.Stopwatch sw = new
> > System.Diagnostics.Stopwatch();
> > sw.Start();
> > Console.WriteLine("--> serial_close({0})", handle);
> > int result = nserial_close(handle);
> > Console.WriteLine("-->  serial_close({0}) took {1} ms",
> > handle, sw.ElapsedMilliseconds);
> > errno = Marshal.GetLastWin32Error();
> > Console.WriteLine("-->  serial_close({0}) took {1} ms",
> > handle, sw.ElapsedMilliseconds);
> > return result;
> > }
> >
> > I added diagnostics to my C code to write performance data to disk and
> > it is:
> > c: serial_close(handle=0x7fe044008d80)
> > c: serial_close(handle=0x7fe044008d80) fd=4
> > c: serial_close(handle=0x7fe044008d80) flushbuffer elapsed=0,005000
> > c: serial_close(handle=0x7fe044008d80) close(prfd) elapsed=0,028000
> > c: serial_close(handle=0x7fe044008d80) close(pwfd) elapsed=0,046000
> > c: serial_close(handle=0x7fe044008d80) close(fd) elapsed=21,53
> > c: serial_close(handle=0x7fe044006620)
> > c: serial_close(handle=0x7fe044006620) fd=14
> > c: serial_close(handle=0x7fe044006620) flushbuffer elapsed=0,004000
> > c: serial_close(handle=0x7fe044006620) close(prfd) elapsed=0,048000
> > c: serial_close(handle=0x7fe044006620) close(pwfd) elapsed=0,062000
> > c: serial_close(handle=0x7fe044006620) close(fd) elapsed=0,066000
> >
> > ___
> > 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] Running Mono on 32bits-big endian PowerPC

[Miguel de Icaza]

>
>
> - Does MONO_THREADS_PER_CPU=1 control the number of threads created by
> sgen-gc implementation ? It does not seems so on my side.
>

This has not relationship to the GC, just to the system thread pool.

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

Re: [Mono-dev] Renew DHCP based IP address

[Miguel de Icaza]

No

On Tue, Mar 1, 2016 at 8:33 AM, techi eth  wrote:

> Hi,
>
> Is it possible to renew DHCP based IP address using System.Net.
>
> 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

Re: [Mono-dev] Unix Signal in mono

[Miguel de Icaza]

Hey,

My bad, I should have said "kill", not "signal" to send messages to other
processes.

Miguel.


On Mon, Feb 29, 2016 at 1:33 PM, Jonathan Pryor  wrote:

> On Feb 29, 2016, at 8:18 AM, techi eth  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.
>
> Don’t use Stdlib.signal() to setup signal handlers. It’s [Obsolete]
> because it isn’t signal safe, i.e. it isn’t safe to invoke managed code
> from within a signal handler.
>
> Instead, to receive a notification of signal delivery, you should use
> UnixSignal:
>
> http://www.jprl.com/Blog/archive/development/mono/2008/Feb-08.html
> http://docs.go-mono.com/?link=T%3aMono.Unix.UnixSignal
> https://gist.github.com/jonpryor/1555261
>
> To *send* a signal, use Syscall.kill().
>
>  - Jon
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Unix Signal in mono

[Miguel de Icaza]

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

Re: [Mono-list] WCF and Named Pipes on OS X

[Miguel de Icaza]

Hello,

We do not support named pipes in Mono.

Named objects were a feature that was supported on earlier versions of
Mono, but emulating them without kernel support introduced more trouble and
pain than it was worth.

So we removed it, and the code that supported it has been removed as well.



On Thu, Dec 3, 2015 at 7:00 AM, Jonathan Mitchell 
wrote:

> Hi
>
> I need some cross platform IPC.
> Does Mono WCF support named pipes on OS X?
> There is some *nixy looking stuff in the source code but also some notes
> about win32 only support.
>
> J
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono, Windows Forms, and Headless operation

[Miguel de Icaza]

Hello,

ThreadPools are available on .NET 2.0, just not the fancier TPL-based ones.

Perhaps you could consider replacing that bit of code with using the
ThreadPool?

Miguel

On Thu, Jan 7, 2016 at 4:24 PM, George, Glover E ERDC-RDE-ITL-MS <
glover.e.geo...@erdc.dren.mil> wrote:

> Hi all,
>
> We’re currently porting a Windows Forms Application to Mono, and have
> generally had great success.  However, we have now hit a critical decision
> point, and were hoping for some guidance on the best route forward.   If we
> don’t have X11, mono fails to run Windows Forms code with the following
> error:
>
> From: System.Windows.Forms, at: Void .ctor(), Error Message: The type
> initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext'
> threw an exception.
>
> Question First:
> The main question I had for the Mono list is this.  Is it possible to have
> mono run Windows Forms code without trying to open X11 (I.e. headless
> mode)?  What triggers mono to request an X11 display? Is it the project
> type?  Is it the call to an object that inherits from a Windows Forms
> control?  I don’t need to see the form, but if I’m using BackgroundWorkers,
> I need the form's event handler, don’t I?
>
> Details Last:
> Requirements dictate that make every attempt possible to keep a single
> code base.  I.e., either if’s or #ifdefs if different code needs to run on
> Linux than on Windows.
>
> The code uses multiple concurrent BackgroundWorkers (it’s a .net 2.0 app,
> and we currently don’t have permission to move it to 4.0 and thread pools)
> that process data in parallel.  We’re trying to run this code on a large
> Linux-based HPC system that uses a batch (PBS) queueing system.  The
> problem is that we do not have X11  available on the compute nodes (well,
> at least not unless we’re in interactive mode, and that’s against the
> requirements).  There is a large amount of logic that is tied into using
> BackgroundWorkers, and those seem to require a visible form to provide an
> event loop to handle events generated by the BackgroundWorkers.
> Essentially, this app was designed to only be run interactively, but now
> we’re both parallelizing it, as well as giving it a headless option (I.e.
> if a command line option is given, we’re running with no GUI).
>
> 1. We tried creating a Windows Console app in Visual Studio, essentially a
> driver, that then instantiated the the forms and ran them.  Although
> nothing is shown on the screen, it still required us to use X11. giving the
> error at the top of this message.
>
> 2.  We tried just not using BackgroundWorkers.  This meant the code was
> single threaded, but it still relies on logic in the Windows forms.  We
> could move this logic to classes that don’t have anything to do with
> Windows Forms, but now we have two code bases, essentially.  However, it
> still fails even though we don’t display anything on screen, we get the
> error at the top of this message.
>
> 3.  Xvfb.  This works on local VM’s, but not on our cluster, which we
> don’t have admin rights to (it’s not installed).  There is a possibility
> that we could install X11-Xvfb from source, but this seems overkill.
>
> 4.  Worst case option - remove all background worker logic, and change it
> to just use C# threads.  REALLY don’t want to do this if we don’t have to.
>
> I know this may be confusing, and if so, please feel free to ask for
> clarifications, or even just to say “Why would you want to do that?”
>
> Cheers.
> — — —
> Glover E. George
> Computer Scientist
> Information Technology Laboratory
> US Army Engineer Research and Development Center
> Vicksburg, MS 39180
> 601-634-4730
>
>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Prefer HTTPS over git:

[Miguel de Icaza]

Exactly.

We are not going to change this, but luckily the solution provided should
work for you.

On Mon, Feb 8, 2016 at 8:08 PM, Jonathan Purdy 
wrote:

> Since Git 1.6.6, HTTP(S) remotes are as efficient as the git/SSH
> protocols. However, SSH keys are more convenient and secure for automatic
> authentication than HTTPS auth. As far as I know, the only way to set up
> automatic authentication with git over HTTPS is to store the username and
> password in cleartext in ~/.netrc, which for many users is not acceptable.
>
> On Sun, Feb 7, 2016 at 11:54 AM, Kai Noda  wrote:
>
>> Hi Etienne,
>>
>> Thanks for your reply, it is certainly one solution employable by each
>> Git user.  But I'm suggesting to change the default behavior for everyone,
>> believing there are zero cons for it.
>>
>> // If only I could send a patch w/o CLA signed by my employer's lawyer!
>>
>> Thanks,
>> Kai
>>
>> 野田  開 
>>
>> 2016-02-08 2:20 GMT+08:00 Etienne Champetier <
>> champetier.etie...@gmail.com>:
>>
>>> Hi,
>>>
>>> Le 7 févr. 2016 7:06 PM, "Kai Noda"  a écrit :
>>> >
>>> > Hi Mono developers,
>>> >
>>> > Could you change .gitmodule so that the sub-modules are fetched with
>>> HTTPS rather than the git: protocol?  I believe the former has a higher
>>> chance to pass through firewalls than the latter.
>>>
>>> See http://stackoverflow.com/a/11383587
>>>
>>> >
>>> > Thanks in advance,
>>> > Kai
>>> >
>>> > 野田  開 
>>> >
>>> > ___
>>> > Mono-devel-list mailing list
>>> > Mono-devel-list@lists.ximian.com
>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> >
>>>
>>
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Mono crashes with native stacktrace, but without managed code stacktrace

[Miguel de Icaza]

Hello,

I posted some comments on the bug with some suggestions.

On Sat, Feb 6, 2016 at 10:13 AM, Jacek Rużyczka 
wrote:

> Hi folks,
>
> for a couple of weeks I've had a strange issue with Mono crashing with a
> native stacktrace, but with an empty managed code stacktrace. I've
> already reported this as a bug on
> https://bugzilla.xamarin.com/show_bug.cgi?id=37355 but haven't received
> any reaction so far. What is so strange in my case is that there is
> no .net stacktrace at all besides the fact that I did run my app in
> debug mode with full debug symbolics switched on. How can this happen?
>
> Can anybody please help me? Thank you.
>
> Kind regards
> Jacek Rużyczka
>
>
> ___
> 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] Which mono libraries should be packed along with the mac app ?

[Miguel de Icaza]

>
>
> The mono class libraries are MIT licensed, so if you need to distribute
> those with your app, should be easy for you to comply. The mono runtime is
> GPL, so unless your app is GPL, you'll have a license conflict trying to
> distribute mono with your app legally.
>

LGPL, not GPL.

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

Re: [Mono-dev] Which mono libraries should be packed along with the mac app ?

[Miguel de Icaza]

You should package any libraries that are referenced by your applicaation,
and any that the libraries themselves reference.

monodis --assemblyref FOO.{exe,dll} would list that for you.

Miguel.

On Wed, Feb 3, 2016 at 4:07 PM, Rajesh Khan  wrote:

> I have two issues.
>
> 1- The first issue is that in my code I am doing this at the start
>
>  mono_set_dirs("/opt/mono/lib", "/opt/mono/etc");
>
>
> I am not sure if this is the correct approach as it wont be able to locate
> the libraries when the app is run from a .app. Any suggestions on what I
> could do to fix this ?
>
> 2- Which libraries should be packed along with my .app ?
>
>
> I am using OSX El-Capitan.
>
>
>
> ___
> 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] Multiplatform support with P/Invoke

[Miguel de Icaza]

For something like this, instead of trying to do a high fidelity mapping of
the low level APIs that you would call from C# and then do the abstraction
work from C#, I would instead do the heavy lifting in C, provide the
abstraction there and surface a simple API to C# which you invoke there.

Miguel

On Friday, January 1, 2016, Jason Curl <jcurln...@arcor.de> wrote:

>
> On 2016-01-01 13:17, Miguel de Icaza wrote:
>
>> Re-reading your original question makes me wonder if you really need
>> something as heavy handed as the approach on Mono.Posix.
>>
>
> Specifically I will port my .NET implementation
> http://serialportstream.codeplex.com to Mono on Linux, but why stop
> there? I would further consider BSD socket networking code which is much
> more complicated (especially obtaining interface names).
>
>>
>> The challenge that Mono.Posix faces is that the structures exposed in
>> each Unix is slightly different (different location for fields, different
>> data types for fields), so Mono.Posix resorts to defining its own
>> interface, say instead of using "struct stat" and trying to have one
>> universal implementation that works across many different Unix systems - it
>> instead defines a "struct MyStat" which has well known fields at well known
>> locations with well known sizes.
>>
>> I've experience in writing portable code with the help of Autotools on
> Solaris, FreeBSD, Linux, Cygwin and QNX, all of which have their own quirks
> as you've needed to solve with Mono.Posix.
>
> Then the C glue maps between those two.
>>
>> But in your case, it is not clear if you are trying to bind libc and
>> their structures, or trying to bind your own C library that already has a
>> stable ABI.  If you are coping with the latter, you do not need a setup as
>> tedious as the one that Mono.Posix does, you merely need to ship your
>> native library for each platform you intend to support and your C# code
>> that calls into it.
>>
>
> I've not started the port of my project to Unix and so have no library
> already. I will write one though, as it seems the solution that Mono.Posix
> has taken. It also appears the only /portable/ way that I can take without
> having to make assumptions about structure layouts.
>
>>
>> Miguel
>>
>
> I took a further look at DllMaps, and while I haven't started/tested yet,
> I believe this can simplify effort by allowing me to having one native lib
> per architecture and a single .NET class that "standardizes" the interfaces
> I need.
>
> I'm still researching the best way. Right now, I'm planning on having a
> Cmake/Autotools project to build my library for the platform, use DllMaps
> to let the Mono runtime pick the appropriate native library when running if
> OSVersion is Unix (etc.)
>
> Do you have time to highlight how the MapAttribute works in Mono.Posix?
>
> Thankyou for your support,
> Jason.
>
>>
>> On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl <jcurln...@arcor.de > jcurln...@arcor.de>> wrote:
>>
>> Thank you Mr. Icaza.
>>
>> Is there more information on what uses the MapAttribute than
>> what's in Syscall.cs? Even though it's internal and I won't use
>> it, I'd like to understand how you solve the problem of ABI
>> compatibility.
>>
>> I'd like to set up a solution where copying the files from one
>> architecture to another simply works (assuming all dependencies
>> from the runtime are present), and the runtime/mylib chooses the
>> most appropriate native library (based on OSVersion and
>> Syscall.uname) for all supported platforms. Something like:
>> * MyLib.dll (assembly)
>> * MyNativeLib.Linux.x86.so <http://MyNativeLib.Linux.x86.so>
>> * MyNativeLib.Linux.x64.so <http://MyNativeLib.Linux.x64.so>
>> * MyNativeLib.FreeBSD.x86.so <http://MyNativeLib.FreeBSD.x86.so>
>> * MyNativeLib.Darwin.x86.so <http://MyNativeLib.Darwin.x86.so>
>> * MyNativeLib.Win.x86.dll (windows native)
>> * MyNativeLib.Win.x64.dll (windows native)
>> * MyNativeLib.[dll|so] (backup for local builds)
>>
>> Your solution (Mono.Unix.Native) looks different, more compact,
>> but I'm not sure if/how it supports side-by-side. My solution
>> requires a lot of work, duplicate code with small changes in
>> defining the structs/DllImports with different offsets and library
>> names.
>>
>> I've yet to look into the Dll mapping mechanism of Mono if that's
>> also suitable.
>>
>> Thank you very much and for giving me the opportunity to use Mono.
>>
>> Regards,
>> Jason.
>>
>>
> ___
> 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] Multiplatform support with P/Invoke

[Miguel de Icaza]

Re-reading your original question makes me wonder if you really need
something as heavy handed as the approach on Mono.Posix.

The challenge that Mono.Posix faces is that the structures exposed in each
Unix is slightly different (different location for fields, different data
types for fields), so Mono.Posix resorts to defining its own interface, say
instead of using "struct stat" and trying to have one universal
implementation that works across many different Unix systems - it instead
defines a "struct MyStat" which has well known fields at well known
locations with well known sizes.

Then the C glue maps between those two.

But in your case, it is not clear if you are trying to bind libc and their
structures, or trying to bind your own C library that already has a stable
ABI.  If you are coping with the latter, you do not need a setup as tedious
as the one that Mono.Posix does, you merely need to ship your native
library for each platform you intend to support and your C# code that calls
into it.

Miguel

On Thu, Dec 31, 2015 at 8:15 PM, Jason Curl <jcurln...@arcor.de> wrote:

> Thank you Mr. Icaza.
>
> Is there more information on what uses the MapAttribute than what's in
> Syscall.cs? Even though it's internal and I won't use it, I'd like to
> understand how you solve the problem of ABI compatibility.
>
> I'd like to set up a solution where copying the files from one
> architecture to another simply works (assuming all dependencies from the
> runtime are present), and the runtime/mylib chooses the most appropriate
> native library (based on OSVersion and Syscall.uname) for all supported
> platforms. Something like:
> * MyLib.dll (assembly)
> * MyNativeLib.Linux.x86.so
> * MyNativeLib.Linux.x64.so
> * MyNativeLib.FreeBSD.x86.so
> * MyNativeLib.Darwin.x86.so
> * MyNativeLib.Win.x86.dll (windows native)
> * MyNativeLib.Win.x64.dll (windows native)
> * MyNativeLib.[dll|so] (backup for local builds)
>
> Your solution (Mono.Unix.Native) looks different, more compact, but I'm
> not sure if/how it supports side-by-side. My solution requires a lot of
> work, duplicate code with small changes in defining the structs/DllImports
> with different offsets and library names.
>
> I've yet to look into the Dll mapping mechanism of Mono if that's also
> suitable.
>
> Thank you very much and for giving me the opportunity to use Mono.
>
> Regards,
> Jason.
>
>
> On 2015-12-31 02:04, Miguel de Icaza wrote:
>
> For something like libc, you can use an approach similar to what
> Mono.Posix does, where an intermediate C glue file acts as a bridge between
> the API differences.
>
> See the P/Invokes for the Mono.Posix assembly, and its supporting glue
> code in mono/support/
>
> On Wed, Dec 30, 2015 at 5:58 AM, Jason Curl <jcurln...@arcor.de> wrote:
>
>> Hello,
>>
>> I'm investigating the best way on how to support multiplatform software
>> especially when using P/Invokes, but have not found any reasonable advice
>> on the Wiki.
>>
>> Can someone point to me on how to handle different architectures,
>> especially when the underlying libc might use different structures or API
>> signatures?
>>
>> Thanks,
>> Jason.
>> ___
>> 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] Multiplatform support with P/Invoke

[Miguel de Icaza]

For something like libc, you can use an approach similar to what Mono.Posix
does, where an intermediate C glue file acts as a bridge between the API
differences.

See the P/Invokes for the Mono.Posix assembly, and its supporting glue code
in mono/support/

On Wed, Dec 30, 2015 at 5:58 AM, Jason Curl  wrote:

> Hello,
>
> I'm investigating the best way on how to support multiplatform software
> especially when using P/Invokes, but have not found any reasonable advice
> on the Wiki.
>
> Can someone point to me on how to handle different architectures,
> especially when the underlying libc might use different structures or API
> signatures?
>
> Thanks,
> Jason.
> ___
> 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] IOC performance much slower than Windows

[Miguel de Icaza]

Hello,

The first step would be to isolate the root cause for the problem.

Once we have that information, from this email alone it is not possible to
determine what the culprit is.

On Mon, Dec 7, 2015 at 9:49 AM, Jonathan Channon  wrote:

> Hi,
>
> I am deploying HTTP API apps into production on Linux with Mono.
>
> With some load testing on OSX I have discovered that when I inject a
> dependency into a HTTP handler the requests per second(req/s) are much
> slower than when I have none.
>
> I have done some test console apps using a couple of containers
> registering some interfaces and types and then calling Resolve. I have
> timed these and I can see mono is slower than Windows.
>
> Is there anything I can give you to make this a priority for mono
> development as there clearly is a problem on mono with reflection and/or
> expressions.
>
> 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-list] Adopting Code of Conduct

[Miguel de Icaza]

Hello,

Oops, I posted with [INSERT EMAIL ADDRESS], for now both the monodevelop
and mono teams point to me.

But we will introduce some alias, as soon as I figure out how to send mail
to mono-project.com ;-)

Miguel.

On Thu, Dec 3, 2015 at 12:48 PM, Miguel de Icaza <mig...@xamarin.com> wrote:

> Hello Monoers,
>
> Today we are adopting the following code of conduct for the Mono
> project.
>
> This comes from: http://contributor-covenant.org
>
> Contributor Code of Conduct
>
> As contributors and maintainers of this project, and in the interest of
> fostering an open and welcoming community, we pledge to respect all
> people who contribute through reporting issues, posting feature
> requests, updating documentation, submitting pull requests or patches,
> and other activities.
>
> We are committed to making participation in this project a
> harassment-free experience for everyone, regardless of level of
> experience, gender, gender identity and expression, sexual orientation,
> disability, personal appearance, body size, race, ethnicity, age,
> religion, or nationality.
>
> Examples of unacceptable behavior by participants include:
>
> * The use of sexualized language or imagery
> * Personal attacks
> * Trolling or insulting/derogatory comments
> * Public or private harassment
> * Publishing other's private information, such as physical or electronic
> addresses, without explicit permission
> * Other unethical or unprofessional conduct
>
> Project maintainers have the right and responsibility to remove, edit,
> or reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that they
> deem inappropriate, threatening, offensive, or harmful.
>
> By adopting this Code of Conduct, project maintainers commit themselves
> to fairly and consistently applying these principles to every aspect of
> managing this project. Project maintainers who do not follow or enforce
> the Code of Conduct may be permanently removed from the project team.
>
> This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community.
>
> Instances of abusive, harassing, or otherwise unacceptable behavior may
> be reported by contacting a project maintainer at [INSERT EMAIL
> ADDRESS]. All complaints will be reviewed and investigated and will
> result in a response that is deemed necessary and appropriate to the
> circumstances. Maintainers are obligated to maintain confidentiality
> with regard to the reporter of an incident.
>
> This Code of Conduct is adapted from the Contributor Covenant
> (http://contributor-covenant.org), version 1.3.0, available at
> http://contributor-covenant.org/version/1/3/0/
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-dev] Adopting Code of Conduct

[Miguel de Icaza]

Hello,

Oops, I posted with [INSERT EMAIL ADDRESS], for now both the monodevelop
and mono teams point to me.

But we will introduce some alias, as soon as I figure out how to send mail
to mono-project.com ;-)

Miguel.

On Thu, Dec 3, 2015 at 12:48 PM, Miguel de Icaza <mig...@xamarin.com> wrote:

> Hello Monoers,
>
> Today we are adopting the following code of conduct for the Mono
> project.
>
> This comes from: http://contributor-covenant.org
>
> Contributor Code of Conduct
>
> As contributors and maintainers of this project, and in the interest of
> fostering an open and welcoming community, we pledge to respect all
> people who contribute through reporting issues, posting feature
> requests, updating documentation, submitting pull requests or patches,
> and other activities.
>
> We are committed to making participation in this project a
> harassment-free experience for everyone, regardless of level of
> experience, gender, gender identity and expression, sexual orientation,
> disability, personal appearance, body size, race, ethnicity, age,
> religion, or nationality.
>
> Examples of unacceptable behavior by participants include:
>
> * The use of sexualized language or imagery
> * Personal attacks
> * Trolling or insulting/derogatory comments
> * Public or private harassment
> * Publishing other's private information, such as physical or electronic
> addresses, without explicit permission
> * Other unethical or unprofessional conduct
>
> Project maintainers have the right and responsibility to remove, edit,
> or reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that they
> deem inappropriate, threatening, offensive, or harmful.
>
> By adopting this Code of Conduct, project maintainers commit themselves
> to fairly and consistently applying these principles to every aspect of
> managing this project. Project maintainers who do not follow or enforce
> the Code of Conduct may be permanently removed from the project team.
>
> This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community.
>
> Instances of abusive, harassing, or otherwise unacceptable behavior may
> be reported by contacting a project maintainer at [INSERT EMAIL
> ADDRESS]. All complaints will be reviewed and investigated and will
> result in a response that is deemed necessary and appropriate to the
> circumstances. Maintainers are obligated to maintain confidentiality
> with regard to the reporter of an incident.
>
> This Code of Conduct is adapted from the Contributor Covenant
> (http://contributor-covenant.org), version 1.3.0, available at
> http://contributor-covenant.org/version/1/3/0/
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-list] Adopting Code of Conduct

[Miguel de Icaza]

Hello Monoers,

Today we are adopting the following code of conduct for the Mono
project.

This comes from: http://contributor-covenant.org

Contributor Code of Conduct

As contributors and maintainers of this project, and in the interest of
fostering an open and welcoming community, we pledge to respect all
people who contribute through reporting issues, posting feature
requests, updating documentation, submitting pull requests or patches,
and other activities.

We are committed to making participation in this project a
harassment-free experience for everyone, regardless of level of
experience, gender, gender identity and expression, sexual orientation,
disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic
addresses, without explicit permission
* Other unethical or unprofessional conduct

Project maintainers have the right and responsibility to remove, edit,
or reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviors that they
deem inappropriate, threatening, offensive, or harmful.

By adopting this Code of Conduct, project maintainers commit themselves
to fairly and consistently applying these principles to every aspect of
managing this project. Project maintainers who do not follow or enforce
the Code of Conduct may be permanently removed from the project team.

This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.

Instances of abusive, harassing, or otherwise unacceptable behavior may
be reported by contacting a project maintainer at [INSERT EMAIL
ADDRESS]. All complaints will be reviewed and investigated and will
result in a response that is deemed necessary and appropriate to the
circumstances. Maintainers are obligated to maintain confidentiality
with regard to the reporter of an incident.

This Code of Conduct is adapted from the Contributor Covenant
(http://contributor-covenant.org), version 1.3.0, available at
http://contributor-covenant.org/version/1/3/0/
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-dev] Adopting Code of Conduct

[Miguel de Icaza]

Hello Monoers,

Today we are adopting the following code of conduct for the Mono
project.

This comes from: http://contributor-covenant.org

Contributor Code of Conduct

As contributors and maintainers of this project, and in the interest of
fostering an open and welcoming community, we pledge to respect all
people who contribute through reporting issues, posting feature
requests, updating documentation, submitting pull requests or patches,
and other activities.

We are committed to making participation in this project a
harassment-free experience for everyone, regardless of level of
experience, gender, gender identity and expression, sexual orientation,
disability, personal appearance, body size, race, ethnicity, age,
religion, or nationality.

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery
* Personal attacks
* Trolling or insulting/derogatory comments
* Public or private harassment
* Publishing other's private information, such as physical or electronic
addresses, without explicit permission
* Other unethical or unprofessional conduct

Project maintainers have the right and responsibility to remove, edit,
or reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviors that they
deem inappropriate, threatening, offensive, or harmful.

By adopting this Code of Conduct, project maintainers commit themselves
to fairly and consistently applying these principles to every aspect of
managing this project. Project maintainers who do not follow or enforce
the Code of Conduct may be permanently removed from the project team.

This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.

Instances of abusive, harassing, or otherwise unacceptable behavior may
be reported by contacting a project maintainer at [INSERT EMAIL
ADDRESS]. All complaints will be reviewed and investigated and will
result in a response that is deemed necessary and appropriate to the
circumstances. Maintainers are obligated to maintain confidentiality
with regard to the reporter of an incident.

This Code of Conduct is adapted from the Contributor Covenant
(http://contributor-covenant.org), version 1.3.0, available at
http://contributor-covenant.org/version/1/3/0/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] malloc error executing OBS-built mono

[Miguel de Icaza]

Well, the good news is that this should be trivial to reproduce under gdb,
are you able to do that?

The valgrind command is not reporting line numbers, could you perhaps
compile with debug symbols, or skip the part where you strip those symbols
out?

As for the bug, I can not figure what it is, the issue is an allocation of
a buffer that is later passed to strlen, and the function at that revision
does not have any buffers allocated from dllmap_start that are later passed
to strlen.

On Fri, Oct 23, 2015 at 3:28 AM, Miguel González <
mgonza...@codicesoftware.com> wrote:

> Hi,
>
>
>
> I’ve run mono inside valgrind. I had already done that when I first bumped
> on this issue, but I didn’t save the results :-(  This is the summarized
> output:
>
>
>
> $ valgrind -v --track-origins=yes --leak-check=full
> /opt/plasticscm5/mono/bin/mono
> /opt/plasticscm5/mono/lib/mono/4.5/gacutil.exe –l
>
>
>
> ==4421== Memcheck, a memory error detector
>
> ==4421== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
>
> ==4421== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
>
> ==4421== Command: /opt/plasticscm5/mono/bin/mono
> /opt/plasticscm5/mono/lib/mono/4.5/gacutil.exe -l
>
> ==4421==
>
> --4421-- Valgrind options:
>
> --4421---v
>
> --4421----track-origins=yes
>
> --4421----leak-check=full
>
> --4421-- Contents of /proc/version:
>
> --4421--   Linux version 3.4.33-2.24-desktop (geeko@buildhost) (gcc
> version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1
> SMP PREEMPT Tue Feb 26 03:34:33 UTC 2013 (5f00a32)
>
> --4421-- Arch and hwcaps: X86, x86-sse1-sse2
>
> --4421-- Page sizes: currently 4096, max supported 4096
>
> --4421-- Valgrind library directory: /usr/lib/valgrind
>
> ==4421==
>
> ### ... more command output (see attached file) ... ###
>
> ==4421==
>
> ==4421== HEAP SUMMARY:
>
> ==4421== in use at exit: 19,546 bytes in 643 blocks
>
> ==4421==   total heap usage: 81,884 allocs, 81,241 frees, 36,260,501 bytes
> allocated
>
> ==4421==
>
> ==4421== Searching for pointers to 643 not-freed blocks
>
> ==4421== Checked 23,326,752 bytes
>
> ==4421== ==4421== LEAK SUMMARY:
>
> ==4421==definitely lost: 5,175 bytes in 326 blocks
>
> ==4421==indirectly lost: 64 bytes in 8 blocks
>
> ==4421==  possibly lost: 288 bytes in 2 blocks
>
> ==4421==still reachable: 14,019 bytes in 307 blocks
>
> ==4421== suppressed: 0 bytes in 0 blocks
>
> ==4421== Reachable blocks (those to which a pointer was found) are not
> shown.
>
> ==4421== To see them, rerun with: --leak-check=full --show-reachable=yes
>
> ==4421==
>
> ### ... Detailed info about leaked heap blocks (see attached file) ... ###
>
> ==4421==
>
> ==4421== ERROR SUMMARY: 130 errors from 130 contexts (suppressed: 0 from 0)
>
> ==4421==
>
> ==4421== 1 errors in context 1 of 130:
>
> ==4421== Conditional jump or move depends on uninitialised value(s)
>
> ==4421==at 0x402C2D9: strlen (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>
> ==4421==by 0x81B749E: dllmap_start (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x8283F41: monoeg_g_markup_parse_context_parse (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6E37: mono_config_parse_xml_with_context (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6F6C: mono_config_parse_file_with_context (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6FD6: mono_config_parse_file (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B808B: mono_config_parse (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x80C1448: mono_main (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x8065E51: main (in /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==  Uninitialised value was created by a heap allocation
>
> ==4421==at 0x402B9FD: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
>
> ==4421==by 0x827C84F: monoeg_malloc (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B7476: dllmap_start (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x8283F41: monoeg_g_markup_parse_context_parse (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6E37: mono_config_parse_xml_with_context (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6F6C: mono_config_parse_file_with_context (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B6FD6: mono_config_parse_file (in
> /opt/plasticscm5/mono/bin/mono-sgen)
>
> ==4421==by 0x81B8

Re: [Mono-dev] malloc error executing OBS-built mono

[Miguel de Icaza]

Hello Miguel,

I also had to apply this change in order to avoid an unallowed warning
> message:
>
> I: Statement might be overflowing a buffer in strncat. Common mistake:
>
>BAD: strncat(buffer,charptr,sizeof(buffer)) is wrong, it takes the
>
>left over size as 3rd argument
>
>GOOD: strncat(buffer,charptr,sizeof(buffer)-strlen(buffer)-1)
>

We replaced that code with the glib string operations just yesterday:

042ddd504c09977682bb48010c5642390826d1da

But thanks for sharing.


> At this point I’m able to build mono RPM packages and they’re working as I
> install them using a test OpenSUSE 12.3 virtual machine. However, when the
> GTK# builds are started –which use the mono packages as build requirement–,
> the worker is unable to run the mono executable: apparently, malloc is
> corrupting the heap or something. This is a sample execution as extracted
> from the OBS build logs:
>
> [  101s] + /opt/plasticscm5/mono/bin/mono 
> /opt/plasticscm5/mono/lib/mono/4.5/gacutil.exe -l
>
> [  101s] *** Error in `/opt/plasticscm5/mono/bin/mono': malloc: top chunk is 
> corrupt: 0x08ab9230 ***
>
>
What you want to do at this point in time is to run the process under gdb,
as this will show where malloc detected the error, and then you should get
both the unmanaged stack trace, and if possible the managed one (with the
mono_stack gdb macro)

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

[Mono-dev] Road to C6

[Miguel de Icaza]

Hello team,

We are very close to the C6 release, but we need your help to wrap things
up.

We are tracking about 34 issues to complete, Adrian will be following up
with some of you to get your patches tested, review bugs, look into
existing bugs, or check regressions.   Some of the tasks just require the
team lead approval to go in, some require the team to provide some builds
so QA can verify, and some require some work ;-)

Please help us get these issues sorted out, as many of these are either
release blockers, critical problems or major bugs - all hopefully with
simple fixes.

Reminder, this is the troll board that it tracking C6

https://trello.com/b/U7vszrR9/platform-cycle-6-baseline-release

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

Re: [Mono-dev] Mono for El Capitan (OS X 10.11) preview package now available

[Miguel de Icaza]

They both work.

One is based on Mono 4.0 series, with minimal changes just to enable the
support on El Capitan;   The 4.2 has the same changes, on top of the latest
Mono 4.2, available on Alpha and the release candidate.

On Wed, Oct 14, 2015 at 3:23 AM, Victor E. 
wrote:

> What is the difference between the latest Mono 4.0.4.4 package for Mac and
> the 4.2.1 El Capitan Preview?
> The changelog of 4.0.4.4 includes "33585: El Capitan System Integrity
> Protection support." so i suppose that the 4.0.4.4 also works on El
> Capitan?.
>
> I ask this because i want to know which version i have to install on OSX El
> Capitan system.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-for-El-Capitan-OS-X-10-11-preview-package-now-available-tp4666401p4666754.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] 32 bit mono

[Miguel de Icaza]

Hello,

Yes, we are planning on shipping the 64 bit release.

It is necessary for Roslyn, because Roslyn consumes so much more memory
that large projects need to run on 64.

On Sat, Oct 10, 2015 at 6:23 AM, Greg Young  wrote:

> As of now 32 bit mono is still being shipped with xamarin studio as I
> understand for osx. Are there plans to start shipping 64 bit? Just
> trying to figure out if its worth supporting a 32 bit build of our
> profiler backend for mono.
>
> 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] 32 bit mono

[Miguel de Icaza]

I believe the packages are already up on the web site

On Saturday, October 10, 2015, Numpsy  wrote:

> I'm interested to know if there are any time frames for this as well - I'm
> currently working on a project that needs to use a 64bit Mono on OSX, and
> it
> would be nice to have an idea when there might be an official release.
>
> Thanks,
> Richard Webb
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/32-bit-mono-tp4666741p4666745.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] Registry

[Miguel de Icaza]

One option would be to write a backend that uses one of the various
configuration systems in Unix that use a separate process to arbitrate
access to the information.

Perhaps you can use dconf.

Since the registry lives in mscorlib, and this would bring a number of
dependencies , I recommend to make this a loadable plugin.

On Tue, Oct 6, 2015 at 5:47 PM, Neale Ferguson  wrote:

> We have a client who is testing the waters with porting some .NET based
> applications to mono. However, a couple of these critical applications
> rely on the windows registry. The implementation of registry-support in
> mono is quite crude and not process-safe and this is holding them back. I
> am looking for ideas as to improving this so that apps can share the
> registry safely and efficiently.
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] System.DirectoryServices.DirectoryEntry.ObjectSecurity property

[Miguel de Icaza]

Hello,

It can be oversight, it can be lack of tests, it can be an implementation
that did not keep up with changes, or it can be something that was never
worked on.

Miguel.

On Thu, Oct 8, 2015 at 5:50 AM, Numpsy  wrote:

> Hi all
>
> When trying to build some Windows .Net libs in Mono (on OSX in this case,
> but I don't think that matters), I got a compile error due to the
> 'ObjectSecurity' property of System.DirectoryServices.DirectoryEntry being
> missing.
> I was wondering, is there a reason for that, or is it an oversight?
>
> As it happens I don't actually need to use the returned object on the Mono
> build at the moment, but the compile error is annoying.
>
> Thanks,
> Richard Webb
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/System-DirectoryServices-DirectoryEntry-ObjectSecurity-property-tp4666718.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] System.DirectoryServices.DirectoryEntry.ObjectSecurity property

[Miguel de Icaza]

Sure, that works.

On Thu, Oct 8, 2015 at 9:13 AM, Numpsy  wrote:

> Ok.
> Is it worth me doing a pull request to add a stub implementation? (Some of
> the other props there just throw NotImplementedException on call, so I can
> do the same).
>
> I've also found another issue with the
> ActiveDirectoryObjectNotFoundException class apparently not being present,
> so I may need to do something with that as well.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/System-DirectoryServices-DirectoryEntry-ObjectSecurity-property-tp4666718p4666723.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] Registry

[Miguel de Icaza]

Hello,

We tried to make those work, and could not.   That is why Mono's SHM
support is getting deprecated, it works most of the time, when things go
right.   The problem is that things can go wrong, and they go wrong.

There are a universe of problems, ranging from the home directory being on
non native file systems that do not make guarantees, to service leaks, to
stale data, to stale locks and so on.

Miguel.

On Thu, Oct 8, 2015 at 10:39 AM, Neale Ferguson 
wrote:

> While this wouldn’t protect against “rogue” apps who want to trash things,
> would using the existing mechanism but using the Linux locking primitives
> (which are co-operative and not proscriptive)  to serialize access to the
> underlying files/directories be an option?
>
>
> One option would be to write a backend that uses one of the various
> configuration systems in Unix that use a separate process to arbitrate
> access to the information.
>
> Perhaps you can use dconf.
>
> Since the registry lives in mscorlib, and this would bring a number of
> dependencies , I recommend to make this a loadable plugin.
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] How to use lib64 in mono 4.3?

[Miguel de Icaza]

.so.0
> libMonoSupportW.so
> libmonoboehm-2.0.so.1  libmono-profiler-iomap.so.0.0.0  mono
> libmonoboehm-2.0.so.1.0.0  libmono-profiler-log.a   pkgconfig
> libMonoPosixHelper.a   libmono-profiler-log.la
>
>
> I'm obviously doing something wrong, but I'd love to know what should I do
> to configure it correctly. (BTW, just copying lib64 inside lib makes it
> work, but I guess this is not the way to do it :P).
>
>
> Thanks again!
>
> pablo
>
>
> On 10/5/2015 22:42, Miguel de Icaza wrote:
>
> Hello,
>
> I do not follow, what "new lib64" thing?   That sounds like a packaging
> issue, more than a Mono issue.
>
> Miguel.
>
> On Mon, Oct 5, 2015 at 12:44 PM, <psant...@codicesoftware.com>
> psant...@codicesoftware.com <psant...@codicesoftware.com> wrote:
>
>> Hi,
>>
>> We're having trouble understanding the new lib64 thing in mono 4.3 (we're
>> trying to move Plastic SCM to 4.3 now).
>>
>> A simple app like this one:
>>
>> using Mono.Unix;
>> namespace testunixdirinfo
>> {
>> class MainClass
>> {
>> public static void Main(string[] args)
>> {
>> UnixDirectoryInfo dir = new UnixDirectoryInfo(args[0]);
>> }
>> }
>> }
>>
>> Fails saying it can't find lib/libMonoPosixHelper.so, which is now under
>> lib64 instead.
>>
>> It is easy to fix just moving it under lib inside your mono binaries, but
>> I guess this is not the right way to do it :confounded:
>>
>> This is the build we're using Mono JIT compiler version 4.3.0
>> (explicit/b6dfce6.
>>
>> Thanks!
>>
>> pablo
>>
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] How to use lib64 in mono 4.3?

[Miguel de Icaza]

Hello,

I do not follow, what "new lib64" thing?   That sounds like a packaging
issue, more than a Mono issue.

Miguel.

On Mon, Oct 5, 2015 at 12:44 PM, psant...@codicesoftware.com <
psant...@codicesoftware.com> wrote:

> Hi,
>
> We're having trouble understanding the new lib64 thing in mono 4.3 (we're
> trying to move Plastic SCM to 4.3 now).
>
> A simple app like this one:
>
> using Mono.Unix;
> namespace testunixdirinfo
> {
> class MainClass
> {
> public static void Main(string[] args)
> {
> UnixDirectoryInfo dir = new UnixDirectoryInfo(args[0]);
> }
> }
> }
>
> Fails saying it can't find lib/libMonoPosixHelper.so, which is now under
> lib64 instead.
>
> It is easy to fix just moving it under lib inside your mono binaries, but
> I guess this is not the right way to do it :confounded:
>
> This is the build we're using Mono JIT compiler version 4.3.0
> (explicit/b6dfce6.
>
> Thanks!
>
> pablo
>
> ___
> 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] [SIGNAL] Segfault in native function called by managed code

[Miguel de Icaza]

It is an implementation choice.

Perhaps we could make this configurable, but more often than not, this
indicates a serious issue, and surfacing something so useful as a
AccessViolationException reduces the usefulness of the feature.

On Fri, Sep 4, 2015 at 6:15 AM, Raphael Boissel 
wrote:

> Hello,
>
>
> I have one little question on the way mono currently handles/uses the
> SEGFAULT signal on Unix OSes.
>
> Currently, and correct me if I'm wrong, either the segfault has been
> raised by a managed function and in this case it is handled as a
> genuine exception for instance a nullRefException or if it is triggered
> by native code the entire program is stopped and a stacktrace is
> displayed.
>
> However it seems that mono also follow the second behavior for
> native code that has been invoked inside managed code,
> where I would have expected an AccessViolationException.
>
> Is there any specific reasons why this behavior is followed, or is it
> just an implementation choice ?
>
> (sorry about the potential double post I sent it first with a
> non-whitelisted
> e-mail address)
>
> Thanks,
>
> --
> Raphaël 'Shugo' Boissel
>
> ___
> 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] State of TLS, SslStream and HttpWebRequest support in Mono

[Miguel de Icaza]

Yes.

On Mon, Aug 31, 2015 at 4:55 AM, Mat Arge <argemat1...@gmail.com> wrote:

> Will it finally be possible to use client certificates with ECDSA keys,
> after
> the changes? (The bug report
> https://bugzilla.xamarin.com/show_bug.cgi?id=8563
> is lying around for quite some time)
>
> cheers
> Mat
>
> On Friday 28. August 2015 09:04:26 Miguel de Icaza wrote:
> > Mono's managed TLS implementation will have it (crypto coming from
> > BouncyCastle)
> >
> > The other options (ModernHttpClient, CFNetworkHandler) already support
> it,
> > because it is the OS that has the support.
> >
> > Miguel.
> >
> > On Fri, Aug 28, 2015 at 12:40 AM, techi eth <techi...@gmail.com> wrote:
> > > Hi,
> > >
> > > Is that support handling ECDHE-ECDSA algorithm ?
> > >
> > > Techi
> > >
> > > On Thu, Aug 27, 2015 at 9:36 PM, Miguel de Icaza <mig...@xamarin.com>
> > >
> > > wrote:
> > >> Hello team,
> > >>
> > >> I have posted an update on our TLS and networking stack efforts:
> > >>
> > >> http://tirania.org/blog/archive/2015/Aug-27.html
> > >>
> > >> Miguel
> > >>
> > >> ___
> > >> Mono-devel-list mailing list
> > >> Mono-devel-list@lists.ximian.com
> > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.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] State of TLS, SslStream and HttpWebRequest support in Mono

[Miguel de Icaza]

Like the posts says, that code is not yet integrated into Mono.

On Mon, Aug 31, 2015 at 11:57 PM, techi eth <techi...@gmail.com> wrote:

> Seems to be good news!!!
>
> Could you please tell me from which mono released version it is getting
> supported.
> Actually I have tried websocket with certificate based authentication for
> client & server with mono 4.0 & it was not working for ECDSA.(I am testing
> on Ubuntu14.04)
>
> Thanks
>
>
>
>
>
> On Tue, Sep 1, 2015 at 12:27 AM, Miguel de Icaza <mig...@xamarin.com>
> wrote:
>
>> Yes.
>>
>> On Mon, Aug 31, 2015 at 4:55 AM, Mat Arge <argemat1...@gmail.com> wrote:
>>
>>> Will it finally be possible to use client certificates with ECDSA keys,
>>> after
>>> the changes? (The bug report
>>> https://bugzilla.xamarin.com/show_bug.cgi?id=8563
>>> is lying around for quite some time)
>>>
>>> cheers
>>> Mat
>>>
>>> On Friday 28. August 2015 09:04:26 Miguel de Icaza wrote:
>>> > Mono's managed TLS implementation will have it (crypto coming from
>>> > BouncyCastle)
>>> >
>>> > The other options (ModernHttpClient, CFNetworkHandler) already support
>>> it,
>>> > because it is the OS that has the support.
>>> >
>>> > Miguel.
>>> >
>>> > On Fri, Aug 28, 2015 at 12:40 AM, techi eth <techi...@gmail.com>
>>> wrote:
>>> > > Hi,
>>> > >
>>> > > Is that support handling ECDHE-ECDSA algorithm ?
>>> > >
>>> > > Techi
>>> > >
>>> > > On Thu, Aug 27, 2015 at 9:36 PM, Miguel de Icaza <mig...@xamarin.com
>>> >
>>> > >
>>> > > wrote:
>>> > >> Hello team,
>>> > >>
>>> > >> I have posted an update on our TLS and networking stack efforts:
>>> > >>
>>> > >> http://tirania.org/blog/archive/2015/Aug-27.html
>>> > >>
>>> > >> Miguel
>>> > >>
>>> > >> ___
>>> > >> Mono-devel-list mailing list
>>> > >> Mono-devel-list@lists.ximian.com
>>> > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>> ___
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.ximian.com
>>> http://lists.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] what git commit id for provided source tarball ?

[Miguel de Icaza]

Hello,

We use tags for that, so you are looking for the mono-4.0.3.20 tag on git.

Miguel

On Sat, Aug 29, 2015 at 1:08 AM, Normand norm...@linux.vnet.ibm.com wrote:

 Hi there,
 Is there a way to find the relation between a source tarball provided in
 (1) and the git tree of (2)
 Is there a git commit id associated to the tarball ?

 (1) http://download.mono-project.com/sources/mono/
 http://download.mono-project.com/sources/mono/mono-4.0.3.20.tar.bz2
 (2) https://github.com/mono/mono

 --
 Michel Normand

 ___
 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] State of TLS, SslStream and HttpWebRequest support in Mono

[Miguel de Icaza]

Mono's managed TLS implementation will have it (crypto coming from
BouncyCastle)

The other options (ModernHttpClient, CFNetworkHandler) already support it,
because it is the OS that has the support.

Miguel.

On Fri, Aug 28, 2015 at 12:40 AM, techi eth techi...@gmail.com wrote:

 Hi,

 Is that support handling ECDHE-ECDSA algorithm ?

 Techi

 On Thu, Aug 27, 2015 at 9:36 PM, Miguel de Icaza mig...@xamarin.com
 wrote:

 Hello team,

 I have posted an update on our TLS and networking stack efforts:

 http://tirania.org/blog/archive/2015/Aug-27.html

 Miguel

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



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

Re: [Mono-dev] WCF

[Miguel de Icaza]

Very unlikely.

The page has not been updated in years, does not even cover the
Silverlight/Moonlight push, which is what made it usable, and most
importantly, recent developments where we replaced large chunks of it with
Microsoft's stack.

MIguel.

On Wed, Aug 26, 2015 at 5:02 PM, Neale Ferguson ne...@sinenomine.net
wrote:

 Does the doc at http://www.mono-project.com/docs/web/wcf/ reflect the
 current state of WCF support?

 ___
 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] State of TLS, SslStream and HttpWebRequest support in Mono

[Miguel de Icaza]

Hello team,

I have posted an update on our TLS and networking stack efforts:

http://tirania.org/blog/archive/2015/Aug-27.html

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

Re: [Mono-dev] Registry question

[Miguel de Icaza]

It is not multi-process safe, you would need to ensure that through an
external mean.

On Thu, Aug 27, 2015 at 12:42 PM, Neale Ferguson ne...@sinenomine.net
wrote:

 Is registry multi-process safe? How are registry transactions maintained
 by Mono? Also, I assume the EventLog is just syslog on Linux.


 Neale

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

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

Re: [Mono-dev] Mono for El Capitan (OS X 10.11) preview package now available

[Miguel de Icaza]

I configure my HomeBrew to use /brew

Otherwise, this will conflict.

Miguel.

On Mon, Aug 3, 2015 at 11:47 AM, Nate McMaster nate.mcmas...@microsoft.com
wrote:

 There is a potential conflict with this change as Homebrew
 http://brew.sh/ also uses /usr/local as the default install location.
 Does this update mean Xamarin Studio will recognize a homebrew installation
 instead? Or will homebrew users have trouble using the MDK installer?

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


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

Re: [Mono-dev] condition `class' not met

[Miguel de Icaza]

yes, produce a minimal test case that exhibits the issue.

On Tue, Jul 28, 2015 at 3:24 AM, Daniel Kuhne dakui...@gmail.com wrote:

 Hello,

 I am getting assertion:

 * Assertion at class.c:5078, condition `class' not met


 Native stacktrace:

 mono() [0x48f940]

 =
 Got a SIGABRT while executing native code. This usually indicates
 a fatal error in the mono runtime or one of the native libraries
 used by your application.
 =

 Aborted


 Any idea?
 Cheers,
 Daniel

 ___
 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] OS X 64 bit stuff

[Miguel de Icaza]

Hello,

1. Is there a timeline for a 64 bit OS X framework release? A few months
 ago the answer was no.


There is a definite timeline, which is before or at Cycle 7, which
currently looks like an end-of-year release.   So that is the worst case
scenario.

We have internal builds that we have been using to test MonoDevelop/Xamarin
Studio with 64 bits, and we are hoping to preview those in the next couple
of weeks to the rest of the world.

There are really no hard technical complications with Mono on 64 bits,
purely the fact that we wanted to ship as much as possible of the runtime
as dual libraries (Mono, but also Cairo, Gtk+ and so on) and give users the
ability to force apps to run on 32 or 64 bit mode.

So all the libraries you can link against would be 32/64 lipo-ed binaries.

The mono command is special, so we were thinking of shipping both
binaries, a mono with 32 and a mono with 64.   This would allow you to
control how your application runs (mono32 will always run in 32 bits,
mono64 always in 64), with the mono command allowing a flag to switch
between 32 and 64, similar to our --gc flag.

The reason to keep 32 around is to not break existing users that might
depend on it, and because some libraries (System.Windows.Forms) are tied to
the 32-bit API.

So it is mostly lots of small logistic issues involved with shipping a
whole framework.

2. I think that Xamarin.mac supports 64 bits. Does this use a discrete 64
 library build as opposed to a standard OS X framework bundle?


Xamarin.Mac does use ship with 64 bit support, that is correct.   It uses
its own build of Mono.


 3. The OS X mono framework is apparently built with
 https://github.com/mono/bockbuild. That repo his pretty opaque.
 https://github.com/mono/bockbuild/blob/master/bockbuild/darwinprofile.py
 looks like it might be able to handle a 64 bit build. Am I on the right
 track there?


You are on the right track.

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

Re: [Mono-dev] SIGSEGV from bad generic type (bug 30085)

[Miguel de Icaza]

Hello,

There is already a similar pull request.

The issue is that returning NULL there has a slightly different meaning.
So the complete fix is to restructure some of the code.

https://github.com/mono/mono/pull/1817

Miguel

On Thu, May 28, 2015 at 4:25 PM, David Curylo cury...@asme.org wrote:

 Found the issue and created PR 1839:
 https://github.com/mono/mono/pull/1839

 Please take a look and let me know if you have any concerns with the fix.

 Thanks,
 Dave

 On May 28, 2015, at 3:51 PM, David Curylo cury...@asme.org wrote:

 I’m researching an issue reported by a colleague of mine.  The error is
 rather serious as the use of a bad type name causes a native SIGSEGV and
 kills the runtime, when it really should just return a null because it
 can’t find the type.  This code reproduces the issue:

 System.Type.GetType(System.Nullable`1[[System.Int32, mscorlibBAD]])

 Since I see there is some work going on with System.Type, I was hopeful
 that mono master would no longer have this issue, but it still exists.
 This is what I’m getting in the thread dump when this occurs and the root
 cause appears to be somewhere in _mono_reflection_get_type_from_info.  Any
 ideas what may be the root cause here?


 Thread 1 (Thread 0x7f28ae81f7c0 (LWP 76562)):
 #0  0x7f28adcf7ee9 in __libc_waitpid (pid=pid@entry=76565,
 stat_loc=stat_loc@entry=0x7f28ae82919c, options=options@entry=0) at
 ../sysdeps/unix/sysv/linux/waitpid.c:40
 #1  0x004a2015 in mono_handle_native_sigsegv (signal=signal@entry=11,
 ctx=ctx@entry=0x7f28ae829ac0, info=info@entry=0x7f28ae829bf0) at
 mini-exceptions.c:2226
 #2  0x004f782e in mono_arch_handle_altstack_exception
 (sigctx=sigctx@entry=0x7f28ae829ac0, siginfo=siginfo@entry=0x7f28ae829bf0,
 fault_addr=optimized out, stack_ovf=stack_ovf@entry=0) at
 exceptions-amd64.c:858
 #3  0x00422f28 in mono_sigsegv_signal_handler (_dummy=11,
 _info=0x7f28ae829bf0, context=0x7f28ae829ac0) at mini-runtime.c:2526
 #4  signal handler called
 *#5  0x005bcb91 in _mono_reflection_get_type_from_info
 (info=0x1efb270, image=image@entry=0x0, ignorecase=ignorecase@entry=0) at
 reflection.c:7450*
 #6  0x005bc750 in mono_reflection_get_type_internal
 (rootimage=rootimage@entry=0x0, image=optimized out, 
 info=info@entry=0x7fff8b7388e0,
 ignorecase=ignorecase@entry=0) at reflection.c:7565
 #7  0x005bc9b3 in mono_reflection_get_type_with_rootimage
 (rootimage=rootimage@entry=0x0, image=image@entry=0x0, 
 info=info@entry=0x7fff8b7388e0,
 ignorecase=ignorecase@entry=0, type_resolve=type_resolve@entry=0x7fff8b7388d4)
 at reflection.c:7661
 #8  0x005bcb00 in mono_reflection_get_type (image=image@entry=0x0,
 info=info@entry=0x7fff8b7388e0, ignorecase=ignorecase@entry=0,
 type_resolve=type_resolve@entry=0x7fff8b7388d4) at reflection.c:7613
 #9  0x0053456d in type_from_name (ignoreCase=optimized out,
 str=0x1ef44f0 System.Nullable`1[[System.Int32, mscorlibBAD]]) at
 icall.c:1286
 #10 ves_icall_type_from_name (name=0x7f28ae7981b0, throwOnError=optimized
 out, ignoreCase=optimized out) at icall.c:1322



 ___
 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] HttpListener

[Miguel de Icaza]

Well, it might be best if you explain what you have in mind, before we
waste time with a pull request.

But either way works.

On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote:

 Miguel,

 Would it be best to just take a stab at an alternative interface and
 send a PR for discussion?

 Greg

 On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com
 wrote:
  This is the code handling the prefixes its here
 
 https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43
 
  There is quite a bit of odd code around this in general. I understand
  much of it is trying to reach compliance with MS but ...
 
  On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Hello Greg,
 
  Is that in HttpListener, or somewhere else?
 
  Miguel
 
  On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com
  wrote:
 
  Here is some of the code in question:
 
  IPAddress addr;
  if (host == *)
  addr = IPAddress.Any;
  else if (IPAddress.TryParse(host, out addr) == false){
  try {
  IPHostEntry iphost = Dns.GetHostByName(host);
 if (iphost != null)
  addr = iphost.AddressList[0];
 else
  addr = IPAddress.Any;
 } catch {
  addr = IPAddress.Any;
 }
  }
 
  On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com
  wrote:
   I have been going through a bunch of this code lately after seeing
   many ... interesting behaviours. I understand that much of the derp
 in
   this code is due to not having IIS and MS having an IIS centric API
   but wow. Some gems I have found...
  
   1) synchronous dns calls being made...
   2) I want to listen on 192.168.0.1:1234 but I want to support a host
   header of whateverdomain can't resolve whatever domain then bind
   listeners to all ips on machine.
   3) Same as above but dns entry has multiple ips it resovles to [0]
   doesnt match see #2
   4) Anything at all to do with elastic ips
   5) Exceptions thrown to calling code with http status codes in them
 (I
   think this is ms legacy but is a pretty biog wtf)
   6) failure parsing ip address says bind all interfaces on machine
 (huh?)
  
   Perhaps it makes sense to expose a Microsoft Http Compatibility
   Layer and then have a Sane API if you want to use it
  
   I dont mind putting some time in on these but is this even worthwhile
   or is the plan to just burn this code with fire and move to something
   sane in general?
  
   Cheers,
  
   Greg
   --
   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
 
 
 
 
 
  --
  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] HttpListener

[Miguel de Icaza]

Shouldn't we bind on the interface based on the IP address?

Would that not solve the problem?

miguel

On Tue, May 19, 2015 at 4:00 PM, Greg Young gregoryyou...@gmail.com wrote:

 I was thinking a basic code api that allowed the specification of
 interface to bind to separately from which prefixes to accept to start
 with. The biggest issue here is that the ms api is basically using
 httpprefix to mean two very different things.

 On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Well, it might be best if you explain what you have in mind, before we
 waste
  time with a pull request.
 
  But either way works.
 
  On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com
 wrote:
 
  Miguel,
 
  Would it be best to just take a stab at an alternative interface and
  send a PR for discussion?
 
  Greg
 
  On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com
  wrote:
   This is the code handling the prefixes its here
  
  
 https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43
  
   There is quite a bit of odd code around this in general. I understand
   much of it is trying to reach compliance with MS but ...
  
   On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com
   wrote:
   Hello Greg,
  
   Is that in HttpListener, or somewhere else?
  
   Miguel
  
   On Fri, Apr 24, 2015 at 12:41 PM, Greg Young 
 gregoryyou...@gmail.com
   wrote:
  
   Here is some of the code in question:
  
   IPAddress addr;
   if (host == *)
   addr = IPAddress.Any;
   else if (IPAddress.TryParse(host, out addr) == false){
   try {
   IPHostEntry iphost = Dns.GetHostByName(host);
  if (iphost != null)
   addr = iphost.AddressList[0];
  else
   addr = IPAddress.Any;
  } catch {
   addr = IPAddress.Any;
  }
   }
  
   On Fri, Apr 24, 2015 at 7:29 PM, Greg Young 
 gregoryyou...@gmail.com
   wrote:
I have been going through a bunch of this code lately after seeing
many ... interesting behaviours. I understand that much of the
 derp
in
this code is due to not having IIS and MS having an IIS centric
 API
but wow. Some gems I have found...
   
1) synchronous dns calls being made...
2) I want to listen on 192.168.0.1:1234 but I want to support a
 host
header of whateverdomain can't resolve whatever domain then bind
listeners to all ips on machine.
3) Same as above but dns entry has multiple ips it resovles to [0]
doesnt match see #2
4) Anything at all to do with elastic ips
5) Exceptions thrown to calling code with http status codes in
 them
(I
think this is ms legacy but is a pretty biog wtf)
6) failure parsing ip address says bind all interfaces on machine
(huh?)
   
Perhaps it makes sense to expose a Microsoft Http Compatibility
Layer and then have a Sane API if you want to use it
   
I dont mind putting some time in on these but is this even
worthwhile
or is the plan to just burn this code with fire and move to
something
sane in general?
   
Cheers,
   
Greg
--
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
  
  
  
  
  
   --
   Studying for the Turing test
 
 
 
  --
  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] Build Mono WITHOUT bash?

[Miguel de Icaza]

It is unlikely.

Your best bet is to cross compile.

On Sun, May 17, 2015 at 6:24 AM, cyd chasel...@gmail.com wrote:

 Is there a version of the mono source that can be built without bash?

 I'm building mono on an Android device in the KBOX environment, which has
 the busybox version of bash.  It does not support arrays so when running
 make it fails when running ./doltlibtool (at line 4, args=())or
 ./doltcompile (line 3, args=($@)).

 Thanks!



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Build-Mono-WITHOUT-bash-tp4665954.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Building Mono MDK

[Miguel de Icaza]

Mono's source code by default builds a 64-bit version.

So the usual configure; make; make install with defaults does that.

Now, if you want the entire set of native libraries we ship with Mono (Gtk+
and family) as 64 bits, then that might require some work.

On Sun, May 17, 2015 at 7:20 AM, Jonathan Mitchell jonat...@mugginsoft.com
wrote:

 I would like to build a 64 bit version of the Mono MDK for OS X.
 It looks as if the current Mono OS X release is still 32 bit only.

 How do I configure an MDK build?

 Thanks

 Jonathan













 ___
 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] ECDSA support

[Miguel de Icaza]

Hello,

We do not have plans to add the code right now, but we would welcome anyone
that wants to contribute the code to Mono.

ReferenceSource code would only bring the API layer, but does not actually
bring an implementation of the algorithms.

The implementation would have to come from something like Bouncy Castle.

Miguel


On Tue, May 12, 2015 at 9:03 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
  boun...@lists.ximian.com] On Behalf Of techi eth
 
  Is mono support ciphers ECDSA ?
  Mono 4.0.0 release show some handling of same under mono-
  4.0.0/external/referencesource/System.Core/System/Security/Cryptograph
  y.
  Please let me know how to use the same in build.

 If it's not coming for any reason, I know bouncycastle has it.
 ___
 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] WebSocket Support in Mono

[Miguel de Icaza]

Have you looked at WebSocket/ClientWebSocket in the System.Net.WebSocket
namespace?

Alternatively, for a chat app that we recently built, we used:

https://supersocket.codeplex.com/

Which comes with a nice WebSocket stack.

On Tue, Apr 28, 2015 at 12:05 AM, techi eth techi...@gmail.com wrote:

 Hi,

 Is mono is supporting Websocket ?

 When I look Web socket handling in HttpListnerRequest in .Net4.5
 implementation in mono it is always returning False.(Flag :
 IsWebSocketRequest)

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

[Miguel de Icaza]

Hello Greg,

Is that in HttpListener, or somewhere else?

Miguel

On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com
wrote:

 Here is some of the code in question:

 IPAddress addr;
 if (host == *)
 addr = IPAddress.Any;
 else if (IPAddress.TryParse(host, out addr) == false){
 try {
 IPHostEntry iphost = Dns.GetHostByName(host);
if (iphost != null)
 addr = iphost.AddressList[0];
else
 addr = IPAddress.Any;
} catch {
 addr = IPAddress.Any;
}
 }

 On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com
 wrote:
  I have been going through a bunch of this code lately after seeing
  many ... interesting behaviours. I understand that much of the derp in
  this code is due to not having IIS and MS having an IIS centric API
  but wow. Some gems I have found...
 
  1) synchronous dns calls being made...
  2) I want to listen on 192.168.0.1:1234 but I want to support a host
  header of whateverdomain can't resolve whatever domain then bind
  listeners to all ips on machine.
  3) Same as above but dns entry has multiple ips it resovles to [0]
  doesnt match see #2
  4) Anything at all to do with elastic ips
  5) Exceptions thrown to calling code with http status codes in them (I
  think this is ms legacy but is a pretty biog wtf)
  6) failure parsing ip address says bind all interfaces on machine (huh?)
 
  Perhaps it makes sense to expose a Microsoft Http Compatibility
  Layer and then have a Sane API if you want to use it
 
  I dont mind putting some time in on these but is this even worthwhile
  or is the plan to just burn this code with fire and move to something
  sane in general?
 
  Cheers,
 
  Greg
  --
  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

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

Re: [Mono-dev] LLVM + mac deploys

[Miguel de Icaza]

Right, Mono on Mac is currently 32 bits, and we ship LLVM with it.

But we do not default to LLVM, that is something that you can use when you
pass the --llvm option.

I believe we are just about to release a Mono that includes both 32 and 64
bit binaries.

Miguel

On Thu, Apr 16, 2015 at 10:15 AM, Greg Young gregoryyou...@gmail.com
wrote:

 Some others are saying the xamarin package is also 32bit + llvm

 I don't have it installed here to test

 On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Hello,
 
  LLVM is never the default for JIT configurations, it is something that
 you
  must manually opt-into.
 
  Did homebrew default to it?   Because LLVM as a JIT is *very slow*
 
  Miguel
 
  On Thu, Apr 16, 2015 at 8:35 AM, Greg Young gregoryyou...@gmail.com
 wrote:
 
  I was looking through an issue from a mac user today.
 
  Apparently when they brought down mono from home brew there were two
  odds things.
 
  1) It was 32bit. That's not really for this list though
  2) It was using LLVM by default. Is LLVM ready for being the default
  at this point? I haven't been following it much.
 
  What is the current best practice for a mac user to be installing? I
  run builds myself but figure there is a better way
 
  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

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

Re: [Mono-dev] LLVM + mac deploys

[Miguel de Icaza]

Hello,

LLVM is never the default for JIT configurations, it is something that you
must manually opt-into.

Did homebrew default to it?   Because LLVM as a JIT is *very slow*

Miguel

On Thu, Apr 16, 2015 at 8:35 AM, Greg Young gregoryyou...@gmail.com wrote:

 I was looking through an issue from a mac user today.

 Apparently when they brought down mono from home brew there were two
 odds things.

 1) It was 32bit. That's not really for this list though
 2) It was using LLVM by default. Is LLVM ready for being the default
 at this point? I haven't been following it much.

 What is the current best practice for a mac user to be installing? I
 run builds myself but figure there is a better way

 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] LLVM + mac deploys

[Miguel de Icaza]

That is most definitely not the version that xamarin is shipping.

On Thu, Apr 16, 2015 at 10:30 AM, Greg Young gregoryyou...@gmail.com
wrote:

 Did something like just change with this? I just asked if anyone could
 do a fresh install and got

 mono --version
 Mono JIT compiler version 3.12.1 (tarball Tue Mar 17 15:03:14 GMT 2015)
 Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
 www.mono-project.com
 TLS:   normal
 SIGSEGV:   altstack
 Notification:  kqueue
 Architecture:  amd64
 Disabled:  none
 Misc:  softdebug
 LLVM:  supported, not enabled.
 GC:sgen

 On Thu, Apr 16, 2015 at 5:17 PM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Right, Mono on Mac is currently 32 bits, and we ship LLVM with it.
 
  But we do not default to LLVM, that is something that you can use when
 you
  pass the --llvm option.
 
  I believe we are just about to release a Mono that includes both 32 and
 64
  bit binaries.
 
  Miguel
 
  On Thu, Apr 16, 2015 at 10:15 AM, Greg Young gregoryyou...@gmail.com
  wrote:
 
  Some others are saying the xamarin package is also 32bit + llvm
 
  I don't have it installed here to test
 
  On Thu, Apr 16, 2015 at 5:13 PM, Miguel de Icaza mig...@xamarin.com
  wrote:
   Hello,
  
   LLVM is never the default for JIT configurations, it is something that
   you
   must manually opt-into.
  
   Did homebrew default to it?   Because LLVM as a JIT is *very slow*
  
   Miguel
  
   On Thu, Apr 16, 2015 at 8:35 AM, Greg Young gregoryyou...@gmail.com
   wrote:
  
   I was looking through an issue from a mac user today.
  
   Apparently when they brought down mono from home brew there were two
   odds things.
  
   1) It was 32bit. That's not really for this list though
   2) It was using LLVM by default. Is LLVM ready for being the default
   at this point? I haven't been following it much.
  
   What is the current best practice for a mac user to be installing?
 I
   run builds myself but figure there is a better way
  
   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] Update on Build System

[Miguel de Icaza]

Hello,

I do not think this work was completed.

Miguel

On Thu, Apr 9, 2015 at 3:12 PM, Chris Tacke cta...@opennetcf.com wrote:

 It’s been about a year and thought I’d loop back on this thread since it’s
 still something I could really use. Are we yet to a point where we can
 build Mono using the Microsoft compilers only?  If so, I can then start
 looking at modifying those projects to build using the Windows CE compilers.



 -Chris Tacke



 *From:* Miguel de Icaza [mailto:mig...@xamarin.com]
 *Sent:* Monday, May 26, 2014 10:23 AM
 *To:* Chris Tacke
 *Cc:* mono-devel
 *Subject:* Re: [Mono-dev] Update on Build System



 Hello Chris,



 That is what I am trying to do with this work.



 There are still a number of problems that I need to address:

- Installing the resulting binaries
- Signing (currently we are skipping this)
- Ensure the binaries produced are identical with Make and msbuild
- Add assertions to ensure that flags that we currently ignore are
caught, in case we add new features in the future
- Fix the C# compiler build (currently disabled)
- Extend this to other components, so we can have the entire setup in
a solution.

 Then we would have something that works.



 Miguel



 On Mon, May 26, 2014 at 11:04 AM, Chris Tacke cta...@opennetcf.com
 wrote:

 Miguel,



 This is great news. Are there any plans to update the build system to
 allow us to compile the runtime itself using Visual Studio (i.e. a
 Microsoft compiler)?



 Now before everyone starts with the eye rolling and “why the hell would
 you want to do that?” questions, let me explain.  As of today, we can
 create applications in C# that will run on Windows and a large array of
 Linux machines (including Android) but Windows CE has been orphaned.
 Microsoft is not putting any effort into the Compact Framework, but there
 are still people developing for Windows CE devices.  I’d like to put a last
 nail in the coffin of the Compact Framework by getting Mono supported on
 Windows CE so we can all move into using technology from the current
 decade, not the last one.



 I don’t see any real path for getting the runtimes to compile for Windows
 CE  for ARM and 586 (not 686, since we have new Intel processors now that
 are 586 based).  There is an old (last touch in 2009) CeGCC project that
 might be a step, but I was hoping for something a little simpler.  I’m up
 for any suggestions.



 -Chris Tacke











 *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
 mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Miguel de Icaza
 *Sent:* Friday, May 23, 2014 9:59 PM
 *To:* mono-devel
 *Subject:* [Mono-dev] Update on Build System



 Hey guys,



 #1 Makefile Build System Update



 So the clean staged setup has been added to mono/master and in practice
 most of you will never notice an improvement.



 Those working on libraries that had cross dependencies will enjoy reliable
 and working builds.   If you make a change in say System, and you type
 make in mcs/class/System, it will make sure that all the dependencies are
 properly compiled and the result will be stable.



 #2 MSBuild setup


 Based on the work above, I have updated the MSBuild setup, and it is now
 possible to build most of the managed code with xbuild.   This means that
 you can use this from Visual Studio or Xamarin Studio.



 Since xbuild does not support passing /keyfile to the C# compiler, I still
 have to fix about 6-7 assemblies that use -keyfile to be signed.



 Once that happens, you should be able to build all of Mono's managed code
 with:



 xbuild msvc/scripts/net_4_5.sln



 Currently I disabled generating project files for profiles other than 4.5,
 just because it is easier to debug this way.



 I am also a bit sad that our xbuild does not have any support for parallel
 builds, it would have been a neat hack to make the xbuild-based build
 system parallel and get this for free.



 #3 Future Parallel Work - Makefiles



 I tried to implement parallel builds for mcs/class/Facades, and while it
 works, it regressed some of the other standard targets that we have (the
 other -local).   I will have to revisit this later.



 But the principle behind the patch that enabled this could be used for
 mcs/class and parallelize all the builds as well.   We only need to (a)
 generate the assembly dependencies [1] and (b) we need to figure out the
 -local target breakage (same stuff I broke for Facades).



 [1]  (which we have from the xbuild work above)

 Miguel



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

Re: [Mono-dev] Some MSBuild porting progress

[Miguel de Icaza]

Well, the idea would be to fix all major issues before we switch.

But I do not see the value of keeping the two around.

On Sun, Mar 29, 2015 at 6:07 AM, Atsushi Enomoto atsu...@xamarin.com
wrote:

 Actually IMO it's nicer to add msbuild (and msbuild.exe) while
 keeping xbuild as is, unless those upgraded Framework/Utilities/Tasks
 break it. That way people don't have to worry about backward
 compatibility and switch to new build engine simply by switching to
 msbuild from xbuild. That also fills gap between .NET and Mono.

 I even have created mcs/tools/msbuild before (unfinished, not part of
 build yet).

 Atsushi Eno

 On Sun, Mar 29, 2015 at 4:48 AM, Lluis Sanchez ll...@xamarin.com wrote:
 
  El 28/03/2015, a les 15:32, Miguel de Icaza mig...@xamarin.com va
  escriure:
 
  Hello,
 
  Question: does XS/MD depend on Microsoft.Build.Engine.dll?
 
 
  MD currently depends on Microsoft.Build.Engine when running on Mac or
 Linux,
  but my plan is to replace it by the new Microsoft.Build in the new
 project
  model branch. In any case we can keep Microsoft.Build.Engine in Mono for
  backwards compatibility and add the new ones for xbuild and MD.
 
 
  Because we only would need it if the IDE needed it, and in that case,
  hopefully we could replace it?
 
  But the idea is to make xbuild the script just use the new msbuild.
 
  Miguel
 
  On Sat, Mar 28, 2015 at 12:02 AM, Atsushi Enomoto atsu...@xamarin.com
  wrote:
 
  Microsoft.Build.dll is the (relatively) new build engine which
  obsoleted Microsoft.Build.Engine.dll. The deprecated one is not in the
  msbuild repo and that's what we use in xbuild.
 
  Atsushi Eno
 
 
  On Sat, Mar 28, 2015 at 4:48 AM, Miguel de Icaza mig...@xamarin.com
  wrote:
   Hello,
  
   I was under the impression that there were different versions of the
   MSBuild
   API?
  
   But I guess we implement the right one?
  
   My main concern was not breaking MonoDevelop, so if we do not break
 it,
   we
   should be fine.
  
   Let me know when you think you are ready, and we should incorporate
   MSBuild
   into Mono's current build setup.
  
   Miguel
  
   On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez ll...@xamarin.com
   wrote:
  
  
   El 27/03/2015, a les 19:41, Miguel de Icaza mig...@xamarin.com va
   escriure:
  
   Hello Lluis,
  
   I think once we are happy with msbuild, that we should build msbuild
 as
   part of the standard Mono build process and ship the resulting
   libraries and
   script.
  
   My only concern is whether the public API surface that msbuild has is
   able
   to replace the assemblies that we currently install on the GAC.
  
  
   Yes, it does. The assemblies are Microsoft.Build,
   Microsoft.Build.Framework, Microsoft.Build.Tasks and
   Microsoft.Build.Utilities. We have partial implementations of those
 in
   Mono.
   The msbuild repo fully implements all of them.
  
   We can also use the .targets files included in the msbuild repo. I’ve
   been
   able to mostly build MD using the new libraries and using both Mono’s
   targets files and MS’s targets files. There are a few issues in both
   cases
   that should not be hard to fix.
  
  
   If it does, then we can get rid of our implementation, if not, we
 might
   have to keep both around until we get everyone out of the xbuild
   implementation.
  
  
   Miguel
  
   On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com
   wrote:
  
   There is a new xplat branch in the msbuild repo with many fixes to
   make
   it work on Mono. I’ve been doing additional fixes and I could make
 it
   work
   to build the MonoDevelop solution (some Exec tasks are failing
 though,
   due
   to missing path conversions). I posted my fixes as PRs to the main
   repo, and
   I keep a branch with all of them in my own repo
   (https://github.com/slluis/msbuild/tree/fix-xplat).
  
   What’s the plan for integrating it into Mono?
  
   El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va
   escriure:
  
   Hey guys,
  
   I used the work from Alex to get started, and did some work on my
 own.
  
   I posted all the patches to github.com/mono/msbuild
  
   When using it to bootstrap building itself, it is not breaking at
   invoking NuGet.
  
   I am out of the office until next week, so I think this is as far I
   will
   get.
  
   Miguel
  
  
  
  
  
 
 
 

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

Re: [Mono-dev] Some MSBuild porting progress

[Miguel de Icaza]

Hello,

Question: does XS/MD depend on Microsoft.Build.Engine.dll?

Because we only would need it if the IDE needed it, and in that case,
hopefully we could replace it?

But the idea is to make xbuild the script just use the new msbuild.

Miguel

On Sat, Mar 28, 2015 at 12:02 AM, Atsushi Enomoto atsu...@xamarin.com
wrote:

 Microsoft.Build.dll is the (relatively) new build engine which
 obsoleted Microsoft.Build.Engine.dll. The deprecated one is not in the
 msbuild repo and that's what we use in xbuild.

 Atsushi Eno


 On Sat, Mar 28, 2015 at 4:48 AM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Hello,
 
  I was under the impression that there were different versions of the
 MSBuild
  API?
 
  But I guess we implement the right one?
 
  My main concern was not breaking MonoDevelop, so if we do not break it,
 we
  should be fine.
 
  Let me know when you think you are ready, and we should incorporate
 MSBuild
  into Mono's current build setup.
 
  Miguel
 
  On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez ll...@xamarin.com
 wrote:
 
 
  El 27/03/2015, a les 19:41, Miguel de Icaza mig...@xamarin.com va
  escriure:
 
  Hello Lluis,
 
  I think once we are happy with msbuild, that we should build msbuild as
  part of the standard Mono build process and ship the resulting
 libraries and
  script.
 
  My only concern is whether the public API surface that msbuild has is
 able
  to replace the assemblies that we currently install on the GAC.
 
 
  Yes, it does. The assemblies are Microsoft.Build,
  Microsoft.Build.Framework, Microsoft.Build.Tasks and
  Microsoft.Build.Utilities. We have partial implementations of those in
 Mono.
  The msbuild repo fully implements all of them.
 
  We can also use the .targets files included in the msbuild repo. I’ve
 been
  able to mostly build MD using the new libraries and using both Mono’s
  targets files and MS’s targets files. There are a few issues in both
 cases
  that should not be hard to fix.
 
 
  If it does, then we can get rid of our implementation, if not, we might
  have to keep both around until we get everyone out of the xbuild
  implementation.
 
 
  Miguel
 
  On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com
 wrote:
 
  There is a new xplat branch in the msbuild repo with many fixes to make
  it work on Mono. I’ve been doing additional fixes and I could make it
 work
  to build the MonoDevelop solution (some Exec tasks are failing though,
 due
  to missing path conversions). I posted my fixes as PRs to the main
 repo, and
  I keep a branch with all of them in my own repo
  (https://github.com/slluis/msbuild/tree/fix-xplat).
 
  What’s the plan for integrating it into Mono?
 
  El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va
  escriure:
 
  Hey guys,
 
  I used the work from Alex to get started, and did some work on my own.
 
  I posted all the patches to github.com/mono/msbuild
 
  When using it to bootstrap building itself, it is not breaking at
  invoking NuGet.
 
  I am out of the office until next week, so I think this is as far I
 will
  get.
 
  Miguel
 
 
 
 
 

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

Re: [Mono-dev] Some MSBuild porting progress

[Miguel de Icaza]

Hello,

I was under the impression that there were different versions of the
MSBuild API?

But I guess we implement the right one?

My main concern was not breaking MonoDevelop, so if we do not break it, we
should be fine.

Let me know when you think you are ready, and we should incorporate MSBuild
into Mono's current build setup.

Miguel

On Fri, Mar 27, 2015 at 3:31 PM, Lluis Sanchez ll...@xamarin.com wrote:


 El 27/03/2015, a les 19:41, Miguel de Icaza mig...@xamarin.com va
 escriure:

 Hello Lluis,

 I think once we are happy with msbuild, that we should build msbuild as
 part of the standard Mono build process and ship the resulting libraries
 and script.

 My only concern is whether the public API surface that msbuild has is able
 to replace the assemblies that we currently install on the GAC.


 Yes, it does. The assemblies are Microsoft.Build,
 Microsoft.Build.Framework, Microsoft.Build.Tasks and
 Microsoft.Build.Utilities. We have partial implementations of those in
 Mono. The msbuild repo fully implements all of them.

 We can also use the .targets files included in the msbuild repo. I’ve been
 able to mostly build MD using the new libraries and using both Mono’s
 targets files and MS’s targets files. There are a few issues in both cases
 that should not be hard to fix.


 If it does, then we can get rid of our implementation, if not, we might
 have to keep both around until we get everyone out of the xbuild
 implementation.


 Miguel

 On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com wrote:

 There is a new xplat branch in the msbuild repo with many fixes to make
 it work on Mono. I’ve been doing additional fixes and I could make it work
 to build the MonoDevelop solution (some Exec tasks are failing though, due
 to missing path conversions). I posted my fixes as PRs to the main repo,
 and I keep a branch with all of them in my own repo (
 https://github.com/slluis/msbuild/tree/fix-xplat).

 What’s the plan for integrating it into Mono?

 El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va
 escriure:

 Hey guys,

 I used the work from Alex to get started, and did some work on my own.

 I posted all the patches to github.com/mono/msbuild

 When using it to bootstrap building itself, it is not breaking at
 invoking NuGet.

 I am out of the office until next week, so I think this is as far I will
 get.

 Miguel





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

Re: [Mono-dev] Some MSBuild porting progress

[Miguel de Icaza]

Hello Lluis,

I think once we are happy with msbuild, that we should build msbuild as
part of the standard Mono build process and ship the resulting libraries
and script.

My only concern is whether the public API surface that msbuild has is able
to replace the assemblies that we currently install on the GAC.   If it
does, then we can get rid of our implementation, if not, we might have to
keep both around until we get everyone out of the xbuild implementation.

Miguel

On Fri, Mar 27, 2015 at 2:33 PM, Lluis Sanchez ll...@xamarin.com wrote:

 There is a new xplat branch in the msbuild repo with many fixes to make it
 work on Mono. I’ve been doing additional fixes and I could make it work to
 build the MonoDevelop solution (some Exec tasks are failing though, due to
 missing path conversions). I posted my fixes as PRs to the main repo, and I
 keep a branch with all of them in my own repo (
 https://github.com/slluis/msbuild/tree/fix-xplat).

 What’s the plan for integrating it into Mono?

 El 19/03/2015, a les 20:40, Miguel de Icaza mig...@xamarin.com va
 escriure:

 Hey guys,

 I used the work from Alex to get started, and did some work on my own.

 I posted all the patches to github.com/mono/msbuild

 When using it to bootstrap building itself, it is not breaking at invoking
 NuGet.

 I am out of the office until next week, so I think this is as far I will
 get.

 Miguel



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

[Mono-dev] Some MSBuild porting progress

[Miguel de Icaza]

Hey guys,

I used the work from Alex to get started, and did some work on my own.

I posted all the patches to github.com/mono/msbuild

When using it to bootstrap building itself, it is not breaking at invoking
NuGet.

I am out of the office until next week, so I think this is as far I will
get.

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

Re: [Mono-dev] PR1155

[Miguel de Icaza]

Ah, thanks for providing the answers to the comments.

This pull request has been merged.

On Fri, Mar 6, 2015 at 9:25 AM, Steffen Kieß 
steffen.ki...@ipvs.uni-stuttgart.de wrote:

 Hello,

 pull request https://github.com/mono/mono/pull/1155 fixes some issues
 with string handling in System.Json:
 - Escape control characters, as required by JSON spec
 - Escape invalid surrogate pairs
 - Escape characters invalid in JavaScript strings
 - Escape / for HTML script tags
 - Fix serialization of chars

 Can someone take a look at the pull request / tell me if I should change
 anything?


 Steffen Kieß
 ___
 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] crash at mono_class_vtable

[Miguel de Icaza]

Hello,

This looks like the code that you are trying to create has been linked out.
  You need to preserve the code (reference it in some form from your code,
to prevent the linker from killing the code, as it would not be present on
device).

But that is as much of a guess as I can offer without looking at the actual
code.

Also, the Mono desktop version has nothing to do with the Mono on the
simulator version.

Miguel

On Thu, Feb 26, 2015 at 1:12 AM, techi eth techi...@gmail.com wrote:

 Hi All,



 I am getting one exception when running  IPhone application using mono.
 Please find below stack trace.



 Assertion at mini.c:6289, condition `vtable' not met



 Stacktrace:



   at unknown 0x

   at IPhone.MainService..ctor () 0x000ab

   at (wrapper runtime-invoke) object.runtime_invoke_void__this__
 (object,intptr,intptr,intptr) 0x

   at unknown 0x

   at (wrapper managed-to-native)
 System.Reflection.MonoCMethod.InternalInvoke
 (System.Reflection.MonoCMethod,object,object[],System.Exception)
 0x

   at System.Reflection.MonoCMethod.InternalInvoke (object,object[])
 0x0003b

   at System.Activator.CreateInstance (System.Type,bool) 0x0018b

   at System.Activator.CreateInstance (System.Type) 0x00017

   at System.Reflection.Assembly.CreateInstance (string,bool) 0x0006f

   at System.Reflection.Assembly.CreateInstance (string) 0x0001f



 Below is the detail of mono version.

 mono --version

 Mono JIT compiler version 3.10.0 (tarball Mon Dec  8 11:37:11 GMT 2014)

 Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
 www.mono-project.com

 TLS:   __thread

 SIGSEGV:   normal

 Notifications: epoll

 Architecture:  armel,vfp+fallback

 Disabled:  aot,profiler

 Misc:  softdebug

 LLVM:  supported, not enabled.

 GC:sgen



 Regards,

 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

Re: [Mono-dev] Patch for Bug 8207: Can't set 1000000 baud with System.IO.Ports.SerialPort.BaudRate

[Miguel de Icaza]

Applied, and updated also to support Mac.

On Tue, Feb 24, 2015 at 3:45 PM, Christian Hofstaedtler 
ch---mono-de...@zeha.at wrote:

 This patch (against mono-2.10.8.1 from Debian) allows setting
 custom baud rates, and very likely would support a baudrate of
 100.

 I release this patch under the MIT license.


 --- serial.c.orig   2013-01-30 12:06:52.379691461 +0100
 +++ serial.c.orig   2013-01-30 13:05:50.383390154 +0100
 @@ -17,6 +17,11 @@
  #endif
  #include sys/ioctl.h

 +/* This is for ASYNC_*, serial_struct on linux */
 +#if defined(__linux__)
 +#include linux/serial.h
 +#endif
 +
  #include glib.h

  /* This is for FIONREAD on solaris */
 @@ -151,6 +156,7 @@
  set_attributes (int fd, int baud_rate, MonoParity parity, int dataBits,
 MonoStopBits stopBits, MonoHandshake handshake)
  {
 struct termios newtio;
 +   gboolean custom_baud_rate = FALSE;

 if (tcgetattr (fd, newtio) == -1)
 return FALSE;
 @@ -227,8 +233,10 @@
 break;
 case 50:
 case 0:
 -   default:
 baud_rate = B9600;
 +   break;
 +   default:
 +   custom_baud_rate = TRUE;
 break;
 }

 @@ -319,16 +327,54 @@
 newtio.c_iflag |= IXOFF | IXON;
 break;
 }
 -
 -   if (cfsetospeed (newtio, baud_rate)  0 || cfsetispeed (newtio,
 baud_rate)  0 ||
 -   tcsetattr (fd, TCSANOW, newtio)  0)
 +
 +   if (custom_baud_rate == FALSE)
 {
 -   return FALSE;
 +   if (cfsetospeed (newtio, baud_rate)  0 || cfsetispeed
 (newtio, baud_rate)  0)
 +   {
 +   return FALSE;
 +   }
 }
 else
 {
 -   return TRUE;
 +   /* On Linux, to set a custom baud rate, we must set the
 standard baud_rate
 +* to 38400. */
 +   if (cfsetospeed (newtio, B38400)  0 || cfsetispeed
 (newtio, B38400)  0)
 +   {
 +   return FALSE;
 +   }
 +   }
 +
 +   if (tcsetattr (fd, TCSANOW, newtio)  0)
 +   {
 +   return FALSE;
 +   }
 +
 +   if (custom_baud_rate == TRUE)
 +   {
 +#if defined(__linux__)
 +   struct serial_struct ser;
 +
 +   if (ioctl (fd, TIOCGSERIAL, ser)  0)
 +   {
 +   return FALSE;
 +   }
 +
 +   ser.custom_divisor = ser.baud_base / baud_rate;
 +   ser.flags = ~ASYNC_SPD_MASK;
 +   ser.flags |= ASYNC_SPD_CUST;
 +
 +   if (ioctl (fd, TIOCSSERIAL, ser)  0)
 +   {
 +   return FALSE;
 +   }
 +#else
 +   /* Don't know how to set custom baud rate on this
 platform. */
 +   return FALSE;
 +#endif
 }
 +
 +   return TRUE;
  }


 ___
 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] Patch for Bug 8207: Can't set 1000000 baud with System.IO.Ports.SerialPort.BaudRate

[Miguel de Icaza]

Hello Christian,

This looks fine.  Are you the original author of the patch?

Miguel

On Tue, Feb 24, 2015 at 3:45 PM, Christian Hofstaedtler 
ch---mono-de...@zeha.at wrote:

 This patch (against mono-2.10.8.1 from Debian) allows setting
 custom baud rates, and very likely would support a baudrate of
 100.

 I release this patch under the MIT license.


 --- serial.c.orig   2013-01-30 12:06:52.379691461 +0100
 +++ serial.c.orig   2013-01-30 13:05:50.383390154 +0100
 @@ -17,6 +17,11 @@
  #endif
  #include sys/ioctl.h

 +/* This is for ASYNC_*, serial_struct on linux */
 +#if defined(__linux__)
 +#include linux/serial.h
 +#endif
 +
  #include glib.h

  /* This is for FIONREAD on solaris */
 @@ -151,6 +156,7 @@
  set_attributes (int fd, int baud_rate, MonoParity parity, int dataBits,
 MonoStopBits stopBits, MonoHandshake handshake)
  {
 struct termios newtio;
 +   gboolean custom_baud_rate = FALSE;

 if (tcgetattr (fd, newtio) == -1)
 return FALSE;
 @@ -227,8 +233,10 @@
 break;
 case 50:
 case 0:
 -   default:
 baud_rate = B9600;
 +   break;
 +   default:
 +   custom_baud_rate = TRUE;
 break;
 }

 @@ -319,16 +327,54 @@
 newtio.c_iflag |= IXOFF | IXON;
 break;
 }
 -
 -   if (cfsetospeed (newtio, baud_rate)  0 || cfsetispeed (newtio,
 baud_rate)  0 ||
 -   tcsetattr (fd, TCSANOW, newtio)  0)
 +
 +   if (custom_baud_rate == FALSE)
 {
 -   return FALSE;
 +   if (cfsetospeed (newtio, baud_rate)  0 || cfsetispeed
 (newtio, baud_rate)  0)
 +   {
 +   return FALSE;
 +   }
 }
 else
 {
 -   return TRUE;
 +   /* On Linux, to set a custom baud rate, we must set the
 standard baud_rate
 +* to 38400. */
 +   if (cfsetospeed (newtio, B38400)  0 || cfsetispeed
 (newtio, B38400)  0)
 +   {
 +   return FALSE;
 +   }
 +   }
 +
 +   if (tcsetattr (fd, TCSANOW, newtio)  0)
 +   {
 +   return FALSE;
 +   }
 +
 +   if (custom_baud_rate == TRUE)
 +   {
 +#if defined(__linux__)
 +   struct serial_struct ser;
 +
 +   if (ioctl (fd, TIOCGSERIAL, ser)  0)
 +   {
 +   return FALSE;
 +   }
 +
 +   ser.custom_divisor = ser.baud_base / baud_rate;
 +   ser.flags = ~ASYNC_SPD_MASK;
 +   ser.flags |= ASYNC_SPD_CUST;
 +
 +   if (ioctl (fd, TIOCSSERIAL, ser)  0)
 +   {
 +   return FALSE;
 +   }
 +#else
 +   /* Don't know how to set custom baud rate on this
 platform. */
 +   return FALSE;
 +#endif
 }
 +
 +   return TRUE;
  }


 ___
 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] Switch off the Jenkins ARM builds on PRs for now

[Miguel de Icaza]

Hey,

We could do the ARM runs only for things that touch mono/mono.   While it
is not perfect, it is a close enough approximation for what we care.

Miguel

On Thu, Feb 19, 2015 at 3:01 PM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 I very much agree, but currently when multiple PR builds are scheduled
 you're waiting a couple of hours for the result which is not ideal either.
 Jo advised me to bring this up on the mailing list, I'm not really happy
 with my suggestion as well...

 -- Alex

 --
 Date: Thu, 19 Feb 2015 16:53:34 -0500
 Subject: Re: [Mono-dev] Switch off the Jenkins ARM builds on PRs for now
 From: kump...@gmail.com
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com


 Why should we not test changes on ARM?

 It's as important as the intel targets and breaking it comes with the same
 issues.

 On Thu, Feb 19, 2015 at 4:18 PM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 The Jenkins ARM builds cause quite some delays in PR building as they are
 slower than an amd64/i386 build and Jenkins can only start the next build
 when the previous one finished on all architectures.

 What's your opinion on switching off the ARM builds for pull requests for
 now until more workers can be brought online to better handle PR spikes?

 -- Alex



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



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


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

Re: [Mono-dev] Build problems

[Miguel de Icaza]

This looks like it was recently fixed.

MIguel

On Wed, Feb 18, 2015 at 11:48 AM, Neale Ferguson ne...@sinenomine.net
wrote:

 Over the last couple of days I’ve had problems building from head on
 s390x.

 (1) When I use 3.6.1 I get:

 MCS [basic] mscorlib.dll
 warning CS2002: Source file
 `../../../external/referencesource/mscorlib/system/globalization/bidicatego
 ry.cs' specified multiple times
 warning CS2002: Source file
 `../../../external/referencesource/mscorlib/system/globalization/charunicod
 einfo.cs' specified multiple times
 warning CS2002: Source file
 `../../../external/referencesource/mscorlib/system/globalization/globalizat
 ionassembly.cs' specified multiple times
 ../../../external/referencesource/mscorlib/system/collections/compatiblecom
 parer.cs(23,25): warning CS1635: Cannot restore warning `CS0618' because
 it was disabled globally
 ../../../external/referencesource/mscorlib/system/collections/compatiblecom
 parer.cs(67,25): warning CS1635: Cannot restore warning `CS0618' because
 it was disabled globally
 ../../../external/referencesource/mscorlib/system/collections/hashtable.cs(
 1206,25): warning CS1635: Cannot restore warning `CS0618' because it was
 disabled globally
 ../../../external/referencesource/mscorlib/system/collections/hashtable.cs(
 1244,25): warning CS1635: Cannot restore warning `CS0618' because it was
 disabled globally
 ../../../external/referencesource/mscorlib/system/collections/hashtable.cs(
 1270,25): warning CS1635: Cannot restore warning `CS0618' because it was
 disabled globally
 ../../../external/referencesource/mscorlib/system/threading/Tasks/TaskSched
 uler.cs(50,25): warning CS1635: Cannot restore warning `CS0618' because it
 was disabled globally
 System/TimeZoneInfo.cs(1414,30): warning CS0219: The variable
 `ambiguousStartModified' is assigned but its value is never used
 System/TimeZoneInfo.cs(1415,30): warning CS0219: The variable
 `ambiguousEndModified' is assigned but its value is never used
 ../../../external/referencesource/mscorlib/system/text/asciiencoding.cs(502
 ,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/text/asciiencoding.cs(683
 ,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/text/unicodeencoding.cs(4
 93,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/text/unicodeencoding.cs(4
 93,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/text/unicodeencoding.cs(7
 77,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/text/unicodeencoding.cs(7
 77,21): error CS0165: Use of unassigned local variable `ch'
 ../../../external/referencesource/mscorlib/system/threading/Tasks/Parallel.
 cs(125,21): warning CS0472: The result of comparing value type
 `System.Threading.CancellationToken' with null is always `false'
 ../../../external/referencesource/mscorlib/system/threading/Tasks/Parallel.
 cs(126,21): warning CS0162: Unreachable code detected
 Compilation failed: 6 error(s), 10 warnings


 The code looks correct in those files, it appears to be a compiler error.
 I tried initializing the variable ch but that results in a different
 problem.

 (2) When I use monolite-latest things go bizarre and appear endian-related:

 /home/neale/Mono/mono/mcs/class/lib/monolite/basic.exe:
 /home/neale/Mono/mono/mcs/class/lib/monolite/basic.exe: cannot execute
 binary file
 make[6]: *** [build/deps/basic-profile-check.exe] Error 126
 *** The compiler '/home/neale/Mono/mono/mcs/class/lib/monolite/basic.exe'
 doesn't appear to be usable.
 *** Trying the 'monolite' directory.
 .miudlc/moom/nabis-crpfoli-ehcce.ksc1(0,:)e rrroC 1S25:5U
 enpxceet dysbmlo` suinSy'
 'miudlc/moom/nabis-crpfoli-ehcce.ksc2(,535:)e rrroC 1S10:0N
 weileni  nocsnattn
 nmiudlc/moom/nabis-crpfoli-ehcce.ksc2(,632:)e rrroC 1S10:0N
 weileni  nocsnattn
 nmiudlc/moom/nabis-crpfoli-ehcce.ksc3(,9)4 :reor rSC5098
 :nIetnrlac moipel rreor rudirgnp raisgnyStsmeF.roamEtcxpeitno :nUnkwo
 nhcra
 a  tyStsmeD.uolb.eaPsr eS(syet.mtSirgns  ,uNbmretSlyses ytel
 ,FIroamPtorived rrpvodire )0[0x ]ni ifelanemu knonnw: 0
 a  toMonC.hSra.poTekinez.rdaujtsr_ae lT(pyCedo e,tL cotaoi nol)c[
 x0]0i  nflinema enunkwon0:
taM no.oSCahprT.konezirei._sunbmre( nI3t 2,cB ooelnad toeLda )0[0x
 ]ni ifelanemu knonnw: 0
 a  toMonC.hSra.poTekinez.rtxkone(  )0[0x ]ni ifelanemu knonnw: 0
 a  toMonC.hSra.poTekinez.rotek n)([ x0]0i  nflinema enunkwon0:
taM no.oSCahprC.hSraPpraes.ryyapsr ey(Iypntuy Lyxe )0[0x ]ni
 ifelanemu knonnw: 0
 a  toMonC.hSra.pSCahpraPsrrep.raes(  )0[0x ]ni ifelanemu knonnw: 0
 Copmlitaoi naflide : 4reor(r)s , 0awnrings

 Neale

 ___
 Mono-devel-list mailing list
 

Re: [Mono-dev] Google Summer Of Code (GSOC) 2015

[Miguel de Icaza]

Hello,

Yes, we are planning on applying to this year Google Summer of Code.

Miguel

On Tue, Feb 17, 2015 at 12:30 PM, Ahmed GameHackerPM 
gamehacke...@hotmail.com wrote:

 Greetings,

 I just want to ask you if you will join this year in GSOC, if you will,
 what will be the ideas list for this year?
 I'm willing to contribute to your project. I got some skills in C#, i made
 some little programs before, developed in some other programs/bots and
 created many useful projects for some people.
 All what i do is for helping people, i don't care about money or waiting
 for them to pay or something like that. I just love to help people that
 makes me happy.
 My age is 19. I'm Level 2 at MUST Computer Science university, but i
 teach myself by myself to be able to code in C#.

 Have a nice day!

 Regards,
 Ahmed Osama (GH).

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


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

Re: [Mono-dev] Error building mono on x86

[Miguel de Icaza]

Hello,

I am not sure why you are passing a --host command line option.   Configure
should be able to figure this out on its own.

Miguel

On Tue, Feb 17, 2015 at 6:29 PM, Rafael Mueller - Inventti 
raf...@inventti.com.br wrote:

  Hi there,


  My (c#) application (compiled on windows, as x86) needs to load a 32
 bits library (.so), so I must compile mono as x86, right?


  I've downloaded the 3.12 source and configured it with

 ./configure --host=i386-pc-linux-gnu


  But it always fails to compile:

 In file included from mono-context.c:8:0:
 mono-context.c: In function ‘mono_sigctx_to_monoctx’:
 ../../mono/utils/mono-sigcontext.h:144:74: error: ‘REG_EAX’ undeclared
 (first use in this function)
   #define UCONTEXT_REG_EAX(ctx) (((ucontext_t*)(ctx))-uc_mcontext.gregs
 [REG_EAX])


  I've tried to add AC_GNU_SOURCE on configure.ac and also compiling with
 CFLAGS=$CFLAGS -D_GNU_SOURCE but I still can't compile it.


  I'm doing anything wrong? Any other advice to compile it on x86?


  I've also tried with mono 3.2.3 and 3.6, without success.


  Kind regards,

 Rafael

 ___
 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] making mono builds reproducible (xamarin bz #26842)

[Miguel de Icaza]

Hey guys,

I assume this is related to the unique identifier generated on each ECMA
assembly?

The issue here is that this goes against the requirements of the spec.

What exactly is being proposed here?

On Mon, Feb 16, 2015 at 7:06 PM, Daniel Kahn Gillmor d...@fifthhorseman.net
wrote:

 On Mon 2015-02-16 18:17:53 -0500, Michael McGlothlin wrote:
  I'd always store time in epochs. Seconds since 1/1/1970 GMT.
 
  The use of textual date strings instead of a epochs is one of the
  worst things I've seen from the C# way of doing things. I had often
  wondered why so many programs could have so much trouble with handling
  dates and times correctly..

 I agree that silly standards like RFC 822 timestamps are crazy and
 should not be used anywhere we can avoid them.

 However, the ISO-8601 date/timestamp format is both human- and
 machine-parseable, whereas most humans can't look at a UNIX epoch
 timestamp and know even whether it's in the past or the future.

 That said, i really care more about reproducibility than i do about any
 particular timestamp format.  if folks are fine with UNIX epoch
 timestamps and with the environment variable interfacfe Jo proposes,
 i'll be happy with that.  Is this something that could be adopted
 upstream?

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

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

Re: [Mono-dev] WCF WebServiceHost crashes mono if client disconnects early

[Miguel de Icaza]

Hello, [ I am CCing Atsushi so he can eyeball the patch ]

Thanks for the background research and for pointing me to that
long-standing bug.

It seems like a pull request was created, but that the author closed the
pull request.

I have updated the patch, can you try this and report back?

https://gist.github.com/migueldeicaza/01aaf064b1bf626f8cc0

Atsushi, does the above look correct?   And is Console.WriteLine the right
thing to do there, or should we use some other mechanism?

Miguel

On Sat, Feb 14, 2015 at 6:24 PM, Horst Müller alexhg...@gmail.com wrote:

 Greetings!

 I've stumbled upon what I believe to be a rather serious problem in mono's
 WCF implementation.

 When a client disconnects during a transmission from a WebServiceHost, an
 exception is thrown:

 Exception Write failure   at System.Net.Sockets.NetworkStream.Write
 (System.Byte[] buffer, Int32 offset, Int32 size) [0x0008e] in
 /build/mono/src/mono-3.12.0/mcs/class/System/System.Net.Sockets/NetworkStream.cs:418

   at System.Net.ResponseStream.InternalWrite (System.Byte[] buffer, Int32
 offset, Int32 count) [0x00029] in
 /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:132

   at System.Net.ResponseStream.Write (System.Byte[] buffer, Int32 offset,
 Int32 count) [0x000dd] in
 /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:165

   at System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
 (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00157] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:160

   at System.ServiceModel.Channels.Http.HttpRequestContext.Reply
 (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x0] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101

   at System.ServiceModel.Dispatcher.MessageProcessingContext.Reply
 (Boolean useTimeout) [0x00026] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/MessageProcessingContext.cs:96

   at System.ServiceModel.Dispatcher.OperationInvokerHandler.Reply
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc, Boolean
 useTimeout) [0x0001d] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:69

   at System.ServiceModel.Dispatcher.OperationInvokerHandler.ProcessRequest
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00044] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:29

   at
 System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x0] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:15

   at
 System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00017] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:16

   at System.ServiceModel.Dispatcher.HandlersChain.ProcessRequestChain
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0xb] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:72

   at System.ServiceModel.Dispatcher.BaseRequestProcessor.ProcessRequest
 (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00018] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:26


 This exception gets caught and rethrown until it ends up at
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:596,
 where ProcessErrorWithHandlers returns false and we reply to the
 RequestContext with an error message. This then generates a second
 exception that is not caught, crashing the whole program:

 Unhandled Exception:
 System.InvalidOperationException: Cannot be changed after headers are sent.
   at System.Net.HttpListenerResponse.set_ContentType (System.String value)
 [0x00027] in
 /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/HttpListenerResponse.cs:110

   at
 System.ServiceModel.Channels.Http.HttpStandaloneResponseInfo.set_ContentType
 (System.String value) [0x0] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpContextInfo.cs:274

   at System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply
 (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00046] in
 /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:140

   at 

Re: [Mono-dev] xsp-3.12 RPM package is missing in mono-project's CentOS repository

[Miguel de Icaza]

That looks like a bad package.

XSP should not depend on a specific version of Mono, instead it should
require at least a specific version of Mono.

CCing Jo.

On Mon, Feb 9, 2015 at 11:46 AM, sean_houston sean.sta...@aesir-media.com
wrote:

 apache2-mod_mono-3.12 is available in the CentOS package repo; however, the
 repo is missing xsp-3.12.  This is forcing the use of apache2-mod_mono-3.8
 since xsp-3.12 is a requirement for installing apache2-mod_mono-3.12.  Will
 it be possible for the package maintainer(s) to release xsp-3.12 in the
 near
 future?  Information from my system follows:

 # yum update apache2-mod_mono
 snipped
 Resolving Dependencies
 -- Running transaction check
 --- Package apache2-mod_mono.x86_64 0:3.8-0 will be updated
 --- Package apache2-mod_mono.x86_64 0:3.12-0 will be an update
 -- Processing Dependency: xsp = 3.12 for package:
 apache2-mod_mono-3.12-0.x86_64
 -- Finished Dependency Resolution
 Error: Package: apache2-mod_mono-3.12-0.x86_64
 (download.mono-project.com_repo_centos_)
Requires: xsp = 3.12
Installed: xsp-3.8-0.x86_64
 (@download.mono-project.com_repo_centos_)
xsp = 3.8-0
  You could try using --skip-broken to work around the problem
  You could try running: rpm -Va --nofiles --nodigest

 

 Here are the currently-installed mono packages:
 # yum list installed \*mono\* \*xsp\*
 snipped
 Installed Packages
 apache2-mod_mono.x86_64   3.8-0
 libmono-2_0-1.x86_64  3.12.0-1
 libmono-2_0-devel.x86_64  3.12.0-1
 libmonoboehm-2_0-1.x86_64 3.12.0-1
 libmonoboehm-2_0-devel.x86_64 3.12.0-1
 libmonosgen-2_0-1.x86_64  3.12.0-1
 libmonosgen-2_0-devel.x86_64  3.12.0-1
 mono-complete.x86_64  3.12.0-1
 mono-core.x86_64  3.12.0-1
 mono-data.x86_64  3.12.0-1
 mono-data-oracle.x86_64   3.12.0-1
 mono-data-postgresql.x86_64   3.12.0-1
 mono-data-sqlite.x86_64   3.12.0-1
 mono-devel.x86_64 3.12.0-1
 mono-entityframework.x86_64   3.12.0-1
 mono-extras.x86_643.12.0-1
 mono-locale-extras.x86_64 3.12.0-1
 mono-mvc.x86_64   3.12.0-1
 mono-nunit.x86_64 3.12.0-1
 mono-reactive.x86_64  3.12.0-1
 mono-wcf.x86_64   3.12.0-1
 mono-web.x86_64   3.12.0-1
 mono-winforms.x86_64  3.12.0-1
 mono-winfxcore.x86_64 3.12.0-1
 monodoc-core.x86_64   3.12.0-1
 xsp.x86_643.8-0

 

 Enabled repositories:
 # yum repolist enabled
 snipped
 repo id repo name
 status
 base/7/x86_64   CentOS-7 - Base
 8,465
 download.mono-project.com_repo_centos_  added from:
 http://download.mono-project.com/repo/centos/199
 epel/x86_64 Extra Packages for Enterprise Linux
 7 - x86_64 7,195
 extras/7/x86_64 CentOS-7 - Extras
 104
 updates/7/x86_64CentOS-7 - Updates
 1,668

 Thanks!
 Sean



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/xsp-3-12-RPM-package-is-missing-in-mono-project-s-CentOS-repository-tp4665433.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] Integration Tests

[Miguel de Icaza]

Hello Edward,

We are doing a few things in the space:

   - We are setting up a more comprehensive harness for SSL/TLS tests that
   do not depend on remote servers.
   - We are setting up a series of web tests to more comprehensively test
   the http client (the tests today are not complete enough).
   - We are bringing Microsoft's ReferenceSource HTTP stack, SslStream to
   Mono.
   - We are developing a new TLS/SSL stack to allow this to be plugged into
   the above (as the Microsoft implementation depends on Windows APIs).

Some code we have finally checked into branches, some code we have not yet.
  It is not ready for landing into master, but we are actively working on
these.

Cheers,
Miguel

On Wed, Feb 4, 2015 at 7:32 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

 Does Mono have any sort of integration tests?  Maybe that's where this
 belongs?  I would like to make sure at some point, SslStream will be fixed,
 and the reason it hasn't happened so far was because nobody ever tested it
 with intermediate chain served by the server, which is of course the
 typical real world usage - I wrote a unit test for it, but have not had any
 progress getting it accepted, mono developers aloof and unresponsive, don't
 know why - I guess it's because it's more an integration test and not
 really a unit test - the inactive pull request is here:

 https://github.com/mono/mono/pull/1490

 I also have not been able to get any response from Martin Baulig, working
 on the updated TLS code, so it seems likely SslStream will continue to be
 useless as a server, unless something gives...
 https://trello.com/c/PvUaV89u/16-tls-stack

 ___
 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] Want to contribute

[Miguel de Icaza]

Hello Aman,

Thanks for your interest.   This is a good place to start:

http://www.mono-project.com/community/contributing/

Miguel

On Sun, Feb 1, 2015 at 5:22 AM, Aman Priyadarshi aman.eur...@gmail.com
wrote:

 Hello everybody,
 I'm Aman from India.I want to contribute to this project. So, in order
 that i've setup build environment and all. Can anybody please guide me,
 from where can i start my journey?

 Thanks in advance.

 Sorry for bad english :/

 Greetings

 *Aman Priyadarshi*


 ___
 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] Re. PR 1501: Mark hot functions in the runtime.

[Miguel de Icaza]

Hello Jonathan,

There seems to have been a couple of regressions on the test suite, but it
is hard to read from the graph.

Do we know what could have caused this?

On Mon, Jan 26, 2015 at 8:45 PM, Jonathan Purdy jonathan.pu...@xamarin.com
wrote:

 In this pull request[1] I add GCC/Clang’s “__attribute__((hot))” to
 various hot GC functions. This increases code size a small amount, and
 makes a very small improvement in performance—see the attached graph. I
 think actually marking some slow-path/error-handling functions as
 “__attribute__((cold))” would do more to improve branch prediction in cases
 where we haven’t marked things as “G_UNLIKELY”.

 [1]: https://github.com/mono/mono/pull/1501


 ___
 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] llvm and mini

[Miguel de Icaza]

Hey,

This has a couple of stages:

   - Easy, allow for re-JITing of a method (in fact, I think this is one of
   our interview questions)
   - Easy, support regular + LLVM code generation
   - Easy, instrument the code to track hot methods, and set a flag to do
   LLVM code gen
   - Easy, use the first and third bullet points to achieve what you want
   - Very hard: replace a running method with a re-JITed version, this is
   hard because you would need to transplant the state from one set of
   generated code to another one.
   - Very hard: hijack returns to return to re-JITed methods, has the same
   problem as above, but also requires some system to return to the new code.

Miguel

On Wed, Jan 28, 2015 at 2:19 PM, Alex Rønne Petersen a...@alexrp.com
wrote:

 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

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

Re: [Mono-dev] Fork of certmgr - any ideas? (Mono-devel-list Digest, Vol 117, Issue 32)

[Miguel de Icaza]

Yes, we have a partial project that does this.

Not sure where we are at on it, but the last time I checked, it did most of
the class libraries.

On Sat, Jan 24, 2015 at 12:24 PM, Arthur Peka artur.p...@gmail.com wrote:

 In the case of certmgr, was there any complexity in creating the solution
 in MD?  If it's trivial, it might be reasonable for people to just
 generate them when they need them.  If it's non-trivial, it might not be
 unreasonable to include those in the mono sources.

 I beg to differ. There wasn't really any complexity there, but scaffolding
 takes time and energy. Proper solution file could at least be generated
 with make.

 Arthur.

 On Thu, Jan 22, 2015 at 2:25 PM, Edward Ned Harvey (mono) 
 edward.harvey.m...@clevertrove.com wrote:

  From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
  boun...@lists.ximian.com] On Behalf Of Jo Shields
 
  it's
  easier to work with a standalone MD project than the whole Mono tree,
  when doing breakpointing  object inspection

 Something I've certainly done in the past to debug mono sources, was to
 create a MD/XS solution in the mono source dir locally on my system, with a
 really basic console application that referenced some mono classes, so I
 could then debug my console app  step through mono source in the IDE.
 After doing stuff, I chose to commit mono source changes and discard the
 IDE scaffolding because it was trivial.

 In the case of certmgr, was there any complexity in creating the solution
 in MD?  If it's trivial, it might be reasonable for people to just generate
 them when they need them.  If it's non-trivial, it might not be
 unreasonable to include those in the mono sources.



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

Re: [Mono-dev] Fork of certmgr - any ideas?

[Miguel de Icaza]

Hello,

We have to revisit the build scripts that we started last year that are
able to generate an entire solution/projects from the existing Makefiles.

Miguel

On Sat, Jan 24, 2015 at 9:10 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: Arthur Peka [mailto:artur.p...@gmail.com]
 
  I don't see any solution files which can be easily
  built with xbuild/Monodevelop.

 When you reply, please quote what you're responding to, and don't top
 post.  Makes it hard to follow the conversation.  (Etiquette.)

 You clearly have created solution  project files.  I don't know how
 difficult it was, but maybe you missed this comment?
 http://lists.ximian.com/pipermail/mono-devel-list/2015-January/042674.html


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

Re: [Mono-dev] System.Data from referencesource

[Miguel de Icaza]

Hello,

 https://trello.com/c/RnH3O9vJ/18-system-data

 I was aware of the native code in MS' driver, but it looked like it was
 about SNI (transport), Windows-native auth, and other diagnostics.  I
 will investigate a bit more to see if bringing a least the TDS encoder/
 decoder to Mono is possible within my constraints, and keep you posted.


Oh, I was not aware of this.

If this is the case, an entire world of opportunities just opened up.

Please keep us posted.

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

Re: [Mono-dev] Plans for new types/methods in .NET 4.6

[Miguel de Icaza]

Hey,

We will not.

You can use 4_5 as the same define that includes new APIs.

Feel free to add away.

Rationale:

   - there is only one GAC assembly for all the 4.0 based assemblies, so
   there is only one assembly used at runtime
   - The only useful purpose of building 4.5 is to get reference
   assemblies, but:
  - I do not think it is worth it to produce reference assemblies for
  4.5-only
  - Because 4.5-only was never quite complete, so our references would
  be incomplete anyways
  - We just abandoned the idea of building the 4.0 references for
  maintenance cost
   - Not even Microsoft's Shared Source tries to produce the reference
   assemblies from a single code base
   - PCLs are a better contract than 4.0, 4.5 or other contracts might be.

So in short, since we are a smaller project, and we have enough in our
hands, with viable alternatives.

Miguel

On Fri, Jan 23, 2015 at 10:59 AM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 Hey, I'm wondering what the current plan for new types and methods (like
 System.Array.Empty) in .NET 4.6 is?
 Will Mono stick to the net_4_5 profile or will a new profile be created?

 -- Alex


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


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

Re: [Mono-dev] System.Data from referencesource

[Miguel de Icaza]

Hello Damien,

I have not actually talked to Marek about this, but we have discussed
internally a bit what to do with System.Data.

Our current thinking is described here:

https://trello.com/c/RnH3O9vJ/18-system-data

As for your specific questions:

  * If you are in the process of porting the MS SQL driver over, or are
 just picking specific bits at this time;


At this point, we have only done small bits at a time.   I think we can
coordinate over email when we do some work.


   * How likely I am to clash with other initiatives if I start
 submitting similar pull requests against that subtree;


I think it would be difficult, as it is a fairly large space.

  * If there are specific words of caution, or documentation regarding
 the MOBILE defines, and exercising the mobile profile's test suite.


We can build it as we go.

In general MOBILE drops the dependency on System.Configuration.   It is
often used with FULL_AOT (which is used both on iOS and game consoles)
which also removes support for dynamically generated code with the
Reflection.Emit API

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

Re: [Mono-dev] Fork of certmgr - any ideas?

[Miguel de Icaza]

Seems like we have a case of these:

http://tirania.org/blog/archive/2010/Dec-31.html

On Tue, Jan 20, 2015 at 4:36 PM, Arthur Peka artur.p...@gmail.com wrote:

 Hey Andres,

 you don't seem to get my point.
 Firstly, IMO certmgr is *far* better off as a standalone app (not part of
 Mono bundle). That would allow to have much faster development.

 Secondly, from what I know Mono has a lengthy code review process, and
 lack of people who have the right to approve changes. Given that cergmgr is
 not a priority I can imagine how long will it be until request is
 accepted/rejected. I will try to merge my fixes back to certmgr, however,
 and I'm more than sure it will be *months *before any action is taken.
 Hope I'm wrong.

 And lastly, I'm using Visual Studio style as opposed to Mono style.

 Artur.

 On Tue, Jan 20, 2015 at 4:27 PM, Andres G. Aragoneses kno...@gmail.com
 wrote:

 On 17/01/15 21:22, Arthur Peka wrote:

 Hello mono devs,

 as you know, currently certmgr is bundled with Mono which IMO slows its
 development progress. There are some known bugs
 https://bugzilla.xamarin.com/show_bug.cgi?id=3516, and I think overall
 user experience as well as tool's code could be better.

 So I decided to make a standalone fork, maybe you have some ideas that
 could be implemented?

 You can find the fork here https://github.com/arthur-peka/PowerCertmgr
 .


 Hey Arthur, do you have any experience in opensource?

 Forking is only recommended as a last resort, when maintainers are not
 willing to merge your contributions or your longer-term aspirations for the
 project differ from theirs, drastically.

 Have you tried to contribute fixes for the bugs you mention?


 ___
 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] Tests for ParseRouteInfo

[Miguel de Icaza]

Hello,

Considering that we do not even have a test, I think it would be nice to
turn one of the samples on the git discussion into the test.   While not
100% robust, we could check that at least *one* of the interfaces has a
gateway, and perhaps make this into a soft failure for those that do not
actually have a network with a gateway when running the tests.

Miguel

using System;

using System.Net;

using System.Net.NetworkInformation;


public class Test

{

public static void Main()

{

DisplayGatewayAddresses();

}


public static void DisplayGatewayAddresses()

{

Console.WriteLine(Gateways);

NetworkInterface[] adapters  =
NetworkInterface.GetAllNetworkInterfaces();

foreach (NetworkInterface adapter in adapters)

{

IPInterfaceProperties adapterProperties =
adapter.GetIPProperties();

GatewayIPAddressInformationCollection addresses =
adapterProperties.GatewayAddresses;

Console.WriteLine(adapter.Description);

if (addresses.Count 0)

{

foreach (GatewayIPAddressInformation address in addresses)

{

Console.WriteLine(  Gateway Address
. : {0},

address.Address.ToString());

}

Console.WriteLine();

}

}

}

}

On Thu, Jan 15, 2015 at 8:58 AM, Ben Woods woods...@gmail.com wrote:

 Mono is not able to get the system gateway address on Mac OSX or BSD when
 performing GetIPProperties on an a NetworkInterface. This is due to the
 mono class libraries solely utilising the /proc/net/route file, which is
 only available on Linux.

 I have submitted a pull request to fix this here:
 https://github.com/mono/mono/pull/1404

 The last comment on the pull request is that the code looks good, but it
 would be nice to have a test added to the regression test suite. As I
 understand it, the test code would reside
 in mcs/class/System/Test/System.Net.NetworkInformation.

 What do you think the test would look like? Seeing as mono does not
 support setting the routing table, only reading it, it is difficult to
 assert that the default gateway would be.

 Perhaps simply that the code executes without error, regardless of the
 result, even if it is empty (it is possible for a system to not have a
 default route, after all).

 Thoughts?

 --
 From: Benjamin Woods
 woods...@gmail.com

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


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

Re: [Mono-dev] Tests for ParseRouteInfo

[Miguel de Icaza]

Also, thanks so much for this patch!

On Thu, Jan 15, 2015 at 10:16 AM, Miguel de Icaza mig...@xamarin.com
wrote:

 Hello,

 Considering that we do not even have a test, I think it would be nice to
 turn one of the samples on the git discussion into the test.   While not
 100% robust, we could check that at least *one* of the interfaces has a
 gateway, and perhaps make this into a soft failure for those that do not
 actually have a network with a gateway when running the tests.

 Miguel

 using System;

 using System.Net;

 using System.Net.NetworkInformation;


 public class Test

 {

 public static void Main()

 {

 DisplayGatewayAddresses();

 }


 public static void DisplayGatewayAddresses()

 {

 Console.WriteLine(Gateways);

 NetworkInterface[] adapters  =
 NetworkInterface.GetAllNetworkInterfaces();

 foreach (NetworkInterface adapter in adapters)

 {

 IPInterfaceProperties adapterProperties =
 adapter.GetIPProperties();

 GatewayIPAddressInformationCollection addresses =
 adapterProperties.GatewayAddresses;

 Console.WriteLine(adapter.Description);

 if (addresses.Count 0)

 {

 foreach (GatewayIPAddressInformation address in addresses)

 {

 Console.WriteLine(  Gateway Address
 . : {0},

 address.Address.ToString());

 }

 Console.WriteLine();

 }

 }

 }

 }

 On Thu, Jan 15, 2015 at 8:58 AM, Ben Woods woods...@gmail.com wrote:

 Mono is not able to get the system gateway address on Mac OSX or BSD when
 performing GetIPProperties on an a NetworkInterface. This is due to the
 mono class libraries solely utilising the /proc/net/route file, which is
 only available on Linux.

 I have submitted a pull request to fix this here:
 https://github.com/mono/mono/pull/1404

 The last comment on the pull request is that the code looks good, but it
 would be nice to have a test added to the regression test suite. As I
 understand it, the test code would reside
 in mcs/class/System/Test/System.Net.NetworkInformation.

 What do you think the test would look like? Seeing as mono does not
 support setting the routing table, only reading it, it is difficult to
 assert that the default gateway would be.

 Perhaps simply that the code executes without error, regardless of the
 result, even if it is empty (it is possible for a system to not have a
 default route, after all).

 Thoughts?

 --
 From: Benjamin Woods
 woods...@gmail.com

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



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

Re: [Mono-dev] Tests for ParseRouteInfo

[Miguel de Icaza]

It does not need to print to console.

Ignore the soft failure, let us jsut assert if there is no gateway (the
soft failure part of my email was written before I changed my mind, and
forgot to remove it).

Miguel

On Thu, Jan 15, 2015 at 10:28 AM, Ben Woods woods...@gmail.com wrote:

 Should a test really print to the Console? Presumably this should be
 adapted to detect if there is at least one valid route?

 Also, what does a soft failure look like? Is there an example already in
 the mono source?

 Thanks for your help.

 --
 From: Benjamin Woods
 woods...@gmail.com

 On 15 January 2015 at 23:16, Miguel de Icaza mig...@xamarin.com wrote:

 Hello,

 Considering that we do not even have a test, I think it would be nice to
 turn one of the samples on the git discussion into the test.   While not
 100% robust, we could check that at least *one* of the interfaces has a
 gateway, and perhaps make this into a soft failure for those that do not
 actually have a network with a gateway when running the tests.

 Miguel

 using System;

 using System.Net;

 using System.Net.NetworkInformation;


 public class Test

 {

 public static void Main()

 {

 DisplayGatewayAddresses();

 }


 public static void DisplayGatewayAddresses()

 {

 Console.WriteLine(Gateways);

 NetworkInterface[] adapters  =
 NetworkInterface.GetAllNetworkInterfaces();

 foreach (NetworkInterface adapter in adapters)

 {

 IPInterfaceProperties adapterProperties =
 adapter.GetIPProperties();

 GatewayIPAddressInformationCollection addresses =
 adapterProperties.GatewayAddresses;

 Console.WriteLine(adapter.Description);

 if (addresses.Count 0)

 {

 foreach (GatewayIPAddressInformation address in addresses)

 {

 Console.WriteLine(  Gateway Address
 . : {0},

 address.Address.ToString());

 }

 Console.WriteLine();

 }

 }

 }

 }

 On Thu, Jan 15, 2015 at 8:58 AM, Ben Woods woods...@gmail.com wrote:

 Mono is not able to get the system gateway address on Mac OSX or BSD
 when performing GetIPProperties on an a NetworkInterface. This is due to
 the mono class libraries solely utilising the /proc/net/route file, which
 is only available on Linux.

 I have submitted a pull request to fix this here:
 https://github.com/mono/mono/pull/1404

 The last comment on the pull request is that the code looks good, but it
 would be nice to have a test added to the regression test suite. As I
 understand it, the test code would reside
 in mcs/class/System/Test/System.Net.NetworkInformation.

 What do you think the test would look like? Seeing as mono does not
 support setting the routing table, only reading it, it is difficult to
 assert that the default gateway would be.

 Perhaps simply that the code executes without error, regardless of the
 result, even if it is empty (it is possible for a system to not have a
 default route, after all).

 Thoughts?

 --
 From: Benjamin Woods
 woods...@gmail.com

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




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

Re: [Mono-dev] Unix.Native

[Miguel de Icaza]

Just do `make install' on Mono.

On Mon, Jan 12, 2015 at 11:59 PM, Greg Young gregoryyou...@gmail.com
wrote:

 Are there any instructions on building/testing the area (linux)?

 I don't mind jumping in it a bit

 On Tue, Jan 13, 2015 at 6:28 AM, Miguel de Icaza mig...@xamarin.com
 wrote:
  Hey,
 
  Good observation, so passing a -1 is enough.
 
  That said, perhaps we do need to expose a number of overloads with
 various
  possible data types of other sizes.
 
  On Mon, Jan 12, 2015 at 11:23 PM, Greg Young gregoryyou...@gmail.com
  wrote:
 
  I would guess it to be the same for others like F_RDAHEAD
 
  I don't think the long is too horrible as its only defined as 0/non-zero
 
  On Tue, Jan 13, 2015 at 6:15 AM, Miguel de Icaza mig...@xamarin.com
  wrote:
   I added support for this on master.
  
   That said, there is an issue that I think will bite us.
  
   Currently the fcntl P/Invoke declaration uses a long as a general
   purpose
   way of passing flags to fcntl, and I suspect the parameter to
 F_NOCACHE
   should be an int.
  
   Thoughts?
  
   Miguel
  
   On Mon, Jan 12, 2015 at 7:28 PM, Greg Young gregoryyou...@gmail.com
   wrote:
  
   I have been trying to set F_NOCACHE via fcntl on a mac to no avail.
  
r = Syscall.fcntl
   (handle.DangerousGetHandle().ToInt32(), (FcntlCommand) MAC_F_NOCACHE,
   1);
} while (UnixMarshal.ShouldRetrySyscall ((int) r));
if (r == -1)
UnixMarshal.ThrowExceptionForLastError ();
  
   (EINVAL)
  
   I have tried
   48
   0x400
   and 0x4
   for F_NOCACHE though from
  
  
  
 https://github.com/realthunder/mac-headers/blob/master/usr/include/sys/fcntl.h#L256
  
   Given FcntlCommandFlags does not expose F_NOCACHE but it still should
   be fine to jam the value into the enum
  
   Has anyone set this before? Chances of finding this on google are
   slightly better than 0 :)
  
   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] Managed/Unmanaged code debugging

[Miguel de Icaza]

We do not have a simple way to debug both.

You can debug managed with XAmarin Studio, and you can debug unmanaged with
gdb.

On Mon, Jan 12, 2015 at 11:29 PM, techi eth techi...@gmail.com wrote:

 Hi,



 Can anyone suggest me how i can debug unmanned/managed code together using
 mono develop ?



 I have used mono-soft-debugger  successfully debug managed code locally
  remotely.


 *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

Re: [Mono-dev] Unix.Native

[Miguel de Icaza]

I added support for this on master.

That said, there is an issue that I think will bite us.

Currently the fcntl P/Invoke declaration uses a long as a general purpose
way of passing flags to fcntl, and I suspect the parameter to F_NOCACHE
should be an int.

Thoughts?

Miguel

On Mon, Jan 12, 2015 at 7:28 PM, Greg Young gregoryyou...@gmail.com wrote:

 I have been trying to set F_NOCACHE via fcntl on a mac to no avail.

  r = Syscall.fcntl
 (handle.DangerousGetHandle().ToInt32(), (FcntlCommand) MAC_F_NOCACHE,
 1);
  } while (UnixMarshal.ShouldRetrySyscall ((int) r));
  if (r == -1)
  UnixMarshal.ThrowExceptionForLastError ();

 (EINVAL)

 I have tried
 48
 0x400
 and 0x4
 for F_NOCACHE though from

 https://github.com/realthunder/mac-headers/blob/master/usr/include/sys/fcntl.h#L256

 Given FcntlCommandFlags does not expose F_NOCACHE but it still should
 be fine to jam the value into the enum

 Has anyone set this before? Chances of finding this on google are
 slightly better than 0 :)

 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] Unix.Native

[Miguel de Icaza]

Hey,

Good observation, so passing a -1 is enough.

That said, perhaps we do need to expose a number of overloads with various
possible data types of other sizes.

On Mon, Jan 12, 2015 at 11:23 PM, Greg Young gregoryyou...@gmail.com
wrote:

 I would guess it to be the same for others like F_RDAHEAD

 I don't think the long is too horrible as its only defined as 0/non-zero

 On Tue, Jan 13, 2015 at 6:15 AM, Miguel de Icaza mig...@xamarin.com
 wrote:
  I added support for this on master.
 
  That said, there is an issue that I think will bite us.
 
  Currently the fcntl P/Invoke declaration uses a long as a general
 purpose
  way of passing flags to fcntl, and I suspect the parameter to F_NOCACHE
  should be an int.
 
  Thoughts?
 
  Miguel
 
  On Mon, Jan 12, 2015 at 7:28 PM, Greg Young gregoryyou...@gmail.com
 wrote:
 
  I have been trying to set F_NOCACHE via fcntl on a mac to no avail.
 
   r = Syscall.fcntl
  (handle.DangerousGetHandle().ToInt32(), (FcntlCommand) MAC_F_NOCACHE,
  1);
   } while (UnixMarshal.ShouldRetrySyscall ((int) r));
   if (r == -1)
   UnixMarshal.ThrowExceptionForLastError ();
 
  (EINVAL)
 
  I have tried
  48
  0x400
  and 0x4
  for F_NOCACHE though from
 
 
 https://github.com/realthunder/mac-headers/blob/master/usr/include/sys/fcntl.h#L256
 
  Given FcntlCommandFlags does not expose F_NOCACHE but it still should
  be fine to jam the value into the enum
 
  Has anyone set this before? Chances of finding this on google are
  slightly better than 0 :)
 
  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

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

Re: [Mono-dev] CodeContacts open sourced

[Miguel de Icaza]

 Regarding XS/MD support for the code contracts tools, there are really
 two pieces.

 The first is to port/reimplement the VS addin. It doesn't look
 particularly complex, a proof of concept might only take a couple of
 days.


This would be glorious.   They seem to be doing some kind of
source-analysis like support, where they show potential problems.

The second is figuring out how to build and ship the analysis tools,
 contract annotations and MSBuild tasks. AFAIK On Windows they're
 shipped in a MSI installer, but there are scripts to build a NuGet
 package too, though it doesn't seem to be on the public NuGet server.


I think we could ship this with Mono itself (once we figure out how to
build it).

I tried to build it, but failed.Then again, I tried to build on
Windows, and failed too :-)

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

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

[Miguel de Icaza]

Hello Edward,

Martin is creating the branch now where we bring the Microsoft SslStream
into Mono as well as his crypto stack.

For details see:

https://trello.com/c/PvUaV89u/16-tls-stack

On Wed, Dec 17, 2014 at 2:21 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

 I was able to trim this down to a specific subset and make a unit test out
 of it.  Although SslStream has compatibility problems communicating with
 other implementations (such as .Net), mono SslStream also has a problem
 talking to *itself*.  The root causes are the same for both the internal
 compatibility problem, and the external problems.  So the internal problem
 is demonstrated in  the SslStreamTest here:

 https://github.com/rahvee/mono/commit/b0362fe70fb445f90197eab712b8d995f88d78e1

 Should I submit a pull request?  Note:  This test currently passes on
 .Net, and fails on mono.  I don't know if you guys want me submitting a
 test that is known to fail on mono.

 Should I file a bug in bugzilla?  (I'm not sure if I have sufficient
 permission).

 And as a matter of style, in the above commit I needed to use some classes
 that weren't available in the MonoTest namespace, so I used
 global::System. in several places.  Is this the correct and/or best
 way to deal with it?  Or is there a better way to handle that?


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

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

[Miguel de Icaza]

)

 On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza mig...@xamarin.com
 wrote:

 Thanks Alex.

 I do not think that we will have a strict rule for when to copy and when
 to reference.

 There are scenarios where we will want to keep a lot of the code in one of
 our files, and pull code from the referencesource.   At that point, we will
 have to determine whether the use of #ifdefs or partial classes is a better
 long-term maintenance approach than copying the source.

 In this particular case, I feel that we can modify the reference source,
 and add the #if MONO around it.

 The reason is that the changes are pretty straight forward, it is mostly
 about disabling code, and not about picking some specific bits of code and
 putting them on our tree.   So an #if would be nice, since we can do a few
 things (a) we can later find out what code is being disabled by the port
 (looking at work we can do in the future to import new versions, or
 contribute back to .NET) and (b) the changes are minimal right now.

 Miguel

 On Sat, Nov 29, 2014 at 10:59 AM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 Here's the diff between my trimmed version and the original:
 http://www.mergely.com/9E70e5Ls/

 Hmm, I actually think that most of the removed methods don't matter (as
 they aren't called anyway). I just wanted to make the file only contain the
 code that is necessary.
 The only real changes I had to make where accesses to internal fields in
 NumberFormatInfo, I just replaced them with accesses to the public
 properties that read them.

 Maybe it makes more sense to correct those accesses directly in the
 referencesource, so we can reference it from there?
 As a general guidance, when should we copy something to the Mono tree vs.
 editing referencesource? And if we copy, should we keep unneeded methods or
 remove them?

 -- Alex

 --
 From: mig...@xamarin.com
 Date: Sat, 29 Nov 2014 10:40:10 -0500
 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource,
 approaches for copying code?
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com


 Hey Alex,

 In general, the approach works.

 I am curious as to what is that you had to remove, and why.   Can you
 describe the needed changes?   (I saw the diff, but it is hard to tell what
 happened with it).

 I thought that Numerics was pretty much standalone.

 On Sat, Nov 29, 2014 at 10:32 AM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 Hey, I've been trying to port System.Numerics (BigInteger, Complex
 classes) from referencesource to see and feel what the process looks like.
 It mostly went fine, but there was one file (number.cs) I couldn't
 reference directly from the submodule and had to copy to the assembly folder
 in the Mono tree.

 I had to remove a bunch of code from that file to trim it down to only
 what is needed for System.Numerics to compile (all the tests pass now as
 well).
 Question: is this a valid approach or is there something better? Note that
 ifdefing the file wasn't feasible as it originally sits inside corlib and
 has many other unrelated methods in it.

 Here's the commit with the WIP:
 https://github.com/akoeplinger/mono/commit/d7c461155a975a35f76b79ebcc3fe33407bd5dce

 -- Alex

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







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




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

[Mono-dev] CodeContacts open sourced

[Miguel de Icaza]

Hey guys,

Microsoft has open sourced their CodeContracts tools:

https://github.com/CodeContractsDotNet/CodeContracts

The companion class libraries are here:

https://github.com/mono/referencesource/tree/mono/mscorlib/system/diagnostics/contracts

While Mono has an implementation, it might be a good idea to replace them
with the Microsoft version, in case the tools depend on some internal bits.

In addition, it seems like we could enable MonoDevelop/XamarinStudio to
support code contracts now.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] X509Chain

[Miguel de Icaza]

Hello Edward,

I do not believe we have made changes to X509Chain.

The only thing we have been doing is reimplementing chunks of the protocol
(as it does not exist in the referecesource)

Miguel

On Wed, Jan 7, 2015 at 3:57 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  Miguel, you said



  We have implemented TLS 1.1 and 1.2 on top of the not yet open sourced

  networking stack and will be publishing it as soon as Microsoft open
 sources

  the .NET networking stack.



 Have there been unpublished changes to Mono.Security.X509.X509Chain?



 Something I think I could reasonably do, if it's not a waste of time, is
 to improve the Build() method, so it will build a chain using both the
 roots store, and the intermediates store.  And come up with a way of
 populating the intermediates store.  (Such as improvement on mozroots.)



 I wouldn't want to work on that, if it's obsoleted by code that will
 hopefully be published soon...



 ___
 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] WIP: Microsoft's System.Runtime.Serialization

[Miguel de Icaza]

Hey guys,

My work is described here:

https://trello.com/c/L6jkUdOQ/12-system-runtime-serialization

The status of this patch is:

Work in progress to bring Microsoft System.Runtime.Serialization to Mono



The current code compiles by replacing existing Mono code with

Microsoft code (without actually deleting the unreferenced files -

purely to use them as a roadmap for things that we should do to make

the code MOBILE and AOT friendly).



Currently this does not compile the mobile profile assembly, nor has

the code been tested yet.



The code also brings an extensive tracing/logging system that wont

work on Unix as it is based on Window's Event Tracing facility.



We should consider a few options:



   * Allow for the code to be disabled (for release builds on Mobile,

 or for an initial delivery that does not support any tracing

 capabilities).



   * Allow for the tracing framework to be replaced with some other

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

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

[Miguel de Icaza]

Hey,

Sorry, really poor email on my part.

You answered my concern to my satisfaction, so this is good to go.

Miguel

On Mon, Jan 5, 2015 at 12:09 PM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

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

 -- Alex

 --
 From: mig...@xamarin.com
 Date: Wed, 3 Dec 2014 13:34:47 -0500

 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource,
 approaches for copying code?
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com

 Got it.

 Miguel

 On Wed, Dec 3, 2014 at 11:13 AM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

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

 -- Alex

 --
 From: alex.koeplin...@outlook.com
 To: mig...@xamarin.com
 Date: Wed, 3 Dec 2014 17:01:42 +0100
 CC: mono-devel-list@lists.ximian.com

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

 Hey,
 we need to ensure we only continue for the format specifiers used in
 decimalFmt. Any other format specifier (i.e. culture-specific ones) would
 result in a call into unmanaged code later on (
 https://github.com/akoeplinger/referencesource/blob/mono/System.Numerics/System/Numerics/BigNumber.cs#L611-L634)
 which we of course don't have implemented.

 Note that it only throws an exception when decimalFmt == false, i.e. when
 any of the culture-specific specifiers was used (which is *not* a common
 code path). This is exactly what the current Mono code also does:
 https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1470

 -- Alex

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

 Hello Alex,

 I am not sure I am understanding this.

 This looks like we are choosing to not bring features that we are missing?
   Why would we want to do that?

 Miguel

 On Wed, Dec 3, 2014 at 10:33 AM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 Mono today also only supports the format specifiers used in decimalFmt:
 https://github.com/mono/mono/blob/f8a517624de3fdfc070d2f0660fce1b62d41bc4c/mcs/class/System.Numerics/System.Numerics/BigInteger.cs#L1458-L1471

 So using this #if for Mono is the correct way to go.

 (reposted, seems like the mailing list ate my previous mail)

 -- Alex

 --
 From: mig...@xamarin.com
 Date: Sat, 29 Nov 2014 12:06:20 -0500

 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource,
 approaches for copying code?
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com

 Can you explain the rationale for the #if used with the same SILVERLIGHT
 setting?

 It seems like it limits the code.

 On Sat, Nov 29, 2014 at 12:03 PM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 Yeah, that was what I was doing.

 I created these PRs:
 https://github.com/mono/referencesource/pull/1
 https://github.com/mono/mono/pull/1433

 -- Alex

 --
 From: mig...@xamarin.com
 Date: Sat, 29 Nov 2014 11:23:01 -0500

 Subject: Re: [Mono-dev] Porting System.Numerics from referencesource,
 approaches for copying code?
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com

 I just realized it might not have been 100% clear what I think we should
 do.

 We would in this case replace the references to our
 mono/mcs/class/XX/*/*cs source files, with the
 ../../external/referencesource/... files, and then alter the original
 referencesource file with the #if statements.

 We have done that already in a couple of places.

 (More to come, last night we got XML working, but needs some work)

 On Sat, Nov 29, 2014 at 11:21 AM, Miguel de Icaza mig...@xamarin.com
 wrote:

 Thanks Alex.

 I do not think that we will have a strict rule for when to copy and when
 to reference.

 There are scenarios where we will want to keep a lot of the code in one of
 our files, and pull code from the referencesource.   At that point, we will
 have to determine whether the use of #ifdefs or partial classes is a better
 long-term maintenance approach than copying the source.

 In this particular case, I feel that we can modify the reference source,
 and add the #if MONO around it.

 The reason is that the changes are pretty straight forward, it is mostly
 about disabling code, and not about picking some specific bits of code and
 putting them on our tree

[Mono-dev] If you accept pull requests on Mono's github

[Miguel de Icaza]

Hey guys,

If you are accepting pull requests on Mono's github, please request that
pull requests that were iterated multiple-times have their multiple commits
squashed into one.

Otherwise Mono ends up merging code that does things like:

   - Commit 1:
   Implement a feature + reformatted entire file
   - Commit 2:
   Fix bug in first feature
   - Commit 3:
   Undo all the format changes

From a git history perspective, we managed to make the history more
difficult to read for most of the file, not once (from commit 1), but twice
(commit 1 and 2).

So before you merge a patch from the community, please make sure that
either the contributor squashes all their commits into one, or you merge
the commit into one manually and apply the patch.

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

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

[Miguel de Icaza]

Done, this patch can be merged.

Miguel

On Fri, Dec 26, 2014 at 3:05 PM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 Any updates on this? Might be a good review candidate if you have some
 spare time during the holidays :)

 -- Alex

 --
 From: mig...@xamarin.com
 Date: Thu, 30 Oct 2014 17:38:18 -0400
 Subject: Re: [Mono-dev] PR 1081: Allow CLR binaries to be passed to
 Process.Start
 To: alex.koeplin...@outlook.com
 CC: mono-devel-list@lists.ximian.com; kump...@xamarin.com


 In general, it looks fine, but I want to review this in more detail.

 I'll add it to my list.

 On Thu, Oct 30, 2014 at 4:46 PM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:

 This PR (https://github.com/mono/mono/pull/1081) has been sitting in the
 queue for some time. @kumpera already gave his +1 to the patch, so I think
 we could merge it?


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



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

Re: [Mono-dev] PR 1464/1465: xbuild fixes to allow dotnet/corefx to compile with Mono

[Miguel de Icaza]

Hey,

1465 looks great!

I will let someone more experienced with msbuild discuss 1464

On Fri, Dec 19, 2014 at 6:38 AM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 Hey, I sent the following xbuild fixes that are necessary so that the .NET
 Core framework projects can be compiled with Mono:

 https://github.com/mono/mono/pull/1464
 https://github.com/mono/mono/pull/1465

 Please share your feedback :)

 -- Alex


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


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

Re: [Mono-dev] After an initial investigation of porting WCF to mono, this is what I've found so far

[Miguel de Icaza]

My quick take, as I am about to bird a plane:

- ifdef out transactions
- SR missing stuff is pretty common, we have been stubbing these out, check
the recent commits to mono/mcs/class/System to get an idea
- use reference source for the landing spot.

On Tuesday, December 16, 2014, Bernie Schoch bpsch...@gmail.com wrote:

 References to XAML configuration #if XAML out
 References to COM  #if COM out

 There are references to Transaction processing in Microsoft namespace is
 this something we need to support or #if it out?

 There is a ton of stuff missing from System.IdentityModel:
 This is where the majority of the errors lie. 100+ items;  Should I just
 back port this into existing Mono code or use reference source versions?  I
 ask because I don't have much history on mono project and don't really know
 status of System.IdentiyModel.

 What is the strategy to deal with SR messages?  Right now I've just
 created an internal SR and InternalsSR class

 Thanks,
 Bernie Schoch

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