Re: [Mono-list] String comparisons slow

[Stifu]

Yeah, from what I read and understand, Ordinal is faster because it checks
characters one by one, sequentially, while Invariant does more complex
checks.

By the way, it's "résumé", not "rèsumè". ;)


Bojan Rajkovic-2 wrote:
> 
> Hi Alexander,
> 
> My understanding based on the documentation is that
> StringComparison.Ordinal
> is essentially a C strcmp (in fact, it may be implemented as such under
> the
> hood, via an icall to the C runtime code), and StringComparison.Invariant
> is
> aware of surrogate pairs and composed characters, and is a linguistic
> comparison (ie. this *letter* comes before the other, not this character
> code).
> 
> --Bojan
> 
> 2010/7/22 Alexander M. Batishchev 
> 
>> Michael, could you please clarify the difference between Ordinal and
>> Invariant string comparison?
>>
>> -Original Message-
>> From: mono-list-boun...@lists.ximian.com
>> [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael
>> Hutchinson
>> Sent: Thursday, July 22, 2010 12:29 AM
>> To: David S
>> Cc: mono-list@lists.ximian.com; wtftc
>> Subject: Re: [Mono-list] String comparisons slow
>>
>> On Wed, Jul 21, 2010 at 3:30 PM, David S  wrote:
>> > Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just
>> run
>> > the Ordinal??? Perhaps there are some weird alphabetizing things I just
>> > don't understand. BTW, Thanks for tell us about the StringComparer
>> class.
>> I
>> > never knew that existed.
>>
>> Note also that some string methods have overloads for taking specific
>> cultures, or the StringComparison enum. Both StringComparison.Ordinal
>> and StringComparison.OrdinalIgnoreCase (as well as StringComparer) can
>> be very useful to improve performance when culture-dependent behaviour
>> is not needed or desirable.
>>
>> Culture-dependent string comparisons are a very complex topic. There's
>> also an "invariant" culture for doing things in a culture-independent
>> way.
>>
>> --
>> Michael Hutchinson
>> http://mjhutchinson.com
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
> 
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 
> 

-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2298183.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Atsushi Eno]

While jonp has already explained it though...
StringComparison.Ordinal means comparison in Unicode character codepoint 
order.
Invariant comparison is culture-aware comparison that includes "natural" 
sortings (i.e. sorting like A->a->B->b), processing combined characters 
(AE == \u00C6) etc.
They are mostly common to all cultures, while there are some difference 
between cultures e.g. CJK ideography character sortings differ a lot 
among those cultures. Some Latin1 character orders differ for each 
European culture.
For more details, see Collation-notes.txt in 
corlib/Mono.Globalization.Unicode:
http://anonsvn.mono-project.com/viewvc/trunk/mcs/class/corlib/Mono.Globalization.Unicode/Collation-notes.txt

Atsushi Eno

On 2010/07/22 14:50, Alexander M. Batishchev wrote:
> Michael, could you please clarify the difference between Ordinal and
> Invariant string comparison?
>
> -Original Message-
> From: mono-list-boun...@lists.ximian.com
> [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael Hutchinson
> Sent: Thursday, July 22, 2010 12:29 AM
> To: David S
> Cc: mono-list@lists.ximian.com; wtftc
> Subject: Re: [Mono-list] String comparisons slow
>
> On Wed, Jul 21, 2010 at 3:30 PM, David S  wrote:
>
>> Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just
>>  
> run
>
>> the Ordinal??? Perhaps there are some weird alphabetizing things I just
>> don't understand. BTW, Thanks for tell us about the StringComparer class.
>>  
> I
>
>> never knew that existed.
>>  
> Note also that some string methods have overloads for taking specific
> cultures, or the StringComparison enum. Both StringComparison.Ordinal
> and StringComparison.OrdinalIgnoreCase (as well as StringComparer) can
> be very useful to improve performance when culture-dependent behaviour
> is not needed or desirable.
>
> Culture-dependent string comparisons are a very complex topic. There's
> also an "invariant" culture for doing things in a culture-independent
> way.
>
>

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

Re: [Mono-list] String comparisons slow

[David S]

Will that is very true, I tend to think that users only tend to use the
characters on there keyboards. The ability to sort è (had to copy past this)
is important in certain applications. I just don't think
the English language uses it enough to require such a complicated default
compare. Then again, this really doesn't matter because it has to be the
same on both .Net and Mono. So, yah.

On Thu, Jul 22, 2010 at 12:06 AM, Atsushi Eno <
atsushi...@veritas-vos-liberabit.com> wrote:

> Exactly. Once Windows build gets stable, I'd run make run-test-ondotnet and
> see what's broken under 4.0 profile. I'm even not sure if it builds now
> though (I'll update my working copy only when I'm almost sure that it
> builds, as it's usually broken).
>
> Atsushi Eno
>
>
> On 2010/07/22 5:23, Michael Hutchinson wrote:
>
>> On Wed, Jul 21, 2010 at 3:35 PM, Alan  wrote:
>>
>>
>>> I believe that's the default since .NET 4.0. You'll have to check MSDN to
>>> be
>>> sure though. I'm fairly sure there's a page explaining which type of
>>> string
>>> sort is used where.
>>>
>>>
>> Yes, I'm pretty sure .NET 4.0 changed *some* string compares to be
>> ordinal by default instead of culture-dependent, so perf comparisons
>> between the .NET 4 and the Mono 2.0 profile could easily be biased by
>> this.
>>
>>
>>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Bojan Rajkovic]

Hi Alexander,

My understanding based on the documentation is that StringComparison.Ordinal
is essentially a C strcmp (in fact, it may be implemented as such under the
hood, via an icall to the C runtime code), and StringComparison.Invariant is
aware of surrogate pairs and composed characters, and is a linguistic
comparison (ie. this *letter* comes before the other, not this character
code).

--Bojan

2010/7/22 Alexander M. Batishchev 

> Michael, could you please clarify the difference between Ordinal and
> Invariant string comparison?
>
> -Original Message-
> From: mono-list-boun...@lists.ximian.com
> [mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael
> Hutchinson
> Sent: Thursday, July 22, 2010 12:29 AM
> To: David S
> Cc: mono-list@lists.ximian.com; wtftc
> Subject: Re: [Mono-list] String comparisons slow
>
> On Wed, Jul 21, 2010 at 3:30 PM, David S  wrote:
> > Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just
> run
> > the Ordinal??? Perhaps there are some weird alphabetizing things I just
> > don't understand. BTW, Thanks for tell us about the StringComparer class.
> I
> > never knew that existed.
>
> Note also that some string methods have overloads for taking specific
> cultures, or the StringComparison enum. Both StringComparison.Ordinal
> and StringComparison.OrdinalIgnoreCase (as well as StringComparer) can
> be very useful to improve performance when culture-dependent behaviour
> is not needed or desirable.
>
> Culture-dependent string comparisons are a very complex topic. There's
> also an "invariant" culture for doing things in a culture-independent
> way.
>
> --
> Michael Hutchinson
> http://mjhutchinson.com
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Alexander M. Batishchev]

Michael, could you please clarify the difference between Ordinal and
Invariant string comparison?

-Original Message-
From: mono-list-boun...@lists.ximian.com
[mailto:mono-list-boun...@lists.ximian.com] On Behalf Of Michael Hutchinson
Sent: Thursday, July 22, 2010 12:29 AM
To: David S
Cc: mono-list@lists.ximian.com; wtftc
Subject: Re: [Mono-list] String comparisons slow

On Wed, Jul 21, 2010 at 3:30 PM, David S  wrote:
> Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just
run
> the Ordinal??? Perhaps there are some weird alphabetizing things I just
> don't understand. BTW, Thanks for tell us about the StringComparer class.
I
> never knew that existed.

Note also that some string methods have overloads for taking specific
cultures, or the StringComparison enum. Both StringComparison.Ordinal
and StringComparison.OrdinalIgnoreCase (as well as StringComparer) can
be very useful to improve performance when culture-dependent behaviour
is not needed or desirable.

Culture-dependent string comparisons are a very complex topic. There's
also an "invariant" culture for doing things in a culture-independent
way.

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

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

Re: [Mono-list] String comparisons slow

[Atsushi Eno]

Exactly. Once Windows build gets stable, I'd run make run-test-ondotnet 
and see what's broken under 4.0 profile. I'm even not sure if it builds 
now though (I'll update my working copy only when I'm almost sure that 
it builds, as it's usually broken).

Atsushi Eno

On 2010/07/22 5:23, Michael Hutchinson wrote:
> On Wed, Jul 21, 2010 at 3:35 PM, Alan  wrote:
>
>> I believe that's the default since .NET 4.0. You'll have to check MSDN to be
>> sure though. I'm fairly sure there's a page explaining which type of string
>> sort is used where.
>>  
> Yes, I'm pretty sure .NET 4.0 changed *some* string compares to be
> ordinal by default instead of culture-dependent, so perf comparisons
> between the .NET 4 and the Mono 2.0 profile could easily be biased by
> this.
>
>

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

Re: [Mono-list] mono swallows threadpool exceptions

[Atsushi Eno]

Hello,

You can (and please) feel free to contribute bug reports. We just don't 
accept your patches to mono itself (including mcs).

Atsushi Eno

On 2010/07/22 11:40, Daniel Hughes wrote:
> I do not believe I am allowed to contribute to mono as I have used
> reflector on the .net class libraries.
>
> On Thu, Jul 22, 2010 at 12:02 AM, Stifu  wrote:
>
>> Among the bugs I reported, the ones which tended to get fixed the fastest
>> were the ones I submitted patches for. :)
>> Not catching an Exception (or throwing one) sounds like a trivial patch, but
>> I could be wrong.
>>
>>
>> Daniel Hughes wrote:
>>  
>>> And I found the bug.
>>>
>>> Bug 491191
>>>
>>> Which is over a year old.
>>>
>>> This one is not in an obscure part of the framework like my serial
>>> port bug so it should be fixed quickly??
>>>
>>>
>>>
>>> On Wed, Jul 21, 2010 at 10:21 PM, Daniel Hughes
>>> wrote:
>>>
 Ok I think I have it:

 http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions

 tells us that since .net 2.0 the runtime does not swallow threadpool
 exceptions. So that means that the mono implementation is wrong.

 On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes
 wrote:
  
> upon further reading this appears to be the correct behavior. Although
> it does not seem to be what is happening in .net I will need to do
> more investigation it seems.
>
> On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes
> wrote:
>
>> In trying to port our application to run on mono I have discovered
>> that mono is silently swallowing exceptions. This is a really big
>> deal, we expect these exceptions to bubble up and kill the
>> application.
>>
>> There is not even any indication that an exception has occurred it is
>> just lost.
>>
>> public static void Main (string[] args)
>> {
>> Action action = () =>
>> {
>> throw new Exception("this should Kill
>> the process but doesn't");
>> };
>>
>> ThreadPool.QueueUserWorkItem(_ =>  action());
>> while(true)
>> {
>> Thread.Sleep(1000);
>> Console.WriteLine("wrongly still
>> running");
>> }
>> }
>>
>> The implications of this could be catastrophic. Imagine some code
>> which performs a check, finds bad data and throws an exception.
>> However mono swallows that exception so instead of the program closing
>> it carries on running and uses the bad data. This results in sensitive
>> data being lost. Or in our case a radio being bricked.
>>
>> Can someone explain why mono is doing this and if their is some
>> setting / environment variable I can change to make unhandled
>> threadpool exceptions terminate the process as is expected.
>>
>>  
>
  
>>> ___
>>> Mono-list maillist  -  Mono-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-list
>>>
>>>
>>>
>> --
>> View this message in context: 
>> http://mono.1490590.n4.nabble.com/mono-swallows-threadpool-exceptions-tp2296815p2296994.html
>> Sent from the Mono - General mailing list archive at Nabble.com.
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>>  
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
>
>

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

Re: [Mono-list] mono swallows threadpool exceptions

[Daniel Hughes]

I do not believe I am allowed to contribute to mono as I have used
reflector on the .net class libraries.

On Thu, Jul 22, 2010 at 12:02 AM, Stifu  wrote:
>
> Among the bugs I reported, the ones which tended to get fixed the fastest
> were the ones I submitted patches for. :)
> Not catching an Exception (or throwing one) sounds like a trivial patch, but
> I could be wrong.
>
>
> Daniel Hughes wrote:
>>
>> And I found the bug.
>>
>> Bug 491191
>>
>> Which is over a year old.
>>
>> This one is not in an obscure part of the framework like my serial
>> port bug so it should be fixed quickly??
>>
>>
>>
>> On Wed, Jul 21, 2010 at 10:21 PM, Daniel Hughes 
>> wrote:
>>> Ok I think I have it:
>>>
>>> http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions
>>>
>>> tells us that since .net 2.0 the runtime does not swallow threadpool
>>> exceptions. So that means that the mono implementation is wrong.
>>>
>>> On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes 
>>> wrote:
 upon further reading this appears to be the correct behavior. Although
 it does not seem to be what is happening in .net I will need to do
 more investigation it seems.

 On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes 
 wrote:
> In trying to port our application to run on mono I have discovered
> that mono is silently swallowing exceptions. This is a really big
> deal, we expect these exceptions to bubble up and kill the
> application.
>
> There is not even any indication that an exception has occurred it is
> just lost.
>
>                public static void Main (string[] args)
>                {
>                        Action action = () =>
>                        {
>                                throw new Exception("this should Kill
> the process but doesn't");
>                        };
>
>                        ThreadPool.QueueUserWorkItem(_ => action());
>                        while(true)
>                        {
>                                Thread.Sleep(1000);
>                                Console.WriteLine("wrongly still
> running");
>                        }
>                }
>
> The implications of this could be catastrophic. Imagine some code
> which performs a check, finds bad data and throws an exception.
> However mono swallows that exception so instead of the program closing
> it carries on running and uses the bad data. This results in sensitive
> data being lost. Or in our case a radio being bricked.
>
> Can someone explain why mono is doing this and if their is some
> setting / environment variable I can change to make unhandled
> threadpool exceptions terminate the process as is expected.
>

>>>
>> ___
>> Mono-list maillist  -  mono-l...@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>>
>
> --
> View this message in context: 
> http://mono.1490590.n4.nabble.com/mono-swallows-threadpool-exceptions-tp2296815p2296994.html
> Sent from the Mono - General mailing list archive at Nabble.com.
> ___
> Mono-list maillist  -  mono-l...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Jonathan Pryor]

On Wed, 2010-07-21 at 15:30 -0400, David S wrote:
> Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't
> just run the Ordinal?

This may be hard to believe, but en-US (and en-UK) are more than just
ASCII.  Consider the word rèsumè, an English loan word from French.  Or
the "long s" [0] which, while not commonly used anymore, was used in no
less than the US Bill of Rights...

So, consider è: there are (at least) two ways to express it:

  - Precomposed as U+00E8
  - With combining chars as U+0065 U+0300.

Presumably when sorting entries, you would like \u00e8 to sort with
\u0065\u0300, not...elsewhere [1]; at least, this is usually what users
expect, as they (hopefully) don't know or care about ASCII, they just
want to use their data.

The other reason has to do with Windows collation [2] (and thus may or
may not matter for Mono, and certainly won't matter for Silverlight in
which the underlying platform's collation support is used), as the
default collation table contains collation data for 70 languages [3],
and (of course!) English uses the default table, so it gets a lot of
this collation information "for free".

 - Jon

[0] http://en.wikipedia.org/wiki/Long_s
[1] And "elsewhere" varies a lot; it could be intermingled with some 
other character, placed after all other characters, placed before 
all other characters...
[2] See also the years of articles written by Michael Kaplan, in which 
the default table is frequently mentioned: 
http://blogs.msdn.com/b/michkap/
[3] http://blogs.msdn.com/b/michkap/archive/2005/04/08/406413.aspx


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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

I was probably speaking too fast:

MCS [net_4_0] permview.exe
MCS [net_4_0] mozroots.exe
MCS [net_4_0] httpcfg.exe
make all-local
make all-local
make[7]: Nothing to be done for `all-local'.
make all-local
make[7]: Nothing to be done for `all-local'.
make all-local
MDOC[net_4_0] cs-errors.tree
Stacktrace:


Native stacktrace:

0   mono0x000100086e24
mono_handle_native_sigsegv + 292
1   mono0x00012d23
mono_sigsegv_signal_handler + 339
2   libSystem.B.dylib   0x7fff8849635a _sigtramp +
26
3   libSystem.B.dylib   0x7fff70f675c0
__stack_chk_guard + 0
4   ??? 0x000103472dc1 0x0 +
4349963713
* Assertion: should not be reached at mini-darwin.c:241

/bin/sh: line 1: 67859 Abort trap
MONO_PATH="./../class/lib/net_4_0:./../class/lib/net_2_0:$MONO_PATH"
/Users/sylvain/development/lib/mono-trunk/mono/runtime/mono-wrapper
./../tools/mdoc/mdoc.exe assemble -o cs-errors -f error cs-errors.config
make[7]: *** [cs-errors.tree] Error 134
make[6]: *** [do-all] Error 2
make[5]: *** [all-recursive] Error 1
make[4]: *** [profile-do--net_4_0--all] Error 2
make[3]: *** [profiles-do--all] Error 2
make[2]: *** [all-local] Error 2
make[1]: *** [all-recursive] Error 1

any idea?

Best regards,
Sylvain

On Thu, Jul 22, 2010 at 12:18 AM, Sylvain Pointeau <
sylvain.point...@gmail.com> wrote:

> make get-monolite-latest
>
> I forgot it... I am obliged to use it as I don't have any working
> installation,
> it is written in the README of the "mono" directory
> (maybe it should be indicated on the web page as well)
>
> so far it seems to build...
>
> Best regards,
> Sylvain
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

make get-monolite-latest

I forgot it... I am obliged to use it as I don't have any working
installation,
it is written in the README of the "mono" directory
(maybe it should be indicated on the web page as well)

so far it seems to build...

Best regards,
Sylvain

On Wed, Jul 21, 2010 at 11:48 PM, Sylvain Pointeau <
sylvain.point...@gmail.com> wrote:

> On Wed, Jul 21, 2010 at 11:42 PM, Geoff Norton  wrote:
>
>> http://mono-project.com/Compiling_Mono_From_SVN
>>
>>
> yes I saw it, but
>
> make EXTERNAL_MCS=/foo/bar/mcs EXTERNAL_RUNTIME=/somewhere/else/mono
>
> is not so clear
>
> should I do the make install first then reference the install path for MCS
> and MONO?
> or should I point to a directory in my build? but where?
>
> Best regards,
> Sylvain
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] mono swallows threadpool exceptions

[Miguel de Icaza]

Hello,

> And I found the bug.
> 
> Bug 491191
> 
> Which is over a year old.
> 
> This one is not in an obscure part of the framework like my serial
> port bug so it should be fixed quickly??

This is a different case.

In this case, the fear that we have is that existing applications that
were built on the Mono world (not on the .NET one) depend on the broken
behavior.

We might look at this for the 2.8 release as we are making various
breaking changes as well.

Miguel

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

On Wed, Jul 21, 2010 at 11:42 PM, Geoff Norton  wrote:

> http://mono-project.com/Compiling_Mono_From_SVN
>
>
yes I saw it, but

make EXTERNAL_MCS=/foo/bar/mcs EXTERNAL_RUNTIME=/somewhere/else/mono

is not so clear

should I do the make install first then reference the install path for MCS
and MONO?
or should I point to a directory in my build? but where?

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

http://mono-project.com/Compiling_Mono_From_SVN


On 2010-07-21, at 5:32 PM, Sylvain Pointeau wrote:

> 
> 
> On Wed, Jul 21, 2010 at 11:27 PM, Geoff Norton  wrote:
> You didn't checkout mcs;
> 
> -g
> 
> 
> right! I was just seeing now the next error...
> 
> mkdir -p -- build/deps
> touch build/deps/.stamp
> make[6]: gmcs: No such file or directory
> make[6]: *** [build/deps/basic-profile-check.exe] Error 1
> *** The compiler 'gmcs' doesn't appear to be usable.
> *** You need Mono version 2.4 or better installed to build MCS
> *** Read INSTALL.txt for information on how to bootstrap a Mono installation.
> make[5]: *** [do-profile-check] Error 1
> make[4]: *** [profile-do--basic--all] Error 2
> make[3]: *** [profiles-do--all] Error 2
> 
> Cheers,
> Sylvain

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

On Wed, Jul 21, 2010 at 11:27 PM, Geoff Norton  wrote:

> You didn't checkout mcs;
>
> -g
>
>
right! I was just seeing now the next error...

mkdir -p -- build/deps
touch build/deps/.stamp
make[6]: gmcs: No such file or directory
make[6]: *** [build/deps/basic-profile-check.exe] Error 1
*** The compiler 'gmcs' doesn't appear to be usable.
*** You need Mono version 2.4 or better installed to build MCS
*** Read INSTALL.txt for information on how to bootstrap a Mono
installation.
make[5]: *** [do-profile-check] Error 1
make[4]: *** [profile-do--basic--all] Error 2
make[3]: *** [profiles-do--all] Error 2

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

You didn't checkout mcs;

-g

On 2010-07-21, at 4:41 PM, Sylvain Pointeau wrote:

> On Wed, Jul 21, 2010 at 9:31 PM, Geoff Norton  wrote:
> Please follow the directions on the wiki:
> 
> http://www.mono-project.com/Compiling_Mono_on_OSX
> 
> pkg-config is required, pass ---enable-nls=no if you want to not have gettext 
> which is an optional dep.
> 
> glib2 and libiconv are not.
> 
> -g
> 
> it does not describe how to build the SVN...
> 
> furthermore I don't understand the error I have :
> 
> if test -w ; then :; else chmod -R +w ; fi
> cd  && make NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5  net_4_0 ' CC='gcc' 
> all-profiles
> make[3]: *** No rule to make target `all-profiles'.  Stop.
> make[2]: *** [all-local] Error 2
> 
> ...
> 
> Best regards,
> Sylvain

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

On Wed, Jul 21, 2010 at 9:31 PM, Geoff Norton  wrote:

> Please follow the directions on the wiki:
>
> http://www.mono-project.com/Compiling_Mono_on_OSX
>
> pkg-config is required, pass ---enable-nls=no if you want to not have
> gettext which is an optional dep.
>
> glib2 and libiconv are not.
>
> -g
>

it does not describe how to build the SVN...

furthermore I don't understand the error I have :

if test -w ; then :; else chmod -R +w ; fi
cd  && make NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5  net_4_0 ' CC='gcc'
all-profiles
make[3]: *** No rule to make target `all-profiles'.  Stop.
make[2]: *** [all-local] Error 2

...

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

Re: [Mono-list] String comparisons slow

[Michael Hutchinson]

On Wed, Jul 21, 2010 at 3:30 PM, David S  wrote:
> Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just run
> the Ordinal??? Perhaps there are some weird alphabetizing things I just
> don't understand. BTW, Thanks for tell us about the StringComparer class. I
> never knew that existed.

Note also that some string methods have overloads for taking specific
cultures, or the StringComparison enum. Both StringComparison.Ordinal
and StringComparison.OrdinalIgnoreCase (as well as StringComparer) can
be very useful to improve performance when culture-dependent behaviour
is not needed or desirable.

Culture-dependent string comparisons are a very complex topic. There's
also an "invariant" culture for doing things in a culture-independent
way.

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

Re: [Mono-list] String comparisons slow

[Michael Hutchinson]

On Wed, Jul 21, 2010 at 3:35 PM, Alan  wrote:
> I believe that's the default since .NET 4.0. You'll have to check MSDN to be
> sure though. I'm fairly sure there's a page explaining which type of string
> sort is used where.

Yes, I'm pretty sure .NET 4.0 changed *some* string compares to be
ordinal by default instead of culture-dependent, so perf comparisons
between the .NET 4 and the Mono 2.0 profile could easily be biased by
this.

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

What brings gettext?
What do I loose if I have not gettext?

Best regards,
Sylvain

On Wed, Jul 21, 2010 at 9:31 PM, Geoff Norton  wrote:

> Please follow the directions on the wiki:
>
> http://www.mono-project.com/Compiling_Mono_on_OSX
>
> pkg-config is required, pass ---enable-nls=no if you want to not have
> gettext which is an optional dep.
>
> glib2 and libiconv are not.
>
> -g
>
> On 2010-07-21, at 3:28 PM, Sylvain Pointeau wrote:
>
>
>
> On Wed, Jul 21, 2010 at 9:21 PM, Sylvain Pointeau <
> sylvain.point...@gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 21, 2010 at 9:03 PM, Sylvain Pointeau <
>> sylvain.point...@gmail.com> wrote:
>>
>>>  for compiling mono, I installed
> gettext 0.18.1.1
> libiconv 1.13.1
> glib-2.24.1
>
>
>
> You shouldn't have installed any of these as they aren't needed, and
> not supported on x86-64 darwin.
>


>>> I listened to you, then I uninstall all of them...
>> I rerun the command:
>>
>> ./autogen.sh --prefix=/user/local/mono64/ --build=x86_64-apple-darwin10
>>
>> then I have the error:
>>
>> configure: error: msgfmt not found. You need to install the 'gettext'
>> package, or pass --enable-nls=no to configure.
>>
>> Should I put the option --enable-nls=no then?
>>
>>
>>
> I just removed also pkg-config... and I have now:
>
> configure: error: You need to install pkg-config
> configure: error: ./configure failed for eglib
>
>
> Are you sure I should not install those tools?
>
> Best regards,
> Sylvain
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Alan]

I believe that's the default since .NET 4.0. You'll have to check MSDN to be
sure though. I'm fairly sure there's a page explaining which type of string
sort is used where.

Alan.

On Wed, Jul 21, 2010 at 8:30 PM, David S  wrote:

> Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just run
> the Ordinal??? Perhaps there are some weird alphabetizing things I just
> don't understand. BTW, Thanks for tell us about the StringComparer class. I
> never knew that existed.
>
>
> On Wed, Jul 21, 2010 at 2:56 PM, wtftc  wrote:
>
>>
>> Thanks, guys. This helped.
>>
>> Michael is right here. StringComparer.Ordinal made the sorting about 8x
>> faster for me.
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2297584.html
>> Sent from the Mono - General mailing list archive at Nabble.com.
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>
>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

Please follow the directions on the wiki:

http://www.mono-project.com/Compiling_Mono_on_OSX

pkg-config is required, pass ---enable-nls=no if you want to not have gettext 
which is an optional dep.

glib2 and libiconv are not.

-g

On 2010-07-21, at 3:28 PM, Sylvain Pointeau wrote:

> 
> 
> On Wed, Jul 21, 2010 at 9:21 PM, Sylvain Pointeau 
>  wrote:
> 
> 
> On Wed, Jul 21, 2010 at 9:03 PM, Sylvain Pointeau 
>  wrote:
>> for compiling mono, I installed
>> gettext 0.18.1.1
>> libiconv 1.13.1
>> glib-2.24.1
>>  
> 
> 
> You shouldn't have installed any of these as they aren't needed, and not 
> supported on x86-64 darwin.
> 
> 
> I listened to you, then I uninstall all of them...
> I rerun the command:
> 
> ./autogen.sh --prefix=/user/local/mono64/ --build=x86_64-apple-darwin10
> 
> then I have the error:
> 
> configure: error: msgfmt not found. You need to install the 'gettext' 
> package, or pass --enable-nls=no to configure.
> 
> Should I put the option --enable-nls=no then?
> 
> 
>  
> I just removed also pkg-config... and I have now:
> 
> configure: error: You need to install pkg-config
> configure: error: ./configure failed for eglib
> 
> 
> Are you sure I should not install those tools?
> 
> Best regards,
> Sylvain
> 

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

Re: [Mono-list] String comparisons slow

[David S]

Ok. Now I'm confused. How come "CurrentCulture" for US/ENG doesn't just run
the Ordinal??? Perhaps there are some weird alphabetizing things I just
don't understand. BTW, Thanks for tell us about the StringComparer class. I
never knew that existed.

On Wed, Jul 21, 2010 at 2:56 PM, wtftc  wrote:

>
> Thanks, guys. This helped.
>
> Michael is right here. StringComparer.Ordinal made the sorting about 8x
> faster for me.
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2297584.html
> Sent from the Mono - General mailing list archive at Nabble.com.
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

On Wed, Jul 21, 2010 at 9:21 PM, Sylvain Pointeau <
sylvain.point...@gmail.com> wrote:

>
>
> On Wed, Jul 21, 2010 at 9:03 PM, Sylvain Pointeau <
> sylvain.point...@gmail.com> wrote:
>
>>  for compiling mono, I installed
 gettext 0.18.1.1
 libiconv 1.13.1
 glib-2.24.1



 You shouldn't have installed any of these as they aren't needed, and not
 supported on x86-64 darwin.

>>>
>>>
>> I listened to you, then I uninstall all of them...
> I rerun the command:
>
> ./autogen.sh --prefix=/user/local/mono64/ --build=x86_64-apple-darwin10
>
> then I have the error:
>
> configure: error: msgfmt not found. You need to install the 'gettext'
> package, or pass --enable-nls=no to configure.
>
> Should I put the option --enable-nls=no then?
>
>
>
I just removed also pkg-config... and I have now:

configure: error: You need to install pkg-config
configure: error: ./configure failed for eglib


Are you sure I should not install those tools?

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

On Wed, Jul 21, 2010 at 9:03 PM, Sylvain Pointeau <
sylvain.point...@gmail.com> wrote:

> for compiling mono, I installed
>>> gettext 0.18.1.1
>>> libiconv 1.13.1
>>> glib-2.24.1
>>>
>>>
>>>
>>> You shouldn't have installed any of these as they aren't needed, and not
>>> supported on x86-64 darwin.
>>>
>>
>>
> I listened to you, then I uninstall all of them...
I rerun the command:

./autogen.sh --prefix=/user/local/mono64/ --build=x86_64-apple-darwin10

then I have the error:

configure: error: msgfmt not found. You need to install the 'gettext'
package, or pass --enable-nls=no to configure.

Should I put the option --enable-nls=no then?

Many thanks for your guidance,
Sylvain
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

now I have this error:

Making all in runtime
d=`cd ../support && pwd`; \
sed
's,target="libMonoPosixHelper[^"]*",target="'$d/libMonoPosixHelper.la'",'
../data/config > etc/mono/configt
if test -z ""; then :; else \
  sed 's,,& ,'
etc/mono/configt > etc/mono/configtt; \
  mv -f etc/mono/configtt etc/mono/configt; fi
mv -f etc/mono/configt etc/mono/config
/bin/sh ../mkinstalldirs _tmpinst/bin
mkdir -p -- _tmpinst/bin
cp mono-wrapper _tmpinst/bin/mono
echo '#! /bin/sh' > _tmpinst/bin/ilasm ; \
r=`pwd`; m=`cd  && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/ilasm/ilasm.exe"'" "$@"' >>
_tmpinst/bin/ilasm ; \
chmod +x _tmpinst/bin/ilasm
echo '#! /bin/sh' > _tmpinst/bin/gmcs ; \
r=`pwd`; m=`cd  && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'"
"'"$m/class/lib/net_2_0/gmcs.exe"'" "$@"' >> _tmpinst/bin/gmcs ; \
chmod +x _tmpinst/bin/gmcs
echo '#! /bin/sh' > _tmpinst/bin/dmcs ; \
r=`pwd`; m=`cd  && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'"
"'"$m/class/lib/net_4_0/dmcs.exe"'" "$@"' >> _tmpinst/bin/dmcs ; \
chmod +x _tmpinst/bin/dmcs
echo '#! /bin/sh' > _tmpinst/bin/al2 ; \
r=`pwd`; m=`cd  && pwd`; \
echo 'exec "'"$r/_tmpinst/bin/mono"'" "'"$m/class/lib/net_2_0/al.exe"'"
"$@"' >> _tmpinst/bin/al2 ; \
chmod +x _tmpinst/bin/al2
if test -w ; then :; else chmod -R +w ; fi
cd  && make NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5  net_4_0 ' CC='gcc'
all-profiles
make[3]: *** No rule to make target `all-profiles'.  Stop.
make[2]: *** [all-local] Error 2

What should I do?

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

>
> for compiling mono, I installed
>> gettext 0.18.1.1
>> libiconv 1.13.1
>> glib-2.24.1
>>
>>
>>
>> You shouldn't have installed any of these as they aren't needed, and not
>> supported on x86-64 darwin.
>>
>
> but why have I issue with my iconv provided by the system?
I never touched the tools in /usr/bin...

Do you have an idea?

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

>
> I installed:
> boost
> cmake
> git
> Qt
> readline
> sqlite
> icu
>
> for compiling mono, I installed
> gettext 0.18.1.1
> libiconv 1.13.1
> glib-2.24.1
>
>
>
> You shouldn't have installed any of these as they aren't needed, and not
> supported on x86-64 darwin.
>

do you mean gettext, libiconv, glib2 ?
ok then I will remove them, but as far as I have seen, it compiled
correctly...

Many thanks for your help,
best regards,
Sylvain
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[wtftc]

Thanks, guys. This helped.

Michael is right here. StringComparer.Ordinal made the sorting about 8x
faster for me.
-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2297584.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

sgen-os-mach.c:101: error: ‘REG_R13’ undeclared (first use in this function)

> sgen-os-mach.c:101: error: ‘REG_R14’ undeclared (first use in this
> function)
> sgen-os-mach.c:101: error: ‘REG_R15’ undeclared (first use in this
> function)
> make[3]: *** [libmonoruntimesgen_la-sgen-os-mach.lo] Error 1
>
>
> This will be fixed in svn shortly.
>
> already fixed? waoo thank you,
it continues to compile now.

I will keep you informed.

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

On 2010-07-21, at 2:23 PM, Sylvain Pointeau wrote:

> 
> 
> that's strange ... how can I introduce dependencies in my system?
> 
> make ended with an error:
> sgen-os-mach.c: In function ‘mono_sgen_thread_handshake’:
> sgen-os-mach.c:101: warning: implicit declaration of function ‘UCONTEXT_GREGS’
> sgen-os-mach.c:101: warning: nested extern declaration of ‘UCONTEXT_GREGS’
> sgen-os-mach.c:101: error: ‘REG_RAX’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: (Each undeclared identifier is reported only once
> sgen-os-mach.c:101: error: for each function it appears in.)
> sgen-os-mach.c:101: error: ‘REG_RBX’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_RCX’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_RDX’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_RSI’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_RDI’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_RBP’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R8’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R9’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R10’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R11’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R12’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R13’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R14’ undeclared (first use in this function)
> sgen-os-mach.c:101: error: ‘REG_R15’ undeclared (first use in this function)
> make[3]: *** [libmonoruntimesgen_la-sgen-os-mach.lo] Error 1
> 

This will be fixed in svn shortly.

> I installed:
> boost
> cmake
> git
> Qt
> readline
> sqlite
> icu
> 
> for compiling mono, I installed
> gettext 0.18.1.1
> libiconv 1.13.1
> glib-2.24.1
> 
You shouldn't have installed any of these as they aren't needed, and not 
supported on x86-64 darwin.

-g

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

that's strange ... how can I introduce dependencies in my system?

make ended with an error:
sgen-os-mach.c: In function ‘mono_sgen_thread_handshake’:
sgen-os-mach.c:101: warning: implicit declaration of function
‘UCONTEXT_GREGS’
sgen-os-mach.c:101: warning: nested extern declaration of ‘UCONTEXT_GREGS’
sgen-os-mach.c:101: error: ‘REG_RAX’ undeclared (first use in this function)
sgen-os-mach.c:101: error: (Each undeclared identifier is reported only once
sgen-os-mach.c:101: error: for each function it appears in.)
sgen-os-mach.c:101: error: ‘REG_RBX’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_RCX’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_RDX’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_RSI’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_RDI’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_RBP’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R8’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R9’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R10’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R11’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R12’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R13’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R14’ undeclared (first use in this function)
sgen-os-mach.c:101: error: ‘REG_R15’ undeclared (first use in this function)
make[3]: *** [libmonoruntimesgen_la-sgen-os-mach.lo] Error 1

I installed:
boost
cmake
git
Qt
readline
sqlite
icu

for compiling mono, I installed
gettext 0.18.1.1
libiconv 1.13.1
glib-2.24.1

I never installed something in /usr/bin
my system was reinstalled for Snow-leopard...
How could I have introduce weird dependencies ?
strange ...

Best regards,
Sylvain




On Wed, Jul 21, 2010 at 8:15 PM, Geoff Norton  wrote:

> You seem to have installed a bunch of weird dependencies into your
> environment.  I suggest following the wiki with a clean environment.
>
> iconv is included with osx, eglib is the only support glib method on x86_64
> darwin, etc.
>
> -g
>
> On 2010-07-21, at 2:06 PM, Sylvain Pointeau wrote:
>
> I re-installed libiconv on /usr/local/
>
> and I run the command:
>
> CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./autogen.sh
> --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
>
> I had a message saying I should not use host but build? do you have an
> idea?
> what are the value I can put? same as host?
>
> but I made "make", seems to run now.
>
> is it correct?
>
> Best regards,
> Sylvain
>
> On Wed, Jul 21, 2010 at 6:45 PM, Geoff Norton  wrote:
>
>> You dont; only eglib is supported on x86-64; libiconv is shipped with
>> apples compiler tho; so you'll need to figure out whats wrong with your
>> environment.
>>
>> -g
>>
>> On 2010-07-21, at 12:41 PM, Sylvain Pointeau wrote:
>>
>> I just made
>>
>> > svn co http://anonsvn.mono-project.com/source/trunk/mono
>> > ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
>> > make
>>
>> I have:
>>
>> Undefined symbols:
>>   "_libiconv_open", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>>   "_libiconv_close", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>>   "_libiconv", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>> ld: symbol(s) not found
>>
>>
>> How to force it by taking the glib2 in my /usr/local/ ?
>>
>> Many thanks for your help,
>> Sylvain
>>
>>
>>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

You seem to have installed a bunch of weird dependencies into your environment. 
 I suggest following the wiki with a clean environment.

iconv is included with osx, eglib is the only support glib method on x86_64 
darwin, etc.

-g

On 2010-07-21, at 2:06 PM, Sylvain Pointeau wrote:

> I re-installed libiconv on /usr/local/
> 
> and I run the command:
> 
> CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./autogen.sh 
> --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
> 
> I had a message saying I should not use host but build? do you have an idea?
> what are the value I can put? same as host?
> 
> but I made "make", seems to run now.
> 
> is it correct?
> 
> Best regards,
> Sylvain
> 
> On Wed, Jul 21, 2010 at 6:45 PM, Geoff Norton  wrote:
> You dont; only eglib is supported on x86-64; libiconv is shipped with apples 
> compiler tho; so you'll need to figure out whats wrong with your environment.
> 
> -g
> 
> On 2010-07-21, at 12:41 PM, Sylvain Pointeau wrote:
> 
>> I just made
>> 
>> > svn co http://anonsvn.mono-project.com/source/trunk/mono
>> > ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
>> > make
>> 
>> I have:
>> 
>> Undefined symbols:
>>   "_libiconv_open", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>>   "_libiconv_close", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>>   "_libiconv", referenced from:
>>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>> ld: symbol(s) not found
>> 
>> 
>> How to force it by taking the glib2 in my /usr/local/ ?
>> 
>> Many thanks for your help,
>> Sylvain
> 
> 

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

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

I re-installed libiconv on /usr/local/

and I run the command:

CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./autogen.sh
--prefix=/user/local/mono270/ --host=x86_64-apple-darwin10

I had a message saying I should not use host but build? do you have an idea?
what are the value I can put? same as host?

but I made "make", seems to run now.

is it correct?

Best regards,
Sylvain

On Wed, Jul 21, 2010 at 6:45 PM, Geoff Norton  wrote:

> You dont; only eglib is supported on x86-64; libiconv is shipped with
> apples compiler tho; so you'll need to figure out whats wrong with your
> environment.
>
> -g
>
> On 2010-07-21, at 12:41 PM, Sylvain Pointeau wrote:
>
> I just made
>
> > svn co http://anonsvn.mono-project.com/source/trunk/mono
> > ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
> > make
>
> I have:
>
> Undefined symbols:
>   "_libiconv_open", referenced from:
>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>   "_libiconv_close", referenced from:
>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
>   "_libiconv", referenced from:
>   _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
> ld: symbol(s) not found
>
>
> How to force it by taking the glib2 in my /usr/local/ ?
>
> Many thanks for your help,
> Sylvain
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

I just made

> svn co http://anonsvn.mono-project.com/source/trunk/mono
> ./autogen.sh --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
> make

I have:

Undefined symbols:
  "_libiconv_open", referenced from:
  _monoeg_g_convert in libeglib.a(libeglib_la-
gunicode.o)
  "_libiconv_close", referenced from:
  _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
  "_libiconv", referenced from:
  _monoeg_g_convert in libeglib.a(libeglib_la-gunicode.o)
ld: symbol(s) not found


How to force it by taking the glib2 in my /usr/local/ ?

Many thanks for your help,
Sylvain


On Wed, Jul 21, 2010 at 6:15 PM, Geoff Norton  wrote:

> You took some ancient revision; the current mono revision is in the 16
> range; you took 142439
>
> Check the sources out
>
> -g
>
> On 2010-07-21, at 12:13 PM, Sylvain Pointeau wrote:
>
> I am taking the tar.gz from svn...
> so it should compile right?
>
> On Wed, Jul 21, 2010 at 5:59 PM, Geoff Norton  wrote:
>
>> 64-bit support on OSX is only experimentally supported on SVN and Intel
>>
>> -g
>>
>> On 2010-07-21, at 11:45 AM, Sylvain Pointeau wrote:
>>
>> Hi,
>>
>> I am running in 64bits mode on my mac and I compiled everything in 64
>> bits.
>> therefore now, I am obliged to compile Mono in 64b as well.
>> I thought it will work to take the SVN version and to compile it with the
>> configure below:
>>
>> ./configure --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
>>
>> but I have this error then:
>>
>> /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\"libgc-mono\"
>> -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE_VERSION=\"6.6\"
>> -DPACKAGE_STRING=\"libgc-mono\ 6.6\" -DPACKAGE_BUGREPORT=\"
>> hans_bo...@hp.com\" -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1
>> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
>> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
>> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1
>> -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1
>> -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./..
>> -I./include  -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS
>> -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP
>> -DGetCurrentProcess=MonoGetCurrentProcess
>> -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent   -g
>> -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c
>> mkdir .libs
>>  gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\"
>> -DPACKAGE_VERSION=\"6.6\" "-DPACKAGE_STRING=\"libgc-mono 6.6\""
>> -DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\" -DGC_DARWIN_THREADS=1
>> -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
>> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>> -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1
>> -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1
>> -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE
>> -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP
>> -DGetCurrentProcess=MonoGetCurrentProcess
>> -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT
>> allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c  -fno-common -DPIC
>> -o .libs/allchblk.o
>> In file included from ./include/private/gc_priv.h:66,
>>  from allchblk.c:19:
>> ./include/private/gcconfig.h:500: error: expected identifier or ‘(’ before
>> ‘--’ token
>> make[3]: *** [allchblk.lo] Error 1
>> make[2]: *** [all-recursive] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> the configure command gave me this summary:
>>
>> mcs source:$(top_srcdir)/mcs
>> olive source:
>>
>> GC:   included
>> GLIB:   system
>> TLS:   pthread
>> SIGALTSTACK:   no
>> Engine:Building and using the JIT
>> 2.0 Profile:   yes
>> Moon Profile:  yes
>> 4.0 Alpha: no
>> MonoTouch: no
>> JNI support:   IKVM Native
>> libgdiplus:assumed to be installed
>> zlib:  bundled zlib
>> oprofile:  no
>> BigArrays: no
>> DTrace:no
>> Parallel Mark: Disabled_Currently_Hangs_On_MacOSX
>> LLVM Back End: no
>>
>> and I took the tar.gz from
>> http://mono.ximian.com/monobuild/snapshot/snapshot_sources/mono/mono-142439.tar.bz2
>>
>> I saw this message from the "how to build from source 
>> MACOSX"
>>
>> "If you wish to try the experimental 64-bit x86 support available in 2.7+
>> you should check out mono from svn and do:
>>
>>   $ cd mono-trunk
>>   $ ./configure --prefix=DIR --with-glib=embedded 
>> --host=x86_64-apple-darwin10
>>
>>
>>   $ make
>>   $ make install
>>
>> "
>>
>> What should I do?
>> is it possible to have it 64 bits?
>>
>> best regards,
>> Sylvain
>>
>>
>>
>>
>>

Re: [Mono-list] macosx --host=x86_64-apple-darwin10

[Geoff Norton]

64-bit support on OSX is only experimentally supported on SVN and Intel

-g

On 2010-07-21, at 11:45 AM, Sylvain Pointeau wrote:

> Hi,
> 
> I am running in 64bits mode on my mac and I compiled everything in 64 bits.
> therefore now, I am obliged to compile Mono in 64b as well.
> I thought it will work to take the SVN version and to compile it with the 
> configure below:
> 
> ./configure --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10
> 
> but I have this error then:
> 
> /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\"libgc-mono\" 
> -DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE_VERSION=\"6.6\" 
> -DPACKAGE_STRING=\"libgc-mono\ 6.6\" 
> -DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\" -DGC_DARWIN_THREADS=1 
> -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
> -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 
> -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 
> -D_IN_LIBGC=1 -I./.. -I./.. -I./include  -no-cpp-precomp -D_THREAD_SAFE 
> -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP 
> -DGetCurrentProcess=MonoGetCurrentProcess 
> -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent   -g   
> -MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c
> mkdir .libs
>  gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\" 
> -DPACKAGE_VERSION=\"6.6\" "-DPACKAGE_STRING=\"libgc-mono 6.6\"" 
> -DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\" -DGC_DARWIN_THREADS=1 
> -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
> -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 
> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
> -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 
> -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 
> -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE 
> -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP 
> -DGetCurrentProcess=MonoGetCurrentProcess 
> -DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT 
> allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c  -fno-common -DPIC 
> -o .libs/allchblk.o
> In file included from ./include/private/gc_priv.h:66,
>  from allchblk.c:19:
> ./include/private/gcconfig.h:500: error: expected identifier or ‘(’ before 
> ‘--’ token
> make[3]: *** [allchblk.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> the configure command gave me this summary:
> 
> mcs source:$(top_srcdir)/mcs
> olive source:  
> 
> GC:   included
> GLIB:   system
> TLS:   pthread
> SIGALTSTACK:   no
> Engine:Building and using the JIT
> 2.0 Profile:   yes
> Moon Profile:  yes
> 4.0 Alpha: no
> MonoTouch: no
> JNI support:   IKVM Native
> libgdiplus:assumed to be installed
> zlib:  bundled zlib
> oprofile:  no
> BigArrays: no
> DTrace:no
> Parallel Mark: Disabled_Currently_Hangs_On_MacOSX
> LLVM Back End: no
> 
> and I took the tar.gz from 
> http://mono.ximian.com/monobuild/snapshot/snapshot_sources/mono/mono-142439.tar.bz2
> 
> I saw this message from the "how to build from source MACOSX"
> "If you wish to try the experimental 64-bit x86 support available in 2.7+ you 
> should check out mono from svn and do:
> 
>   $ cd mono-trunk
>   $ ./configure --prefix=DIR --with-glib=embedded --host=x86_64-apple-darwin10
> 
>   $ make
>   $ make install
> "
> 
> What should I do?
> is it possible to have it 64 bits?
> 
> best regards,
> Sylvain
> 
> 
> 
> 
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list

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

[Mono-list] macosx --host=x86_64-apple-darwin10

[Sylvain Pointeau]

Hi,

I am running in 64bits mode on my mac and I compiled everything in 64 bits.
therefore now, I am obliged to compile Mono in 64b as well.
I thought it will work to take the SVN version and to compile it with the
configure below:

./configure --prefix=/user/local/mono270/ --host=x86_64-apple-darwin10

but I have this error then:

/bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\"libgc-mono\"
-DPACKAGE_TARNAME=\"libgc-mono\" -DPACKAGE_VERSION=\"6.6\"
-DPACKAGE_STRING=\"libgc-mono\ 6.6\" -DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\"
-DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1
-DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1
-DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include
-no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX
-DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess
-DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent   -g
-MT allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c -o allchblk.lo allchblk.c
mkdir .libs
 gcc -DPACKAGE_NAME=\"libgc-mono\" -DPACKAGE_TARNAME=\"libgc-mono\"
-DPACKAGE_VERSION=\"6.6\" "-DPACKAGE_STRING=\"libgc-mono 6.6\""
-DPACKAGE_BUGREPORT=\"hans_bo...@hp.com\" -DGC_DARWIN_THREADS=1
-DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1
-DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1
-D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE
-DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP
-DGetCurrentProcess=MonoGetCurrentProcess
-DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT
allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c  -fno-common -DPIC
-o .libs/allchblk.o
In file included from ./include/private/gc_priv.h:66,
 from allchblk.c:19:
./include/private/gcconfig.h:500: error: expected identifier or ‘(’ before
‘--’ token
make[3]: *** [allchblk.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

the configure command gave me this summary:

mcs source:$(top_srcdir)/mcs
olive source:

GC:   included
GLIB:   system
TLS:   pthread
SIGALTSTACK:   no
Engine:Building and using the JIT
2.0 Profile:   yes
Moon Profile:  yes
4.0 Alpha: no
MonoTouch: no
JNI support:   IKVM Native
libgdiplus:assumed to be installed
zlib:  bundled zlib
oprofile:  no
BigArrays: no
DTrace:no
Parallel Mark: Disabled_Currently_Hangs_On_MacOSX
LLVM Back End: no

and I took the tar.gz from
http://mono.ximian.com/monobuild/snapshot/snapshot_sources/mono/mono-142439.tar.bz2

I saw this message from the "how to build from source
MACOSX"

"If you wish to try the experimental 64-bit x86 support available in 2.7+
you should check out mono from svn and do:

  $ cd mono-trunk
  $ ./configure --prefix=DIR --with-glib=embedded --host=x86_64-apple-darwin10
  $ make
  $ make install

"

What should I do?
is it possible to have it 64 bits?

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

Re: [Mono-list] mono swallows threadpool exceptions

[Stifu]

Among the bugs I reported, the ones which tended to get fixed the fastest
were the ones I submitted patches for. :)
Not catching an Exception (or throwing one) sounds like a trivial patch, but
I could be wrong.


Daniel Hughes wrote:
> 
> And I found the bug.
> 
> Bug 491191
> 
> Which is over a year old.
> 
> This one is not in an obscure part of the framework like my serial
> port bug so it should be fixed quickly??
> 
> 
> 
> On Wed, Jul 21, 2010 at 10:21 PM, Daniel Hughes 
> wrote:
>> Ok I think I have it:
>>
>> http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions
>>
>> tells us that since .net 2.0 the runtime does not swallow threadpool
>> exceptions. So that means that the mono implementation is wrong.
>>
>> On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes 
>> wrote:
>>> upon further reading this appears to be the correct behavior. Although
>>> it does not seem to be what is happening in .net I will need to do
>>> more investigation it seems.
>>>
>>> On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes 
>>> wrote:
 In trying to port our application to run on mono I have discovered
 that mono is silently swallowing exceptions. This is a really big
 deal, we expect these exceptions to bubble up and kill the
 application.

 There is not even any indication that an exception has occurred it is
 just lost.

                public static void Main (string[] args)
                {
                        Action action = () =>
                        {
                                throw new Exception("this should Kill
 the process but doesn't");
                        };

                        ThreadPool.QueueUserWorkItem(_ => action());
                        while(true)
                        {
                                Thread.Sleep(1000);
                                Console.WriteLine("wrongly still
 running");
                        }
                }

 The implications of this could be catastrophic. Imagine some code
 which performs a check, finds bad data and throws an exception.
 However mono swallows that exception so instead of the program closing
 it carries on running and uses the bad data. This results in sensitive
 data being lost. Or in our case a radio being bricked.

 Can someone explain why mono is doing this and if their is some
 setting / environment variable I can change to make unhandled
 threadpool exceptions terminate the process as is expected.

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

-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/mono-swallows-threadpool-exceptions-tp2296815p2296994.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] mono swallows threadpool exceptions

[Daniel Hughes]

And I found the bug.

Bug 491191

Which is over a year old.

This one is not in an obscure part of the framework like my serial
port bug so it should be fixed quickly??



On Wed, Jul 21, 2010 at 10:21 PM, Daniel Hughes  wrote:
> Ok I think I have it:
>
> http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions
>
> tells us that since .net 2.0 the runtime does not swallow threadpool
> exceptions. So that means that the mono implementation is wrong.
>
> On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes  wrote:
>> upon further reading this appears to be the correct behavior. Although
>> it does not seem to be what is happening in .net I will need to do
>> more investigation it seems.
>>
>> On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes  wrote:
>>> In trying to port our application to run on mono I have discovered
>>> that mono is silently swallowing exceptions. This is a really big
>>> deal, we expect these exceptions to bubble up and kill the
>>> application.
>>>
>>> There is not even any indication that an exception has occurred it is just 
>>> lost.
>>>
>>>                public static void Main (string[] args)
>>>                {
>>>                        Action action = () =>
>>>                        {
>>>                                throw new Exception("this should Kill the 
>>> process but doesn't");
>>>                        };
>>>
>>>                        ThreadPool.QueueUserWorkItem(_ => action());
>>>                        while(true)
>>>                        {
>>>                                Thread.Sleep(1000);
>>>                                Console.WriteLine("wrongly still running");
>>>                        }
>>>                }
>>>
>>> The implications of this could be catastrophic. Imagine some code
>>> which performs a check, finds bad data and throws an exception.
>>> However mono swallows that exception so instead of the program closing
>>> it carries on running and uses the bad data. This results in sensitive
>>> data being lost. Or in our case a radio being bricked.
>>>
>>> Can someone explain why mono is doing this and if their is some
>>> setting / environment variable I can change to make unhandled
>>> threadpool exceptions terminate the process as is expected.
>>>
>>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] mono swallows threadpool exceptions

[Daniel Hughes]

Ok I think I have it:

http://msdn.microsoft.com/en-us/library/ms228965.aspx#ChangeFromPreviousVersions

tells us that since .net 2.0 the runtime does not swallow threadpool
exceptions. So that means that the mono implementation is wrong.

On Wed, Jul 21, 2010 at 9:51 PM, Daniel Hughes  wrote:
> upon further reading this appears to be the correct behavior. Although
> it does not seem to be what is happening in .net I will need to do
> more investigation it seems.
>
> On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes  wrote:
>> In trying to port our application to run on mono I have discovered
>> that mono is silently swallowing exceptions. This is a really big
>> deal, we expect these exceptions to bubble up and kill the
>> application.
>>
>> There is not even any indication that an exception has occurred it is just 
>> lost.
>>
>>                public static void Main (string[] args)
>>                {
>>                        Action action = () =>
>>                        {
>>                                throw new Exception("this should Kill the 
>> process but doesn't");
>>                        };
>>
>>                        ThreadPool.QueueUserWorkItem(_ => action());
>>                        while(true)
>>                        {
>>                                Thread.Sleep(1000);
>>                                Console.WriteLine("wrongly still running");
>>                        }
>>                }
>>
>> The implications of this could be catastrophic. Imagine some code
>> which performs a check, finds bad data and throws an exception.
>> However mono swallows that exception so instead of the program closing
>> it carries on running and uses the bad data. This results in sensitive
>> data being lost. Or in our case a radio being bricked.
>>
>> Can someone explain why mono is doing this and if their is some
>> setting / environment variable I can change to make unhandled
>> threadpool exceptions terminate the process as is expected.
>>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] mono swallows threadpool exceptions

[Daniel Hughes]

upon further reading this appears to be the correct behavior. Although
it does not seem to be what is happening in .net I will need to do
more investigation it seems.

On Wed, Jul 21, 2010 at 9:16 PM, Daniel Hughes  wrote:
> In trying to port our application to run on mono I have discovered
> that mono is silently swallowing exceptions. This is a really big
> deal, we expect these exceptions to bubble up and kill the
> application.
>
> There is not even any indication that an exception has occurred it is just 
> lost.
>
>                public static void Main (string[] args)
>                {
>                        Action action = () =>
>                        {
>                                throw new Exception("this should Kill the 
> process but doesn't");
>                        };
>
>                        ThreadPool.QueueUserWorkItem(_ => action());
>                        while(true)
>                        {
>                                Thread.Sleep(1000);
>                                Console.WriteLine("wrongly still running");
>                        }
>                }
>
> The implications of this could be catastrophic. Imagine some code
> which performs a check, finds bad data and throws an exception.
> However mono swallows that exception so instead of the program closing
> it carries on running and uses the bad data. This results in sensitive
> data being lost. Or in our case a radio being bricked.
>
> Can someone explain why mono is doing this and if their is some
> setting / environment variable I can change to make unhandled
> threadpool exceptions terminate the process as is expected.
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Creating a stand-alone linux executable

[Tim Martin]

On 20/07/2010 4:01 PM, Robert Jordan wrote:
> It's due to a missing native SO (libMonoPosixHelper.so).
> Mkbundle does not embed native libraries (excepting
> libmono when the --static option is used).
>
> Those libraries must be deployed manually (side-by-side
> with your bundle).
>
OK, thanks. I've deployed libMonoPosixHelper.so to the test box. I now 
have the executable file and .so file in the same directory. It only 
works if I add the directory to the LD_LIBRARY_PATH - I can probably 
work around this, but is there a better way to configure it? Can the 
current directory be added to the rpath, or something?

Thanks to Alexander as well, --deps appears to work OK if I list the 
application-specific DLLs on the command line (Mono deps are pulled in 
automatically). I'm not sure why this is, but it works well enough for me.

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

[Mono-list] mono swallows threadpool exceptions

[Daniel Hughes]

In trying to port our application to run on mono I have discovered
that mono is silently swallowing exceptions. This is a really big
deal, we expect these exceptions to bubble up and kill the
application.

There is not even any indication that an exception has occurred it is just lost.

public static void Main (string[] args)
{
Action action = () =>
{
throw new Exception("this should Kill the 
process but doesn't");
};

ThreadPool.QueueUserWorkItem(_ => action());
while(true)
{
Thread.Sleep(1000);
Console.WriteLine("wrongly still running");
}
}

The implications of this could be catastrophic. Imagine some code
which performs a check, finds bad data and throws an exception.
However mono swallows that exception so instead of the program closing
it carries on running and uses the bad data. This results in sensitive
data being lost. Or in our case a radio being bricked.

Can someone explain why mono is doing this and if their is some
setting / environment variable I can change to make unhandled
threadpool exceptions terminate the process as is expected.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Creating a stand-alone linux executable

[Alexander Shulgin]

On 21.07.2010 11:32, Tim Martin wrote:
> On 20/07/2010 3:43 PM, Alexander Shulgin wrote:
>> You're missing the --deps parameter, obviously.
>>
>
> Thanks for the suggestion. I originally tried --deps, but it doesn't
> work for me. I get the error message:
>
> Unhandled Exception: System.IO.FileNotFoundException: Could not load
> file or assembly 'Foobar.Common.Support' or one of its dependencies. The
> system cannot find the file specified.
> File name: 'Foobar.Common.Support'
> at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef,
> System.Security.Policy.Evidence assemblySecurity) [0x0]
> at (wrapper remoting-invoke-with-check) System.AppDomain:Load
> (System.Reflection.AssemblyName,System.Security.Policy.Evidence)
> at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef)
> [0x0]
> at (wrapper remoting-invoke-with-check) System.AppDomain:Load
> (System.Reflection.AssemblyName)
> at System.Reflection.Assembly.Load (System.Reflection.AssemblyName
> assemblyRef) [0x0]
> at MakeBundle.QueueAssembly (System.Collections.ArrayList files,
> System.String codebase) [0x0]
> at MakeBundle.Main (System.String[] args) [0x0]
>
> But Foobar.Common.Support.dll exists in the current directory where I'm
> trying to make the bundle, and if I explicitly list it on the command
> line then it adds it without trouble. I tried mucking with the -L flag,
> but that doesn't seem to help. I've analysed the dependencies of the DLL
> in Windows, and the only non-core dependency is also present in the
> directory.
>
> Any suggestions?

Sorry, not sure.  May be it should be looking for 
`Foobar.Common.Support.dll' and not plain `Foobar.Common.Support'?  You 
might need to check your assembly references.

Otherwise, if it works by adding Foobar.Common.Support.dll on command 
line, why not try going this way?

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

Re: [Mono-list] String comparisons slow

[Michael Hutchinson]

On Wed, Jul 21, 2010 at 4:18 AM, David S  wrote:
> Man, I wish there was an edit on a Mailing List. ANYWHO, I made my own

> I'm pretty sure that compare is good. But now I get
> OUTPUT = 00:00:01.6366606
> Then again, I could have messed up my compare so someone check it again for
> me. Its not the perfect solution, but its kinda cool that it might be right
> and faster than the original. XP Thinking about it, this might only work
> with English  hmmm food for thought.

Or you could just use StringComparer.Ordinal.

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

Re: [Mono-list] Creating a stand-alone linux executable

[Tim Martin]

On 20/07/2010 3:43 PM, Alexander Shulgin wrote:
> You're missing the --deps parameter, obviously.
>

Thanks for the suggestion. I originally tried --deps, but it doesn't 
work for me. I get the error message:

Unhandled Exception: System.IO.FileNotFoundException: Could not load 
file or assembly 'Foobar.Common.Support' or one of its dependencies. The 
system cannot find the file specified.
File name: 'Foobar.Common.Support'
   at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef, 
System.Security.Policy.Evidence assemblySecurity) [0x0]
   at (wrapper remoting-invoke-with-check) System.AppDomain:Load 
(System.Reflection.AssemblyName,System.Security.Policy.Evidence)
   at System.AppDomain.Load (System.Reflection.AssemblyName assemblyRef) 
[0x0]
   at (wrapper remoting-invoke-with-check) System.AppDomain:Load 
(System.Reflection.AssemblyName)
   at System.Reflection.Assembly.Load (System.Reflection.AssemblyName 
assemblyRef) [0x0]
   at MakeBundle.QueueAssembly (System.Collections.ArrayList files, 
System.String codebase) [0x0]
   at MakeBundle.Main (System.String[] args) [0x0]

But Foobar.Common.Support.dll exists in the current directory where I'm 
trying to make the bundle, and if I explicitly list it on the command 
line then it adds it without trouble. I tried mucking with the -L flag, 
but that doesn't seem to help. I've analysed the dependencies of the DLL 
in Windows, and the only non-core dependency is also present in the 
directory.

Any suggestions?

Thanks,

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

Re: [Mono-list] String comparisons slow

[David S]

Man, I wish there was an edit on a Mailing List. ANYWHO, I made my own
string compare

public static void Main()
{
List> lists = new List>();
Random r = new Random();
for ( int i=0; i < 4; i++ ) {
lists.Add( new List() );
for ( int j=0; j < 40; j++ )
lists[i].Add( r.Next().ToString() );
}
Stopwatch watch = new Stopwatch();
watch.Start();
foreach ( List list in lists )
list.Sort( (string a, string b) => {
string longer = a;
string shorter = b;
if ( a.Length < b.Length ) {
longer = b;
shorter = a;
}
for ( int i=0; i < shorter.Length; i++ ) {
if ( shorter[i] < longer[i] )
return -1;
else if ( shorter[i] > longer[i] )
return 1;
}
if ( a.Length == b.Length )
return 0;
else
return 1;
});
watch.Stop();
Console.WriteLine( watch.Elapsed );
}

I'm pretty sure that compare is good. But now I get

OUTPUT = 00:00:01.6366606

Then again, I could have messed up my compare so someone check it again for
me. Its not the perfect solution, but its kinda cool that it might be right
and faster than the original. XP Thinking about it, this might only work
with English  hmmm food for thought.

On Wed, Jul 21, 2010 at 4:06 AM, David S  wrote:

> Ran the mono profiler which should be taken with a grain of salt but
> whatever
>
>2639 25.83 % Mono.Globalization.Unicode.CodePointIndexer:ToIndex (int)
>1921 18.80 % Mono.Globalization.Unicode.SimpleCollator:CompareInternal
> (string,int,int,string,int,int,bool&,bool&,bool,bool,Mono.Globalization.Unicode.SimpleCollator/Context&)
> 824 8.06 % Mono.Globalization.Unicode.SimpleCollator:GetContraction
> (string,int,int,Mono.Globalization.Unicode.Contraction[])
> 505 4.94 % Mono.Globalization.Unicode.MSCompatUnicodeTable:IsIgnorable
> (int,byte)
> 354 3.46 % Mono.Globalization.Unicode.SimpleCollator:Category (int)
> 332 3.25 % Mono.Globalization.Unicode.SimpleCollator:GetContraction
> (string,int,int)
> 311 3.04 % Mono.Globalization.Unicode.SimpleCollator:Compare
> (string,int,int,string,int,int,System.Globalization.CompareOptions)
> 289 2.83 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Category
> (int)
> 233 2.28 % Mono.Globalization.Unicode.SimpleCollator:IsIgnorable
> (int,System.Globalization.CompareOptions)
> 233 2.28 % Mono.Globalization.Unicode.SimpleCollator:FilterOptions
> (int,System.Globalization.CompareOptions)
> 227 2.22 % Mono.Globalization.Unicode.SimpleCollator:GetExtenderType
> (int)
> 178 1.74 % Mono.Globalization.Unicode.SimpleCollator:Level1 (int)
> 168 1.64 % Mono.Globalization.Unicode.SimpleCollator:Level2
> (int,Mono.Globalization.Unicode.SimpleCollator/ExtenderType)
> 167 1.63 %
> Mono.Globalization.Unicode.MSCompatUnicodeTable:HasSpecialWeight (char)
> 156 1.53 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level3
> (int)
> 156 1.53 % mono()
> 151 1.48 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level2
> (int)
> 118 1.15 %
> 116 1.14 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level1
> (int)
>
> Looks like MSCompatUnicodeTable, SimpleCollator, and CodePointIndexer are
> just going to town on it. Well, I don't have the mono source on this comp to
> look into it any further.
>
> OH btw Im using Mono 2.4.4 :)
>
> On Wed, Jul 21, 2010 at 4:00 AM, David S  wrote:
>
>> I take it back. DAM YOU MISSING ZERO.
>>
>> for ( int j=0; j < 4; j++ ) // missing a 0 >.>
>>
>> Output = 00:00:39.8547202 LOL I got pwned.
>>
>>
>> On Wed, Jul 21, 2010 at 3:57 AM, David S  wrote:
>>
>>> I think there is another problem that is hidden behind all the complexity
>>> of your program. I can tell you this, it isn't string comparer.
>>>
>>> using System;
>>> using System.Collections.Generic;
>>> using System.Diagnostics;
>>>
>>> namespace StringCompare
>>> {
>>>
>>>
>>> public class MainClass
>>>  {
>>>
>>> public static void Main()
>>> {
>>>  List> lists = new List>();
>>> Random r = new Random();
>>>  for ( int i=0; i < 4; i++ ) {
>>> lists.Add( new List() );
>>>  for ( int j=0; j < 4; j++ )
>>> lists[i].Add( r.Next().ToString() );
>>>  }
>>> Stopwatch watch = new Stopwatch();
>>> watch.Start();
>>>  foreach ( List list in lists )
>>> list.Sort();
>>> watch.Stop();
>>>  Console.WriteLine( watch.Elapsed );
>>> }
>>> }
>>> }
>>>
>>> OUTPUT = 00:00:03.1364747
>>>
>>> That being said I think its how you set up your threading. It could
>>> very easily be how Mono handles Threads (sleeping and such). Honestly, I
>>> have no idea, but I am intrigued.
>>>
>>> On Wed, Jul 21, 2010 at 3:31 AM, Stifu  wrote:
>>>

 No release date, but Miguel recently said [1] "6-8 weeks from now."
 No idea how it compares with the .NET GC.

 [1] http://tirania.org/blog/archive/2010/Jul-14.html


 Mike Christensen-2 wrote:
 >
 > Is there a release date for 2.8?
 >
 > Also, how does the 2.8 GC (I realize it's only a beta) compare with
 the
 > .NET GC?
 >
 > Mike
 >
 > On Tue, Jul 20, 2010 at 11:19 PM, Stifu  wrote:
 >>
 >> There has

Re: [Mono-list] String comparisons slow

[David S]

Ran the mono profiler which should be taken with a grain of salt but
whatever

   2639 25.83 % Mono.Globalization.Unicode.CodePointIndexer:ToIndex (int)
   1921 18.80 % Mono.Globalization.Unicode.SimpleCollator:CompareInternal
(string,int,int,string,int,int,bool&,bool&,bool,bool,Mono.Globalization.Unicode.SimpleCollator/Context&)
824 8.06 % Mono.Globalization.Unicode.SimpleCollator:GetContraction
(string,int,int,Mono.Globalization.Unicode.Contraction[])
505 4.94 % Mono.Globalization.Unicode.MSCompatUnicodeTable:IsIgnorable
(int,byte)
354 3.46 % Mono.Globalization.Unicode.SimpleCollator:Category (int)
332 3.25 % Mono.Globalization.Unicode.SimpleCollator:GetContraction
(string,int,int)
311 3.04 % Mono.Globalization.Unicode.SimpleCollator:Compare
(string,int,int,string,int,int,System.Globalization.CompareOptions)
289 2.83 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Category
(int)
233 2.28 % Mono.Globalization.Unicode.SimpleCollator:IsIgnorable
(int,System.Globalization.CompareOptions)
233 2.28 % Mono.Globalization.Unicode.SimpleCollator:FilterOptions
(int,System.Globalization.CompareOptions)
227 2.22 % Mono.Globalization.Unicode.SimpleCollator:GetExtenderType
(int)
178 1.74 % Mono.Globalization.Unicode.SimpleCollator:Level1 (int)
168 1.64 % Mono.Globalization.Unicode.SimpleCollator:Level2
(int,Mono.Globalization.Unicode.SimpleCollator/ExtenderType)
167 1.63 %
Mono.Globalization.Unicode.MSCompatUnicodeTable:HasSpecialWeight (char)
156 1.53 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level3 (int)
156 1.53 % mono()
151 1.48 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level2 (int)
118 1.15 %
116 1.14 % Mono.Globalization.Unicode.MSCompatUnicodeTable:Level1 (int)

Looks like MSCompatUnicodeTable, SimpleCollator, and CodePointIndexer are
just going to town on it. Well, I don't have the mono source on this comp to
look into it any further.

OH btw Im using Mono 2.4.4 :)

On Wed, Jul 21, 2010 at 4:00 AM, David S  wrote:

> I take it back. DAM YOU MISSING ZERO.
>
> for ( int j=0; j < 4; j++ ) // missing a 0 >.>
>
> Output = 00:00:39.8547202 LOL I got pwned.
>
>
> On Wed, Jul 21, 2010 at 3:57 AM, David S  wrote:
>
>> I think there is another problem that is hidden behind all the complexity
>> of your program. I can tell you this, it isn't string comparer.
>>
>> using System;
>> using System.Collections.Generic;
>> using System.Diagnostics;
>>
>> namespace StringCompare
>> {
>>
>>
>> public class MainClass
>>  {
>>
>> public static void Main()
>> {
>>  List> lists = new List>();
>> Random r = new Random();
>>  for ( int i=0; i < 4; i++ ) {
>> lists.Add( new List() );
>>  for ( int j=0; j < 4; j++ )
>> lists[i].Add( r.Next().ToString() );
>>  }
>> Stopwatch watch = new Stopwatch();
>> watch.Start();
>>  foreach ( List list in lists )
>> list.Sort();
>> watch.Stop();
>>  Console.WriteLine( watch.Elapsed );
>> }
>> }
>> }
>>
>> OUTPUT = 00:00:03.1364747
>>
>> That being said I think its how you set up your threading. It could
>> very easily be how Mono handles Threads (sleeping and such). Honestly, I
>> have no idea, but I am intrigued.
>>
>> On Wed, Jul 21, 2010 at 3:31 AM, Stifu  wrote:
>>
>>>
>>> No release date, but Miguel recently said [1] "6-8 weeks from now."
>>> No idea how it compares with the .NET GC.
>>>
>>> [1] http://tirania.org/blog/archive/2010/Jul-14.html
>>>
>>>
>>> Mike Christensen-2 wrote:
>>> >
>>> > Is there a release date for 2.8?
>>> >
>>> > Also, how does the 2.8 GC (I realize it's only a beta) compare with the
>>> > .NET GC?
>>> >
>>> > Mike
>>> >
>>> > On Tue, Jul 20, 2010 at 11:19 PM, Stifu  wrote:
>>> >>
>>> >> There has been performance improvements since Mono 2.0. You may get
>>> >> better
>>> >> results with Mono 2.6. Or if you're not in a hurry, wait for Mono 2.8
>>> >> which
>>> >> should come out soon (that way you could also check out performances
>>> with
>>> >> the new GC).
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296643.html
>>> >> Sent from the Mono - General mailing list archive at Nabble.com.
>>> >> ___
>>> >> Mono-list maillist  -  Mono-list@lists.ximian.com
>>> >> http://lists.ximian.com/mailman/listinfo/mono-list
>>> >>
>>> > ___
>>> > Mono-list maillist  -  Mono-list@lists.ximian.com
>>> > http://lists.ximian.com/mailman/listinfo/mono-list
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296702.html
>>> Sent from the Mono - General mailing list archive at Nabble.com.
>>> ___
>>> Mono-list maillist  -  Mono-list@lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-list
>>>
>>
>>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com

Re: [Mono-list] String comparisons slow

[David S]

I take it back. DAM YOU MISSING ZERO.

for ( int j=0; j < 4; j++ ) // missing a 0 >.>

Output = 00:00:39.8547202 LOL I got pwned.

On Wed, Jul 21, 2010 at 3:57 AM, David S  wrote:

> I think there is another problem that is hidden behind all the complexity
> of your program. I can tell you this, it isn't string comparer.
>
> using System;
> using System.Collections.Generic;
> using System.Diagnostics;
>
> namespace StringCompare
> {
>
>
> public class MainClass
>  {
>
> public static void Main()
> {
>  List> lists = new List>();
> Random r = new Random();
>  for ( int i=0; i < 4; i++ ) {
> lists.Add( new List() );
>  for ( int j=0; j < 4; j++ )
> lists[i].Add( r.Next().ToString() );
>  }
> Stopwatch watch = new Stopwatch();
> watch.Start();
>  foreach ( List list in lists )
> list.Sort();
> watch.Stop();
>  Console.WriteLine( watch.Elapsed );
> }
> }
> }
>
> OUTPUT = 00:00:03.1364747
>
> That being said I think its how you set up your threading. It could
> very easily be how Mono handles Threads (sleeping and such). Honestly, I
> have no idea, but I am intrigued.
>
> On Wed, Jul 21, 2010 at 3:31 AM, Stifu  wrote:
>
>>
>> No release date, but Miguel recently said [1] "6-8 weeks from now."
>> No idea how it compares with the .NET GC.
>>
>> [1] http://tirania.org/blog/archive/2010/Jul-14.html
>>
>>
>> Mike Christensen-2 wrote:
>> >
>> > Is there a release date for 2.8?
>> >
>> > Also, how does the 2.8 GC (I realize it's only a beta) compare with the
>> > .NET GC?
>> >
>> > Mike
>> >
>> > On Tue, Jul 20, 2010 at 11:19 PM, Stifu  wrote:
>> >>
>> >> There has been performance improvements since Mono 2.0. You may get
>> >> better
>> >> results with Mono 2.6. Or if you're not in a hurry, wait for Mono 2.8
>> >> which
>> >> should come out soon (that way you could also check out performances
>> with
>> >> the new GC).
>> >> --
>> >> View this message in context:
>> >>
>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296643.html
>> >> Sent from the Mono - General mailing list archive at Nabble.com.
>> >> ___
>> >> Mono-list maillist  -  Mono-list@lists.ximian.com
>> >> http://lists.ximian.com/mailman/listinfo/mono-list
>> >>
>> > ___
>> > Mono-list maillist  -  Mono-list@lists.ximian.com
>> > http://lists.ximian.com/mailman/listinfo/mono-list
>> >
>> >
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296702.html
>> Sent from the Mono - General mailing list archive at Nabble.com.
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[David S]

I think there is another problem that is hidden behind all the complexity of
your program. I can tell you this, it isn't string comparer.

using System;
using System.Collections.Generic;
using System.Diagnostics;

namespace StringCompare
{


public class MainClass
{

public static void Main()
{
List> lists = new List>();
Random r = new Random();
for ( int i=0; i < 4; i++ ) {
lists.Add( new List() );
for ( int j=0; j < 4; j++ )
lists[i].Add( r.Next().ToString() );
}
Stopwatch watch = new Stopwatch();
watch.Start();
foreach ( List list in lists )
list.Sort();
watch.Stop();
Console.WriteLine( watch.Elapsed );
}
}
}

OUTPUT = 00:00:03.1364747

That being said I think its how you set up your threading. It could
very easily be how Mono handles Threads (sleeping and such). Honestly, I
have no idea, but I am intrigued.

On Wed, Jul 21, 2010 at 3:31 AM, Stifu  wrote:

>
> No release date, but Miguel recently said [1] "6-8 weeks from now."
> No idea how it compares with the .NET GC.
>
> [1] http://tirania.org/blog/archive/2010/Jul-14.html
>
>
> Mike Christensen-2 wrote:
> >
> > Is there a release date for 2.8?
> >
> > Also, how does the 2.8 GC (I realize it's only a beta) compare with the
> > .NET GC?
> >
> > Mike
> >
> > On Tue, Jul 20, 2010 at 11:19 PM, Stifu  wrote:
> >>
> >> There has been performance improvements since Mono 2.0. You may get
> >> better
> >> results with Mono 2.6. Or if you're not in a hurry, wait for Mono 2.8
> >> which
> >> should come out soon (that way you could also check out performances
> with
> >> the new GC).
> >> --
> >> View this message in context:
> >>
> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296643.html
> >> Sent from the Mono - General mailing list archive at Nabble.com.
> >> ___
> >> Mono-list maillist  -  Mono-list@lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-list
> >>
> > ___
> > Mono-list maillist  -  Mono-list@lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-list
> >
> >
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296702.html
> Sent from the Mono - General mailing list archive at Nabble.com.
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] String comparisons slow

[Stifu]

No release date, but Miguel recently said [1] "6-8 weeks from now."
No idea how it compares with the .NET GC.

[1] http://tirania.org/blog/archive/2010/Jul-14.html


Mike Christensen-2 wrote:
> 
> Is there a release date for 2.8?
> 
> Also, how does the 2.8 GC (I realize it's only a beta) compare with the
> .NET GC?
> 
> Mike
> 
> On Tue, Jul 20, 2010 at 11:19 PM, Stifu  wrote:
>>
>> There has been performance improvements since Mono 2.0. You may get
>> better
>> results with Mono 2.6. Or if you're not in a hurry, wait for Mono 2.8
>> which
>> should come out soon (that way you could also check out performances with
>> the new GC).
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296643.html
>> Sent from the Mono - General mailing list archive at Nabble.com.
>> ___
>> Mono-list maillist  -  mono-l...@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
> ___
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 
> 

-- 
View this message in context: 
http://mono.1490590.n4.nabble.com/String-comparisons-slow-tp2296525p2296702.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list