Apparently, racket's threads have problems on linux/ppc64. I ran
manually each test and only failed "thread.rktl".
Here is the output: http://git.io/vqm18
quiet.rktl contains this code:
;; -- set up a timeout
(set! timeout-thread
(thread
(lambda ()
(sleep 1200)
(fprintf errp "\n\n~aTIMEOUT -- ABORTING!\n" Section-prefix)
(exit 3)
;; in case the above didn't work for some reason
(sleep 60)
(custodian-shutdown-all cust)))))))
quiet.rktl prints the error very quickly, less than a second. (sleep
1200) is not working there.
On 07/03/2015 08:49 PM, Matthew Flatt wrote:
It's possible that the recent change will fix this problem, but I'm not
optimistic. Assuming that the test still fails, is it possible to get
output from `racket -f basic.rktl` to we can see more specifically the
point of failure?
At Fri, 3 Jul 2015 01:11:59 +0200, Juan Francisco Cantero Hurtado wrote:
Racket builds fine on linux/ppc64 with your change.
The tests fail:
$ racket -f quiet.rktl
Section(basic)
TIMEOUT -- ABORTING!
On 07/03/2015 12:31 AM, Matthew Flatt wrote:
I was able to get an AArch64 installation running with Qemu, and I
think I've found the main problem with these failing builds.
The end of "gc2.h" has a preprocessor test for `__x86_64__` or `WIN64`,
but it should have been a more general test for
`SIXTY_FOUR_BIT_INTEGERS`.
With that repair, the AArch64 build still fails for me due to a GC
problem. If I disable generational GC, then the build seems ok. I think
I've had trouble in the past, where the signal handlers that implement
the write barrier didn't work correctly inside Qemu. The problem might
not be Qemu-specific, though, and I'm interested to hear whether the
"gc2.h" change to use `SIXTY_FOUR_BIT_INTEGERS` fixes the problem on
real machines.
Here's the commit to fix "gc2.h":
https://github.com/plt/racket/commit/0cda0c98b085dc289bbb40cb37325042b35eea07
At Mon, 29 Jun 2015 21:58:12 -0400, James McCoy wrote:
On Tue, Jun 30, 2015 at 02:44:46AM +0200, Juan Francisco Cantero Hurtado
wrote:
Similar bug:
http://bugs.racket-lang.org/query/?cmd=view%20audit-trail&database=default&pr=1
5079
David, Debian has some machine with those architectures available to give
shell accounts to upstream developers?. I asked for a shell account for
Matthew in the OpenBSD mailing list long time ago but nobody replied.
Yes, David or I could sponsor a request to get Matthew guest access on
relevant porterboxes[0] if he'd like to debug the build failures[1].
Matthew would just need to follow the “non-DMs” instructions[2] to
provide one of us with the relevant information we can use to make the
request.
[0]: https://db.debian.org/machines.cgi Systems where purpose=porterbox
and hostname matches debian.org.
[1]: https://buildd.debian.org/status/package.php?p=racket
[2]: https://dsa.debian.org/doc/guest-account/ DMUP refers to [3]
[3]: https://www.debian.org/devel/dmup
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/5595C53F.50809%40juanfra.info.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/55982C0D.3030604%40juanfra.info.
For more options, visit https://groups.google.com/d/optout.
