Re: [Mono-list] Mono and Real-Life

[Bruce Wilkie]

Hello Mono community.  :)

The Sims 3 makes non-trivial use of Mono.  Reading the blogs around the 
interwebs, you guys have already figured that out.  Most of the behavior you 
guys see in relation to object and Sim interactions is written in C#.

Read a bit of  http://www.gamasutra.com/php-bin/news_index.php?story=23980 for 
an idea of how the first week sales went.  Go Sims 3!  Yay!

Using Mono was an interesting experience.  It can be a hard sell to management 
for sure, especially when a commercial license is needed, and for me, talking 
to lawyers is rarely fun.  I will say Mono is in a much better place now than 
years ago when we first started using it - you guys have already pulled the 
version number from the last drop of Mono we took, and you'll notice it is 
rather old.  :P

Good luck in your efforts TheBlueSky!

thx,
bruce



- Original Message 
From: TheBlueSky 
To: mono-list@lists.ximian.com
Sent: Monday, June 8, 2009 1:19:28 AM
Subject: Re: [Mono-list] Mono and Real-Life


Thanks for the reference :)


RL wrote:
> 
> Wikipedia uses Lucene.Net + mono:
> "at first GCJ-based solution, afterwards .net Lucene port was used on top
> of
> Mono .NET framework"  (page 28)
> http://www.scribd.com/doc/43868/Wikipedia-site-internals-workbook-2007
> 
> 
> http://tirania.org/blog/archive/2005/May-30.html
> 
> 
> 2009/6/5 TheBlueSky 
> 
>>
>> Thanks, I guess I'll add Unity to my references :)
>>
>> Now, anybody has an idea about:
>>
>> 1. Wikipedia
>> 2. VistaDB
>> 3. The Sims 3
>>
>>
>> Stifu wrote:
>> >
>> > I'm almost sure Unity is made with Mono (and it was originally a
>> Mac-only
>> > product before they switched to C#, and I don't think they'd have
>> switched
>> > if Mono wasn't there, since otherwise that'd mean no longer supporting
>> > Mac).
>> > Also, this is what a Unity developer posted yesterday on Miguel's blog:
>> >
>> > "The majority of C# work done at Unity Technologies are done with
>> > MonoDevelop - and yes, we want it to be good enough to be the default
>> > editor as well."
>> >
>> > http://tirania.org/blog/archive/2009/Jun-04.html
>> >
>> > Hope that helps.
>> >
>> >
>> > TheBlueSky wrote:
>> >>
>> >> Thank you for the piece you shared, I really appreciate it.
>> >>
>> >> The project I was talking about isn't that complex or huge, although
>> can
>> >> be a bit big, and based of my knowledge about Mono, I think it can fit
>> >> here (also based of my experience in .Net in general)... I'm also
>> taking
>> >> it as a chance to learn something new ;)
>> >>
>> >> Well, you're right, I had a look at Unity, but correct me if I'm
>> wrong,
>> >> isn't it of the kind that works-with-Mono, instead of built-with-Mono.
>> >> Sorry, I just don't know much about Unity, and skimming through their
>> >> website previously, didn't really help in that matter. Any reference
>> will
>> >> be very much appreciated.
>> >>
>> >> Thanks again.
>> >>
>> >>
>> >> Stifu wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> I take it you had a look at Unity?
>> >>> And any games made with Unity therefore rely on Mono, the last
>> example
>> >>> I've heard about being that lego Star Wars game
>> >>> (http://tirania.org/blog/archive/2009/May-16.html).
>> >>>
>> >>> By the way, it's nice to push Mono in companies (I've done so too),
>> but
>> >>> in order to avoid taking risks and getting into unexpected
>> situations,
>> >>> it may be wise to first propose to try it with a little project, so
>> you
>> >>> and your colleagues can first get used to it, better understand its
>> >>> limitations, and so on... Just to be on the safe side, especially if
>> >>> your colleagues are reluctant. I don't know how big the project you
>> >>> mentioned is, though.
>> >>>
>> >>>
>> >>> TheBlueSky wrote:
>> 
>>  Hello everyone,
>> 
>>  This isn't a technical question or something, but I'm trying to
>>  convince the company I'm working with to use Mono for some project
>> we
>>  are doing (Linux only project). I, myself, came from strong .Net
>>  background and I know what .Net is capable of, I mean in term of RAD
>>  and such, however, other people around me is kind of
>> "old-fashioned",
>>  and they just can't (or their minds are just not ready to) get that
>>  things are changing all the time, and what was the best yesterday,
>>  doesn't necessarily the best today.
>> 
>>  .Net has proven itself over the years, but that was all about
>> Microsoft
>>  .Net and only under Windows platforms, and still when you say .Net,
>>  it's associated in people minds with Microsoft and Windows, of
>> course
>>  because it is, as there are relatively few people who know about
>> ECMA
>>  or ISO CLI and C#, but my point is that the trend is still "on
>> Linux,
>>  anything but .Net".
>> 
>>  Anyway, long story ;) I'm also new to Mono, and I wan

[Mono-list] the GC define ALL_INTERIOR_POINTERS - needed?

[Bruce Wilkie]

hi all - quick question.  does anyone happen to know the reason mono needed 
this #define set?
thx!
bruce
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] SecurityIdentifier and IdentityReference op_Equality

[Bruce Wilkie]

while doing some offline code analysis, these two classes in the 
System.Security.Principal namespace appear to have infinite recursion in their 
op_Equality methods:

C#:

  public static bool operator == (SecurityIdentifier left, SecurityIdentifier 
right)
  {
   if (left == null)
return (right == null);
   if (right == null)
return false;
   return (left.Value == right.Value);
  }

IL:

  IL_:  ldarg.0
  IL_0001:  ldnull
  IL_0002:  call   bool 
System.Security.Principal.SecurityIdentifier::op_Equality(class 
System.Security.Principal.SecurityIdentifier,

  class System.Security.Principal.SecurityIdentifier)
  IL_0007:  brfalse.s  IL_0011
  IL_0009:  ldarg.1
  IL_000a:  ldnull
  IL_000b:  call   bool 
System.Security.Principal.SecurityIdentifier::op_Equality(class 
System.Security.Principal.SecurityIdentifier,

  class System.Security.Principal.SecurityIdentifier)
  IL_0010:  ret
  IL_0011:  ldarg.1
  IL_0012:  ldnull
  IL_0013:  call   bool 
System.Security.Principal.SecurityIdentifier::op_Equality(class 
System.Security.Principal.SecurityIdentifier,

  class System.Security.Principal.SecurityIdentifier)
  IL_0018:  brfalse.s  IL_001c
  IL_001a:  ldc.i4.0
  IL_001b:  ret
  IL_001c:  ldarg.0
  IL_001d:  callvirt   instance string 
System.Security.Principal.IdentityReference::get_Value()
  IL_0022:  ldarg.1
  IL_0023:  callvirt   instance string 
System.Security.Principal.IdentityReference::get_Value()
  IL_0028:  call   bool System.String::op_Equality(string,
   string)
  IL_002d:  ret


i don't think i use those two functions, but just curious if others have seen 
this.  am i missing something?  :)

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

[Mono-list] dup_type in reflection.c - leaking memory?

[Bruce Wilkie]

hey all, quick question while trying to understand some of the generics support 
in mono.

dup_type uses g_new0(...), however mono_metadata_free_type(...) assumes mempool 
allocation.  is there a disconnect here, or am I missing something obvious?  :)

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

[Mono-list] ves_icall_FieldInfo_SetValueInternal

[Bruce Wilkie]

i'm seeing a bug where setting a static field uses the class the field is on:
--
MonoVTable *vtable = mono_class_vtable (mono_object_domain (field), 
field->klass);
--

consider, however, that the static field is coming from a base class.  in this 
case, it seems that vtable should really be the vtable of the base class?  i 
don't see a way to trivially understand when this traversal needs to happen, 
however.
 
end result, I end up crashing in mono_set_value(...), because dest is null, 
because the vt data for the top level class was null (correct, because it has 
no statics).
 
thoughts?  am I imagining things?
 
thx,
bruce
 
 
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Re: another request for help: SecurityManager

[Bruce Wilkie]

yes, the Mono interpreter.  I'm using 1.1.8 - I don't
need (yes, prolly ever for this project) .NET 2 stuff.

btw, I think my current problem is byte swapping.  the
interp package is pretty loose on type safety.  so
putting a 4 byte int into memory, then chopping off
the first 2 bytes to convert to a 2 byte int works
different in BE vs LE.  i'm updating my code to handle
this - i'm hopeful that was my problem (or at least
one of them).

thx,
bruce

--- Robert Jordan <[EMAIL PROTECTED]> wrote:

> Bruce,
> 
> > I'm having some trouble getting Mono to run the
> same
> > on two different platforms - one x86, one PPC. 
> Again,
> > I'm unable to generate code at runtime, so I'm
> using
> > the interp package + handwritten thunks (which I
> did
> > get working yesterday - string ctors fooled me).
> 
> What do you mean with "interp"? The old yet
> unsupported
> Mono interpreter? Which Mono version are you using?
> 
> Robert
> 
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 

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

[Mono-list] another request for help: SecurityManager

[Bruce Wilkie]

Hello list - another request for help, in hopes of
saving me some time.

I'm having some trouble getting Mono to run the same
on two different platforms - one x86, one PPC.  Again,
I'm unable to generate code at runtime, so I'm using
the interp package + handwritten thunks (which I did
get working yesterday - string ctors fooled me).

On the two platforms, a trace of functions starts out
looking the same, until the PPC platform starts to
deal with a SecurityManager...  the PC never does
that.  in the end, the PPC platform will fail, due to
a config handler class not supporting a requested
interface.  :(  the traces (snipped to the important
stuff):

PC

...
VES:  System.Char..cctor()
System.Char.GetDataTablePointers(byte*&,byte*&,double*&,uint16*&,uint16*&,uint16*&,uint16*&)
VES: 
System.Char.GetDataTablePointers(byte*&,byte*&,double*&,uint16*&,uint16*&,uint16*&,uint16*&)
VES:  System.Char.ToString()
VES:  System.String..cctor()
VES: 
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,System.RuntimeFieldHandle)
VES:  System.RuntimeFieldHandle.get_Value()
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,intptr)
VES: 
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,intptr)
System.String..ctor(char,int)
VES:  System.String..ctor(char,int)
VES:  System.Diagnostics.DefaultTraceListener..ctor()
VES:  System.Diagnostics.TraceListener..ctor(string)
VES:  System.MarshalByRefObject..ctor()
VES: 
System.Diagnostics.TraceListener.set_Name(string)
VES: 
System.Diagnostics.TraceListenerCollection.Add(System.Diagnostics.TraceListener)
VES: 
System.Diagnostics.TraceListenerCollection.InitializeListener(System.Diagnostics.TraceListener)
... 
goes on to work fine

PPC

...
VES:  System.Char..cctor()
System.Char.GetDataTablePointers(byte*&,byte*&,double*&,uint16*&,uint16*&,uint16*&,uint16*&)
VES: 
System.Char.GetDataTablePointers(byte*&,byte*&,double*&,uint16*&,uint16*&,uint16*&,uint16*&)
VES:  System.Char.ToString()
VES:  System.String..cctor()
VES: 
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,System.RuntimeFieldHandle)
VES:  System.RuntimeFieldHandle.get_Value()
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,intptr)
VES: 
System.Runtime.CompilerServices.RuntimeHelpers.InitializeArray(System.Array,intptr)
System.String..ctor(char,int)
VES:  System.String..ctor(char,int)
VES: 
System.Environment.GetEnvironmentVariable(string)
VES:  System.Security.SecurityManager..cctor()
VES: 
System.Security.Permissions.SecurityPermission..ctor(System.Security.Permissions.SecurityPermissionFlag)
VES:  System.Security.CodeAccessPermission..ctor()
VES: 
System.Security.Permissions.SecurityPermission.set_Flags(System.Security.Permissions.SecurityPermissionFlag)
VES:  System.Object..ctor()
...
goes on to throw "system.diagnostics does not
implement
System.Configuration.IConfigurationSectionHandler" in
System.Configuration.ConfigurationData:CreateNewHandler.


it feels like i just have some compile flag not set or
something on the PPC...  this is running the same
assemblies (mscorlib.dll and system.dll) on both
platforms.  The embedding of mono into the app is a
bit different, but pretty close - I don't think the
problem is there.  i've tried taking machine.config
down to almost nothing, but that doesn't help either. 


i'll be spending the day working on this, but if
someone has pointers to help me out, i'd love to hear
from you.

thanks,
bruce

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

[Mono-list] Question about Mono to native function calling

[Bruce Wilkie]

Hello Mono lists - I'm emailing both lists in hopes
someone has a tip or two.

some background - I'm in a situation where i can't
generate code at runtime.  so I'm trying to use the
interp package, by embedding it into my application. 
my current test case is pretty simple:

   
System.Diagnostics.Trace.WriteLine("Hello");

that one line is sooo deceptively simple...

one challenge that I have to solve is that even the
interp package wants to generate code at runtime - for
each native function called (internal calls and
PInvoke) a little bit of ASM gets generated to allow
variables on the managed interp stack to flow to the
native function, as well as a return value. 
currently, based on the sig of the function being
called, I'm looking up a hand-written function to
replace the little bit of ASM that would normally be
generated.  This is (for the most part) working great,
and I get 41 native calls in before things go wrong. 
:(

like I said, that one line is deceptively simple...

So, I'm hoping the lists have an idea about how those
hand-written functions should look?  for example, take
the native function GetDataTablePointers.  it returns
void, and it's sig is:

System.Char.GetDataTablePointers(byte*&,byte*&,double*&,uint16*&,uint16*&,uint16*&,uint16*&)

my first thought was to do this:

void
Thunk_void_refintptr_refintptr_refintptr_refintptr_refintptr_refintptr_refintptr(MonoFunc
callMe, void *pRetval, void *this_obj, stackval
*arguments)
{
typedef void (*Func)(void**, void**, void**,
void**, void**, void**, void**);
(*(Func)(callMe))((void**)arguments[0].data.p,
(void**)arguments[1].data.p,
(void**)arguments[2].data.p,
(void**)arguments[3].data.p,
(void**)arguments[4].data.p,
(void**)arguments[5].data.p,
(void**)arguments[6].data.p);
}


and the native function it calls is:

static void
ves_icall_System_Char_GetDataTablePointers (guint8
const **category_data,
guint8 const **numeric_data,
gdouble const
**numeric_data_values,
guint16 const
**to_lower_data_low,
guint16 const
**to_lower_data_high,
guint16 const
**to_upper_data_low,
guint16 const
**to_upper_data_high)
.
.
.

another example, InternalTrim.  It returns a
MonoString*, and it's sig is:

System.String.InternalTrim(char[],int)

my thought was to do this:

void Thunk_intptr_thisobj_intptr_int(MonoFunc
callMe, void *pRetval, void *this_obj, stackval
*arguments)
{
stackval* retval = (stackval*)pRetval;

typedef void* (*Func)(void*, void*, int);
retval->data.p = (*(Func)(callMe))(this_obj,
arguments[0].data.p, arguments[1].data.i);
}


and the native function it calls is:

MonoString * 
ves_icall_System_String_InternalTrim (MonoString *me,
MonoArray *chars, gint32 typ)
.
.
.

again - most everything works.  I'm prototyping all
this on the PC first.  When I enable original
mono_arch_create_trampoline function (it generates
code at runtime), everything is fine - I see "Hello". 
when I enable my version of
mono_arch_create_trampoline, that looks up sigs and
gives back hand-written thunks, I end up dying in
ves_icall_System_String_InternalJoin, because the
first arg being passed is junk.  :(  this is all with
the interp engine, so i can step almost everything if
someone has a pointer what to look for.  please feel
free to offlist email me for more details if you think
you can help but have more questions.

thanks in advance lists!
bruce


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

Re: [Mono-list] Running Mono on platforms that can't generate code at runtime.

[Bruce Wilkie]

Jon - thx for the background.  

In my case, it would actually be better to pre-compile
the entire program to native code before execution. 
Plus, we'll never be using the code generation stuff
in the Reflection API.

At least it's idea for us to try.  =)

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

[Mono-list] Running Mono on platforms that can't generate code at runtime.

[Bruce Wilkie]

Is anyone doing this / has done this?  Specifically,
on systems that can't alloc memory that can later be
executed.

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

[Mono-list] Mono, Win32 fibers. Almost there...

[Bruce Wilkie]

One final question in hopes someone has an idea.  I've
gotten fibers to work with both the JIT and Interp
engines.  However, I'm having problems with garbage
collection.  That is, objects seem to be getting
collected when the shouldn't.

Could it be because the stack of the fiber isn't
registered with the boehm collector?  does that sound
right?

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

RE: [Mono-list] Mono and Win32 fibers

[Bruce Wilkie]

I have my appliction hosting the MS CLR and running
fibers.  Works fine.  I simply use threads when I need
managed debugging - VS.NET can't debug across the COM
call to make the MS CLR aware of the fiber switch
(both 2003 and 2005).  Of course, the performance
benefit of threads is noticable - simply switching
between 800 threads takes ~8ms on a 3+Ghz cpu, while
the same number of fibers only take ~1ms.

I'm guessing the TLS that Mono uses is what's getting
confused.  Debugging against the interp stuff, I'm
close to narrowing down exactly what's breaking.  I
was just hoping someone in the community had already
done it.  =)

On a related note - if I could swap out the managed
stack / execution point, and later swap that back in -
that would be another way to go.  This is just to get
LUA-like coroutines - I'll never need to fiber native
code...

thx,
bruce


--- "Chad Z. Hower" <[EMAIL PROTECTED]> wrote:

> :: It's unlikely to ever work.  Please read the
> "Dire warnings about
> :: fibers" section at:
> 
> A bit off topic - but I've done a lot of work with
> Fibers. Delphi supports
> fibers just fine using the Indy library. The VCL
> (Kind of like STL / FCL for
> Delphi) had 1-2 items, but appropriate hooks allows
> Indy to handle them.
> 
> I've looked at making it work in .NET and have had
> some reasonable success,
> but the biggest problem is debugging them. VS gets
> really confused... Mind
> you the Delphi debugger can be interesting to use
> with fibers too, but it
> does work and you can even tell what fiber you are
> in with some
> "extensions".
> 
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 

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

[Mono-list] Mono and Win32 fibers

[Bruce Wilkie]

has anyone gotten this to work?  I'd love tips. 
Currently, using Mono with fibers (embedding in a
Win32 app) will crash when executing managed code from
the fiberproc.

thx for any help!
bruce
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] Building / Embedding Mono on Win32

[Bruce Wilkie]

Hello all.

I'm looking into the idea of using Mono as an embedded
scripting language for an application my team is
working on.  Currently, we're using MS.NET v1.1, which
is all working great.  But, we'd like to look at other
options besides MS.NET - plus, not shut the door on
cross platform.

We're using VS.NET2003, and would like to keep using
it - all our primary development would be on WinXP.

My first attempt was to embed Mono, via the tutorial
on the Mono site, using the Win32 install.  As I
didn't have any .libs to link against, I then tried to
build Mono from the VS.NET solution from svn.  This
however doesn't build.

after looking thru the makefile, I've used bison to
get monoburg going, and monoburg to inssel.c /
inssel.h, and genmdesc to get cpu-pentium.h.

libmono builds / links after that.

however, mono *still* didn't build.  I had to edit the
VSDependancies\include\config.h file and #define
HAVE_BOEHM_GC and #USE_INCLUDED_LIBGC.  I was doing
that to get rid of the link errors that resulted from
not having any GC.

i'm finally left with 4 link errors:
mono_local_regalloc ref in mono_arch_local_regalloc
mono_magic_trampoline ref in
mono_arch_create_trampoline_code
mono_aot_trampoline ref in
mono_arch_create_trampoline_code
mono_class_init_trampoline ref in
mono_arch_create_trampoline_code

also, the Embedded Samples, Libraries, and Tools
projects all don't load in that solution - because
they seem to have no project associated with them.

Anyway, does someone have pointers here?  Ideally, I'd
like a Win32 solution I can build that will give me
Mono .lib files, which I can link against (static or
.DLL, static is prolly better) to embed Mono into
another native Win32 application.  i really, really
don't want to use cygwin / gcc.  i'm not unix / linux
savvy.

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