Re: [Mono-list] .so file not found in /usr/lib

[Jonathan Pryor]

On Jul 4, 2016, at 7:24 PM, Daniel Hughes  wrote:
> I have a library that I am trying to pinvoke to (libsword.so) that is located 
> in /usr/lib
> 
> This page: http://www.mono-project.com/docs/advanced/pinvoke/
> tells me that /usr/lib is on the search path.
> 
> However when I run my app I get a DllNotFoundException
> 
> If I run with: MONO_LOG_LEVEL=debug mono CSSword.Tests.exe
> 
> Then I get the following in the output:
> 
> Mono: DllImport error loading library 'libsword.so’: 'libicui18n.so.48: 
> cannot open shared object file: No such file or directory’.

`libsword.so` depends on `libicuil18n.so.48`, and `libicuil18n.so.48` can’t be 
found.

 - Jon

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

Re: [Mono-list] (no subject)

[Jonathan Pryor]

On Apr 27, 2016, at 2:53 PM, Sharmad Naik  wrote:
> I have now another system where I have copied the service application build 
> and running earlier and some of the binaries like mono-service, mono, 
> libMonoPosixHelper.so, mono-service.exe, Mono.Posix.dll and mscorlib.dll and 
> set the MONO_PATH variable to the location of the folder
> 
> On executing the service application using the following command 
>  mono-service --debug Service1App.exe 
> I get an error 
> UnhandledException:
> System.DllNotFoundException: msvcrt

I think you need to copy over $prefix/etc/mono/config as well, because you’re 
apparently missing the DLL mapping from msvcrt to libc:

 
 

 - Jon

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

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-list] Missing Unix inside of Mono

[Jonathan Pryor]

On May 20, 2015, at 5:08 AM, Baltasar García Perez-Schofield 
baltas...@gmail.com wrote:
 $ sudo apt-get install Pinta
...
 The following packages have unmet dependencies:
  pinta : Depends: libmono-posix2.0-cil (= 3.2.3) but it is not going to be 
 installed
 E: Unable to correct problems, you have held broken packages.
 ===
 
 Okay, so I downloaded the tarball from their web and tried to install from 
 source. However, it complains about missing namespace Unix inside of Mono 
 (23 errors). What Xamarin packages am I missing?

You need Mono.Posix.dll, which presumably would be provided by 
libmono-posix2.0-cil, if it could be installed, which it can’t.

I don’t know why apt-get won’t install it. :-(

 - Jon

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

Re: [Mono-list] Anyone else missing reply-to?

[Jonathan Pryor]

On May 12, 2015, at 2:43 PM, Maury Markowitz maury.markow...@gmail.com wrote:
 Well my mailer does that, and it’s precisely the wrong behaviour IMHO. 
 Maintaining readable threads requires posts to go back to the group, and if 
 they’re doing that, what’s the purpose of sending it directly to the poster 
 who’s going to get a copy anyway?

1. Sometimes you actually want to reply privately. Munging the Reply-To header 
makes this more difficult.

2. Redundancy. Sometimes the mail server is down or slow. Getting two messages 
is thus an advantage if you’re waiting for a response, as you’re not waiting on 
any delays in the listserv software.

3. Filtering and convention: it’s common practice that if you’re in the “To” 
header, the message is directed at you specifically, and thus a response may be 
warranted from you specifically, while if you’re in the “Cc” header, you don’t 
necessarily need to reply (it’s informative).

 - Jon

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

Re: [Mono-list] System.IO.Compression

[Jonathan Pryor]

On May 8, 2015, at 10:19 AM, Baltasar García Perez-Schofield 
baltas...@gmail.com wrote:
 Are there any plans to implement System.IO.Compression? Or maybe that now the 
 library is open-sourced, will it be added to mono any time soon?

Which types?

DeflateStream has been present since at least Mono 1.2:


https://github.com/mono/mono/tree/mono-1-2/mcs/class/System/System.IO.Compression

ZipArchive and ZipFile have been present since at least Mono 3.2.0:


https://github.com/mono/mono/tree/mono-3.2.0-branch/mcs/class/System.IO.Compression

https://github.com/mono/mono/tree/mono-3.2.0-branch/mcs/class/System.IO.Compression.FileSystem

 - Jon

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

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

[Jonathan Pryor]

On Jan 29, 2015, at 3:33 AM, Alex J Lennon ajlen...@dynamicdevices.co.uk 
wrote:
 Can anybody advise if this is an implementational issue or if I'm doing 
 something wrong here?

You're doing something wrong, *and* there's an implementation issue.

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

The C# compiler has a /platform:PLATFORM flag to specify the target platform:

mcs /platform:x86 myapp.cs

This sets a flag in the PE header, and Module.GetPEKind() extracts this 
information. For example, build with /platform:arm, and Module.GetPEKind() will 
return ImageFileMachine.ARM *for that assembly*.

.NET checks this PE header value during process startup. For example, if you 
compile with /platform:anycpu, your app may run as a 32-bit process on 32-bit 
windows, and as a 64-bit process on 64-bit windows. If you need to run as a 
32-bit process on 64-bit windows (e.g. because a dependent .dll you use is only 
32-bit), then you must build your app with /platform:x86 to force .NET to run 
your app as a 32-bit process on 64-bit windows.

Mono ignores this PE header value. In the case of 32-bit vs. 64-bit processes, 
you must use an appropriately built mono (e.g. mono32 for a 32-bit mono) in 
order to get an appropriate bitness. (It's also entirely possible that there is 
no option; at present on OS X, the Mono package only provides a 32-bit runtime, 
though you can build a 64-bit runtime yourself.)

Offhand, short of using uname(3)/Mono.Unix.Native.Syscall.uname(), I'm not sure 
of a good way to determine the processor architecture.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Debug.Assert - a cross-platform issue

[Jonathan Pryor]

On Nov 21, 2014, at 7:25 PM, MarLOne infoseeker...@gmail.com wrote:
 It will be good if these classes and assemblies from Microsoft open-sources 
 are incorporated verbatim into Mono to replace its inconsistent code.

This will not be possible, for (at least) three reasons:

1. That code is also shared by Xamarin.Android, Xamarin.iOS, and Xamarin.Mac, 
all of which lack System.Configuration.dll, and the .NET DefaultTraceListener 
relies upon System.Configuration (via DiagnosticsConfiguration).

2. There are several CAS demands, which don't make sense on Mono.

3. The default code to write messages is useless outside of Windows, as no 
other platform has OutputDebugString():


https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs#L182-191

This doesn't mean that the .NET source can't be taken *and modified* for use 
off Windows, but it can't be used as-is.

 I have to thank Microsoft to open-source the .Net library allowing me to read 
 ...  default values for the System.Diagnostics.DefaultTraceListener.
 The default value of property that determines the reaction of Debug.Assert is 
 set here:  assertuienabled

The hilarious thing is that AssertUiEnabled does not alone control actual 
runtime behavior!


https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs#L105-107

The behavior of DefaultTraceListener.Fail() depends on *both* 
DefaultTraceListener.AssertUiEnabled *and* DefaultTraceListener.UiPermission, 
which is a private property that demands the UIPermissionWindow.SafeSubWindows 
CAS permission:

try {
new 
UIPermission(UIPermissionWindow.SafeSubWindows).Demand();
return true;
}
catch {
return false;
}

This explains how they can sanely have a non-GUI Windows service use 
Debug.Assert() and have it not hang when there's no Window Station: just have 
the startup code set security permissions which denies 
UIPermissionWindow.SafeSubWindows...

This doesn't at all answer how things should work off Windows. You can 
reasonably argue that DefaultTraceListener.AssertUiEnabled should default to 
`true` off Windows, even if/when a GUI is never shown, because 
DefaultTraceListener.AssertUiEnabled is in fact meaningless (it's not the sole 
control over whether a GUI is shown).

Which really means the docs are misleading. :-)


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

It's entirely possible, as we can now see, for user interface mode to be 
enabled, yet still not actually display a GUI when Fail() is invoked. This 
possibility is not noted at all in the documentation, afaict.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Cross-Platform GUI Tookit

[Jonathan Pryor]

On Nov 17, 2014, at 10:55 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:
 The fact that XS/MD is or was based on Xwt is a good sign

based on might be a bit strong. It *uses* Xwt.

Most of the current Xamarin Studio/MonoDevelop code is based on Gtk#. *Parts* 
were done in Xwt so that those parts could use the platform-native UI and share 
code with Visual Studio (e.g. File  Open, the Android designer), but most was 
written in, and continues to be in, Gtk#.

 - Jon

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

Re: [Mono-list] Cross-Platform GUI Tookit

[Jonathan Pryor]

On Nov 18, 2014, at 3:33 PM, Daniel Hughes tramps...@gmail.com wrote:
 Jonathan can you comment on Xamarins plans

I can't comment on any plans for the IDEs (or anything else that isn't related 
to Xamarin.Android), as I don't work on them. I have no idea what they plan on 
doing.

 - Jon

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

Re: [Mono-list] libMonoPosixHelper.dylib?

[Jonathan Pryor]

On Nov 5, 2014, at 9:15 AM, Maury Markowitz maury.markow...@gmail.com wrote:
 The OSX code I'm using will need to reference MonoPosixHelper.

Why do you need to reference libMonoPosixHelper.dylib? It has NO STABLE ABI; it 
is intended for use only from Mono.Posix.dll.

 However, I cannot find this libMonoPosixHelper.dylib anywhere.

$ find /Library/Frameworks/Mono.framework/Libraries/ -name 
libMonoPosixHelper.dylib
/Library/Frameworks/Mono.framework/Libraries//libMonoPosixHelper.dylib

/Library/Frameworks/Mono.framework/Libraries//libMonoPosixHelper.dylib.dSYM/Contents/Resources/DWARF/libMonoPosixHelper.dylib

 - Jon

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

Re: [Mono-list] libMonoPosixHelper.dylib?

[Jonathan Pryor]

On Nov 5, 2014, at 11:19 AM, Maury Markowitz maury.markow...@gmail.com wrote:
 unzOpen2 is part of miniunzip, itself part of zlib. The zlib code appears to 
 be in the MPH project essentially/completely unchanged. Of course I also have 
 libz in /usr/lib on every device I'm targeting.

libMonoPosixHelper.dylib has a copy of minzip for use in 
System.IO.Packaging/etc.

 *** What are you doing, man?! ***
 
 Is WindowsBase available in a OSX version? Or just System.IO.Packaging? It 
 does not appear to be, which is what started me down this rabbit hole.

The System.IO.Packaging namespace is in WindowsBase.dll:


http://msdn.microsoft.com/en-us/library/system.io.packaging.package(v=vs.110).aspx
 Assembly:  WindowsBase (in WindowsBase.dll)

WindowsBase.dll, in turn, is installed:

$ find /Library/Frameworks/Mono.framework/Libraries/ -name 
WindowsBase.dll
/Library/Frameworks/Mono.framework/Libraries//mono/2.0/WindowsBase.dll
/Library/Frameworks/Mono.framework/Libraries//mono/4.0/WindowsBase.dll
/Library/Frameworks/Mono.framework/Libraries//mono/4.5/WindowsBase.dll

/Library/Frameworks/Mono.framework/Libraries//mono/gac/WindowsBase/3.0.0.0__31bf3856ad364e35/WindowsBase.dll

/Library/Frameworks/Mono.framework/Libraries//mono/gac/WindowsBase/4.0.0.0__31bf3856ad364e35/WindowsBase.dll

Using the assembly Works For Me™:

$ csharp -r:WindowsBase.dll
csharp using System.IO.Packaging;
csharp Package p = null;

OK, not a great example, but it shows that the assembly, namespace, and type 
were found by the compiler...

 *** It just works! ***
 
 If this call should normally just work, then perhaps the path is screwed up 
 and it can't find it. How would I test this possibility?

What would be helpful is if you provided your sample code and the corresponding 
error message. AFAIK, Mono should be able to find libMonoPosixHelper.dylib, so 
I don't understand the error you're seeing.

 - Jon

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

Re: [Mono-list] Consts.cs vs. Consts.cs.in

[Jonathan Pryor]

On Oct 16, 2014, at 12:54 PM, Maury Markowitz maury.markow...@gmail.com wrote:
 1) Almost all of the projects refer to /System/Consts.cs. I do not have such 
 a file, but I do have Consts.cs.in, which looks a lot like a cs file. I am 
 unfamiliar with .in - is this supposed to be converted into a .cs by 
 someone/thing, or is this simply the .cs with some extra crud at the end of 
 the name?

A `.in` file is an input file, often processed by sed, to replace various 
strings within the file.

In the case of Consts.cs.in, the string to be replaced is @MONO_VERSION@, which 
is done by mono/mcs/build/Makefile [0]

common/Consts.cs: common/Consts.cs.in $(wildcard config.make)
test -n '$(MONO_VERSION)'
sed -e 's,@''MONO_VERSION@,$(MONO_VERSION),' $  $@

 - Jon

[0]: 
https://github.com/mono/mono/blob/6edd8bf89e0e30a08d0ba0a5391a796d94f61abc/mcs/build/Makefile#L13



___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Java Convert to C#

[Jonathan Pryor]

On Sep 12, 2014, at 3:40 AM, mutasim d_muta...@hotmail.com wrote:
 the difference between Java and C# is the native code

That's...one way to think of it, certainly.

That's also an oversimplification: before you even get to native code, your 
compiler needs to emit *something*, and that something needs to support your 
desired semantics.

CIL and a set of custom attributes can support the necessary Java semantics, 
*except* for interface versioning. (At least, the last time I tried covariant 
return types in CIL it appeared to work... Java interfaces allow adding methods 
with impunity w/o invalidating existing compiled implementations. CIL doesn't 
permit that.)

C#, on the other hand, does *not* support all Java semantics, nor can it easily 
be made to support them. (I've pondered a lot about how to sanely do covariant 
return types in C#. It's not easy.)

Since your very premise consists of converting Java code into C# code, this 
requires that you get all of the semantic issues nailed down first, OR that you 
fork the C# language and add the missing Java-oriented semantics to C#. (This 
would be an interesting project, but it would no longer be C#.)

 if the native code been programmed and add to the mono CLI that will handle 
 all the problems , i think , all the codes will return back to C or C++ and 
 then to the low level

Mono, at present, consumes CIL. Consequently, you either need to emit CIL -- 
assuming CIL can represent your required semantics -- or you need to extend 
mono to consume some alternate serialization format that supports your desired 
semantics.

As stated elsewhere in this thread, the easiest answer is to use IKVM to 
execute your Java bytecode atop Mono. IKVM handles the responsibility of 
properly representing Java bytecode semantics atop CIL.

 - Jon

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

Re: [Mono-list] Java Convert to C#

[Jonathan Pryor]

On Sep 11, 2014, at 9:50 AM, mutasim d_muta...@hotmail.com wrote:
 i convert java code to C# but there is a lot of error the code is connected 
 to C directly the file that been converted : openjdk-7-fcs-src-b147-27 jun 
 2011

Just offhand...are you aware of the semantic differences between Java and C#, 
particularly when it comes to generics? Porting Java to C# will be an 
interesting exercise, and I can see from the generated code that it's not 
going to work:

// from Java/java/lang/Class.cs:
public static Class? forName(string name, bool initialize, 
ClassLoader loader)

`Class?` is perfectly fine for Java, but (1) is not valid C#, and (2) has no 
real equivalent in C# either. The underpinnings of Java type erasure compared 
to C#'s reified generics are just completely different. Squaring this circle 
will be a fun exercise.

Then there's covariant return types (used in java.lang.Appendable  
java.lang.AbstractStringBuilder), name resolution and overloading differences...

 why some of the programs in mono back to java , in java is powerful language, 
 and also you can program java with the C# if the java is CLI

I'm not sure what to make of this either.

Running Mono programs on Java will be a difficult exercise for a variety of 
reasons, including differences in generics, but also in Platform Invoke, GC 
heap pinning, and more.

Running Java programs atop Mono can already be done without porting the Java 
code to C#; that's what IKVM is for. IKVM also allows Java code to interact 
with C# code.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Microsoft open sources the roslyn compiler under the Apache 2.0 License

[Jonathan Pryor]

On Apr 3, 2014, at 4:21 PM, Justin Dearing zippy1...@gmail.com wrote:

 https://roslyn.codeplex.com/
 
 Are there any plans to port rosyln to mono?

Miguel demo'd Roslyn running atop Mono/OS X at //build yesterday. I don't think 
it will be too difficult to port.

 Also, since this is apache 2.0 licensed, whats the policy on contributing 
 code from it to Mono itself? Does contributing to mono require copyright 
 assignment?

I _suspect_ -- but do not _know_ -- that Roslyn will _not_ be part of the Mono 
git repo. (Why should it be? It can remain an independent repo, just as e.g. 
cecil, ikvm, and rx are.)

Contributions to Mono _itself_ will require copyright assignment, but I rather 
doubt that contributions to Roslyn will be considered as contributions to 
mono.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Failing dlopen on Linux via DllImport with error message 'dlopen: invalid caller'

[Jonathan Pryor]

On Nov 25, 2013, at 5:47 PM, jean-michel.perr...@csiro.au wrote:
  [DllImport(libdl)]
  [return: MarshalAs(UnmanagedType.LPStr)]
  private static extern string dlerror();

You should (almost?) never use `string` (or any other reference type) as the 
return type in a P/Invoke method:


http://mono-project.com/DllImport#Classes_and_Structures_as_Return_Values
 The CLI assumes that all memory that is passed between the CLI/unmanaged code 
 boundary is allocated via a common memory allocator. The developer does not 
 get a choice in which memory allocator is used. For managed code, the 
 Marshal.AllocCoTaskMem method can be used to allocate memory, 
 Marshal.FreeCoTaskMem is used to free the memory allocated by 
 Marshal.AllocCoTaskMem, andMarshal.ReAllocCoTaskMem is used to resize a 
 memory region originally allocated by Marshal.AllocCoTaskMem.
 
 Since classes are passed by reference, a pointer is returned, and the runtime 
 assumes that it must free this memory to avoid a memory leak.

You should instead use IntPtr as the return type, then use 
Marshal.PtrToStringAnsi() to convert the IntPtr into a string.

 - Jon

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

Re: [Mono-list] self signed certificate

[Jonathan Pryor]

On Oct 24, 2013, at 6:02 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:
 All the guides out there that I can find tell people to use makecert, which 
 isn't an option.  Or use openssl.

Why aren't those options? It shouldn't matter how you create the cert, as long 
as you have one...

...except that the normal System.Net stack wants a valid certificate chain 
lest it start throwing exceptions, and it'll start throwing exceptions with 
your self-signed cert.

The workaround for this is to set the 
System.Net.ServicePointManager.ServerCertificateValidationCallback property [0, 
1] to a delegate which will check that the certificate you're getting from the 
server matches what your app expects. If it does, it can return `true` and the 
certificate will be used anyway, allowing you to use a self-signed cert. If the 
delegate returns `false`, the connection will be refused, as normal.

 - Jon

[0]: 
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.servercertificatevalidationcallback.aspx
[1]: 
http://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback.aspx

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Why Mono developers merged System.ServiceModel.Activation.dll to System.ServiceModel.dll?

[Jonathan Pryor]

On Sep 8, 2013, at 3:43 AM, mauzik mau...@centrum.cz wrote:
 My question is why?

Bugs and oversight.

.NET does not require that the assembly name match the namespace, and many of 
the types in the System.ServiceModel.Activation namespace are in the 
System.ServiceModel.dll assembly, _not_ the System.ServiceModel.Activation.dll 
assembly.

For example, AspNetCompatibilityRequirementsAttribute [0], 
ServiceHostFactoryBase [1], and VirtualPathExtension [2] are all in 
System.ServiceModel.dll. The WebScriptServiceHostFactory and 
WebServiceHostFactory types are in System.ServiceModel.Web.dll. 
WorkflowServiceHostFactory is in System.WorkflowServices.dll.

Please file a bug so that we can move the appropriate types into the correct 
assembly.

 - Jon

[0]: 
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.aspnetcompatibilityrequirementsattribute.aspx
[1]: 
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.servicehostfactorybase.aspx
[2]: 
http://msdn.microsoft.com/en-us/library/system.servicemodel.activation.virtualpathextension.aspx

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

Re: [Mono-list] FtpWebRequest works targeting .net, fails in mono 2.10.9

[Jonathan Pryor]

On Jul 30, 2013, at 9:31 AM, MikeN mniem...@oowidgets.com wrote:
 I have a simple FTP binary file upload, the code works fine in VS and Xamarin

As Aaron Oneal asked, what's the error? If it's a UriFormatException, it could 
be this:

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

 - Jon


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

Re: [Mono-list] Can't get a simple shared object to be used - DllNotFoundException

[Jonathan Pryor]

On Jul 30, 2013, at 5:34 PM, Stifu st...@free.fr wrote:
 I've never done that myself, but if I remember correctly, you're not supposed 
 to add the .so part. Just do [DllImport(libshared)].

Close; you should prefer [DllImport(shared)], with one exception. On Windows, 
this will try to load SHARED.DLL, on Linux it will load libshared.so, and on OS 
X it will load libshared.dylib.

The exception is that if the library name contains a '.', Windows LoadLibrary() 
will not automatically append a .DLL extension, so this would always fail:

[DllImport(gtksharp-2.0)]

In these cases, you should use the full Windows filename, and provide a 
.dll.config file so that the file can be found on other platforms:

[DllImport(libgtksharp-2.0.dll)]

- Jon

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

Re: [Mono-list] XML Serialization - difference between WinCLR and Mono runtime

[Jonathan Pryor]

On Jul 25, 2013, at 9:20 PM, MarLOne infoseeker...@gmail.com wrote:
 Parden my ignorance in Mono, is there more than one sgen program in Ubuntu 
 Mono?

sgen has two different meanings:

1. SGen is Mono's Simple Generational GC, now the default in Mono 3.2. You can 
explicitly opt-in to using the SGen GC by using `mono-sgen` or `mono --gc=sgen`.

2. SGEN is .NET's XML Serialization Generator Tool. Mono also has an `sgen` 
tool to generate XML serialization assemblies.

 - Jon

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

Re: [Mono-list] Accessing extension methods via embedded API

[Jonathan Pryor]

On Jul 10, 2013, at 11:56 AM, mugginsoft jonat...@mugginsoft.com wrote:
 I am trying to access a simple extension method in an embedded mono project.

Extension methods are C# syntactic sugar to invoke a static method. Extension 
methods WILL NOT appear as instance methods on the given type, ever, via both 
the embedded API and System.Reflection.

You must instead invoke the static method directly.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] mkbundle and cross compiling for ARM

[Jonathan Pryor]

On Jun 11, 2013, at 10:00 AM, markcoburnwa mcob...@globalscape.com wrote:
 Thanks, that is helpful to know about.  However, according to the mkbundle.cs 
 source file, it defaults to using the linux style and that style matches what 
 is being generated when I run mkbundle.

Indeed; I should have read the temp.s you provided more closely.

It would appear that your ARM arm-none-linux-gnueabi-as takes an assembly 
format that is currently unsupported. You will need to determine what assembly 
format arm-none-linux-gnueabi-as accepts and patch mkbundle to generate it.

 - Jon

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

Re: [Mono-list] how to run applications using mono framework instead of .NET framework on windows

[Jonathan Pryor]

On Jun 11, 2013, at 5:16 AM, ishmeet ishmeet.bha...@jci.com wrote:
 Now I want to ensure that when I debug my dll's they run using mono framework 
 and not .NET framework. Is there a way to do that.

Use Mono's embedding API to execute your .dll's:

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

Aside: How were you attempting to execute managed code from your native app if 
you weren't embedding Mono already? COM interop? LoadLibrary() + 
GetProcAddress()[0]?

 - Jon

[0]: 
http://www.codeproject.com/Articles/37675/Simple-Method-of-DLL-Export-without-C-CLI
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] mkbundle and cross compiling for ARM

[Jonathan Pryor]

On Jun 10, 2013, at 7:56 PM, markcoburnwa mcob...@globalscape.com wrote:
 Unfortunately, I get unrecognized symbol type assembler errors.

The problem is that there is not just one style of assembly. There are 
multiple styles, for varying conventions, in order to appease the default 
assembler for each platform.

When you run mkbundle on OS X, `mkbundle` will (by default) generate OS X-style 
assembly, which differs from Linux-style assembly, which differs from 
Windows-style assembly.

Fortunately, you can set this, using the undocumented --style option:


https://github.com/mono/mono/blob/master/mcs/tools/mkbundle/mkbundle.cs#L132

Thus:

export CC=/opt/arm-none-linux-gnueabi-gcc-4.4.1
export AS=/opt/arm-none-linux-gnueabi-as
mkbundle --style linux -c -o myapp.c -oo bundles.o --deps myapp.exe 
--keeptemp

 - Jon

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

Re: [Mono-list] ZipArchive?

[Jonathan Pryor]

On May 27, 2013, at 1:46 PM, Madsn ma...@theweb.dk wrote:
 Hi, I had hoped to find the System.IO.Compression.ZipArchive class when using 
 mono .net 4.5, but didn't find it.
 
 Will it be supported or are there copyright issues or something? (Or didn't I 
 just look hard enough)

That type was added in .NET 4.5 and we haven't had a chance to implement it yet.

Please file a feature request at bugzilla.xamarin.com.

In the meantime, ICSharpCode.SharpZipLib is included with Mono, and Ionic.Zip 
also works with Mono.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] java parser in C#

[Jonathan Pryor]

On Apr 7, 2013, at 6:12 PM, mutasim d_muta...@hotmail.com wrote:
 in this web site www.java2s.com i can find the JDK source code , the classes 
 can be add as dll files, compiling these files will be all at one time to 
 have full classes without error 

Which is more or less what IKVM allows. IKVM is two things (possibly among 
others):

1. A transpiler that can convert Java bytecode into CIL.
2. A JVM implementation that can load Java bytecode at runtime and execute it.

(1) is required in order for (2) to work. However, (1) can also be done ahead 
of time, e.g. you can take the JDK `classes.jar` and transpile it into 
classes.dll. Other Java code can then refer to this classes.dll (via more 
transpiling), and C# code can reference classes.dll and use Java types such as 
java.util.ArrayList.

The benefit to this approach is that you have a Real Java Compiler compiling 
the Java code, along with a Real Java Class Library (allowing Java code to 
easily execute), both of which you don't need to maintain (bonus!), and has 
full support for all Java language features. Furthermore, after running 
ikvmc.exe, there's no additional runtime overhead -- everything is CIL.

Is there any reason -- other than learning/education -- to prefer a new Java 
compiler based on mcs than to leverage the work of IKVM?

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] csharp REPL

[Jonathan Pryor]

On Mar 18, 2013, at 4:33 AM, Ian Norton 
ian.norton-bad...@thales-esecurity.com wrote:
 You probably mean to do:
 
 $ csharp -r:System.Core 

That shouldn't be necessary at all; System.Core.dll should be in the default 
assembly include set and `using System.Linq` should be in the default namespace 
set for `csharp` so that you can immediately use LINQ:

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

Enter statements below.
csharp Enumerable.Range(1, 10).Max();
10 

 - Jon

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

Re: [Mono-list] csharp REPL

[Jonathan Pryor]

On Mar 17, 2013, at 11:54 AM, Dale Ragan d...@ragan.io wrote:
 I was playing with the csharp REPL today after upgrading my install to 3.0.6 
 and I tried using System.Core, but it returns:

System.Core is an assembly (System.Core.dll), not a namespace. There is no 
System.Core namespace. System.Core.dll contains types in the namespaces 
System.IO, System.Linq, System.Threading, and others:

https://github.com/mono/mono/tree/master/mcs/class/System.Core

`using System.Core;` is thus not valid in a C# app, unless you yourself have 
declared types in a System.Core namespace.

 - Jon

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

Re: [Mono-list] Mono for Android: how to use a non-standard widget from axml?

[Jonathan Pryor]

On Mar 11, 2013, at 8:07 AM, Dimitar Dobrev dpldob...@yahoo.com wrote:
I have a class in my project that is a widget. I know I can use it in 
 code as a workaround but can I use it in axml as well? If so, how do I 
 configure it?

The monodroid list [0] or the forums [1] would be a better place to ask.

To refer to a type in a .axml file, you must use either the fully-qualified C# 
type name (case-sensitive), or the fully-qualified Android Callable Wrapper 
type name [2, 3]:


https://github.com/xamarin/monodroid-samples/blob/master/GLCube/Resources/layout/main.xml#L21

https://github.com/xamarin/monodroid-samples/blob/master/GLCube/PaintingView.cs#L16

The above sample is old, so it's using the Android Callable Wrapper type name, 
but it could instead use the fully-qualified C# type name instead:

Mono.Samples.GLCube.PaintingView
android:id=@+id/paintingview
android:layout_width=fill_parent
android:layout_height=fill_parent
/

 - Jon

[0]: http://lists.ximian.com/mailman/listinfo/monodroid
[1]: http://forums.xamarin.com/categories/android
[2]: http://forums.xamarin.com/discussion/comment/6912/#Comment_6912
[3]: 
http://docs.xamarin.com/guides/android/advanced_topics/java_integration_overview/android_callable_wrappers

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

Re: [Mono-list] Poor Mono performance

[Jonathan Pryor]

On Mar 11, 2013, at 6:04 AM, Ian Norton 
ian.norton-bad...@thales-esecurity.com wrote:
 Don't forget too, that process creation is very expensive on windows, .Net 
 sort of shortcuts this because it is deeply welded into windows.

Not really. A process is a process. That's why the .NET team invented 
AppDomains, to avoid the overhead involved in process creation...

 - Jon

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

Re: [Mono-list] callvirt instruction performance penalty?

[Jonathan Pryor]

On Mar 11, 2013, at 8:47 PM, Nigel Delaney nigel.dela...@outlook.com wrote:
 However, I was surprised to learn when disassembling code that both Mono and 
 Microsoft seem to ignore this optimization, and emit all method calls as 
 callvirt instructions in IL regardless of whether or not they are actually 
 virtual method calls, which seems to defeat the whole point of not being java.

No. That's a different optimization. ;-)

A callvirt to a non-virtual method does not bind the method virtually; it binds 
it non-virtually, and the method cannot be overridden.

So why use callvirt? Because callvirt implicitly checks the target's `this` 
reference and will throw a NullReferenceException when it's null.

It is thus a space optimization: instead of needing to null-check arguments 
everywhere, they just rely on callvirt to do the null check.

 A Microsoft employee blogged about this  
 (http://blogs.msdn.com/b/ericgu/archive/2008/07/02/why-does-c-always-use-callvirt.aspx)
   and it seems that made this change to ensure that instance methods could 
 not be called on null instance references (a debatable decision perhaps). 

I should finish reading emails before replying.

 I gather/suspect that Microsoft still optimizes the callvirt instruction 
 during the JIT stage to call the method and check for a null reference,

This is not possible. At JIT time, they just have data, they just have 
instructions to execute. They don't have everything that won't be known until 
runtime. It's thus ~impossible (in the general case) to know if a given 
instance will be null at JIT time. You will know if the instance is null at 
runtime.

For example, consider string.Concat(). That method will be invoked from lots of 
different places in your code. It _cannot_ null check the arguments at JIT 
time, because there's only one (~random) code path that will hit it at JIT 
time, but it'll be invoke at runtime by lots of different places.

The null check thus must be at runtime.

 And if Mono also is able to optimize callvirt calls that are not actually 
 virtual calls?

Yes. callvirts to non-virtual calls do not go through the virtual method table, 
they just directly call the target method after the null check.

 - Jon

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

Re: [Mono-list] Xamarin 2.0 concern

[Jonathan Pryor]

On Feb 27, 2013, at 2:09 PM, edward.harvey.mono 
edward.harvey.m...@clevertrove.com wrote:
 Still, how to pronounce it?   Samarin?  Zamarin?  Ex-amarin?

The X is pronounced as a Z, so more like Zamarin (just like Xylophone).

 - Jon

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

Re: [Mono-list] Running a shell builtin from mono

[Jonathan Pryor]

On Feb 8, 2013, at 5:39 AM, Mathias Tausig mathias.tau...@a-cert.at wrote:
 Does it? I didn't know that. I assumed it uses the same shell that mono is  
 running in.

You're assuming that Mono was started from a shell. This need not be the case 
(e.g. started directly as user's login shell or as system service, in which 
`init` would be the parent process).

Even if Mono is started from a shell, it's usually not possible for a child 
process to communicate with the parent process unless they're explicitly 
designed to do so (e.g. via common file descriptor or pipes); e.g. there's no 
way (that I know of) for a child to ask it's parent shell what environment 
variables do you currently have?. (Keep in mind that the child gets a _copy_ 
of the parent's environment, so if the parent's environment changes, the child 
won't see those changes.)

Then there's Windows which doesn't even have a parent/child relationship.

 - Jon

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

Re: [Mono-list] Running a shell builtin from mono

[Jonathan Pryor]

On Feb 7, 2013, at 8:27 AM, Ulrich Hertlein u.hertl...@gmail.com wrote:
 Any particular reason why you don't just call the POSIX syscall directly, w/o 
 exec a shell?

Which is bound as Syscall.umask():


http://docs.go-mono.com/?link=M%3aMono.Unix.Native.Syscall.umask(Mono.Unix.Native.FilePermissions)

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Why Gnome prefer JavaScript?

[Jonathan Pryor]

On Feb 5, 2013, at 10:23 AM, Alberto León leontis...@gmail.com wrote:
 But, JavaScript was the reason to Oracle denounced Google.

No, Java as why Oracle sued Google. JavaScript is completely different. It's 
kinda/sorta/not-really like comparing C and Perl -- sure, they both use '{' for 
blocks, but other than that...completely different.

 I can't understand why Gnome and Linux rejected support C# and has accepted 
 javascript as official language.

Let's just admit that C# was never going to be a viable first-choice option for 
Gnome, for both political reasons (Microsoft sucksoneone!!) and 
functional reasons (is there a decent GTK+ 3.0 binding yet? I'm not sure, and 
even if there is it took awhile...).

Gnome needed a single language to tell newcomers to use, to use for 
documentation and samples [0]. C is too low-level and annoying. C# isn't 
viable, politically. Java sucks. Python would be plausible, but it's whitespace 
requirements tends to turn people off.

Gnome Shell is already partially implemented in JavaScript, so their decision 
to recommend it is not entirely unsurprising or shocking.

 - Jon

[0] See also The Paradox of Choice: 
https://www.google.com/search?q=the+paradox+of+choice

Too many choices make decision making harder, which will drive people away from 
the platform. Gnome _needs_ a single choice BY DEFAULT. Sure, other languages 
can, should be, and are usable, but for newcomers a single choice needs to be 
used.

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

Re: [Mono-list] Unable to get block device size in UnixStream

[Jonathan Pryor]

On Jan 29, 2013, at 3:46 AM, Dragony csch...@rapidshare.com wrote:
 I want to get the device size of /dev/sda. I have an open fd and a UnixStream

Don't use UnixStream.Length here; UnixStream.Length uses the stat(2) system 
call, which states:

http://linux.die.net/man/2/stat
 The st_size field gives the size of the file (if it is a regular file or a 
 symbolic link) in bytes. The size of a symbolic link is the length of the 
 pathname it contains, without a terminating null byte.


You should instead use Syscall.fstatvfs() and Statvfs:


http://docs.go-mono.com/index.aspx?link=M%3aMono.Unix.Native.Syscall.fstatvfs(System.Int32%2cMono.Unix.Native.Statvfs%40)
http://docs.go-mono.com/index.aspx?link=T%3aMono.Unix.Native.Statvfs%2f*

For example:

Statvfs stat;
int r = Syscall.fstatvfs (fd, out stat);
int filesystem_size = stat.f_blocks*stat.f_frsize;

 - Jon

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

Re: [Mono-list] Question on unix signal handling

[Jonathan Pryor]

On Jan 17, 2013, at 11:02 AM, mickeyf mic...@thesweetoasis.com wrote:
 I see   in this documentation:
 http://oddacon.hopto.org:8181/1.1/handlers/monodoc.ashx?link=T%3AMono.Unix.UnixSignal

 
 In a multi-threaded program, a thread is selected at random among the 
 threads that can handle the signal, and that thread is hijacked to run the 
 signal
 
 I understand that that is referring to _unmanaged_ *nix code, not Mono.

Mono Threads are POSIX threads, which are native threads, so that is equally 
true for managed code. Any thread in the process can be hijacked by the 
kernel to execute signal handlers, and care must be taken to only call 
signal-safe functions from within a signal handler.

This was why Stdlib.signal() was deprecated: it's not possible for managed code 
to _only_ call signal-safe functions, as the native-managed transition itself 
isn't signal safe.

This is also why UnixSignal is _not_ like signal(2). It's a flag that gets 
set when a signal is raised, nothing more.

 So, I'm thinking of using code based on height8's (only 2 year old) blog post 
 :  here http://www.height8.com/?unixsignal_mono  
...
 If I have a Mono application with an arbitrary number of threads, can I use 
 this approach to make sure that any signal is properly caught and handled by 
 a single method?

Without dropping down to C and using sigaction(2), there is no way of 
restricting which thread will execute a signal handler. UnixSignal provides no 
facility to do that.

 That is, will any signals that are raised be seen only by my signal handler, 
 and ignored by everything else?

As stated above, a UnixSignal represents a flag (has the signal been 
raised?). _You_ aren't providing a signal handler, so there is no signal 
handler of yours to execute.

 If my Mono app is using unmanaged libraries, I presumably have to ensure that 
 the library code also either ignores any signals or handles them in a 
 sensible way. (Using signal(2), or SIGACTION(2) ?)

Signals are like The Highlander: There Can Be Only One (signal handler for a 
particular signal).

Some programs and libraries will have special ways to forward signal 
invocation (e.g. mono_set_signal_chaining ()), but that is not common practice 
afaict. Thus, yes, you would need to somehow ensure that the union of all 
libraries your app uses doesn't have an overlap in handled signals, e.g. you 
can't have multiple libraries have their signal handlers raised for the 
SIGWINCH signal; there can be only one SIGWINCH handler, period.

 What I'm ultimately aiming at is that I can 
 
 a) make sure that I can shut down my application cleanly and completely by 
 sending it a signal (ctrl-C from the keyboard for example), and that 
 
 b) it does not get tripped up by signals that may originate from other 
 processes other than a system shut down, an intentional kill, etc.

That should be doable.

 - Jon

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

Re: [Mono-list] Question on unix signal handling

[Jonathan Pryor]

On Jan 17, 2013, at 4:21 PM, mickeyf mic...@thesweetoasis.com wrote:
 Ok, so if I have a thread in my managed code that does nothing but check 
 UnixSignal.WaitAny, as described in height8's blog post, and then does no 
 more than set some simple variable when that occurs, that should as safe and 
 reliable as I can expect to get using managed code?

Yes that's safe.

 - Jon

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

Re: [Mono-list] libc.so vs libc.so.6

[Jonathan Pryor]

On Jan 14, 2013, at 12:11 PM, tomason t...@creamysoft.com wrote:
 Is there a way to tell mono to look somewhere else for libc.so?

Yes: an .exe.config with a dllmap/:

http://mono-project.com/DllMap

However, this really shouldn't be necessary; mono includes a default dllmap in 
$prefix/etc/mono/config which _should_ contain an appropriate remapping, e.g. 
on OS X:

  dllmap dll=libc target=libc.dylib os=!windows/


However, for that to work you need to use the same value in your [DllImport], 
e.g. from mono/mcs/class/corlib/Linux/Linux.cs:

[DllImport(libc, EntryPoint=getpid)]
private unsafe static extern int _getPid(); 

What library are you using in your [DllImport]'s? Could you try using libc 
and see if that fixes things?

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] ASCII bytes to string?

[Jonathan Pryor]

On Jan 10, 2013, at 1:28 PM, mickeyf mic...@thesweetoasis.com wrote:
 The string itself displays as expected, but shows a length of twice the 
 number of characters, as if String.Length is reporting the number of bytes 
 (UTF16) rather than the number of Unicode characters in the string. 

In all likelihood, the string contains non-printable characters. Consider this 
`csharp` snippet:

csharp var b = new byte[]{(byte) 'a', (byte) 'b', 0, 0, 0, 0};
csharp var s = System.Text.Encoding.UTF8.GetString(b);
csharp s.Length
6
csharp s;
ab

So this is more or less exactly what you're describing; `s` _clearly_ has two 
characters, yet s.Length is 6!

Except `s` doesn't have two characters:

csharp  [3];
'\x0

There's some null data in there, because our source byte array contained null 
bytes, and System.String can contain ASCII NUL characters, which `b` contains.

You can confirm/deny this by seeing that `buffFromDrv` actually contains, and 
see if it has any non-printable data (e.g. ASCII NUL).

Assuming that's the case, what you need to do is not convert extra data:

byte[] buffFromDrv = new byte [BIG_ENOUGH];
int bytesRead = stream.Read(buffFromDrv, readPosition, bytesToRead);
string s = System.Text.UTF8Encoding.UTF8.GetString(buffFromDrv, 0, 
bytesRead);

Or for the above `csharp` snippet:

csharp var s = System.Text.Encoding.UTF8.GetString(b, 0, 2);
csharp s;
ab
csharp s.Length;
2

 The documentation for string.length says number of characters, not number 
 of bytes,

It's actually neither; String.Length is the number of UTF-16 code units 
stored in the string. This is _not_ the number of characters (code points), 
because a code point may require the use of a surrogate pair, in which case 
it will take up two `char` values within the string:

http://en.wikipedia.org/wiki/UTF-16

(Normally you don't need to care about this, except when you do...)

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] linux, binfmts:Unexpected behavior

[Jonathan Pryor]

On Jan 2, 2013, at 1:02 PM, ma...@manfbraun.de wrote:
 I moved over a lot of utilities from windows to linux, but starting them 
 using mono ... is a pain and luckily, I discovered binfmts.

Presumably as suggested at:


http://www.mono-project.com/Guide:Running_Mono_Applications#Registering_.exe_as_non-native_binaries_.28Linux_only.29

Please don't do that; please follow the Application Deployment Guidelines and 
use a shell script wrapper:


http://www.mono-project.com/Guide:Running_Mono_Applications#Shell_Scripts
http://www.mono-project.com/Guidelines:Application_Deployment

The reason being for increased compatibility across Unix platforms, and because 
(as you note), it doesn't work properly:

 Running via binfmts looks strange:
 
 myuser WakeTheBox.exe hel
 AppDomain.CurrentDomain.BaseDirectory: /usr/sbin/

Why? I'm not entirely sure, but I would guess that binfmt works by having the 
kernel execute a helper program located in /usr/sbin, and the helper in turn 
is responsible for executing mono + the assembly, which may screw up mono's 
normal logic. The fact that it screws things up is documented at the above 
urls; _why_ it screws things up is not.

 - Jon

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

Re: [Mono-list] Questions on Mono.Unix.Pipes

[Jonathan Pryor]

On Dec 17, 2012, at 12:05 PM, mickeyf mic...@thesweetoasis.com wrote:
 I have been using this with some success, but I am relatively new to Linux, 
 and the mono documentation that I have found is missing or incomplete.

Is it?

http://docs.go-mono.com/?link=T%3aMono.Unix.UnixPipes
http://docs.go-mono.com/?link=M%3aMono.Unix.UnixPipes.CreatePipes()
http://docs.go-mono.com/?link=T%3aMono.Unix.UnixStream

Granted, there aren't any unit tests or full examples using it, but there's 
certainly documentation... Of course, there's always source:


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

 The Linux manual pages docs on pipes are clearly referring to a different 
 animal than this.

UnixPipes wraps the pipe construct documented in the pipe(2) man page. 
pipe(2) opens a pair of file descriptors for reading and writing; 
UnixPipes.CreatePipes() calls pipe(2), wraps the reading file descriptor in the 
UnixPipes.Reading field, and wraps the writing file descriptor in the 
UnixPipes.Writing field.

 It appears that I can read a pipe as mypipes.readend.Read(buffer_to_read_to, 
 read_position, bytes_to_read).

Correct. However, you may be misinterpreting read_position; read_position 
is the offset within buffer_to_read_to at which to start writing bytes_to_read 
bytes worth of data. It does _not_ imply any form of seeking at all.

For example, given:

byte[] buffer = new byte [3];
stream.Read (buffer, 1, 2);

After `stream.Read()`, buffer[0] will always be 0x00, because it will never 
have been written to. The `1` specifies the position within `buffer` to start 
writing, that's all, and has nothing to do with the underlying Stream.

See also:

http://msdn.microsoft.com/en-us/library/system.io.stream.read.aspx
 offset
 Type: System.Int32
 The zero-based byte offset in buffer at which to begin storing the data read 
 from the current stream.

 I understand that I can't actually fseek using read_position,

You're dealing with pipes; you want POSIX functions, not libc functions. 
(Granted, in C-land you could use fdopen(3), then use fseek(3)...) 
Consequently, the appropriate seek function is lseek(2), which errors out with 
ESPIPE when  using pipes:

[ESPIPE] Fildes is associated with a pipe, socket, or FIFO. 

No seeking on pipes. It's POSIX.

 but it seems that if I do not read the entire bytes_to_read, I can then 
 continue to adjust read_position to read the remaining data.

I believe you're misunderstanding the `offset` parameter in the 
Stream.Read(buffer, offset, count) method.

 2) Since I can't find documentation specific to this, it's not clear what the 
 return values from Read will be when I can't actually read anything.

UnixStream needs to conform to the System.IO.Stream contract, which MSDN 
documents:

http://msdn.microsoft.com/en-us/library/system.io.stream.read.aspx
 Return Value
 Type: System.Int32
 The total number of bytes read into the buffer. This can be less than the 
 number of bytes requested if that many bytes are not currently available, or 
 zero (0) if the end of the stream has been reached.


 Does -1 indicate error, or simply no data available? What about 0?

-1 should not be returned, ever. (If read(2) returns -1, UnixStream.Read() 
translates that into an exception.) If 0 is returned, then End-Of-Stream has 
been reached. If no data is available, the Read() method will _block_ until 
data is available.

 3) Can I set the write end to disable O_NONBLOCK,

Syscall.fcntl() can be used to set O_NONBLOCK.

 and does this guarantee that both the write and the read are atomic and that 
 all bytes will in fact be read in a single read on the read end of the pipe?

As far as I am aware, _nothing_ can guarantee that. I could be wrong.

 Or, since what I really want to do is guarantee that a entire (privately 
 defined) data packet as written by my C library code is read by my mono app, 
 perhaps there is an entirely different, and better way to do this? Sockets?

As far as I am aware, no Stream-like API will support this, including sockets. 
Data structure boundaries need to be dealt with at a higher level, e.g. 
having a protocol that sends a length packet before sending the data. This 
would allow the reader to read (and block reading, or read until it has read) 
~4 bytes, examine the length, and then read the specified amount of data.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] monologue blogs

[Jonathan Pryor]

On Oct 16, 2012, at 11:40 AM, Ian Norton 
ian.norton-bad...@thales-esecurity.com wrote:
 Hello all
 
 I was wondering, how do blog feeds get added to 
 http://www.go-mono.com/monologue/ ? My blog posts about debian packages might 
 be useful to more people.

If you have permission to commit to the mono git repos, just add your blog to:

https://github.com/mono/monologue/blob/master/worker/bloggers.xml

IIRC the server should pick up the change every ~30 minutes.

 - Jon

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

Re: [Mono-list] How does mono translated into C++ Native Code in Linux

[Jonathan Pryor]

On Sep 16, 2012, at 9:05 PM, John Chen john...@gmail.com wrote:
 Question, when Mono using AutoEvent inside managed code, what does it 
 corresponding it to? I know in Windows it translated into Windows Event 
 object (I could use the same handle in C, C++), how about in Linux?

On Linux, io-layer is used to implement a WinAPI subset for use on 
non-Windows platforms, e.g. CreateEvent():

https://github.com/mono/mono/blob/master/mono/io-layer/events.c#L321

It is highly unlikely that your code could rely on these unless your native 
code is linking against libmono.so. Furthermore, on many systems these WinAPI 
exports have a Mono prefix, e.g. on OS X:

$ dyldinfo -export 
/Library/Frameworks/Mono.framework/Libraries/libmono-2.0.dylib | grep 
CreateEvent
0x001B6280 _ves_icall_System_Threading_Events_CreateEvent_internal
0x001D5EB0 _MonoCreateEvent 

 - Jon

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

Re: [Mono-list] Thread safe list in C#

[Jonathan Pryor]

On Sep 3, 2012, at 1:31 AM, vnan122 veeresh...@gmail.com wrote:
 Hello every one, I just want to know how to make a list thread safe

In practice, you don't; a method can do anything...

By convention, you can generally assume that static members are thread safe and 
instance members are not (unless those instance methods are exposed from static 
methods, e.g. System.Reflection), but that's by no means guaranteed and may be 
violated.

In general, you need to read the documentation to determine which members are 
threadsafe and which are not.

 and is there any options for concurrent list like in JAVA.

Have you tried System.Collections.Concurrent.ConcurrentBagT?

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

This assumes that you don't need to maintain ordering.

Of course, you could always just use ListT + `lock`, unless/until profiling 
demonstrates that you're spending too much time acquiring locks...

 - Jon

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

Re: [Mono-list] Proper way to reference assemblies?

[Jonathan Pryor]

On Sep 6, 2012, at 7:31 PM, kibagami labra...@csusm.edu wrote:
 I'm trying to work with MonoDroid

The monodroid list would be more appropriate:

http://lists.ximian.com/mailman/listinfo/monodroid

 anyhow, while coding; I've been trying to add extra .NET libraries that were 
 not included with my eval pack and other pre-made C# classes to my mono 
 solution.

If these are precompiled assemblies (i.e. you didn't build them yourself), this 
is unadvisable, and liable to blow up. Mono for Android is a distinct 
profile, not entirely compatible with regular .NET. In the same way that 
you couldn't intermix .NET 3.5 assemblies and Silverlight 3 assemblies, you 
can't safely intermix Mono for Android assemblies with anything that wasn't 
compiled against the Mono for Android assemblies.

For example, if you use an assembly that uses System.Configuration, or 
System.Windows.Forms, it WILL fail on device, as those assemblies don't exist.

 All of the .NET and C# classes appeared to have been absorbed and consumed 
 except for the a library written in VB.NET. 
 I keep on getting this error: 
 
 /Could not load assembly 'Microsoft.VisualBasic, Version=8.0.0.0, 
 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'./

Same problem: Mono for Android doesn't provide a Microsoft.VisualBasic.dll 
assembly, so your VB.NET assembly can't be used. Furthermore, you can't use 
Microsoft's Microsoft.VisualBasic.dll assembly, as it wasn't compiled against 
the Mono for Android assemblies, so it would likely fail to load at runtime.

Unfortunately you can't use VB.NET-generated assemblies with Mono for Android 
at this time.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Questions about coding style

[Jonathan Pryor]

On Aug 20, 2012, at 3:28 PM, Philippe Grohrock philippe.grohr...@gmail.com 
wrote:
 Thanks for the reply already and I'm sorry, I should've added the lines of 
 code.
 
   static class GlobalVariables
   {
   public static MySqlConnection connection = new connection();
   }
 
 This way the whole program has access to it and can modify/query the DB when 
 needed (this is what I meant with global).

I believe that this is a Bad Idea™.

Firstly, this is counter to ~every MSDN example on using connections, which 
always scopes the Connection instance:

// 
http://msdn.microsoft.com/en-us/library/ff647768.aspx#scalenetchapt12_topic9
using (SqlConnection conn = new SqlConnection(connString))
{
conn.Open();
// ...
}

This implies that you should instead do:

static class Database {

internal static MySqlConnection CreateConnection ()
{
return new connection ();
}
}

And narrowly scope your use:

using (var c = Database.CreateConnection ()) {
c.Open ();
// ...
}

Now, _why_ should you do this? Unfortunately I can't find anything to confirm 
or deny the following, but this is my recollection from using SQL many years 
ago...

The reason why is connection-related errors: if (when) you hit a network 
interruption, the DbConnection instance is unusable afterward, even if the 
network came back. (Though maybe I needed to .Close() and .Open() to repair the 
instance? I no longer remember.) I found that the easiest/sanest way to go was 
to just recreate the Connection instance when needed, and Dispose() of it as 
soon as possible (relying on lower-level connection pooling if possible).

 - Jon

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

Re: [Mono-list] Questions about coding style

[Jonathan Pryor]

On Aug 17, 2012, at 5:49 PM, Philippe Grohrock philippe.grohr...@gmail.com 
wrote:
 1. Is it bad/good style to have a public class that implements global 
 variables?

How do you define global variable? :-)

`public static` fields are Very Bad™, unless they're `readonly`. This is 
because there's no way to prevent modification of the field from anything else 
in your process.

`public static` properties are (generally) fine, and are common in the Base 
Class Library.

Best, though, is to keep things `internal` or `private` unless they _really_ 
need to be public.

 My program readys a DB connection right at the start which is queried by 
 multiple different GTK windows.

This is a case where `internal` should normally be preferred over `public`, 
unless another assembly in your app needs access to the value.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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] .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-list] Help finding system.media sounds

[Jonathan Pryor]

On Apr 4, 2012, at 11:07 PM, Xavi de Blas wrote:
 Hello, I need to find the audio files that are called when I do:
 
 System.Media.SystemSounds.Question.Play()
 System.Media.SystemSounds.Asterisk.Play()
 System.Media.SystemSounds.Beep.Play()
 
 because I need to play them also with another software in other language.

These are not stored as separate files outside of the source tree. They're 
stored as resources within System.dll:

// 
https://github.com/mono/mono/blob/master/mcs/class/System/System.Media/SystemSound.cs#L40
resource = typeof (SystemSound).Assembly.GetManifestResourceStream (tag 
+ .wav);

They're available from the git repository:

https://github.com/mono/mono/tree/master/mcs/class/System/resources

https://github.com/mono/mono/blob/master/mcs/class/System/resources/Question.wav

https://github.com/mono/mono/blob/master/mcs/class/System/resources/Asterisk.wav

https://github.com/mono/mono/blob/master/mcs/class/System/resources/Beep.wav

 - Jon

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

Re: [Mono-list] Linux - Mono - Image Files...?

[Jonathan Pryor]

On Mar 30, 2012, at 3:01 AM, Allen Copeland wrote:
 Just out of curiosity:  does mono support .so-based images for CLI metadata?

No, though there was some thinking in that direction many moons ago in the 
context of supporting mixed-mode assemblies:

http://lists.ximian.com/pipermail/mono-devel-list/2011-July/037779.html

I don't think it ever went anywhere.

 - Jon

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

Re: [Mono-list] Embedded Mono using DllImport(__Internal) and returning string

[Jonathan Pryor]

On Mar 12, 2012, at 3:51 PM, efontana wrote:
 I'm using Embedded Mono and P/Invoke DllImport.   If I have a method which 
 returns a string
...
 The corresponding C method should strdup the string right?

Probably not. During string marshaling, the pointer returned from 
CSharp_Test_ReturnString() will be freed as if through 
System.Runtime.InteropServices.Marshal.FreeCoTaskMem(), which is 
platform-specific. On Windows, this is CoTaskMemFree(). On non-Windows, this is 
g_free().

Either way, unless g_free() is aliased as free(3), strdup() will not allocate 
memory from the appropriate heap.

Consequently, you should explicitly allocate your memory with the correct 
memory allocator and strcpy() the value.

 - Jon

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-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-list] Monodroid + emulator

[Jonathan Pryor]

On Nov 22, 2011, at 11:02 AM, sebi77 wrote:
 I'm writing an app for an Android tablet, so I need larger resolution then
 the default. I set up a 1024*768, 2.2 Android emulator, and I deleted the
 Abstracted LCD density property, because it spoils the size of my bitmaps.
 It works fine with Eclipse+Java, but with Monodevelop the app doesn't fit
 the screen, only cc. the half of it. What's wrong? Thx!

A more appropriate list would be:

http://lists.ximian.com/mailman/listinfo/monodroid

That said, the problem is a feature -- Mono for Android automatically generates 
a uses-sdk/ element and sets the minSdkVersion attribute to the 
TargetFrameworkVersion you compiled against. The default Java project, 
meanwhile, will not.

Result: you're automatically opted in to the new, no automagic scaling 
support introduced in Android 1.5 (API level 3!):

http://developer.android.com/guide/practices/screens_support.html

Starting with Android 1.6 (API Level 4), Android provides support for 
multiple screen sizes and densities, reflecting the many different screen 
configurations that a device may have.

You can override this behavior by adding a uses-sdk/ without any attributes 
to your Properties\AndroidManifest.xml file (which will override the default 
behavior).

 - Jon

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

Re: [Mono-list] System.Diagnostics.Debug.Assert()

[Jonathan Pryor]

On Oct 27, 2011, at 1:33 PM, Steve Lessard wrote:
 Debug builds of my Mono command line application blow right by all 
 Debug.Assert statements, even the ones I know fail the assertion. Heck, even 
 Debug.Assert(false, Foo) gets ignored.  Neither running standalone on the 
 command line via Terminal.app nor running in MonoDevelop's debugger makes a 
 difference; the asserts are always ignored.  I've checked, double-checked, 
 and even triple checked that I am created Debug builds. Is there any way to 
 force Mono to honor the asserts?

By default, the DefaultTraceListener prints nothing (as there's no real 
equivalent to OutputDebugString() on not-Windows). You can set an environment 
variable to override this behavior; see the remarks for the 
DefaultTraceListener type:


http://docs.go-mono.com/index.aspx?link=T%3aSystem.Diagnostics.DefaultTraceListener

$ export MONO_TRACE_LISTENER=Console.Error:+++
$ mono yourapp.exe

However, this is purely console based, so no dialog box yelling abort, retry, 
ignore. If you want something more elaborate, you'll need to write it and add 
it to the Listeners collection, as Nicholas Frechette suggested.

You should also re-read the compiler output to ensure that -define:DEBUG is on 
the command line, or add a `#define DEBUG` to the relevant file, otherwise the 
compiler will omit the Debug.Assert() call.

 - Jon

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