Re: [Mono-dev] Building Mono on Linux/Alpha
Zoltan Varga wrote: Hi, The best approach, as I said previously, is to make sure all the tests (except perhaps the pinvoke/marshalling tests) run under mono/tests. Since these tests are much simpler than mcs, it is much easier to track down the possible problems. Ok, thank you for advice. I checked the mono/tests and see that there are more tests than in regression testsuite I downloaded from the site (it is said they are old). I will try them out. Playing with mcs I got into alpha-specific problem. In my current aproach working with consts and method addresses requires that the size of generated code should be less than 32kb. The mcs.exe has yyparse method that was translated into 160kb size native code and aborted on internal assertions. :( I would have to find a solution for that too. Regards, -- Sergey Tikhonov Solvo Ltd. Saint-Petersburg, Russia [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announce: Mono.Fuse (+ Required Mono.Posix Changes)
Mono.Fuse is a binding for the FUSE library, permitting user-space
file systems to be written in C#.
Why?
===
I read Robert Love's announcement of beaglefs, a FUSE program that
exposes Beagle searches as a filesystem. My first thought: Why
wasn't that done in C# (considering that the rest of Beagle is C#)?
What about SULF?
===
Stackable User-Level Filesystem, or SULF
(http://arg0.net/users/vgough/sulf/), is a pre-existing FUSE binding
in C#, started by Valient Gough in 2004.
Mono.Fuse has no relation to SULF, for two reasons:
1. It goes to great efforts to avoid a Mono.Posix.dll dependency,
duplicating Mono.Unix.Native.Stat (Fuse.Stat),
Mono.Unix.Native.Statvfs (Fuse.StatFS), and many methods from
Mono.Unix.Native.Syscall (Fuse.Wrapper).
2. I don't like the SULF API. (Not that I spent a great deal of
time looking at it, but what I did see I didn't like.)
3. SULF wraps the FUSE kernel-level interface, while Mono.Fuse
wraps the higher level libfuse C interface
I find (1) the most appalling, if only because I'm the Mono.Posix
maintainer and I'd like to see my work actually used. :-)
Once I started writing Mono.Fuse, I discovered a good reason to avoid
Mono.Posix: it's currently impossible to use from outside of Mono.
I figured this would be a good opportunity to rectify that, making it
easier for additional libraries to build upon the Mono.Posix
infrastructure.
Implementation:
==
Mono.Fuse requires patches to the mcs mono modules, changes which
need to be proposed (hence this email) and discussed.
mono:
The biggest problem with the mono module is that no headers are
installed, making it difficult to make use of libMonoPosixHelper.so.
Changes:
- Modify `configure' to generate a mono-config.h file, installed as
$libdir/mono/include/mono-config.h. (Basic idea borrowed from
GLib's $libdir/glib-2.0/include/glibconfig.h).
- Add a mono-posix-helper.pc file
- Install the files $includedir/mono/posix/helper.h and
$includedir/mono/posix/map.h.
map.h is the current map.h file generated by make-map.exe, with some
major additions (detailed in the mcs section).
helper.h is the main include file, which includes map.h and declares
all types/functions which cannot be generated by make-map.exe.
mono-config.h is necessary because it needs to contain
platform-specific macros. In particular, Linux needs:
int
Mono_Posix_ToStat (struct statvfs *to, struct Mono_Posix_Helper *to);
while OS X and *BSD need:
int
Mono_Posix_ToStat (struct statfs *to, struct Mono_Posix_Helper *to);
Note `struct statvfs' vs. `struct statfs'. The mono/posix/helper.h
header needs to paper over the difference, and thus needs to know
which type the platform prefers. helper.h thus looks like:
#ifdef MONO_HAVE_STATVFS
struct statvfs;
int Mono_Posix_ToStatvfs (struct statvfs *from,
struct Mono_Posix_Statvfs *to);
#endif
#ifdef MONO_HAVE_STATFS
struct statfs;
int Mono_Posix_ToStatvfs (struct statfs *from,
struct Mono_Posix_Statvfs *to);
#endif
One of MONO_HAVE_STATVFS or MONO_HAVE_STATFS would be defined in
mono-config.h.
mcs:
---
There are two major changes:
* The addition of one public attributes to the API:
// targets Class, Delegate, Enum, Field, Struct
class Mono.Unix.Native.MapAttribute {
public MapAttribute ();
public MapAttribute (string nativeType);
public string NativeType {get;}
public string NativeSymbolPrefix {get; set;}
}
* A major revamp to make-map.exe
The Map and MapHeader attributes are public so that make-map.exe can
use a publically exposed API for code generation purposes which can be
used by other libraries (Mono.Fuse makes use of these changes).
Make-map.exe can also generate structure declarations and delegate
declarations in addition to P/Invoke function declarations,
allowing for a better, automated interface between C and C#.
Previously, [Map] could only be used on enumerations.
Now, [Map] can be used on classes, structures, delegates, to create
a C declaration of the C# type, suitable for P/Invoke purposes, e.g.
[Map] struct Stat {public FilePermissions mode;}
would generate the C declaration
struct Namespace_Stat {unsigned int mode;};
The MapAttribute.NativeType property is used to specify that type
conversion functions should be generated, thus:
[Map (struct stat)] struct Stat {public FilePermissions mode;}
would generate
struct Namespace_Stat {unsigned int mode;};
int Namespace_ToStat (struct stat *from, struct Namespace_Stat *to);
int Namespace_FromStat (struct Namespace_Stat *from, struct stat *to);
along with the actual implementations of Namespace_ToStat() and
Namespace_FromStat().
The MapAttribute.NativeSymbolPrefix is used to specify the C
namespace to use:
[Map (NativeSymbolPrefix=Foo)] struct Stat {FilePermissiond mode;}
generates
struct Foo_Stat {unsigned int mode;};
This
[Mono-dev] Case sensitivity and xbuild
Hi, Some IDEs when making a new project add a reference to Microsoft.CSharp.targets and some to Microsoft.CSharp.Targets. Of course under Linux you need to convert the name or install both files. In mcs/tools/xbuild/Makefile there's already line that installs Microsoft.CSharp.targets. What should I add/change to install the file with another name without having to keep 2 files in svn? (I think that it would create some problems under Windows then) Copying A to B and installing B as it was done with A looks like a best thing to do. -- Marek Sieradzki [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Official invitation letter to the Mono meeting
Hi, all! I would like to participate in the Mono conference. Unfortunately my American visa has expired. Is it possible get an official invitation letter to the meeting for the US Embassy? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ 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...
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 mailto: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] Why not NAnt?
Hi Atsushi, No one practically uses NAnt on cygwin (it is obvious as NAnt never supports cygwin-considered buid/installation system and no one complained about that). Considering that there are many many additional things that depends on make like standalone tests, there is no better development environment than cygwin on Windows. Having build depencency just for dogfooding isn't a good idea. Every time the build got broken somehow, it will mess every hackers until the problem goes away. Have you joined the development and tasted that pain? Are you making this statement with regard to building Mono or applications that run on Mono? If it's the first, I agree. For applications, it seems as if standardizing on NAnt is a valid choice to be made by the application developers and might even be a preferred choice since it allows one build to work on all platforms. Or am I missing some issue of deployment that NAnt cannot handle? [BTW, I'm currently deciding how to deploy NUnitLite, so it's a pretty central question for me.] Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why not NAnt?
Hi, No one practically uses NAnt on cygwin (it is obvious as NAnt never supports cygwin-considered buid/installation system and no one complained about that). Considering that there are many many additional things that depends on make like standalone tests, there is no better development environment than cygwin on Windows. Having build depencency just for dogfooding isn't a good idea. Every time the build got broken somehow, it will mess every hackers until the problem goes away. Have you joined the development and tasted that pain? Are you making this statement with regard to building Mono or applications that run on Mono? For my first paragraph, the second, and the first for everything else. If it's the first, I agree. For applications, it seems as if standardizing on NAnt is a valid choice to be made by the application developers and might even be a preferred choice since it allows one build to work on all platforms. Under Mono on windows it is unlikely to work fine with installation (installing assemblies to mono GAC) at least from what I know of. Of course I might be missing something, especially the latest cvs version might work (anyways Gert would help you). Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hello Zoltan, Here is first try of running mono/tests on Linux/Alpha. :) make check-local make[2]: Entering directory `/root/work/mono/mono/mono/tests' Testing array-init.exe... pass. Testing arraylist.exe... pass. Testing checked.exe... pass. Testing char-isnumber.exe... pass. Testing create-instance.exe... pass. Testing field-layout.exe... pass. Testing pack-layout.exe... pass. Testing hash-table.exe... pass. Testing test-ops.exe... pass. Testing obj.exe... pass. Testing string.exe... pass. Testing stringbuilder.exe... pass. Testing switch.exe... pass. Testing outparm.exe... pass. Testing delegate.exe... pass. Testing bitconverter.exe... pass. Testing exception.exe... pass. Testing exception2.exe... pass. Testing exception3.exe... pass. Testing exception4.exe... pass. Testing exception5.exe... pass. Testing exception6.exe... pass. Testing exception7.exe... pass. Testing exception8.exe... pass. Testing exception10.exe... pass. Testing exception11.exe... pass. Testing exception12.exe... pass. Testing exception13.exe... pass. Testing exception14.exe... pass. Testing exception15.exe... pass. Testing exception16.exe... pass. Testing struct.exe... pass. Testing valuetype-gettype.exe... pass. Testing typeof-ptr.exe... pass. Testing static-constructor.exe... pass. Testing pinvoke.exe... pass. Testing pinvoke2.exe... sh: line 1: 16828 Aborted MONO_PATH=../../../mcs/class/lib/default MONO_SHARED_DIR=/root/work/mono/mono/runtime /bin/sh ../../libtool --mode=execute ../mini/mono --config tests-config pinvoke2.exe 2pinvoke2.exe.stderr pinvoke2.exe.stdout failed 34304 (134) signal (0). Testing pinvoke3.exe... sh: line 1: 16863 Aborted MONO_PATH=../../../mcs/class/lib/default MONO_SHARED_DIR=/root/work/mono/mono/runtime /bin/sh ../../libtool --mode=execute ../mini/mono --config tests-config pinvoke3.exe 2pinvoke3.exe.stderr pinvoke3.exe.stdout failed 34304 (134) signal (0). Testing pinvoke11.exe... sh: line 1: 16898 Aborted MONO_PATH=../../../mcs/class/lib/default MONO_SHARED_DIR=/root/work/mono/mono/runtime /bin/sh ../../libtool --mode=execute ../mini/mono --config tests-config pinvoke11.exe 2pinvoke11.exe.stderr pinvoke11.exe.stdout failed 34304 (134) signal (0). Testing pinvoke13.exe... pass. Testing pinvoke17.exe... pass. Testing invoke.exe... failed 256 (1) signal (0). Testing invoke2.exe... pass. Testing runtime-invoke.exe... pass. Testing invoke-string-ctors.exe... pass. Testing reinit.exe... pass. Testing box.exe... pass. Testing array.exe... pass. Testing enum.exe... pass. Testing enum2.exe... pass. Testing property.exe... pass. Testing enumcast.exe... pass. Testing assignable-tests.exe... pass. Testing array-cast.exe... pass. Testing cattr-compile.exe... pass. Testing cattr-field.exe... pass. Testing cattr-object.exe... pass. Testing custom-attr.exe... pass. Testing double-cast.exe... pass. Testing newobj-valuetype.exe... pass. Testing arraylist-clone.exe... pass. Testing setenv.exe... pass. Testing vtype.exe... pass. Testing isvaluetype.exe... pass. Testing iface6.exe... pass. Testing ipaddress.exe... pass. Testing array-vt.exe... pass. Testing interface1.exe... pass. Testing reflection-enum.exe... pass. Testing reflection-prop.exe... pass. Testing reflection4.exe... pass. Testing reflection5.exe... pass. Testing reflection-const-field.exe... pass. Testing many-locals.exe... failed 256 (1) signal (0). Testing string-compare.exe... pass. Testing test-prime.exe... pass. Testing params.exe... pass. Testing reflection.exe... pass. Testing interface.exe... pass. Testing iface.exe... pass. Testing iface2.exe... pass. Testing iface3.exe... pass. Testing iface4.exe... pass. Testing iface-large.exe... pass. Testing virtual-method.exe... pass. Testing intptrcast.exe... pass. Testing indexer.exe... pass. Testing stream.exe... pass. Testing console.exe... pass. Testing shift.exe... pass. Testing jit-int.exe... pass. Testing jit-uint.exe... pass. Testing jit-long.exe... pass. Testing long.exe... pass. Testing jit-ulong.exe... pass. Testing jit-float.exe... pass. Testing pop.exe... pass. Testing time.exe... pass. Testing appdomain.exe... failed 256 (1) signal (0). Testing appdomain1.exe... failed 256 (1) signal (0). Testing appdomain2.exe... failed 256 (1) signal (0). Testing appdomain-client.exe... pass. Testing appdomain-unload.exe... disabled. Testing loader.exe... pass. Testing pointer.exe... pass. Testing hashcode.exe... pass. Testing delegate1.exe... pass. Testing delegate2.exe... pass. Testing delegate3.exe... pass. Testing delegate5.exe... pass. Testing delegate6.exe... pass. Testing delegate7.exe... pass. Testing delegate8.exe... pass. Testing remoting1.exe... pass. Testing remoting2.exe... pass. Testing remoting3.exe... pass. Testing remoting4.exe... failed 256 (1) signal (0). Testing remoting5.exe... pass. Testing nonvirt.exe... failed 256 (1) signal (0). Testing largeexp.exe... pass. Testing largeexp2.exe... pass. Testing marshalbyref1.exe...
Re: [Mono-dev] Why not NAnt?
Hi, No one practically uses NAnt on cygwin (it is obvious as NAnt never supports cygwin-considered buid/installation system and no one complained about that). Considering that there are many many additional things that depends on make like standalone tests, there is no better development environment than cygwin on Windows. Having build depencency just for dogfooding isn't a good idea. Every time the build got broken somehow, it will mess every hackers until the problem goes away. Have you joined the development and tasted that pain? Are you making this statement with regard to building Mono or applications that run on Mono? For my first paragraph, the second, and the first for everything else. OK, that makes sense. If it's the first, I agree. For applications, it seems as if standardizing on NAnt is a valid choice to be made by the application developers and might even be a preferred choice since it allows one build to work on all platforms. Under Mono on windows it is unlikely to work fine with installation (installing assemblies to mono GAC) at least from what I know of. Of course I might be missing something, especially the latest cvs version might work (anyways Gert would help you). Yes... I can see that an install target would be an issue. I've always avoided having an install target in my NAnt builds, just using them to build the actual installer in the case of Windows. I think it would be burdensome to need NAnt if you were merely installing pre-built assemblies. In the Linux world, an install target in a makefile is a perfect solution, since make is pretty much always present. For windows, that isn't as reasonable. I'll think more about this and add something about it to the wiki page on cross-platform compatibility. Charlie Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 1.1.17 has been released.
Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now features an abstract Unix end point in addition to Unix End Points [Alp Toker]. XML Land Fixed XmlSchemaSet and XmlSchemaCollection problem across multiple namespaces [Atsushi Enomoto] Important Bug Fixes Dynamic linking of Mono is now possible in applications that were using the TLS (open office) [Zoltan Varga]. Newly created AppDomains no longer inherit the list of loaded assemblies from the main domain. This has an important side-effect, to get XSP and mod_mono running, you must install the latest versions of it (released in this iteration), older versions will not work [Lluis Sanchez]. A number of missing pieces of System.IO.Ports have been implemented (ReadChar, ReadLine, BytesToRead, BytesToWrite, ReadTo, return USB tty
[Mono-dev] Patch to avoid some race conditions on the mono runtime
Hello,I'm sorry to double post this message, but I just find out that my first post doesn't have a subject !I'm really sorry if you have already seen the first message.In my work, i have to use mono with a specific thread library which
permits us to see some race conditions when we use mono as a libraryin a threaded environnement . Mono with the use of this library showsome race conditions that i've tried to fixed. In the patch we can see
four modifications of the file mini.c.The first two are modifications which avoid to put two times the samefonction in a table.The last modification (which corresponds to the two last modificationson the patch) was done since we have plenty of bugs which aren't
reproductibles, but all theses bugs have this fonction as a commonpoint. In this way we have just extend the critical section. thismodifications permits to run our tests program without any scratch.yours sincerely
Ps : theses errors are also in the new release of mono 1.1.17.The patch work on this version too, even if there are a fuzzwithout any consequences.---
Subete ga wakatta toki…watashi ga anta wo korosu.
diff -abur mono-1.1.16.1/mono/mini/mini.c mono-1.1.16.1.1/mono/mini/mini.c
--- mono-1.1.16.1/mono/mini/mini.c 2006-07-05 23:55:50.0 +0200
+++ mono-1.1.16.1.1/mono/mini/mini.c2006-08-04 09:22:11.418560308 +0200
@@ -2848,12 +2848,15 @@
info = mono_find_jit_icall_by_name (icall_name);
if (info == NULL) {
+ mono_jit_lock ();
+ info = mono_find_jit_icall_by_name (icall_name);
+ if (info == NULL) {
esig = mono_get_array_new_va_signature (rank);
name = g_strdup (icall_name);
info = mono_register_jit_icall (mono_array_new_va, name, esig,
FALSE);
- mono_jit_lock ();
g_hash_table_insert (jit_icall_name_hash, name, name);
+ }
mono_jit_unlock ();
}
@@ -3052,13 +3055,18 @@
info = mono_find_jit_icall_by_name (icall_name);
if (info == NULL) {
+ mono_jit_lock();
+ info = mono_find_jit_icall_by_name (icall_name);
+ if(info==NULL){
esig = mono_get_element_address_signature (rank);
name = g_strdup (icall_name);
info = mono_register_jit_icall (ves_array_element_address,
name, esig, FALSE);
- mono_jit_lock ();
+ /*mono_jit_lock ();*/
g_hash_table_insert (jit_icall_name_hash, name, name);
- mono_jit_unlock ();
+ /*mono_jit_unlock ();*/
+ }
+ mono_jit_unlock();
}
temp = mono_emit_native_call (cfg, bblock, mono_icall_get_wrapper
(info), info-sig, sp, ip, FALSE, FALSE);
@@ -10284,7 +10292,6 @@
}
}
- mono_domain_unlock (target_domain);
p = mono_create_ftnptr (target_domain, mono_jit_compile_method_inner
(method, target_domain, opt));
if (callinfo) {
@@ -10296,7 +10303,7 @@
}
mono_jit_unlock ();
}
-
+ mono_domain_unlock (target_domain);
return p;
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VMWare machine, monodevelop, and some thoughts
Hello, So which one is more important? My boss always says when everything's important, nothing is. Microsoft has yet to release a version of the NET Framework without an associated version of Visual Studio.NET. It would be nice to see a release cycle like this in the mono community, where a new version of the runtime is released either along with an accompanying version of MD, or new version of MD is released a short time later to update all language features. I would love to work on MD/Linux full-time here, but we're stuck because those small number of features that exist in VS.NET completely kill the case for MD right now. This is not likely going to happen any time soon; The range of features supported by Mono today is much larger than MonoDevelop, and the amount of features that go into Mono make it hard for MonoDevelop to keep up, specially with the current team size. One option is to grow the MonoDevelop team, am open to hear ideas about how to do this. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Cross compiling mono for arm-linux targated at 2.6 kernel
Hi, I am trying to compile mono-1.1.13.8 for a arm-linux device running 2.6 kernel. I tried to use mono for nokia 770 but it failed. I guess the reason is because nokia 770 uses 2.4 kernel. I tried to use scratchbox but it failed since my device is new and its toolchain is not yet provided for scratchbox. Hence I am trying the old way of cross-compilation. I configured using /configure --target=arm-linux --host=i686-linux --prefix=/usr/arm-linux command. Then, I ran make which resulted in the compilation error at the bottom of the email. Any idea what is the reason behind the error? Thanks, - Vinayak arm-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../../libgc/include -DMONO_BINDIR=\/usr/arm-linux/bin\ -I../.. -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP -g -O2 -fno-strict-aliasing -Wdeclaration-after-statement -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings -MT collection.lo -MD -MP -MF .deps/collection.Tpo -c collection.c -fPIC -DPIC -o .libs/collection.o In file included from ../../mono/io-layer/shared.h:13, from ../../mono/io-layer/collection.h:20, from collection.c:18: ../../mono/io-layer/wapi-private.h:21:2: #error configure failed to discover size of unix socket path make[3]: *** [collection.lo] Error 1 make[3]: Leaving directory `/home/naik/download/mono-1.1.13.8/mono/io-layer' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/naik/download/mono-1.1.13.8/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/naik/download/mono-1.1.13.8' make: *** [all] Error 2 ___ 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.
I just want to say great job to those making mono a real and competitive alternative to the .NET platform, in addition to its incredible cross-platform enabling; being an engineer with .NET technologies, I can say that mono is truly robust and really (finally) provides the write once, run anywhere capability we all have longed for. I salute you, Mr. Cross-platform Enabler! Original Message Subject: [Mono-dev] Mono 1.1.17 has been released. From: Miguel de Icaza [EMAIL PROTECTED] Date: Tue, August 29, 2006 4:43 pm To: mono-list@lists.ximian.com, Mono Announce mono-announce-list@lists.ximian.com, mono-devel-list@lists.ximian.com Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM JScriptCodeProvider code JavaScript code is now included [Akiramei] An EventLog implementation is available on both Unix and Windows, to use set the MONO_EVENTLOG_TYPE variable like this: * local[:path] generates a log file in the given path. If the path is not given, it will store the results in /var/lib/mono/eventlog on Unix and in %APPDATA%\mono\eventlog on Windows. * win32: This uses the native Windows API to send the log messages to the system event log. * null: discards all of the events to a pathname where the events should be logged to [Atsuhi Enomoto, Gert Driesen] COM Interop: Basic support for Runtime Callable Wrappers (RCWs). This allows users to use unmanaged components from managed code. [Jon Chambers] Sqlite now exposes a Version property to detect which underlying database is available (2.x or 3.x) [Joshua Tauberer] Mono.Posix now
Re: [Mono-dev] Mono 1.1.17 has been released.
On Tue, 2006-08-29 at 19:23 -0700, Carlos J. Muentes wrote: I just want to say great job to those making mono a real and competitive alternative to the .NET platform, in addition to its incredible cross-platform enabling; being an engineer with .NET technologies, I can say that mono is truly robust and really (finally) provides the write once, run anywhere capability we all have longed for. I salute you, Mr. Cross-platform Enabler! Aside from needing C for linux kernel programming, what would even be better then write once, run anywhere, is write for any purpose, write once, run anywhere and unfortunately mono has not provided a means to use it as a browser plugin like Java. For me i could go for just a plugin to Firefox (linux and Win32), wouldnt even need it to support IE. Until this can occur, a programmer still has to Java or (active x plugin), to achieve web page integration. Unfortunately not having this is a huge barrier to some people adopting mono. Providing this (as even MS .Net doesn't seem to provide web page plugin ability of .Net) would put Mono over the top, and likely bring many more contributors on board making Mono grow much faster. -tl Original Message Subject: [Mono-dev] Mono 1.1.17 has been released. From: Miguel de Icaza [EMAIL PROTECTED] Date: Tue, August 29, 2006 4:43 pm To: mono-list@lists.ximian.com, Mono Announce mono-announce-list@lists.ximian.com, mono-devel-list@lists.ximian.com Hello, Mono 1.1.17 has been released. Full release notes: www.go-mono.com/archive/1.1.17 Mono was branched at version 1.1.13 to become the stable version of Mono that is distributed by Novell on its enterprise products. That series of releases are only getting bug fixes. Before each release we run all of the regression tests on Mono, so we consider this release usable for deployment, but there are still a few changes in various areas. This release is mostly a bug-fix release, there are very few new developments. Changes since Mono 1.1.16 Highlights Basic world: The Mono Basic compiler and the Basic runtime have been removed from the Mono distribution. A new compiler that is compatible with Visual Basic 2005 and a matching runtime are now part of a separate distribution. On this particular release, we are offering the basic runtime, but the compiler is not able to run completely on Mono yet. Windows.Forms: Printing is now supported. This release is able to compile and build IronPython 1.0 RC2. COM: Basic COM support has been integrated. Inotify watcher The FileSystem will now use inotify directly on systems that support it without having to go through an external library like FAM or Gamin, this should make our use of inotify reliable. [Gonzalo Paniagua] Async Process Notification 2.0 support for asynchronous reads and writes from the Process class is now supported [Gonzalo]. Mono Loading as a Shared Library Works Again This was a problem that mostly affected the OpenOffice plugin, which loaded Mono as a separate process, this is now fixed [Zoltan Varga] Gtk# Split As part of Gtk# becoming one of the supported language bindings in the Gnome platform and Tomboy, a Gtk#-based application, becoming part of the Gnome desktop, Gtk# has been split up into multiple packages, instead of a single one. All the packages are available from our download site [Mike Kestner]. Mono.Cairo Mono.Cairo bindings now supports a DirectFB surface now [Alp Toker]. System.Drawing This release includes an upgraded Cairo stack (from 1.0 to 1.2) and allowed us to enable printing in System.Drawing and System.Windows.Forms. The original work was done by Jordi Mas, the Cairo upgrade by Peter Bartok and the work was completed by Chris Toshok. 2.0 API updates Process now support the async io handling [Gonzalo Paniagua] String.Normalize is included [Atsushi Enomoto] ADO.NET 2.0 updates, included an implementation for SqlConnection.GetSchema (Nagappan, Nagappan). Registry Updated to the 2.0 API. [Miguel de Icaza] Gert added support for splitting the registry across user and system level settings. [Gert Driesen] mod_mono Added support for X.509 client certificates. It's now possible to use System.Web.HttpClientCertificate with Apache. Certificate validation can be done by Apache, Mono or both (default). [Hubert Fongarnand, Sebastien Pouliot] Security SN now accept password-protected PKCS#12/PFX files to strongname assemblies. This feature is enabled in both 1.x and 2.0 profiles [Sebastien Pouliot] Additions CodeDOM
