[Mono-dev] Bug in default site

[Brian Crowell]

The default site created by the System.ComponentModel.Container class does not
pass service requests (IServiceProvider.GetService()) to its container unless
the requested service is of type ISite. That's just batty, because anyone trying
to get the site this way won't get it, and anyone trying to get any other
service from the container won't get it.

The offending code is in Container.cs:

105 if (typeof(ISite) != t) {
106 return null;
107 }

The fix is simple:

105 if (typeof(ISite) == t) {
106 return this;
107 }

I've also attached a test program so you can see the difference between the .NET
implementation and the Mono implementation of this class.

--Brian

using System;
using System.ComponentModel;
using System.ComponentModel.Design;

namespace Test {
class MainClass {
public static void Main() {
TestContainer container = new TestContainer();
Console.WriteLine( "// Results should be not null" );

container.Add( new TestComponent() );

Console.ReadLine();
}
}

class TestService {
}

class TestContainer : Container {
ServiceContainer _services = new ServiceContainer();

public TestContainer() {
_services.AddService( typeof(TestService), new 
TestService() );
}

protected override object GetService( Type serviceType ) {
return _services.GetService( serviceType );
}
}

class TestComponent : Component {
public override ISite Site {
get {
return base.Site;
}
set {
base.Site = value;

if( value != null ) {
Console.WriteLine( "ISite request 
result is {0}",
(value.GetService( 
typeof(ISite) ) == null) ? "null" : "not null" );
Console.WriteLine( "TestService request 
result is {0}",
(value.GetService( 
typeof(TestService) ) == null) ? "null" : "not null" );
}
}
}
}
}


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

[Mono-dev] Bug in default site

[Brian Crowell]

The default site created by the System.ComponentModel.Container class does not 
pass service requests (IServiceProvider.GetService()) to its container unless 
the requested service is of type ISite. That's just batty, because anyone trying 
to get the site this way won't get it, and anyone trying to get any other 
service from the container won't get it.


The offending code is in Container.cs:

105 if (typeof(ISite) != t) {
106 return null;
107 }

The fix is simple:

105 if (typeof(ISite) == t) {
106 return this;
107 }

I've also attached a test program so you can see the difference between the .NET 
implementation and the Mono implementation of this class.


--Brian
using System;
using System.ComponentModel;
using System.ComponentModel.Design;

namespace Test {
class MainClass {
public static void Main() {
TestContainer container = new TestContainer();
Console.WriteLine( "// Results should be not null" );

container.Add( new TestComponent() );

Console.ReadLine();
}
}

class TestService {
}

class TestContainer : Container {
ServiceContainer _services = new ServiceContainer();

public TestContainer() {
_services.AddService( typeof(TestService), new 
TestService() );
}

protected override object GetService( Type serviceType ) {
return _services.GetService( serviceType );
}
}

class TestComponent : Component {
public override ISite Site {
get {
return base.Site;
}
set {
base.Site = value;

if( value != null ) {
Console.WriteLine( "ISite request 
result is {0}",
(value.GetService( 
typeof(ISite) ) == null) ? "null" : "not null" );
Console.WriteLine( "TestService request 
result is {0}",
(value.GetService( 
typeof(TestService) ) == null) ? "null" : "not null" );
}
}
}
}
}

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

[Mono-dev] Undefined reference to 'mono_set_rootdir' while building metadata path

[Brian Crowell]

When linking a file in the /mono/metadata directory, the following error occurs:

/bin/sh ../../libtool --tag=CC --mode=link gcc -O -g -O2 -fno-strict-aliasing -g 
-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wcast-align -Wwrite-strings   -o pedump  pedump.o libmonoruntime.la 
../io-layer/libwapi.la ../utils/libmonoutils.la ../os/libmonoos.la 
../../libgc/libmonogc.la -pthread -L/usr/local/lib -lgthread-2.0 -lglib-2.0 
-Wl,--export-dynamic -L/usr/local/lib -lgmodule-2.0 -ldl -lglib-2.0   -lm -lnsl 
-lpthread -lm -lrt
gcc -O -g -O2 -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes 
-Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs 
-Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -o pedump pedump.o 
-pthread -Wl,--export-dynamic  ./.libs/libmonoruntime.a 
../io-layer/.libs/libwapi.a ../utils/.libs/libmonoutils.a 
../os/.libs/libmonoos.a ../../libgc/.libs/libmonogc.a -L/usr/local/lib 
/usr/local/lib/libgthread-2.0.so /usr/local/lib/libgmodule-2.0.so -ldl 
/usr/local/lib/libglib-2.0.so -lnsl -lpthread -lm -lrt
./.libs/libmonoruntime.a(assembly.o)(.text+0x881): In function 
`mono_assemblies_init':
/home/dsl/mono-1.1.13.2/mono/metadata/assembly.c:481: undefined reference to 
`mono_set_rootdir'

collect2: ld returned 1 exit status
make: *** [pedump] Error 1

As far as I can tell, everything else seems to be building correctly. This is on 
DamnSmallLinux, though, so I'm probably missing a shell variable or dependency.
I know for certain that libgdiplus is not installed, but I don't think that's 
it. Can anyone give me a hint?


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

Re: [Mono-dev] Undefined reference to 'mono_set_rootdir' - more info

[Brian Crowell]

Brian Crowell wrote:
When linking a file in the /mono/metadata directory, the following error 
occurs:


More info:

Near as I can tell, libmonoos.a is being built without any sources. It's empty. 
It should have the source from the /unix subdirectory. What controls this?


This occurs on both the latest stable and development builds. Packages installed 
are:


  gcc
  autoconf-2.59
  pkg-config-0.20
  m4-1.4.4
  bison-1.875
  gettext-0.14.5

...and then Mono. Make no assumptions about anything else installed.

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

Re: [Mono-dev] Undefined reference to 'mono_set_rootdir' - further correction

[Brian Crowell]

Brian Crowell wrote:
When linking a file in the /mono/metadata directory, the following error 
occurs:


It's not so much that libmonoos.a is empty-- it's that there's two of them, and 
the wrong one is empty.


mono/os/.libs/libmonoos.a is empty, but mono/os/unix/.libs/libmonoos.a has the 
right export. So I expect that somewhere in the build process, someone was 
supposed to copy the Unix-specific library over the one in the common build 
path. Where does this take place, and why might it fail?


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

[Mono-dev] Linking errors in mono build

[Brian Crowell]

Various parts of the mono build process are failing on my installation. Building 
it raw first runs into a link error in making pedump:



./.libs/libmonoruntime.a(assembly.o)(.text+0x881): In function 
`mono_assemblies_init':
/home/dsl/mono-1.1.13.2/mono/metadata/assembly.c:481: undefined reference to 
`mono_set_rootdir'

collect2: ld returned 1 exit status
make: *** [pedump] Error 1


Investigation shows that the unix path of libmonoos.a was built, but was not 
being used, hence the missing mono_set_rootdir function.


Copying mono/os/unix/.libs/libmonoos.a to mono/os/.libs/libmonoos.a solves that 
problem, but not much further down the line, a whole mess of linker errors 
occurs while building mono itself:



gcc -I../.. -I../../libgc/include -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include -g -O2 -fno-strict-aliasing -g -Wall -Wunused 
-Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual 
-Wcast-align -Wwrite-strings -o mono -Wl,-version-script=./ldscript.mono main.o 
-Wl,--export-dynamic -Wl,--export-dynamic  ./.libs/libmono-static.a 
-L/usr/local/lib ../os/.libs/libmonoos.a -pthread 
/usr/local/lib/libgthread-2.0.so /usr/local/lib/libgmodule-2.0.so -ldl 
/usr/local/lib/libglib-2.0.so -lnsl -lpthread -lm -lrt

./.libs/libmono-static.a(driver.o)(.text+0x320): In function `mini_regression':
/home/dsl/mono-1.1.13.20060208/mono/mini/driver.c:290: undefined reference to 
`mono_image_get_table_rows'
./.libs/libmono-static.a(driver.o)(.text+0x349):/home/dsl/mono-1.1.13.20060208/mono/mini/driver.c:291: 
undefined reference to `mono_get_method'
./.libs/libmono-static.a(driver.o)(.text+0x357):/home/dsl/mono-1.1.13.20060208/mono/mini/driver.c:292: 
undefined reference to `mono_class_init'
./.libs/libmono-static.a(driver.o)(.text+0x3f2):/home/dsl/mono-1.1.13.20060208/mono/mini/driver.c:311: 
undefined reference to `mono_image_get_filename'



This appears to be because of a missing reference to 
mono/metadata/.libs/libmonoruntime.a. I'm afraid I'm not familiar with the whole 
automake business, so this one may take me awhile to fix on my own.


Can anyone help me figure out what's going on here? Please?

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

Re: [Mono-dev] Getting error at Runtime

[Brian Crowell]

Javier Ruiz wrote:
The error is coming from the SYSTEM.NET.MAIL part of the code. 


Have your catch code output the stack trace like this:

  catch( Exception ex ) {
  Console.WriteLine( "Error: " + ex.ToString() );
  }

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

Re: [Mono-dev] Getting error at Runtime

[Brian Crowell]

Javier Ruiz wrote:
The error is coming from the SYSTEM.NET.MAIL part of the code. 


Have your catch code output the stack trace like this:

  catch( Exception ex ) {
  Console.WriteLine( "Error: " + ex.ToString() );
  }

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

Re: [Mono-dev] a question on ThreadAbortException

[Brian Crowell]

huangyi wrote:
My project need to run and schedule many scripts written by user (and 
user can write code like "while(true) ;"), because the number of scripts 
is huge, so i use a single thread running all the scripts.so i need a 
function just like Abort() to interrupt the current script (if time out) 
and go on to run next script, but i don't know how to implement that in 
c/c++.


I'll warn you about something: The ThreadAbortException wasn't designed to be 
caught and ignored. According to specs, it will be thrown again at the end of 
any catch block that catches it. To cancel the thread abort, you would have to 
call the Thread.ResetAbort() method inside whatever catch block you use.


But therein lies another problem. If the user's scripting language supports it, 
the user can set up his own ThreadAbortException handler and either call 
Thread.Abort() or refuse to leave the catch block.


The .NET Framework 2.0 includes explicit support for what's called a "rude 
thread abort" which kills a thread and only guarantees that certain special 
finally blocks will be run, and no others. Does Mono have something similar?


I've considered this problem for running user scripts and concluded that 
whatever scripting language the user uses must allow me to define what a user 
can do, including setting up exception handlers and defining what external code 
is available (to limit access to Thread.ResetAbort()). I know there are 
scripting engines out there like that, but none comes to mind.


Does anyone have any recommendations?

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

Re: [Mono-dev] high-resolution timer in Mono?

[Brian Crowell]

Jonathan Resnick wrote:
What is the best way to do accurate high-resolution timing in Mono on 
Linux?  I'm basically looking for the equivalent of 
QueryPerformanceCounter() on Windows...  I looked at 
System.Environment.TickCount, but it has a resolution that "cannot be 
less than 500 milliseconds", according to the Mono docs.  Is there a 
high-resolution timer available to Mono?


Not that I know of, but anyone wanting to develop one would want to implement 
the new System.Diagnostics.Stopwatch class from .NET 2.0. It was designed to 
wrap/replace QueryPerformanceCounter(). I guess a lot of people wanted that.


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

[Mono-dev] Current state of documentation?

[Brian Crowell]

I've checked out the monodoc project from AnonSVN, but I'm not sure if it's 
being used. The contents of the various XML files don't match those on the 
website, unless there's some special translation for anything marked "To be added".


So I guess what I want to know is:

1. What is being used from this project, and should it be updated in its present 
form?


2. Who is currently watching over this?

3. Would it be helpful (and/or legal) to update the Mono doc set with the 
documentation from the ECMA specs? (I can't find a notice from the ECMA site 
that says either way.) If not, what other way could the documentation for the 
base classes be updated?


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

Re: [Mono-dev] Current state of documentation?

[Brian Crowell]

Ah. I missed the part about monodoc being a program with submission support.

The questions still stand, though: Is monodoc still being used and maintained? 
What would be an appropriate way to fill in missing documentation?


--Brian


Brian Crowell wrote:
1. What is being used from this project, and should it be updated in its 
present form?


2. Who is currently watching over this?

3. Would it be helpful (and/or legal) to update the Mono doc set with 
the documentation from the ECMA specs? (I can't find a notice from the 
ECMA site that says either way.) If not, what other way could the 
documentation for the base classes be updated?


--Brian
___
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] Current state of documentation?

[Brian Crowell]

Joshua Tauberer wrote:

For future reference, mono-docs-list is the right place for these
questions.  (Anyone replying should now reply on that list and not
mono-devel-list.)  On to my reply:


I would, except that list appears to be a ghost town. I'll check with them as 
soon as my subscription clears, though.




Unless the ECMA docs have been released under an open-source-ish
license, they're copyrighted and can't be 'imported' without permission
from the copyright holder.  I don't know if they're licensed at all.

The other way to update docs is for people to write them. :)


There's a fundamental problem here: Any documentation you could write for the 
base classes must necessarily be a derivative work of the original ECMA 
documentation. I think trying to avoid copyright infringement here will be 
difficult at best.


I've written to the ECMA to ask what the rules are on licensing the contents of 
their standards. It might be better, though, if either a Novell employee or a 
Swiss native would give them a call.


--Brian

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

Re: [Mono-dev] Undeclared identifier in threads.c/VS2005

[Brian Crowell]

Janne Rantala wrote:
I'm currently trying to build Mono in Visual Studio 2005, but it seems 
that there is undeclared identifier __func__ in threads.c which causes 
build to fail. Revision of threads.c is 57160. Looks like latest changes 
to that file have been made six days ago, am I the only one having these 
problems?


"__func__" is the GCC macro for the name of the current function. The Visual C++ 
compiler uses the macro "__FUNCTION__" to do the same thing. So you might 
consider adding the following #define:


#define __func__ __FUNCTION__

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

Re: [Mono-dev] Operator overloading in C#

[Brian Crowell]

Rusmin Susanto wrote:
If I need to access the operator quite often, I am afraid that a 
numerous calls to "new" will slow down the program (as it needs to 
allocate 200 x 200 array of double).


You're asking if, in A + B + C + D + E + F, only one new allocation can be made, 
is that correct? If so, then I'm afraid that just doesn't match the correct 
behavior of a operator +(). When you create an operator +(), it *must* return a 
new instance to satisfy the requirements of that operator. And really, you 
should be doing that regardless of the language.


What you're really trying to do is something more along the lines of:

M = A;
M += B;
M += C;

...which in C++ could be optimized to perform only the one allocation for M. C# 
does not work this way, as you cannot overload the += operator (except by 
overloading +), so the allocations would still be performed in this case.


A better solution is to create an Add() method on your class, which would add 
the argument's contents directly into your array, avoiding allocations altogether:


  public void Add( Foo value ) {
  for( int i = 0; i < __maxX; i++ )
  for( int j = 0; j < __maxY; j++ )
  _array[i,j] += value._array[i,j];
  }

So your statement set then becomes:

  M = A;
  M.Add( B );
  M.Add( C );

This makes the actual behavior of the code more obvious.

To round out this pattern, you should also implement:

  public static Foo Add( Foo value1, Foo value2 ) {
  Foo result = new Foo();

  for( int i = 0; i < __maxX; i++ )
  for( int j = 0; j < __maxY; j++ )
  result._array[i,j] = value1._array[i,j] + value2._array[i,j];

  return result;
  }

  [CLSCompliant(false)]
  public static Foo operator+( Foo value1, Foo value2 ) {
  return Add( value1, value2 );
  }

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

Re: [Mono-dev] Question about performance improvement in C#

[Brian Crowell]

Rusmin Susanto wrote:
In C, we can process all array in one loop. But, in C# we have to 
process array 2 at a time.  This means (for the above example), we need 
to execute the loop 4 times instead of once.


You're just going to have to rethink your design. Object-oriented design is an 
art, and has to yield to concerns of performance, stability, and expandability.


In this case, you should not encapsulate the idea of a linear or two-dimensional 
array. It looks like a good object-oriented design in theory, but makes you lose 
a lot of cache and some heap performance in practice, because, as you've said, 
you have to process one pair at a time.


It may help you to examine more of the patterns in .NET and think of more of the 
tools at your disposal. Consider this static method:


  public static double[] Sum( params double[][] args ) {
  if( args == null || args.Length == 0 )
  throw new ArgumentException( ... );

  double[] result = new double[args[0].Length];

  for( int arg = 0; arg < args.Length; arg++ )
  for( int i = 0; i < args[0].Length; i++ )
   result[i] += args[arg][i];

  return result;
  }

It's not the best method in the world, but may get you much closer to your 
performance goal without sacrificing too much readability. Also note that the 
performance can hinge on such simple things as the order of the loops:


  for( int i = 0; i < args[0].Length; i++ )
  for( int arg = 0; arg < args.Length; arg++ )
   result[i] += args[arg][i];

The first example might perform better because it processes the arrays linearly. 
The second might perform better because the variable "result" is less likely to 
leave the processor's cache.


On top of that, remember that your two-dimensional C loop does work in C#. There 
is no rule that everything you do in C# must yield a class.



How do we tell C# to process all operands at once, instead of only 2 at 
a time? Do we need to modify the C# language so that it can process all 
at once? If we do need to modify C# or the JIT compiler, where should I 
start?


Nyet. Try first to work within your language. There are very simple things you 
can do to solve your problem without re-inventing the wheel. From what I've seen 
of your work, C# will do the job, and easily. You just haven't wrapped your head 
around the language yet.


--Brian


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

[Mono-dev] Newlines and startup scripts

[Brian Crowell]

All right, so I'm a Linux n00b. So I don't have any clue whether what I'm about 
to describe is purely a Linux issue or a Mono issue. Here's what I've got.


I'm running Mono from a startup script as a background task, something like:

  #!/bin/sh

  ...

start)
   echo "Starting background process..."
   /opt/mono-1.1.13.4/bin/mono /opt/my-program/program.exe &
   ;;

This program outputs diagnostic text every few minutes, but it looks like this:

  Whenever there is a line break,
 the text continues without resetting to th
  e first column. This makes any diagnostic
   output very difficult to read, a
  nd nearly impossible to read a long stack trace because it
takes up too ma
  ny lines.

The text is output using Console.WriteLine. I discovered recently-- and this is 
why I think it may purely be a Linux issue-- that the text appears correctly 
after I enter a username at the prompt. This may have something to do with the 
fact that my program's first lines of text always appear after the prompt.


Any clues? Suggestions?

--Brian


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

Re: [Mono-dev] Newlines and startup scripts

[Brian Crowell]

Brian Crowell wrote:
All right, so I'm a Linux n00b. So I don't have any clue whether what 
I'm about to describe is purely a Linux issue or a Mono issue. Here's 
what I've got.


Update: Definitely a Linux issue. This goes back to fun times with serial 
devices.

For anyone interested (and who didn't already know), the TTY devices in Linux 
still emulate serial devices, complete with stop bits, parities, baud rates, 
line-ending-translation, etc. Some getty programs, such as agetty, reset the 
terminal settings upon startup and then attempt to guess those settings after 
you've typed your login name and hit enter.


So my solution is just to disable agetty on the main terminal, and require 
anyone who wants to log in to switch to another terminal. That works for my 
solution. I'm sure there are other ways.


--Brian

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

[Mono-dev] Version-specific binding on non-strong-name assemblies: bug?

[Brian Crowell]

I have an application that creates a new AppDomain under Mono. The application 
is under /home at the moment. It loads into this assembly, through a 
cross-AppDomain delegate, a file called hostee.dll, which lives in 
/var/lib/klotron-monitor/images. (The domain's ApplicationBase is set to this 
directory when it is created.)


hostee.dll references yet another assembly in /var/lib/klotron-monitor/images. 
However, if the version of that assembly does not match the version specified in 
hostee.dll, I get an assembly-not-found error, a SIGSEGV, a stack trace, a 
native stack trace, and then a command prompt:


===
Host Proxy: Loading common interface...
Host Proxy: Loading hostee...
/var/lib/klotron-monitor/images/hostee.dll

** (bin/MonitorHost.exe:13141): WARNING **: The following assembly referenced 
from /var/lib/klotron-monitor/images/hostee.dll could not be loaded:

 Assembly:   Clotron.MobileResource(assemblyref_index=1)
 Version:3.0.2354.22385
 Public Key: (none)
The assembly was not found in the Global Assembly Cache, a path listed in the 
MONO_PATH environment variable, or in the location of the executing assembly 
(/var/lib/klotron-monitor/images).



** (bin/MonitorHost.exe:13141): WARNING **: The class 
Clotron.MobileResource.Server.Interfaces.INetworkMonitorService could not be 
loaded, used in Clotron.MobileResource, Version=3.0.2354.22385, Culture=neutral


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

Stacktrace:

in (wrapper managed-to-native) System.Reflection.Assembly:InternalGetType 
(System.Reflection.Module,string,bool,bool) <0x4>
in (wrapper managed-to-native) System.Reflection.Assembly:InternalGetType 
(System.Reflection.Module,string,bool,bool) <0xffc6>
in System.Reflection.Assembly:GetType (string,bool,bool) (at 
/tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System.Reflection/Assembly.cs:341)
in System.Activator:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/Activator.cs:148)
in System.AppDomain:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/AppDomain.cs:291)
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstance 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xffb6>
in System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
(at /tmp/scratch/BUILD/mono-1.1.14/mcs/class/corlib/System/AppDomain.cs:311)
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xfdb4>
in (wrapper xdomain-dispatch) System.AppDomain:CreateInstanceAndUnwrap 
(object,byte[]&,byte[]&,string,string,bool) <0xfffe33be>
in (wrapper xdomain-invoke) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xff76>
in (wrapper remoting-invoke-with-check) System.AppDomain:CreateInstanceAndUnwrap 
(string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence) 
<0xfff9b350>

in Loader.Class1:LoadDomain (string) <0x1a8>
in Loader.Class1:LoadDefaultImageDomain () <0x59>
in Loader.Class1:ContactService () <0x432>
in Loader.Class1:HandleTimerElapsed (object,System.Timers.ElapsedEventArgs) 
<0x1c>
in (wrapper delegate-invoke) 
System.MulticastDelegate:invoke_void_object_ElapsedEventArgs 
(object,System.Timers.ElapsedEventArgs) <0xdd57>

in System.Timers.Timer:Callback (object) <0x1cf>
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object 
(object) <0xff95>
in (wrapper runtime-invoke) System.Object:runtime_invoke_void_object 
(object,intptr,intptr,intptr) <0xc72643cf>


Native stacktrace:

mono(mono_handle_native_sigsegv+0xbb) [0x815385b]
mono [0x813e1bf]
[0xe440]
mono [0x808b683]
mono(mono_class_init+0x555) [0x808ed75]
mono [0x80ee9ba]
   

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Brian Crowell wrote that Mono said:
** (bin/MonitorHost.exe:13141): WARNING **: The following assembly 
referenced from /var/lib/klotron-monitor/images/hostee.dll could not be 
loaded:

 Assembly:   Clotron.MobileResource(assemblyref_index=1)
 Version:3.0.2354.22385
 Public Key: (none)
The assembly was not found in the Global Assembly Cache, a path listed 
in the MONO_PATH environment variable, or in the location of the 
executing assembly (/var/lib/klotron-monitor/images).


After digging deep into the Mono runtime (without a debugger!), I came to the 
conclusion that the assembly I was trying to load had actually been corrupted by 
something else I was doing. Unfortunately, just by the definition of the API, 
this comes out as a file-not-found error. Therefore, Mono was doing the right 
thing on this issue.


On a side note, I did discover that AppDomain.AssemblyLoad does not fire for 
implicitly-loaded assemblies (referenced ones), but does fire for 
explicitly-loaded and dynamic assemblies.


I also discovered that Mono does not like me reading the Assembly.CodeBase or 
Assembly.Location properties on dynamic assemblies. For Assembly.Location, the 
documentation implies that the property will be an empty string wherever it 
doesn't apply. Throwing an exception for these properties is counter-intuitive, 
especially when there isn't a IsDynamic property on Assembly to help you avoid 
the exception.


--Brian

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

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Gonzalo Paniagua Javier wrote:

Can you please file bug reports in bugzilla.ximian.com and attach a test
case for these problems?


Turns out it's a false alarm on the second one. The properties on dynamic 
assemblies in .NET also throw exceptions, though I still think this behavior is 
bad design because it should be treated the same as if the assembly had been 
loaded as a bag-o-bytes.


On the first one, I found that the reason my implicitly-loading assemblies were 
not showing up is because the assemblies loaded into my first domain had 
propogated into the second one. So the bug here is not that the correct assembly 
wasn't being reported, it was that it wasn't even being loaded!


A quick example:

==
using System;
using System.Reflection;

namespace Test {
class TestClass {
public static void Main( string[] args ) {
AppDomain newDomain = AppDomain.CreateDomain( "testDomain" );

foreach( Assembly assem in newDomain.GetAssemblies() ) {
 Console.WriteLine( assem.FullName );
}
}
}
}
==

Under .NET, this program reports the following assembly in the new AppDomain:

  mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089


Under Mono, these assemblies are reported:

  mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
  test-EmptyAppDomain, Version=0.0.0.0, Culture=neutral


It can be shown that any assembly found in the AppDomain that called 
CreateDomain ends up in the new domain.


This has been filed as bug #78648.

--Brian


using System;
using System.Reflection;

namespace Test {
class TestClass {
public static void Main( string[] args ) {
AppDomain newDomain = AppDomain.CreateDomain( 
"testDomain" );

foreach( Assembly assem in newDomain.GetAssemblies() ) {
Console.WriteLine( assem.FullName );
}
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Gonzalo Paniagua Javier wrote:

Can you please file bug reports in bugzilla.ximian.com and attach a test
case for these problems?


mono-devel-list is taking a bizarre amount of time to show my message. 
Regardless, here's one potential solution.


--Brian
Index: appdomain.c
===
--- appdomain.c (revision 61712)
+++ appdomain.c (working copy)
@@ -496,12 +496,8 @@

mono_context_init (data);

-   /* The new appdomain should have all assemblies loaded */
-   mono_domain_assemblies_lock (domain);
-   /*g_print ("copy assemblies from domain %p (%s)\n", domain, 
domain->friendly_name);*/
-   for (tmp = domain->domain_assemblies; tmp; tmp = tmp->next)
-   add_assemblies_to_domain (data, tmp->data, NULL);
-   mono_domain_assemblies_unlock (domain);
+   /* Load only the corlib into the new domain */
+   add_assemblies_to_domain (data, mono_defaults.corlib->assembly, NULL);

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

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Gonzalo Paniagua Javier wrote:

Can you please file bug reports in bugzilla.ximian.com and attach a test
case for these problems?


Slightly improved patch which removes the now-unnecessary locals.

Sorry for the spam; still very new to this.

--Brian
Index: appdomain.c
===
--- appdomain.c (revision 61712)
+++ appdomain.c (working copy)
@@ -467,11 +467,9 @@
 MonoAppDomain *
 ves_icall_System_AppDomain_createDomain (MonoString *friendly_name, 
MonoAppDomainSetup *setup)
 {
-   MonoDomain *domain = mono_domain_get ();
MonoClass *adclass;
MonoAppDomain *ad;
MonoDomain *data;
-   GSList *tmp;

MONO_ARCH_SAVE_REGS;
 
@@ -496,12 +494,8 @@
 
mono_context_init (data);
 
-   /* The new appdomain should have all assemblies loaded */
-   mono_domain_assemblies_lock (domain);
-   /*g_print ("copy assemblies from domain %p (%s)\n", domain, 
domain->friendly_name);*/
-   for (tmp = domain->domain_assemblies; tmp; tmp = tmp->next)
-   add_assemblies_to_domain (data, tmp->data, NULL);
-   mono_domain_assemblies_unlock (domain);
+   /* Load only the corlib into the new domain */
+   add_assemblies_to_domain (data, mono_defaults.corlib->assembly, NULL);
 
return ad;
 }
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Brian Crowell wrote:
mono-devel-list is taking a bizarre amount of time to show my message. 
Regardless, here's one potential solution.


Unfortunately, this solution has splash damage.

Once this bug is fixed, other bad assumptions come into light. For example, a 
CrossAppDomainDelegate does not fire properly in the new domain because the 
assembly associated with its target is not loaded into the new domain before an 
attempt is made to call the target.


I believe the problem can be traced to a combination of the 
CrossAppDomainSink.SyncProcessMessage method (in 
/class/corlib/System.Runtime.Remoting.Channels/CrossAppDomainChannel.cs) and 
AppDomain.InvokeInDomainByID (in /class/corlib/System/AppDomain.cs). It seems to 
be because the cross-appdomain call bypasses the normal remoting channels, and 
therefore bypasses the part that ensures deserialized references can be used in 
the new domain.


I'll keep looking into this.

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

Re: [Mono-dev] Version-specific binding - resolved, but real bugs found

[Brian Crowell]

Jb Evain wrote:

This is discussed here:

http://bugzilla.ximian.com/show_bug.cgi?id=76757


Ah, good. I thought I was alone here.

So, from that discussion I gather that this is a known bug that no-one wants to 
fix, for fear of having to fix other applications that rely on it.


And yet, from my perspective, this is a known bug that prevents my application 
from running, since my app relies on being able to load two different versions 
of the same assembly in two different AppDomains.


Is that where we stand? Because I would certainly be willing to fix the bug in 
the runtime, and, regardless, it must be fixed, though I would really appreciate 
your input on how to do it.


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

[Mono-dev] NullReferenceException on a callvirt... with a non-null reference? (please help!)

[Brian Crowell]

Okay, while dealing with the whole AppDomains-should-be-empty-bug, I came across 
a strange phenomenon. After making sure that new AppDomains carry only the 
corlib, cross-domain calls to that AppDomain fail with a NullReferenceException.


After careful examination, I've determined that this exception occurs inside the 
xdomain-wrapper method created in metadata/marshal.c. Specifically, it occurs 
during the callvirt instruction that *would* carry out the last step of the 
cross-domain call-- calling the method on the object in the next domain.


Yet, by injecting Console.WriteLine calls into this code, I can show that the 
reference to the target object is, in fact, not null. So, I guess what I need to 
know is-- under what other conditions could a NullReferenceException occur on a 
callvirt (in x86)?


I have a feeling this may have to do with the fact that the called method and 
the calling method come from two instances of the same assembly. Example: I have 
one AppDomain which pulls its assemblies from /foo, and the second which pulls 
it assemblies from /bar. Under the original implementation, these AppDomains 
would carry the same assemblies; that is, the ones that come from the original 
AppDomain. Under the new implementation, the assemblies are separately loaded 
from /foo and /bar, like they should be. So maybe the call-wrapping doesn't take 
this into account?


I'm still working through this, but any help on this particular point would be 
appreciated.


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

Re: [Mono-dev] NullReferenceException on a callvirt... with a non-null reference? (please help!)

[Brian Crowell]

Zoltan Varga wrote:
 The fact that new appdomains have all assemblies loaded is clearly a 
bug, but
it can't be fixed easily because certain parts of the runtime, most 
notably the

remoting infrastructure seem to depend on this broken behaviour.


Yeah, I'm noticing that, too. But, at least in my case, it has to be fixed. :P

Although, I can't really think of anything outside of this particular case that 
might also need to be fixed. Only in-process cross-domain calls would try to 
take advantage of having the same assembly in both AppDomains. If it's in the 
same domain, it *is* the same assembly, and if it's not in the same process, 
then you can't take the shortcut anyways. What other areas can you think of that 
might also need to be fixed?


I find it odd that the author took pains to call the correct method, but failed 
to see that late-loading the method's pointer (the apparent function of 
CEE_MONO_LDPTR) does no good if you assume you're working with the same 
assembly-- you'll just get the same pointer again.


In fact, it may be as simple as introducing a late-binding mechanism into the 
emitted methods.


Thoughts? Suggestions?

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

[Mono-dev] PATCH: Bug #76757, new AppDomains inherit current loaded assemblies

[Brian Crowell]

The attached patch (create-empty-appdomain.patch) fixes bug #76757. New domains 
are created with only the corlib loaded, and the cross-domain code now handles 
the type differences correctly.


An important thing to note about this patch is that it disables a lot of code in 
mono/metadata/marshal.c relating to the fast cross-domain wrappers. Much of that 
code made bad assumptions about the availability of types in other domains and 
the ability to make equality comparisons by pointers. The patch forces all 
cross-domain calls to go through the CrossAppDomainChannel, which has also been 
fixed in this regard.


The attached marshal.diff shows another strategy I thought about taking. This 
tries to get the cross-domain wrappers to correctly understand type equality 
across domains. I abandoned it because it was too much effort, but anyone 
interested can look at it and see what I was trying to do. That diff is based on 
version 1.1.13.8.


Please look at this and approve it for inclusion. I can't commit things, nor 
would I in this case without having someone look into #76811:


  http://bugzilla.ximian.com/show_bug.cgi?id=76811

--Brian
Index: mcs/class/corlib/System.Runtime.Remoting.Messaging/CADMessages.cs
===
--- mcs/class/corlib/System.Runtime.Remoting.Messaging/CADMessages.cs   
(revision 61823)
+++ mcs/class/corlib/System.Runtime.Remoting.Messaging/CADMessages.cs   
(working copy)
@@ -51,19 +51,19 @@

internal class CADObjRef {
ObjRef objref;
-   public int SourceDomain;
+   int _sourceDomain;
 
public CADObjRef (ObjRef o, int sourceDomain) {
objref = o;
-   SourceDomain = sourceDomain;
+   _sourceDomain = sourceDomain;
}
-   
-   public string TypeName {
-   get { return objref.TypeInfo.TypeName; }
+
+   public ObjRef ObjRef {
+   get { return objref; }
}
-   
-   public string URI {
-   get { return objref.URI; }
+
+   public int SourceDomain {
+   get { return _sourceDomain; }
}
}
 
@@ -170,12 +170,8 @@
 
CADObjRef objref = arg as CADObjRef;
if (null != objref) {
-   string typeName = string.Copy (objref.TypeName);
-   string uri = string.Copy (objref.URI);
-   int domid = objref.SourceDomain;
-   
-   ChannelInfo cinfo = new ChannelInfo (new 
CrossAppDomainData (domid));
-   ObjRef localRef = new ObjRef (typeName, uri, 
cinfo);
+   ChannelInfo cinfo = new ChannelInfo (new 
CrossAppDomainData (objref.SourceDomain));
+   ObjRef localRef = new ObjRef (objref.ObjRef, 
cinfo);
return RemotingServices.Unmarshal (localRef);
}

Index: mcs/class/corlib/System.Runtime.Remoting/ChangeLog
===
--- mcs/class/corlib/System.Runtime.Remoting/ChangeLog  (revision 61823)
+++ mcs/class/corlib/System.Runtime.Remoting/ChangeLog  (working copy)
@@ -1,3 +1,9 @@
+2006-06-17  Brian Crowell  <[EMAIL PROTECTED]>
+   
+   * CADMessages.cs: Fixed the use of CADObjRef. The ObjRef is capable of
+   serializing itself, so there should be no need to re-derive its
+   properties on the other end.
+
 2006-04-27  Robert Jordan  <[EMAIL PROTECTED]>
 
* RemotingServices.cs (IsObjectOutOfAppDomain, IsObjectOutOfContext):
Index: mcs/class/corlib/System.Runtime.Remoting/TypeInfo.cs
===
--- mcs/class/corlib/System.Runtime.Remoting/TypeInfo.cs(revision 61823)
+++ mcs/class/corlib/System.Runtime.Remoting/TypeInfo.cs(working copy)
@@ -42,6 +42,9 @@
 
public TypeInfo(Type type)
{
+   if (type == null)
+   throw new ArgumentNullException( "type" );
+   
if (type.IsInterface)
{
serverType = typeof 
(MarshalByRefObject).AssemblyQualifiedName;
Index: mcs/class/corlib/System.Runtime.Remoting/ObjRef.cs
===
--- mcs/class/corlib/System.Runtime.Remoting/ObjRef.cs  (revision 61823)
+++ mcs/class/corlib/System.Runtime.Remoting/ObjRef.cs  (working copy)
@@ -65,11 +65,13 @@
UpdateChannelInfo();
}
 
-   internal ObjRef (

Re: [Mono-dev] PATCH: Bug #76757, new AppDomains inherit current loaded assemblies

[Brian Crowell]

Ben Maurer wrote:

That code had a large impact on xsp performance. It may be worthwhile to
measure this before deciding if the quick fix of disabling that code
path is acceptable.


Unfortunately, any fix will reduce the performance of cross-domain calls, 
because on every call you have to determine whether an acceptable target is 
available or whether a new assembly needs to be loaded. That involves a lot of 
table lookups and string comparisons.


I can think of two ways of reducing the impact of the fix:

* Design the code to perform the target lookup once per domain. For example, if 
one domain makes calls to several others, create one invoke-wrapper for the 
caller, one dispatch-wrapper per target domain, and cache the pointer to the 
dispatch wrapper in the calling domain (per, say, CrossAppDomainChannel).


* Reduce the number of cross-domain calls.

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

[Mono-dev] ExecutionEngineException: Couldn't create thread

[Brian Crowell]

I've got the following sequence staring at me:



** (/opt/ProgramName.Withheld.exe:2670): WARNING **: CreateThread: error 
creating thread handle

Unhandled Exception: System.ExecutionEngineException: Couldn't create thread
in <0x0> 
in (wrapper delegate-begin-invoke) System.MulticastDelegate:begin_invoke_IAsyncR
esult_object_AsyncCallback_object (object,System.AsyncCallback,object)
in <0x00015> System.Threading.ThreadPool:QueueUserWorkItem (System.Threading.Wai
tCallback callback, System.Object state)
in <0x6> System.Timers.StartTimer ()
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

** (/opt/ProgramName.Withheld.exe:2670): WARNING **: _wapi_handle_unref: 
Attempting to unref unused handle 0x20b3a8

** (/opt/ProgramName.Withheld.exe:2670): WARNING **: _wapi_handle_unref: 
Attempting to unref unused handle 0x20b2d0

** (/opt/ProgramName.Withheld.exe:2670): WARNING **: _wapi_handle_unref: 
Attempting to unref unused handle 0x20b120

** (/opt/ProgramName.Withheld.exe:2670): WARNING **: _wapi_handle_unref: 
Attempting to unref unused handle 0x20b1f8



...and there the program has hung.

I'm going to attempt to reproduce the error with a test case, but in the 
meantime, here's the highlights:


class MainClass {
 public static int Main( string[] args ) {
 // Check args, return one if there's a problem

_timer = new System.Timers.Timer( 10.0 );
_timer.BeginInit();
_timer.AutoReset = false;
_timer.Elapsed += new System.Timers.ElapsedEventHandler( 
HandleTimerElapsed );
_timer.EndInit();
_timer.Start();

// Do not allow the program to end
Thread.CurrentThread.Suspend();

return 0;
 }

 private static void HandleTimerElapsed( object sender, 
System.Timers.ElapsedEventArgs e ) {
 try {
 // Set the interval to something substantially higher
 // (on the order of several minutes)
 _timer.Interval = someLongerInterval;
 _timer.Start();

 DoSomethingThatMayOrMayNotBeLongerThanTheInterval();
 }
 catch( ThreadAbortException ) {
 throw;
 }
 catch( Exception ex ) {
 // Default: check every minute if there's an error
 _timer.Interval = 6.0;
 _timer.Start();

 Console.Error.WriteLine( ex );
 }
 }
}


In the instance that produced the above error, 
DoSomethingThatMayOrMayNotBeLongerThanTheInterval() was always shorter than the 
interval. (unless, I suppose, something in that call hung, but then the 
thread-pool should just be starved, and shouldn't throw a wrench)

Other possible sources of threads:

* The program uses remoting heavily
* The program does a lot of work in a separate AppDomain (but does not 
explicitly create threads, nor uses asynchronous invokes or the thread pool)
* The program often calls System.Diagnostics.Process.Start() followed by 
process.WaitForExit()

Also, while the program has changed slightly since I last ran it on 1.1.13.4, 
that version did not exhibit this behavior. I am running it on my 
domain-patched 
1.1.13.8 (which funnels all cross-domain calls through the 
CrossAppDomainChannel).

--Brian



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

Re: [Mono-dev] ExecutionEngineException: Couldn't create thread

[Brian Crowell]

Brian Crowell wrote:
> I've got the following sequence staring at me:

Whoa. Here's a weird twist. Killing the program and starting it over again 
didn't help, at least not right away. After waiting awhile, I got the program 
started again, but at first, it crashed right away with errors such as:

===
** (/opt/Program.NameWithheld.exe:9003): WARNING **: thread_attach: error 
creating thread handle

** (/opt/Program.NameWithheld.exe:9003): WARNING **: thread_attach: error 
creating thread handle

** (/opt/Program.NameWithheld.exe:9003): WARNING **: thread_attach: error 
creating thread handle

** (/opt/Program.NameWithheld.exe:9003): WARNING **: thread_attach: error 
creating thread handle

** (/opt/Program.NameWithheld.exe:9003): WARNING **: process_set_current: error 
creating process handle

** (/opt/Program.NameWithheld.exe:9003): WARNING **: thread_attach: error 
creating thread handle

** ERROR **: file threads.c: line 415 (mono_thread_attach): assertion failed: 
(thread_handle)
aborting...
Aborted
===

Just how many threads _were_ there in that thread-pool?

--Brian


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

Re: [Mono-dev] ExecutionEngineException: Couldn't create thread

[Brian Crowell]

Robert Jordan wrote:
> This bug is already tracked in Bugzilla:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=78241

Wow. According to that, my program is doing everything it can to cause the 
problem. I guess I'll try a build from SVN.

Thanks for the heads-up.

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

Re: [Mono-dev] .Net TCP/IP remoting with unmanaged C++ endpoint?

[Brian Crowell]

Marek Habersack wrote:
> That's the whole problem about SOAP/XML-RPC (which I considered as well). The
> communication is going to be done over slow links (most probably on-demand
> dial-up connections) between embedded devices and a central server, so both 
> the
> volume of data sent and the size of code running on the embedded devices are
> very important. The embedded devices are the ones that would run the C++
> software and the server would run a Mono application. CORBA seems to heavy
> weight for the purpose, too, even though ACE runs on devices with tight 
> memory.
> Therefore, it seems, I will need to come up with a proprietary communication
> protocol.

We had similar issues with the remoting stack. We wanted a compact, but 
portable, binary protocol.

What we ended up doing was creating an RPC format that transitioned data in a 
fashion similar to that of the Torque Network Library 
. Data is packed like structures 
based 
on order and known types in a recursive pass, which makes the codec both fast 
and simple and doesn't require the entire .NET Framework to work.

There are plenty of caveats, though: Your structures must be trees, they have 
to 
be typed public (although a class trying to marshal itself can easily create a 
marshallable instance, similar to a SerializationInfo instance), and you have 
to 
know all the types ahead of time. But since you're creating a C++ endpoint as 
well, I'm sure those aren't major setbacks.

I've mulled over open-sourcing that library. Would you be interested?

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

Re: [Mono-dev] Multiple domains

[Brian Crowell]

Janne Rantala wrote:
> First, could someone specify what root domain exactly means and what is 
> it meant for?

As Zoltan said, it's the first domain created when an application starts up.

Play around with the AppDomain class in the .NET Framework for experience with 
domains.


> Mono project's web site says about mono_jit_init that "That will return 
> a MonoDomain where your code will be executed. You can create multiple 
> domains. Each domain is isolated from the other domains and code in one 
> domain will not interfere with code in other domains."
> But when I tried to initialize mono_jit_init with two different assembly 
> names, I got error saying "**ERROR**: file domain.c:line 517 
> (mono_init_internal):should not be reached aborting..."

You probably shouldn't create domains that way. I think mono_domain_create() 
will give you a new, uninitialized domain. 
ves_icall_System_AppDomain_createDomain() in appdomain.c shows an example of 
using this call, as well as how to add already-loaded assemblies to it.

Please note, though, that Mono does not adhere to the rules of creating new 
domains properly, and as such, you don't really get the guarantees of isolation 
that you should. This is documented as bug #76757.

   


> But if I use mono_domain_get to get current domain (is that also root 
> domain?)  I can create objects from different assemblies just fine.

mono_domain_get() doesn't necessarily return the root domain, but it certainly 
will if it's the only domain. mono_get_root_domain() always gets the root.


> Is there some other way to initialize multiple domains?

There are several ways. Again, look through the AppDomain documentation for 
more 
help on this.

One way, if the same assemblies will be loaded in your root domain as your new 
one, is to use AppDomain.DoCallBack, which invokes a delegate in another 
domain. 
The corresponding code for this is duplicated in both AppDomain.cs, and (less 
accurately) in marshal.c (see mono_marshal_get_xappdomain_invoke for a 
low-level 
way of crossing between domains).

You can also do it in a way to avoid loading the target assembly in your new 
domain. Of course, you always need some common ground, so at least one common 
assembly needs to be loaded in both domains, but after that you can vary on 
which assembly you load and call into.

In my case, for example, I would create a new AppDomain with a different 
directory. I would create an instance of a MarshalByRefObject on the other side 
through a call to AppDomain.CreateInstanceAndUnwrap(), which avoids loading the 
target assembly in the root domain. (This is very important, as the target 
assembly doesn't exist in the root domain's path, and therefore the root domain 
can't load it anyways.) I cast the return value to an interface that is present 
in both domains, and I make calls on it.

The directory structure, for example, looks like this:

/app1
Interface.dll
Host.exe
/app2
Interface.dll
Hostee.dll

This allows me to create two domains, the first (my root) with the corlib, 
Interface.dll, and Host.exe assemblies, and the second with the corlib, 
Interace.dll, and Hostee.dll assemblies. With cross-domain calls, I can contact 
the second domain and have it do my bidding, and any objects it creates or 
assemblies it loads won't interfere with my first. When I'm done with my second 
domain, I can unload it and the assemblies will disappear. In effect, this is 
the only way to "unload" an assembly, and that's the main reason I use multiple 
domains.

Of course, I don't know what you're looking for in domains. They can be very 
complex at times, but they offer some interesting ways around some of the 
deeper 
restrictions of the CLI.

--Brian



> 
> 
> ___
> 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] Multiple domains

[Brian Crowell]

Brian Crowell wrote:
> You can also do it in a way to avoid loading the target assembly in your new 
> domain. Of course, you always need some common ground, so at least one common 
> assembly needs to be loaded in both domains, but after that you can vary on 
> which assembly you load and call into.

Revise:

You can also do it in a way that avoids loading the calling assembly in your 
new 
domain.

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

Re: [Mono-dev] Edit and Continue / Function body rewrite

[Brian Crowell]

David Srbecky wrote:
> The idea is that I will emit disk assembly using System.Reflection.Emit 
> as usually, but later on I will re-emit body of some function and fetch 
> changed data into memory. Once I got the data I can feed it to the .NET 
> runtime - that should not be a problem.

Er, I don't know the full internals of the Mono runtime, but I suspect this is 
not that easy to do. Correct me if I'm wrong, but I think one of the main 
reasons assemblies cannot be unloaded is that it allows you to make some very 
nice assumptions about the immutability of code-- for example, that function 
pointers will not change. It may require patching previously JITted code to 
reference a new function.

Of course, I'd be happy to be wrong about this. Obviously, since Microsoft did 
it, there must be a way.

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

Re: [Mono-dev] Edit and Continue / Function body rewrite

[Brian Crowell]

David Srbecky wrote:
> Yes, you are right - changing running program is probably extremely 
> difficult, but I want to use Microsoft runtime which has this 
> functionality already implemented and available via really simple API. 
> So this is not a problem.
> 
> The problem is that I need to get the new IL code and metadata for the 
> new function from System.Reflection.Emit.

I'm confused. The way I read this, you want to use System.Reflection.Emit to 
take a source code change, turn it into real code, and patch a running program, 
all while running under the .NET Framework (not Mono). Is that it?

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

Re: [Mono-dev] Edit and Continue / Function body rewrite

[Brian Crowell]

Kornél Pál wrote:
> According to Microsoft's public announcements they have done significant 
> modifications to their runtime to support Edit and Continue so this 
> probably it's as easy as writing some managed code.

Under the .NET Framework, yes. You could probably write a set of classes that 
gave you access to the IMetaDataEmit/IMetaDataEmit2 interfaces, and then you 
could use reflection emit to generate the IL and insert it into a running 
program. You could probably do some really freaky programs that way.

My confusion can be summed up as:

1. Since the question was posed on mono-devel, I thought he might want to do 
this sort of thing under Mono.

2. He wants to patch System.Reflection.Emit, which implies he wants to modify 
the source code.

Barring those two things, such a set of classes might be trivial to write. 
They'd essentially just be wrappers for the runtime's metadata services.

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

Re: [Mono-dev] Edit and Continue / Function body rewrite

[Brian Crowell]

Brian Crowell wrote:
> Barring those two things, such a set of classes might be trivial to write. 
> They'd essentially just be wrappers for the runtime's metadata services.

Oh, er, except for the part about starting with source code. How do you 
generate 
the code for just *one* method?

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

[Mono-dev] More _wapi_handle_unref fun

[Brian Crowell]

Well, my program has run for at least a week now, and it just now gave up the 
ghost. I now have a screen full of these messages:

-
** (/opt/MyProgram/MyProgram.exe:2603): WARNING **: _wapi_handle_unref: 
Attempting to unref unused handle 0x1
-

They are all identical; the screen shows eight in a row, and I don't know how 
many came before it.

After some time (probably based on my program's System.Timers.Timer instance) 
the screen starts showing strange exceptions, such as a failed 
Console.WriteLine 
call with some low-level exception or a Socket.Send call that insists "The 
descriptor is not a socket."

This is from a recent (1.1.16-ish) checkout of Mono; I still heavily use the 
System.Timers.Timer class and invoke outside processes.

Several questions:

1. Does anyone know what might cause this? Is it possible that I've exhausted 
all possible handles because the program has run for so long?

2. Is there a way I can make Mono abort when this occurs? This way, I can at 
least restart the process, rather than let it think that it still has any valid 
data left.

--Brian

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

Re: [Mono-dev] More _wapi_handle_unref fun

[Brian Crowell]

Brian Crowell wrote:
> -
> ** (/opt/MyProgram/MyProgram.exe:2603): WARNING **: _wapi_handle_unref: 
> Attempting to unref unused handle 0x1
> -

Sorry. According to http://bugzilla.ximian.com/show_bug.cgi?id=78241, this has 
been repaired in a build after mine. I'll try that one first.

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

Re: [Mono-dev] Application Portability Guidelines.

[Brian Crowell]

Miguel de Icaza wrote:
> Feel free to augment the page with your experiences or with tools,
> tricks and tips that might be useful to others.

Probably add a suggestion to never create more than one AppDomain under Mono.

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

Re: [Mono-dev] Application Portability Guidelines.

[Brian Crowell]

Atsushi Eno wrote:
> We do support multi AppDomain. Your complaints on bug #76757 is
> too tiny to be taken care on this general information. Or are you
> saying that we should say "we don't support generics because there
> are some bugs" ?

All I know is that I'm tired of patching every copy of Mono I get in order to 
get correct behavior. So maybe just add a warning that Mono treats AppDomains 
differently from the way .NET treats them. I know that warning would have saved 
me a few days.

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

Re: [Mono-dev] Application Portability Guidelines.

[Brian Crowell]

Miguel de Icaza wrote:
> I will add the semantics of our current AppDomain behavior.

Thank you. Sorry for the caustic attitude.

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

Re: [Mono-dev] Application Portability Guidelines.

[Brian Crowell]

Charlie Poole wrote:
> Oddly enough, loading our NUnit 2.4 test assemblies under a single domain
> causes it to fail. We're making it work under Mono by using Multiple
> AppDomains. So I assume the problem is more subtle than "never create more
> than one" I'll be interested in reading what the issues are.

It was more of a "don't do it because you can't be sure what will work and what 
won't." Obviously, you guys are doing NUnit tests, so multiple AppDomains work 
in some cases. I would expect you to have trouble, say, running NUnit tests on 
NUnit; the current setup causes great difficulty if you're trying to use two 
different versions of the same assembly.

--Brian

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

Re: [Mono-dev] Keep-alive connection with Remoting?

[Brian Crowell]

Ympostor wrote:
>> Is there a way to use only a connection (with a somewhat keep-alive 
>> behaviour) between the client and the server so as to allow to bypass 
>> any firewalls (that prevent incoming connections, like NAT) that may 
>> affect the client?
> 
> http://www.ingorammer.com/Software/OpenSourceRemoting/BiDirTcpChannel.html

If what you're looking for is bi-directional support over firewalls, you won't 
have many choices. If you're only looking for uni-directional support, the fact 
that remoting closes the connection every now and then won't hurt you.

Bi-directional support in remoting can be tricky, *especially* if you're behind 
a NAT. Remember that every marshalled object has a URI that allows the remoting 
framework to find its way to it. Anything that would allow bi-directional 
remoting has to account for the fact that you can't use the hostname on return.

If you're willing to step up the game a bit, though, it's possible to hijack 
the 
remoting pipeline right at the end, where it would try to find your client 
based 
on its URL and send a message across to it. You'd be creating an IChannelSender 
and an IChannelReceiver pair, with maybe one or two other supporting classes.

But, of course, that's a tad advanced. Alternative, simpler methods exist 
outside of remoting, such as just creating your own 
System.Net.Sockets.NetworkStream and piping your data across it.

So... I'd say no, there's no simple way to do it, not without finding an 
already-made product, and I don't know of any.

--Brian

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

Re: [Mono-dev] Keep-alive connection with Remoting?

[Brian Crowell]

Ympostor wrote:
> Are you referring to any of the tecniques that are being used by the 
> solutions that Robert and I have mentioned?

Yes, they look like they do pretty much what I said.


> I don't want to deal with Sockets. I am trying to use Remoting so as to 
> avoid the implementation of the network bits :-/

The TcpClient and NetworkStream classes make TCP networking pretty easy. It 
sounds like you have an existing solution, though, so maybe that won't work so 
well.


> Thanks for the info Brian!

As helpful or unhelpful as it may be  :P
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] ThreadAbortExceptions and Process.Start

[Brian Crowell]

Anyone know why I might be getting ThreadAbortExceptions when talking to 
another 
process? Or when dealing with unmanaged code, in general?

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

Re: [Mono-dev] Keep-alive connection with Remoting?

[Brian Crowell]

Rafael Teixeira wrote:
> Trying to keep 3 open TCP connections is something you simply
> can't do with affordable hardware, no matter the framework/language
> you use.

See, now that's an interesting observation for me, because that's almost 
exactly 
what I was going to do. And here was my theory on how I was going to do it.

First, you must understand that I've been designing a TCP-based protocol with 
the intent of (a) being able to funnel arbitrary streams all over the place, 
(b) 
sending quick-burst messages quickly, and (c) bypassing firewalls and allowing 
unsolicited traffic in return. I wanted it this way to serve my company's 
current business strategy, but also so I could go off and write games with it.

(side note: my original intent was to use SCTP, but it seems a bit early for 
reliable SCTP support across the range of technologies)

Naturally, you'll have some substantial networking problems to overcome here. 
You'll kill most any router you set to the task. So, my plan was to have a set 
of cheap machines, maybe with two NICs apiece, all assigned various public IP 
addresses that were all listed as A records on a single domain name. (That way, 
DNS randomly chooses a machine for you to connect to.)

Then, each of these machines will handle some set amount of connections. They 
would also form several connections (in the tens) to some server behind the 
firewall/router. Client requests could then be funneled over those few 
connections to be processed by the actual workhorses.

There are a few other ways of looking at this. More work could be handed up to 
the cheap machines to take some of the load off of the central servers, or they 
could be smart enough to route amongst themselves. Or, you could only form 
persistent connections when necessary, and otherwise close the connection.

Anyhow, I thought it was a workable plan. From what you've said, it sounds 
difficult at best. What are your thoughts? Could it be done?

--Brian

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

[Mono-dev] Trying to reproduce _wapi_handle_unref bug

[Brian Crowell]

I'm trying to reproduce a situation seen in my program involving the following 
message:

---
   ** (process:2655): WARNING **: _wapi_handle_unref: Attempting to unref nused 
handle 0x18
---

...where 0x18 may be any low hex number. This happens on mono-1.1.16.1 on 
Linux. 
Nearby error messages suggest a handle allocation problem:

---
   ** (process:2655): WARNING **: CreateThread: error creating thread handle

   Unhandled Exception: System.ExecutionEngineException: Couldn't create thread
 at <0x0> 
 at (wrapper managed-to-native) 
System.Object:__icall_wrapper_mono_delegate_begin_invoke (object,intptr)
 at (wrapper delegate-begin-invoke) 
System.MulticastDelegate:begin_invoke_IAsyncResult_object_AsyncCallback_object 
(object,System.AsyncCallback,object)
 at System.Threading.ThreadPool.QueueUserWorkItem 
(System.Threading.WaitCallback callback, System.Object state) [0x0]
 at System.Timers.Timer.StartTimer () [0x0]
 at (wrapper delegate-invoke) System.MulticastDelegate::invoke_void ()
---

So far, I've been able to make the mono internals SIGSEGV and deadlock from 
managed code (and I will file these as bugs later) but I'm having trouble 
reproducing this particular error except with the original application. So far, 
I'm pretty sure this is something that only comes up with a long-running 
application.

Can anyone give me some guidance as to what, in general, could cause this 
error? 
Handle exhaustion? Leaked handles?

Any help would be appreciated.

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

Re: [Mono-dev] Trying to reproduce _wapi_handle_unref bug - done and done

[Brian Crowell]

Brian Crowell wrote:
I'm trying to reproduce a situation seen in my program involving the following 
message:


After months of chasing this particular problem down, I think I finally found my 
problem. Here it is, with some I found on the way:



http://bugzilla.ximian.com/show_bug.cgi?id=79061 (killwapi.cs)

WAPI shared handles don't seem to disappear when the AppDomain does. This causes 
a really big problem, because a thread handle seems to appear for every 
AppDomain in existence. This program will exhaust the handle table.



http://bugzilla.ximian.com/show_bug.cgi?id=79062 (sigsegv.cs)

The combination of unquoted parameters and standard out redirects, over three 
attempts, will cause a SIGSEGV. Got this one entirely by accident.



http://bugzilla.ximian.com/show_bug.cgi?id=79063 (processdeadlock.cs)

This one is rare. There's a small chance of a deadlock if you run multiple 
processes simultaneously.


--Brian
using System;
using System.Diagnostics;
using System.IO;
using System.Threading;
using System.Net.Sockets;

namespace Test {
class Test {
static void Main() {
for( int i = 0; i < 5; i++ ) {
Thread empty = new Thread( new ThreadStart( 
StartProcess ) );
empty.Start();
}

Thread.Sleep( -1 );
}

static int __processIter = 0;

static void StartProcess() {
for( ;; ) {
ProcessStartInfo info = new ProcessStartInfo( "/bin/echo",
"\"I'm hen-er-y the 8th I am..." + 
Interlocked.Increment( ref __processIter ).ToString() + "\"" );
info.UseShellExecute = false;
info.RedirectStandardOutput = true;

Process process = Process.Start( info );

Console.WriteLine( 
process.StandardOutput.ReadLine() );

process.WaitForExit();
process.Dispose();
}
}
}
}
using System;
using System.Diagnostics;

namespace Test {
class TestClass {
static void Main() {
for( int i = 0; i < 3; i++ ) {
ProcessStartInfo info = new ProcessStartInfo( 
"/bin/echo",
"I'm hen-er-y the 8th I am...8" );
info.UseShellExecute = false;
info.RedirectStandardOutput = true;
Process process = Process.Start( info );
Console.WriteLine( process.StandardOutput.ReadLine() );
process.WaitForExit();
}
}
}
}
using System;

namespace Test {
class Test {
static void Main() {
for( ;; ) {
AppDomain domain = AppDomain.CreateDomain( 
"dummy" );
domain.DoCallBack( new CrossAppDomainDelegate( 
Callback ) );
AppDomain.Unload( domain );
}
}

public static void Callback() {
}
}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Remoting implementation question - calls on System.Object

[Brian Crowell]

Hey, here's a question-- does the remoting framework in Mono forward 
System.Object calls on MarshalByRefObjects? I'm looking at a stack trace that 
suggests it does, in which case, that could be a major source of your 
performance problems in XSP.

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

Re: [Mono-dev] Remoting implementation question - calls on System.Object

[Brian Crowell]

Robert Jordan wrote:
> Err, MS.NET 1.1 does not follow the rules at the bottom of
> the page. Only 2.0 is optimized wrt to System.Object calls.

Well, that's odd. I was almost certain .NET 1.1 did the same thing. It seems 
only natural. I once had to write a set of RealProxies, and one of the ways I 
got the biggest performance boost out of the Framework was to handle the Object 
methods locally. (Particularly GetType, as that is used by the ServiceContainer 
class, but it seems that's not exactly right, given Microsoft's list.)

I'll file the bug anyways, but it's probably not the magic bullet I thought it 
was. I'm reasonably sure, though, that XSP's performance shouldn't be as 
heavily 
tied to remoting performance as people have made it sound.

--Brian


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

Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.

[Brian Crowell]

Robert Jordan wrote:
> This is related to this bugfix:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=76757

http://bugzilla.ximian.com/showattachment.cgi?attach_id=17200

You guys might want to look at the part of this patch that applies to the class 
libraries, as I found some really silly things going on in there.

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

Re: [Mono-dev] XSP Problem : System.Exception: Error reading headers.

[Brian Crowell]

Lluis Sanchez wrote:
> They are not so silly. The problem is we can't leak objects created in
> one domain to another domain. That's why CADMessageBase makes a copy of
> the content of the CADObjRef, instead of reusing it.

The copies are made in CADMessageBase.UnmarshalArgument, which, if I'm not 
mistaken, is called after the jump to the new domain. That means that the 
contents of CADObjRef have already been serialized and deserialized, so no copy 
needs to be made-- the contents have already been copied.

The silly thing about it to me is that ObjRef is marked ISerializable. In other 
words, it knows how to serialize itself. CADObjRef takes advantage of this by 
storing the ObjRef in a field-- but once it's across the gap, it discards most 
of the ObjRef's internal information by only reporting the TypeName string on 
the other side.

Think about that-- the ObjRef's TypeInfo instance is serialized and 
deserialized, and then the type's name is pulled from this field to construct 
yet *another* TypeInfo instance from the *less* applicable type data at the far 
end of the channel.

That's why I changed the code to preserve the work the ObjRef had done in 
serializing itself, and used the CADObjRef type to preserve the only piece of 
information that the ObjRef is missing: the domain ID, needed to construct a 
path back to the object underlying the ObjRef.

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

Re: [Mono-dev] Key matching issue in generic Dictionary [correct message]

[Brian Crowell]

Generic 2006 wrote:
> I'm facing a strange behavior affecting 
> System.Collections.Generic.Dictionary: when I try to search for 
> a key among the dictionary entries using interface members such as 
> ContainsKey( key) or this[ key] I receive wrong responses (the 
> key can't be find, whilst it's really there!).
> I supposed that it could be a problem on the TKey side (where I implemented 
> System.IEquatable), so I put some Console.WriteLine()
> inside the code to verify. A System.Collections.Generic.Dictionary instance 
> is incapsulated in MyDictionary (an implementation of generic IDictionary), 
> TKey is assigned to Name type, TValue is irrelevant.

IEquatable is not enough. You need to override Object.GetHashCode() and 
Object.Equals(). IEquatable is optional, GetHashCode and Equals are 
mandatory.

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

Re: [Mono-dev] Key matching issue in generic Dictionary [correct message]

[Brian Crowell]

Brian Crowell wrote:
> IEquatable is not enough. You need to override Object.GetHashCode() and 
> Object.Equals(). IEquatable is optional, GetHashCode and Equals are 
> mandatory.

Off the top of my head, this is the proper implementation:

class Name : IEquatable
{
  public Name(string value)
  {
   ...
  }

  public bool Equals(Name obj)
  {
   Console.WriteLine("Name.Equals(): this: " + this.value + " other: " + 
obj.Value);
   return this.value.Equals(obj.Value);
  }

  public string Value
  {
   get{return this.value;}
  }

  public override bool Equals( object obj ) {
Name other = obj as Name;

if( other == null )
  return false;

return Equals(other);   // Calls Equals(Name obj)
  }

  public override int GetHashCode() {
return value.GetHashCode();
  }

  // Override operator == and operator != as well;
  //   not necessary, but recommended
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] new AppDomain changes affect mono-service...

[Brian Crowell]

Hubert FONGARNAND wrote:
> check http://bugzilla.ximian.com/show_bug.cgi?id=79207

This bug is caused by the mono-service.exe assembly not being present in the 
target assembly's directory. A workaround would be to copy that file to your 
program's directory.

--Brian


> Le mardi 29 août 2006 à 17:15 +0200, Hubert FONGARNAND a écrit :
>> Hello
>>
>> I'm working with the last mono from svn, and i've several problems 
>> with mono-services...
>> I think that could be related to recent changes in appdomain loading 
>> (http://bugzilla.ximian.com/show_bug.cgi?id=76757)
>>
>> if I run my service (IntranetServer.exe)
>>
>> [EMAIL PROTECTED] ~/applications/IntranetServer/bin/Debug $ mono 
>> /usr/lib/mono/1.0/mono-service.exe ./IntranetServer.exe
>>
>> Unhandled Exception: System.IO.FileNotFoundException: mono-service, 
>> Version=0.0.0.0, Culture=neutral : mono-service, Version=0.0.0.0, 
>> Culture=neutral
>>   at (wrapper xdomain-invoke) System.AppDomain:CreateInstanceAndUnwrap 
>> (string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence)
>>   at (wrapper remoting-invoke-with-check) 
>> System.AppDomain:CreateInstanceAndUnwrap 
>> (string,string,bool,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo,object[],System.Security.Policy.Evidence)
>>   at MonoServiceRunner.Main (System.String[] args) [0x0]
>>
>> This bug is only reproductible with a recent mono (with changes 
>> http://bugzilla.ximian.com/show_bug.cgi?id=76757)
>> I will open a bug in bugzilla... 
>> ___
>> Ce message et les ventuels documents joints peuvent contenir des 
>> informations confidentielles.
>> Au cas o㌠ il ne vous serait pas destin, nous vous remercions de bien 
>> vouloir le supprimer et en aviser imm㐠diatement l'expditeur. Toute 
>> utilisation de ce message non conforme ″ sa destination, toute 
>> diffusion ou publication, totale ou partielle et quel qu'en soit le 
>> moyen est formellement interdite.
>> Les communications sur internet n'tant pas s〵curises, l'int‰grit de 
>> ce message n'est pas assur⼍e et la socit慎 mettrice ne peut ⁸tre 
>> tenue pour responsable de son contenu.
>> ___
>> Mono-devel-list mailing list
>> Mono-devel-list@lists.ximian.com 
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> ___
> Ce message et les �ventuels documents joints peuvent contenir des 
> informations confidentielles.
> Au cas o� il ne vous serait pas destin�, nous vous remercions de bien 
> vouloir le supprimer et en aviser imm�diatement l'exp�diteur. Toute 
> utilisation de ce message non conforme � sa destination, toute diffusion 
> ou publication, totale ou partielle et quel qu'en soit le moyen est 
> formellement interdite.
> Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de 
> ce message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue 
> pour responsable de son contenu.
> 
> 
> 
> 
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Mono 1.1.17 has been released.

[Brian Crowell]

Hubert FONGARNAND wrote:
> I've talk with Robert Jordan, and he doesn't understant why you can't 
> reproduce the bug... He can reproduce the bug, and we've find the 
> solution, he's making a patch in order to place mono-service.exe into 
> the GAC (like XSP)

I've made an addendum to that bug report. I think it should be possible to 
avoid 
installing everything to the GAC by making liberal use of  
declarations in the machine.config file instead.

Of course, I guess it's six one way, half a dozen the other; either way, you 
still have to sign the assembly.

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

Re: [Mono-dev] Mono 1.1.17 has been released.

[Brian Crowell]

Miguel de Icaza wrote:
>   Bugs fixed
> 
>The following bugs were fixed on this release:
> 
>7, 76449, 76453, 76757, 77340, 77551, 77820, 78190, 78220, 78271,
>78288, 78291, 78328, 78399, 78483, 78513, 78525, 78592, 78607, 78646,
>78661, 78696, 78730, 78731, 78732, 78737, 78746, 78753, 78759, 78761,
>78773, 78775, 78800, 78804, 78806, 78810, 78813, 78816, 78821, 78822,
>78825, 78826, 78827, 78837, 78854, 78855, 78856, 78859, 78864, 78865,
>78866, 78868, 78869, 78871, 78877, 78886, 78889, 78907, 78912, 78914,
>78927, 78929, 78931, 78939, 78945, 78949, 78969, 78970, 78971, 78972,
>78977, 79000, 79001, 79002, 79007, 79016, 79020, 79023, 79030, 79037,
>79052, 79053, 79076, 79080, 79085, 79087, 79091, 79095, 79096, 79150,
>30235, 45730, 70506, 77403, 77489, 77539, 78253, 78468, 78703, 78724,
>78767, 78770, 78784, 78799, 78842, 78860, 7, 78899, 78901, 78943,
>78968, 79010, 79033, 79056, 79067, 79084, 79090, 79112, 79117, 79118,
>79125, 77396, 78323, 78384, 78986, 78990, 79012, 79019, 79026, 79064,
>77963, 78985, 79027 and 79028.

Allow me to say a big thanks to everyone who works so hard to make Mono a 
better 
product. I'm looking forward to using Mono more and more in my future projects. 
You guys do an awesome job.

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

Re: [Mono-dev] File System-like storage

[Brian Crowell]

pablosantosluac wrote:
> but, can you add files??
> 
> I tried with a commercial tool, and setting compression off... was horrible 
> for performance inserting data...

Is it out-of-the-question to use a Linux loop device to create a filesystem 
inside a file? Granted, that requires admin privileges...

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

Re: [Mono-dev] File System-like storage

[Brian Crowell]

pablosantosluac wrote:
> would be great! but I wonder if it will work on windows... ;-)

Not in the least!  :P  But lightweight read-write filesystems that can be used 
inside another program are in short supply. You might as well just use the 
actual filesystem.

Besides, I just checked, and only root can do this. But it's one of the neatest 
things I've learned about Linux so far, so I'll share it anyhow.

Create an empty file where your "partition" will reside:

   # dd if=/dev/zero of=my.fs bs=1M count={count}

...where {count} is the number of MB in the filesystem.

Then create the filesystem. mke2fs will do it straight on the file; if others 
refuse, research losetup.

   # mke2fs my.fs
   mke2fs 1.38 (30-Jun-2005)
   my.fs is not a block special device.
   Proceed anyway? (y,n) y
   ...

Mount your filesystem using a loop device.

   # mkdir my.fs.dir
   # mount -o loop my.fs my.fs.dir

When you're done, unmount it.

   # umount my.fs.dir

Feel free to compress the resulting file. It will give worse results than just 
doing tar/gz, though.

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

Re: [Mono-dev] Nokia 770

[Brian Crowell]

pablosantosluac wrote:
>  Unhandled Exception: System.IO.FileNotFoundException: mscorlib.resources 
>  .

What is the full stack trace? Check to see whether your code triggers the 
loading of these resources.

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

Re: [Mono-dev] Thread Pool WAPI Ref Problems

[Brian Crowell]

Patrick Earl wrote:
> Hi.  I've been trying to track what might be causing the issue in the 
> following bug:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=79060

Thought I'd toss in my own related bug:

   http://bugzilla.ximian.com/show_bug.cgi?id=79286

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

Re: [Mono-dev] Thread Pool WAPI Ref Problems

[Brian Crowell]

Patrick Earl wrote:
> Is it correct to assume that wapi handles for threads should stick 
> around until sometime after the thread finishes executing?

Thread has a finalizer that calls Thread_free_internal in metadata/threads.c 
(554), which then just calls CloseHandle. So that's probably when the handle is 
supposed to disappear; when the GC calls the finalizer.

Of course, that's for threads created using the System.Threading namespace. I 
don't know how the other threads disappear, but threads.c is littered with all 
kinds of CloseHandle calls, and some places where CloseHandle is explicitly not 
called, such as mono_thread_detach.

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

Re: [Mono-dev] Mono - CreateProcess error

[Brian Crowell]

Honey, Steve wrote:
> Help!

Hey, Steve. I've been watching this one, too. For months.

The latest bug is filed as:

   http://bugzilla.ximian.com/show_bug.cgi?id=79286

The only workaround I know of at this point (other than, say, rebooting every 
now and then) is to periodically empty the contents of the ~/.wapi directory. 
You can do this while the program's running, say, every ten minutes, or just as 
you've finished one run of data.

At least, I *think* that works. It's such a finicky problem, I can never be 
sure 
of a real fix.

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

Re: [Mono-dev] Mono - CreateProcess error

[Brian Crowell]

Brian Crowell wrote:
> At least, I *think* that works. It's such a finicky problem, I can never be 
> sure 
> of a real fix.

Check that. We just received reports in this morning from our application. This 
doesn't clear or disable WAPI at all.

Looks like the next alternative would be to shut down the Mono process, delete 
the contents of ~/.wapi, and restart the Mono process.

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

Re: [Mono-dev] Mono - CreateProcess error

[Brian Crowell]

Miguel de Icaza wrote:
> I wonder if you are calling too many processes in quick succession, so
> its just a matter of not enough time to clean up those handles/.

That's not the case. I've had long-running programs that would wait several 
minutes between invocations, and they also suffer from this.

As I explain in the bug report, even creating a Process and failing to call 
Dispose will not cause a problem by itself. Yes, there may be more Process 
handles in the table at once, but the garbage collector is pretty quick at 
cleaning them up, and the most I've seen in the table this way is maybe twenty, 
a far cry from the table's limit of 4096.

No, the handle leak problem happens regardless of how the C# program chooses to 
treat its resources. Disposing of the Process object will clean up most handles 
instantly, but regardless of whether you call Dispose, some handles will be 
leaked. And if your program runs for a long time, it will eventually hang the 
Mono process.

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

[Mono-dev] Offtopic: C5 and class design

[Brian Crowell]

Jonathan Pryor wrote:
> Look at the Mono.C5 assembly, which contains many of these special
> collections classes.  Though I don't see what's wrong with the
> System.Collections & System.Collections.Generic types.  Sure, there's no
> Set, but Dictionary suffices, just use the keys as a set.

I've never seen that library before. What a wacky collection!

Has anyone noticed how a lot of projects, when designing object-oriented 
frameworks, tend to ignore principles of keep-it-simple? I'm all for powerful 
classes, but I try to keep them small.

I could write volumes about the errors of frameworks like Crystal Space or OGRE 
(game "engines"). C5 is better off than most libraries, but I still see them 
using protected fields (ick!), and there's something to be said for consistent 
naming.

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

Re: [Mono-dev] WAPI Handle Leaks

[Brian Crowell]

Patrick Earl wrote:
> I suspect there are problems with threads created internally (for 
> example, as part of the thread pool) that aren't cleaned up by the 
> garbage collector.  I would be happy to help test, but solving the 
> problem seems that it would require fairly in depth knowledge of the io 
> layer, garbage collection, wapi handle usage, and such.

I think it's more likely that the garbage collector cleans it up, but a race 
condition on that thread leaves the handle open. And I, like you, haven't 
exactly the Linux debugging skills to track this down.

Anywho, here's the latest bug number for reference:

   http://bugzilla.ximian.com/show_bug.cgi?id=79286

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

Re: [Mono-dev] Replacing/Removing I18N

[Brian Crowell]

Atsushi Eno wrote:
> I quite don't understand why you speak about the _existence_
> of mmaped external resource loader.

Forgive me for jumping in, but I think he's talking about it because it could 
be 
a big help without actually wasting a lot of memory/process time.

Now, *is* there a memory-mapping capability somewhere in Mono, or isn't there? 
And if there is, wouldn't it be helpful to use it, even if just to try this 
strategy out? Remember, with memory mapping, you're not actually *using* 
physical memory so much as using the kernel's cache, so you hurt neither disk 
performance nor memory consumption if you go down this road and end up not 
using 
the larger tables. All you do is devote a little more of the address space to 
Mono.

If that's all it is, then memory mapping isn't really so much of a "hack" as a 
useful loading strategy. You leave it up to the kernel to decide whether you 
need the tables or not, and if you don't use them, fine-- you haven't hurt 
anything. But if you do, the kernel will pop the data off disk and keep it 
until 
it thinks you're done with it.

Now, the question, like I said, is whether Mono actually has that capability. 
For example, does it memory-map assemblies? What about satellite assemblies? 
Could you wrap the memory mapping API and just use it to obtain an unsafe 
pointer?

--Brian

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

Re: [Mono-dev] Compatible dll's

[Brian Crowell]

Joachim Ante wrote:
> Is there any way to verify if two dll's are compatible?

The "official" way is to ensure that the DLL has the same name, major version, 
and minor version as the original; but of course, that's not what you're 
looking 
for.


> So i want to check if all classes, functions & all their parameters still
> exist and are identitical to what we had when mcs compiled against the dll
> last time.

Looks like you'll just have to reflect the two assemblies type by type, method 
by method, and parameter by parameter, taking care to only check the public and 
protected members.

The trickier part is whether you'll treat various attributes as breaking 
changes.

--Brian

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

Re: [Mono-dev] Still trying to solve e=mc^2

[Brian Crowell]

jan jan wrote:
> Can someone please explain to me the patch process or refer me to some 
> step-by-step document that explains this ?

Disclaimer: I'm not a Mono developer. I just watch this list; I tend to have 
issues only the developers can solve.

-- Getting patches

The easiest thing to do is to download the current stable version and follow 
the instructions in the release notes:

  http://www.mono-project.com/Downloads
  http://www.go-mono.com/archive/1.1.18/

You could also do the same with the daily packages:

  http://mono.ximian.com/daily/


The second-easiest thing to do is to keep up with the bleeding edge of 
development using Subversion. See:
  
  http://www.mono-project.com/AnonSVN

Your Linux distribution should most likely come with Subversion, but it case it 
doesn't:

  http://subversion.tigris.org/


The most difficult thing to do is patch from the lists. Generally if you just 
wait, though, the patch will be approved and end up in the repository anyhow.


-- Submitting patches

If you're looking to submit stuff, it's best if you develop against the 
bleeding edge using Subversion. Once you have modified the code so that it 
works, run "svn diff" from an appropriate directory. You can save the output to 
a file and submit it, either by uploading to Bugzilla or to this mailing list.


> Is there a chat room or something where I can meet other developers - 
> specifically those with their emails in the source code ?

As far as I know, you're in the best place for this, assuming you want to know 
about hacking on Mono. If you're writing code that uses Mono, and you don't 
have a bug report or other internal question, the right place is the mono-list:

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

--Brian


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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Stefan Dösinger wrote:
> I am one of the programmers of the Wine Direct3D implementation, and I 
> wondered if there are any plans to implement Managed DirectX in Mono, and if 
> it is possible to share efforts between wine and mono?

Hello.

I started on an open implementation of the XNA libraries. Mostly because I was 
cheesed at the lack of good error messages. I know that isn't Managed DirectX, 
but Microsoft never really seemed interested in supporting that. The good news 
is that they're not terribly different from each other.

The only catch is that it's implemented in C++/CLI, which at present is really 
the best way to do it. I wouldn't attempt it in C#, unless you could figure out 
a better way to do all the calli instructions. I thought at one point about 
doing a simple wrapper around the COM implementation and doing the rest in C#, 
but even that's not all that great, and you still have the C++/CLI dependency.

Here, I'll give you a good example:

--
_device->CreateTexture( width, height, levels, (DWORD) usage, (D3DFORMAT) 
format, (D3DPOOL) pool, &tex, NULL )
--

...becomes:

--
  IL_0006:  ldarg.0
  IL_0007:  ldfld  valuetype IDirect3DDevice9* 
Fluggo.Graphics.Direct3D.GraphicsDevice::_device
  IL_000c:  ldarg.1
  IL_000d:  ldarg.2
  IL_000e:  ldarg.3
  IL_000f:  ldarg.susage
  IL_0011:  ldarg.sformat
  IL_0013:  ldarg.spool
  IL_0015:  ldloca.s   tex
  IL_0017:  ldc.i4.0
  IL_0018:  ldarg.0
  IL_0019:  ldfld  valuetype IDirect3DDevice9* 
Fluggo.Graphics.Direct3D.GraphicsDevice::_device
  IL_001e:  ldind.i4
  IL_001f:  ldc.i4.s   92
  IL_0021:  add
  IL_0022:  ldind.i4
  IL_0023:  calli  unmanaged stdcall int32 
modopt([mscorlib]System.Runtime.CompilerServices.IsLong) 
modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native 
int,uint32,uint32,uint32,uint32 
modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype 
_D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**)
--

Here, you can see C++ calculating the address of the pointer to the function, 
loading it, then issuing a calli. I don't know of a way to do that in C#, at 
least, not one that will give you any kind of good performance.

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Jon Chambers wrote:
> I am working on COM Interop support in mono. ...
> ... If you want to try anything out on mono, you will need to 
> build you interop assemblies with .Net (either by hand or via tlbimp). If you 
> need any other help let me know.

A practical example of building a wrapper by hand would be most helpful. Late 
binding is not an option, and I haven't ever found interface definition files 
for DirectX9.

--Brian


> On 10/25/06, *Brian Crowell* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
> Stefan Dösinger wrote:
>  > I am one of the programmers of the Wine Direct3D implementation,
> and I
>  > wondered if there are any plans to implement Managed DirectX in
> Mono, and if
>  > it is possible to share efforts between wine and mono?
> 
> Hello.
> 
> I started on an open implementation of the XNA libraries. Mostly
> because I was cheesed at the lack of good error messages. I know
> that isn't Managed DirectX, but Microsoft never really seemed
> interested in supporting that. The good news is that they're not
> terribly different from each other.
> 
> The only catch is that it's implemented in C++/CLI, which at present
> is really the best way to do it. I wouldn't attempt it in C#, unless
> you could figure out a better way to do all the calli instructions.
> I thought at one point about doing a simple wrapper around the COM
> implementation and doing the rest in C#, but even that's not all
> that great, and you still have the C++/CLI dependency.
> 
> Here, I'll give you a good example:
> 
> --
> _device->CreateTexture( width, height, levels, (DWORD) usage,
> (D3DFORMAT) format, (D3DPOOL) pool, &tex, NULL )
> --
> 
> ...becomes:
> 
> --
>   IL_0006:  ldarg.0
>   IL_0007:  ldfld  valuetype IDirect3DDevice9*
> Fluggo.Graphics.Direct3D.GraphicsDevice::_device
>   IL_000c:  ldarg.1
>   IL_000d:  ldarg.2
>   IL_000e:  ldarg.3
>   IL_000f:   ldarg.susage
>   IL_0011:  ldarg.sformat
>   IL_0013:  ldarg.spool
>   IL_0015:  ldloca.s   tex
>   IL_0017:  ldc.i4.0
>   IL_0018:  ldarg.0
>   IL_0019:  ldfld  valuetype IDirect3DDevice9*
> Fluggo.Graphics.Direct3D.GraphicsDevice::_device
>   IL_001e:  ldind.i4
>   IL_001f:  ldc.i4.s   92
>   IL_0021:  add
>   IL_0022:  ldind.i4
>   IL_0023:  calli  unmanaged stdcall int32
> modopt([mscorlib]System.Runtime.CompilerServices.IsLong)
> modopt([mscorlib]System.Runtime.CompilerServices.CallConvStdcall)(native
> int,uint32,uint32,uint32,uint32
> modopt([mscorlib]System.Runtime.CompilerServices.IsLong),valuetype
> _D3DFORMAT,valuetype _D3DPOOL,valuetype IDirect3DTexture9**,void**)
> --
> 
> Here, you can see C++ calculating the address of the pointer to the
> function, loading it, then issuing a calli. I don't know of a way to
> do that in C#, at least, not one that will give you any kind of good
> performance.
> 
> --Brian
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> <mailto:Mono-devel-list@lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Richard Matthias wrote:
> It's worth mentioning that Microsoft's Managed DirectX doesn't use COM
> interop. They have a library with a simpler C interface that talks to
> the kernel portion of DirectX that the drivers plug into and the MDX
> library uses that - it's almost completely seperate from the DirectX
> that C++ developers use.

Er... no. I have Managed DirectX installed, and I can find, through ILDASM, 
pretty much the exact same IL sequence I posted earlier, pointer arithmetic and 
all. They use hand-written marshaling to the COM interfaces, not to the kernel.

In fact, here's the document where they say they did it:

  
http://members.microsoft.com/customerevidence/Common/FileOpen.aspx?FileName=12419_MicrosoftDirectX_CS.doc

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Michael Schurter wrote:
> Careful what you do with ILDASM Brian, at least if you plan on 
> contributing code to the mono project:

Yes, I know. I mostly just wanted to figure out how they made calls; everything 
else in my own managed implementation is written from scratch using 
documentation. Better yet, I throw more useful exceptions.

Anyhow, does anyone know of a good way to step around the hand-coded interop 
problem without using Managed C++ or C++/CLI?

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Stefan Dösinger wrote:
> So from the other replies it sounds like you can use wine for dx, but mono 
> needs some preparation work first. If you need any help just contact me or 
> the wine-devel list :-)

Well, one option is to use a library written in C++/CLI, compile it with 
Microsoft's C++ compiler, and then use the resulting library with Mono. That 
should work. There's just no equivalent all-Mono method.

Tell you what. Sometime this week I'll look to release what I have done 
regarding XNA. It won't be exactly what you want-- in particular, my library 
depends on a common primitives library-- but it could be a good starting point 
for a Managed DirectX 9 implementation.

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

> Unfortunately this dll depends on Wine. The dependency is not too big, but 
> needed for certain functionality, namely IWineD3DSurface::GetDC. This method 
> allows applications to do normal gdi operations on d3d surfaces and the 
> framebuffer. I don't know if managed dx still supports that, because GetDC a 
> broken api and ms even tried to remove it from d3d8, but reintroduced it in 
> d3d9

This is available in Managed DirectX indirectly through the 
Surface.GetGraphics() method.


> At the moment wined3d calls glx directly, but we want to change it to use our 
> opengl32.dll instead and fix some opengl issues(windowed gl, glx<->agl 
> abstraction) in opengl32.dll.

I think I don't understand what you're looking for. Managed DirectX is a thin 
wrapper around the DX9 COM interfaces. The most important entry points are 
functions like Direct3DCreate9() and DirectSoundCreate8() (ignoring for the 
moment all the D3DX stuff)-- everything else is available through interface 
calls and calls to IUnknown functions. To look at it another way, if you have 
an implementation of COM and DirectX 9, all you have to do is wrap it; the 
exact same managed DLL should run on both Windows and Wine. 

(I confess to ignorance about how Wine works, so if that doesn't sound right, 
let me know.)

It sounds like what you want is an implementation of Managed DirectX that 
doesn't actually use DirectX, or at least talks to the Wine libs more directly. 
Is that right?

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Jon Chambers wrote:
> interop assemblies. If you want to try anything out on mono, you will 
> need to build you interop assemblies with .Net (either by hand or via 
> tlbimp). If you need any other help let me know.

All right, I went back and found the COM import examples in the .NET 
documentation. I had read this stuff once, but I hadn't ever tried it out. 
Managed to get an IDirect3D9 interface definition working in pure C#.

That lends some possibility to doing the whole thing in C#. *Now* my question 
is how this performs. How do runtime-callable-wrappers perform, compared to 
doing the icall shown in the previous IL listing?

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

Re: [Mono-dev] Managed DirectX

[Brian Crowell]

Jon Chambers wrote:
all currently. A brief benchmark showed COM Interop on mono running at 
about 5x slower than on .Net. I'm sure that will get better if I spend 
some time working on that (but I'd rather get some other features 
working first). I don't know how this compares to the icall example you 
posted.


A better way to phrase my question, I guess, is "will COM Interop performance ever 
be close enough to a custom icall to make it a viable solution?"

Funny thing... I just did a small performance comparison. I created an 
IDirect3D9 in both C# (via COM interop) and C++/CLI (with the DX9 headers and 
/clr:pure), and then called the GetAdapterCount() function 1,000,000 times.

While the application was under the debugger, the RCW won out over the icall by 
some 50%. Running the programs directly gave the opposite result, which is what 
I expected, but I guess that shows the importance of running outside the 
debugger.

But based on this comparison, I expect that RCW would probably never be as fast 
as an icall. It would certainly be possible to do the whole thing via COM 
Interop, and a well-designed DirectX application will try to make as few calls 
as possible. If Mono had a C++ compiler available, I'd advocate that, but 
without it, it's a toss-up as to whether it's worth implementing the whole 
thing in C#.

Just for grins, I've attached the sources to my C++ and C# tests.

--Brian
using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using System.Diagnostics;

namespace DxSharp {
public class MainClass {
static void Main() {
IDirect3D9 d3d = Direct3DCreate9( __sdkVersion );

Stopwatch watch = new Stopwatch();

watch.Start();
for( int i = 0; i < 100; i++ ) {
d3d.GetAdapterCount();
//Console.WriteLine( i );
}
watch.Stop();

Console.WriteLine( "Time elapsed: {0}", watch.Elapsed );
Console.WriteLine( "Calls/second: {0}", 100.0 * 
(double) TimeSpan.TicksPerSecond / (double) watch.ElapsedTicks );

watch.Reset();
watch.Start();
for( int i = 0; i < 100; i++ ) {
d3d.GetAdapterCount();
//Console.WriteLine( i );
}
watch.Stop();

Console.WriteLine( "Time elapsed: {0}", watch.Elapsed );
Console.WriteLine( "Calls/second: {0}", 100.0 * 
(double) TimeSpan.TicksPerSecond / (double) watch.ElapsedTicks );

//Console.WriteLine( d3d.GetAdapterCount() );
Console.ReadKey();
}

const uint __sdkVersion = 32;

[DllImport("d3d9.dll")]
[return:MarshalAs(UnmanagedType.Interface)]
static extern IDirect3D9 Direct3DCreate9( uint sdkVersion );
}

[ComImport, Guid("81BDCBCA-64D4-426d-AE8D-AD0147F4275C"), 
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
interface IDirect3D9 {
/*** IDirect3D9 methods ***/
// STDMETHOD(RegisterSoftwareDevice)(THIS_ void* pInitializeFunction) PURE;
[PreserveSig]
IntPtr RegisterSoftwareDevice( IntPtr initializeFunction );
//STDMETHOD_(UINT, GetAdapterCount)(THIS) PURE;
[PreserveSig]
uint GetAdapterCount();
//STDMETHOD(GetAdapterIdentifier)(THIS_ UINT Adapter,DWORD 
Flags,D3DADAPTER_IDENTIFIER9* pIdentifier) PURE;
[PreserveSig]
IntPtr GetAdapterIdentifier( uint adapter, uint flags, IntPtr 
identifier );
//STDMETHOD_(UINT, GetAdapterModeCount)(THIS_ UINT Adapter,D3DFORMAT 
Format) PURE;
[PreserveSig]
uint GetAdapterModeCount( uint adapter, uint format );
//STDMETHOD(EnumAdapterModes)(THIS_ UINT Adapter,D3DFORMAT Format,UINT 
Mode,D3DDISPLAYMODE* pMode) PURE;
[PreserveSig]
IntPtr EnumAdapterModes( uint adapter, uint format, uint mode, 
IntPtr pMode );
//STDMETHOD(GetAdapterDisplayMode)(THIS_ UINT Adapter,D3DDISPLAYMODE* 
pMode) PURE;
[PreserveSig]
IntPtr GetAdapterDisplayMode( uint adapter, IntPtr mode );
//STDMETHOD(CheckDeviceType)(THIS_ UINT Adapter,D3DDEVTYPE 
DevType,D3DFORMAT AdapterFormat,D3DFORMAT BackBufferFormat,BOOL bWindowed) PURE;
[PreserveSig]
IntPtr CheckDeviceType( uint adapter, uint devType, uint 
adapterFormat, uint backBufferFormat, int windowed );
//STDMETHOD(CheckDeviceFormat)(THIS_ UINT Adapter,D3DDEVTYPE 
DeviceType,

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

jmacdonagh wrote:
> Glad to see I'm not the only one interested in ths. I've also toyed around
> with this idea for some time. I began looking at traditional operating
> system development to learn a little more.

What interests me most about this is a C# program as a first-class citizen, or 
really, every API in the system being not only available, but *designed for* 
managed programs.

I think a good example of that can be found in Microsoft's DirectX, which we 
were just discussing. Compare Managed DirectX to XNA. The differences are big. 
XNA exposes, for the most part, the very same APIs, but in a much more 
intuitive and friendly manner than Managed DirectX.

You could consider fully object-oriented operating systems, where the design of 
the API is every bit as important as its concept. You could organize the system 
around safe plug-ins, each providing some service to the whole, such as a 
windowing system, file systems, etc., but which are most importantly *as easy 
to write as implementing an interface or an abstract base class.*

I'd be very interested in participating on design of such a thing. I've been 
trying to teach myself good object-oriented design over the years, and I think 
I would have some good input to give past the initial problem of booting such 
an environment.

Perhaps the project could be approached in two stages? Half where we boot the 
managed environment, and half where we assume the managed environment. You 
could design and implement these independently of each other. You could even 
design a set of classes to emulate the kernel on top of an ordinary runtime, 
for the purposes of unit testing. One strategy I've become fond of, especially 
where components and unit testing come into play, is generous use of the 
IServiceProvider interface; if components accessed kernel objects this way (or 
a similar way, where you ask for a base class but not a specific 
implementation), they would neither need to know or care whether they're using 
the real thing or not.

Several thoughts. Exciting stuff.

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

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

Mauricio Henriquez wrote:
> all that I mention is in C#, please keep in mind that is a "probe of 
> concepts" test code, is not a serious effor as the proposed in this 
> thread, I love to work on this proyect, I know about assembler on 
> windows, linux and a little IL, I also know a lote of OSs behinds (I'm 
> "Operating System" class teacher on my university)

That's actually more of an emulator than an operating system, but it would 
still be worthwhile to have someone on hand with assembly experience, so stick 
around.

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

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

Johann MacDonagh wrote:
> Actually if it's all the same, I'd like to keep this operating system
> separate from the Unix mentality. That's not to say we wouldn't borrow some
> of Unix's ways of doing things, but there are certain things that would need
> to be changed.

There are lots of things to address, for sure. Device drivers are a hairy issue 
all by themselves, but I could see you encapsulating things like IRQs and I/O 
ports into classes.

One good place to start might be to write a file-system driver. You would 
assume that the operating system would hand you a stream tailored for block 
devices (e.g. BlockStream) and you just go to town. I'd design it at three 
levels:

* The classes and structures that encapsulate various internal states of the 
file system (e.g. inodes, directories, journals)

* A class that encapsulates all the external behavior of the file system (e.g. 
EfsFileSystem) upon being given a block device, where you can ask for streams 
and query/set attributes, but which knows nothing about other loaded drivers, 
or even about the system at all

* A class that presents the file system to the operating system (e.g. 
EfsFileSystemComponent)

Certainly a lot of good ideas and good sample code can come from Unix. One 
question will come up right away: what do we port, and what do we re-write? In 
practice, I've rarely been satisfied when porting projects to C#. It's one 
thing to wrap an API, but to try to translate pointer/error code mentality to 
reference/exception mentality on the fly is rough. I suggest we re-write most 
things, with an eye toward using testing to achieve compatibility, rather than 
hoping that we get the translation right.


> SharpOS.org isn't taken. Kind of shows both sides of the issue.

Sounds awesome to me.


> If there was enough brains behind this, then I wouldn't mind paying for some
> shared hosting on a separate domain name. Set up a wiki (for brainstorming,
> designing), svn, and perhaps some forums (I prefer them over mailing lists).

I like mailing lists because I get them in my mail client; I don't have to 
browse anywhere, remember passwords, or learn yet another bulletin board 
system. My two cents.

Speaking of two cents, I'd be willing to chip in on hosting costs. Actually, 
I've been meaning to try out virtual hosting for awhile; those things almost 
look too good to be true, at US$50/month.

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

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

Johann MacDonagh wrote:
> I did a little research and it looks like it is possible to install 
> MediaWiki, although it can be painful at times.

You could go the Google Project Hosting route. They offer Subversion hosting 
and their own (primitive) issue tracking service:

  http://code.google.com/hosting/
  example: http://code.google.com/p/s3net/

They also offer wiki-like page editing and file hosting in their latest Google 
Groups implementation:

  http://groups-beta.google.com/

Google Groups is sort of a cross between a forum and a mailing list anyhow.

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

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

Johann MacDonagh wrote:
> SF doesn't offer a Wiki do they? For the initial brainstorming of this
> project, a wiki would work great.

If I'm reading the Sourceforge docs right, you should be able to install a 
PHP-based wiki (such as MediaWiki) without too much trouble:

 http://sourceforge.net/docs/E07/en/#top

SourceForge apparently offers both mailing lists and forums. You know, I've 
never actually used SourceForge, other than the hundreds of files I've 
downloaded from them. I didn't know they had a donation system, either :P

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

Re: [Mono-dev] [Mono-devel-list] Operating System in C# Project

[Brian Crowell]

William Lahti wrote:
> I have expressed support for the managed kernel idea because I am
> already in the process of building a managed operating system. I call
> it Jeto. Currently it consists of...

That figures. We've already drafted budgets and purchased an office.

Kidding, kidding. Sort of. Mr. Schurter has cobbled together sharpos.org and a 
mailing list. And yes, of course we'd be interested in what you have.

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