I've seen this before, although by now I've seen so many errors crop
up that I can't recall them all.
>> === RUN TestErrors-2
>> template.test 289408: suicide: sys: floating point in note handler
>> pc=0x0001e9c7
>> exit status: 'template.test 289408: sys: floating point in note
>> handler pc=0x0
> I have a 386 which is capable of SSE2, and I'm up to date with sources.
Thank you. Could you please try testing html/template alone (I think
you'll get better advice from Skip on how to do it - I would "cd
src/pkg/html/template; go test", i suppose that will do)? Maybe a
couple of times for lu
> I'm seeing something that looks to me like a resource exhaustion of some
> sort. When running the standard test (i.e. go test std), some tests are
> broken (see below); but test of each "broken" package/cmd/etc, passes
> correctly.
I would agree with you, that is the impression I get as well, bu
> === RUN TestErrors-2
> template.test 289408: suicide: sys: floating point in note handler
> pc=0x0001e9c7
> exit status: 'template.test 289408: sys: floating point in note
> handler pc=0x0001e9c7'
> FAIL html/template 0.213s
acid: stk()
runtime.memmove(to=0x106dd000,fr=0x30887660,n=0x2c)+0x107
On Fri, May 24, 2013 at 8:00 PM, Skip Tavakkolian
wrote:
> I sent a message on a thread earlier about broken procs when running 'go test
> std' -- test of template/html is one of those that broken -- that seems to
> indicate resource limit problems because running each test individually
> passe
following up on the fpregs... it is possible to have a little
acid library like /sys/lib/acid/sse that just remaps the fpregs
mapping and redefines the E0-7 and F0-7 symbols fpr() functions.
so when debugging fp on a new kernel, one could just attach with
acid -lsse and everything would work.
--
I sent a message on a thread earlier about broken procs when running 'go test
std' -- test of template/html is one of those that broken -- that seems to
indicate resource limit problems because running each test individually passes
without a problem. Does the test fail if you 'go test' in the
I consistently fail at html/template. At one point I was hanging
indefinitely on some other tests (net/http I think) due to goroutines
never giving up control, setting GOMAXPROCS=2 fixed it. I'm not sure
if that's still an issue though.
I have a 386 which is capable of SSE2, and I'm up to date wit
This is just an FYI.
I'm seeing something that looks to me like a resource exhaustion of some
sort. When running the standard test (i.e. go test std), some tests are
broken (see below); but test of each "broken" package/cmd/etc, passes
correctly.
I thought it might be related to semaphores, but t
the sse change broke floating point exception handling.
from /sys/src/9/pc/main.c:^matherror()
/*
* save floating point state to check out error
*/
fpenv(&up->fpsave);
mathnote();
this is wrong, because fpenv() will store the enviroment
in x87 format, bu
> which tests does it break? ?c compile -0. as 0 (which is incorrect),
> and print(2)'s %g and %f print -0. as 0. could this or other bits of
> non-ieee conformance in the system be the real issue?
They could be significant, but only where floating point is involved,
the failures I noted do not
>
> Compiling the go tool chain with sse2 under VMware yields broken
> tools, and building with GO386=387, consistently breaks the tests. On
> bare metal, all tests except net/http pass most of the time. When a
> test fails I get the following errors:
which tests does it break? ?c compile -0. as
On Fri, May 24, 2013 at 03:45:07PM +0400, Ruslan Khusnullin wrote:
> Hello, 9 fans!
>
> If I wanted to play with native Plan 9 installation or demonstrate it
> to someone, does anyone have a Plan 9 installed on a VPS or a Pi with
> free guest access? It would be nice to be able to drawterm to it.
You can also talk to khm about getting you a machine on 9cloud. It's 9 bucks a
month and the service is super good.
I'm up for giving you an account on my machine if you pay for a month of
hosting, but I agree with everyone that said you should set it up on your own.
--
Veety
On Fri, May 24, 2013 at 5:22 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> Why bother? Because you might learn something from the experience
> of doing it yourself. I think you can get still get free usage of
> an ec2 instance for a year, so it's not a costly experiment.
I have installed Plan
> remember there were discussions about creating Plan 9 instance on
> Amazon EC2 platform, but why bother if someone would be so kind to
> share own virtual server.
Why bother? Because you might learn something from the experience
of doing it yourself. I think you can get still get free usage of
Hello, 9 fans!
If I wanted to play with native Plan 9 installation or demonstrate it
to someone, does anyone have a Plan 9 installed on a VPS or a Pi with
free guest access? It would be nice to be able to drawterm to it. I
remember there were discussions about creating Plan 9 instance on
Amazon EC
17 matches
Mail list logo
