gmane.comp.gnome.mono.devel

build faild in libgc

KISHIMOTO, Makoto — 2012-05-24T05:36:33

Hello,

In my FreeBSD box, since e7f3bbad80fe04bea1a055e870d856a22003d34d of Mono trunk
build failed. Following is error message.

./doltlibtool --mode=compile --tag=CC gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE_VERSION=\"6.6\" -DPACKAGE_STRING=\"libgc-mono\ 6.6\" -DPACKAGE_BUGREPORT=\"Hans_Boehm< at >hp.com\" -DPACKAGE_URL=\"\" -DGC_FREEBSD_THREADS=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I../../mono/libgc/.. -I../../mono/libgc/include  -DGC_FREEBSD_THREADS -DPLATFORM_BSD -I/usr/local/include -D__default_codegen__  -g -mno-tls-direct-seg-refs   -MT pthread_support.lo
  -MD -MP -MF .deps/pthread_support.Tpo -c -o pthread_support.lo ../../mono/libgc/pthread_support.c
../../mono/libgc/pthread_support.c: In function 'GC_register_altstack':
../../mono/libgc/pthread_support.c:870: error: 'main_pthread_self' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:870: error: (Each undeclared identifier is reported only once
../../mono/libgc/pthread_support.c:870: error: for each function it appears in.)
../../mono/libgc/pthread_support.c:871: error: 'main_stack' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:872: error: 'main_stack_size' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:873: error: 'main_altstack' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:874: error: 'main_altstack_size' undeclared (first use in this function)
../../mono/libgc/pthread_support.c: In function 'GC_thr_init':
../../mono/libgc/pthread_support.c:1114: error: 'main_pthread_self' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:1115: error: 'main_stack' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:1116: error: 'main_stack_size' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:1117: error: 'main_altstack' undeclared (first use in this function)
../../mono/libgc/pthread_support.c:1118: error: 'main_altstack_size' undeclared (first use in this function)
gmake[3]: *** [pthread_support.lo] Error 1

Thnaks.

Mono profiler on windows

Daniel Bullington — 2012-05-23T20:00:21

Is the profiler supported in windows? I try to do the following and get error:

Mono --profile test.exe

The log profiler wasn't found in the main executable nor could it be
loaded from mono-profiler-log.

Used 2.11 and 2.10.8 on both win xp 32 bit and win 7 64 bit.

Thanks

~

/dpb

Daniel Bullington

CS0589 on arm Linux

Torsten Harenberg — 2012-05-23T18:26:01

Dear all,

I'm new to mono (doing anything than just running C# "binaries" on
Linux and or Mac). Please excuse if this is the wrong mailing list (or
a silly issue).

I try to run a small application written by someone else on a
Pandaboard (ARM Linux, Ubuntu 12.04 Server).

After just trying to run the application just by downloading the file
and start "mono dvrptr.exe" did not work (error message at the end of
this mail), I grabbed the sources and tried to compile the application
on the device itself. I used the mono installation provided by Ubuntu
which reported itself as being:

harenber< at >pandaboard:~/dvrptr$ mono -V
Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors.
www.mono-project.com
TLS:           __thread
SIGSEGV:       normal
Notifications: epoll
Architecture:  armel,vfp
Disabled:      none
Misc:          softdebug
LLVM:          supported, not enabled.
GC:            Included Boehm (with typed GC and Parallel Mark)

However, trying to compile the stuff with "xbuild dvrptr.csproj" the
compiler stops here:

aprs.cs(60,70): error CS0589: Internal compiler error during parsing
qthloc.cs(88,100): error CS0589: Internal compiler error during parsing
Form1.cs(249,39): error CS0589: Internal compiler error during parsing
Form1.Designer.cs(853,91): error CS0589: Internal compiler error during parsing

I couldn't find anything fishy at these positions, for example the
first one is the line inside this try block:

            int range_miles = 100;
            try
            {
                range_miles = (int)(Convert.ToDouble(myRange) * 0.6214);
                }
            catch
            {
            }

Trying the same on a x86_64 machine running the same Linux
distribution builds the application fine and it can be started
afterwards.

I put the complete source code at

http://www.atlas.uni-wuppertal.de/~harenber/dvrptr.zip

Is this a bug or is this generally not possible on ARM based machines?

Thanks for any hint!

Kind regards,

  Torsten

Appendix: error message while running the x86_64 compiled app:

harenber< at >pandaboard:~/dvrptr$ mono dvrptr.exe
Stacktrace:

  at System.Drawing.Font.CreateFont
(string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool)
<0x0013f>
  at System.Drawing.Font..ctor
(string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool)
<0x0007f>
  at System.Drawing.Font..ctor (string,single,string) <0x00057>
  at (wrapper remoting-invoke-with-check) System.Drawing.Font..ctor
(string,single,string) <0xffffffff>
  at System.Drawing.SystemFonts.get_DefaultFont () <0x0005b>
  at System.Windows.Forms.Theme..ctor () <0x0002b>
  at System.Windows.Forms.ThemeWin32Classic..ctor () <0x00013>
  at System.Windows.Forms.ThemeVisualStyles..ctor () <0x00013>
  at System.Windows.Forms.ThemeEngine..cctor () <0x00063>
  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
  at System.Windows.Forms.X11DesktopColors..cctor () <0x000a7>
  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
  at System.Windows.Forms.XplatUIX11..ctor () <0x0014b>
  at System.Windows.Forms.XplatUIX11.GetInstance () <0x0004b>
  at System.Windows.Forms.XplatUI..cctor () <0x0010b>
  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
  at System.Windows.Forms.Application.EnableVisualStyles () <0x0001b>
  at dvrptr.Program.Main () <0x00067>
  at (wrapper runtime-invoke) object.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:


Debug info from gdb:


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

Aborted
harenber< at >pandaboard:~/dvrptr$

Re: Mono JIT Init for two different versions

Rodrigo Kumpera — 2012-05-23T16:26:12

Loading two runtimes in the same process is not something mono was designed
to. You might encounter all
sort of issues when doing so.
You'll have to call all mono functions using function pointers and hope it
works as expected.

Multiple GCs in the same process will be racy and you might end up getting
all sort of crash deadlocks.

Good luck.


On Tue, May 22, 2012 at 11:27 AM, Dimitri Kirsanoff <
dimitri.kirsanoff< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Regression with Linux update

Rodrigo Kumpera — 2012-05-23T16:23:00

There is no plan to support W^X environments in the runtime. But if you
want to contribute code to support it, it would be welcome.


On Tue, May 22, 2012 at 10:01 PM, the mad mole <madmole< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Mono JIT Init for two different versions

Dimitri Kirsanoff — 2012-05-22T14:27:46

I want to initialize different mono run time (different version of mono
like 2.8, 2.11)  in a single process.
One application package is using mono-2.8 run time and other application is
using mono-2.11 run time.


I am trying to initialize mono two times for two different versions, i.e.
two different versions of the library.
To try that I found that getting dlsym function pointers from sharedobject
and calling function pointer to "mono_jit_init" may make it work.

But here scenario seems to be bit different, as I need to initialize mono
library for two different versions in same process


The call hierarchy of call is as following

My_Application
      |
      |
      |
     \/
libraryInterfaceToMono.so
      |
      |
      |
     \/
libmono-2.so (alternately for 2.8 and 2.11)


Using my application I am initializing monoruntime share objects using
mono_jit_init for version 2.11, but there is another version 2.8 for that
another mono_jit_init call is needed.
For calling mono_jit_init I am using dlsym for mono_jit_init. I want to
know can I do it for two different versions in one process.

Can I use mno_jit_init call twice so that I can initialize two versions ( I
am using 2.8 and 2.11 ) alternately?


Instead of mono_jit_cleanup I am using mono_runtime_unload api as
mono_jit_cleanup calling from a function is giving me abrupt crashes.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Image.PropertyItems empty with mono

Denys — 2012-05-22T07:23:25

Hi Christian,
I just opened a new Bug in Bugzilla with *# 5228*.
Hope they find a solution.
Best regards
Denys

--
View this message in context: http://mono.1490590.n4.nabble.com/Image-PropertyItems-empty-with-mono-tp4397247p4649487.html
Sent from the Mono - Dev mailing list archive at Nabble.com._______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Regression with Linux update

the mad mole — 2012-05-23T01:01:14

I wanted to post an update for the benefit of mono maintainers.  The kernel
team of our SOC vendor was able to get (at least some of) the try-catch
tests to pass (including the example below) by disabling the XI (execute
inhibit, similar to x86 NX) feature, which was recently added to their MIPS
core (doing some research, this appears to be part of MIPS' SmartMIPS ASE,
which also includes a bunch of crypto functions).

The speculation is that some of the jitted code is getting written to pages
mapped with just PROT_READ | PROT_WRITE permissions: with XI enabled the
page would need PROT_EXEC as well.  If anyone knows when this might be
addressed, posting to this list would be much appreciated.

TMM

On Tue, May 15, 2012 at 6:49 PM, the mad mole <madmole< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Image.PropertyItems empty with mono

Rafael Teixeira — 2012-05-22T11:52:57

lbigdiplus, reads exif data for jpeg files, if it was compiled to use
libexif, as this extract from jpegcodec.c shows:

#ifdef HAVE_LIBEXIF
if (st == Ok){
    dstream_get_exif_buffer (loader, &ptr, &length);
    load_exif_data (exif_data_new_from_data (ptr, length), *image);
}
#endif


I'm not sure if Mono is compiled for MacOSX with the libexif dependency,
which may be the cause of your problem.
From libexif project page, seems that MacOSX doesn't provide libexif, per
se, you need to use Fink, or some other tool to add it manually, so...

A custom build of libgdiplus with libexif may solve your problem, but I
would rather explore some alternatives that may even avoid having to load
the full image in memory just to get the exif data, see:

http://stackoverflow.com/questions/42017/what-is-the-best-exif-library-for-net
http://stackoverflow.com/questions/58649/how-to-get-the-exif-data-from-a-file-using-c-sharp

Hope it helps,

Rafael "Monoman" Teixeira
---------------------------------------
"The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'"
Isaac Asimov
US science fiction novelist & scholar (1920 - 1992)


On Mon, May 21, 2012 at 4:24 PM, ChristianManthey <info< at >manthey-it.de>wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

TypeLoadException when porting WCF-application to Mono

Ole Bromose — 2012-05-21T19:56:03

Hi,

I'm currently porting a WCP application to Mono. The application has 4 
netTcpBindings which are self-hosted. When trying to start the first 
Service Host, I get an exception and a text in the Console:

Exception:

System.TypeLoadException: Could not load type 
'System.ServiceModel.Description.ServiceCredentials' from assembly 
'System.ServiceModel, Version=4.0.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089'.

   at System.ServiceModel.ServiceHost..ctor (System.Type serviceType, 
System.Uri[] baseAddresses) [0x00000] in <filename unknown>:0


Console:

Could not load signature of 
System.ServiceModel.Description.ServiceCredentials:CreateSecurityTokenManager 
due to:

Could not load signature of 
System.ServiceModel.Security.SecurityCredentialsManager:CreateSecurityTokenManager 
due to:


I originally had "security=Transport". Changing this to "security=None" 
had no effect.

The ServiceCredentials class should be in System.ServiceModel. Is it not 
implemented in Mono? If not, is there a work-around?

Thanks,
Ole

Re: Image.PropertyItems empty with mono

ChristianManthey — 2012-05-21T19:24:23

No, unfortunatly i did not find a solution so far and also did not get any
response on how this could be solved.
If you have an idea, please share it.

Christian

--
View this message in context: http://mono.1490590.n4.nabble.com/Image-PropertyItems-empty-with-mono-tp4397247p4648691.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

Re: Multiple mono_jit_init/mono_jit_cleanup issue

Rodrigo Kumpera — 2012-05-21T12:42:08

The runtime was never meant to be loaded/unloaded multiple times in the
same process. If you need so, you'll have
to fix all bugs you find in your way.


On Fri, May 18, 2012 at 6:58 AM, Anshya Aggarwal
<anshya.aggarwal< at >gmail.com>wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Multiple mono_jit_init/mono_jit_cleanup issue

Anshya Aggarwal — 2012-05-18T09:58:59

Hi,

I am working on some application in which I am required to call
mono_jit_init multiple times. When I run my application for the first time
I do mono_jit_init then mono_jit_cleanup everything works fine, problem
occurs when I try do mono_jit_init again(this time to load different
runtime[this is my requirement :(]). And on the mono website it is
mentioned that we should init mono runtime once in a process. I have
searched for this issue and didnt find any working solution. So, I want to
know is there anything possible that can be done for this issue? And also
if possible can anybody elaborate why mono_jit_init multiple times is not
supported? Is it related to some GC cleanup issue?

Re: Image.PropertyItems empty with mono

Denys — 2012-05-18T06:56:57

Christian,
I have the same problem, did you find a solution ?
Thank you

Denys

--
View this message in context: http://mono.1490590.n4.nabble.com/Image-PropertyItems-empty-with-mono-tp4397247p4644173.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

Re: Current Implementation of Async Sockets

james — 2012-05-19T09:05:55

Would there be any mileage to looking at libuv?  It seems to wrap IOCP 
and libev. Its not clear whether the limited performance implied here 
(http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks) 
is a reflection of the single-threaded node engine, or more intrinsic. 
I'd expect the former; libev is designed for reactive use in a single 
thread environment, but does allow you to run multiple event handlers so 
you should be able to run a handler per core.

It would be nice if mono aio could approach the performance of Java nio, 
but i don't think it ever has.

Re: Compiling Mono with Visual Studio and .pdb files

Marek Safar — 2012-05-19T08:41:06

Hi,


That's not correct, all projects were regenerated recently. About the
corlib-build issue, you don't need to build any of *-build.csproj projects,
they are needed only on systems with no .NET 4 API. I have done some work
on cleaning this up recently but it's not yet finished.

Marek

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Compiling Mono with Visual Studio and .pdb files

2012-05-19T05:05:31

Hi Miguel, mono-devel subscribers,

Thanks Miguel, your description helped me figure out a couple of key things. I'm gradually getting on top of the mcs/class  build process and its translation to VS solutions/projects. There was already a lot of prior work done by Sebastien Pouliot (I think) a few years ago.

One thing I came across is that the project for "corlib-build" builds if targeting .Net 2.0, but fails on .NET 4.0 with a few errors such as follows. The only related issue I found (https://github.com/nikhilk/scriptsharp/issues/156) suggests that .NET4.5 may be the issue. Any advice on handling this is welcome. I need to add project dependencies on a couple of outputs from the "basic" profile to overcome the issue and still target 4.0. However I do not like the departure from the cygwin build process.

The type 'System.Diagnostics.TextWriterTraceListener' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.                C:\src\mono\mono\mcs\class\corlib\System.Diagnostics\ConditionalAttribute.cs         35           11           corlib-build
The type 'System.Collections.Generic.ISet`1<T0>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.                C:\src\mono\mono\mcs\class\corlib\System.Collections.Generic\CollectionDebuggerView.cs               32           11                corlib-build


Cheers,
J-M

From: Miguel Mudge [mailto:michael.mudge< at >welchallyn.com]
Sent: Saturday, 12 May 2012 12:34 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: mono-devel-list< at >lists.ximian.com
Subject: Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files

Making progress with msvc, with a lot of second guessing, but I cannot seem to fully get out of the circular dependencies easily. After fixing a few things, there seems to be a two to three stage build process ('basic', 'build' and, well, the huge rest). I can build the 'basic' stuff with references being the MS.NET<http://MS.NET> libraries it defaults to, but the 'build' phase fails both with dependencies on the basic system or the MS.NET<http://MS.NET> libraries (missing implementations or ambiguous references). Well done for you to sort it all out.

Our build uses *none* of the MS.NET<http://MS.NET> libraries - every project *only* depends on other projects in the same Mono solution file.  All of the projects reference the mscorlib project built in that solution, *never* Microsoft's mscorlib.dll (see Project Properties -> Build -> Advanced -> "Do not reference mscorlib.dll").

mscorlib has these compilation symbols: INSIDE_CORLIB LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0
And it has a few links to external files: Aes.cs, Consts.cs, Locale.cs, MonoTODOAttribute.cs, SemaphoreFullException, TimeZoneInfo.AdjustmentRule.cs, TimeZoneInfo.Android.cs, TimeZoneInfo.cs, TimeZoneInfo.TransitionTime.cs.
We were able to determine most of those files by looking at corlib.dll.sources - definitely look at the .sources files for the other DLLs too... although it's better to look at the Linux build in-action.

You should be able to build mscorlib with the above info.  Here is the info for system (notice the dash, as in "minus"):

System -XML -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0
Depends on: mscorlib project

System.Xml then depends on the above.

System -Config: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0 CONFIGURATION_2_0 XML_DEP
Depends on: mscorlib project, System.Xml project

Mono.Security then depends on mscorlib and System -Config
Mono.Configuration then depends on mscorlib, System.Xml and System -Config

System: LIBC NET_1_1 NET_2_0 NET_3_0 NET_3_5 NET_4_0  CONFIGURATION_2_0 CONFIGURATION_DEP XML_DEP SECURITY_DEP
Depends on: mscorlib, System.Xml, System.Configuration, Mono.Security

Don't trust the above though - I think there's a missing step, there may need to be 4 builds of System (one before XML_DEP is added, one before SECURITY_DEP is added, one before CONFIGURATION_DEP is added, then the final build with all 3 constants added).

The best thing to do is compile mcs in Linux and gather this information:
- The order in which each library is built - including if it is built multiple times.
- What dependencies each build has.
- What compile-time constants are set.
- What files are a part of the build.

I would definitely add you to my list of super-cool people if you duplicated / modified the Linux build process to capture the above 4 things to generate a working MSVC solution - it's just XML files, an xslt might do this well.  I'm sure the Mono folks would be happy to include the output of such a process in each source release to make it easier on us MSVC-centric folks.

- Kipp

It sounds like your approach is similar to that in the 'msvc' folder and related makefile targets, but I probably miss many details. I found that I could run the make targets generating csproj files only after a successful 'make' on cygwin, using anciliary files (.response) from the call to 'make'. I wonder how similar to what you describe this is. My question may be naive, but what do you mean by compiler constants, build order and files used? Are you post-processing the captured output redirected to a file?

I never really had to do much with makefiles, and with a codebase the size of Mono, this is a steep learning curve.

Cheers,
J-M



From: Miguel Mudge [mailto:michael.mudge< at >welchallyn.com<mailto:michael.mudge< at >welchallyn.com>]
Sent: Tuesday, 8 May 2012 12:30 AM
To: Perraud, Jean-Michel (CLW, Black Mountain)
Cc: mono-devel-list< at >lists.ximian.com<mailto:mono-devel-list< at >lists.ximian.com>
Subject: Re: [Mono-dev] Compiling Mono with Visual Studio and .pdb files

We've been building the 2.10.2 Mono framework libraries in Visual Studio.  We performed a build on Linux, copied the compiler constants, build order and files used, and use this information to create the Visual Studio project - we did not start from Mono's msvc.  It was a very manual process, but I am pleased with the output.

We don't compile all of the libraries since our embedded device doesn't have the space.  Most of the difficulty is in the roots anyways - for example, we have several System.dll projects, which are incrementally more dependent, in order to solve circular dependency problems.  Picture attached:

It seems like the only way to reliably "copy" the build process into MSVC is to actually run the mcs make.  You might be able to hack it a bit to mock a build, grab the compile flags/files and then generate msvc files from that.

Thanks,
Michael "Kipp" Mudge | Welch Allyn | Lead Software Engineer
315-554-4057<tel:315-554-4057> | michael.mudge< at >welchallyn.com<mailto:michael.mudge< at >welchallyn.com>



_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Xmx analogue

Danil Yuferev — 2012-05-18T16:59:35

Hello! Does Mono have Java Xmx-analogue?
Help me, please)
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: Getting Started

Adhir Ramjiawan — 2012-05-18T16:30:42

Hi Micheal!

I will definitely consider using mono for a proof of concept I'll
working on shortly.

Thank you again for everything!

Adhir


On Fri, May 18, 2012 at 5:07 PM, Miguel Mudge
<michael.mudge< at >welchallyn.com> wrote:

Re: Current Implementation of Async Sockets

longway77 — 2012-05-18T15:41:54

Oh, this looks like a rather advanced one!
After some scanning through the sources he seems to have written the server
in c# on top of mono and then he extended (or modified) the implementation
of monos socket implementation.
It's not quite the type of server I want to write and I might be a little
overwhelmed by what was done there, but I'll have a look.
I would prefer thought, if the implementation in mono worked performant.

I found some links which hint on some "recent?" changes to that
implementation, like that one:
http://c-cpp.r3dcode.com/files/mono/2/10.2/mono/metadata/tpool-epoll.c

It's really hard to find updated documentation on the project. Am I looking
in the wrong places? On the website, most of the stuff is seriously
outdated.

--
View this message in context: http://mono.1490590.n4.nabble.com/Current-Implementation-of-Async-Sockets-tp4642031p4644669.html
Sent from the Mono - Dev mailing list archive at Nabble.com.

Re: Getting Started

Miguel Mudge — 2012-05-18T15:07:17

No problem, I love the enthusiasm.  I couldn't tell you how to get involved
in the Mono project - someone else will point you in the right direction.

There is no way to know what Microsoft will do and if they really feel that
their toes are being stepped on, but Mono has a lot going for it.
 Microsoft has developed and published the CLR under the Microsoft
Community Promise.  I think this basically means that Mono's core CLR
implementation is safe.  Microsoft has even provided Mono some guidance and
clarification on the details of the standard.  The legal safety of the
libraries outside of the core framework are not quite as clear - Microsoft
has not stated any "opinion" on Mono's capabilities, but they've had plenty
of time to act.  If Microsoft pulls the rug out from under Mono, I think
people may choose against Visual Studio in favor of Java due to portability
issues, and Microsoft doesn't want that.  If Oracle loses their case
against Google, it may suggest that all of Microsoft's public-facing
interfaces can legally be reimplemented.  If Oracle wins, Google might take
a serious look at the Mono framework as an alternative.  (this is so very
exciting!)  There's more information here:
http://en.wikipedia.org/wiki/Mono_(software)#Mono_and_Microsoft.27s_patents

Yes, Mono's assemblies are all written in C#.  They compile using Mono's C#
compiler, but I have been able to compile them under Visual Studio too
(that takes a bit of organizing).  At the "bottom" of those framework
libraries are internal and P/Invoke calls that bridge the core
functionality with native functions.

Before you get too far ahead of yourself, get MonoDevelop and play around a
bit - see what might benefit from your contributions.

Thanks,
Michael "Kipp" Mudge | Welch Allyn | Lead Software Engineer
315-554-4057 | michael.mudge< at >welchallyn.com



On Fri, May 18, 2012 at 10:08 AM, <adhirramjiawan0< at >gmail.com> wrote:

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list< at >lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list