Re: [Mono-dev] How to stop and debug native code of a method?

[Robert Jordan]

On 12.07.2016 12:39, Pin Cheng wrote:

Hi All,

I am porting mono to a platform,

I wander if I want to trace a method(compiled into native code) how do

You stop the program running when entering into this method? Gdb can

Watch the PC register, but it is very slow, I have wait for tens of minutes.

Is there any efficient way to interrupt some method running?



mono --break namespace.class:methodname  your-assembly.exe

See mono's man page.

Robert


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

Re: [Mono-dev] about appdomain and threads.

[Robert Jordan]

On 08.07.2016 05:34, Zhanxing Ding wrote:

Can anyone could tell me about the relationship between appdomain and
threads?

The details are that:



If creating a new appdomian must create a new thread corresponding to it?


It's not required to create a thread for the AppDomain, nor does
the .NET/Mono runtime create one implicitly. Furthermore, AppDomains
do not isolate threads. A thread is readily able to run code from
multiple AppDomains.

Robert


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

Re: [Mono-dev] mono_add_internal_call to mscorlib method

[Robert Jordan]

On 09.06.2016 15:37, nicob wrote:

Hi Robert, thanks for the reply. I didn't explain my self correctly. Here's
an example, I have a c# assembly with a method that prints the args to the
console:


I believe I didn't explain the workaround entirely.

Parts of the Mono runtime are expecting that the main entry point
of some assembly has been executed.

Environment.GetCommandLineArgs belongs clearly to this part of
the runtime because, well, it needs data only provided
by executing the main entry point.

The trick is to invoke  mono_jit_exec () on a simple assembly
which does only this:

$ cat < entrypoint.cs
namespace Helper {
   public static class EntryPoint {
public static void Main ()
{
}
   }
}
EOF

$ mcs /target:exe /out:entrypoint.dll entrypoint.cs


Then load entrypoint.dll and pass it to mono_jit_exec.
After this call, almost all parts of the runtime will work
as expected, including Environment.GetCommandLineArgs.
It will return what you've provided to mono_jit_exec ().

Robert


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

Re: [Mono-dev] mono_add_internal_call to mscorlib method

[Robert Jordan]

On 08.06.2016 21:26, nicob wrote:

Hi, I'm trying to use the Skype Sdk in mono embedded. I'm able to load the
assemblies but when I try to create a instance of a class that internally
calls System.Environment.GetCommandLineArgs it throws an exception. After
digging a bit I found out the System.Environment.GetCommandLineArgs
internally invokes:

private static extern string[] GetCommandLineArgsNative();

this method is returning null therefore it fails. I'm trying to add an
internal call to the extern method using:

mono_add_internal_call ("System.Environment::GetCommandLineArgsNative",
(void*)GetCommandLine);

I also tried:

mono_add_internal_call
("mscorlib.System.Environment::GetCommandLineArgsNative",
(void*)GetCommandLine);

but neither of them seem to work as my C++ function is never invoked.


You can't override methods which have an IL implementation with icalls.

However, your problem is most likely related to the fact that
you haven't initialized the runtime properly.

You're supposed to invoke a "static void Main () {} " method (which
you can implement in a support assembly) with mono_jit_exec ().

Robert



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

Re: [Mono-dev] Embedded API: delegate type building

[Robert Jordan]

Hi Jonathan,

You may want to have a look at this repo:

https://github.com/robert-j/Mono.Embedding/tree/master/Mono.Embedding

especially at UniversalDelegateServices.

UniversalDelegateServices is able to wrap (almost) all delegate
types with a UniversalDelegate with the following signature:

public delegate object UniversalDelegate(object[] args);

This basically means that you can handle all kind of delegate types
with only one internal call.


Recipe:


Implement an icall with the following signature:


MonoObject*
UniversalDelegateServices_NativeHandler(void *context,
  MonoArray *params)
{
  ...
}


Register it with:

mono_add_internal_call (
  name,
  _NativeHandle);

"name" can be obtained by invoking
UniversalDelegateServices.GetInternalCallName ().


Whenever you need to create a delegate of a given type,
invoke

UniversalDelegateServices.CreateWrapper(type, context);

"context" is a user-defined IntPtr that will be passed
to your icall as the first argument. It can be an
instance ("this" ptr) of a native object, etc.

It's up to you how to handle "context" in the aforementioned
icall.

You could define a native base class "UniversalDelegate"
with a virtual "Handler" method with a signature
more friendly to your framework than
MonoObject*(void *, MonoArray*), etc.


Robert

On 04.03.2016 14:44, Jonathan Mitchell wrote:

Hi

At present I use an InternalCalls for my callbacks and conditional compilation 
(see end) in our cross platform code
In this we assign  a Func directly to an extern static string 
FilePathCallback(string EmployerName);

  In future I would like to support calling methods such as

public CloudClient(Func filePathCallback)

using the Embedded API and cut out the extra plumbing need for InternalCalls.

I have a wooly feel for how I should approach this!
When generating generic types I use a managed helper method.

So I could envisage creating a System.Delegate instance of System.Func.
Then I could set the Target and Method properties - however since I am calling 
back into C there won’t be a Target class.
However System.Delegate is abstract so I would need to sort that out too! - 
presumably this needs to be done dynamically at runtime.

I am aware of the existence of Delegate.CreateDelegate() put that only seems to 
work for instance delegates.

Any insight would be helpful.

Thanks

Jonathan

end
===
public class CloudClient
{
#if TARGET_OSX
[MethodImplAttribute(MethodImplOptions.InternalCall)]
extern static string FilePathCallback(string EmployerName);
#endif
public CloudClient(Func filePathCallback) {

_filePathCallback = filePathCallback;

#if TARGET_OSX
if (_filePathCallback == null) {
_filePathCallback = FilePathCallback;
}
#endif
}

}





___
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] Embedded API: .ctor method signature query [mono]

[Robert Jordan]

Hi Jonathan,

The JIT isn't using these functions for method look-ups.

mono_method_descs are mainly for embedders (and for
trivial method look-ups at some places inside the runtime).

They come handy when you want to get an overloaded
MonoMethod in C/C++:

easy:

desc = mono_method_desc_new (":Method(int, string, int)");
method = mono_method_desc_search_in_class (desc, class);
mono_method_desc_free (desc);

versus hard:

- enum methods with mono_class_get_methods ()
- check method name
- check param count
- check param types
...


If you're generating stubs automatically and don't
have a string description of the methods up front,
the hard way involving mono_class_get_methods () might
be better and faster.

You may want to file a bug, though.

Robert


On 03.03.2016 19:28, Jonathan Mitchell wrote:

HI Robert

Thanks for that.
I think you are right.
I call hundreds of methods that take Obj`1 arguments with out issue but I see that 
I have had to construct a number of helper methods to deal with cases of Obj`2<T, K> 
which failed signature resolution.

I presume that  managed code execution doesn’t involve calls to 
mono_method_desc_new() - are thunks used instead?
One of the difficulties, I find, of working with the embedded API is trying to 
visualise just how a particular managed code statement is implemented within 
the runtime.

I was hoping to be able to call the constructor from C with a pointer to a 
static (MonoString *)fund(MonoString *).
Not sure if that would even fly.

As a work around I will use an internal call.

Shall I log this as a bug and reference this thread?

Thanks a lot for replying.

Jonathan


On 3 Mar 2016, at 18:02, Robert Jordan <robe...@gmx.net> wrote:

On 03.03.2016 14:36, Jonathan Mitchell wrote:

HI

I want to call the following constructor via the embedded API:

public CloudClient(Func<string, string> filePathCallback)

All my other embedded method and constructor calls work okay but there is an issue 
with this one - it is the only place I use a System.Func.
The API reports that a method cannot be found for signature 
.ctor(System.Func`2<string, string>)
When I dump out the class method names I see .ctor(System.Func`2<string, 
string>) listed.

Any ideas on this one?


It looks like a bug in mono_method_desc_new ():

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378

The function is treating

.ctor(System.Func`2<string, string>)

like a method with 2 arguments:

arg0 = System.Func`2

This is obviously wrong :)

The function is then storing the (wrong) argument count
for optimization purposes, and the comparison of methods
is starting to fail:

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L447

Robert





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

Re: [Mono-dev] Embedded API: .ctor method signature query

[Robert Jordan]

On 03.03.2016 14:36, Jonathan Mitchell wrote:

HI

I want to call the following constructor via the embedded API:

public CloudClient(Func filePathCallback)

All my other embedded method and constructor calls work okay but there is an issue 
with this one - it is the only place I use a System.Func.
The API reports that a method cannot be found for signature 
.ctor(System.Func`2)
When I dump out the class method names I see .ctor(System.Func`2) listed.

Any ideas on this one?


It looks like a bug in mono_method_desc_new ():

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378

The function is treating

.ctor(System.Func`2)

like a method with 2 arguments:

arg0 = System.Func`2

This is obviously wrong :)

The function is then storing the (wrong) argument count
for optimization purposes, and the comparison of methods
is starting to fail:

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L447

Robert


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

Re: [Mono-dev] DllMap default architecture for P/Invoke

[Robert Jordan]

On 16.01.2016 14:08, Jason Curl wrote:
>
> How would I handle this scenario within Mono?
>

The dllmap machinery does not probe for target dlls. It performs
a solely textual mapping.

You may want to have different configs with dllmaps for
DEBUG and RELEASE builds.

Robert


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

Re: [Mono-dev] Loading AOT output using mono_domain_assembly_open

[Robert Jordan]

On 14.11.2015 18:13, zebrajap wrote:

Hi,

I am trying to load the .so file generated by AOT.
When the .dll is passed to mono_domain_assembly_open it returns the
assembly. However when I pass the .so path, it returns NULL. Is there a
different API for AOT assembly loading?


You're still supposed to pass the .dll to mono_assembly_open
or to any other API which expects assembly images.

The AOT machinery will load the .so transparently.

Robert


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

Re: [Mono-dev] Problem with custim marshaller on list

[Robert Jordan]

Hey,

On 15.10.2015 18:21, Guillaume wrote:


when I call that method, I have this error:
marshaling type 15 not implemented
* Assertion: should not be reached at marshal.c:1952


The error most likely means that Mono's marshaller does not
support generic types in structures supposed to be used
in p/invoke scenarios, even if you have a custom
marshaller for it.

Try "public object b" in place of "public IList b".

You may also want to file a bug it this feature is supported
on MS.NET but not on Mono.

Robert




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

Re: [Mono-dev] Registry

[Robert Jordan]

On 08.10.2015 10:44, psant...@codicesoftware.com wrote:

Hi there,


Are you trying to run "on mono" or do you mean on mono + linux or mac?


Mono's registry implementation is using native Windows APIs
under Windows, so the concurrency issues Neale was speaking
about do not apply here.

Robert



pablo



On 10/6/2015 23:47, Neale Ferguson wrote:

We have a client who is testing the waters with porting some .NET based
applications to mono. However, a couple of these critical applications
rely on the windows registry. The implementation of registry-support in
mono is quite crude and not process-safe and this is holding them back. I
am looking for ideas as to improving this so that apps can share the
registry safely and efficiently.

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





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




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

Re: [Mono-dev] boehm and pin to sgen and moveable

[Robert Jordan]

Hey Jonathan,

On 03.10.2015 16:25, Jonathan Mitchell wrote:

In my ObjC->Mono bridge I have been using the Boehm collector and pinned memory 
(as an expedient).
I now want to move to SGEN and moveable memory.
As a first step I have switched to SGEN and left pinning enabled.

My ObjC code wraps a MonoObject * in an NSObject.
When the MonoObject is set it is pinned.
A simple monoObjectTrace property watches to see if the MonoObject moves.

Under the Boehm collector objects seem to stay pinned as requested.
Under SGEN they don’t i.e.: the exception in the second method below raises 
i.e.:  self.monoObjectTrace != (NSUInteger)monoObject)

What am I doing wrong?


It depends on how your methods are actually used.

In setMonoObject, there is a time frame between

mono_gchandle_free ()
mono_gchandle_new ()

where the GC might regain control and move the object.

Try to ensure that setMonoObject is called only once for
the same obj, such that mono_gchandle_free () followed
by mono_gchandle_new () isn't needed.

Robert


___
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

[Robert Jordan]

On 01.09.2015 22:04, Edward Ned Harvey (mono) wrote:

The workaround I've found is to create a wrapper class MonoSpecific,
so the if-clause and the Mono.Posix call are not in the same file.
But this is clearly a hack. Is there a better way?


You're depending on undefined behavior. The workaround is only
working because the JIT compiler is lazily compiling methods,
and won't compile DoChmod() under Windows.

You should mark DoChmod() with

[MethodImpl(MethodImplOptions.NoInlining)]

Otherwise the issue might come back unexpectedly.

However, if .NET 5.0 would start to eagerly compile assemblies
(for whatever reason), the issue will come back as well.


A sane and easy solution is to deploy Mono.Posing on Windows side-by-
side with you app.

Even when running on Mono, Mono.Posix should be picked up
from the GAC. Your copy won't be loaded anyway.

The super-sane solution is to abstract these calls away using a
factory and 2 assemblies, one for Windows and one for Mono
which has Mono.Posix as a reference.

Robert

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

Re: [Mono-dev] Invoking .net interface method from c api

[Robert Jordan]

On 21.08.2015 11:43, zebrajap wrote:

Oh. I got your point.

The build output have System.dll in multiple places.

./lib/mono/2.0/System.dll
./lib/mono/4.5/System.dll
*./lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll*
./lib/mono/4.0/System.dll

I was loading it from ./lib/mono/4.0/System.dll. I am loading it as follows.

mono_set_dirs(Build Path/lib, Build Path/etc);
pDomain = mono_jit_init_version(BuildDomain, v4.0.30319 ); // Init 
the
JIT Engine
mono_config_parse(NULL);

MonoAssembly* pSystemAssembly = mono_domain_assembly_open (pDomain, 
Build
Path/lib/mono/4.0/System.dll);
pSystemImage = mono_assembly_get_image (pSystemAssembly);

The file in gac seems to have the implementation.
How to make it load from gac without providing absolute path? Please note
that I cannot install it here.



Use one of the mono_assembly_load_*() functions because they
are obeying the usual CLR assembly binding rules (those rules C#
programmers are used to).


A good start is mono_assembly_load_with_partial_name () which
can be as simple as:

MonoImageOpenStatus status;
asm = mono_assembly_load_with_partial_name(System, status);

Robert


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

Re: [Mono-dev] Invoking .net interface method from c api

[Robert Jordan]

On 21.08.2015 06:44, zebrajap wrote:

Now I am getting a different error.

104 MonoObject* pIcc = mono_runtime_invoke(pMethodCreateCompiler,
pCodeProvider, NULL, NULL);
(gdb) p pMethodCreateCompiler
$1 = (MonoMethod *) 0x6aa288
(gdb) n

Unhandled Exception:
System.InvalidProgramException: Invalid IL code in
Microsoft.CSharp.CSharpCodeProvider:CreateCompiler (): IL_: ret

[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidProgramException: Invalid
IL code in Microsoft.CSharp.CSharpCodeProvider:CreateCompiler (): IL_:
ret

So I opened mono/4.0/System.dll using ILSpy. There, all the methods seems to
have empty body with single instruction.
http://mono.1490590.n4.nabble.com/file/n4666512/IlSpy.png

What could be the issue ?



It looks like you are tying to execute a reference assembly.
These are stripped off of method bodies.

How do you load System.dll?

Robert


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

Re: [Mono-dev] Invoking .net interface method from c api

[Robert Jordan]

On 20.08.2015 11:17, zebrajap wrote:

The build machine does not have mono installed. So I have copied the dlls
from another similar machine to
/home/sameeraj/assemblies/mono/1.0/. (I am not sure why I had to copy in to
mono/1.0 but if I don't when the program runs it complains mscorlib should
be in that folder.)

mono_set_dirs(/home/sameeraj/assemblies, .);
pDomain = mono_jit_init (BuildDomain);

MonoAssembly* pSystemAssembly = mono_domain_assembly_open (pDomain,
/home/sameeraj/assemblies/mono/1.0/System.dll);
pSystemImage = mono_assembly_get_image (pSystemAssembly);

MonoAssembly* pMscorlibAssembly = mono_domain_assembly_open (pDomain,
/home/sameeraj/assemblies/mono/1.0/mscorlib.dll);
pMscorlibImage = mono_assembly_get_image (pMscorlibAssembly);

Thanks.



Wow, I'm sensing a couple of issues here :)

1) your Mono is old. The 1.0 profile has been phased out a couple
of years ago.

2) the directory layout you're passing to mono_set_dirs
is most likely incorrect. Both dirs must contain a directory
mono with the contents taken from a full Mono installation
($prefix/lib/mono and $prefix/etc/mono).

3) the CodeDomProvider is necessitating even more of a Mono installation
because it must be able to invoke the C# compiler (mcs). Step (2)
is enough for this, though.

4) for complex things like CodeDomProvider you're supposed to
initially mono_jit_exec() an assembly that implements an entry
point (static void Main()).


Please do yourself a favor and start developing on a machine
with a full (and fresh) Mono.

Robert


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

Re: [Mono-dev] Invoking .net interface method from c api

[Robert Jordan]

On 19.08.2015 17:31, zebrajap wrote:

Thanks Robert.
It still does not work. Was it working in your case ? Now I begin to wonder
if there are any issues with my system


Please show us the code where you're initializing the runtime.

Robert


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

Re: [Mono-dev] Invoking .net interface method from c api

[Robert Jordan]

On 19.08.2015 08:39, zebrajap wrote:


This code fails at MonoObject* pIcc =
mono_runtime_invoke(pMethodCreateCompiler, pCodeProvider, NULL, NULL); line.
What am I doing wrong.




You're supposed to call mono_object_get_virtual_method () on the
interface method prior to invoking it on a derived class:

pMethodCreateCompiler = mono_object_get_virtual_method(pCodeProvider,
  pMethodCreateCompiler);
mono_runtime_invoke(pMethodCreateCompiler, pCodeProvider, NULL, NULL);



Robert


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

Re: [Mono-dev] Embedded mono crash on exception

[Robert Jordan]

On 06.08.2015 08:12, Trigve wrote:

I'm using embedded mono (using unity) in C++ DLL. I'm calling some managed
functions using mono_runtime_invoke(). The function does throw an exception,
which I caught with the MonoException argument. Then I want to unwind stack
(in C++) so I throw my custom exception. But application crashes at address
 (last function on the stack is ExecuteHandler2@20()). So it looks
like some exception handler is set pointing to the NULL.



I'm pasting this from the Nabble Forum because it didn't make
into the mail:


First-chance exception at 0x7548C42D in Unity.exe: Microsoft C++ exception: 
ExceptionAlreadySet at memory location 0x0028D63C.

First-chance exception at 0x in Unity.exe: 0xC005: Access violation 
executing location 0x.


Not sure about Unity's Mono (it's a customized version) but
First-chance exception at 0x is usually not an error,
at least not in the old Mono version Unity is using.

This exception is an artifact of Mono's NullReferenceException handling.
You are supposed to ignore it.

Robert



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

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

[Robert Jordan]

On 15.03.2015 10:59, Nirmal Lankathilaka wrote:

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

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

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


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

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

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

The target is here emscripten/asm.js, so it needs a port.

mono cross compiler that can target emscripten
is a Mono LLVM AOT target that generates LLVM code suitable
for emscripten. This part is supposed to run on the host, i.e.
it has access to a full tool chain etc.



On a different note, could you explain to me whether I should use the
forums instead of the mailing-lists (which I prefer) for communication
regarding GSoC and the `asm.js` port.


The forums are just a mirror of this list.

Robert


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

Re: [Mono-dev] What will happen if Dispose() hangs?

[Robert Jordan]

On 27.01.2015 18:56, Edward Ned Harvey (mono) wrote:

From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
boun...@lists.ximian.com] On Behalf Of Robert Jordan

You may want to look up how a sane IDisposable pattern has to be
sensibly implemented in .NET. You'll find out that Dispose()
shouldn't be called from a finalizer.


Uhmm...  You got that wrong.  Here is the recommended pattern:
https://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.110).aspx

Basically, *always* call Dispose(false) from the finalizer, if present, but 
avoid having a finalizer unless you need one.


That's Dispose(bool). I was speaking about Dispose().


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

Re: [Mono-dev] What will happen if Dispose() hangs?

[Robert Jordan]

On 27.01.2015 15:46, Edward Ned Harvey (mono) wrote:


The question still stands about what happens if Dispose() hangs during garbage 
collection...



You may want to look up how a sane IDisposable pattern has to be 
sensibly implemented in .NET. You'll find out that Dispose()

shouldn't be called from a finalizer.

A blocking finalizer will hang the GC, but it looks like SslStream is
implementing finalization correctly:

https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.Security/SslStream.cs#L516

https://github.com/mono/mono/blob/master/mcs/class/System/System.Net.Security/AuthenticatedStream.cs#L78

Robert


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

Re: [Mono-dev] monolite URL

[Robert Jordan]

On 11.12.2014 07:33, Alex J Lennon wrote:

The thing to keep in mind is that the corlib version inside monolite
needs to match the runtime version or bootstrapping the classlib build
won't work, so you can't just keep an old monolite and use it to build
newer Mono (at least that's how I understood it).



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


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

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

Robert


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

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

[Robert Jordan]

On 27.11.2014 19:19, Alexander Köplinger wrote:

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


It doesn't make sense to us, but removing them would just break
thinks downstream.

It's really annoying when such changes are done just for the
sake of OCD, so please stop this.


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

Re: [Mono-dev] .NET Reference source terminology

[Robert Jordan]

On 23.11.2014 12:57, Martin Thwaites wrote:

Hi All,

Has anyone got any idea what FEATURE_PAL is?

It's a define, and seems to have a lot of comments around IIS, and that if
it's Enabled, then don't do IIS stuff.  Seems like something that we could
just add in our stuff to exclude alot of windows specific stuff without
having to add our own defines?

e.g.
https://github.com/Microsoft/referencesource/blob/fa352bbcac7dd189f66546297afaffc98f6a7d15/System.Web/HttpRuntime.cs#L139

The best explanation I've seen says it's the Platform Adaptation Layer,
and is to do with compiling it for other architectures such as ARM.  Seems
like something that we would want to enable?



There is a ROTORTODO comment inside a FEATURE_PAL block:

https://github.com/Microsoft/referencesource/blob/fa352bbcac7dd189f66546297afaffc98f6a7d15/System.Web/HttpRuntime.cs#L304

Rotor: 
http://en.wikipedia.org/wiki/Shared_Source_Common_Language_Infrastructure


PAL: Platform Abstraction Layer.

So it probably makes sense to enable (or to look closely at)
FEATURE_PAL when compiling for Mono.

Robert


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

Re: [Mono-dev] Webapp stuck with Key duplication when adding: httpModules

[Robert Jordan]

On 23.10.2014 13:25, Etienne Champetier wrote:

After some more investigation, reading many lines of code with a collegue,
we came to the conclusion that this exception is impossible :)
(yet the web is stuck on it)


Are you sure that this NameObjectCollection isn't mistakenly accessed
from  multiple threads?

Look System.Web.Configuration.WebConfigurationManager.GetSection
all the way up the stacktrace. There are several scary parts that
deal with locking.

Robert




m_ItemsContainer is an hashtable, and a private field of
NameObjectCollectionBase
class (new HashTable(0,StringComparer.Ordinal)).
The exception tell us that there is already a key 'httpModules' in
m_ItemsContainer.
Reading the code the only way we go from BaseSet to BaseAdd is if
FindFirstMatchedItem('httpModules'), so if (_Item)m_ItemsContainer[
'httpModules'] is null,
so if the value is null (the key exists, we got an exception to prove it :))

if i'm right, we are sure that we have ('httpModules',null) in
m_ItemsContainer.


Now m_ItemsContainer only modifications are:
0) m_ItemsContainer = new Hashtable (m_defCapacity, equality_comparer);

1) m_ItemsContainer.Clear ();

2) _Item newitem=new _Item(name, value);
m_ItemsContainer.Add(name,newitem);

3) m_ItemsContainer.Remove(name);

So there is no way there is ('httpModules',null) in m_ItemsContainer


Please someone tell me where i'm wrong

https://github.com/mono/mono/blob/master/mcs/class/System/System.Collections.Specialized/NameObjectCollectionBase.cs

Thanks
Etienne


2014-10-21 14:54 GMT+02:00 Etienne Champetier champetier.etie...@gmail.com
:


Hi,

At my firm we are running multiple webapplication using mono (nginx +
fastcgi-mono-server2.exe) on a cluster of 4 VM, 2 vcpus.
One of them is restarted every day at 1h45 (small memory leak).
3 weeks ago we went from 8VM with 1vcpu (no restart problem) to 4VM with
2vcpus, and now,
it's the 3rd time in 2 weeks that on one VM, the restart doesn't work well
and we have:

[System.ArgumentException]: Key duplication when adding: httpModules
   at System.Collections.Hashtable.PutImpl (System.Object key,
System.Object value, Boolean overwrite) [0x0] in filename unknown:0
   at System.Collections.Hashtable.Add (System.Object key, System.Object
value) [0x0] in filename unknown:0
   at System.Collections.Specialized.NameObjectCollectionBase.BaseAdd
(System.String name, System.Object value) [0x0] in filename unknown:0
   at System.Collections.Specialized.NameObjectCollectionBase.BaseSet
(System.String name, System.Object value) [0x0] in filename unknown:0
   at System.Configuration.ConfigurationSectionCollection.get_Item
(System.String name) [0x0] in filename unknown:0
   at System.Configuration.Configuration.GetSection (System.String path)
[0x0] in filename unknown:0
   at System.Web.Configuration.WebConfigurationManager.GetSection
(System.String sectionName, System.String path, System.Web.HttpContext
context) [0x0] in filename unknown:0
   at System.Web.Configuration.WebConfigurationManager.GetSection
(System.String sectionName, System.String path) [0x0] in filename
unknown:0
   at
System.Web.Configuration.WebConfigurationManager.GetWebApplicationSection
(System.String sectionName) [0x0] in filename unknown:0
   at System.Web.HttpApplication.InitOnce (Boolean full_init) [0x0] in
filename unknown:0


The really cool stuff is that even if it's a 500 error, the returned http
code is 200 :)

I've already checked and all files are equal (dll, exe, conf), all VM conf
are equal (vcpu, memory, ...), ...

I'm not able to reproduce the bug (restart under high load (ab -c 50 -n
10)) so can't tell if the bug is there in the newest version.

We are using a version of mono before 3.2.7
(92887027be801b012846866208e6b4e362a4fc24) and fastcgi-mono-server2 (xsp)
version 2.10.2-1 (old version build on 14/09/12 by someone at my firm)
I know we are using old version but it seems that the bug is still there:
https://bugzilla.xamarin.com/show_bug.cgi?id=18303

I've run lsof on the processes (the stuck one and one working), and by
comparing the 2, i see that App_global.asax_XXX.dll
is here in both case, but not  App_Web_.dll (only on the working
one) (see attachment)

I have root access on the VM with the stuck process, and i'm on irc right
now (champtar), so if you have some ideas to gather more info to kill this
bug

Thanks in advance

Etienne





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

[Robert Jordan]

On 21.10.2014 13:05, Edward Ned Harvey (mono) wrote:

From: Miguel de Icaza [mailto:mig...@xamarin.com]

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

Pull requests do not work well with Mono.   They need to be
discussed in the mailing list


Did I miss something?  Do you not recognize that there's a problem
here?

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


Please do not intermix the expectations/entitlements you've got for
being a paying customer of Xamarin with their Open Source efforts.

As long as the community isn't moving (or even fork, as a last resort)
things won't change substantially. Miguel has clearly stated
multiple times that there is enough room for involvement in some
areas (e.g. Server Stack), even commercially. I haven't seen anyone
stepping up so far, at least not here.

A few pull requests are not enough to show commitment and to take
ownership over a module/subsystem/whatever. Hackers are coming
and going, code is rotting away, Xamarin is collecting the garbage.
I guess they are tired of this ;)

On pull request discussions on this list: Assuming that core
devs are rather monitoring this list (I hope it's still the case),
I'd prefer this approach anytime to the discussion over at GitHub.
I've given up on reviewing because of this `media switch'.

Robert

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

Re: [Mono-dev] Resx files in Mono

[Robert Jordan]

On 08.10.2014 23:05, Martin Thwaites wrote:


I've tried adding a reference to it, and I can't find that assembly, even
in the mono directories.

So the question is, does compiling Resx files work in mono?



It does.

The long story: Microsoft has implemented the ResX support in
the System.Windows.Forms assembly (a GUI library) and reused
it from System.Web.

For compatibility reasons, Mono did the same (Mono's
System.Windows.Forms can be found in the Native.Windows.Forms
directory side-by-side with System.Web inside mcs/class).

However, since System.Windows.Forms is kinda unsupported
and deprecated under Mono, the team has begun including
the ResX source code directly into System.Web:

https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web.dll.sources


What you can do is:

- install System.Windows.Forms. It's usually part of Mono
but your disto might have split it into its own package.

- build your aspnet update inside Mono mcs/class tree while
reusing the build infrastructure. Look at how Mono's System.Web
is built.

Robert


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

Re: [Mono-dev] mono_fntptr_to_delegate

[Robert Jordan]

Bruno,

Marshal.GetDelegateFromFunctionPointer() and mono_ftnptr_to_delegate
only work on functions with p/invoke-compatible signatures.

This means that you can't pass MonoObjects* to these functions.
You can only declare and pass p/invoke-compatible arguments.
There is also no *this* pointer available.

If you want a signature like this

MonoBoolean testMethod(MonoString *arg2)

then you must declare a C# helper for it:

namespace EmbeddingHelpers
{
class DelegateHelper
{
public static Funcstring, bool CreateDelegate()
{
return TestMethod;
}

[MethodImpl(MethodImplOptions.InternalCall)]
static bool extern TestMethod(string arg);
}
}

C++:

MonoBoolean TestMethodInternal(MonoString* arg)
{
return TRUE;
}

mono_add_internal_call(EmbeddingHelpers.DelegateHelper::TestMethod);



The delegate can be finally obtained from the static method
EmbeddingHelpers.DelegateHelper.CreateDelegate();

There might be better/elegant ways to do this, but they all
need an InternalCall declaration. There is no other way to tell
mono to wrap a native function to support native (embedded mono)
calls.


Robert

On 08.08.2014 19:29, Bruno Lauze wrote:

Hi,



I am sure someone can help me out. At one point this code did work. I
changed something and/or I just reinstalled latest trunk and it broke.

I am trying to pass C delegate to C#. Everything is working C# is calling
back the method but the parameters seems to be invalid pointers.

The C delegate was returning the delegate object, and the parameters.



I did put mono_ftnptr_to_delegate to external removing MONO_INTERNAL and
placing it under MONO_API.

One could use Marshal.GetDelegateFromPointer with mono_runtime_invoke
(Adding that way too at the bottom.)





Consider the following code:





DelegateHelper.dll: MyClass.cs:



using System;



namespace DelegateHelper

{

 public delegate bool TestDelegate(string arg1);



 public class MyClass

 {

 public static bool Test(TestDelegate predicate)

 {

 return predicate(TEST);

 }

 }

}





main.c:





#include stdio.h

#include glib.h

#include mono/jit/jit.h

#include mono/metadata/object.h

#include mono/metadata/reflection.h

#include mono/metadata/assembly.h

#include mono/metadata/threads.h

#include mono/metadata/mono-config.h



MONO_API MonoDelegate*

mono_ftnptr_to_delegate (MonoClass *klass, gpointer ftn);



MonoBoolean testMethod(MonoObject *arg1, MonoObject *arg2)

{

 printf(Calling delegate!);

 MonoString *str = mono_object_to_string(arg2, NULL); //crash

 return TRUE;

}



int main (int argc, char *argv[])

{

 printf (Delegate Test!\n);



 MonoDomain *domain = mono_jit_init_version(DelegateTest,
v4.0.30319);

 mono_config_parse(NULL);

 void *__parameters__[1];

 MonoAssembly *ass = mono_assembly_open(DelegateHelper.dll, NULL);

 MonoImage *image = mono_assembly_get_image(ass);

 MonoClass *delegateClass = mono_class_from_name(image,
DelegateHelper, TestDelegate);

 mono_class_init(delegateClass);

 MonoClass *testClass = mono_class_from_name(image, DelegateHelper,
MyClass);

 mono_class_init(testClass);

 gpointer ptr = (gpointer)testMethod;

 MonoDelegate *delegateObj = mono_ftnptr_to_delegate(delegateClass,
ptr); //Short way to call Marshal.GetDelegateFromFunctionPointer()

 MonoMethod *testMethod = mono_class_get_method_from_name(testClass,
Test, 1);

 __parameters__[0] = delegateObj;

 MonoObject *result = mono_runtime_invoke(testMethod, NULL,
__parameters__, NULL);

 return 0;

}





Result:



Delegate Test!

Calling delegate!

Stacktrace:



   at unknown 0x

   at (wrapper managed-to-native) object.wrapper_native_0x40ea40 ()
0x

   at DelegateHelper.MyClass.Test (System.Func`2string, bool) 0x00018

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



=

Got a SIGSEGV while executing native code. This usually indicates

a fatal error in the mono runtime or one of the native libraries

used by your application.

=



Abort





This code could be used instead of mono_ftnptr_to_delegate which is normally
internal



 /*

 MonoImage *mscorlib =
mono_assembly_get_image(mono_domain_assembly_open(domain, mscorlib));

 MonoClass *marshal = mono_class_from_name(mscorlib,
System.Runtime.InteropServices, Marshal);

 MonoMethod *getDelegate = mono_class_get_method_from_name(marshal,
GetDelegateForFunctionPointer, 2);

 void *marshal_params[2];

 marshal_params[0] = ptr;

  

Re: [Mono-dev] Developing Mono

[Robert Jordan]

On 14.05.2014 00:55, Martin Thwaites wrote:

So I've given in, and I'm now looking at using linux (ubuntu 14.04) to try
and add some things to mono.

I have the same issues with loading the net_4_5.sln file in MD as I do in
VS, in that it won't compile.  I'm assuming that the solution itself is
just broken.

The main issue though is I've not found anything that could show me some
simple steps to how I should go about building and running tests.


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

Robert


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

Re: [Mono-dev] .exe referencing itself ...

[Robert Jordan]

On 10.04.2014 13:59, etienne.champet...@free.fr wrote:


It's looking for itself ...
If I put it in the gac, it works, but is there a way to not put it in the gac?

I'm building it with xbuild /p:Configuration=Release /target:rebuild,
but it's the same with the Makefile (make install install it in the gac)


This is by design of System.Web. All assemblies a web app is referencing
must be either located in the GAC or in the bin directory of the
web app.

So you can copy (not move, as it must exit twice) this DLL into
bin directory of the web app.

Robert


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

Re: [Mono-dev] .exe referencing itself ...

[Robert Jordan]

On 10.04.2014 15:03, Robert Jordan wrote:

On 10.04.2014 13:59, etienne.champet...@free.fr wrote:


It's looking for itself ...
If I put it in the gac, it works, but is there a way to not put it in
the gac?

I'm building it with xbuild /p:Configuration=Release /target:rebuild,
but it's the same with the Makefile (make install install it in the gac)


This is by design of System.Web. All assemblies a web app is referencing
must be either located in the GAC or in the bin directory of the
web app.

So you can copy (not move, as it must exit twice) this DLL into
bin directory of the web app.


s/DLL/exe/

Robert


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

Re: [Mono-dev] ***UNCHECKED*** Re: Ongoing Mono development / Mono roadmap

[Robert Jordan]

On 09.04.2014 23:17, Alex J Lennon wrote:


A key component of what I was told toay is that Xamarin are unable to
work on Mono due to contractual obligations to Attachmate. As a
result they are (I am told) abandoning Mono and doing something
else which is the (presumably) VM underneath the Xamarin tooling.

I guess I'm looking for confirmation that either this is true, or
is some strange new form of FUD :) This comes from a discussion which
was originally about Microsoft open sourcing (ish, bits of) .Net.


The story you were told is incomplete. It turned out well:

http://tirania.org/blog/archive/2011/Dec-21.html
http://www.itworld.com/mobile-wireless/184215/xamarin-attachmate-band-together-mono

Robert


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

Re: [Mono-dev] Library path bug in Makefile?

[Robert Jordan]

On 05.03.2014 15:31, Edward Ned Harvey (mono) wrote:

It is a safe conclusion to draw, that *whatever* is specified by
--libdir=DIR, the binary should be linked against libraries in that
directory.  (If not specified, libdir is derived from
--exec-prefix=EPREFIX, which is derived from --prefix=PREFIX)


Non-default Mono installations still need LD_LIBRARY_PATH, otherwise
p/invoke of Mono libraries (libgdiplus, libMonoPosixHelper) won't
work because p/invoke is obeying the CLR rules of library look-up
that know nothing about ELF RPATH attributes.

Moreover, things like pkg-config need to be configured as well,
because they also know nothing about mono's executable RPATH.

The only thing you'd achieve by setting the RPATH attribute:
you won't be able to safely relocate Mono anymore, as RPATH
takes precedence over LD_LIBRARY_PATH.

Robert

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

Re: [Mono-dev] Strange Crash with mono-3.2.3 + Qt-5.2.1

[Robert Jordan]

On 14.02.2014 21:35, Frank Fuchs wrote:

I first noticed with my Qt based application and a 64 bit build of
mono-3.2.3. However, I confirmed the very same problem with the offical
binary releases fo Qt-5.2.1 (mingw) and mono-3.2.3.

An application which embedds mono and initializes the runtime (which passes
without problems) like

mono_set_dirs(libs,etc);
domain = mono_jit_init (test);  

will crash upon opening a Qt file dialog. gdb reports the crash to occur in
rpcrt4.dll RpcCompleteAndFree (32 bit) and RpcEpRegisterNoReplaceW (64bit).
I'm not sure if this is any helpfull.

If there's something more you need to trace this problem, let me know how I
can help.


This looks like a COM problem to me (rpcrt4.dll does COM marshaling).

Odds are that Qt's file dialog is needing an STA (single thread
apartment) because it's somehow interacting with the Windows shell.

By default, Mono (and MS.NET) is initializing COM for multithreaded
concurrency (MTA) which may interact badly with STA COM objects
used by the Windows shell.

You may want to try to add an [STAThread] attribute to your Main
C# method.

Robert


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

Re: [Mono-dev] Windows.Forms broken on Windows

[Robert Jordan]

On 01.02.2014 20:27, Frank Fuchs wrote:

The offical mono-package (32 bit for Windows) from mono-project.com seem
broken when it comes to Windows.Form apps. I tested the following for
mono-3.0.10 and mono-3.2.3, with Windows 7 Professional 64bit.


using System;
using System.Windows.Forms;
class Hello{
static public void Main(){
MessageBox.Show(Hello World);
  }
}


and build  run it like:

./bin/mono.exe lib/mono/4.5/mcs.exe test.cs
-r:lib/mono/4.5/System.Windows.Forms.dll
./bin/mono.exe test.exe


This is caused by a wrong dll-map:

dllmap dll=gdiplus target=@prefix@/lib/libgdiplus@libsuffix@ /
dllmap dll=gdiplus.dll target=@prefix@/lib/libgdiplus@libsuffix@ /

in $prefix/etc/mono/config.

It should read

dllmap dll=gdiplus target=@prefix@/lib/libgdiplus@libsuffix@ 
os=!windows /
dllmap dll=gdiplus.dll target=@prefix@/lib/libgdiplus@libsuffix@ 
os=!windows  /


Robert


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

Re: [Mono-dev] Windows.Forms broken on Windows

[Robert Jordan]

On 02.02.2014 15:12, Robert Jordan wrote:

This is caused by a wrong dll-map:

dllmap dll=gdiplus target=@prefix@/lib/libgdiplus@libsuffix@ /
dllmap dll=gdiplus.dll target=@prefix@/lib/libgdiplus@libsuffix@ /

in $prefix/etc/mono/config.

It should read

dllmap dll=gdiplus target=@prefix@/lib/libgdiplus@libsuffix@
os=!windows /
dllmap dll=gdiplus.dll target=@prefix@/lib/libgdiplus@libsuffix@
os=!windows  /


And it's already fixed on master:

https://github.com/mono/mono/blob/master/data/config.in

Robert


___
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

[Robert Jordan]

On 31.12.2013 10:34, mobin.seven wrote:

Same here! Did you solve it?

ralphbariz wrote

Hi,

I'm trying to compile a static one binary mono(Because the target system
has an incompatible loader).
First I got mono to build statically, but without libMonoPosixHelper in
the archive. After a few tries, I got also this, changed all
DllImport(MPH) calls in Mono.Posix.dll to DllImport(__Internal), it
still gives me a TypeInitializationexception when I try to access the stat
symbol of the libMonoPosixHelper. With objdump I looked inside, the
symbols of libMonoPosixHelper are all inside the archive, so what am I
doing wrong?


Your custom loader is supposed to support dlopen(NULL) and
your linker must be able to export public symbols.
See ld's --export-dynamic option.


Robert


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

Re: [Mono-dev] Socket.IsBound wrong behavior

[Robert Jordan]

On 12.11.2013 11:29, Stifu wrote:

Yeah, sometimes classes are in unexpected folders.
Socket isn't under System.Net, but just System, for some reason.


The reason is that Socket is implemented in the System assembly.

$(Assembly)/$(Namespace)/$(Class).cs

=

System/System.Net.Sockets/Socket.cs

Robert


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

Re: [Mono-dev] mono mkbundle made file is Not working

[Robert Jordan]

On 03.11.2013 08:58, mobin.seven wrote:

I tried to bundle my app with mkbundle command due to this help:

http://www.mono-project.com/Guide:Running_Mono_Applications#Bundles
http://www.mono-project.com/Guide:Running_Mono_Applications#Bundles

but I don't understand this part of this doc:
With -c, the further option --nomain will generate the host.c file without
a main method so that you can embed it as a library in an existing native
application in which you are embedding the Mono runtime yourself. Just call
mono_mkbundle_init() before initializing the JIT to make the bundled
assemblies available.


This option is only useful if you want to link the bundle
with your own native application. Do you want this?


I have bundled an exe with all of its deps in Ubuntu via 'mkbundle' and it
works well there but when I move the bundle to lubuntu it won't work! when
executes nothing happens!
What should I do?


Mkbundle does not bundle native deps, e.g. GTK#, libgdiplus + its
myriad of deps. What kind of application are you trying to bundle?
GUI? Console?


Robert


___
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 DateTime.Now.IsDaylightSavingTime() returns false when it should be true.

[Robert Jordan]

On 28.10.2013 07:35, Alistair Bush wrote:

I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.


Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.

The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.

To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.

Maybe this:

is_daylight = start.tm_isdst  0;

just before

/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day  365; day++) {

Robert


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

Re: [Mono-dev] Embedded API: mono_array_element_size issue

[Robert Jordan]

Jonathan,

On 02.10.2013 12:21, jonat...@mugginsoft.com wrote:

The following raises so I presume that I have used it incorrectly:

 MonoClass *arrayClass = mono_get_byte_class();
 int32_t elementSize = mono_array_element_size(arrayClass);

* Assertion at class.c:8201, condition `ac-rank' not met



This is because arrayClass is not the MonoClass of a MonoArray.

You need something like that:

// assign the mono array
uintptr_t byteLength = [self length];
MonoArray *monoArray = mono_array_new(mono_domain_get(), 
mono_get_byte_class(), byteLength);
int32_t elementSize = 
mono_array_element_size(mono_object_get_class((MonoObject*)monoArray);


Robert


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

Re: [Mono-dev] Help with xsp

[Robert Jordan]

Neale,

On 18.09.2013 00:19, Neale Ferguson wrote:

I had a webservice that was working fine. I duplicated a routine - same name
but with different parameters which requires the MessageName attribute. So
for the duplicated routine which originally just had:
 [WebMethod (Description=Process VMARCH QUERY TAPES ALL
command)]
I changed it to
 [WebMethod (Description=Process VMARCH QUERY TAPES ALL
command,
 MessageName=vmaQryTapesAll)]

Pointed browser to: http://localhost:9000/webservice.asmx and now get:

System.ArgumentOutOfRangeException
Argument is out of range.

Is there some way to get more informative messages from xsp to get it to
tell me exactly what it's choking on? I can invoke the webmethods directly
on the browser but it's just this bit that is giving me grief.


The Web Service overview and test page is generated by
$prefix/etc/mono/x.x/DefaultWsdlHelpGenerator.aspx,
where x.x is the .NET version.

It looks like the exception is thrown when Page_Load of this
ASPX page is invoking WebServicesInteroperability.CheckConformance.

That's where I would start looking for issue with overloaded
WebMethods following back the stack trace.

Try to get line numbers with

MONO_OPTIONS=--debug xsp ...

Robert



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

Re: [Mono-dev] GAC on Mac

[Robert Jordan]

On 16.09.2013 20:29, Vassil Vassilev wrote:

Hi,
   Sorry if this is the wrong mailing list.
   I am trying to compile a simple cs file with using gtk-sharp library.
It looks like that the compiler doesn't look at the 'right' place. Any
ideas are very welcome, because I am stuck with that for quite a while...



The compiler (neither mcs nor csc) is never resolving assemblies
using the GAC. This means that you have to explicitly specify
all assemblies (except system assemblies) using their path.

Mcs/dmcs is also supporting pgk-config files (-pkg option),
but I cant tell you how the GTK pkg-config is called.
Maybe -pkg:gtk-sharp-2.0

Robert



   I have this problem:
cat /tmp/t.cs
using Gtk;

namespace Test {
   class Program {
 void f() {
   Gtk.Label l = new Gtk.Label(aa);
 }
   }
}

/usr/bin/dmcs /t:library /out:SolidV.dll /platform:anycpu /debug:full
/debug+ /optimize- /sdk:4  /tmp/t.cs /reference:System.dll
/reference:gtk-sharp.dll
error CS0006: Metadata file `gtk-sharp.dll' could not be found
Compilation failed: 1 error(s), 0 warnings




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

Re: [Mono-dev] mono from git will not build on cygwin 32

[Robert Jordan]

On 05.09.2013 00:36, Bryan Crotaz wrote:

After ./autogen.sh ...

I get:

Running ./configure --enable-maintainer-mode --enable-compile-warnings
--host=i686-pc-mingw32 --profile=/cygdrive/c/mono ...
configure: error: unrecognized option: `--profile=/cygdrive/c/mono'
Try `./configure --help' for more information


Profile? You want `--prefix'.

Robert


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

Re: [Mono-dev] MonoProperty and generic types

[Robert Jordan]

Hi,

On 23.07.2013 13:27, Bartosz Przygoda wrote:

Hello,

I'm obtaining the *Capacity *property from the *ListT* class:

 class_ = mono_class_from_name(image, System.Collections.Generic,
List`1);
 _Capacity = mono_class_get_property_from_name(list, Capacity);



This isn't supported. Only constructed generic classes (e.g. Listint)
are fully accessible by the embedded API.

Robert

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

Re: [Mono-dev] MonoListWrapper WIP - code review/feedback

[Robert Jordan]

On 20.07.2013 12:03, rf...@tbrf.net wrote:

2) Using mono_class_get_generic_class(),
mono_generic_class_get_context(), and the MonoGenericContext structure
to retrieve the ListT generic type argument:

I can't find any public API for retrieving info about a generic
instantiation. There's a couple of methods for checking whether
something *is* inflated, but nothing for retrieving or working with the
MonoGenericContext that it was inflated *with*. So I'm not sure what to
change this to. Any suggestions?


This is no public API for this, but you can always use the
managed reflection API:

1) get the MonoReflectionType* (the unmanaged representation of
  a System.Type object) of the MonoType* of the class using
  mono_type_get_object

2) invoke Type.GenericArguments() on this MonoReflectionType*.

Unfortunately, you'll hit the next read block after (2). There is
no public way to get a MonoType* from MonoReflectionType*, so you
have to implement a C# helper for (2):

/*
 * gets the MonoTypes* of the generic arguments of the specified Type.
 */
static IntPtr[] GenericArguments(Type type)
{
/* FIXME: check that type is a closed generic type */
var types = t.GetGenericArguments(type);
var handles = new IntPtr[types.Length];
for (int i = 0; i  types.Length; i++)
handles [i] = types[i].TypeHandle.Value;
return handles;
}



But, according to 
https://github.com/richard-fine/mono/blob/MonoListWrapper/contrib/MonoListWrapper/MonoListWrapper.c#L34

it looks like you don't need this stuff at all :)

You can obtain the element class of the array (the elementType of
your wrapper) with mono_class_get_element_class () invoked
on the class of the _items field of the ListT in question.

Robert

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

Re: [Mono-dev] MonoListWrapper WIP - code review/feedback

[Robert Jordan]

Hi,

On 18.07.2013 19:16, rf...@tbrf.net wrote:

I've been working on a little wrapper library for working with
System.Collections.Generic.ListT instances from native code. The
motivation is to provide a way for Mono embedders to easily design APIs
that use ListT instances as output buffers, whilst running as quickly
as possible and with minimal allocations. Presently I'm getting around a
30x speedup for bulk loading a chunk of data, compared to allocating a
new array to return that data in. Particular users I envision for this
are game engines like Unity3D.

Any chance I could get a review of what I've done so far? It's just a
couple of files, plus a short readme:

https://github.com/richard-fine/mono/tree/MonoListWrapper/contrib/MonoListWrapper


I'm interested in any there's a better way to do this observations,
suggestions for things I should add, ways to speed up the new-array
cases, bugs you can spot, or any generally un-Mono things about it.


Although I understand your motivation, I find that you're
exposing/using too much internals to make this wrapper
ready for public consumption with an unchanged Mono runtime.

You seem to have exposed mono/class-internals.h, which is
a no-go. Also, poking into ListT internals isn't quite
safe, as there is no written contract between runtime and BCL
regarding ListT.

It would be safer if you'd copy and rename ListT and provide
it together with your MonoListWrapper implementation.

Also, there are public mono_array_* macros that
you can use for accessing MonoArray* elements. You can still
use them unsafely (like taking the address of the first element
and access elements using pointer arithmetic) but at least
it won't poke into too much internals.

Robert

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

Re: [Mono-dev] What is the best practice for disposing of transient MonoObject in an embedding scenario

[Robert Jordan]

On 16.06.2013 13:21, jean-michel.perr...@csiro.au wrote:

Hi,

I'd like some guidance on how to free memory in an embedded Mono
scenario.

I 'monkeyed' a few things started from the embedded samples in the
mono codebase, but they are limited to g_free calls on UTF8 strings.
I think I figured out I needed to use mono_gchandle_new and
mono_gchandle_free to 'pin' (resp. 'free') MonoObject from the
embedding application when they re not in use anymore outside of the
CLR. Nevertheless the fate of transient objects is a bit of a
mystery.

Say I have a C# function: public static object CreateInstance(string
typename, object[] ctorArgs)

Which I am calling from C with the code below. What should I do with
the transient MonoArray 'ctor_params' before leaving the function? is
mono_free to call in this case, or would the garbage collector do its
job just fine as it is.


As long as you store transient MonoObjects* in local variables on the
stack, you don't need to care about their lifetime.

MonoObjects* stored on the C/C++ heap or static segments must be
kept alive with a gchandle.

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

[Robert Jordan]

On 29.04.2013 21:20, Marcelo Zabani 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 *

The DllImported method is this:

*[DllImport (__Internal, EntryPoint=log_error_core_wrapper)]*
*public static extern void ngx_log_error(uint level, IntPtr log, int err,
string msg);*



You must link the main executable (nginx) with the the

-Wl,--export-dynamic

option, otherwise the dynamic linker won't expose its symbols to dlopen.

Robert

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

Re: [Mono-dev] TypeForwardedFrom

[Robert Jordan]

It looks like there are more places where we need the same
Assembly - Type promotion.

GetAssemblyId should also take a Type argument where the
forwarded assembly is determined, similar to the first change.

Robert

On 12.04.2013 16:46, Neale Ferguson wrote:

In both the MONO_REFLECTION_SERIALIZER=yes  no cases we die in
GetAssemblyId when called from WriteTypeSpec:

case TypeTag.GenericType:
   writer.Write (type.FullName);
   writer.Write ((int)GetAssemblyId (type.Assembly));
   break;

I put a couple of WriteLines in the ObjectWriter version before each call
and prior to the break and saw:

type.FullName = TypeTag.GenericType:
System.Collections.ObjectModel.ObservableCollection`1[[System.String,
mscorlib, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089]]

Type.Assembly = Getting assembly id System, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089

I'm not sure why commenting out the EmitLoadType/EmitCall to
WriteTypeAssembly and using the previous EmitLoadAssemblyType/EmitCall to
WriteAssembly causes things not to fail.


On 4/11/13 6:40 PM, Robert Jordan robe...@gmx.net wrote:


This looks good. Maybe the error is somewhere else, so try to
disable the IL serializer with

MONO_REFLECTION_SERIALIZER=yes mono yourtest.exe

If it still breaks, the bug is in WriteTypeAssembly.

Robert

On 11.04.2013 20:58, Neale Ferguson wrote:

This, in my naivety, looks like what I want. However, it's not and leads to
a NULL reference exception. What I am attempting to do is change the
generated code from calling ow.WriteAssembly(writer, memberType.Assembly) to
ow.WriteTypeAssembly(writer, memberType)

---
a/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/CodeGenera
tor.cs
+++
b/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/CodeGenera
tor.cs
@@ -115,8 +115,10 @@ namespace
System.Runtime.Serialization.Formatters.Binary
-   // EMIT ow.WriteAssembly (writer,
memberType.Assembly);
+   // EMIT ow.WriteTypeAssembly
(writer, memberType);

  gen.Emit (OpCodes.Ldarg_1);
  gen.Emit (OpCodes.Ldarg_2);
-   EmitLoadTypeAssembly (gen,
memberType, field.Name);
-   gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteAssembly), null);
+// EmitLoadTypeAssembly (gen,
memberType, field.Name);
+// gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteAssembly), null);
+   EmitLoadType (gen, memberType);
+   gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteTypeAssembly), null);
  gen.Emit (OpCodes.Pop);
  }
  }
@@ -318,6 +320,12 @@ namespace
System.Runtime.Serialization.Formatters.Binary
  gen.EmitCall (OpCodes.Callvirt,
typeof(Type).GetProperty(Assembly).GetGetMethod(), null);
  }

+   static void EmitLoadType (ILGenerator gen, Type type)
+   {
+   gen.Emit (OpCodes.Ldtoken, type);
+   gen.EmitCall (OpCodes.Call,
typeof(Type).GetMethod(GetTypeFromHandle), null);
+   }
+
  static void EmitWrite (ILGenerator gen, Type type)
  {
  gen.EmitCall (OpCodes.Callvirt,
typeof(BinaryWriter).GetMethod(Write, new Type[] { type }), null);



On 4/11/13 1:21 PM, Robert Jordan robe...@gmx.net wrote:


Neale,

Rename  Modify WriteAssembly to take a Type argument:

public int WriteTypeAssembly (BinaryWriter writer, Type type)
{
return WriteAssemblyName (writer, type.GetAssemblyName ());
}

(GetAssemblyName () is the extension from my first post)

Then change all call sites such that they pass the type directly
instead type.Assembly to WriteTypeAssembly. Don't forget
CodeGenerator.cs, where things get nastier due to IL code
generation ;)

Robert


On 11.04.2013 17:48, Neale Ferguson wrote:

Thanks again and apologies for peppering you with questions. In
WriteAssemblyName() it retrieves the AssemblyFullName so I'm not sure how I
can get the forwarded name without the associated Type value.

Neale

On 4/11/13 10:04 AM, Robert Jordan robe...@gmx.net wrote:


Neale,

The icall's declaration:

mono/metadata/icall-def.h:ICALL(ASSEM_23, get_fullname,
ves_icall_System_Reflection_Assembly_get_fullName)

The function:

mono/metadata/icall.c:ves_icall_System_Reflection_Assembly_get_fullName
(MonoReflectionAssembly *assembly)


I won't add this overhead to the Assembly class because it's a Type
feature after all. You can handle this locally in ObjectWriter,
as this is the only place where TypeForwardedFrom is used

Re: [Mono-dev] TypeForwardedFrom

[Robert Jordan]

Hi Neale,

On 11.04.2013 01:45, Neale Ferguson wrote:

[MethodImplAttribute (MethodImplOptions.InternalCall)]
private extern string get_fullname ();

Where is get_fullname? I can't find it anywhere. In any event just
manipulating the strings isn't good enough, I need the type information to
do the TypeForwardedLookup don't I?


It's an internal call implemented in the runtime.

Anyway, you can't change this property. Assembly.FullName must
always reflect the real assembly name, regardless of whether
TypeForwardedFrom is in effect or not.

Bad Things(TM) would happen if you'd change it.

Robert

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

Re: [Mono-dev] TypeForwardedFrom

[Robert Jordan]

Neale,

The icall's declaration:

mono/metadata/icall-def.h:ICALL(ASSEM_23, get_fullname, 
ves_icall_System_Reflection_Assembly_get_fullName)


The function:

mono/metadata/icall.c:ves_icall_System_Reflection_Assembly_get_fullName 
(MonoReflectionAssembly *assembly)



I won't add this overhead to the Assembly class because it's a Type
feature after all. You can handle this locally in ObjectWriter,
as this is the only place where TypeForwardedFrom is used at all.

Robert

On 11.04.2013 15:48, Neale Ferguson wrote:

So would my best approach be a case of saving the type information at the
same time the fullname information is saved in Assembly and then retrieving
it before the WriteAssemblyName() to get the forwarded name?

Out of curiosity shouldn't I find get_fullname() defined somewhere in the
source tree?

Neale


On 4/11/13 6:47 AM, Robert Jordan robe...@gmx.net wrote:


Hi Neale,

On 11.04.2013 01:45, Neale Ferguson wrote:

[MethodImplAttribute (MethodImplOptions.InternalCall)]
private extern string get_fullname ();

Where is get_fullname? I can't find it anywhere. In any event just
manipulating the strings isn't good enough, I need the type information to
do the TypeForwardedLookup don't I?


It's an internal call implemented in the runtime.

Anyway, you can't change this property. Assembly.FullName must
always reflect the real assembly name, regardless of whether
TypeForwardedFrom is in effect or not.

Bad Things(TM) would happen if you'd change it.

Robert




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

[Robert Jordan]

Neale,

Rename  Modify WriteAssembly to take a Type argument:

public int WriteTypeAssembly (BinaryWriter writer, Type type)
{
return WriteAssemblyName (writer, type.GetAssemblyName ());
}

(GetAssemblyName () is the extension from my first post)

Then change all call sites such that they pass the type directly
instead type.Assembly to WriteTypeAssembly. Don't forget
CodeGenerator.cs, where things get nastier due to IL code
generation ;)

Robert


On 11.04.2013 17:48, Neale Ferguson wrote:

Thanks again and apologies for peppering you with questions. In
WriteAssemblyName() it retrieves the AssemblyFullName so I'm not sure how I
can get the forwarded name without the associated Type value.

Neale

On 4/11/13 10:04 AM, Robert Jordan robe...@gmx.net wrote:


Neale,

The icall's declaration:

mono/metadata/icall-def.h:ICALL(ASSEM_23, get_fullname,
ves_icall_System_Reflection_Assembly_get_fullName)

The function:

mono/metadata/icall.c:ves_icall_System_Reflection_Assembly_get_fullName
(MonoReflectionAssembly *assembly)


I won't add this overhead to the Assembly class because it's a Type
feature after all. You can handle this locally in ObjectWriter,
as this is the only place where TypeForwardedFrom is used at all.





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

Re: [Mono-dev] TypeForwardedFrom

[Robert Jordan]

This looks good. Maybe the error is somewhere else, so try to
disable the IL serializer with

MONO_REFLECTION_SERIALIZER=yes mono yourtest.exe

If it still breaks, the bug is in WriteTypeAssembly.

Robert

On 11.04.2013 20:58, Neale Ferguson wrote:

This, in my naivety, looks like what I want. However, it's not and leads to
a NULL reference exception. What I am attempting to do is change the
generated code from calling ow.WriteAssembly(writer, memberType.Assembly) to
ow.WriteTypeAssembly(writer, memberType)

---
a/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/CodeGenera
tor.cs
+++
b/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/CodeGenera
tor.cs
@@ -115,8 +115,10 @@ namespace
System.Runtime.Serialization.Formatters.Binary
-   // EMIT ow.WriteAssembly (writer,
memberType.Assembly);
+   // EMIT ow.WriteTypeAssembly
(writer, memberType);

 gen.Emit (OpCodes.Ldarg_1);
 gen.Emit (OpCodes.Ldarg_2);
-   EmitLoadTypeAssembly (gen,
memberType, field.Name);
-   gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteAssembly), null);
+// EmitLoadTypeAssembly (gen,
memberType, field.Name);
+// gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteAssembly), null);
+   EmitLoadType (gen, memberType);
+   gen.EmitCall (OpCodes.Callvirt,
typeof(ObjectWriter).GetMethod(WriteTypeAssembly), null);
 gen.Emit (OpCodes.Pop);
 }
 }
@@ -318,6 +320,12 @@ namespace
System.Runtime.Serialization.Formatters.Binary
 gen.EmitCall (OpCodes.Callvirt,
typeof(Type).GetProperty(Assembly).GetGetMethod(), null);
 }

+   static void EmitLoadType (ILGenerator gen, Type type)
+   {
+   gen.Emit (OpCodes.Ldtoken, type);
+   gen.EmitCall (OpCodes.Call,
typeof(Type).GetMethod(GetTypeFromHandle), null);
+   }
+
 static void EmitWrite (ILGenerator gen, Type type)
 {
 gen.EmitCall (OpCodes.Callvirt,
typeof(BinaryWriter).GetMethod(Write, new Type[] { type }), null);



On 4/11/13 1:21 PM, Robert Jordan robe...@gmx.net wrote:


Neale,

Rename  Modify WriteAssembly to take a Type argument:

public int WriteTypeAssembly (BinaryWriter writer, Type type)
{
return WriteAssemblyName (writer, type.GetAssemblyName ());
}

(GetAssemblyName () is the extension from my first post)

Then change all call sites such that they pass the type directly
instead type.Assembly to WriteTypeAssembly. Don't forget
CodeGenerator.cs, where things get nastier due to IL code
generation ;)

Robert


On 11.04.2013 17:48, Neale Ferguson wrote:

Thanks again and apologies for peppering you with questions. In
WriteAssemblyName() it retrieves the AssemblyFullName so I'm not sure how I
can get the forwarded name without the associated Type value.

Neale

On 4/11/13 10:04 AM, Robert Jordan robe...@gmx.net wrote:


Neale,

The icall's declaration:

mono/metadata/icall-def.h:ICALL(ASSEM_23, get_fullname,
ves_icall_System_Reflection_Assembly_get_fullName)

The function:

mono/metadata/icall.c:ves_icall_System_Reflection_Assembly_get_fullName
(MonoReflectionAssembly *assembly)


I won't add this overhead to the Assembly class because it's a Type
feature after all. You can handle this locally in ObjectWriter,
as this is the only place where TypeForwardedFrom is used at all.










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

Re: [Mono-dev] TypeForwardedFrom

[Robert Jordan]

Hi Neale,

It looks like your patch doesn't work correctly, because the
assembly references are still the same, as if the patch
didn't have any effect.

Assembly references start with ff in your dump (ff is
decimal 12). See:

https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Runtime.Serialization.Formatters.Binary/binary_serialization_format.htm


| ID (LE) | String length | String (assembly name)
--
Mono:12 | 3 0 0 0 | 6  | System
Windows: 12 | 3 0 0 0 | 78 | WindowsBase, Version=...


I had a look at Mono's

System.Runtime.Serialization.Formatters.Binary/ObjectWriter.cs

and it seems that the necessary patch isn't quite a smooth sailing.
The code is dealing with Assembly objects which we don't have
if TypeForwardedFrom is in effect. The code must be somehow
changed to deal with plain assembly names (strings).

I'd rename ObjectWriter.WriteAssembly to ObjectWriter.WriteTypeAssembly 
and pass it a Type in place of the type's Assembly object.


Whatever you do, don't forget that there is another
fast serializer implemented in CodeGenerator.cs which must be
kept in sync with ObjectWriter.cs

Robert


On 09.04.2013 00:18, Neale Ferguson wrote:

Hi,
  I've taken your code as a base for creating a test fix. It works nicely but
.NET appears to be doing something a little strange (in my eyes, not theirs
of course). A program (such as shown in bugzilla 11294) when run creates a
serialized object but the header contents are different:

Mono -

000 nul soh nul nul nul del del del del soh nul nul nul nul nul nul
020 nul  ff stx nul nul nul bel   P   r   o   g   r   a   m  ff etx
040 nul nul nul ack   S   y   s   t   e   m enq soh nul nul nul   9  ==
060   S   e   r   i   a   l   i   z   a   t   i   o   n   P   r   o
100   t   o   t   y   p   e   .   D   a   t   a   O   b   j   e   c
120   t   W   i   t   h   O   b   s   e   r   v   a   b   l   e   C
140   o   l   l   e   c   t   i   o   n etx nul nul nul  cr   m   _
160   s   t   r   i   n   g   V   a   l   u   e  cr   m   _   d   o
200   u   b   l   e   V   a   l   u   e  ff   m   _   c   o   l   l
220   e   c   t   i   o   n soh nul eot ack dc3 soh   S   y   s   t
240   e   m   .   C   o   l   l   e   c   t   i   o   n   s   .   O
260   b   j   e   c   t   M   o   d   e   l   .   O   b   s   e   r
300   v   a   b   l   e   C   o   l   l   e   c   t   i   o   n

Windows -

000  nul soh nul nul nul  FF  FF  FF  FF soh nul nul nul nul nul nul
020  nul  ff stx nul nul nul  P   r   o   g   r   a   m   ,  sp
040V   e   r   s   i   o   n   =   0   .   0   .   0   .   0   ,
060   sp   C   u   l   t   u   r   e   =   n   e   u   t   r   a   l
100,  sp   P   u   b   l   i   c   K   e   y   T   o   k   e   n
120=   n   u   l   l  ff etx nul nul nul   N   W   i   n   d   o ==
140w   s   B   a   s   e   ,  sp   V   e   r   s   i   o   n   =
1603   .   0   .   0   .   0   ,  sp   C   u   l   t   u   r   e
200=   N   e   u   t   r   a   l   ,  sp   P   u   b   l   i   c
220K   e   y   T   o   k   e   n   =   3   1   b   f   3   8   5
2406   a   d   3   6   4   e   3   5 enq soh nul nul nul   9   S
260e   r   i   a   l   i   z   a   t   i   o   n   P   r   o   t
300o   t   y   p   e   .   D   a   t   a   O   b   j   e   c   t
320W   i   t   h   O   b   s   e   r   v   a   b   l   e   C   o
340l   l   e   c   t   i   o   n

Note, that Mono associates System with Program, but .NET associates it with
WindowsBase. I'm not sure why it does this.

On 4/5/13 10:14 AM, Robert Jordan robe...@gmx.net wrote:


You don't need to know how mcs operates. The TypeForwardedFrom
information can be obtained via reflection:



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

[Robert Jordan]

On 04.04.2013 20:57, Neale Ferguson wrote:

Hi,
  I¹m looking at fixing an incompatibility between .NET and Mono when it
comes to Serialization. Bugzilla 11294 describes the situation but in brief
it is a case that when .NET serializes something that has a
TypeForwardedFrom attribute that information gets put into the serialized
object, but mono does not. It appears that all mono does when it encounters
that attribute it simply stores it away and nothing uses it. To emulate the
.NET behavior that information needs to be accessible in metadata about the
type and that information uses by the Serializers.
  I¹m trying to work out how the information captured by
TypeForwardedFromAttribute.cs can be made available at runtime to the
serializer. My knowledge of how mcs operates and what the contents of
metadata are and how to access them is my roadblock. So any reading/code
that I can be directed to would be a great help.



You don't need to know how mcs operates. The TypeForwardedFrom
information can be obtained via reflection:


public static class TypeExtensions
{
// Returns the assembly name of a type while considering
// TypeForwardedFromAttribute.
public static string GetAssemblyName (this Type self)
{
		var attrs = self.GetCustomAttributes(typeof 
(TypeForwardedFromAttribute), false);

if (attrs.Length == 0)
return self.Assembly.FullName;
else
return ((TypeForwardedFromAttribute)attrs 
[0]).AssemblyFullName;
}
}


I've attached a full sample which proves that MS.NET is simply
emitting TypeForwardedFromAttribute.AssemblyFullName for the
assembly name during serialization.

Robert

using System;
using System.IO;
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
using System.Runtime.CompilerServices;

public static class TypeExtensions
{
	public static string GetAssemblyName (this Type self)
	{
		var attrs = self.GetCustomAttributes(typeof (TypeForwardedFromAttribute), false);
		if (attrs.Length == 0)
			return self.Assembly.FullName;
		else
			return ((TypeForwardedFromAttribute)attrs [0]).AssemblyFullName;
	}
}

[TypeForwardedFrom(SomeOtherAssembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)]
[Serializable]
public class TestClass
{
}

public class Program
{
	static void Main ()
	{
		Console.WriteLine (TypeForwardedFrom:);
		Console.WriteLine (typeof (TestClass).GetAssemblyName ());

		Console.WriteLine (Serialization dump:);
		Dump (new TestClass ());
	}

	static void Dump (object obj)
	{
		using (var stm = new MemoryStream ()) {
			var fmt = new BinaryFormatter ();
			fmt.Serialize (stm, obj);
			Dump (stm.ToArray (), 72);
		}
	}

	static void Dump(byte[] bytes, int width)
	{
		for (int i = 0; i  bytes.Length; i++) {

			byte b = bytes[i];
			if (b  32)
b = (byte) '.';

			Console.Write (Convert.ToChar(b));
			
			if ((i + 1) % width == 0)
Console.WriteLine ();
		}
		if (bytes.Length % width != 0)
			Console.WriteLine ();
	}
}
___
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 Mono's CoreCLR blocks internal method reflection from transparent code ?

[Robert Jordan]

On 24.03.2013 19:08, nelson wrote:

I'm checking that code, at
https://github.com/mono/mono/blob/master/mono/metadata/security-core-clr.c.

If to ensure that the specified method can be used with reflection since
Transparent code cannot call Critical methods is fine with me, why does
CoreCLR also prevents transparent code to call internal transparent methods
or properties through reflection ?


In Silverlight, reflection is as powerful as statically compiled
code. With other words, if the code does not compile due to member
access violations, then reflection won't help either.

While this rule doesn't add concrete security, it helps obscuring
stuff from application code w/out having to decorate members with
[SecurityCritical].

Robert


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

Re: [Mono-dev] ObservableCollection and BindingList Serialization

[Robert Jordan]

On 12.03.2013 00:16, Neale Ferguson wrote:
   ObservableCollection was moved from Windows.Base to System and

TypeForwardedTo and TypeForwardedFrom tags were added to the relevant source
code. ObservableCollection is serializable but when done on a Windows system
using .NET = 3 the serialized object will still contain the WindowsBase,
Version=3.0.0.0, Culture=Neutral, PublicKeyToken=31bf3856ad364e35 data but
Mono will use System. Hence, if you serialize on Mono and then try and
deserialize on .NET then you get an error message:

Error when trying to deserialize with ObservableCollection: Unable to find
assembly 'System'.

Should the serializer use the forwarded information to ensure compatibility
with older programs (and with what .NET does)?


MS.NET 4.0 beta was using the information gathered from
TypeForwardedFrom during serialization. Odds are that this
still applies.

Then Mono's binary serialization machinery should be changed
to pay attention to this attribute during de/serialization,
maybe in class/corlib/System.Runtime.Serialization/ObjectManager.cs.


  In addition, Windows serializes a variable name _busyCount whereas Mono
defines _count.

  Also, I note that BindingList serialization on Mono has different and
missing variable names compared to the .NET equivalent. For example,
allow_new is allowNew in .NET. In addition, do those serialized variables
need to be public or should they be declared as private?


They must have the same visibility as in MS.NET.

Usually, when a class does not implement ISerializable, Mono's
implementation must be changed to match MS down to member naming.
It's a tedious work given that we don't look at MS' source code...

Robert


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

Re: [Mono-dev] Can't create a local tcp connection on mono

[Robert Jordan]

On 02.03.2013 15:56, Ole Bromose wrote:

Hello,

The code below works on Windows. However, when running on mono 2.10.5 on
Gentoo Linux, the listener throws the exception:
  System.Net.Sockets.SocketException: The requested address is not valid
in this context

Listening on the address IPAddress.Any instead of the loopback address
makes the listener run without exception. However, when the client is
started, no connection is created (the server eventually times out).

Can anybody explain why I can't create a local connection on mono?



Please show us the output of /sbin/ifconfig and the contents of
/etc/hosts.

Robert



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

Re: [Mono-dev] Mono.CSharp.Evaluator: x.GetType Bug?

[Robert Jordan]

On 25.01.2013 18:33, lukebuehler wrote:

 //this doesnt work
 evaluator.Evaluate(var a = new A();, out result, out set);
 //Error here:
 evaluator.Evaluate(a.GetType();, out result, out set);
 Console.WriteLine(result);


Local variables don't survive the evaluation. You must Run() them:

evaluator.Run(var a = new A(););
evaluator.Evaluate(a.GetType(););


Robert


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

Re: [Mono-dev] Obtaining class from the assembly or one of the referenced assemblies

[Robert Jordan]

Hi,

On 07.12.2012 07:49, Bartosz Przygoda wrote:

Hi,

Currently I am obtaining the MonoClass* objects via mono_class_from_name
which acts upon the MonoImage of provided assembly.

However, I am planning my project to span throughout few assemblies and I
still want the native host to be able to load classes by name. Do I have to
track the loaded assemblies, and when class is requested, iterate over all
of them and look for it in each one?


Yes, you have to, but you could reuse BCL's Type.GetType
by implementing the following code in a helper assembly
and mono_runtime_invoke it:

// returns the MonoType* of the specified type name
public static IntPtr GetType (string typeName)
{
return Type.GetType (typeName, true).TypeHandle.Value;
}

Then use assembly qualified type names as typeName, e.g.

Namespace.Class, SomeAssemblyNameWithoutDllExtension

Robert


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

Re: [Mono-dev] Building mono on windows

[Robert Jordan]

Hi,

On 03.12.2012 12:52, Michael Stoll wrote:

I'm trying to build Mono on Windows 7.

The System:
Windows 7 Professional x64
Mono 3.0.1
Cygwin 1.7

What I did:
Checkout git repository (with Tortoise GIT, no auto CRLF)
./autogen.sh --prefix /usr/local  autogen.log (see attachment)
make  make.log (see attachment)

But make fails:
MCS [net_2_0] mscorlib.dll
Cannot open assembly './../../class/lib/build/mcs.exe': Permission denied.


Rerun `make' until it works. It might also help to call `make'
once from the directory where it started to fail (here: mcs/classes/corlib):

make PROFILE=net_2_0

When it comes to cygwin, doing stuff until it eventually starts
working is a perfectly valid modus operandi. Don't worry ;)

Robert


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

Re: [Mono-dev] Invoking unmanaged code without marshaling

[Robert Jordan]

Manual pinning isn't required. Blittable types and their one
dimensional arrays are automatically pinned by the p/invoke
marshaler.

Robert

On 02.12.2012 22:19, Rafael Teixeira wrote:

I would not go that route. Have you tried to pin the arrays in managed code
and marshalling just the pointers, using unsafe C# code obviously? It would
do what you want, avoid copying, but with no need to do hard to maintain
hacks... ;-)

Have fun,
Em 02/12/2012 18:12, Marcelo Zabani mzab...@gmail.com escreveu:


Hi everyone, I've been trying to find a way to invoke unmanaged code
without any marshaling, i.e. by making my unmanaged functions receive
Mono's objects (or their addresses).
I've read the Embedding Mono page (a very good one at that) and found that
if I embed Mono in my application, I could call mono_add_internal_call on
my unmanaged functions and mark my C# methods with
[MethodImplAttribute(MethodImplOptions.InternalCall)]; there is a catch in
my case, however.
I am not trying to embed Mono in my application, I'm trying to avoid
marshaling from my standard .NET app to my C API calls since my C
functions deal with large byte arrays all the time, and this implies a
significant overhead in allocating and copying them. I would much rather
try pinning the arrays and accessing the underlying C-like array directly
in some cases (is this possible and is this in Mono's public API?). For
this reason, I can only run mono_add_internal_call after my managed code
has already executed, and apparently because of this I'm getting

  Unhandled Exception: System.MissingMethodException: Cannot find the
requested method.

Is there anyway to achieve what I want?
This is my first time with Mono's internals and I'm only beginning with
Interop, so please excuse any stupidities I may be doing.

--
Marcelo Zabani

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






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




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

Re: [Mono-dev] DllImports cannot load an .so that references another .so (on Ubuntu)

[Robert Jordan]

On 28.11.2012 06:54, hpavlov wrote:

Just for completeness, the Deployment Guidelines on the Mono web site suggest
setting the /LD_LIBRARY_PATH/ before running the application:

http://www.mono-project.com/Guidelines:Application_Deployment#Layout_Recommendation


This is the recommended approach.

Robert


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

Re: [Mono-dev] Latest mod_mono

[Robert Jordan]

On 20.11.2012 15:13, Ben Clewett wrote:

Thanks for the assurance.

It also bothers me that these packages have been excluded (so far) from
the 3.0.n release.  Does this mean they are not ready?  I guess because
the comments are quite old, this is not the case.


It means that there were no changes which would pay off for
a new version.

Robert


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

Re: [Mono-dev] Using console with embedded mono runtime

[Robert Jordan]

On 20.11.2012 14:23, Bartosz Przygoda wrote:

Hi,

My scenario is windows app hosting mono3.0.1 runtime. I wanted to add REPL
functionality, so I've used AllocConsole to open console window. However,
calls to Console static methods do not produce any result, as if


Try this:

Console.SetOut(new StreamWriter(Console.OpenStandardOutput()));
Console.SetError(new StreamWriter(Console.OpenStandardError()));
Console.SetIn(new StreamReader(Console.OpenStandardInput()));

This should reset the console streams in the context of the
newly allocated console.

Robert


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

Re: [Mono-dev] mono 2.11.4 on Windows GetThreadContext failed

[Robert Jordan]

Hi,

On 19.11.2012 11:29, Frank Fuchs wrote:

Hi,
I'm using mono-2.11.4 on Windows 7 in 32 bit and 64 bit for embedding
into my C++ application. Since updating from an rather old 2.6.4 mono
I'm getting an error GetThreadContext failed from the GC every now
and then (there seems to be no pattern). The same error occurs with
mono-3.0.1 both for 32 bit (directly downloaded from mono-project.com)
and 64 bit (self compiled with external Boehm GC - the same as I used
for 2.6.4).

I don't use any antivirus software (in my virtual test machine) so I
can exclude this as the reason.

The only solution I found up to now was to mess with the GC itself and modify

win32_threads.c:
if (!GetThreadContext(THREAD_HANDLE(thread), context))
-   ABORT(GetThreadContext failed);
+  return thread-stack_base;



Can you print the GetLastError() value when this occurs?

How are you loading mono*.dll and the external GC dll?
Boehm is relying on its DllMain function to detect threads.
If you're lazy-loading these DLLs you may miss all threads
that were created before loading Mono with LoadLibrary.

Robert


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

Re: [Mono-dev] Is the `sizeof` opcode doing the right thing?

[Robert Jordan]

On 14.11.2012 04:04, Jordan Earls wrote:

Hi, I've been messing with building a rather low-level datastructure
to avoid the Large Object Heap.

One thing this required of me was to write a very small library
directly in IL. The function I implemented is this:

 .method public static hidebysig
default int32 SizeOfT ()  cil managed
 {
 .maxstack 1
sizeof !!T
  ret
 }


Have you verified this code with PEVerify under MS.NET?


In the ECMA spec, on page 423 for partition III, it says For a
reference type, the size returned is the size of a reference value to
the corresponding type, not the size of the data stored in objects
referred to by a reference value

I think that language is a tiny bit ambiguous. Basically, does this
mean mono is being correct in that it's storing a reference value as
the entire class(an optimization?), or is Mono doing the wrong thing
in not returning just the size of the pointer? I'm not sure about the
Mono internals or anything, so I suspect that it *might* be conforming
to the spec, but I'd really like if someone could verify for this for
me.


According to BCL's specs, OpCodes.Sizeof only applies to
value types:

http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.sizeof%28v=vs.110%29.aspx

The C# sizeof operator doesn't allow reference types either.

Robert


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

Re: [Mono-dev] Seeking advice on converting basic value types from the CLR representation to native C types, using mono embedding

[Robert Jordan]

Hi,

On 11.10.2012 04:45, jean-michel.perr...@csiro.au wrote:


I am working on a package to access the Mono (resp. MS.NET) CLR from
the R statistical language. I am trying to convert 'simple' CLR value
types (e.g. string, double, bool, DateTime) to marshall them to their
R equivalent. I managed to deal with the 'bool', but stumbled on the
DateTime



DateTime is a real value type (in contrast to double, bool etc.
which are primitive types). This means that whenever you unbox
an object of this type you'd need its unmanged representation,
something like that:

typedef struct _MonoDateTime {
gint64 encoded;
} MonoDateTime;


Obviously this is pretty opaque as you've probably no
idea how the field encoded is actually encoded ;) Also, it's
unsafe to rely on undocumented layouts, because they may
change w/out notice (although I believe DateTime won't
change any time soon).

What you can safely do is: implement a helper method
in C# which returns an R date-time from a .NET DateTime.
It's probably just a matter of converting DateTime.Ticks from
the .NET epoch to R's epoch.

Of course, you could also invoke the Ticks getter from C,
but it's usually easier and faster to provide helper methods.

Robert

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

Re: [Mono-dev] Doing dev under win?

[Robert Jordan]

On 11.09.2012 12:50, Robert Wilkens wrote:
 One unimplemented feature i remember, for example, was the
 'WebBrowser' integration, I was using a 'HtmlEditor' control (source
 free on the web) which relied on WebBrowser -- but before i go
 further: I want to say Windows 8 seems to have dropped support for
 that too.  So maybe Mono is not alone.

The WebBrowser integration is still working under Win8.

All related COM interfaces down to IE 5 are still in place as
one would expect from Microsoft ;)

Robert

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

Re: [Mono-dev] Building XSP on MacOSX?

[Robert Jordan]

On 30.06.2012 03:50, Rob Wilkens wrote:

I managed to get XSP to build on MacOSX but it was not pretty.

When i downloaded it from git (g...@github.com:mono/xsp) autogen was
failing at the configure script.  What i did was just comment out the
parts that were failing, then build and install and i was left with a
working fresh compiled XSP.

I had another issue though: It wasn't using my development version of
mono (which the environment variables were pointing at), it was using
(it appeared) the system-wide installed version.  That probably had
something to do with the lines i commented out of the configure script
which had to do with detecting mono and mono installed assemblies.


Use the --with-runtime option.

{./configure|./autogen.sh} --with-runtime=/path/to/your/mono-executable

Robert


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

Re: [Mono-dev] Embedded mono - cross compile on cygwin and linux

[Robert Jordan]

Hi Matthias,

On 04.06.2012 16:46, Matthias D. wrote:

Note: I'm still trying to get this reproduced on a smaller program, but I
did not manage it jet :(.


Or at least tell us which thunk call is actually failing in your code.


Note also: These errors also happen in the (stable) 2.11.1 tarball. I will
always test master and 2.11.1 tarball. Did your mentioned changes are also
in there?


Yes.


And: I'm not using managed classes for interop, only structs as far as i
can see? But maybe I'm missing something here.


It doesn't really matter because both layouts were changed.
However, your structs do not seem to be affected.

This is the change I'm speaking about:

https://github.com/mono/mono/commit/706aaed7c772e00b9cec76f8452ef5f1cedfb5e6

Robert

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

Re: [Mono-dev] strange problem with mkbundle

[Robert Jordan]

On 24.04.2012 12:46, michelw wrote:

Hello,

i've a strange problem.

I do a simple program for test (download a http file, and print to
console the file), who works fine on framework 2, 3, 3.5, 4.0. (on dev
machine)

First problem:
When i use mkbundle -o mytest mytest.exe --deps --static, i see he
always use /usr/lib/mono/4.0/mscorlib.dll and
/usr/lib/mono/gac/***/4.0.0.0, even i compile on 2,3,3.5, or 4.0


This is by design. Use mkbundle2 to bundle the 2.0 assemblies.


Second: (very strange)
When i launch my test program on another linux machine, who haven't
mono, if i compile it with 4.0, i've the error :
System.NotSupportedException: http://www.domain.com/page.php
at System.Net.WebRequest.GetCreator (System.String prefix) [0x0] in

But, if i compile on 2,3 or 3.5, i've no error, test program works fine
(remember he use /***/4.0 dll with mkbundle)


It seems that you have to bundle the machine config as well
when you're targeting the 4.0 runtime. See mkbundle's man page
on how to do this.

Robert


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

Re: [Mono-dev] BUG in mkbundle 2.10.8

[Robert Jordan]

On 18.04.2012 15:52, Andrew Tierney wrote:

I believe there is a bug in the 2.10.8 Mono for Windows release.



When I issue the following command, I get an error as shown below:


http://mono.1490590.n4.nabble.com/Problem-running-mkbundle-using-cygwin-windows-td2990382.html


Robert

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

Re: [Mono-dev] Mono Maintainers list

[Robert Jordan]

On 10.04.2012 23:54, Alex Rønne Petersen wrote:


So, in order to put together an initial list, I'm writing to the
various dev lists. If you are willing to take maintainership of a
particular part of Mono's source base, please reply to this email with
a description of the parts of Mono you wish to take maintainership of
and your IRC nickname (if any). Essentially, doing this just means
that people will be able to go to you when they need patch reviews.


.NET remoting and binary serialization.
IRC: robertj

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

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

On 04.03.2012 15:50, Atsushi Eno wrote:

Some monotouch guys broke jay-related builds on Windows and they are
kept as they are.


This is already fixed.

Robert


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

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

Hi Jonathan,

On 03.03.2012 16:23, Jonathan Chambers wrote:

I am attempting to build mono on Windows using cygwin. I have been building
the runtime using Visual Studio, and using class libraries built on
Linux/OSX. This prevents me from easily running the runtime/classlib tests
though. So, I clone the mono repository, and attempt to configure. I
immediately get a ton of errors all related to line endings in the scripts.
Looking at the .gitattributes file it appears we work native line endings
on *.sh files.

https://github.com/mono/mono/blob/master/.gitattributes


I don't see these CRLF issues when I clone using cygwin's git.

What's the output of

git config --global core.autocrlf

on your system?

Robert

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

Re: [Mono-dev] Building Mono on Windows

[Robert Jordan]

Hi Jonathan,

On 03.03.2012 18:01, Jonathan Chambers wrote:

Hello Robert,

$ git config --global core.autocrlf
true

I believe I enabled that following directions for Windows here:

http://help.github.com/line-endings/

Should that be set to 'input'?


Yes. It's 'input' on my system, and it seems to work (git version
1.7.5.1, cygwin).

Robert

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

Re: [Mono-dev] System.Runtime.Remoting.Channels.Tcp upgrade to Async

[Robert Jordan]

Hi Pablo,

On 23.02.2012 14:17, pablosantosl...@terra.es wrote:

Hi there,

As far as I see here:

https://github.com/mono/mono/tree/master/mcs/class/System.Runtime.Remoting/System.Runtime.Remoting.Channels.Tcp

the good old TCP channel has been largely untouched for about 4 years now.

We use it on a daily basis in Plastic SCM (with some tweaks) but I
wonder if there's interest in converting it into Async sockets.

We're considering it right now, but my question is also: do you think
remoting is dead and should stay this way? Any better alternative?


Remoting won't die anytime soon because it's a core part of the
AppDomain machinery (I'm still using it in new projects whenever
cross-framework compatibility isn't necessary and where security
can be handled by another layer).

About yours (or Dick Porter's?) Async patch: The problem is there
aren't any Remoting maintainers left. I did it in the past
(mostly bug fixing), but I'm starting to forget about the details ;)

If you want this patch in Mono, you'd have to maintain at least
the TcpChannel (monitoring Bugzilla, etc.).

OTOH, given how plugable Remoting is, it would be easier to maintain
your own AsycTcpChannel instead of risking a maintenance burden...

Robert

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

Re: [Mono-dev] starting process in Linux environment

[Robert Jordan]

On 21.02.2012 13:36, pattex007 wrote:

Hi

i'm trying to start a proces in linux but it fails.

the problem is the process argument, it doesnt recognize it.
   Process procNetAdapters = new Process();

 ProcessStartInfo startInfo = new ProcessStartInfo(ifconfig);
 startInfo.Arguments = | grep 'inet addr:';



Pipes are a shell feature. You can only use them as arguments
to ProcessStartInfo if the process you're trying to start
is the shell itself:

ProcessStartInfo startInfo = new ProcessStartInfo(/bin/bash);
startInfo.Arguments = -c '| grep \\'inet addr:\\'';
...

Robert

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

Re: [Mono-dev] starting process in Linux environment

[Robert Jordan]

On 21.02.2012 14:39, Robert Jordan wrote:

On 21.02.2012 13:36, pattex007 wrote:

Hi

i'm trying to start a proces in linux but it fails.

the problem is the process argument, it doesnt recognize it.
Process procNetAdapters = new Process();

ProcessStartInfo startInfo = new ProcessStartInfo(ifconfig);
startInfo.Arguments = | grep 'inet addr:';



Pipes are a shell feature. You can only use them as arguments
to ProcessStartInfo if the process you're trying to start
is the shell itself:

ProcessStartInfo startInfo = new ProcessStartInfo(/bin/bash);
startInfo.Arguments = -c '| grep \\'inet addr:\\'';


Correction:

startInfo.Arguments = -c 'ifconfig | grep \\'inet addr:\\'';

Robert

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

Re: [Mono-dev] starting process in Linux environment

[Robert Jordan]

On 21.02.2012 14:59, pattex007 wrote:

if i run this i get an error with stacktrace


I like how you kept that stacktrace well hidden from us ;)

Robert

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

Re: [Mono-dev] UserName/Password not being used by Process/ProcessStartInfo?

[Robert Jordan]

On 16.02.2012 07:03, ray2k wrote:

Note the disparity between 'Invoking HelloWorld.exe as testuser' and
'Environment.UserName = ec2-user'. What gives? I know slightly more than
nothing about linux- is this related to its shell/security posture or
something? Shouldn't I be seeing Environment.UserName = testuser?


Mono does not support ProcessStartInfo.UserName and Password.
You may want to use 'sudo' or 'su' instead.

Robert

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

Re: [Mono-dev] Manifest file with mono in order to run apps in Administrator

[Robert Jordan]

On 13.02.2012 21:46, Nixeus wrote:

Hello,

I have created a little C# apps with MonoDevelop that needs Administrator
privileges.
I know that it's possible to force running as administrator with a manifest
file embedded with :

requestedExecutionLevel level=requireAdministrator uiAccess=false /

This work with Visual Studio, nevertheless i use mono + MonoDevelop .
Do you know how doing this in MonoDevelop please ?


I don't think MD is supporting embedded manifests.

However, the manifest does not need to be embedded.
E.g., if you app's executable file name is app.exe,
its manifest is called app.manifest.

Robert

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

Re: [Mono-dev] SSL Certificate Binding

[Robert Jordan]

On 09.02.2012 14:30, monoUser wrote:

My HttpListener prefix looks like that

 m_HttpListener.Prefixes.Add(
 string.Format(http://+:9920/;)
 );


You may want to use the https-schema.

Robert

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

Re: [Mono-dev] Process.Start closing file descriptors

[Robert Jordan]

On 27.01.2012 12:54, Weeble wrote:

I have a program that uses
System.IO.Pipes.AnonymousPipe{Server,Client}Stream on .NET to
communicate between a parent and child process while still allowing
the child process to use stdin, stdout and stderr normally. I've found
that this part of System.IO.Pipes isn't implemented in Mono. From what
I can tell, it shouldn't be especially hard to implement these classes
themselves, but the critical problem would be that Process.Start
explicitly closes all open file descriptors (except for stdin, stdout
and stderr). The relevant code is here, in CreateProcess in
processes.c:

https://github.com/mono/mono/blob/master/mono/io-layer/processes.c#L988

Because of that, I believe any working implementation of
System.IO.Pipes.Anonymous* would require changes to CreateProcess.
Either:

1. Remove entirely the loop that closes file descriptors.


This is out of question. For example, you don't want to share sockets.


2. Maintain a process-wide table of all file descriptors associated
with the client-end of an AnonymousPipeServerStream, pass it into
CreateProcess and skip closing of those file descriptors.


This is the way to go. The Win32 pipe functions must be simulated
by the io-layer similarly to the other I/O functions. This way
you'd know which handles to duplicate/inherit.

Robert

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

Re: [Mono-dev] FireFox not correctly detected as high level browser?

[Robert Jordan]

On 27.01.2012 14:22, H . wrote:


I guess that this version
of FireFox is somehow not always accepted as a high level browser. As
a result, the page is rendered in compatibility mode. There might be
a bug in the browser detection block inside the Mono class library.
This problem is very difficult to debug.


You can always add new user agents to $monoprefix/etc/mono/browscap.ini.
The user agent string of the offending browser can be found in
Apache's log file.

Robert

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

Re: [Mono-dev] Mono.Data.Sqlite performance

[Robert Jordan]

On 27.01.2012 15:54, David A Knight wrote:

I have been looking at changing an iOS app over to using Monotouch
and run into an issue with Sqlite performance.  Writing some test
code (not running on a device) that just opens a database and does a
number of inserts (in a transaction) the performance difference
between C (using Core Foundation for unicode strings) and C# is
massive.  ~37k compared to ~14k inserts per second under MacOSX
(including the iOS simulator) / Linux.

Looking at Mono.Data.Sqlite I can't see any code that would cause
this and so have come to the conclusion (wrongly or rightly) that the
difference in performance is down to Sqlite functions being called
via P/Invoke and the overhead it causes.  Is there anything that can
be done to reduce this overhead that isn't already in place?  Am I
wrong that the difference is caused by the P/Invoke?


It's hard to say w/out a test case.

If you did not specify SqliteConnection's UseUTF16Encoding=true
option, the p/invoke layer would have to marshal strings  back and
forth between UTF-8 and UTF-16. This might add substantial overhead
to apps that need 37k transactions per second.

Robert

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

Re: [Mono-dev] How to access AOTed assembly code?

[Robert Jordan]

On 25.01.2012 21:45, Kamal Aboul-Hosn wrote:

Thanks, Robert, that worked very well. I have one more question, if I
may. So I'm embedding Mono on Android on ARM. Up until now, I've been
AOT compiling the libraries by running a little app on the Android
device itself. Obviously, in the long term, this is not really a good
option. So now, I'm trying to build a Mono cross compiler for Android
ARM on my Mac OS X machine (gcc --arch returns
i686-apple-darwin11-llvm-gcc-4.2 if that is useful).

I do the following configure:

./configure --target=armv5-linux-androideabi --enable-nls=no
--prefix=/Users/kamal/mono-cross --disable-mcs-build


Hmm, I'm inclined to say that targeting armv5-linux-androideabi
with a GCC whose arch is i686-apple-darwin11-llvm-gcc-4.2 is
doomed to fail.

You need a cross build toolchain for armv5-linux-androideabi.

Robert

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

Re: [Mono-dev] How to access AOTed assembly code?

[Robert Jordan]

On 24.01.2012 19:39, Kamal Aboul-Hosn wrote:

Hi, everyone,

If I call mono --aot=static,asmonly on a dll to generate a .s file,
how can I get Mono to load the generated AOT'ed assembly if I include
the .s in a native .so I'm building myself as part of an application?
It seems Mono normally just goes looking for a .so file for the
AOT'ed code. Is it possible to get Mono to use the linked in AOT'ed
code in the same native library as the rest of my application? Please
let me know if I can provide any more details.


First, you must embed the runtime as described here:

http://mono-project.com/Embedding_Mono

Second, you must register the static AOT assembly with
mono_aot_register_module. See the description of
--aot=static on mono's man page.

This assembly can be consumed like any other file-based
assembly using the embedding API.

Robert


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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 20.01.2012 08:18, jaysonp wrote:

Hi Robert,

  Again I would make a follow-up regarding my question about $monoprefix
in Windows.


$monoprefix does not exist. It's just a shortcut I'm using in place
of directory where Mono was installed into.

Robert


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

Re: [Mono-dev] AOT compiler crash

[Robert Jordan]

On 20.01.2012 20:38, Michael Bayne wrote:

I'm trying to get IKVM working with MonoTouch. That has required a lot
of crazy hackery, but now I'm crashing the AOT compiler, and I don't
think I'm going to be able to fix this one myself (since I don't have
the source). Here's what it reports:


Try to add -v -v -v to the AOT compiler's command line arguments
in MonoDevelop.

BTW, the MonoTouch mailing list is over there:

http://lists.ximian.com/pipermail/monotouch

Robert

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

Re: [Mono-dev] AOT compiler crash

[Robert Jordan]

On 20.01.2012 21:46, Michael Bayne wrote:

On Fri, Jan 20, 2012 at 12:31 PM, Robert Jordanrobe...@gmx.net  wrote:

Try to add -v -v -v to the AOT compiler's command line arguments
in MonoDevelop.


Unfortunately that didn't yield any additional output.


BTW, the MonoTouch mailing list is over there:


This seems more like a compiler issue (or an issue of IKVM generating
funky bytecodes) than anything particularly MonoTouch specific. But if
you think someone on that mailing list is more likely to have insight
into the problem, I can definitely give it a shot.


It doesn't really matter where the problem is. MT is a commercial,
closed-source product, and its support mailing list isn't mono-devel.

If I were you I'd just drop the project together with the
IKVM assemblies into a freshly created bug report at
http://bugzilla.xamarin.com/.

Other than that, you may want to check whether the IKVM assemblies
are defining delegates that are not derived from MulticastDelegate
(unlikely). Note that in this case the JIT runtime would abort in
the same way, but given its lazy operating principle, odds are
that the offending method was not triggered by your test.

Robert

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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 18.01.2012 02:55, jaysonp wrote:

Thanks again Robert but another clarification... Does this mean that I just
have to add the m parameter/switch on this line of the script to activate
the mono cert store? Like this:

  */  $certmgr  /add /c CA $certfile /m/*

Or should I change the c parameter instead? Like this:
   */  $certmgr  /add /m CA $certfile/*



It's probably this:

$certmgr /add /c CA /m $certfile

Robert

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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 18.01.2012 14:24, jaysonp wrote:

Hi Robert,

  $certmgr /add /c CA /m $certfile  runs OK. However, 0 certificates
were added. Certmgr displays:

   */
   Unknown file extension:
   0 certificate(s) added to store Trust
   /*


Then maybe

$certmgr /add /c /m CA $certfile

You may want to test yourself from the command line. Read
certmgr's man page.

Robert

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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 18.01.2012 17:24, jaysonp wrote:

I thought you've mentioned that .mono will be activated once mono store is
updated with certs... Do you have an idea where the certs were
installed/placed after the script was executed and if the machine's mono
cert store was activated already?


It looks like they are placed into

%PROGRAMDATA%\.mono\certs\cert-store-name\

%PROGRAMDATA% is c:\ProgramData on my machine (Win7).

Robert


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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 16.01.2012 11:24, jaysonp wrote:

Hi Robert,

 Thank you very much for the steps you provided. It's really helpful. I
have 3 clarifications though. Specifically, for step number 4:

 /* 4) mount the shared folders an all other machines as
 $monoprefix/share/.mono/.*/

  1. This is not applicable to Windows machines right? I mean even if
shared the mono cert store like you instructed, other Windows machines
cannot connect to that mounted cert store?


It applies to all platforms.


  2. Does this mean that when I run chktrust of mono on a machine where
the mono cert store was mounted, it will connect to the said mounted cert
store? Or will it still connect on its local mono store?


It will use the local cert store, but since this directory is
mounted, it will use a remote store. That's the trick.


  3. On my Windows machine, I checked the mono cert store directory and
found no  $monoprefix/share/.mono/... Is this the same as C:\Program
Files\Mono-2.10.4\share\mono-2.0\mono? However, this directory contains


The cert store does not exist until you create it, e.g. by adding
a cert.

Robert

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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 17.01.2012 16:54, jaysonp wrote:

Now after running this shellscript, should I expect that
$monoprefix/share/.mono/ will exist? Because I already did run this
shellscript but .mono is still not existing? Does this mean that mono cert
store is still not existing?


The script operates certmgr in user mode. This means that the certs
are be placed into user's cert store (%APPDATA%\.mono\).

The machine store is activated with cermgr's -m switch.
Mozroots equivalent: --machine.

Robert

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

Re: [Mono-dev] Centralized MonoStore

[Robert Jordan]

On 16.01.2012 08:33, jaysonp wrote:

Any feedback? Thank you


Sorry, I'm not proficient enough to tell you how to share
folders securely between Unix and Windows.

I can only give your a sketch:

1) set up a machine running Mono that can act as a server (Windows
or Unix, it doesn't matter),
2) fill its machine cert store periodically using mozroots,
3) share the machine cert store directory. The directory
   is $monoprefix/share/.mono/,
4) mount the shared folders an all other machines as
   $monoprefix/share/.mono/.


If you can't set up network share, you may want to use
a synchronization tool instead. A widely used tool for this
purpose is rsync. Its docs should be self-explanatory.

Robert

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