Yes, thank you Erik. With this html/template passes.
On Sat, May 25, 2013 at 6:53 AM, erik quanstrom wrote:
> On Sat May 25 01:50:51 EDT 2013, lu...@proxima.alt.za wrote:
>> I've seen this before, although by now I've seen so many errors crop
>> up that I can't recall them all.
>>
>> >> === RUN T
On Sat May 25 01:50:51 EDT 2013, lu...@proxima.alt.za wrote:
> 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 s
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
> === 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
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
> 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
At one time the SSE support in the labs kernel was incomplete,
it contained just enough that people actually needed so its possible
that the full state of sse is not being saved/restored.
I haven't experimented with recent kernels, things may wll have changed,
but it might be somthing to check.
-
I am trying to get the Plan 9/386 port of go stable enough to run a
builder on one of my machines, but I've run into a few snags and could
use some guidance.
Here's the relevant setup:
VMware Workstation instance running as CPU/FS/Auth server
Thinkpad T21 running as a CPU server
The Plan 9 instal
12 matches
Mail list logo
