Re: [Mono-devel-list] Plan for XSP Changes
Hi, It will be great if xsp could have a case unsensitive option. In fact i'm working on porting MS.NET app to Mono and I don't want to rewrite the original app. I'm using apache2/mod_mono with the mod_speling module with some success... but apache is hard to use for debuging ASP... It would be useful that xsp has an --case-insentive option... Le Vendredi 08 Avril 2005 08:53, Bill Middleton a écrit : Hi, Looks like a good plan to me, fwiw. I'd like to add Just a small feature request though, if you have time. I'd really like to have xsp provide a configurable output for errors. Right now it pretty much just does console.write() for everything, making it difficult to catch errors, especially in the mod-mono server. Thanks, Bill On Apr 8, 2005 6:22 AM, Brian Ritchie [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Based on comments from Gonzalo, Sebastien, and Miguel and I'm planning on making the following changes to the XSP code base. Hopefully I'm not putting words in your mouth :) Please review... 1) Create 2 modules: xsp.exe Mono.ASPNET.dll (Let me know what names you prefer for the modules) 2) Configure library to be compiled with both mcs and gmcs (for 1.x and 2.x profiles and controls) 3) Add a .pc file so third parties can link against it. I'm not familiar with the pkg-config stuff, so I'll need a hand on this one. 4) Divide existing code between the modules: - xsp.exe would contain all configuration options, functinality such as AddApplicationsFromConfigDirectory, AddApplicationsFromConfigFile, AddApplicationFromElement, AddApplicationsFromCommandLine. It would handle console output, help messages, etc. - Mono.ASPNET.dll would contain the core HTTP Server. In the future this would be further split into the new HttpListener class (.net 2.0) and ASP.NET http://ASP.NET integration code. 5) Make class method accessibility changes to limit the public surface of the assembly. 6) Add HTTPS support. The core assembly will utilize the SslServerStream from Mono.Security. Besides IP Port, it will also require a SecurityProtocolType, X509 Certificate, and a PrivateKeySelectionCallback which returns an AsymmetricAlgorithm to the private key. xsp.exe will be enhanced to allow the protocol types, certificate filename, private key filename password to be specified. This can be enhanced in the future to support other kinds of certificate stores. Also, client-side certs will be looked at in a future round of changes. 7) Add OnCreateHost delegate to allow trapping of loading (or reloading) of application hosts. This is useful for responding to an AppDomain reload after a config file or other change. Well, that's the basic plan. Let me know what you think, 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 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
Re: [Mono-devel-list] Weird warnings using mcs svn on Windows
- Original Message - From: Marek Safar [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 11, 2005 10:34 AM Subject: Re: [Mono-devel-list] Weird warnings using mcs svn on Windows Hello Gert, As of recently, I get the following warning (numerous times) when using mcs svn to compile even the simplest app on Windows: warning CS8028: The method 'System.Object.Finalize()' is marked 'override', but doesn't appear to override any virtual or abstract method: it may be ignored dur ing overload resolution C:\cygwin\usr\local\lib\mono\1.0\mscorlib.dll: 'System.Object.Finalize' (name of symbol related to previous warning Any idea what might be causing this ? It is caused by one of last Hari commit. I will look at this, unfortunately I have not had time so far. But even if you are using mcs on windows you should use Mono runtime because mcs functionality with Microsoft runtime is limited. I am using the Mono runtime, that's what makes this warning so weird. I have no problems using gmcs svn on Windows, and no problems using mcs or gmcs (both built from svn) on linux. Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Weird warnings using mcs svn on Windows
Hello, As of recently, I get the following warning (numerous times) when using mcs svn to compile even the simplest app on Windows: warning CS8028: The method 'System.Object.Finalize()' is marked 'override', but doesn't appear to override any virtual or abstract method: it may be ignored dur ing overload resolution C:\cygwin\usr\local\lib\mono\1.0\mscorlib.dll: 'System.Object.Finalize' (name of symbol related to previous warning Any idea what might be causing this ? It is caused by one of last Hari commit. I will look at this, unfortunately I have not had time so far. But even if you are using mcs on windows you should use Mono runtime because mcs functionality with Microsoft runtime is limited. I am using the Mono runtime, that's what makes this warning so weird. No, I don't think you are using Mono runtime. Try to compile some simple code by mono mcs.exe x.cs and then by mono.exe mcs.exe x.cs (add correct path to mcs) I have no problems using gmcs svn on Windows, and no problems using mcs or gmcs (both built from svn) on linux. Because Martin have not integrated the changes yet. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Weird warnings using mcs svn on Windows
- Original Message - From: Marek Safar [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Monday, April 11, 2005 11:31 AM Subject: Re: [Mono-devel-list] Weird warnings using mcs svn on Windows Hello, As of recently, I get the following warning (numerous times) when using mcs svn to compile even the simplest app on Windows: warning CS8028: The method 'System.Object.Finalize()' is marked 'override', but doesn't appear to override any virtual or abstract method: it may be ignored dur ing overload resolution C:\cygwin\usr\local\lib\mono\1.0\mscorlib.dll: 'System.Object.Finalize' (name of symbol related to previous warning Any idea what might be causing this ? It is caused by one of last Hari commit. I will look at this, unfortunately I have not had time so far. But even if you are using mcs on windows you should use Mono runtime because mcs functionality with Microsoft runtime is limited. I am using the Mono runtime, that's what makes this warning so weird. No, I don't think you are using Mono runtime. Try to compile some simple code by mono mcs.exe x.cs and then by mono.exe mcs.exe x.cs (add correct path to mcs) I don't have access to my dev box right now, but I'll try that when I get home this evening. Although I'm pretty sure I also tried mono c:\cygwin\usr\local\lib\mono\1.0\mcs.exe x.cs I have no problems using gmcs svn on Windows, and no problems using mcs or gmcs (both built from svn) on linux. Because Martin have not integrated the changes yet. Ok, that explains. Thanks ! Gert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
Some last minute touch-ups broke the patch to exceptions-x86.c, in the
patch, please change the following:
286c286
+#if def(__FreeBSD__)
---
+#if defined(__FreeBSD__)
Sorry about that. Updated patch attached
Bill
Index: libgc/include/private/gcconfig.h
===
--- libgc/include/private/gcconfig.h(revision 42774)
+++ libgc/include/private/gcconfig.h(working copy)
@@ -1186,8 +1186,8 @@
# ifndef GC_FREEBSD_THREADS
# define MPROTECT_VDB
# endif
-# define SIG_SUSPEND SIGUSR1
-# define SIG_THR_RESTART SIGUSR2
+# define SIG_SUSPEND SIGTSTP
+# define SIG_THR_RESTART SIGCONT
# define FREEBSD_STACKBOTTOM
# ifdef __ELF__
# define DYNAMIC_LOADING
@@ -1501,8 +1501,8 @@
# ifdef FREEBSD
# define OS_TYPE FREEBSD
/* MPROTECT_VDB is not yet supported at all on FreeBSD/alpha. */
-# define SIG_SUSPEND SIGUSR1
-# define SIG_THR_RESTART SIGUSR2
+# define SIG_SUSPEND SIGTSTP
+# define SIG_THR_RESTART SIGCONT
# define FREEBSD_STACKBOTTOM
# ifdef __ELF__
# define DYNAMIC_LOADING
Index: libgc/configure.in
===
--- libgc/configure.in (revision 42774)
+++ libgc/configure.in (working copy)
@@ -124,6 +124,17 @@
THREADLIBS=$PTHREAD_LIBS
fi
;;
+ *-*-freebsd6*)
+ AC_DEFINE(GC_FREEBSD_THREADS)
+ if test x$PTHREAD_CFLAGS != x; then
+ INCLUDES=$INCLUDES $PTHREAD_CFLAGS
+ fi
+ if test x$PTHREAD_LIBS = x; then
+ THREADLIBS=-lpthread
+ else
+ THREADLIBS=$PTHREAD_LIBS
+ fi
+ ;;
*-*-solaris*)
AC_DEFINE(GC_SOLARIS_THREADS)
AC_DEFINE(GC_SOLARIS_PTHREADS)
Index: libgc/os_dep.c
===
--- libgc/os_dep.c (revision 42774)
+++ libgc/os_dep.c (working copy)
@@ -702,10 +702,10 @@
# endif
# if defined(SUNOS5SIGS) || defined(IRIX5) || defined(OSF1) \
-|| defined(HURD) || defined(NETBSD)
+|| defined(HURD) || defined(NETBSD) || defined(FREEBSD)
static struct sigaction old_segv_act;
# if defined(_sigargs) /* !Irix6.x */ || defined(HPUX) \
- || defined(HURD) || defined(NETBSD)
+ || defined(HURD) || defined(NETBSD) || defined(FREEBSD)
static struct sigaction old_bus_act;
# endif
# else
@@ -720,7 +720,7 @@
# endif
{
# if defined(SUNOS5SIGS) || defined(IRIX5) \
-|| defined(OSF1) || defined(HURD) || defined(NETBSD)
+|| defined(OSF1) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
struct sigaction act;
act.sa_handler= h;
@@ -740,7 +740,7 @@
#else
(void) sigaction(SIGSEGV, act, old_segv_act);
# if defined(IRIX5) defined(_sigargs) /* Irix 5.x, not 6.x */ \
- || defined(HPUX) || defined(HURD) || defined(NETBSD)
+ || defined(HPUX) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
/* Under Irix 5.x or HP/UX, we may get SIGBUS. */
/* Pthreads doesn't exist under Irix 5.x, so we */
/* don't have to worry in the threads case. */
@@ -776,10 +776,10 @@
void GC_reset_fault_handler()
{
# if defined(SUNOS5SIGS) || defined(IRIX5) \
- || defined(OSF1) || defined(HURD) || defined(NETBSD)
+ || defined(OSF1) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
(void) sigaction(SIGSEGV, old_segv_act, 0);
#if defined(IRIX5) defined(_sigargs) /* Irix 5.x, not 6.x */ \
-|| defined(HPUX) || defined(HURD) || defined(NETBSD)
+|| defined(HPUX) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
(void) sigaction(SIGBUS, old_bus_act, 0);
#endif
# else
Index: libgc/dyn_load.c
===
--- libgc/dyn_load.c(revision 42774)
+++ libgc/dyn_load.c(working copy)
@@ -96,20 +96,28 @@
/* Newer versions of GNU/Linux define this macro. We
* define it similarly for any ELF systems that don't. */
# ifndef ElfW
-#ifdef NETBSD
-# if ELFSIZE == 32
+#ifdef FREEBSD
+# if __ELF_WORD_SIZE == 32
#define ElfW(type) Elf32_##type
# else
#define ElfW(type) Elf64_##type
# endif
#else
-# if !defined(ELF_CLASS) || ELF_CLASS == ELFCLASS32
-#define ElfW(type) Elf32_##type
+# ifdef NETBSD
+#if ELFSIZE == 32
+# define ElfW(type) Elf32_##type
+#else
+# define ElfW(type) Elf64_##type
+#endif
# else
-#define ElfW(type) Elf64_##type
+#if !defined(ELF_CLASS) || ELF_CLASS == ELFCLASS32
+# define ElfW(type) Elf32_##type
+#else
+# define
[Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
And one more. Thats what I get for doing last-minute touchups.
313c313
+#if def(__FreeBSD__)
---
+#if defined(__FreeBSD__)
Thanks for your patience, Complete, working patch attached.
Bill
Index: libgc/include/private/gcconfig.h
===
--- libgc/include/private/gcconfig.h(revision 42774)
+++ libgc/include/private/gcconfig.h(working copy)
@@ -1186,8 +1186,8 @@
# ifndef GC_FREEBSD_THREADS
# define MPROTECT_VDB
# endif
-# define SIG_SUSPEND SIGUSR1
-# define SIG_THR_RESTART SIGUSR2
+# define SIG_SUSPEND SIGTSTP
+# define SIG_THR_RESTART SIGCONT
# define FREEBSD_STACKBOTTOM
# ifdef __ELF__
# define DYNAMIC_LOADING
@@ -1501,8 +1501,8 @@
# ifdef FREEBSD
# define OS_TYPE FREEBSD
/* MPROTECT_VDB is not yet supported at all on FreeBSD/alpha. */
-# define SIG_SUSPEND SIGUSR1
-# define SIG_THR_RESTART SIGUSR2
+# define SIG_SUSPEND SIGTSTP
+# define SIG_THR_RESTART SIGCONT
# define FREEBSD_STACKBOTTOM
# ifdef __ELF__
# define DYNAMIC_LOADING
Index: libgc/configure.in
===
--- libgc/configure.in (revision 42774)
+++ libgc/configure.in (working copy)
@@ -124,6 +124,17 @@
THREADLIBS=$PTHREAD_LIBS
fi
;;
+ *-*-freebsd6*)
+ AC_DEFINE(GC_FREEBSD_THREADS)
+ if test x$PTHREAD_CFLAGS != x; then
+ INCLUDES=$INCLUDES $PTHREAD_CFLAGS
+ fi
+ if test x$PTHREAD_LIBS = x; then
+ THREADLIBS=-lpthread
+ else
+ THREADLIBS=$PTHREAD_LIBS
+ fi
+ ;;
*-*-solaris*)
AC_DEFINE(GC_SOLARIS_THREADS)
AC_DEFINE(GC_SOLARIS_PTHREADS)
Index: libgc/os_dep.c
===
--- libgc/os_dep.c (revision 42774)
+++ libgc/os_dep.c (working copy)
@@ -702,10 +702,10 @@
# endif
# if defined(SUNOS5SIGS) || defined(IRIX5) || defined(OSF1) \
-|| defined(HURD) || defined(NETBSD)
+|| defined(HURD) || defined(NETBSD) || defined(FREEBSD)
static struct sigaction old_segv_act;
# if defined(_sigargs) /* !Irix6.x */ || defined(HPUX) \
- || defined(HURD) || defined(NETBSD)
+ || defined(HURD) || defined(NETBSD) || defined(FREEBSD)
static struct sigaction old_bus_act;
# endif
# else
@@ -720,7 +720,7 @@
# endif
{
# if defined(SUNOS5SIGS) || defined(IRIX5) \
-|| defined(OSF1) || defined(HURD) || defined(NETBSD)
+|| defined(OSF1) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
struct sigaction act;
act.sa_handler= h;
@@ -740,7 +740,7 @@
#else
(void) sigaction(SIGSEGV, act, old_segv_act);
# if defined(IRIX5) defined(_sigargs) /* Irix 5.x, not 6.x */ \
- || defined(HPUX) || defined(HURD) || defined(NETBSD)
+ || defined(HPUX) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
/* Under Irix 5.x or HP/UX, we may get SIGBUS. */
/* Pthreads doesn't exist under Irix 5.x, so we */
/* don't have to worry in the threads case. */
@@ -776,10 +776,10 @@
void GC_reset_fault_handler()
{
# if defined(SUNOS5SIGS) || defined(IRIX5) \
- || defined(OSF1) || defined(HURD) || defined(NETBSD)
+ || defined(OSF1) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
(void) sigaction(SIGSEGV, old_segv_act, 0);
#if defined(IRIX5) defined(_sigargs) /* Irix 5.x, not 6.x */ \
-|| defined(HPUX) || defined(HURD) || defined(NETBSD)
+|| defined(HPUX) || defined(HURD) || defined(NETBSD) ||
defined(FREEBSD)
(void) sigaction(SIGBUS, old_bus_act, 0);
#endif
# else
Index: libgc/dyn_load.c
===
--- libgc/dyn_load.c(revision 42774)
+++ libgc/dyn_load.c(working copy)
@@ -96,20 +96,28 @@
/* Newer versions of GNU/Linux define this macro. We
* define it similarly for any ELF systems that don't. */
# ifndef ElfW
-#ifdef NETBSD
-# if ELFSIZE == 32
+#ifdef FREEBSD
+# if __ELF_WORD_SIZE == 32
#define ElfW(type) Elf32_##type
# else
#define ElfW(type) Elf64_##type
# endif
#else
-# if !defined(ELF_CLASS) || ELF_CLASS == ELFCLASS32
-#define ElfW(type) Elf32_##type
+# ifdef NETBSD
+#if ELFSIZE == 32
+# define ElfW(type) Elf32_##type
+#else
+# define ElfW(type) Elf64_##type
+#endif
# else
-#define ElfW(type) Elf64_##type
+#if !defined(ELF_CLASS) || ELF_CLASS == ELFCLASS32
+# define ElfW(type) Elf32_##type
+#else
+# define ElfW(type) Elf64_##type
Re: [Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
Hi, This looks ok to me, except this part: PREVIEW=yes AC_ARG_WITH(preview, [ --with-preview=yes,no If you want to install the 2.0 FX preview],[ - if test x$with_preview = xyes; then - PREVIEW=yes + if test x$with_preview = xno; then + PREVIEW=no fi Zoltan On Apr 11, 2005 12:48 PM, Bill Middleton [EMAIL PROTECTED] wrote: And one more. Thats what I get for doing last-minute touchups. 313c313 +#if def(__FreeBSD__) --- +#if defined(__FreeBSD__) Thanks for your patience, Complete, working patch attached. Bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
On 04/08/05 Miguel de Icaza wrote: I would like to have a `global-dllmap' entry on our .config files so that it is possible to register standard mappings by libraries. Today we have something like that in the form of $mono/etc/mono/config, but there is no way for a binding library to provide these. The issue at hand is that gtk-sharp ships with a config file that maps the libgtk-win32-etc.dll name to the proper name on the underlying OS. And I would like third party apps to be able to consume this binding as opposed to introducing the logic on every application that needs to bind an API from Gtk+ that might not be bound. I don't like the fact that an assembly would push in the global space some dllmappings, because it would be indiscriminate: every app wuld get them even if they are not interested and it's not clear what kind of ordering is applied to the mappings. An alternative way to provide the same functionality with sane semantics could be to have a new config directive in the assemblies that want to reuse the mappings from other assemblies. configuration dllmap reference=gtk-sharp / /configuration Suggestions for better names than 'reference' are welcome. This would allow the apps that need the dllmaps to reference other assemblies by name (it could eventually also use a full assembly name, with version and pubtoken) explicitly but in a pain-less way. And we wouldn't pollute the global dllmap space. The 'reference' dllmapping would be tried after the local explicit dllmaps and before the global ones, allowing an easy override. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
Thanks Zoltan, we freebsd folks look forward to its inclusion. Regarding $PREVIEW I guess it's enabled by default in svn and will be disabled in the release? Also, regarding the two nits I hurriedly sent, there's a Good Explanation (tm) for those. As I was finalizing the patch, I noticed that I had #ifdef'd only __FreeBSD__ for the sigaltstack changes in exceptions-x86.c, where I could have checked for both FreeBSD and NetBSD. I started to change it, then decided to double check. After a visit to the NetBSD source CVS archive, I found that NetBSD _does_ define gregs[], so the change was not needed. NetBSD sigaltstack should build out of the box now with the SA_STACK change to configure.in, and the command line option to configure. Still, I should have done that one, last test build. I know. Regards, Bill On Apr 11, 2005 2:43 PM, Zoltan Varga [EMAIL PROTECTED] wrote: Hi, This looks ok to me, except this part: PREVIEW=yes AC_ARG_WITH(preview, [ --with-preview=yes,no If you want to install the 2.0 FX preview],[ - if test x$with_preview = xyes; then - PREVIEW=yes + if test x$with_preview = xno; then + PREVIEW=no fi Zoltan On Apr 11, 2005 12:48 PM, Bill Middleton [EMAIL PROTECTED] wrote: And one more. Thats what I get for doing last-minute touchups. 313c313 +#if def(__FreeBSD__) --- +#if defined(__FreeBSD__) Thanks for your patience, Complete, working patch attached. Bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
On 04/09/05 Mike Kestner wrote: 2) On the specific case of Gtk#, I should point out that I've been considering the possibility of switching to statically compiled dll names for win32 and x11. The situation as it stands now is that we not only have platform specific glue, but we also have a build hack in place to dasm/hack/asm the assemblies on win32 for the cdecl calling convention thing. The dllmap .config hack is a throwback to the good old days when we thought we could have build-once-run-everywhere deployment for Gtk#, but based on current knowledge I don't believe such a goal is attainable. I someday plan to extend the dllmaps to include the call convention info, so it will be able to handle that, too. Nothing prevents us from overriding the call convention used for delegate unmanaged wrappers using an entry in the config file: configuration delegatemap name=Gtk.SomeDelegate callconv=cdecl / /configuration So it would be easy to use the same assemblies on any OS. Not that this solves your immediate problem (the need to change the build ildasm/ilasm to apply the correct callconv on windows), but once we use the new explicit attribute to set the callcaon we'll be able to use this. This is also something which doesn't necessarily apply to Gtk], since it has already the need to build a platform-specific shared library anyway. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
On 04/11/05 Bill Middleton wrote: Index: mono/mini/exceptions-x86.c === --- mono/mini/exceptions-x86.c(revision 42774) +++ mono/mini/exceptions-x86.c(working copy) @@ -25,6 +25,10 @@ #include mini.h #include mini-x86.h +#if defined(__FreeBSD__) +#include ucontext.h +#endif Maybe it's better to check if the header is present in configure and use HAVE_UCONTEXT_H here? Same with checking for the gregs field in ctx-uc_mcontext. In any case it may be better to define the macros to access the registers in the context and use those in the file: #if defined(__FreeBSD__) #define CTX_REG_EAX(ctx) ((ctx)uc_mcontext.mc_eax) ... #else #define CTX_REG_EAX(ctx) ((ctx)uc_mcontext.gregs [REG_EAX]) ... #endif This way the #ifdefs are moved to the header file and not in the middle of the code. Index: mono/mini/mini-x86.c === --- mono/mini/mini-x86.c (revision 42774) +++ mono/mini/mini-x86.c (working copy) @@ -4691,6 +4691,9 @@ pthread_getattr_np( self, attr ); #else #ifdef HAVE_PTHREAD_ATTR_GET_NP +#if defined(__FreeBSD__) + pthread_attr_init( attr ); +#endif This is likely a good idea on any platform, right? So no need for #ifdefs. Index: mono/mini/mini-x86.h === --- mono/mini/mini-x86.h (revision 42774) +++ mono/mini/mini-x86.h (working copy) @@ -77,17 +77,21 @@ #ifndef PLATFORM_WIN32 #ifdef HAVE_WORKING_SIGALTSTACK - #define MONO_ARCH_SIGSEGV_ON_ALTSTACK #define MONO_ARCH_USE_SIGACTION -/* NetBSD doesn't define SA_STACK */ -#ifndef SA_STACK -#define SA_STACK SA_ONSTACK -#endif -#endif +/* FreeBSD and NetBSD need SA_STACK and MAP_ANON re-definitions */ +#if defined(__FreeBSD__) || defined(__NetBSD__) +#ifndef SA_STACK +#define SA_STACK SA_ONSTACK +#endif +#ifndef MAP_ANONYMOUS +#define MAP_ANONYMOUS MAP_ANON +#endif +#endif /* BSDs */ This stuff doesn't belong to mini-x86.h, though mono-compiler.h is not a good place either. In any case, I don't see any need to make this conditional on __FreeBSD__/__NetBSD__, so remove at least that. Thanks! lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
Hi Lupus, I will work up another patch to implement your suggestions. I based the original on the principle of do the least harm, but I will remove the #ifdefs where you have suggested, and setup a check for ucontext.h in configure.in. See below. On Apr 11, 2005 7:17 PM, Paolo Molaro [EMAIL PROTECTED] wrote: #if defined(__FreeBSD__) #define CTX_REG_EAX(ctx) ((ctx)uc_mcontext.mc_eax) ... #else #define CTX_REG_EAX(ctx) ((ctx)uc_mcontext.gregs [REG_EAX]) ... #endif This way the #ifdefs are moved to the header file and not in the middle of the code. This one is a bit trickier. The current implementation relies on Zoltan's new sigcontext_to_monocontext() fix, and I don't know how he wants to handle it going forward. I'll defer to him. Thanks for the feedback. Bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Weird warnings using mcs svn on Windows
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marek Safar Sent: maandag 11 april 2005 11:31 To: Gert Driesen Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-devel-list] Weird warnings using mcs svn on Windows Hello, As of recently, I get the following warning (numerous times) when using mcs svn to compile even the simplest app on Windows: warning CS8028: The method 'System.Object.Finalize()' is marked 'override', but doesn't appear to override any virtual or abstract method: it may be ignored dur ing overload resolution C:\cygwin\usr\local\lib\mono\1.0\mscorlib.dll: 'System.Object.Finalize' (name of symbol related to previous warning Any idea what might be causing this ? It is caused by one of last Hari commit. I will look at this, unfortunately I have not had time so far. But even if you are using mcs on windows you should use Mono runtime because mcs functionality with Microsoft runtime is limited. I am using the Mono runtime, that's what makes this warning so weird. No, I don't think you are using Mono runtime. Try to compile some simple code by mono mcs.exe x.cs and then by mono.exe mcs.exe x.cs (add correct path to mcs) I verified this again, and I'm very sure I'm using the Mono runtime: $ mono.exe c:/cygwin/usr/local/lib/mono/1.0/mcs.exe test.cs warning CS8028: The method 'System.Object.Finalize()' is marked 'override', but doesn't appear to override any virtual or abstract method: it may be ignored dur ing overload resolution C:\cygwin\usr\local\lib\mono\1.0\mscorlib.dll: 'System.Object.Finalize' (name of symbol related to previous warning Compilation succeeded - 1 warning(s) I attached the verbose log. Gert test.tar.gz Description: Binary data
RE: [Mono-devel-list] PATCH: reworked async IO for Socket
Epool, kqueue and async IO all share the same problem: they are barely portable. They don't really have to be - there are plenty of examples of how to wrap them up to create a virtual layer that *is* portable. You only need 'one of' these technologies on any given platform, and configure can take care of the rest. Given the effectiveness of P/Invoke and dynamic loading, the portability layer could be in C#. AIO I would ignore, *that* suffers from the IMO worse fate of portable APIs and generally half-baked implementations that are passable on a small number of disk devices and rubbish on large numbers of sockets. Sometimes, Microsoft do things right. James ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Re: Patch: 100% working mono under FreeBSD (small nit)
Hello, Thanks Zoltan, we freebsd folks look forward to its inclusion. Regarding $PREVIEW I guess it's enabled by default in svn and will be disabled in the release? Preview=yes will become the new default. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
Hello, The issue at hand is that gtk-sharp ships with a config file that maps the libgtk-win32-etc.dll name to the proper name on the underlying OS. And I would like third party apps to be able to consume this binding as opposed to introducing the logic on every application that needs to bind an API from Gtk+ that might not be bound. Can't we just say that if you pull in gtk-sharp.dll from the GAC, that you automatically pull in gtk-sharp.dll.config from the GAC too? (And can't we just store the .config file as a resource inside gtk-sharp.dll rather than as a separate file? Or would that be at the wrong level of abstraction for the vm to be able to find it?) The config file is already being pulled, but Mono only resolves the dll mappings for Dllimports done from that assembly. What I want to have is a new keyword global-dllmap that would insert the mapping into the global mapping table as opposed to the local assembly mapping table. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
On Fri, 2005-04-08 at 13:47 -0400, Miguel de Icaza wrote: The issue at hand is that gtk-sharp ships with a config file that maps the libgtk-win32-etc.dll name to the proper name on the underlying OS. And I would like third party apps to be able to consume this binding as opposed to introducing the logic on every application that needs to bind an API from Gtk+ that might not be bound. Can't we just say that if you pull in gtk-sharp.dll from the GAC, that you automatically pull in gtk-sharp.dll.config from the GAC too? (And can't we just store the .config file as a resource inside gtk-sharp.dll rather than as a separate file? Or would that be at the wrong level of abstraction for the vm to be able to find it?) -- Dan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
On 04/11/05 Dan Winship wrote: Can't we just say that if you pull in gtk-sharp.dll from the GAC, that you automatically pull in gtk-sharp.dll.config from the GAC too? (And Well, this issue is not related to the GAC in any way. One possibility is to make the code look for the dllmaps in any of the referenced assemblies automatically so there would be no need even for the reference dllmap. But I don't like this, because it is out of the control of the app and the user (in mostly the same way as the global-dllmap proposed by miguel). can't we just store the .config file as a resource inside gtk-sharp.dll rather than as a separate file? Or would that be at the wrong level of abstraction for the vm to be able to find it?) If you store the config in the assembly you might as well build a correct assembly in the first place. I designed the dllmap in that way because it allows users to change the configuration (because it's a lost cause to have every developer understand the issues of library names and different operating systems etc), so hardcoding the config inside the assembly doesn't make much sense (even if we can access it there). My proposal addresses the stated need to reuse the mappings from assemblies like gtk-sharp with the only cost of adding a simple config file (which is arch-indep) to the asemblies that need it. A global dllmap may seem a simpler solution, but introduces changes in all the apps in ways that may not be predictable. I'll also note that my solution can work even when the referenced assembly is not loaded, which might be useful. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-devel-list] Global dllmap entries?
On Mon, 2005-04-11 at 18:57 +0200, Paolo Molaro wrote: A global dllmap may seem a simpler solution, but introduces changes in all the apps in ways that may not be predictable. It would seem good to to give the app more control over how assemblies can mess with it. Maybe reverse the direction of the map, so in app.exe.config we have import-dllmap dll=libglib-2.0-0.dll assembly=gtk-sharp.dll / which would import whatever mapping gtk-sharp.dll.config specifies for libglib-2.0-0.dll. This way you can specify exactly which DLL maps your app 'trusts'. (Eg, what if two referenced assemblies have conflicting global-dllmap entries for the same DLL name?) Peter -- Peter Williams [EMAIL PROTECTED] [Ninjas] are cool; and by cool, I mean totally sweet. -- REAL Ultimate Power ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
