Hello,
In mono svn trunk head, gmake check failed with compile error.
$ gmake check
(snip)
gmake[7]: Leaving directory
`/export/home/ksmakoto/Mono/mcs/class/System.ComponentModel.DataAnnotations'
gmake[7]: Entering directory
`/export/home/ksmakoto/Mono/mcs/class/System.Web.DynamicData'
gmake te
I resolved this issue by making fresh install of ubuntu (it was something
wrong with mono installation)
--
View this message in context:
http://mono.1490590.n4.nabble.com/Compiling-mono-from-trunk-on-Ubuntu-tp2220004p2220402.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
_
> To me this seems like it is time for a change in policy: our
> string
> collation should reflect what the rules are in Unicode as it
> will be easier for us to maintain.
> In that case, we might as well use ICU.
I do not want to go back to the business of maint
> That can certainly be done. I suppose you envision a compile-time
> switch? Is there already such an option/flag/preprocessor symbol I
> should use as a model?
For C code, just use the symbol DISABLE_ASTRAL, then we can add that to
configure.in
> Sure. I guess this means some more compile-t
Hi
> To me this seems like it is time for a change in policy: our string
> collation should reflect what the rules are in Unicode as it will be
> easier for us to maintain.
>
> Miguel.
>
>
>
In that case, we might as well use ICU.
Zoltan
> ___
Hello,
> MS have (or used to on 2.0) a lot of broken stuff when it comes to
> unicode/locales.
> So sometimes fixing for MS compatibility means breaking correctness.
It might be time to revisit this policy.
Currently the situation is that we kept compatibility with Microsoft as
Microsoft's work
Hi Miguel,
Miguel de Icaza writes:
> Hello,
>
>> This approach grows the category data table from 64 to ~70kB, and
>> requires an additional 8kB index for the astral planes. The resulting
>> runtime produces the same results as Microsoft's v2.0.50727 and
>> v3.5.21022 for the whole Unicode rang
Hello,
> This approach grows the category data table from 64 to ~70kB, and
> requires an additional 8kB index for the astral planes. The resulting
> runtime produces the same results as Microsoft's v2.0.50727 and
> v3.5.21022 for the whole Unicode range, but has no support for v4.
>
> Would that
Hello,
Great patch!
> The code doesn't check whether it's running on (or compiled for)
> Windows, just whether the appropriate registry key exists. I don't
> know if that's the preferred way of doing things.
Would you mind changing the code to not probe the registry unless it is
not running
> Now that you mention System.Reflection,
I'm not sure how you get to that statement. But I NEVER mentioned
System.Reflection. I've been talking about System.Reflection.Emit which is
an (entirely) different thing.
> https://blogs.msdn.com/jmstall/archive/2008/03/15/things-in-metadata-
> that-are-
"Andreas Nahr" wrote in message
news:002b01caf54b$a49d3940$edd7ab...@com...
> Which use case do you see for a "temporary solution" using .il files?
The compiler backend in question currently generates .il but no .dll or .exe
files. That's why I was thinking about calling Mono ilasm as a librar
11 matches
Mail list logo
