Zoltan, I noticed you mentioned that some IL parser fixes for
big endian for float constants got made recently.
I'm still getting iltest.exe failures for testcase test_0_fcont_to_i
It's the only basic test that fails on the current 2.6 branch on sparc
for me, maybe it's related to that other IL
Hi,
I think this is due to a rounding problem on sparc
in the OP_FCONV_TO_I implementation in mini-sparc.c. I can't debug this
right now because our
sparc buildbot seems to be down.
Zoltan
On Tue, Mar 16, 2010 at 8:07 AM, David Miller wrote:
>
> Zoltan, I noticed you
From: Zoltan Varga
Date: Tue, 16 Mar 2010 08:24:14 +0100
> I think this is due to a rounding problem on sparc
> in the OP_FCONV_TO_I implementation in mini-sparc.c.
For integer conversions, the Sparc FPU always rounds towards zero, no
matter what is set in the floating point control register.
Hi,
I suspect, like powerpc, that this test should simply be disabled
> on sparc.
>
Done in SVN HEAD and the mono 2.6 branch.
Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinf
I won't comment on the algorithm itself (keep in mind that the existing one
already was replaced once with a "better" one which failed miserably in real
world apps, so had to be reverted).
Also a newsgroup as source doesn't sound reliable at all.
But your patch adds errors for exceptions (which we
Hi,
I've followed what is written on the website and in the README in mono
to build mono from svn (head of trunk), and the build process fails on
my Linux/x86 box (see trace below).
Note that the version of mono which is installed is 2.6.1 (from
tarball).
I don't know what I've missed, and I d
Also note that this patch seems to break serialization compatibility
that might be a problem for some applications.
Kornél
Andreas Nahr wrote:
> I won't comment on the algorithm itself (keep in mind that the existing one
> already was replaced once with a "better" one which failed miserably in r
I moved to Chicago in mid January. I'm wondering if there are any like
minded individuals (people following this list) interested in getting
together in downtown Chicago to talk tech? If so email me and we can meet
up.
--dave
__
I don't do work in the city anymore, but it would be interesting to see if you
get any bites. I only started following this list a few days ago. Ordinarily
I work on and write about real computers.
On Tuesday 16 March 2010 09:16:34 am David Smith wrote:
> I moved to Chicago in mid January. I'
On Tue, 2010-03-16 at 10:31 +0100, Thierry Lafage wrote:
> I've followed what is written on the website and in the README in mono
> to build mono from svn (head of trunk), and the build process fails on
> my Linux/x86 box (see trace below).
...
> $ make
> [...]
> make[7]: En
Thanks, Rodrigo. I'll try this out!
On Sat, Mar 13, 2010 at 6:14 AM, Rodrigo B. de Oliveira <
rodrigobam...@gmail.com> wrote:
> Hey Amir!
>
> Yes, you can use Mono.Cecil:
>
>import System
>import Mono.Cecil
>import Mono.Cecil.Cil
>
>pathToAssembly = "/tmp/test.exe"
>asm = Asse
Hello,
I get SIGSERV (from mono_arch_get_llvm_call_info at mini-x86.c:1224)
when trying to compile attached example with Mono + LLVM backend.
Both Mono and LLVM updated today:
Mono revision: 153681
LLVM revision: 98629
Code, exe and dump are attached.
This errors happens when when non-static metho
Andreas Nahr wrote:
> I won't comment on the algorithm itself (keep in mind that the existing one
> already was replaced once with a "better" one which failed miserably in real
> world apps, so had to be reverted).
I tested a sequence of 68 million 32-bit values for randomness using the
Diehard t
Kornél Pál wrote:
> Also note that this patch seems to break serialization compatibility
> that might be a problem for some applications.
That is indeed a problem. However, it should be sufficient to load the state
and xor it with the default state if the
serialized object is the old version. I
In Text
>Andreas Nahr wrote:
>> I won't comment on the algorithm itself (keep in mind that the existing
one
>> already was replaced once with a "better" one which failed miserably in
real
>> world apps, so had to be reverted).
>I tested a sequence of 68 million 32-bit values for randomness using t
Hello,
> As already said I didn't test and can't comment but keep in mind that the
> Random class is used (real-world) under VERY specific situations and none of
> them are near random.
I am not sure about this.
I looked through the svn log for the commits to the Random class, and
I can not find
Hi,
This is fixed now in SVN.
Zoltan
On Tue, Mar 16, 2010 at 4:52 PM, Sergei Dyshel wrote:
> Hello,
> I get SIGSERV (from mono_arch_get_llvm_call_info at mini-x86.c:1224)
> when trying to compile attached example with Mono + LLVM backend.
> Both Mono and LLVM updated today:
> Mon
my previous issue in Solaris-Sparc was resolved - but this problem occurs in
Solaris 10 x86 while building mono-basic:
make[3]: Entering directory `/Desktop/dev/mono-2-6/mono-basic/vbnc/vbnc'
MONO_PATH="../../class/lib/bootstrap:$MONO_PATH" mono --debug
../../class/lib/bootstrap/vbnc.exe @vbn
18 matches
Mail list logo
