[Mono-dev] About System.Net.Security.SslStream
Hello! I'm using mono 1.9.2 and trying to write a small program using SslStream. The program runs as server side program. I found if I write the program as serverCertificate = X509Certificate.CreateFromCertFile(certificate); SslStream sslStream = new SslStream( client.GetStream() ); sslStream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Tls, true); I will get a "Server certificate Private Key unavailable" error. But if I use SslServerStream provided by Mono.Security and prepare a pvk file and do as the monodoc says, it works. But certainly the program won't run in .net framework. Is it because the developing of SslStream not finished or is it a bug of SslStream? Is there any way to write a program works with better compatibility? Thanks. 以Wiki模式创建Linux中文文档，欢迎加入 http://www.linux-wiki.cn/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.0 download
I have the same problem. Except OpenSuse11 and SLE11 no other platforms packages are in supported list. Our product runs on RHEL and sle9 as well. Would like to know if it is planned in future to support them? Thanks, Vadiraj [EMAIL PROTECTED] wrote: > > So, *right now* the only way to use mono 2.0 on OpenSuse < 11 is > building the source? > > If there's other way, a howto would be greatly appreciated > > > > Robert Jordan escribió: >> Hey Andrew, >> >> Andrew Jorgensen wrote: >> >>> Sounds to me like it's a problem with the .repo file, not with the >>> repository itself. Please file a bug against the Build Service. >>> Also try adding using just the URL. >>> >> >> Adding by URL doesn't work either. I'll file a bug. >> >> Thanks >> Robert >> >> ___ >> 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 > > -- View this message in context: http://www.nabble.com/Mono-2.0-download-tp19845566p20434265.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Build / Release team meeting with Miguel notes...
On Mon, 2008-11-10 at 17:17 -0700, Thomas Wiest wrote: > * Make the Mono windows installer a smaller download >- Split gtk# out into it's own component >- Strip out the static libraries (the .a's) >- Change the gtk# installer to install to both the MS and Mono GACs This is an awesome idea. Gtk# trunk, and therefore 2.12.6 already has an msm/wix build set up which can be invoked with: make win32-installer There is also a win32-installers module which builds msms for gtk+ and glade and the dependencies using wix. It also produces a runtime and sdk .msi for gtk-sharp + gtk + deps via automake. You just have to copy the msms produced by the gtk-sharp build into the root directory and do a make. This installer currently specifies a dependency for .Net 1.1 or greater, but maybe that wix dependency could be revised to test for a mono msi as well. The assembly installation is already done using gacutil, so maybe it will 'just work' with a mono provided gacutil. Brad and Cody are the gurus on this stuff. I've tinkered around enough with it to know how to do minor version updates and so on. I'd be happy to work with you guys to see if we can move this idea forward. I have a 2.12.6 installer sitting on my win32 machine right now which I was going to see about uploading to mono-project.com, but maybe we can use this release as an opportunity to get you guys started by rebuilding it on your build machine(s). > * Change the Mono windows installer over to Wix so that it is an MSI There are a bunch of wix files in svn now to borrow from. -- Mike Kestner <[EMAIL PROTECTED]> ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ToolLocationHelper - NUnit Tests
Hi, I have put together some NUnit tests for ToolLocationHelper and have a few questions that need to be clarified. 1. When mono is installed, is there a differentiation between the runtime and the SDK? Some methods return different results depending on which runtimes and SDKs are actually installed. Example are GetPathToDotNetFrameworkFile depends on which runtimes are installed and GetPathToDotNetFrameworkSdkFile depends on which SDK is installed. 2. Is Mono expected to return the same values for all methods regardless of the platform it is running on? An example is GetDotNetFrameworkRootRegistryKey, on windows it returns 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework'. Would Microsoft be replaced with Novell? Should the correct value be HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Mono? I created the test based on running the unimplemented method on windows and determining what the output should be. I also consulted the MSDN documentation to get a better idea of what to expect. In most cases running the tests provided more information. Thanks Michael ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Build / Release team meeting with Miguel notes...
Hey Guys, We had a Build / Release team meeting with Miguel today, and he asked me to send out the notes. Meeting Notes: * We don't want to stop the build bots during releases. - For Mono 2.0, we changed our releases to being built in the openSUSE build service, so this fixed the majority of the reasons we were stopping the build bots. For the last week, Andrew has been working on the last few issues, and is now confident that for Mono 2.2, we won't need to stop the build bots. * Create a lane for building Olive - This has already been done, it's just that the web page isn't clear. The Olive builds are on the bottom of the page under the no-arch builds. * We need to start building IronPython ourselves as the community edition isn't being updated on a regular basis. * Make the Mono windows installer a smaller download - Split gtk# out into it's own component - Strip out the static libraries (the .a's) - Change the gtk# installer to install to both the MS and Mono GACs * Change the Mono windows installer over to Wix so that it is an MSI * Make the Mono OSX installer a smaller download - Make 2 packages 1. Mono runtime / gtk# 2. SDK (all of the static libs, MonoDevelop and everything else not in the Mono runtime) * Publish ia64 builds for SLES * Fix the Mono daily builds Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.2 has been branched
The branch is at branches/mono-2-2 in svn and we will be making a preview build sometime this week. Please help us make this the best and most stable release of Mono yet. Trunk revision at which we branched is 118441. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono 2.x on CentOS 5?
Hello! I've compiled Mono 2.0.1 on CentOS 5.2, using the directions provided on the mono-project website (which worked great, by the way - thanks very much for posting them!), and things aren't working quite right with my NUnit 2.5 (alpha) project. The NUnit project works great on Windows XP, using Visual Studio 2005. Oddly, it works great on Windows, using CygWin and Mono 2.x that I installed using the pre-built binaries. I wanted to try installing, using pre-built binaries, Mono 2.x onto the CentOS machine in order to see if the NUnit test works then (the idea being that if my NUnit 2.5 alpha stuff works on the normal Mono 2.x stuff, then I've probably built my own Mono wrong, somehow). When I went looking for Mono 2.x for CentOS (or RHEL), I couldn't find anything. CentOS has 1.2.4 or so as an option, and adding the mono.repos file (from mono-project.com) into the /etc/yum directory adds an option for Mono 1.9.x (which is soo close :) ), but there doesn't appear to be a 2.x option. Is this right? Is 2.x available (pre-compiled) on Windows but not CentOS? Any help would be greatly appreciated! Thanks! --Mike___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono C# compiler parser errors
Hello, As part of upcoming Mono 2.2 release we tried to improve gmcs/mcs parser error reporting and parser error recovery. However, there may be some places which we missed, and we would like to fix them. Please report any parser errors which you think are not useful, or where parser reports misleading errors such as "Parsing error" or "Expecting `;'" as a normal compiler bugs. Thanks Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Mono unit test failures on windows...
Hi, I believe that r118412 fixes https://bugzilla.novell.com/show_bug.cgi?id=443056 at least. -bill ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] appdomain-unload crashes
On Mon, 2008-11-10 at 17:06 -0200, Rodrigo Kumpera wrote: > Guys, > > Attached is the final version of the patch. > > It can timeout properly - thou the appdomain unload code doesn't > bother about it. This one works fine for me with xsp and a lot of incoming connections at the time of shutting down. Thanks! -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Ximian-mono-list] Mono unit test failures on windows...
Hi Jonathan, Basically any test related to thread abort won't work on windows, this should account at least for: appdomain-unload.exe finalizer-abort.exe Half of the others look like bugs that require a smaller ammount of changes. I'll add a more detailed explanation on bugzilla once I start looking at each bug. Rodrigo On Mon, Nov 10, 2008 at 5:10 PM, Jonathan Chambers <[EMAIL PROTECTED]>wrote: > Rodrigo, > Can you specify (or try to specify) which ones require the big code > change? That way anyone interested can look at the other ones. > > Thanks, > Jonathan > > 2008/11/7 Rodrigo Kumpera <[EMAIL PROTECTED]> > >> Hi Thomas, >> >> Thanks for taking time on this. I'll spend some time on this next week. >> What I can say is that at least half of those bugs won't be fixed for 2.2 >> as they require >> a big code change. >> >> We came to a similar situation in the 2.0 time frame and decided to >> postpone it. >> The changes required to fix the whole thread interruption problem are >> quite complex >> and would better be done at the beginning of a release cycle and not close >> to its end. >> >> I hope we can get someone to work on this for the 2.4 as this is a >> significant source of >> instability for mono. >> >> Rodrigo >> >> >> On Fri, Nov 7, 2008 at 9:29 PM, Thomas Wiest <[EMAIL PROTECTED]> wrote: >> >>> Hey Guys, >>>As per Miguel's request, we've submitted bugs for the non-nunit unit >>> test failures on windows. >>> >>> Here they are: >>> >>> [test-runtime] >>> https://bugzilla.novell.com/show_bug.cgi?id=442812 >>> https://bugzilla.novell.com/show_bug.cgi?id=442815 >>> https://bugzilla.novell.com/show_bug.cgi?id=442816 >>> https://bugzilla.novell.com/show_bug.cgi?id=442820 >>> https://bugzilla.novell.com/show_bug.cgi?id=442990 >>> https://bugzilla.novell.com/show_bug.cgi?id=442994 >>> https://bugzilla.novell.com/show_bug.cgi?id=442997 >>> https://bugzilla.novell.com/show_bug.cgi?id=443051 >>> https://bugzilla.novell.com/show_bug.cgi?id=443056 >>> >>> [test-cas] >>> https://bugzilla.novell.com/show_bug.cgi?id=443003 >>> >>> [test-compiler-2.0] >>> https://bugzilla.novell.com/show_bug.cgi?id=443024 >>> >>> >>> We will be e-mail out the failures for the nunit based tests. >>> >>> >>> Thomas >>> >>> >>> ___ >>> Ximian-mono-list mailing list >>> [EMAIL PROTECTED] >>> http://lists.ximian.com/mailman/listinfo/ximian-mono-list >>> >> >> >> ___ >> 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] [Ximian-mono-list] Mono unit test failures on windows...
Rodrigo, Can you specify (or try to specify) which ones require the big code change? That way anyone interested can look at the other ones. Thanks, Jonathan 2008/11/7 Rodrigo Kumpera <[EMAIL PROTECTED]> > Hi Thomas, > > Thanks for taking time on this. I'll spend some time on this next week. > What I can say is that at least half of those bugs won't be fixed for 2.2 > as they require > a big code change. > > We came to a similar situation in the 2.0 time frame and decided to > postpone it. > The changes required to fix the whole thread interruption problem are quite > complex > and would better be done at the beginning of a release cycle and not close > to its end. > > I hope we can get someone to work on this for the 2.4 as this is a > significant source of > instability for mono. > > Rodrigo > > > On Fri, Nov 7, 2008 at 9:29 PM, Thomas Wiest <[EMAIL PROTECTED]> wrote: > >> Hey Guys, >>As per Miguel's request, we've submitted bugs for the non-nunit unit >> test failures on windows. >> >> Here they are: >> >> [test-runtime] >> https://bugzilla.novell.com/show_bug.cgi?id=442812 >> https://bugzilla.novell.com/show_bug.cgi?id=442815 >> https://bugzilla.novell.com/show_bug.cgi?id=442816 >> https://bugzilla.novell.com/show_bug.cgi?id=442820 >> https://bugzilla.novell.com/show_bug.cgi?id=442990 >> https://bugzilla.novell.com/show_bug.cgi?id=442994 >> https://bugzilla.novell.com/show_bug.cgi?id=442997 >> https://bugzilla.novell.com/show_bug.cgi?id=443051 >> https://bugzilla.novell.com/show_bug.cgi?id=443056 >> >> [test-cas] >> https://bugzilla.novell.com/show_bug.cgi?id=443003 >> >> [test-compiler-2.0] >> https://bugzilla.novell.com/show_bug.cgi?id=443024 >> >> >> We will be e-mail out the failures for the nunit based tests. >> >> >> Thomas >> >> >> ___ >> Ximian-mono-list mailing list >> [EMAIL PROTECTED] >> http://lists.ximian.com/mailman/listinfo/ximian-mono-list >> > > > ___ > 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] [PATCH] appdomain-unload crashes
Guys,
Attached is the final version of the patch.
It can timeout properly - thou the appdomain unload code doesn't bother
about it.
Cheers,
Rodrigo
On Mon, Nov 10, 2008 at 11:24 AM, Rodrigo Kumpera <[EMAIL PROTECTED]> wrote:
> Yes, you're right, there is a race condition between pushing the the domain
> ref, decrementing the counter
> and checking if the domain needs to be unloaded.
>
>
>
> On Sun, Nov 9, 2008 at 6:19 PM, Zoltan Varga <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> Looks good. Isn't there a race between the check:
>> + if (domain->state == MONO_APPDOMAIN_UNLOADED ||
>> domain->state ==
>> MONO_APPDOMAIN_UNLOADING) {
>> and the
>> + mono_thread_push_appdomain_ref (domain);
>> call ?
>>
>> Zoltan
>>
>
>
diff --git a/mono/metadata/ChangeLog b/mono/metadata/ChangeLog
index b5fab23..59078aa 100644
--- a/mono/metadata/ChangeLog
+++ b/mono/metadata/ChangeLog
@@ -1,3 +1,32 @@
+2008-11-10 Rodrigo Kumpera <[EMAIL PROTECTED]>
+
+ * appdomain.c (unload_thread_main): Clean up threadpool by
+ calling mono_thread_pool_remove_domain_jobs.
+
+ * domain-internals.h (struct _MonoDomain): Add new fields to
+ help coordinate the cleanup of the threadpool.
+
+ * threadpool.c (mono_thread_pool_remove_domain_jobs): New fuction
+ that cleans up the threadpool of all jobs associated with an appdomain.
+ It does that by cleaning up the queues and making sure all active
+ threads are accounted.
+
+ * threadpool.c (async_invoke_io_thread): Ignore job if its domain is
+ unloaded or in the process of. Take this is such way that there is
+ no race condition between another thread starting the unload and the
+ current thread acknowledging it.
+
+ * threadpool.c (async_invoke_thread): Same.
+
+ * threadpool.c (start_io_thread_or_queue): Increment threadpool_jobs before
+ firing the new thread.
+
+ * threadpool.c (start_tpthread): Same.
+
+ * theadpool.c (append_job): Increment threadpool_jobs before queueing.
+
+ * threadpool.h: Add mono_thread_pool_remove_domain_jobs.
+
2008-11-06 Jonathan Chambers <[EMAIL PROTECTED]>
* file-io.c (ves_icall_System_IO_MonoIO_DuplicateHandle):
diff --git a/mono/metadata/appdomain.c b/mono/metadata/appdomain.c
index d229ca0..4d92d08 100644
--- a/mono/metadata/appdomain.c
+++ b/mono/metadata/appdomain.c
@@ -1876,6 +1876,11 @@ unload_thread_main (void *arg)
return 1;
}
+ if (!mono_thread_pool_remove_domain_jobs (domain, -1)) {
+ data->failure_reason = g_strdup_printf ("Cleanup of threadpool jobs of domain %s timed out.", domain->friendly_name);
+ return 1;
+ }
+
/* Finalize all finalizable objects in the doomed appdomain */
if (!mono_domain_finalize (domain, -1)) {
data->failure_reason = g_strdup_printf ("Finalization of domain %s timed out.", domain->friendly_name);
diff --git a/mono/metadata/domain-internals.h b/mono/metadata/domain-internals.h
index ceb1c08..1594e0e 100644
--- a/mono/metadata/domain-internals.h
+++ b/mono/metadata/domain-internals.h
@@ -215,6 +215,10 @@ struct _MonoDomain {
/* Information maintained by the JIT engine */
gpointer runtime_info;
+
+ /*thread pool jobs, used to coordinate shutdown.*/
+ int threadpool_jobs;
+ HANDLEcleanup_semaphore;
};
typedef struct {
diff --git a/mono/metadata/threadpool.c b/mono/metadata/threadpool.c
index 727f47f..bc42642 100644
--- a/mono/metadata/threadpool.c
+++ b/mono/metadata/threadpool.c
@@ -231,6 +231,22 @@ get_events_from_list (MonoMList *list)
(SOCKET)(gssize)x->handle, x->buffer, x->offset, x->size,\
x->socket_flags, &x->error);
+
+static gboolean
+clear_job (MonoDomain *domain, MonoAsyncResult *ar)
+{
+ int remaining_jobs = InterlockedDecrement (&domain->threadpool_jobs);
+ if (remaining_jobs == 0 && domain->cleanup_semaphore) {
+ EnterCriticalSection (&ares_lock);
+ mono_g_hash_table_remove (ares_htable, ar);
+ LeaveCriticalSection (&ares_lock);
+
+ ReleaseSemaphore (domain->cleanup_semaphore, 1, NULL);
+ return TRUE;
+ }
+ return FALSE;
+}
+
static void
async_invoke_io_thread (gpointer data)
{
@@ -261,23 +277,36 @@ async_invoke_io_thread (gpointer data)
/* worker threads invokes methods in different domains,
* so we need to set the right domain here */
domain = ((MonoObject *)ar)->vtable->domain;
- mono_thread_push_appdomain_ref (domain);
- if (mono_domain_set (domain, FALSE)) {
-ASyncCall *ac;
-
-mono_async_invoke (ar);
-ac = (ASyncCall *) ar->object_data;
-/*
-if (ac->msg->exc != NULL)
- mono_unhandled_exception (ac->msg->exc);
-*/
-mono_domain_set (mono_get_root_domain (), TRUE);
+
+ g_assert (domain);
+
+ if (domain->state == MONO_APPDOMAIN_UNLOADED || domain->state == MONO_APPDOMAIN_UNLOADING) {
+clear_job (domain, ar);
+data = NULL;
+ } else {
+mono_thread_push_appdomain_ref (domain);
+if (clear_job (domain, ar)) {
+ data = NULL;
+ mono_thread_pop_appdomain_ref ();
+ continue;
+}
+if (mono_domain_set
Re: [Mono-dev] WindowsBase in mcs
Also, If you're actually writing the package to disk, you need free space == size (package) * 2 as you will have to store a temporary full copy of the package as well as the final copy. Alan. On Mon, Nov 10, 2008 at 7:01 PM, Alan McGovern <[EMAIL PROTECTED]>wrote: > The only other option is for there to be a place on disk which is: > > A) Guaranteed to be writable > B) Guaranteed to have enough space to create the package. > > If those guarantees can be given, I'll gladly make the change. If they > can't, then I don't want to completely break this API just to save memory. > > Alan. > > > On Mon, Nov 10, 2008 at 6:17 PM, Paolo Molaro <[EMAIL PROTECTED]> wrote: > >> On 11/06/08 Alan McGovern wrote: >> > However this use case is likely to never be hit in System.IO.Packaging. >> The >> > API requires that when you 'write' data to a zip archive, the data is >> also >> > kept in memory. If you did try to use a 2gb file with this API, you'd >> end up >> > trying to allocate a 2gb block of memory. >> >> There is no requirement in the API that data is kept in memory, this bug >> needs to be fixed, if you don't know how, at least file a bug report in >> bugzilla so we don't forget about it. >> >> 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 >> > > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WindowsBase in mcs
The only other option is for there to be a place on disk which is: A) Guaranteed to be writable B) Guaranteed to have enough space to create the package. If those guarantees can be given, I'll gladly make the change. If they can't, then I don't want to completely break this API just to save memory. Alan. On Mon, Nov 10, 2008 at 6:17 PM, Paolo Molaro <[EMAIL PROTECTED]> wrote: > On 11/06/08 Alan McGovern wrote: > > However this use case is likely to never be hit in System.IO.Packaging. > The > > API requires that when you 'write' data to a zip archive, the data is > also > > kept in memory. If you did try to use a 2gb file with this API, you'd end > up > > trying to allocate a 2gb block of memory. > > There is no requirement in the API that data is kept in memory, this bug > needs to be fixed, if you don't know how, at least file a bug report in > bugzilla so we don't forget about it. > > 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 > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Lining error while compilation Mono under Windows/VS2008
Hi, This configuration works correctly for me. I believe the problem is that you are using the VS Dependency zip-archive. That archive has not been kept up to date. I know there is documentation somewhere that points to using it but that should be changed. >From http://www.mono-project.com/Compiling_Mono_VSNET... "All required libraries for building mono in Visual Studio are referenced via the MONO_DEPENDENCIES_PREFIX environment variable. Set this variable to a previous installed mono (C:\Mono-1.2.5.2 for example), or to a cygwin environment setup for building mono (D:\cygwin\opt for example)." I did verify that g_str_has_prefix is not an exposed method in the dll that is contained in the VS Dependency zip-archive, but it does exist in the 2.0 installed version of libglib. -bill On Mon, Nov 10, 2008 at 1:17 PM, Alexander M. Batishchev <[EMAIL PROTECTED]> wrote: > Hi everybody, > I'm trying to compile Mono under VS2008. > > Configuration 'Debug_eblib' is compiled successfully. > But just 'Debug' - is not. > Error LNK2019: unresolved external symbol _g_str_has_prefix referenced in > function _mono_class_generic_sharing_enabled occurs. > > In case of 'Debug_eblib' implementation of 'g_str_has_prefix' is contained > in eglib.lib which is compiling before libmono, and all works fine. > > But in case of just 'Debug' implementation is contained in glib-2.0.lib > which must be downloaded with VS Dependency zip-archive. > Is it possible that glib-2.0.lib doesn't contains proper data? > > Thanks for any information! > > === > Best regards, > Alexander M. Batishchev > > > ___ > 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] WindowsBase in mcs
On 11/06/08 Alan McGovern wrote: > However this use case is likely to never be hit in System.IO.Packaging. The > API requires that when you 'write' data to a zip archive, the data is also > kept in memory. If you did try to use a 2gb file with this API, you'd end up > trying to allocate a 2gb block of memory. There is no requirement in the API that data is kept in memory, this bug needs to be fixed, if you don't know how, at least file a bug report in bugzilla so we don't forget about it. 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
[Mono-dev] Lining error while compilation Mono under Windows/VS2008
Hi everybody, I'm trying to compile Mono under VS2008. Configuration 'Debug_eblib' is compiled successfully. But just 'Debug' - is not. Error LNK2019: unresolved external symbol _g_str_has_prefix referenced in function _mono_class_generic_sharing_enabled occurs. In case of 'Debug_eblib' implementation of 'g_str_has_prefix' is contained in eglib.lib which is compiling before libmono, and all works fine. But in case of just 'Debug' implementation is contained in glib-2.0.lib which must be downloaded with VS Dependency zip-archive. Is it possible that glib-2.0.lib doesn't contains proper data? Thanks for any information! === Best regards, Alexander M. Batishchev ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Can anyone review this fix for FreeBSD build?
I committed a much simpler patch that should address the same issue. Let me know if it works. 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-dev] [PATCH] appdomain-unload crashes
Yes, you're right, there is a race condition between pushing the the domain
ref, decrementing the counter
and checking if the domain needs to be unloaded.
On Sun, Nov 9, 2008 at 6:19 PM, Zoltan Varga <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Looks good. Isn't there a race between the check:
> + if (domain->state == MONO_APPDOMAIN_UNLOADED ||
> domain->state ==
> MONO_APPDOMAIN_UNLOADING) {
> and the
> + mono_thread_push_appdomain_ref (domain);
> call ?
>
> Zoltan
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono.Simd Acceleration Attributes
Hi Russel, Our initial goal is to make simd instructions available to managed code. At first we thought about trying to make an instruction set agnostic library, but there are way too many quirks and differences between them that the result could be too crippled to be usable. There are quite many valid use cases for having the whole sse instruction set available and these are what we are targeting now. But then, this was an analysis based on the fact that no well known compiler/runtime exposes such library (arch agnostic simd), they always have a binding to a specific platform. This doesn't mean we just won't do it. Once we have, for example, Altivec and VFP supported if an usable common subset emerge, we'll work on making it available. Now back to the Acceleration attribute. It's meant to support not only sse, but others as well, they are not present for the simple reason that we didn't have the time for it. Anyway, the attribute right now should be considered an implementation detail and if it shows to be a problem in cases such as the one you describe we'll change it. Keep in mind that the current design is not final, but at the same time it's hard to change it based on assumptions. Thanks for the feedback, Rodrigo On Mon, Nov 10, 2008 at 10:04 AM, <[EMAIL PROTECTED]> wrote: > Rodrigo, > > > > My only problem with this is the language is tied to the x86 architecture, > when Altivec or Paired Single etc are added for PowerPC then these > attributes are nonsensical and will mean nothing to the user. This would be > better done in a static location (rather than spread over the libraries) and > split into a machine agnostic (Simd acceleration ON) and a machine specific > manner (sse1 – 4.2 active). > > > > My 2c > > > Russell > > > -- > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Rodrigo Kumpera > *Sent:* 07 November 2008 15:15 > *To:* Christophe Guillon > *Cc:* mono-devel-list@lists.ximian.com > *Subject:* Re: [Mono-dev] Mono.Simd Acceleration Attributes > > > > Hi Christophe, > > 2008/11/7 Christophe Guillon <[EMAIL PROTECTED]> > > Thank you for the explanation. It confirms my point and it seems that we > agree. > > For the user guide aspect: > > > >2) the attributes on the methods are never inspected by the runtime: > >they are there to guide the programmers using Mono.Simd in determining > >what kind of optimizations are usually available or currently enabled. > > If it is indeed "just" a guide to the user of Mono.Simd, thus why putting > it in the library and coupling this with the specific architecture (SSE2 or > other). The fact that it is an AddWithSaturation on a Vector16b is > sufficient for the semantic. Then a note in the mono VM documentation can > tell that on SSE2 architectures -O=simd will select the corresponding SSE2 > op is sufficient. Optionaly a note in the library documentation can tell > that mono "normally" should catch such calls on SSE2 architectures. > > > We want to expose this information on the documentation as well and instead > of having to dig this information twice we are planning on generating this > part of the docs. > > > > > > For the choice of the accelerated or not accelerated mode at runtime: > > static readonly bool use_mono_simd = (SimdRuntime.AccelMode & > AccelMode.SSE2) != >0; > > > > ... > > if (use_mono_simd) > > // simd codepath > > else > > //scalar codepath > > If it is actually to overcome a temporary inneficiency due to some copy, it > is imho far too intrusive in the user code. Here the user clearly wrote a > code that is dependent on some "external" context, but instead of querying > the actual VM runtime, or simply a user defined variable that can be found > in some configuration file of the application, the query is on the Mono.Simd > library itself. > While in fact the library itself as no knowledge of the actual efficiency > of the running VM. > > > There are two good reasons for using this approach, the first one is > because the user requires the best performance in all situations and want to > know if it's method will be optimized or not. > > The second reason happens when there are many different ways to implement a > given function, each one using different instruction sets and the user wants > to have improved performance on newer processors. > > For example, there are 3 ways to implement dot product using Mono.Simd: > > 1) Only using sse1 and sse2 which takes 5 instructions (1 mul, 2 add and 2 > shuffle) > 2) Using sse3, which takes 3 instructions (1 mul, 2 hadd) > 3) Using sse4.2 which takes 1 instruction (dotp) -- sse4.2 still not > supported by Mono.Simd. > > For some users having this option is important and this is the main > objective of the runtime query capabilities. > > > > Thus I fully agree with this (which is my point): > > > "Note that we may eventually either return the attribute not based on the > metadata in
Re: [Mono-dev] Mono.Simd Acceleration Attributes
Rodrigo, My only problem with this is the language is tied to the x86 architecture, when Altivec or Paired Single etc are added for PowerPC then these attributes are nonsensical and will mean nothing to the user. This would be better done in a static location (rather than spread over the libraries) and split into a machine agnostic (Simd acceleration ON) and a machine specific manner (sse1 - 4.2 active). My 2c Russell From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rodrigo Kumpera Sent: 07 November 2008 15:15 To: Christophe Guillon Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono.Simd Acceleration Attributes Hi Christophe, 2008/11/7 Christophe Guillon <[EMAIL PROTECTED]> Thank you for the explanation. It confirms my point and it seems that we agree. For the user guide aspect: >2) the attributes on the methods are never inspected by the runtime: >they are there to guide the programmers using Mono.Simd in determining >what kind of optimizations are usually available or currently enabled. If it is indeed "just" a guide to the user of Mono.Simd, thus why putting it in the library and coupling this with the specific architecture (SSE2 or other). The fact that it is an AddWithSaturation on a Vector16b is sufficient for the semantic. Then a note in the mono VM documentation can tell that on SSE2 architectures -O=simd will select the corresponding SSE2 op is sufficient. Optionaly a note in the library documentation can tell that mono "normally" should catch such calls on SSE2 architectures. We want to expose this information on the documentation as well and instead of having to dig this information twice we are planning on generating this part of the docs. For the choice of the accelerated or not accelerated mode at runtime: > static readonly bool use_mono_simd = (SimdRuntime.AccelMode & AccelMode.SSE2) != >0; > ... > if (use_mono_simd) > // simd codepath > else > //scalar codepath If it is actually to overcome a temporary inneficiency due to some copy, it is imho far too intrusive in the user code. Here the user clearly wrote a code that is dependent on some "external" context, but instead of querying the actual VM runtime, or simply a user defined variable that can be found in some configuration file of the application, the query is on the Mono.Simd library itself. While in fact the library itself as no knowledge of the actual efficiency of the running VM. There are two good reasons for using this approach, the first one is because the user requires the best performance in all situations and want to know if it's method will be optimized or not. The second reason happens when there are many different ways to implement a given function, each one using different instruction sets and the user wants to have improved performance on newer processors. For example, there are 3 ways to implement dot product using Mono.Simd: 1) Only using sse1 and sse2 which takes 5 instructions (1 mul, 2 add and 2 shuffle) 2) Using sse3, which takes 3 instructions (1 mul, 2 hadd) 3) Using sse4.2 which takes 1 instruction (dotp) -- sse4.2 still not supported by Mono.Simd. For some users having this option is important and this is the main objective of the runtime query capabilities. Thus I fully agree with this (which is my point): "Note that we may eventually either return the attribute not based on the metadata in the assembly, but based on the runtime understanding: this will avoid the need to have an updated Mono.Simd assembly when new optimizations are added. Just use the b pattern if you want to avoid that issue and remember that you don't usually need to check all the methods, but just the ones you actually need to be optimized." All the question there is, whether or not there is a way to get from the runtime this information and by which mean? Is it possible to have attributes attached (or simulated) by the runtime? The SimdRuntime.AccelMode property queries the runtime for the supported instruction sets. You might look at the implementation and get puzzled by the fact that it returns AccelMode.None, but in fact this is a "magic method" that the runtime takes special care and make sure it returns the right thing. Thanks for taking your time looking at the Mono.Simd library :) Cheers, Rodrigo This email has been scanned by the MessageLabs Email Security System DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended rec
