Re: [Mono-dev] Cross Platform on Linux/Windows with Mono.Posix reference on Linux

[Jonathan Pryor]

On Mar 30, 2016, at 8:33 AM, Alan  wrote:
> If you package Mono.Posix.dll your app *will crash* on different systems.

Not necessarily.

> This binary is platform specific and is not safe to copy between OS’s.

Mono.Posix.dll *itself* contains no platform-specific code and is perfectly 
safe to copy between operating systems.

Mono.Posix.dll contains P/Invokes into “MonoPosixHelper” 
(libMonoPosixHelper.dylib on OS X, MonoPosixHelper.dll on Windows, etc.), and 
MonoPosixHelper contains operating system-specific code. It *cannot* be copied 
between operating systems; it’s a native library.

> It's fine to have a copy of Mono.Posix.dll used purely for compilation 
> purposes. But at runtime you have to use the system provided one, which 
> typically means the one provided by the system's mono installation.

It’s entirely fine to include Mono.Posix.dll with your app, SO LONG AS you 
*also* copy and distribute MonoPosixHelper with your app.

Additionally, Mono.Posix.dll also P/Invokes other native libraries such as 
INTL.DLL (Mono.Unix.Catalog) and MSVCRT.DLL (Mono.Unix.Native.Stdlib), which 
should be usable on Windows (so long as you also distribute INTL.DLL, etc.).

 - 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

[Jonathan Pryor]

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

[Jonathan Pryor]

On Sep 2, 2015, at 9:25 AM, Robert Jordan  wrote:
> A sane and easy solution is to deploy Mono.Posing on Windows side-by-side 
> with you app.

Just do that — and distribute MonoPosixHelper.dll as well.

Parts of Mono.Posix.dll are supported on Windows, e.g. Mono.Unix.Native.Stdlib 
and Mono.Unix.Catalog (INTL.DLL wrapper). There should be no harm in 
distributing these files with your app, other than a size increase.

 - Jon

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

Re: [Mono-dev] Mono.Posix Cross Compiling

[Jonathan Pryor]

On Jan 5, 2015, at 6:08 PM, Greg Young gregoryyou...@gmail.com wrote:
 Have anyone used mono.posix or mono.unix.native in a cross compiling scenario 
 where you have to support visual studio builds? How did you handle this? I 
 don't seem to be able to do a platform specific reference.

What's the problem? Mono.Posix.dll is MIT/X11; simply bundle the assembly with 
your code, along with MonoPosixHelper.dll (just copy from the Mono install).

Furthermore, Mono.Unix.Native.Stdlib should work as-is on Windows (it uses 
MSVCRT.dll).

You will need to be careful not to actually use Syscall/etc. on Windows, but 
due to the lazy nature of the JIT this should be reasonably straightforward:

if (running on Unix)
MethodWhichUsesSyscall ();
...

MethodWhichUsesSyscall() won't be JIT'd unless executed, so any references to 
e.g. Syscall will be lazily evaluated, allowing things to work on Windows.

 - Jon

___
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

[Jonathan Pryor]

On Dec 15, 2014, at 6:54 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:
 I'll look into __MonoCS__ to see if it does what I'm looking for.

It is not what you're looking for. __MonoCS__ is defined by the Mono C# 
compiler (mcs); that's all it means.

It doesn't mean that you're building on Linux or Windows (Mono + mcs runs on 
Windows). It doesn't control which runtime mcs is running within (mcs runs 
within .NET as well as Mono). It doesn't control what runtime you're running in 
(mcs output runs on .NET).

About the only use for __MonoCS__ is if you hit an mcs bug and want to work 
around it.

 - Jon

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

Re: [Mono-dev] Using .so file in Android Library Project and then using it in an Android App

[Jonathan Pryor]

On Dec 2, 2014, at 9:09 AM, Burhan Eyuboglu burhaneyubo...@gmail.com wrote:
 When I add libcyusb.so, I got this error: libcyusb.so is not a valid ELF 
 executable

Where do you get this error from? What's the overall context?

 I checked the library, libcyusb.so is not ELF, it is a linker, however 
 libcyusb.so.1 is ELF 64 bit sharerd object. How can add libcyusb.so.1? 
 Because android accepts lib prefix and so suffix.

Android wants a lib prefix and .so suffix. .1 is not .so; if you managed to 
add libcyusb.so.1 to your .apk, it will *not* be installed.

Additionally, Xamarin.Android does not currently support 64-bit processors. 
(It's being worked on.) Consequently, you'll need to target a 32-bit ABI, e.g. 
armeabi-v7a.

Thanks,
 - Jon

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

Re: [Mono-dev] Mono on Embedded Platform

[Jonathan Pryor]

On Nov 23, 2014, at 11:45 PM, techi eth techi...@gmail.com wrote:
 I would be happy if I will get all running under 10 MB.I have listed approx 
 size of few essential. I am not sure how to reduce  get size under 10 MB.

Where are you getting these file sizes? Perhaps you need to strip(1) the 
binaries?

 1)  Mono (link to mono-sgen) : 13 MB

I'm not sure what this means. If you mean the mono binary, you need to strip(1) 
it; on OS X, it's 4.1MB.

 2)  Libmono-2.0.so : 12 MB

You need to strip(1) this binary. On OS X, libmonosgen-2.0.1.dylib is 4.2MB.

Also note that the `mono` binary doesn't require libmono*.so; it statically 
links it in. libmono*.so is for embedding use.

 3)  Mscorelib.dll : 15 MB

Where are you getting this file size? On OS X, the 4.5 mscorlib.dll is 2.9MB.

For example, consider mkbundle(1):

http://docs.go-mono.com/?link=man%3amkbundle(1)

mkbundle(1) can be used to bundle all assemblies into a single file, to 
simplify distribution. Using mkbundle(1), you can have a single native binary 
which only requires libmonoboehm-2.dylib to execute, no additional assemblies, 
by using `mkbundle --deps`:

$ AS='as -arch i386' \
CC='cc -arch i386' \

PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Libraries/pkgconfig \
mkbundle --deps -z hw.exe -o hw2

$ ls -lh hw2
-rwxr-xr-x+ 1 jon  staff   1.0M Nov 24 10:53 hw2

$ nm -ufm hw2
 (undefined) external ___memcpy_chk (from libSystem)
 (undefined) external ___stderrp (from libSystem)
 (undefined) external _exit (from libSystem)
 (undefined) external _fprintf (from libSystem)
 (undefined) external _getenv (from libSystem)
 (undefined) external _inflate (from libz)
 (undefined) external _inflateEnd (from libz)
 (undefined) external _inflateInit2_ (from libz)
 (undefined) external _malloc (from libSystem)
 (undefined) external _memset (from libSystem)
 (undefined) external _mono_main (from libmonoboehm-2)
 (undefined) external _mono_register_bundled_assemblies (from 
libmonoboehm-2)
 (undefined) external _mono_set_dirs (from libmonoboehm-2)
 (undefined) external _printf (from libSystem)
 (undefined) external _strchr (from libSystem)
 (undefined) external _strdup (from libSystem)
 (undefined) external dyld_stub_binder (from libSystem)

With the above setup, Hello world requires only ~5.2MB of disk to run (for 
OS X binaries).

 - Jon

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

Re: [Mono-dev] Using .so file in Android Library Project and then using it in an Android App

[Jonathan Pryor]

On Nov 18, 2014, at 10:05 AM, Burhan Eyuboglu burhaneyubo...@gmail.com wrote:
 While running my code on an Android Device, it gives that error:

This is better asked on forums.xamarin.com...

 [Mono] DllImport error loading library 
 '/storage/emulated/0/Android/data/LibraryDenemesi.LibraryDenemesi/files/.__override__/libcylibusb.dll':
  'Cannot load library: load_library(linker.cpp:746): library 
 /data/data/LibraryDenemesi.LibraryDenemesi/lib//storage/emulated/0/Android/data/LibraryDenemesi.LibraryDenemesi/files/.__override__/libcylibusb.dll
  not found'.

Please see:


http://developer.xamarin.com/guides/android/advanced_topics/MultiCore_devices_XamarinAndroid/#Android_Native_Library_Installation

There should also be a similar DllImport error loading library message 
regarding `libcylibusb.so`, which presumably also isn't found because it isn't 
present. (Or there's a linker error.)

Your .apk should contain the native libraries in `lib/ABI` directories, and 
Android will extract and install the appropriate library into your app's lib 
directory. Either your .apk doesn't contain libcylibusb.so, or it contains 
libcylibusb.so for the wrong ABI and it isn't being installed, or you're 
hitting an Android installation bug.

You need to `unzip -l` your .apk, ensure libcylibusb.so exists for the ABI that 
your target is running, and (preferably) have a copy of libcylibusb.so for each 
lib/ABI directory within the .apk.

 - Jon

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

Re: [Mono-dev] a set of tests to find out the difference between .Net and Mono implementation

[Jonathan Pryor]

On Sep 16, 2014, at 6:10 AM, 何子杰Hzj_jie hzj_...@hotmail.com wrote:
 1. GC
 thought GC.Collect() does not guarantee all the inaccessible objects are 
 finalized and reclaimed, .Net implementation usually be able to delete all 
 the inaccessible objects.
 impacts, delegate_pinning_test, it make sure the delegate / event in .net 
 will release the object after itself has been released.
 weak_pointer_test, weak_pointer is a simple wrapper of WeakReference, which 
 is strong-typed.
 event_disposer_test, event_disposer is a strong-typed pointer, which provide 
 disposing event when disposing.
 lifetime_binder_test, lifetime_binder is a collection to avoid the object to 
 be finalized.

Developers need to write tests for finalizers, and writing tests for finalizers 
can be tricky for a variety of reasons. As such, it is quite possible that a 
GC-related test that works on .NET won't work on Mono w/o change.

If you want to test your class' finalizer, then you need to use two threads + 
WeakReference:

WeakReference r = null;
var t = new Thread (() = {
var v = new ClassToTest ();
r = new WeakReference (t);
});
t.Start ();
t.Join ();
GC.Collect ();
GC.WaitForPendingFinalizers ();

// can now [0] check r.IsAlive, etc.

The reason you create the instance + WeakReference on another thread is because 
Mono's GC will *conservatively* scan the thread's heap looking for valid 
references. By using a new thread *which exits*, the conservative stack scan 
will skip the exited thread, and thus won't find any valid references to the 
allocated instance. This in turn allows you to use the WeakReference to 
determine if the instance has in fact been collected. (Or not, if your 
ClassToTest registers itself with some static collection or something...)

 - Jon

[0]: https://bugzilla.xamarin.com/show_bug.cgi?id=20503

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

Re: [Mono-dev] New to Mono: Port from iOS to Android Question

[Jonathan Pryor]

On Sep 8, 2014, at 1:31 PM, jimscott007 jimscott...@gmail.com wrote:
 I'm looking to get involved in a project that already has a working iOS app 
 registered with the store and available for download. The next step is to 
 code the Android version of the app and I'm told that the iOS version was 
 built using Mono.

In all likelihood, the iOS app was written with MonoTouch or Xamarin.iOS. You 
may be able to use Xamarin.Android to assist in the Android port:

http://xamarin.com/platform

 - Jon

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

Re: [Mono-dev] OracleClient.Oci and GC

[Jonathan Pryor]

On Aug 25, 2014, at 2:05 PM, Neale Ferguson nealefergu...@verizon.net wrote:
 Do you mean mine not having protected virtual? 

Dispose(bool) doesn't need to be `protected virtual` unless you plan on 
supporting inheritance.

Rephrased: if your type is sealed, it doesn't need to be `protected virtual`. 
If your type *isn't* sealed, your type probably should provide a `protected 
virtual void Dispose(bool disposing)`.

 - Jon

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

Re: [Mono-dev] OracleClient.Oci and GC

[Jonathan Pryor]

Idiomatic IDisposable implementation is slightly different from what you have:


http://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx

On Aug 25, 2014, at 11:08 AM, Neale Ferguson nealefergu...@verizon.net wrote:
 I implemented a Dispose method for OracleParameter:
 
~OracleParameter ()
{
Dispose(false);
}
 
public void Dispose ()
{
Dispose (true);

You should call GC.SuppressFinalize(this) from Dispose(), not Dispose(bool).

 - Jon

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

Re: [Mono-dev] mono and unmanaged code

[Jonathan Pryor]

On Mar 19, 2014, at 12:33 AM, Greg gregorymors...@gmail.com wrote:
 I believe the calls are failing because the unamanged dll has not been 
 compiled in the native environment.  Is this true, or should mono be able to 
 handle unmanaged dlls that were compiled in Windows?

Mono does not support unmanaged shared libraries (.dll files).

If possible, you should port your unmanaged code to linux and build it into a 
.so.

If that isn’t possible, you should look into using Wine. Mono should run atop 
Wine (last I heard…), so this may be a viable solution for you.

 - Jon

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

Re: [Mono-dev] Inconsistent value in System.Diagnostics.DefaultTraceListener.AssertUiEnabled

[Jonathan Pryor]

On Mar 14, 2014, at 8:42 AM, MarLOne infoseeker...@gmail.com wrote:
 The function System.Diagnostics.Debug.Assert(bool, string) is not at fault as 
 I have disassembled the Mono code. The fault lies in the property value of 
 *System.Diagnostics.DefaultTraceListener.AssertUiEnabled* which is default to 
 *false* in *Mono* while in *CLR's runtime code* it is default to *true*.

This behavior is unlikely to change until:

1. We determine a way to reliably (portably!) determine if there is an 
interactive user so that the GUI is not shown in Server context. .NET has the 
Environment.UserInteractive property for this purpose:


http://msdn.microsoft.com/en-us/library/system.environment.userinteractive(v=vs.110).aspx

Unfortunately, it isn't implemented in Mono (it just returns `false`), never 
has been implemented, and I have no idea _how_ to implement it off Windows:


https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Environment.cs#L297

Until this is fixed, DefaultTraceListener.AssertUiEnabled CANNOT be True. (Not 
unless you want some random headless Server to be trying to connect to the GUI, 
halting all operations...)

2. It relies on loading System.Windows.Forms.dll via Reflection at runtime. 
What should happen when that assembly isn't available, as will be the case in 
Xamarin.Android, Xamarin.iOS, Xamarin.Mac, and various embedded platforms that 
include Mono's BCL (MonoGame, Unity3D, etc.)?

What _will_ happen is the UI won't be displayed and (in the MOBILE profile) the 
error message will be logged to stdout.

YOU know in what environments your app will run; the core libraries do not. 
Therefore, YOU can alter default behaviors as you see fit, e.g. by explicitly 
setting DefaultTraceeListener.AssertUiEnabled=true (either in code or in a 
.exe.config file), or by adding a new TraceListener which aborts the process on 
failure.

 - Jon

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

Re: [Mono-dev] mdoc update for a non-public types

[Jonathan Pryor]

On Oct 24, 2013, at 7:38 AM, xplicit s...@ngs.ru wrote:
 Can anyone explain is this normal behaviour or not?

The primary world view for mdoc is for generating and maintaining external 
documentation:


http://jprl.com/Blog/archive/development/mono/mdoc/#entry-development-mono-mdoc-2010-01-08T09:22:00AM

mdoc will generate documentation stubs which are later edited (typically 
by-hand, at least for me...). It does this by enumerating over all types and 
all members in the assembly, and generating mdoc(5)[0] XML for each type found.

Implicit in this worldview is that mdoc should _only_ process public or 
protected members, because generating documentation stubs for private members 
is lunacy.

Importing documentation (`mdoc -i ...`) doesn't change the above worldview: 
non-public/protected types are skipped before mdoc checks to see if it can 
import documentation for the member.

Furthermore, mdoc will _remove_ Member/ nodes for members that aren't found 
in the type, so manually adding private members afterward won't fix it.

 - Jon

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

Re: [Mono-dev] Removing NET_2_0 define

[Jonathan Pryor]

On Oct 16, 2013, at 10:00 AM, Alexander Köplinger alex.koeplin...@outlook.com 
wrote:
 Wouldn’t it make sense to remove the #if NET_2_0 checks in the codebase as 
 those are now unnecessary (every profile is now 2.0 or later)?
 Or are they actually required for something? If not, I’d provide a pull 
 request to clean up those checks.

They are not required, but removing them would add extra commit noise, which 
isn't necessary.

Current policy (as it were) is to remove nearby `#if`s when modifying 
nearby code, so things can be improved in an ongoing basis without littering 
commit history.

 - Jon

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

Re: [Mono-dev] Where can I find GetTargetHandle, etc?

[Jonathan Pryor]

On Jun 21, 2013, at 7:42 PM, Dan Barowy m...@ettinsmoor.net wrote:
  [MethodImplAttribute(MethodImplOptions.InternalCall)]
  private extern static int GetTargetHandle(object obj, int handle, 
 GCHandleType type);

MethodImplOptions.InternalCall means implemented in libmono*.so, so you need 
to look in mono/mono.

The easiest way is usually a recursive grep, which would find:

https://github.com/mono/mono/blob/master/mono/metadata/gc.c#L527
https://github.com/mono/mono/blob/master/mono/metadata/gc.c#L550

The C# method is hooked up to the above C method via 

https://github.com/mono/mono/blob/master/mono/metadata/icall-def.h#L667
https://github.com/mono/mono/blob/master/mono/metadata/icall.c

 - Jon

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

Re: [Mono-dev] Crash on Android when trying to execute dynamic code

[Jonathan Pryor]

Xamarin.Android-related issues should either go to monodr...@lists.xamarin.com 
[0] or the Android forums [1].

This particular case appears to be a JIT bug; please file a bug at bugzilla [2] 
with a reproducible test case, ideally with instructions as simple as run the 
app and watch it crash and burn. (The less interaction, the better.)

Even better, try to run the app on normal/desktop mono, not Xamarin.Android. 
That makes it easier for the runtime team to test and fix.

On Jun 15, 2013, at 8:37 AM, Robert Pickering rob...@strangelights.com wrote:
 I tried grab the IL code generated, but for some reason it always gets 
 truncated in the log.

`adb logcat` output limits message length. (I don't know the length; I just 
know that my stack traces are regularly truncated...)

If possible, try writing your IL to a file so that you can avoid the logcat 
limits.

 The program fails with the following stack trace:
 06-15 12:22:33.666 F/( 5381): * Assertion: should not be reached at 
 /Users/builder/data/lanes/monodroid-mlion-master/f6831347/source/mono/mono/mini/mini-arm.c:3599
...
 I've tried checking out mini-arm.c:3599, but it currently seems to be a 
 comment. I'm not sure how you find the source for the version of Mono that 
 Android is running on.

You ask me; Xamarin.Android commit f6831347 (in the path) is Xamarin.Android 
4.7.4, which uses Mono 20572465 [3]

For more recent releases, I've been mentioning the corresponding git commit 
hash in the release notes, e.g. Xamarin.Android 4.7.8 [4] is based on Mono 
3.0.12 commit 322d5bd3.

I would suggest upgrading to 4.7.9, which is currently in beta (and is 4.7.8 + 
one change, unrelated to mono). I don't think 4.7.9 will fix your issue, 
though, as the assert appears to still be there, just on line mini-arm.c:3674 
Please file a bug.

 - Jon

[0]: http://lists.ximian.com/mailman/listinfo/monodroid
[1]: http://forums.xamarin.com/categories/android
[2]: https://bugzilla.xamarin.com/
[3]: https://github.com/mono/mono/blob/20572465/mono/mini/mini-arm.c#L3599
[3]: 
http://docs.xamarin.com/releases/android/xamarin.android_4/xamarin.android_4.7#Xamarin.Android_4.7.8

___
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 with android ndk standalone toolchain (android ndk r8e)

[Jonathan Pryor]

On May 8, 2013, at 4:29 PM, Jeremy Bell bell.jer...@gmail.com wrote:
 So, it looks like HAVE_SGEN_GC is not defined, but should be? Have I missed a 
 step somewhere?

Yes, it should be. From the commit message you mention:

 The Android NDK/bionic is interesting, in that it's lacking header files and
 macros normally present on Linux which otherwise break the build (e.g. no
 link.h which breaks Boehm support).

breaks Boehm support means only sgen works. You need to disable Boehm, and 
enable sgen.

 - Jon

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

Re: [Mono-dev] Mono documentation

[Jonathan Pryor]

On Apr 29, 2013, at 2:10 AM, Александр Шевченко 
alexandre.shevche...@gmail.com wrote:
 I have a question about monodoc. I want to create documentation for my 
 library on windows, but it looks like monodoc is utility only for Linux. If 
 it is, how can I create docs on Windows?

Grab and extract:

http://mono-project.com/Mdoc
http://www.go-mono.com/archive/mdoc-net-2010-01-04.zip

Inside is an `mdoc.exe` + dependencies which runs on .NET.

See also:

http://www.jprl.com/Blog/archive/development/mono/mdoc/

 - Jon

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

Re: [Mono-dev] EntryPointNotFoundException with __Internal method

[Jonathan Pryor]

On Apr 29, 2013, at 3:20 PM, Marcelo Zabani mzab...@gmail.com wrote:
 When embedding Mono within Nginx, I received the following exception:
 
 Unhandled Exception: System.EntryPointNotFoundException: 
 log_error_core_wrapper
   at (wrapper managed-to-native) Nam.NginxMethods:ngx_log_error 
 (uint,intptr,int,string)
   at Nam.NginxMethods.LogInfo (IntPtr log, System.String msg) [0x0] in 
 filename unknown:0 

Which platform? IIRC __Internal doesn't work on Windows platforms.

 - Jon

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

Re: [Mono-dev] Mono-devel-list Digest, Vol 96, Issue 26

[Jonathan Pryor]

On Apr 26, 2013, at 9:45 AM, James Bellinger ja...@illusorystudios.com wrote:
 Other than that it's really very usable. [On Windows, at least.]

So on the one platform for which it doesn't use it's own theming and instead 
uses the platform theming (it uses WinAPI ~directly), it looks good.

Great.

That also happens to be the platform which has it's own native 
System.Windows.Forms implementation, so I'm not entirely sure what Mono is 
buying you there, except possibly a zero-install app environment (no need to 
install .NET).

EVERYWHERE ELSE (Linux, OS X), it looks like ass.

(Please, for the love of $DEITY, do not use WinForms for new projects with any 
notions of being cross-platform, unless WinForms is a pluggable front-end 
with other front-ends available. The fact that such a pluggable front end 
architecture also makes the app amenable to Xamarin.Android and Xamarin.iOS is 
a happy coincidence. ;-)

 - Jon

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

Re: [Mono-dev] Mono-devel-list Digest, Vol 96, Issue 26

[Jonathan Pryor]

On Apr 26, 2013, at 11:01 AM, James Bellinger ja...@illusorystudios.com wrote:
 This really suggests WinForms ought to be made to look better on other 
 platforms instead of diffusing the needed effort to end users and forcing 
 them to maintain more code.

Arguably true, except:

1. Nobody has stepped up to maintain it.
2. Nobody wants to maintain it (implication of (1)).
3. The company that _was_ maintaining it (Novell/AttachMate) is not doing so 
anymore.
4. Xamarin has no interest in maintaing it.

From the (unofficial!) Xamarin perspective, the best _end-user_ experience is 
native UI code, using the native frameworks, hence MonoTouch.UIKit on iOS, 
Android.Widgets on Android, MonoMac.* on OS X, System.Windows.* on Windows, 
Gtk# on Linux, etc.

There is no sane way for a single UI framework to support all those diverse 
form factors and conventions. It's been tried -- GTK+, Qt, Java/AWT, 
Java/Swing, Java/SWT, wxWidgets, etc. Hell, at one point MFC supported MacOS 
(or my mind is playing tricks on me; Google can't verify that!).

At some point you have to bow to history and admit that one UI framework can't 
rule everything, not for great user experiences.

Sanely supporting multiple front-ends just requires designing your app in a 
UI-anostic fashion (MVC/MVVM/etc.) as opposed to tying your business code 
willy-nilly into your UI code (which is apparently very common with lots of GUI 
code).

 - Jon

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

Re: [Mono-dev] Mono-devel-list Digest, Vol 96, Issue 26

[Jonathan Pryor]

On Apr 24, 2013, at 8:09 AM, Rauf Butt raufb...@gmail.com wrote:
 WinForms is specific to Microsoft platform. Additionally, it will require 
 license too.

System.Windows.Forms is implemented on Mono. It looks like Windows 95, has 
rendering issues, and is generally user-hostile, but it DOES exist, and is 
probably more than reasonable for homework purposes. No License is required to 
use it.

http://github.com/mono/mono/blob/master/mcs/class/Managed.Windows.Forms

I would _not_ recommend using it for real/commercial products. It's largely 
for compatibility only.

 - Jon

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

Re: [Mono-dev] Add openat() etc. to Mono.Posix

[Jonathan Pryor]

On Mar 26, 2013, at 9:13 AM, Steffen Kieß s-ki...@web.de wrote:
 some time ago I submitted a pull request which adds openat() and some other 
 methods to Mono.Posix: https://github.com/mono/mono/pull/221
 
 A related pull request for mono-tools (which is needed for the mono pull 
 request): https://github.com/mono/mono-tools/pull/22

My apologies.

I've now replied to the appropriate pull requests.

 - Jon

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

Re: [Mono-dev] Distinction between generic type and instance type

[Jonathan Pryor]

On Feb 6, 2013, at 10:28 AM, Stuart Golodetz stu...@semmle.com wrote:
 do you know whether the distinction being made by Mono between a generic type 
 and the instance type corresponding to it is only of relevance to the 
 compiler, or does it have real implications for an application-level 
 developer?

It would be helpful if you used existing/normal terminology; I _think_ your'e 
talking about open generic types (e.g. ListT) vs. closed generic types 
(e.g. Listint).

Assuming that's the case, then yes, this does have implications for app 
developers. Suppose you wanted to know if a type implemented IListT, but you 
didn't care about the T?

// Does FooCollection implement IListT?
class FooCollection : CollectionFoo {
}

Here, you do need to care about the difference between open and closed generic 
types:

csharp typeof(FooCollection).BaseType.GetInterfaces().Any(i = i == 
typeof(IListFoo));
true

The above requires that we know the closed generic type IListFoo. What if we 
don't know/care about Foo specifically, but do care about IListT?

csharp typeof(FooCollection).BaseType.GetInterfaces().Any(i = i == 
typeof(IList));
false

Oops.

So now the developer needs to know  care, and behave accordingly:

csharp typeof(FooCollection).BaseType.GetInterfaces().Any(i = 
i.IsGenericType  i.GetGenericTypeDefinition() == typeof(IList));
true

 - Jon

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

Re: [Mono-dev] Problems with FileStream.Lock();

[Jonathan Pryor]

On Jan 8, 2013, at 3:52 PM, Terry Watts terry.terrywatts@gmail.com wrote:
 I have looked at the exception under the debugger, that's why E is in the 
 catch{ Exception E}. The exception thrown is a lock violation; not a Not 
 Supported exception.

The exception thrown is lock violation because that's what it was mapped to 
-- io-layer's LockFile() was translating ~every fcntl(2) error into 
ERROR_LOCK_VIOLATION, even if the actual error was that the parameters were 
invalid (as was the case here). This is fixed in:


https://github.com/mono/mono/commit/6c5d76dd4c953fc26a82e3cce44baa6a06aeaa21

Note that Mono for Android doesn't currently have this patch.

 - Jon

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

Re: [Mono-dev] Problems with FileStream.Lock();

[Jonathan Pryor]

On Jan 8, 2013, at 4:44 PM, Terry-Watts.com te...@terry-watts.com wrote:
 I have check the Android API docs and file locking has been available on 
 channels since API Level 1.

on channels?

Anyway, quick perusal of the source shows that FileStream.Lock() is fcntl(2):


https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/FileStream.cs#L875

https://github.com/mono/mono/blob/master/mcs/class/corlib/System.IO/MonoIO.cs#L414
https://github.com/mono/mono/blob/master/mono/metadata/file-io.c#L1191
https://github.com/mono/mono/blob/master/mono/io-layer/locking.c#L117
https://github.com/mono/mono/blob/master/mono/io-layer/locking.c#L26

So, why is fcntl(2) failing? I don't know, you're swallowing the exception.

 - Jon

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

Re: [Mono-dev] Problems with FileStream.Lock();

[Jonathan Pryor]

On Jan 7, 2013, at 4:50 PM, Terry-Watts.com te...@terry-watts.com wrote:
 I have a class that work fine in C# under Windows but not under Monodroid.

This is a mono bug: https://bugzilla.xamarin.com/show_bug.cgi?id=9411

Thinking about it a but more, though, it's an app bug (+ mono bug).

The problem is that Android doesn't have large file support (meaning 
userspace is limited to 32-bit values for file offsets/etc.). Your code, 
meanwhile, is specifying a 64-bit value for the file range.

fcntl(2) cannot accept a 64-bit value for the size of the file region to lock; 
it needs to be a signed 32-bit value.

Fix: use `int.MaxValue`, not `long.MaxValue`.

Mono should probably throw an exception in this scenario.

 - Jon

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

Re: [Mono-dev] SGen stability

[Jonathan Pryor]

On Nov 5, 2012, at 7:16 AM, Roope Kangas ro...@grandcrugames.com wrote:
 I have noticed a few times that when we cause a spike the amount of threads 
 we run the server sometimes crashes with the following output:
...
 Any ideas on what to do? This kind of behaviour does not occur with Boehm GC. 

If you have a consistent repro, please file a bug with the repro at 
bugzilla.xamarin.com so that we can fix it.

Thanks!
 - Jon

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

Re: [Mono-dev] Malloc issue?

[Jonathan Pryor]

On Aug 23, 2012, at 2:35 AM, Greg Young gregoryyou...@gmail.com wrote:
 We are allocating and releasing unmanaged memory with marshal.allochglobal. 
 In mono we are getting the following failure (no failures under clr).
 
 Any ideas?

That's not a mono error, that's a glibc assert (and thus cannot become an 
exception, ever):

 part from team city logs:
 [20:55:52][Step 2/2] mono: malloc.c:2451: sYSMALLOc: Assertion `(old_top == 
 (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof 
 (struct malloc_chunk, fd  old_size == 0) || ((unsigned long) (old_size) 
 = (unsigned long)__builtin_offsetof (struct malloc_chunk, 
 fd_nextsize))+((2 * (sizeof(size_t))) - 1))  ~((2 * (sizeof(size_t))) - 1))) 
  ((old_top)-size  0x1)  ((unsigned long)old_end  pagemask) == 0)' 
 failed.

Very probably coming from:


http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=0f1796c9134ffef289ec31fb1cd538f3a9490ae1;hb=HEAD#l2361
   /*
  If not the first time through, we require old_size to be
  at least MINSIZE and to have prev_inuse set.
   */

   assert((old_top == initial_top(av)  old_size == 0) ||
  ((unsigned long) (old_size) = MINSIZE 
   prev_inuse(old_top) 
   ((unsigned long)old_end  pagemask) == 0));

The line number is different, but it's the same file and the assert looks close 
enough (considering macro expansion, etc.).

In short, malloc(3) doesn't like you or something that you're doing. I would 
suggest setting the MALLOC_CHECK_ environment variable (see the malloc(3) man 
page), and/or porting your malloc use to C to verify that it also crashes 
there.

 - Jon

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

Re: [Mono-dev] Why does .NET object lifetime not extend into an instance method call?

[Jonathan Pryor]

On Aug 24, 2012, at 1:11 PM, David Jeske dav...@gmail.com wrote:
 (1) Why would a call to an instance method not hold this alive for the 
 entire duration of the call? 

`this` isn't special, it's just an implicit variable passed into the method. If 
the variable isn't used within the method call, then it's collectible.

Rephrased, consider this:

// caller:
Foo (new StringBuilder ());

// Implementation:
static void Foo(StringBuilder b)
{
Thread.Sleep (1000);
}

The variable `sb` isn't used at all within Foo(). Consequently, the 
StringBuilder instance can be collected at any time, and no one will notice (as 
far as the GC is concerned). (The StringBuilder allocation could be omitted 
entirely, actually, if the runtime environment were smart enough to determine 
that it wasn't doing anything...)

Since `this` is just a variable, the GC treats it in the same way. The issue 
isn't so much that the GC is treating P/Invoke specially; the issue is that 
it's not treating it specially at all, and P/Invoke introduces a different 
world (native code) which the GC doesn't know anything about. Consequently, 
the GC can (and will) collect instances that the GC knows are unreachable from 
managed code, but may still be referenced from native code.

 It seems this could happen in more cases than just PInvoke. This seems to 
 allow a finalizer to run before an object is done being used anytime the 
 object instance is not stored. (i.e. inside a statement of the form new 
 Foo().Method();) If the finalizer triggers an IDispose pattern, this could 
 cause a managed resource to be torn down before it's done being used as well.

The managed resource can't be disposed before it's done being used AS LONG AS 
the GC knows about all uses of the managed resource.

In your `new Foo().Method()` example, it IS possible that the GC will finalize 
the `Foo` instance before Method() has returned, but it will only do so AS LONG 
AS `this` is no longer referenced within Method(). Thus, if Method() were empty 
or didn't use any instance members at all (e.g. the above Foo() body), then the 
instance can be collected while Method() is executing. Furthermore, it won't 
matter, as there's no way for Method() to even know that's happening.

The real problem is that the GC doesn't know anything about native code, and 
thus can't ensure that no native code is using the resource.

 Why isn't this considered a bug in the .NET runtime?

How would you fix it? The .NET runtime has no way of knowing what native code 
is doing, so short of disassembling the native code (magic), what is .NET 
supposed to do?

 (2) Does the Mono GC have the same behavior?

Yes, because there's no other sane behavior.

With Boehm it may be less of an issue, as Boehm is non-moving collector (so the 
memory won't be invalidated as quickly), and due to Boehm and Sgen's 
conservative stack walking nature Mono is more likely to preserve managed code 
which is referenced by native stack frames.

However, this can't be relied upon; Linux supports precise stack marking, 
which prevents conservative scanning of native stack frames. This has the 
wonderful performance advantage that less memory needs to be pinned, allowing 
the GC to be more efficient:

http://www.mono-project.com/Generational_GC#Precise_Stack_Marking

 - Jon

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

Re: [Mono-dev] Why does .NET object lifetime not extend into an instance method call?

[Jonathan Pryor]

On Aug 24, 2012, at 4:26 PM, David Jeske dav...@gmail.com wrote:
 Thanks very mych for the detailed reply. It seems to me there is a race that 
 has nothing to do with native code.

Native code just makes it easier to reason about, but as you mention it is 
quite applicable to managed code. My apologies for not considering that angle.

The answer is largely the same, though; you have two threads using the same 
instance, one of which (the finalizer) is disposing of the instance, and one of 
which is invoking a method on that instance.

If you weren't dealing with the GC but still had the same scenario -- two 
threads using the same instance -- how would you it? By introducing locking, or 
otherwise ordering the operations so that they can't overlap.

The same is true with the GC, i.e. you ned to ensure that the threads don't 
stomp on each other, via manual programmer assistance.

void Problem()
{
mo.doSomething();
GC.KeepAlive(this);
}

The above GC.KeepAlive() will prevent the GC from finalizing the Foo instance 
(and thus the Foo.mo instance) until after `mo.doSomething()` completes.

That's the fix, but why is it necessary? Why can't the GC figure this out?

Because auto-parallelism is hard, and the GC isn't fully involved, _you_ are; 
consider your previous sample app, but let's provide an implementation for 
ManagedObject:

class ManagedObject : IDisposable {
static readonly ListManagedObject instances = new 
ListManagedObject();

public ManagedObject ()
{
lock (instances)
instances.Add(this);
}

public static ManagedObject[] GetInstances ()
{
lock (instances)
return instances.ToArray ();
}

public void Dispose()
{
// remove? eh...
}
}

This is for illustrative purposes only; the point is that ManagedObject could 
do _anything_, and the above implementation will result in disposed instances 
within the static ManagedObject.instances list (and, depending on timing, any 
callers of the GetInstances() method). The GC will _never_ collect them -- 
they're rooted! -- but they've been invalided via your Dispose() call. (Sure, 
ManagedObject.Dispose() could remove itself from the list; complicate the 
implementation as appropriate to make that infeasible. ;-)

All the GC does is track which instances are still live and which are 
collectible. That's (mostly) it. The fact that the GC may introduce 
multi-threaded access to member variables is largely beyond it's purview; as 
such, the onus is on the developer to clear it up.

But here's the real rub: even if the GC weren't introducing multi-threaded 
access to a member variable, it _still_ can't be held responsible for 
complicated object graphics like the above. Foo isn't referenced by anything, 
and thus is disposed -- even if it's not at the same time that Foo.Problem() is 
executing -- but the side effects of the finalizer invocation are WAY beyond 
the scope of the GC. It's all too easy for an instance to be disposed/finalized 
while other code is still holding it. The GC doesn't protect you from this; 
you, the developer, have to protect your code against it.

Given that you the programmer are on the hook once you introduce Dispose() and 
finalizers, having the GC be more proactive at freeing resources doesn't 
greatly change the game. If you want things to be easy, avoid IDisposable and 
finalizers entirely.

 I'm sorry for my naivety. Why does allowing unused function arguments to be 
 collected before a function returns have such important effects on memory 
 usage? 

Java. :-)

The context is the JVM, and large methods. Many JVM implementations used to 
do as you suggested, and wouldn't collect a variable until the method 
referencing the variable returned. This even applied to local variables! 
Instead of having precise lifetime semantics (as determined by the 
instruction pointer), it only cared about stack frames.

The result of this behavior is that developers would write huge methods which 
allocated lots of objects, all of which would be considered live even when 
a local was no longer being used. Thus came a body of guidelines that you 
should null out instance/local variables so that the GC could actually collect 
intra-method garbage:

http://stackoverflow.com/questions/473685
http://stackoverflow.com/a/503714/83444

Needing to null out a local variable is, of course, insane -- why can't the GC 
figure this out! -- so .NET (and modern JVMs!) now precisely track which 
variables are in-scope and out-of-scope, and will allow collection of 
any-and-all out-of-scope variables even within the method.

 - Jon

___

Re: [Mono-dev] Few questions about Linq implementation

[Jonathan Pryor]

Unless you _really_ need a System.Data.Linq-compatible API, I would suggest 
giving up. Instead, focus on getting the open-source EF release working on 
Mono, and use that instead.

http://entityframework.codeplex.com/

 - Jon

On Jul 31, 2012, at 4:06 AM, Sharique uddin Ahmed Farooqui saf...@gmail.com 
wrote:

 Hi,
 
 I have few question regarding linq implementation in mono.
 
 1. Afaik current is based on dblinq
 (http://code.google.com/p/dblinq2007), which not much active from some
 time, so did mono team created a fork of it or using same code?
 2. Sometime back there was a discussion about rewriting linq
 implementation using relinq, is anybody working on it?  If somebody
 want to take it up, what should be his priorities?
 
 Thanks
 --
 Sharique uddin Ahmed Farooqui
 http://safknw.blogspot.com/
 Peace is the Ultimate desire of mankind.
 ___
 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] .net/mono inconsistency

[Jonathan Pryor]

On Jul 13, 2012, at 11:23 AM, Matthias D. matth...@googlemail.com wrote:
 I'm porting a .net application to mono and I noticed a small inconsistency in 
 System.Diagnostics.DefaultTraceListener. In .net this class has a public 
 constructor and in mono it has only a private one (none in the source code).

If the source code doesn't contain a constructor, the compiler will create a 
default _public_ constructor, not a private one. Mono is compatible with .NET 
here.

 - Jon

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

Re: [Mono-dev] .net/mono inconsistency

[Jonathan Pryor]

On Jul 14, 2012, at 6:26 AM, Matthias D. matth...@googlemail.com wrote:
 Ok I figured it out, the problem was using the answer from this: 
 http://stackoverflow.com/questions/1769772/reading-tracelistener-initializedata-property-from-config-net-1-1
  and in mono there is no field called initializeData. I did found another 
 workaround though.

What field would you even be looking for? The //listeners/add/@initializeData 
attribute is used to pass a value to the constructor:


https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/DiagnosticsConfigurationHandler.cs#L435

 - Jon

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

Re: [Mono-dev] Mono.Posix question

[Jonathan Pryor]

On Jun 22, 2012, at 9:35 AM, Rob Wilkens robwilk...@gmail.com wrote:
 Do you know where i can find documentation for Mono.Posix?

Documentation is in git:


https://github.com/mono/mono/tree/master/mcs/class/Mono.Posix/Documentation/en

Accessible from the web:

http://docs.go-mono.com/?link=N:Mono.Unix

Documentation is in mdoc(5) format:

http://docs.go-mono.com/?link=man:mdoc(5)

 I was looking at the following problem report: 
 https://bugzilla.xamarin.com/show_bug.cgi?id=1970
 
 And I saw that 
 Mono.Unix.UnixDirectoryInfo(1).Create(FileAccessPermissions.AllPermissions);
 
 Was honoring umask, because that's what the system call for mkdir does.  
 (That is: Create() just calls mkdir with the permissions.)  Should it be 
 honoring umask when it creates the directory, or should we, after the call to 
 mkdir, separately set the permissions as part of the Create call (the 
 equivalent of a call to chmod).

The documentation has a See Also reference to Syscall.mkdir():


http://docs.go-mono.com/?link=M%3aMono.Unix.UnixDirectoryInfo.Create(Mono.Unix.FileAccessPermissions)

So yes, it should honor umask. I've clarified the documentation to spell this 
out:


https://github.com/mono/mono/commit/43955e80628074ee23dbaaee611e97e76c49483b

 - Jon

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

Re: [Mono-dev] Mono.Posix question

[Jonathan Pryor]

On Jun 22, 2012, at 9:35 AM, Rob Wilkens robwilk...@gmail.com wrote:
 Do you know where i can find documentation for Mono.Posix?

Documentation is in git:


https://github.com/mono/mono/tree/master/mcs/class/Mono.Posix/Documentation/en

Accessible from the web:

http://docs.go-mono.com/?link=N:Mono.Unix

Documentation is in mdoc(5) format:

http://docs.go-mono.com/?link=man:mdoc(5)

 I was looking at the following problem report: 
 https://bugzilla.xamarin.com/show_bug.cgi?id=1970
 
 And I saw that 
 Mono.Unix.UnixDirectoryInfo(1).Create(FileAccessPermissions.AllPermissions);
 
 Was honoring umask, because that's what the system call for mkdir does.  
 (That is: Create() just calls mkdir with the permissions.)  Should it be 
 honoring umask when it creates the directory, or should we, after the call to 
 mkdir, separately set the permissions as part of the Create call (the 
 equivalent of a call to chmod).

The documentation has a See Also reference to Syscall.mkdir():


http://docs.go-mono.com/?link=M%3aMono.Unix.UnixDirectoryInfo.Create(Mono.Unix.FileAccessPermissions)

So yes, it should honor umask. I've clarified the documentation to spell this 
out:


https://github.com/mono/mono/commit/43955e80628074ee23dbaaee611e97e76c49483b

- Jon

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

Re: [Mono-dev] .net/mono inconsistency

[Jonathan Pryor]

On Jul 13, 2012, at 11:23 AM, Matthias D. matth...@googlemail.com wrote:
 I'm porting a .net application to mono and I noticed a small inconsistency in 
 System.Diagnostics.DefaultTraceListener. In .net this class has a public 
 constructor and in mono it has only a private one (none in the source code).

If the source code doesn't contain a constructor, the compiler will create a 
default _public_ constructor, not a private one. Mono is compatible with .NET 
here.

- Jon

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

Re: [Mono-dev] .net/mono inconsistency

[Jonathan Pryor]

On Jul 14, 2012, at 6:26 AM, Matthias D. matth...@googlemail.com wrote:
 Ok I figured it out, the problem was using the answer from this: 
 http://stackoverflow.com/questions/1769772/reading-tracelistener-initializedata-property-from-config-net-1-1
  and in mono there is no field called initializeData. I did found another 
 workaround though.

What field would you even be looking for? The //listeners/add/@initializeData 
attribute is used to pass a value to the constructor:


https://github.com/mono/mono/blob/master/mcs/class/System/System.Diagnostics/DiagnosticsConfigurationHandler.cs#L435

- Jon

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

Re: [Mono-dev] Few questions about Linq implementation

[Jonathan Pryor]

Unless you _really_ need a System.Data.Linq-compatible API, I would suggest 
giving up. Instead, focus on getting the open-source EF release working on 
Mono, and use that instead.

http://entityframework.codeplex.com/

- Jon

On Jul 31, 2012, at 4:06 AM, Sharique uddin Ahmed Farooqui saf...@gmail.com 
wrote:

 Hi,
 
 I have few question regarding linq implementation in mono.
 
 1. Afaik current is based on dblinq
 (http://code.google.com/p/dblinq2007), which not much active from some
 time, so did mono team created a fork of it or using same code?
 2. Sometime back there was a discussion about rewriting linq
 implementation using relinq, is anybody working on it?  If somebody
 want to take it up, what should be his priorities?
 
 Thanks
 --
 Sharique uddin Ahmed Farooqui
 http://safknw.blogspot.com/
 Peace is the Ultimate desire of mankind.
 ___
 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] Show Linux . hidden directories

[Jonathan Pryor]

On May 31, 2012, at 4:36 PM, BigalGeorge wrote:
 Hi is mono capable of browsing the hidden directories under Linux? Why I ask 
 is that I have enabled them for viewing under Ubuntu eg are visible in 
 Nautilus, but when using mono browser they are hidden.

What is the mono browser?

I can't easily test on Linux atm, but on OS X hidden files are returned by 
System.IO.Directory.GetFiles():

$ csharp
Mono C# Shell, type help; for help

Enter statements below.
csharp using System.IO; 
csharp Directory.GetFiles(Directory.GetCurrentDirectory()); 
{ /Users/jon/.CFUserTextEncoding, /Users/jon/.DS_Store, 
/Users/jon/.Xauthority, /Users/jon/.bash_history, ...

Notice that the entries in that except begin with a '.', and thus are hidden...

 - Jon

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

Re: [Mono-dev] DllImport(__Internal) and libMonoPosixHelper static build

[Jonathan Pryor]

On Apr 12, 2012, at 3:43 AM, ralphbariz wrote:
 I'm trying to compile a static one binary mono(Because the target system has 
 an incompatible loader).

What platform is this? What kind of loader does your target system have? Does 
it have any shared library loader?

 After a few tries, I got also this, changed all DllImport(MPH) calls in 
 Mono.Posix.dll to DllImport(__Internal),

DllImport(__Internal) requires that the target platform (1) support 
dlopen(NULL, mode) to open the main executable, and (2) that dlsym() be able to 
find symbols within the main executable.

Note that (1) is not true for Windows, so [DllImport(__Internal)] will not 
work on Windows (iirc).

 it still gives me a TypeInitializationexception when I try to access the stat 
 symbol of the libMonoPosixHelper.

That's odd; Syscall.stat() P/Invokes Mono_Posix_Syscall_stat(), not stat():


https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/Syscall.cs#L2851

Mono_Posix_Syscall_stat(), meanwhile, is just a simple wrapper around stat(2):

https://github.com/mono/mono/blob/master/support/sys-stat.c#L25

If your program is dying because Mono_Posix_Syscall_stat() can't be found, then 
the problem is probably that dlopen(NULL, mode) is not supported on your 
platform. If stat() can't be found, then (1) your platform doesn't provide 
stat(2), or (2) (somehow) your program is being improperly linked and stat() 
isn't being found.

 - Jon

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

Re: [Mono-dev] [db|sql]metal using a custom DbSchemaLoader ?

[Jonathan Pryor]

On Mar 8, 2012, at 8:16 AM, Cyrille Chépélov wrote:
 Would a patch removing the #if !MONO_STRICT .. public condition from 
 ISchemaLoader  common implementations be accepted in Mono System.Data.Linq ?

No.

 I notice Mono's S.D.Linq already leaks some bits from DbLinq.Util

Then that's a bug. Mono's System.Data.Linq.dll shouldn't export anything not 
present in .NET.

What you should instead do is use DbLinq proper and bundle it with your app 
instead of using System.Data.Linq.dll. This will give you proper access to all 
that DbLinq provides, without making things horribly confusing if/when you run 
your app on .NET.

 DbLinq.Vendor.DbSchemaLoader's MapDbType method has a smell in its 
 switch/case statement. Apparently, that has been written much earlier than 
 the availability of a proper SchemaLoader child class per provider.  So in 
 effect, all type names from all dialects are tested against every database, 
 regardless of the provider. Wouldn't it be sensible to push down the type 
 tests into each provider ? I would like to do this.

I'd personally prefer to nuke that type from orbit and instead require that 
everything use DbSchemaLoader, as that asks the ADO.NET provider to do the 
database-type - managed type mappings, instead of hardcoding it within DbLinq 
itself. Far saner, and it's what the DbLinq.SqlServer provider does. (The 
DbLinq.Sqlite provider can also work with it.)

This should also be taken upstream with DbLinq...which is nigh unmaintained at 
this point. :-(

Yet another of the million things that should be done...

 - Jon

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

Re: [Mono-dev] DeflateStream on OSX

[Jonathan Pryor]

On Dec 20, 2011, at 1:06 PM, Jonathan Shore wrote:
 I attempted to use System.IO.Compression.DeflateStream and encountered a DLL 
 load error when DeflateStream attempts to load the MonoPosixHelper DLL.   
 Searching in 
 
   /Library/Frameworks/Mono.framework/Libraries/mono
 
 did not find the MonoPosixHelper dll.

That's because it's:

/Library/Frameworks/Mono.framework/Libraries/libMonoPosixHelper.dylib

How are you attempting to use DeflateStream? It works for me from `csharp` on 
OSX:

 $ csharp 
 Mono C# Shell, type help; for help
 
 Enter statements below.
 csharp using System.IO.Compression;
 csharp using System.IO; 
 csharp var s = File.OpenWrite (foo.z);
 csharp var c = new DeflateStream (s, CompressionMode.Compress);
 csharp var o = new StreamWriter (c);
 csharp o.WriteLine (Hello, world!);
 csharp o.Close();
 csharp var i = new StreamReader (new DeflateStream (File.OpenRead (foo.z), 
 CompressionMode.Decompress));
 csharp i.ReadLine();
 Hello, world!

 - Jon

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

Re: [Mono-dev] Crash in call to internalGetHome()

[Jonathan Pryor]

On Dec 22, 2011, at 9:30 AM, Kamal Aboul-Hosn wrote:
 I see that internalGetHome is defined as an extern internalCall function. Is 
 there perhaps something I am missing with regard to all the elements I need 
 to install to make it work?

It's an environment issue. Environment.internalGetHome() is mapped in 
mono/mono/metadata/icall.c to ves_icall_System_Environment_InternalGetHome(), 
which does:

return mono_string_new (mono_domain_get (), g_get_home_dir ());

g_get_home_dir() is defined in mono/eglib/src/gmisc-unix.c.

mono_string_new() is defined in mono/mono/metadata/object.c, and does:

MonoString*
mono_string_new (MonoDomain *domain, const char *text)
{
...
l = strlen (text); 

Note: strlen(NULL) aborts.

Deduction: g_get_home_dir() is returning NULL, which aborts in the strlen() 
call. You'll need to figure out why g_get_home_dir() is returning NULL, and/or 
how to work around it.

 - Jon

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

Re: [Mono-dev] Mixed Mode Assemblies

[Jonathan Pryor]

On Jul 7, 2011, at 11:55 AM, arkain wrote:
 I understand the reasons why the developers chose to leave out support for
 developing mixed-mode assemblies using mono: the lack of cross-platform
 compatibility in such assemblies. However, I would argue that such things
 are not a consideration for those who would choose to develop such
 assemblies.

Mono supports mixed mode assemblies on Windows:

http://www.mono-project.com/CPlusPlus

Mixed-mode assemblies are experimentally supported only on Windows...

Mono can't support mixed-mode assemblies on any other platform, for a simple 
reason: in order for a mixed-mode assembly to be really useful, it needs to be 
loadable as a native library on the platform. This works on Windows because 
assemblies are PE/COFF files, and Windows dynamic link libraries are PE/COFF, 
so everything Just Works.

But try using dlopen(3) on Linux to load an assembly, and dlopen(3) will 
(rightfully) fail -- Linux wants ELF, not PE. There's a rather fundamental file 
format difference here.

That said there are efforts to improve the Mono/C++ interop story, e.g. via COM 
interop (which does work on Linux):

http://blog.worldofcoding.com/2009/08/binding-c-apis.html

There was a GSOC project last year to improve C++/Mono interop, and Andreia 
Gaita presented on it:

http://weblog.savanne.be/files/fosdem-mono-2011/cpp_interop.pdf

There is also a current GSOC project:

http://www.google-melange.com/gsoc/project/google/gsoc2011/corrado/13001

So hopefully things will keep improving, but note that the above C++/mono 
interop techniques are _not_ mixed mode assemblies. (XP)COM is a binary 
standard (via virtual function tables) which works quite nicely with 
dlopen(3)/etc., while the current C++ work can be thought of as an elaborate 
P/Invoke-like solution for C++ code.

 - Jon

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

Re: [Mono-dev] Platform independence of mono assemblies

[Jonathan Pryor]

The perfect is the enemy of the good
- Voltaire

On May 18, 2011, at 5:53 PM, Christian Krause wrote:
 In Fedora, the assemblies are treated as architecture-dependent and so
 they (including the GAC) are put into %{_libdir} which is /usr/lib64 on
 x86_64 systems.
 
 However, it seems to be the standard for mono to place the assemblies
 under %{_prefix}/lib/, regardless of the architecture.
 
 As far as I know this decision was based on a statement from the mono
 developers ([1]), that although the C# assemblies are currently
 architecture independent, it can not be guaranteed that they will be
 forever. That is why Fedora treats C# assemblies as arch-dependent files
 and so they are installed on multi-arch x86_64 systems into /usr/lib64.

Not exactly. As Miguel mentioned, mono at the time required that AOT-compiled 
shared libraries be placed next to the assembly, e.g. for mscorlib.dll the 
AOT-compiled mscorlib.dll.so must be in the same directory.

However, no Linux distribution actually uses AOT-compiled assemblies (that I 
know of, anyway). Hence my quote: the feature is there, but it's rarely 
(never?) used, so using this as a reason to be different from openSUSE, Debian, 
Ubuntu, and the default build setup seems like chasing the perfect at the 
expense of the good.

This is also somewhat moot as Mono no longer requires that the AOT-compiled .so 
be next to the assembly, as it can instead look for assemblies in 
~/.mono/aot-cache if the MONO_AOT_CACHE environment variable is set; see 
mini/aot-runtime.c!load_aot_module_from_cache [0].

A proper fix would likely involve altering the runtime so that other well 
defined platform-specific directories are checked for AOT .so's before JITing 
the assembly, but this apparently hasn't been important enough for anyone to 
actually implement (the above nobody uses AOT argument).

 As far as I know, the C# assemblies are indeed architecture independent
 (as defined by the CIL standard). There may be some corner cases where
 it is possible to explicitly write arch-dependent code, but these may be
 treated as bugs in the projects.

It _is_ possible to have platform specific assemblies. Not because the IL is 
platform specific (as you note), but because of Platform Invoke [1], which 
allows ~direct invocation of native code. Managed code may thus embody platform 
specific assumptions. For example, consider nanosleep(2) [2]:

struct timespec {
time_t tv_sec;
long tv_nsec;
};
int nanosleep(const struct timespec* req, struct timespec *rem);

What's `time_t`? That can vary amongst POSIX implementations. What's `long`? 
That can (and will!) vary between ILP32 (32-bit linux; 32-bits), LP64 (64-bit 
Linux; 64-bits), and P64 (Win64; 32-bits) platforms.

A naive P/Invoke would be:

struct Timespec {
public int tv_sec;
public int tv_nsec;
}
class NativeMethods {
[DllImport (libc.so)]
public static extern int nanosleep (ref Timespec req, out 
Timespec rem);
}

This is naive because it assumes that time_t is 32-bits in size, and `long` is 
also 32-bits in size; in short, this will only work on 32-bit platforms, and 
will fail in weird ways on 64-bit platforms.

This can be fixed, and as such treating the declaration as a bug to be fixed is 
valid:

struct Timespec {
public IntPtr tv_spec;
public IntPtr tv_nsec;
}

Using `IntPtr` instead of `int` results in the use of 32-bit values on 32-bit 
platforms, and 64-bit values on 64-bit platforms. This is thus portable between 
ILP32 and LP64 Linux platforms...and thus breaks on Win64. In this case we can 
declare that Windows is unsupported (which makes sense as Windows doesn't 
provide nanosleep(2) anyway, unless you use cygwin.dll).

However, we're still assuming that `time_t` is an integral value, which is 
valid on Linux but is not required by the standard [3]:

time_t and clock_t shall be integer or real-floating types.

In this case it still might not matter...as long as we have the size correct (a 
32-bit float can still be read as a 32-bit int, it'll just look weird), but 
nothing stops some bizarre 32-bit POSIX platform from using a 64-bit double for 
time_t, which would invalidate the Timespec declaration.

Again, we can declare that the perfect is the enemy of the good and leave it as 
is...or we can involve native code to do the type conversions for us, which is 
what Mono.Posix.dll and libMonoPosixHelper.so do.

 - Jon

[0] https://github.com/mono/mono/blob/master/mono/mini/aot-runtime.c#L843
[1] http://mono-project.com/Dllimport
[2] http://linux.die.net/man/2/nanosleep
[2] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com

Re: [Mono-dev] how to fix TextWriterTraceListener disposal problem

[Jonathan Pryor]

On Apr 13, 2011, at 4:06 AM, Atsushi Eno wrote:
 Do you have any ideas how to solve this problem?

Is it actually a problem? :-)

The reason I ask is that I vaguely recall testing the same behavior under .NET 
at the time (circa 2002?), and .NET behaved the same way -- the stream was not 
flushed.

Furthermore, the only solution I know of to fix this (or knew of circa 2002), 
was to use a finalizer on TraceListener, which MSDN states TraceListener does 
not provide.

Consequently, I believe that TraceListener is not supposed to flush the stream 
at all, and if you really want the stream to be flushed you should set 
Trace.AutoFlush=true, either programmatically or via .config file; MSDN kindly 
provides the .config file snippet here:


http://msdn.microsoft.com/en-us/library/system.diagnostics.tracelistener.aspx

 - Jon

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

Re: [Mono-dev] Faster

[Jonathan Pryor]

On Mar 24, 2011, at 12:00 PM, Miguel de Icaza wrote:
 Plenty of our class library code has code like this:
 
 void Foo (Something x)
 {
if (x == null)
throw new ArgumentNullException (x);
x.DoSomething ();
x.AndThenMore ();
 }
...
 But what if we changed our code in Foo across our class libraries to
 do this instead:
 
 void Foo (Something x)
 {
try {
x.DoSomething ();
} catch (NullReferenceException e){
if (x == null)
 throw new ArgumentNullException (x);
else
  throw;
}
x.AndThenMore ();
 }

I don't think this would be a good idea, for two reasons:

 1. This is counter to years worth of code guidelines. Consequently, it will 
cause anybody new coming to the code to scratch their head. Clear and 
understandable code can't be overstated.

 2. This won't mesh at all with Code Contracts. Yes, Code Contracts suck (as 
currently envisioned), but the idea behind them is reasonable, and their IL 
rewriter currently supports the current legacy null checks for contract 
definitions, ending contracts at a Contract.EndContractBlock() call [0]:

void SoCalledLegacyContractMethod (string s)
{
if (s == null)
throw new ArgumentNullException (s);
Contract.EndContractBlock();
// ...
}

I don't think it's that unlikely that more of mscorlib.dll will gain contracts 
support in the future for improved static analysis of assemblies, which will 
require that argument checking be up front as is currently done anyway.

 - Jon

[0] 
http://msdn.microsoft.com/en-us/library/system.diagnostics.contracts.contract.endcontractblock.aspx

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

Re: [Mono-dev] AppActivate and System.Windows.Forms.SendKeys on Ubuntu 10.10

[Jonathan Pryor]

On Mar 16, 2011, at 4:07 PM, Quandary wrote:
 What, only SendKeys to WinForms, are you serious ?
 That doesn't make much sense.

It makes perfect sense.

 It sends KeyEvents to the Windowing system, which happens to be the
 WinAPI on Windows, or X11 on Linux for all intents and purposes.
 GTK has nothing to do with it.
 
 You send the keyboard keys as simulated input to X11, and before that,
 you set the focus window.

The problem is that there is no such mechanism in X11, at least not in a way 
that can be used in a straightforward fashion.

For example, Microsoft's SendKeys.Send() method is _probably_ implemented in 
terms of the SendInput() WinAPI function:

http://msdn.microsoft.com/en-us/library/ms646310(VS.85).aspx

So SendKeys.Send() presumably maps the input string into a set of INPUT 
structures, then sends the structures to SendInput() so that the operating 
system will interpret them. Note that this is _very_ low level, working at the 
keyboard level, not the thread event loop level.

One of the things that this allows is that SendKeys.Send(%{TAB}) (aka 
Alt+Tab) will change the active window.

Now, what does X11 provide? A cursory glance shows XSendEvent:

http://tronche.com/gui/x/xlib/event-handling/XSendEvent.html

This allows passing an XEvent, such as an XKeyEvent, to a given window.

Problem: In Windows, it's the operating system which handles the input, which 
thus allows OS capturing of Alt+Tab so that the active application is 
switched. In X11, XSendEvent() requires that you explicitly specify both the 
Display and Window that the event is being passed to. Consequently, there is NO 
MECHANISM to have Alt+Tab captured by the OS and thus change windows (even if 
Alt+Tab _will_ change windows when typed via the keyboard). This is because the 
WIndow Manager is grabbing Alt+Tab, but the Window Manager is a completely 
separate process, and there's not necessarily an easy way to grab the 
Display+Window for the Window Manager (which might not have a Window to begin 
with).

In short, you can't get there from here, as the entire X11 architecture is 
~completely different.

 At least on Windows.

Exactly. On Windows, everything uses the same WinAPI message looping mechanism. 
On X11, very little is consistent across toolkits, and X11 doesn't specify much 
(leaving it up to the Window Manager + applications + ... to work out the 
details).

Then there's OSX, which uses yet another completely different mechanism. 
SendKeys.Send() is inherently Windows specific; you should be glad it works for 
System.Windows.Forms apps at all.

 - Jon

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

Re: [Mono-dev] Process.Start and WaitForExit on MacOS X

[Jonathan Pryor]

On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote:
 I've discovered that Process.Start(ProcessStartInfo info) leaves child 
 processes hanging around until the parent process dies, unless you call 
 WaitForExit() on the child process.
...
 Is this a bug or by design?

The problem is the Process.ExitCode property. There's no way to retrieve this 
value except through the waitpid(2) (and related) system calls, so the process 
can't be fully disposed just in case the ExitCode property will be accessed.

That said, once the instance has been disposed, it shouldn't be necessary to 
keep anything open, and the child handles should be closed. Given that you 
_are_ using a `using` block, and thus disposing of the instance, it seems that 
this is likely a bug and that Process.Dispose() isn't fully closing all 
resources as it should.

(For that matter, the Process finalizer should also be disposing of unmanaged 
resources, and it looks like that isn't the case either).

Could you please file a bug?

Thanks,
 - Jon

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

Re: [Mono-dev] [PATCH] Incorrect signal handling for Sys V signal handler

[Jonathan Pryor]

I can't speak to the rest of the patch, but the mono/support patch can't go in 
as-is, as mono/support/signal.c is also built for Windows (it's part of 
MPH_C_SOURCE in mono/support/Makefile.am, which is included in the HOST_WIN32 
build).

MSVCRT.DLL DOES contain signal(3); it does NOT contain sigset(3), and thus this 
would break the Windows build.

Furthermore, OSX doesn't provide sigset(3) either, so this would break the OSX 
build as well.

You should patch configure.in to check for sigset, and wrap the sigset calls 
with HAVE_SIGSET, otherwise keep the existing signal calls.

 - Jon

On Jan 27, 2011, at 10:06 AM, Burkhard Linke wrote:

 Hi,
 
 signal handlers registered with signal(3) behave in a somewhat different way 
 for Sys V systems, e.g. Solaris. The manpage states that during the execution 
 of the signal handler, the signal disposition is set to SIG_DFL. This raises 
 two problems:
 
 a) a possible race condition, if the same signal occurs during the execution 
 of its signal handler
 
 b) handling the signal a second time, since the manpage (and the 
 implementation under Solaris..) does not reinstall the signal handler.
 
 The attached test program uses Mono.Unix.Signal to catch signals. Executing 
 it 
 under Solaris/x86 running Mono 2.8.1, Mono 2.6.7 and the git master gives the 
 following output:
 
 running as process 29499
 sending first HUP
 sending second HUP
 Hangup
 
 The second SIGHUP is not catched by the signal handler, terminating the 
 application (which is the default for SIGHUP).
 
 The applied patch solves the problem by replacing signal(3) with sigset(3). 
 sigset's semantic differs from signal's one; Instead of setting the signal to 
 default handling, it adds the signal to the process/threads signal masks, 
 executed the signal handler and restores the signal mask. Both problems 
 mentioned above are solved. Test program output after applying the patch to 
 git master:
 
 running as process 172
 sending first HUP
 sending second HUP
 sending third HUP
 terminating
 
 
 With best regards,
 Burkhard Linke
 mono_sigset.diffMain.cs___
 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-packagers] Mono 2.10 RC1

[Jonathan Pryor]

On Jan 23, 2011, at 2:56 PM, Jo Shields wrote:
 Preliminary notes:
 * mdoc is still a 2.0 app. Is this intentional?

This doesn't need to be per-profile, as it uses Cecil to read IL (and Cecil 
will read ~any version).

By the same logic it could be a 4.0 app; it really doesn't matter.  It's 
currently a 2.0 app because, circa a few months ago, the 4.0 build was optional 
but building docs wasn't, so we needed to ensure that mdoc was present so the 
build wouldn't break.  Then we changed the build so that docs would only be 
built when building the 4.0 profile, somewhat mooting things, but we didn't 
change mdoc to be built under 4.0 again (as there isn't/wasn't much point).

If there's a reason to make mdoc a 4.0 app, I'm all ears, otherwise I don't 
currently see the need (as I'm not using any 4.0 features in mdoc).

 - Jon

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

Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()

[Jonathan Pryor]

On Jan 18, 2011, at 4:52 PM, mike wrote:
 Hey Jonathan P,  I noticed that u wrote the 'Interop with Native Libraries'
 article on the mono web site. Very good stuff. I have a question, can mono
 link or inter op to a Linux static library instead of a shared object? (i.e
 mylib.a)

_Maybe_. :-)

This won't work:

[DllImport (mylib.a)]
static extern void Foo();

That won't work because dlopen(3) is used to load the specified library, and 
dlopen(mylib.a) will fail.

HOWEVER, if you're using the Mono embedding API, write a native app, and link 
your native app to mylib.a:

gcc -o yourapp yourapp.c mylib.a `pkg-config --cflags mono-2` ...

Then you can do:

[DllImport (__Internal)
static extern void Foo();

See also:

http://www.mono-project.com/DllImport#Linux_Shared_Library_Search_Path

http://www.mono-project.com/Embedding_Mono#Exposing_C_code_to_the_CIL_universe

 - Jon

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

Re: [Mono-dev] Dynamic bootstrapping

[Jonathan Pryor]

I don't fully understand your scenario, but I _suspect_ that what you want is a 
hypervisor,[0] which is basically a nano-kernel (of sorts) that other OS 
kernels run atop as peers to one another.  There are several commercial and 
open-source versions, such as Xen [1], Kernel Based Virtualization [2] and 
VMware ESX [3].

Now, I realize that you asked for a non-virtualized solution, but iirc at least 
some of those permit ~direct access to hardware (e.g. video cards tend not to 
be virtualized), and offhand it's the only technology I can think of that is 
remotely close to what you're asking for.

 - Jon

[0] http://en.wikipedia.org/wiki/Hypervisor
[1] http://www.citrix.com/English/ps2/products/product.asp?contentID=683148
[2] http://www.linux-kvm.org/page/Main_Page
[3] http://en.wikipedia.org/wiki/VMware_ESX

On Jan 13, 2011, at 2:38 PM, Ianis G. Vasilev wrote:

 First - hello. Second - I wasn't sure where to ask, but I hope I asked in the 
 right place.
 I am about to start a project and I am not sure whether a part of the project 
 is possible. I want to know if there is any way to launch a new process in 
 the current operating system which goes through the bootstrapping cycle in a 
 thread separate from the loaded OS threads. Let me explain it better.
 Imagine we have a loaded operating system, for example Ubuntu Linux, and a 
 single-core processor. I want to launch a process with Superuser permissions, 
 which will create a thread in the current OS. That thread should give 
 BIOS/EFI a command to load a boot image, based on the mono livecd,  without 
 interfering the OS itself. And, what is more important – without virtualizing 
 any hardware. Instead of using virtual machines, I want to access the 
 hardware resources of a computer directly. This should result in two separate 
 kernels sharing different parts of hardware resources on a computer. In other 
 words, the goal is to create two simulated computers from one real with each 
 kernel using its own hardware resources, i.e. dividing the hardware resources 
 into two parts.
 I know it is probably possible by creating two custom kernels which run 
 asynchronously and each one giving a command to run the other. With more than 
 one processor cores it should probably be possible to run the kernels 
 synchronously. The monitor should make a split-screen and the kernel managing 
 the active screen should accept all the input. But is it possible to do this 
 without modifying the no kernel?
 More simply, can the second OS run as a process in the first OS?
 In case I didn’t explain it well, I’ve included an attachment which should 
 make it clear.
  
 Thank you in advance,
 Sincerely yours,
 Ianis G. Vasilev
 Chart.png___
 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] File not found error when using Activator.CreateInstanceFrom()

[Jonathan Pryor]

On Jan 6, 2011, at 5:13 PM, mike wrote:
 Thanks for the reply. Not sure what you mean as I'm not doing a
 LoadLibrary().

Yes, you are: it's implicit to P/Invoke.  (OK, so .NET is doing it on your 
behalf under the covers, but a LoadLibrary() is still occurring.)

Since you're on Windows, LD_LIBRARY_PATH has no effect (that's a Unix 
environment variable).  Setting PATH might help; see:

http://mono-project.com/DllImport#Windows_DLL_Search_Path

 Compile the sample code(s) above in this post for an example
 of how to produce the error.

The fundamental problem is that your example is still incomplete.  Providing a 
.zip may be more appropriate, but the fundamental question is this:  how 
_exactly_ you're compiling your native libraries?

For example, when I extract your source files from the relevant email and 
compile like this:

CL /c MyEnviron.cpp
LINK /DLL /OUT:Native\Environ.dll MyEnviron.obj

CL /c MyLib.cpp
LINK /DLL /OUT:Native\Test_Native.dll MyLib.obj Native\Environ.lib

CSC app.cs /platform:x86

The above allows your code to work, but it took me an hour to re-learn enough 
CL+LINK to make it work.  (My first effort at `CL /LD /FoNative\Test_Native.dll 
MyLib.cpp` failed horribly, for reasons I can't fathom.  Thanks, Microsoft!)  
I'm not sure why this would be failing under Mono, so that does appear to be a 
bug.

However, a workaround for mono is to place the .DLL files into the same 
directory as your .EXE, instead of into a Native sub-directory.  (At least, 
this works for me.)

Furthermore, your C# code appears wrong (or you're doing something different 
when compiling your native libraries).  Specifically:

// Test Method
[DllImport(Native\\Test_Native.dll,
EntryPoint = Test,
ExactSpelling = false,
CallingConvention = CallingConvention.StdCall)]
static extern void _Test(); 

Test_Native.dll!Test() will default to Cdecl calling convention, not StdCall, 
so your calling convention is wrong.  This often won't immediately break things 
(as .NET will occasionally detect the stack mismatch and fix it), but it can 
break things, and thus should be fixed.  I'm also not sure why you're setting 
ExactSpelling at all.

 - Jon

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

Re: [Mono-dev] mono linker - mscorlib.dll

[Jonathan Pryor]

On Jan 7, 2011, at 12:36 PM, Guillaume Pouillet wrote:
 Isn't AppDomain's security useable to sandbox the application ?

If Mono had a fully implemented Code Access Security (CAS) mechanism?  Yes.

Unfortunately, Mono doesn't, so AppDomain sandboxing doesn't work.

The only sandboxing/security mechanism that Mono supports is CoreCLR, as used 
in Moonlight/Silverlight.

 - Jon

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

Re: [Mono-dev] Modifying and compiling mono source code

[Jonathan Pryor]

On Dec 25, 2010, at 5:40 PM, Tomi bosak.to...@gmail.com wrote:
 Let's say that I modify mono sources with Visual Studio 2010 on my
 Windows machine and I want to test it on linux (with parallel mono
 environments) hosted at VPS. Is it normal to just overwrite old dll on
 linux machine with a new one copied from Windows?

Yes, but you probably don't want to overwrite the distro-provided assemblies.  
You should instead overwrite assemblies from a parallel mono build; see also:

http://www.mono-project.com/Parallel_Mono_Environments

 Wouldn't I be yelled at when I decide to implement something (and then
 push it to master) if I, for example, use VS 2010 to modify sources?

No problem if you use the VS2010 IDE. There would be problems if you downloaded 
and used the .NET reference sources, which VS2010 occasionally will kindly 
offer to install...

 - Jon

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

Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()

[Jonathan Pryor]

On Dec 19, 2010, at 4:57 PM, mike wrote:
 For some reason, I
 thought we chose this CreateInstance() approach over the P/Invoke for
 performance reasons.

If you have concerns about P/Invoke performance, you might consider looking 
into the System.Security.SuppressUnmanagedCodeSecurityAttribute attribute:


http://msdn.microsoft.com/en-us/library/system.security.suppressunmanagedcodesecurityattribute.aspx

This can help speed up P/Invoke performance by disabling security-related stack 
walks on .NET.  On Mono I *believe* this won't have an effect, as CAS is 
disabled by default (as it isn't supported).

 - Jon

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

Re: [Mono-dev] File not found error when using Activator.CreateInstanceFrom()

[Jonathan Pryor]

On Dec 16, 2010, at 3:24 PM, mike wrote:
 Thanks for the reply. Here is an example attached driver (test.cs) which
 calls the Activator.CreateInstanceFrom(). Runs fine under NET 2.0 but bombs
 under mono 2.8 with the 'implement type compare for 1b!' error message. You
 will need to construct asmall native C++ dll with a matching class name and
 constructor to call. 

On .NET, you're _not_ invoking a native C++ DLL, you're invoking a C++/CLI 
DLL. (It must be this way, as a normal native C++ DLL will use tons of 
compiler-specific name mangling for the types and namespaces, so 
mycplusplusnamespace.mycplusplusclass has no chance of working, ever, on any 
platform, unless the runtime directly supports native C++ code, which would 
likely make it specific to a particular C++ compiler, thus somewhat defeating 
the point of the CLR...)

Mono does NOT support C++/CLI assemblies, hence the error you see.

In short, Don't Do That, avoid C++/CLI and use P/Invoke instead if you want to 
run on Mono under any platform other than Windows.

(Or, compile your C++/CLI assembly with /clr:pure so that it isn't a mixed-mode 
assembly and instead consists solely of IL.  How practical this is depends upon 
your code.)

 - Jon

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

Re: [Mono-dev] libffi

[Jonathan Pryor]

On Dec 13, 2010, at 7:08 PM, Charles Strahan wrote:
 If I understand correctly, we'd have two options for using DLLImport:

I am missing some important context, so I don't understand what you want to 
accomplish, what the problems are, and thus what the best way to do it is.  
As per my original response, libffi was removed from mono for performance 
reasons, and it is thus unlikely to return.

I do not know or understand the semantics of RubyFFI, how it's similar to 
libffi  P/Invoke, and how it differs from P/Invoke, much less how to map 
RubyFFI use to P/Invoke use (if that's even desirable; again, I have no idea).

  1.) Emit classes at runtime, containing the necessary native
 function adorned with the DLLImport attribute.

I can't say if this would work for _you_, but I can say that this can work in 
general; see:


https://github.com/mono/mono/blob/master/mcs/class/Mono.Posix/Mono.Unix.Native/CdeclFunction.cs

  2.) Use DLLImport/PInvoke to provide access to
 dlopen/LoadLibrary[Ex] and other similar functions, to dynamically
 load DLLs and invoke their functions.

This seems silly, given that [DllImport]  P/Invoke are built upon 
dlopen+dlsym/LoadLibrary+GetProcAddress; I do not see the point.

 - Jon

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

Re: [Mono-dev] Mono.Options

[Jonathan Pryor]

On Tue, 2010-11-16 at 08:44 +, Paul F. Johnson wrote:
 Is Mono.Options switched off in the 2.8 tarball? I'm not seeing it
 getting packaged at the end of the build (either with a RPM script or as
 a direct build)

I'm unable to reproduce; specifically, I built and installed the sources
from [0] on openSUSE 11.2, and $prefix/lib/mono-source-libs/Options.cs
is present.  mono-2.8/mono.spec also includes a line to bundle the
$prefix/lib/mono-source-libs directory into mono-devel package:

mono-core.spec:1039: %_prefix/lib/mono-source-libs

I have no idea why you're not seeing this packaged.

 - Jon

[0] http://ftp.novell.com/pub/mono/sources/mono/mono-2.8.tar.bz2

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

Re: [Mono-dev] xbuild - ** ERROR **: shm_semaphores_init: semget error: No space left on device.

[Jonathan Pryor]

On Fri, 2010-11-12 at 13:11 -0800, Arne Claassen wrote:
 Right, that's why I'm confused. That release states Users seeking  
 absolute stability should stay on Mono 2.6, but my impression is that  
 all bug fixes are just going into 2.8.

Stability generally means minimal changes.  The bug fixes going into
2.8 likely change lots of code, and thus have had (comparatively) little
testing, whereas the aim of 2.6 is to fix bugs while making as few
changes as possible (as we don't want a fix for one bug to introduce
another).

 - Jon


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

Re: [Mono-dev] Deadlock Detection in Mono Libraries

[Jonathan Pryor]

On Mon, 2010-11-08 at 07:35 +0530, Arun K wrote:
 I am performing a static analysis on the mono 2.4.x libraries.

2.4.x?  How old!  (We're up to 2.8 now...)

 The aim of this analysis is to detect potential deadlock scenarios
 within the libraries. As a first step, I wanted to find if any
 synchronized method invokes another synchronized method either
 directly or eventually

Thus, the *most* important question: How do you define synchronized?

My guess is that your definition is a method with the attribute:

[MethodImpl (MethodImplOptions.Synchronized)]

If this is the case, the problem you're encountering is that this is
explicitly counter to .NET documentation, e.g. [0, 1]:

Generally, it is best to avoid locking on a public type, or on
object instances beyond the control of your application. For
example, lock(this) can be problematic if the instance can be
accessed publicly, because code beyond your control may lock on
the object as well. This could create deadlock situations where
two or more threads wait for the release of the same object.

.NET guidelines advocate declaring a *private* object instance and
locking on that, instead of using Synchronized methods. [2]

In short, if you see [MethodImpl (MethodImplOptions.Synchronized)],
you're either looking at compatibility with .NET, or you're looking at a
probable bug.

 - Jon

[0] http://msdn.microsoft.com/en-us/library/ms173179.aspx
[1] http://msdn.microsoft.com/en-us/library/ms182290(VS.80).aspx
[2] My guess is that the only reason you can lock on System.Object and
not some more restricted type is for Java compatibility...which is the
~same reason that .NET arrays are covariant.


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

Re: [Mono-dev] UnixUserInfo issues in OpenBSD

[Jonathan Pryor]

I have no idea why it's failing.  Sorry.

What I can do is send you a C program which closely mirrors what
Mono.Unix is doing.  Could you compile and run it, and see if it fails
in the same ways?  The program source is attached.

 - Jon

On Wed, 2010-10-13 at 10:43 +0200, pablosantosl...@terra.es wrote:
 Hi all,
 
 The following simple program fails on OpenBSD:
 
 using System;
 using Mono.Unix;
 
 public class Info
 {
 
 public static void Main()
 {
 Console.WriteLine(Environment.UserName);
 Console.WriteLine(new
 UnixUserInfo(Environment.UserName).UserName);
 Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
 }
 }
 
 
 Environment.UserName retrieves the right user.
 
 
 The two next calls fail saying invalid param:
 
   Console.WriteLine(new UnixUserInfo(Environment.UserName).UserName);
   Console.WriteLine(UnixUserInfo.GetRealUser().UserName);
 
 It seems the problem is the return of the native method getpwuid_r, that
 returns 1 instead of 0.
 
 I tried running as root to (suspected it could be a permissions issue)
 but I get the same result.
 
 I thought it could be related to an old issue with UnixGroupInfo which
 fails if the groups are incorrectly defined (have unexisting users) but
 I think this time my config files are correctly set... :O
 
 Thanks,
 
 pablo
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

#include stdio.h
#include stdlib.h
#include sys/types.h
#include pwd.h
#include errno.h

static inline int
recheck_range (int ret)
{
	printf (# checking return value %i; errno=%i\n, ret, errno);
	if (ret == ERANGE)
		return 1;
	if (ret == -1)
		return errno == ERANGE;
	return 0;
}

static void
dump_user (const char *user)
{
	int r;
	struct passwd p, *prev;
	char *buf, *buf2;
	size_t buflen;

	buf = buf2 = NULL;
	buflen = 2;

	do {
		buf2 = realloc (buf, buflen *= 2);
		if (buf2 == NULL) {
			printf (error: unable to allocate enough memory\n);
			free (buf);
			return;
		}
		buf = buf2;
		errno = 0;
	} while ((r = getpwnam_r (user, p, buf, buflen, prev))  recheck_range (r));

	if (r == 0  !prev) {
		printf (User '%s' was not found.\n, user);
		free (buf);
		return;
	}

	printf (User %s:\n, user);
	printf (\t pw_name=%s\n, p.pw_name);
	printf (\t  pw_uid=%i\n, p.pw_uid);
	printf (\t  pw_gid=%i\n, p.pw_gid);
	printf (\tpw_gecos=%s\n, p.pw_gecos);
	printf (\t  pw_dir=%s\n, p.pw_dir);
	printf (\tpw_shell=%s\n, p.pw_shell);

	free (buf);
}

int main (int argc, char **argv)
{
	int i;
	for (i = 1; i  argc; ++i) {
		dump_user (argv [i]);
	}
	return 0;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] UnixUserInfo issues in OpenBSD

[Jonathan Pryor]

On Wed, 2010-10-13 at 16:38 +0200, pablosantosl...@terra.es wrote:
 This is what I get:
 
 $ ./a.out tester
 # checking return value 1; errno=13

That's...horribly wrong.

First, what's errno=13?  (i.e. what EVALUE is 13?  I'm sure OpenBSD has
different values than Linux does.)

Regardless, OpenBSD doesn't appear to be conforming to the standard
here:

http://www.opengroup.org/onlinepubs/009695399/functions/getpwnam_r.html

If successful, the getpwnam_r() function shall return zero;
otherwise, an error number shall be returned to indicate the
error. 

The value '1' is likely not the correct errno for ERANGE (Under Linux,
EPERM has the value 1), and since the return value isn't -1
recheck_range() won't check errno against ERANGE either.

However, this does point out a bug in MonoPosixHelper: if getpwnam_r()
returns non-zero it should treat it as an error, which is clearly not
happening here (and is why we're printing garbage data to the screen).

This would only marginally help you, though, as it would result in no
users being found, ever.

The fundamental problem is that Mono_Posix_Syscall_getpwnam_r()'s logic
for checking for ERANGE (so it'll resize the buffer and try the call
again) is failing under OpenBSD, and from what I can see here the
problem is within OpenBSD, not MonoPosixHelper.

Patches welcome to properly support OpenBSD. :-)

 - Jon


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

Re: [Mono-dev] System.PlatformID

[Jonathan Pryor]

On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote:
 When I query System.Environment.OSVersion.Platform on Linux I get a
 value that will equate to 128.  Yet, this is not in the source code
 definition for the PlatformID enum.

It means you're running in the 1.0 profile.  If you were running under
the 2.0 profile, you'd get 4 (PlatformID.Unix).  See:

http://www.mono-project.com/FAQ:_Technical

Quote:

The first versions of the framework (1.0 and 1.1) didn't include
any PlatformID value for Unix, so Mono used the value 128. The
newer framework 2.0 added Unix to the PlatformID enum but,
sadly, with a different value: 4 and newer versions of .NET
distinguished between Unix and MacOS X, introducing yet another
value 6 for MacOS X.

 Question: is 128 supposed to mean Linux?

It means Unix under the 1.x .NET profile; under the .NET 2.0 profile,
PlatformID.Unix (4) is returned.

 I am wondering if there is a better way or if this is all that can be done.

Targeting .NET 2.0+ will help (no 128 value), but only so much (there's
still distinct PlatformID.Unix and PlatformID.MacOSX values), so
preferable (normally) are feature checks, not platform checks.

Feature checks are also more useful anyway, as a feature may be added in
some version of a platform, and (based on reading years of Dr. GUI
articles in MSDN) platform version detection and handling is HARD.  You
would not believe the number of errors applications make doing that...

 Also, what if Microsoft suddenly came out of nowhere and said that 128
 will map to AIX?

I would laugh.  A lot.  (AIX?!  Seriously?)

The matter still has a theoretical nature, which can be answered thus:
dontworryaboutit.

More specifically, Mono 2.6 is the last release with 1.x profile
support, and thus is the last version that will return 128 for
PlatformID on Unix platforms.  (Plus, most actual apps have been 2.0
apps for quite some time.).  Mono 2.8 is 2.0+ only, and thus will never
return 128.

Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes,
so even if Microsoft added a new enum value, only mono master will
actually receive the value, not 2.6 (or likely 2.8, at this point).

Thus, in practice, it's not really worth worrying about.

 - Jon


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

Re: [Mono-dev] Stability regression on recent git head

[Jonathan Pryor]

On Thu, 2010-09-16 at 18:38 +0100, Dick Porter wrote:
 It still crashes with the same stack trace, even with git master as of  
 a couple of minutes ago.  I double-checked, and your change is there.

Unfortunately, I think we're rapidly hitting the point of needing to
suspect/assume a horrible GC bug/regression, and the only way to pin
this down will be a test case that we can hand off to the GC devs.

Any chance you can create a reproducible test case for us?

Thanks,
 - Jon


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

Re: [Mono-dev] Stability regression on recent git head

[Jonathan Pryor]

I committed a workaround for this in commit 8cdb685.  Could you see if
that works for you?

Thanks,
 - Jon

On Wed, 2010-09-15 at 11:55 +0100, Dick Porter wrote:
 Hi all
 
 We've been testing the sgen GC with our server, as part of the effort to
 stabilise it.  Recently however we've noticed that the runtime has been
 very unstable, in particular using the _Boehm_ GC.
 
 I can start our server with this morning's git head runtime, with Boehm
 GC, and as soon as I issue a client command (which uses remoting) I get
 the following stack trace on the server:
 
 Plastic SCM daemon up. 3.0.187.2 1151 ms startup time
 Stacktrace:
 
   at (wrapper managed-to-native) Mono.Unix.UnixSignal.WaitAny
 (intptr[],int,int) 0x3
   at (wrapper managed-to-native) Mono.Unix.UnixSignal.WaitAny
 (intptr[],int,int) 0x3
   at Mono.Unix.UnixSignal.WaitAny (Mono.Unix.UnixSignal[],int) 0x0011e
   at Mono.Unix.UnixSignal.WaitAny (Mono.Unix.UnixSignal[]) 0x00012
   at Codice.CM.Daemon.Daemon.HandleSignals () 0x0013a
   at Codice.CM.Daemon.Daemon.LaunchUnixDaemon
 (Codice.CM.Server.ISystemRunner,string) 0x00036
   at xy.c (Codice.CM.Server.SystemRunner) 0x0005f
   at xy.a (an) 0x0035c
   at xy.a (string[]) 0x000b1
   at (wrapper runtime-invoke) Module.runtime_invoke_int_object
 (object,intptr,intptr,intptr) 0x0008f
 
 
 This is 100% repeatable, with the identical stack trace every time.
 Interestingly, it doesn't happen with the sgen GC though I have seen
 this stack trace appear intermittently with sgen, which suggests to me
 that there might be some memory corruption going on that is more likely
 to be tickled by the Boehm GC.
 
 The actual line of code that triggers the segfault is in
 mono/support/signal.c, in wait_for_any():
 
 diff --git a/support/signal.c b/support/signal.c
 index abd7638..a7f97fa 100644
 --- a/support/signal.c
 +++ b/support/signal.c
 @@ -351,7 +351,7 @@ wait_for_any (signal_info** signals, int count, int
 *currfd,
 ptv = tv;
 }
 r = poll (fd_structs, count, timeout);
 -   } while (keep_trying (r)  !shutting_down ());
 +   } while (keep_trying (r) /* !shutting_down ()*/);
 
 idx = -1;
 if (r == 0)
 
 Commenting out the delegate call cures the crash for me.
 
 I reopened bug https://bugzilla.novell.com/show_bug.cgi?id=592981 with these 
 traces, but
 as no-one has commented on it in a couple of weeks I'm highlighting it here 
 too.
 
 - Dick
 
 
 ___
 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-Interop with Native Libraries

[Jonathan Pryor]

On Fri, 2010-09-03 at 09:13 -0300, Rafael Teixeira wrote:
 The highest risk is that without the
 [StructLayout(LayoutKind.Sequential)] the compiler is free to
 rearrange the order of the fields to make things as compact as
 possible but obeying to the alignment requirements of the architecture

Never mind the C# compiler, the JIT could change the layout between
program runs!  (Not that any JIT I know of _would_, but nothing that I
know of requires consistency between one program run and the next.)

For example, pointers are usually placed together and like-size fields
are coalesced; this could produce different layouts between 32-bit and
64-bit platforms (as 'int' could be intermixed with pointers on 32-bit
but won't be on 64-bit).

 - Jon


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

Re: [Mono-dev] libffi

[Jonathan Pryor]

On Thu, 2010-08-19 at 10:35 -0700, Ryan Riley wrote:
 Has anyone created or investigated Mono support for libffi?

Once upon a time, Mono used libffi directly.  It was removed in r724
(git SHA1 ID d0cd6059c1b2edad12eb67cb8e64b3cd187be1b1) on 2001-09-05
(and earlier).  Unfortunately, the commit message is useless, but iirc
the reason for removing it was because it was significantly slower than
what Mono could do itself.

 I'd like to contribute this to help support Ruby-FFI for IronRuby.

I imagine IronRuby doesn't require it's own FFI, it would just use the
usual .NET FFI of DllImport, no?

As for supporting Ruby-FFI, perhaps you can extend the existing Mono FFI
support to support Ruby?  I don't know what would be involved...

 - Jon


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

Re: [Mono-dev] Options needed for imported Linux libraries.

[Jonathan Pryor]

On Thu, 2010-08-12 at 16:49 +0200, Omar Siam wrote:
 I compiled a C so lib on Linux to do ioctl calls and tried to use it
 with DllImport but when I pass structures by ref or StringBuilder for
 returning char* buffers to my library everything is behaving strange.

http://mono-project.com/Dllimport#Classes_and_Structures_as_Return_Values
http://mono-project.com/Dllimport#Strings_as_Return_Values

In short, don't use StringBuilder as a method return type.  Use
StringBuilder as a parameter type, and you _may_ need to use the [Out]
parameter attribute on the StringBuilder.

 I tried to Marshal my structure to an HGlobal IntPtr as the docs say
 passing structures by ref to unmanaged code is unsupported

Where do the docs say this?

As Robert Jordan mentioned, having the managed and native function
signatures would be very helpful.

 - Jon


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

Re: [Mono-dev] Updated DateTime.

[Jonathan Pryor]

On Jul 14, 2010, at 2:19 AM, Miguel de Icaza mig...@novell.com wrote:
 This works on my system, but I am unable to run the test suite currently.

You might not be able to run the full unit tests, but you should be able to run 
a subset of them:

make FIXTURE=System.DateTimeTests run-test

 - Jon

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

Re: [Mono-dev] Referring to libraries on the command line

[Jonathan Pryor]

On Wed, 2010-07-14 at 07:16 +0100, Russell Wallace wrote:
 I'm trying to compile a program with gmcs, which wants references to
 all libraries in the current directory. Normally one would specify
 this with *.dll, but because gmcs wants a prefix of -r: in each case,
 this breaks. Is there any way to obtain this effect, e.g. some way to
 expand a wild card and then prepend a prefix to each expanded name?
 (Ubuntu Linux, make under bash, if it matters.)

make(1) has Substitution References (§6.3.1 in the `info make` page),
which allows:

REFS = Foo.dll Bar.dll Baz.dll

SOURCES = yourapp.cs

yourapp.exe : $(SOURCES) $(REFS)
gmcs -out:$@ $(REFS:%=-r:%) $(SOURCES)

Here, we're using $(REFS:%=-r:%) to prefix every token within $(REFS)
with `-r:`, thus resulting in `-r:Foo.dll -r:Bar.dll -r:Baz.dll`.

 - Jon


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

Re: [Mono-dev] diff: bug-438454.exe.stdout.expected: No such file or directory

[Jonathan Pryor]

Should be fixed in r160202.

 - Jon

On Wed, 2010-07-07 at 21:20 +0900, KISHIMOTO, Makoto wrote:
 Hello,
 
 In my FreeBSD box, make check of Mono svn trunk failed. log is follow.
 
 $ gmake check
 Making check in po
 gmake[1]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po'
 Making check in mcs
 gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po/mcs'
 gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/po/mcs'
 gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po'
 gmake[2]: Nothing to be done for `check-am'.
 (snip)
 Testing generic-xdomain.2.exe ...
 Testing generic-type-load-exception.2.exe ...
 Testing bug-616463.exe ...
 gmake[5]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/tests'
 Testing exists.exe...
 Testing runtime-invoke.gen.exe...
 Testing imt_big_iface_test.exe...
 Testing bug-438454.exe...
 diff: bug-438454.exe.stdout.expected: No such file or directory
 gmake[4]: *** [test-process-exit] Error 2
 gmake[4]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/tests'
 gmake[3]: *** [check-am] Error 2
 gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/tests'
 gmake[2]: *** [check-recursive] Error 1
 gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono/tests'
 gmake[1]: *** [check-recursive] Error 1
 gmake[1]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/mono'
 gmake: *** [check-recursive] Error 1
 ___
 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] Adding documentation for new namespace

[Jonathan Pryor]

Make sure you're running monodoc trunk (maybe 2.6; not sure). 2.4 has lots of 
known+filed+fixed-in-trunk bugs. 

 - Jon

On Jul 1, 2010, at 7:11 AM, Chris Bacon ch...@dunelm.org.uk wrote:

 Hi Jon,
 
 Thanks for thes instructions.
 
 When I run monodoc and select one of the new namespaces in corlib (e.g. 
 System.Diagnostics.Contracts) monodoc throws an exception:
 ch...@ubuntupc:~/Mono/mcs/class/corlib$ monodoc --edit Documentation/en
 using WebKit
 using WebKit
 Marshaling changed signal
 Exception in Gtk# callback delegate
   Note: Applications can use GLib.ExceptionManager.UnhandledException to 
 handle the exception.
 System.Reflection.TargetInvocationException: Exception has been thrown by the 
 target of an invocation. --- System.ArgumentNullException: Argument cannot 
 be null.
 Parameter name: path
   at System.IO.FileStream..ctor (System.String path, FileMode mode, 
 FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, 
 FileOptions options) [0x0] 
   at System.IO.FileStream..ctor (System.String path, FileMode mode, 
 FileAccess access, FileShare share) [0x0] 
   at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor 
 (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
   at System.IO.File.OpenRead (System.String path) [0x0] 
   at ICSharpCode.SharpZipLib.Zip.ZipFile..ctor (System.String name) [0x0] 
   at Monodoc.HelpSource.GetHelpXmlWithChanges (System.String id) [0x0] 
   at Monodoc.EcmaHelpSource.RenderNamespaceLookup (System.String nsurl, 
 Monodoc.Node match_node) [0x0] 
   at Monodoc.RootTree.RenderUrl (System.String url, Monodoc.Node match_node) 
 [0x0] 
   at Monodoc.TreeBrowser.RowActivated (System.Object sender, System.EventArgs 
 a) [0x0] 
   at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
 (object,object[],System.Exception)
   at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags 
 invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, 
 System.Globalization.CultureInfo culture) [0x0] 
   --- End of inner exception stack trace ---
   at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags 
 invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, 
 System.Globalization.CultureInfo culture) [0x0] 
   at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] 
 parameters) [0x0] 
   at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x0] 
   at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) 
 [0x0] 
   at System.Delegate.DynamicInvoke (System.Object[] args) [0x0] 
   at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs 
 args) [0x0] 
   at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x0] 
   at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr 
 return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, 
 IntPtr marshal_data) [0x0] 
at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, 
 Boolean is_terminal)
at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr 
 return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, 
 IntPtr marshal_data)
at Gtk.Application.gtk_main()
at Gtk.Application.Run()
at Monodoc.Driver.Main(System.String[] args)
 ch...@ubuntupc:~/Mono/mcs/class/corlib$
 
 It doesn't crash when selecting a namespace that isn't new.
 
 Thanks
 Chris
 
 Jonathan Pryor wrote:
 
 On Wed, 2010-06-30 at 14:58 +0100, Chris Bacon wrote:
   
 I would like to add some documentation for the 
 System.Diagnostics.Contracts namespace, for which there is currently no 
 documentation.
 
 I cannot see a way to add a new namespace using the Mono Documentation 
 Library. Please could someone let me know how best to do this.
 
 
 cd mcs/class/corlib
  # or some other assembly directory.
 make PROFILE=net_4_0 doc-update
 # generates doc stubs in Documentation/en
 monodoc --edit Documentation/en
  # view the 'Mono Documentation/mscorlib' node in the
  # left-hand pane. [0]
 
 You can then edit e.g.
 mcs/class/corlib/Documentation/en/System.Diagnostics.Contracts/*.xml,
 `svn add` your XML files and `svn commit` them.
 
 I've just committed the doc stubs for mscorlib.dll v4.0, so your first
 commit won't intermix stubs with content (and be gigantic); r159740.
 
 To install the docs:
 
 cd mcs/docs
 rm netdocs{.tree,.zip}
 make PROFILE=net_4_0
 make PROFILE=net_4_0 install
 
 The intermediate `rm` is needed to ensure that nedocs.zip is rebuilt, as
 the make(1) dependencies for rebuilding are inadequate.
 
 Once you've `make install`ed, monodoc will show the new documentation.
 
  - Jon
 
 [0] I can't actually recommend 'monodoc --edit' for editing
 documentation [1], but it is handy for viewing

Re: [Mono-dev] Standard name for mcs

[Jonathan Pryor]

On Sun, 2010-06-27 at 21:29 +0100, Russell Wallace wrote:
 On Sun, Jun 27, 2010 at 9:22 PM, Mark de Bruijn | Dykam
 kram...@gmail.com wrote:
  The problem is that not all version of C# are completely backwards
  compatible themselves.
 
 I was under the impression Microsoft were being very careful about
 maintaining backward compatibility in both the language and the
 library.

They do, but they only try so hard.

For example, the semantics of token evaluation changed from C#1 to C#2
due to generics, e.g. the parsing of 

F(GA, B(7));

In C#1, that would be a call to F(bool, bool) with `GA` as the first
argument, and `B7` as the second argument.

In C#2, the semantics are changed so F(T) is looked for, and the generic
method GA,B() is invoked with the value 7.

Most of the breaking changes between C#1 and C#2 are of this manner.

There are other breaking changes between C#3 and C#3 SP1, e.g.

http://msdn.microsoft.com/en-us/library/cc713578(VS.90).aspx

Most of these could be argued as corner cases where the implementation
didn't meet the spec (e.g. fixing double invocation of 'finally' blocks,
ensuring that 'params' within indexers matches the interface, etc.).

Then there's moving from C#3 to C#4:

http://msdn.microsoft.com/en-us/library/ee855831.aspx

Most of these are changes due to the new C#4 language features.

  If that fails, it's basically going to be a choice between
 going back to Java (which I'd rather not do) or back to C++ (which I'd
 really rather not do).

Java is a stagnant language, which has taken back-compat to such an
excess that improving the language is near impossible (which is likely
why other JVM languages like Scala are increasingly popular).

C++ isn't necessarily any better, either: there are lots of compiler
bugs, non-standardized compiler extensions, and the language itself will
be changing things (e.g. `auto` is being repurposed in C++-1x, thus
changing the semantics of a previously defined (and deprecated)
keyword).

Also, if we take the above C#3 to C#3 SP1 list as a guide, any compiler
fix that is done to better match the spec would be a breaking change,
and when we have compilers chasing and/or leading the spec (as is
true for most of the C++-1x features), things WILL change to be more
conformant with the spec.

In short, for ANY language which is actually changing (even minimally),
breakage is going to be a possible factor. The only languages where
this isn't true is for dead languages which aren't changing anymore (and
arguably aren't being used much anymore because they haven't changed).

 - Jon


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

Re: [Mono-dev] Porting .NET application (Namespaces)

[Jonathan Pryor]

On Wed, 2010-06-30 at 06:40 -0700, djdeveloper wrote:
 I'm asking myself how to port a C#.NET app to mono. Do i have to replace all
 the usual namespaces like e.g. System.Data with Mono.Data and so on?

No.  Mono implements most of the .NET System.* namespaces using the same
assembly names, namespace names, and class names.  Usually [0], no
source code modification is needed.

  Or
 do I just have to compile using the mono compiler and that's all? If yes,
 what's the use of e.r. Mono.Data ?

Mono prefixed namespaces and assemblies are for Mono extensions
to .NET and internal implementation details.

For example, Mono.Posix.dll and the Mono.Unix namespace contain POSIX
wrappers which are not present in .NET.

There is no Mono.Data.dll, but there is a Mono.Data.Sqlite.dll which
contains an ADO.NET provider for SQLite (which .NET doesn't provide). 

Mono.Simd provides a managed wrapper over SIMD instruction sets such as
SSE3; .NET has no equivalent.

Other Mono.* directories are used to implement the public .NET classes
and namespaces, e.g. the implementation of many System.Xml types are
done in mcs/class/System.XML/Mono.Xml*, and mscorlib.dll requires a
minimal XML parser contained in mcs/class/corlib/Mono.Xml which isn't
exposed publicly.

 - Jon

[0] Modulo use of features Mono doesn't implement.  See also MoMA:

http://www.mono-project.com/MoMA


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

Re: [Mono-dev] Adding documentation for new namespace

[Jonathan Pryor]

On Wed, 2010-06-30 at 14:58 +0100, Chris Bacon wrote:
 I would like to add some documentation for the 
 System.Diagnostics.Contracts namespace, for which there is currently no 
 documentation.
 
 I cannot see a way to add a new namespace using the Mono Documentation 
 Library. Please could someone let me know how best to do this.

cd mcs/class/corlib
# or some other assembly directory.
make PROFILE=net_4_0 doc-update
# generates doc stubs in Documentation/en
monodoc --edit Documentation/en
# view the 'Mono Documentation/mscorlib' node in the
# left-hand pane. [0]

You can then edit e.g.
mcs/class/corlib/Documentation/en/System.Diagnostics.Contracts/*.xml,
`svn add` your XML files and `svn commit` them.

I've just committed the doc stubs for mscorlib.dll v4.0, so your first
commit won't intermix stubs with content (and be gigantic); r159740.

To install the docs:

cd mcs/docs
rm netdocs{.tree,.zip}
make PROFILE=net_4_0
make PROFILE=net_4_0 install

The intermediate `rm` is needed to ensure that nedocs.zip is rebuilt, as
the make(1) dependencies for rebuilding are inadequate.

Once you've `make install`ed, monodoc will show the new documentation.

 - Jon

[0] I can't actually recommend 'monodoc --edit' for editing
documentation [1], but it is handy for viewing documentation without
assembling and installing it.

[1]
http://www.jprl.com/Blog/archive/development/mono/mdoc/2010/Jan-10.html


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

Re: [Mono-dev] Standard name for mcs

[Jonathan Pryor]

 There are efforts to make mcs a multi-target compiler (probably
 under a new name and with script wrappers for mcs, gmcs,
 smcs, dmcs), but even then you'll have to specify the target
 runtime version via a command like switch (or resort to the
 aforementioned wrappers).

This already exists via /nostdlib and /r:path/to/mscorlib.dll.

 - Jon

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

Re: [Mono-dev] Altering our build system.

[Jonathan Pryor]

On Thu, 2010-05-20 at 12:52 -0400, Miguel de Icaza wrote:
  I would like to move to a setup where by default we assume we have
 a working mcs/runtime and we build the configured profiles (defaulting
 to 2.0 and 4.0).
...
  A final wish-list item would be to split up the *core* libraries
 from most of the extra libraries.  The moonlight team is using a special
 process already to limit the number of assemblies built.

This would dovetail nicely with the idea of splitting up mcs into
smaller modules as part of the git migration; see:

http://www.mono-project.com/GitMigration

I would also suggest using xbuild to build the non-core libraries.  This
will make it easier for people who aren't using Unix to build the
libraries, as Visual Studio could then (hopefully) be used for building,
thus avoiding the pain that is Cygwin for everything except the runtime
and core libraries.

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [3/4]

[Jonathan Pryor]

On Tue, 2010-04-20 at 11:16 +0200, Paolo Molaro wrote:
 We must use feature checks and not platform checks as much as possible.

The changes you outlined were commited to trunk (r155826) and the
mono-2-6 branch (r155825).

Thanks,
 - Jon


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

[Mono-dev] [PATCH] Android Support [4/4]

[Jonathan Pryor]

This is a series of patches to add support to Mono for building against
the Android NDK [0].  Android runs the Linux kernel, but moves many
things around compared to a normal desktop Linux distro.

These patches are based against the mono-2-6 branch.

This fourth patch patches mono/support so that it will properly build
and link under Android, largely because many POSIX functions aren't
present under Android (hence the numerous configure checks):

* dirent.c, grp.c, macros.c, pwd.c, signal.c, sys-statvfs.c, sys-time.c,
  unistd.c: Add #if HAVE_XXX checks for functions which aren't
  provided on Android.

Permission to commit?

- Jon

[0] http://developer.android.com/sdk/ndk/index.html

Index: configure.in
===
--- configure.in	(revision 155735)
+++ configure.in	(working copy)
@@ -1564,6 +1564,7 @@
 	dnl *** Checks for MonoPosixHelper ***
 	dnl **
 	AC_CHECK_HEADERS(checklist.h)
+	AC_CHECK_HEADERS(pathconf.h)
 	AC_CHECK_HEADERS(fstab.h)
 	AC_CHECK_HEADERS(attr/xattr.h)
 	AC_CHECK_HEADERS(sys/extattr.h)
@@ -1575,13 +1576,15 @@
 	AC_CHECK_HEADERS(sys/mman.h)
 	AC_CHECK_HEADERS(sys/param.h)
 	AC_CHECK_HEADERS(sys/mount.h)
+	AC_CHECK_FUNCS(confstr)
+	AC_CHECK_FUNCS(seekdir telldir)
 	AC_CHECK_FUNCS(getdomainname)
 	AC_CHECK_FUNCS(setdomainname)
-	AC_CHECK_FUNCS(fgetgrent)
-	AC_CHECK_FUNCS(fgetpwent)
-	AC_CHECK_FUNCS(fgetpwent)
+	AC_CHECK_FUNCS(endgrent getgrent fgetgrent setgrent)
+	AC_CHECK_FUNCS(setgroups)
+	AC_CHECK_FUNCS(endpwent getpwent fgetpwent setpwent)
 	AC_CHECK_FUNCS(getfsstat)
-	AC_CHECK_FUNCS(lutimes)
+	AC_CHECK_FUNCS(lutimes futimes)
 	AC_CHECK_FUNCS(mremap)
 	AC_CHECK_FUNCS(remap_file_pages)
 	AC_CHECK_FUNCS(posix_fadvise)
@@ -1589,7 +1592,8 @@
 	AC_CHECK_FUNCS(posix_madvise)
 	AC_CHECK_FUNCS(vsnprintf)
 	AC_CHECK_FUNCS(sendfile)
-	AC_CHECK_FUNCS(sethostid)
+	AC_CHECK_FUNCS(gethostid sethostid)
+	AC_CHECK_FUNCS(sethostname)
 	AC_CHECK_FUNCS(statfs)
 	AC_CHECK_FUNCS(fstatfs)
 	AC_CHECK_FUNCS(statvfs)
@@ -1597,6 +1601,11 @@
 	AC_CHECK_FUNCS(stime)
 	AC_CHECK_FUNCS(strerror_r)
 	AC_CHECK_FUNCS(ttyname_r)
+	AC_CHECK_FUNCS(psignal)
+	AC_CHECK_FUNCS(getlogin_r)
+	AC_CHECK_FUNCS(lockf)
+	AC_CHECK_FUNCS(swab)
+	AC_CHECK_FUNCS(setusershell endusershell)
 	AC_CHECK_SIZEOF(size_t)
 	AC_CHECK_TYPES([blksize_t], [AC_DEFINE(HAVE_BLKSIZE_T)], , 
 		[#include sys/types.h
@@ -1632,6 +1641,14 @@
 		[struct dirent.d_off, struct dirent.d_reclen, struct dirent.d_type],,, 
 		[#include sys/types.h
 		 #include dirent.h])
+	AC_CHECK_MEMBERS(
+		[struct passwd.pw_gecos],,, 
+		[#include sys/types.h
+		 #include pwd.h])
+	AC_CHECK_MEMBERS(
+		[struct statfs.f_flags],,, 
+		[#include sys/types.h
+		 #include sys/vfs.h])
 
 	dnl Favour xattr through glibc, but use libattr if we have to
 	AC_CHECK_FUNC(lsetxattr, ,
Index: ChangeLog
===
--- ChangeLog	(revision 155735)
+++ ChangeLog	(working copy)
@@ -1,3 +1,13 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* configure.in: Use AC_CHECK_LIB() to check for pthread instead of
+	  just blindly linking to -lpthread, as Android includes pthread
+	  support within libc and doesn't provide a separate libpthread.
+	  Add header, structure member, and function checks as Android doesn't
+	  provide all the headers, structure members, and functions that a
+	  full Linux distro includes.  Android provides malloc.h, so check
+	  for it and define HAVE_USR_INCLUDE_MALLOC_H when present.
+
 2010-04-19  Zoltan Varga  var...@gmail.com
 
 	* configure.in: Add a --enable-minimal=normalization option to disable support
Index: support/dirent.c
===
--- support/dirent.c	(revision 155735)
+++ support/dirent.c	(working copy)
@@ -29,6 +29,7 @@
 
 G_BEGIN_DECLS
 
+#if HAVE_SEEKDIR
 gint32
 Mono_Posix_Syscall_seekdir (void *dir, mph_off_t offset)
 {
@@ -38,12 +39,15 @@
 
 	return 0;
 }
+#endif  /* def HAVE_SEEKDIR */
 
+#if HAVE_TELLDIR
 mph_off_t
 Mono_Posix_Syscall_telldir (void *dir)
 {
 	return telldir ((DIR*) dir);
 }
+#endif  /* def HAVE_TELLDIR */
 
 static void
 copy_dirent (struct Mono_Posix_Syscall__Dirent *to, struct dirent *from)
Index: support/grp.c
===
--- support/grp.c	(revision 155735)
+++ support/grp.c	(working copy)
@@ -226,6 +226,7 @@
 }
 #endif /* ndef HAVE_GETGRGID_R */
 
+#if HAVE_GETGRENT
 gint32
 Mono_Posix_Syscall_getgrent (struct Mono_Posix_Syscall__Group *grbuf)
 {
@@ -247,6 +248,7 @@
 	}
 	return 0;
 }
+#endif  /* def HAVE_GETGRENT */
 
 #ifdef HAVE_FGETGRENT
 gint32
@@ -272,13 +274,16 @@
 }
 #endif /* ndef HAVE_FGETGRENT */
 
+#if HAVE_SETGROUPS
 gint32
 Mono_Posix_Syscall_setgroups (mph_size_t size, mph_gid_t *list)
 {
 	mph_return_if_size_t_overflow (size);
 	return setgroups ((size_t) size, list);
 }
+#endif  /* def HAVE_SETGROUPS */
 
+#if HAVE_SETGRENT
 int

[Mono-dev] [PATCH] Android Support [1/4]

[Jonathan Pryor]

 */
 #define g_log_set_handler(a,b,c,d)
 /*
  * Conversions
Index: eglib/ChangeLog
===
--- eglib/ChangeLog	(revision 155735)
+++ eglib/ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* src/glib.h: Rebase g_return_if_fail(), g_return_val_if_fail() in
+	  terms of g_critical() instead of printf, and turn g_printerr() into
+	  an actual function instead of a macro.
+	* src/goutput.c: Add Android support, sending g_print(), g_printerr(),
+	  and g_log() messages to the Android system log.
+
 2009-12-03  Zoltan Varga  var...@gmail.com
 
 	* src/gmisc-unix.c (g_get_user_name): Avoid returning NULL if the env
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Android Support [2/4]

[Jonathan Pryor]

This is a series of patches to add support to Mono for building against
the Android NDK [0].  Android runs the Linux kernel, but moves many
things around compared to a normal desktop Linux distro.

These patches are based against the mono-2-6 branch.

This second patch patches libgc so that it will properly build and link
under Android.  In particular, note that Android includes pthread_*()
functions within libc, not libpthread, thus the added configure check.

* include/private/gcconfig.h: Android platforms are built atop Linux,
  don't use glibc, and uses `environ` instead of `__environ`.
* configure.in: Use AC_CHECK_LIB() to check for pthread instead of
  just blindly linking to -lpthread, as Android includes pthread
  support within libc and doesn't provide a separate libpthread.


Permission to commit?

- Jon

[0] http://developer.android.com/sdk/ndk/index.html

Index: libgc/include/private/gcconfig.h
===
--- libgc/include/private/gcconfig.h	(revision 155735)
+++ libgc/include/private/gcconfig.h	(working copy)
@@ -713,6 +713,9 @@
 #	 if defined(__GLIBC__) __GLIBC__=2
 #  define SEARCH_FOR_DATA_START
 #	 else /* !GLIBC2 */
+#  if defined(PLATFORM_ANDROID)
+#  define __environ environ
+#  endif
extern char **__environ;
 #  define DATASTART ((ptr_t)(__environ))
  /* hideous kludge: __environ is the first */
Index: libgc/configure.in
===
--- libgc/configure.in	(revision 155735)
+++ libgc/configure.in	(working copy)
@@ -84,7 +84,7 @@
 ;;
  posix | pthreads)
 THREADS=posix
-THREADDLLIBS=-lpthread
+AC_CHECK_LIB(pthread, pthread_self, THREADDLLIBS=-lpthread,,)
 case $host in
  x86-*-linux* | ia64-*-linux* | i386-*-linux* | i486-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* | alpha*-*-linux* | s390*-*-linux* | sparc*-*-linux* | powerpc-*-linux*)
 	AC_DEFINE(GC_LINUX_THREADS)
Index: libgc/ChangeLog
===
--- libgc/ChangeLog	(revision 155735)
+++ libgc/ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* include/private/gcconfig.h: Android platforms are built atop Linux,
+	  don't use glibc, and uses `environ` instead of `__environ`.
+	* configure.in: Use AC_CHECK_LIB() to check for pthread instead of
+	  just blindly linking to -lpthread, as Android includes pthread
+	  support within libc and doesn't provide a separate libpthread.
+
 2010-03-09  Zoltan Varga  var...@gmail.com
 
 	* include/private/gc_locks.h: Fix amd64 build with newer gcc's.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Android Support [3/4]

[Jonathan Pryor]

This is a series of patches to add support to Mono for building against
the Android NDK [0].  Android runs the Linux kernel, but moves many
things around compared to a normal desktop Linux distro.

These patches are based against the mono-2-6 branch.

This third patch patches mono so that it will properly build and link
under Android.  In particular, note that Android includes pthread_*()
functions within libc, not libpthread, thus the added configure check.
ChangeLog messages are within the diff.

Permission to commit?

- Jon

[0] http://developer.android.com/sdk/ndk/index.html

Index: mono/io-layer/collection.c
===
--- mono/io-layer/collection.c	(revision 155735)
+++ mono/io-layer/collection.c	(working copy)
@@ -58,7 +58,10 @@
 ret = pthread_attr_init (attr);
 g_assert (ret == 0);
 
-#ifdef HAVE_PTHREAD_ATTR_SETSTACKSIZE
+/* Android implements pthread_attr_setstacksize(), but errors out when using
+ * PTHREAD_STACK_MIN: http://code.google.com/p/android/issues/detail?id=7808
+ */
+#if defined(HAVE_PTHREAD_ATTR_SETSTACKSIZE)  !defined(PLATFORM_ANDROID)
 if (set_stacksize == 0) {
 #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
 			ret = pthread_attr_setstacksize (attr, 65536);
Index: mono/io-layer/ChangeLog
===
--- mono/io-layer/ChangeLog	(revision 155735)
+++ mono/io-layer/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* collection.c, mono-mutex.c: Add Android support.
+
 2010-04-14  Zoltan Varga  var...@gmail.com
 
 	* collection.c (_wapi_collection_init): Set stack size on openbsd similarly to
Index: mono/io-layer/mono-mutex.c
===
--- mono/io-layer/mono-mutex.c	(revision 155735)
+++ mono/io-layer/mono-mutex.c	(working copy)
@@ -22,11 +22,24 @@
 
 
 #ifndef HAVE_PTHREAD_MUTEX_TIMEDLOCK
+/* Android does not implement pthread_mutex_timedlock(), but does provide an
+ * unusual declaration: http://code.google.com/p/android/issues/detail?id=7807
+ */
+#if defined(PLATFORM_ANDROID)
 int pthread_mutex_timedlock (pthread_mutex_t *mutex,
+			struct timespec *timeout);
+#else
+int pthread_mutex_timedlock (pthread_mutex_t *mutex,
 			const struct timespec *timeout);
+#endif
 
+#if defined(PLATFORM_ANDROID)
 int
+pthread_mutex_timedlock (pthread_mutex_t *mutex, struct timespec *timeout)
+#else
+int
 pthread_mutex_timedlock (pthread_mutex_t *mutex, const struct timespec *timeout)
+#endif
 {
 	struct timeval timenow;
 	struct timespec sleepytime;
Index: mono/mini/exceptions-arm.c
===
--- mono/mini/exceptions-arm.c	(revision 155735)
+++ mono/mini/exceptions-arm.c	(working copy)
@@ -12,7 +12,11 @@
 #include glib.h
 #include signal.h
 #include string.h
+#if defined(PLATFORM_ANDROID)
+#include asm/sigcontext.h
+#else
 #include ucontext.h
+#endif
 
 #include mono/arch/arm/arm-codegen.h
 #include mono/metadata/appdomain.h
Index: mono/mini/ChangeLog
===
--- mono/mini/ChangeLog	(revision 155735)
+++ mono/mini/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* exceptions-arm.c: Add Android support for sigcontext structure.
+
 2010-04-16  Zoltan Varga  var...@gmail.com
 
 	* mini.c (mono_jit_compile_method_inner): Avoid calling
Index: configure.in
===
--- configure.in	(revision 155735)
+++ configure.in	(working copy)
@@ -169,7 +169,7 @@
 			CPPFLAGS=$CPPFLAGS -DUSE_MUNMAP
 		fi
 		libmono_cflags=-D_REENTRANT
-		libmono_ldflags=-lpthread
+		AC_CHECK_LIB(pthread, pthread_self, libmono_ldflags=-lpthread,,)
 		libdl=-ldl
 		libgc_threads=pthreads
 		AOT_SUPPORTED=yes
@@ -2399,6 +2416,10 @@
 	fi
 ], [with_moonlight=no])
 
+AC_CHECK_HEADER([malloc.h], 
+		[AC_DEFINE([HAVE_USR_INCLUDE_MALLOC_H], [1], 
+			[Define to 1 if you have /usr/include/malloc.h.])],,)
+
 dnl
 dnl Consistency settings
 dnl
Index: ChangeLog
===
--- ChangeLog	(revision 155735)
+++ ChangeLog	(working copy)
@@ -1,3 +1,13 @@
+2010-04-19  Jonathan Pryor  jpr...@novell.com
+
+	* configure.in: Use AC_CHECK_LIB() to check for pthread instead of
+	  just blindly linking to -lpthread, as Android includes pthread
+	  support within libc and doesn't provide a separate libpthread.
+	  Add header, structure member, and function checks as Android doesn't
+	  provide all the headers, structure members, and functions that a
+	  full Linux distro includes.  Android provides malloc.h, so check
+	  for it and define HAVE_USR_INCLUDE_MALLOC_H when present.
+
 2010-04-19  Zoltan Varga  var...@gmail.com
 
 	* configure.in: Add a --enable-minimal=normalization option to disable support

Re: [Mono-dev] [PATCH] Android Support [1/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 15:15 -0300, Rodrigo Kumpera wrote:
 +static void 
 +out_vfprintf (FILE *ignore, const gchar *format, va_list args)
 +{
 + __android_log_vprint (ANDROID_LOG_ERROR, mono, format, args);
 +}
 
 Shouldn't we identify the entry by the application name instead of
 mono?

In an ideal world, yes, but I'm not sure how to do that.  I suppose
using g_get_application_name() would be THE way, except that Mono
doesn't currently call g_set_application_name() (and eglib doesn't
implement either), so that would appear to be a more invasive change for
the mono-2-6 branch.

Is there some other way to obtain this information?

Thanks,
 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [4/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 13:53 -0400, Joe Dluzen wrote:
 How do these compare with Koush's: http://github.com/koush/androidmono
 ? Are they a complete reimplementation?

No, it's a different take.  Koush's implementation, as I understand it,
uses the Android build system to build Mono.  This instead uses Mono's
existing build system (autotools) to target Android; it's an inversion.

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [2/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 15:17 -0300, Rodrigo Kumpera wrote:
 Looks good.

Thanks.  Committed to mono-2-6 (r155746) and trunk (r155747).

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [3/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 15:22 -0300, Rodrigo Kumpera wrote:
 On Mon, Apr 19, 2010 at 2:44 PM, Jonathan Pryor jonpr...@vt.edu
 wrote:

 +AC_CHECK_HEADER([malloc.h], 
 + [AC_DEFINE([HAVE_USR_INCLUDE_MALLOC_H], [1], 
 + [Define to 1 if you have /usr/include/malloc.h.])],,)
 +

 What's the use for this? We check the header but then we don't use the
 new define.

That's because it's an old define, used in mono/utils/dlmalloc.c and
mono/utils/dlmalloc.h.  I don't know why our configure doesn't set it,
but without this check compiling under the Android NDK results in a
build failure [0].

The primary issue appears to be system header files.  mono-codeman.c
#includes string.h.  Under glibc, string.h only #includes
features.h and stddef.h.

Under Android, however, string.h #includes malloc.h as well, and
malloc.h includes a definition for `struct mallinfo`, and since
mono-codeman.c also #includes dlmalloc.h this results in a duplicate
definition for `struct mallinfo`.

Different system headers, different results.

This also implies that my patch, as is, won't work under desktop Linux
(oops).  Specifically, mono-codeman.c needs to #include malloc.h
before #including dlmalloc.h.

Advice?

 - Jon

[0] In file included from mono-codeman.c:16:dlmalloc.h: At top level:
dlmalloc.h:195: error: redefinition of 'struct mallinfo'


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

Re: [Mono-dev] [PATCH] Android Support [3/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 15:31 -0400, Jonathan Pryor wrote:
 This also implies that my patch, as is, won't work under desktop Linux
 (oops).  Specifically, mono-codeman.c needs to #include malloc.h
 before #including dlmalloc.h.

Never mind; tried the patch as-is, and it builds properly on trunk
(largely because mono-codeman.c doesn't use `struct mallinfo`, so it's
not actually an issue here).

The previous patch, as is, works under desktop Linux.

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [4/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 15:24 -0300, Rodrigo Kumpera wrote

 Looks good.

Thanks.  Committed to mono-2-6 (r155752) and trunk (r155753).

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [3/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 17:16 -0300, Rodrigo Kumpera wrote:
 Looks good to me then. 

Thanks.  Committed to mono-2-6 (r155758) and trunk (r155758).

 - Jon


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

Re: [Mono-dev] [PATCH] Android Support [1/4]

[Jonathan Pryor]

On Mon, 2010-04-19 at 14:26 -0400, Jonathan Pryor wrote:
 On Mon, 2010-04-19 at 15:15 -0300, Rodrigo Kumpera wrote:
  +static void 
  +out_vfprintf (FILE *ignore, const gchar *format, va_list args)
  +{
  + __android_log_vprint (ANDROID_LOG_ERROR, mono, format, args);
  +}
  
  Shouldn't we identify the entry by the application name instead of
  mono?
 
 In an ideal world, yes, but I'm not sure how to do that.  I suppose
 using g_get_application_name() would be THE way, except that Mono
 doesn't currently call g_set_application_name() (and eglib doesn't
 implement either), so that would appear to be a more invasive change for
 the mono-2-6 branch.

Added a TODO comment noting that a better name should be used.

Committed to mono-2-6 (r155762) and trunk (r155763).

Thanks!
 - Jon


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

[Mono-dev] Announcing DbLinq 0.20.1

[Jonathan Pryor]

The DbLinq[0] team is proud to announce the release of DbLinq 0.20.1,
following the DbLinq 0.20 release from last week.

DbLinq is a reimplementation of System.Data.Linq.dll for use with SQL
servers in addition to Microsoft SQL Server.  Support is provided for:

  * Firebird [1]
  * Ingres [2]
  * MySQL [3]
  * Oracle [4]
  * PostgreSQL [5]
  * SQLite [6]
  * SQL Server [7]

Note that not all servers are supported equally: some tests will pass
under some database backends while failing under others.  I maintain the
SQLite and SQL Server backends, while the community handles the others.

This is a minor update to address some DBML validation deficiencies
found in the 0.20 release.  Fixes include [8]:

  * 233: Fix IOE in Processor.ValidateAssociations()
  * 234: Fix NRE when looking up DataContext base class name.
  * 235: Support Association/s with empty @Storage and @Member.
  * 237: Empty //Table/@Name strings are not valid table names.

Enjoy!

 - Jon

[0] http://code.google.com/p/dblinq2007/
[1] http://www.firebirdsql.org/
[2] http://www.ingres.com/
[3] http://www.mysql.com/
[4] http://www.oracle.com/
[5] http://www.postgresql.org/
[6] http://www.sqlite.org/
[7] http://www.microsoft.com/sqlserver/
[8] http://code.google.com/p/dblinq2007/issues/list

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

[Mono-dev] Announcing DbLinq 0.20

[Jonathan Pryor]

The DbLinq[0] team is proud to announce the release of DbLinq 0.20,
following the venerable DbLinq 0.19 release from December 2009.

DbLinq is a reimplementation of System.Data.Linq.dll for use with SQL
servers in addition to Microsoft SQL Server.  Support is provided for:

  * Firebird [1]
  * Ingres [2]
  * MySQL [3]
  * Oracle [4]
  * PostgreSQL [5]
  * SQLite [6]
  * SQL Server [7]

Note that not all servers are supported equally: some tests will pass
under some database backends while failing under others.  I maintain the
SQLite and SQL Server backends, while the community handles the others.

My focus for this release has been on fixing DbMetal and sqlmetal
issues.  In particular, sqlmetal can now generate .dbml files.
Additionally, the CodeDom generator now works, allowing you to generate
Visual Basic .NET sources, and the older CodeText generator has been
deprecated (and is available via `/language:obsolete-c#`).  It will be
removed in the next release.

A horrifically unreadable list of issues fixed is at the end. [8]

Enjoy!

 - Jon

[0] http://code.google.com/p/dblinq2007/
[1] http://www.firebirdsql.org/
[2] http://www.ingres.com/
[3] http://www.mysql.com/
[4] http://www.oracle.com/
[5] http://www.postgresql.org/
[6] http://www.sqlite.org/
[7] http://www.microsoft.com/sqlserver/
[8] Part of the length of this is that all inactive and unresponsive
bugs were closed so that currently relevant bugs would actually be
visible at http://code.google.com/p/dblinq2007/issues/list
   7
Add
MySQL 4.0 support











   9
pgsqlmetal generates invalid DbType attribute for integer








  34
pgsqlmetal primary key constraint










  45
sqlmetal should generate table names without schemas








  60
DbType attribute does not contain some clauses







  67
FirstOrDefault return error











  71
DbMetal  Oracle: Tables aren't loaded










  73
DynamicQueryOrderBy











  77
DataMembers property not implemented










  78
DbLinq.Pgsql.Example.csproj contains bad project reference







  79
contains could not parse correctly to like









  80
left
column should be quoted











  82
Possibility to have all generated classes in lowercase







  83
DbLinq.Linq.DataContext' missing a constructor






  86
read
blob
from
mysql?











  88
MySql dbtype TimeStamp isn't supported by DbLinq.








  90
Referenced tables more than 1 times










  93
Some
LINQ
expressions  an error - no such column True






  94
Unable to read inherited types using DBLinq to Sqlite









  96
NRE
in
QueryBuilder.Upsert.cs: GetUpsertParameters method


  98
Does
dbLinq support EntitySet?










 101
Error saving password











 106
NullReferenceException during insert










 107
DbMetal leaves types blank for fields generating bad code






 108
DBMetal describes an unsigned integer as a signed integer







 109
MySql 5 varbinary columns are undeceted










 116
Unsupported types in Pgsql











 117
Problems in VisualMetal generated file with Pgsql









 118
DBLinq_test build fails due to missing AssemblyInfo.cs








 119
System.Data.Linq missing assembly reference






 120
ORA-02291:integrity constraint violated - parent key not found





 123
dbmetar error with firebird sample










 124
BulkInsert SqlServer fails for nullable










 125
Bug
in
association creation 






 126
Problem in SubmitChanges() in Linux










 127
Multiple associations from the same table to the same table 






 128
Invalid column '{0}' bad error











 129
No
support for aggregate functions with lambdas









 130
Delegate compilation error for types with nullable properties 





 131
An
error has occurred with TableT.Max if table no record








 134
Exception whith sqlite foreign key










 137
Bug
requesting uuid












 138
Trying to iterate through MySQL view throws an exception.








 140
While running dbmetal in VS 2008 i got the Following Error








 141
mediumtext MySql datatype not supported










 142
Joins for more than 3 tables











 143
DbMetal doesn't generate datatypes for sqlite FTS3 tables








 145
mysql: unsigned float problem











 148
LambdaMetaAccessor missing in DbLinq project







 150
Unable to update table: SQLite error no such column: true








 152
Cannot update record if primary key of table is uuid









 154
DbMetal can not create the class file for Oracle 10g







 155
Type
ommitted for timestamp with time zone column








 160
Duplicate methods generated for some overloaded functions







 161
Lambda Parameter not in scope error when calling a function






 164
GetBooleanAttribute should also return true for True









 165
northwind for mysql












 170
Can't use DbMetal with port numbers










 171
SqlMetal can't generate DBML files










 172
ria
services












 173
DbMetal generates method names with 

Re: [Mono-dev] [PATCH] Don't rely on SIGIO

[Jonathan Pryor]

On Sun, 2010-03-21 at 23:44 +0100, Andreas Färber wrote:
 SIGIO is not part of POSIX, Haiku does not support it.

You might want to mention that fact in the ChangeLog, otherwise we'll
need to care why SIGIO is special but not SIGWINCH (which according to
signal(7) is from 4.3BSDand Sun).

Otherwise, the patch looks OK.  Please commit.

 - Jon


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

Re: [Mono-dev] Can't build svn head on Linux/x86

[Jonathan Pryor]

On Tue, 2010-03-16 at 10:31 +0100, Thierry Lafage wrote:
 I've followed what is written on the website and in the README in mono
 to build mono from svn (head of trunk), and the build process fails on
 my Linux/x86 box (see trace below).
...
 $ make
 [...]
 make[7]: Entering directory
 `/udd/lafage/Mono/SVN/trunk/mcs/docs'
 MDOC[net_4_0] cs-errors.tree
 
 ** (./../tools/mdoc/mdoc.exe:21186): WARNING **: The following
 assembly referenced
 from /udd/lafage/Mono/SVN/trunk/mcs/tools/mdoc/mdoc.exe could
 not be loaded:
  Assembly:   monodoc(assemblyref_index=3)
  Version:1.0.0.0
  Public Key: 0738eb9f132ed756

This is (hopefully) fixed in r153683.

 - Jon


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

[Mono-dev] Removing Mono.GetOptions dependency from svcutil

[Jonathan Pryor]

As per the Removing Obsolete Code from Mono 2.8 thread, I've removed
Mono.GetOptions.dll use from mcs/tools/svcutil, migrating it to use
Mono.Options instead.  These are in r153039.

However, I'm unable to fully test these changes, as providing .wsdl or
assemblies on the command line result in no files being generated (even
without my changes).  Consequently, I'm unable to do any sanity
checking to ensure that it actually works.

Could you please test svcutil to make sure I didn't break anything?

Thanks,
 - Jon


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