#1829: Recent changes impeded building and testing on smaller boxes
---------------------+------------------------------------------------------
Reporter: jkeenan | Owner:
Type: bug | Status: reopened
Priority: normal | Milestone:
Component: build | Version: 2.8.0
Severity: medium | Resolution:
Keywords: | Lang:
Patch: | Platform:
---------------------+------------------------------------------------------
Comment(by jkeenan):
To recapitulate where we stand on this ticket ...
On Saturday, October 16, in r49557, chromatic committed to trunk the one-
line hack that had been enabling me to build -- albeit slowly -- the
Parrot executable on a small-physical-memory-by-today's-standards (256MM)
machine since the ''gc_massacre'' merge in r49269. This passed smoke
tests on all platforms reported to Smolder between that time and the
moment on Tuesday, October 19, when Gerd tagged trunk and released Parrot
2.9.0.
Almost as soon as that release was made, Rakudo Perl 6 developers -- who
were planning to do a monthly release targeted on top of Parrot 2.9.0
three days after the latter's release -- began reporting that Rakudo
builds were now "unbearably slow." These reports started to come in just
before our weekly ''#parrotsketch'' meeting and the issues dominated
discussion at that meeting. Ultimately, the consensus was to revert
r49269 (performed by Util++ in r49583) and to do a bug fix release, Parrot
2.9.1 (performed by cotto+ in r49584).
As expected, this meant that on my small-resource machine Parrot once
again took an inordinately long time to run 'make' and 'make test' --
though both ultimately concluded successfully. The times I recorded were:
{{{
'make': 28:54
'make smoke': 2:08::51
}}}
If the definition of "unbearably slow" is "so slow as to make developing
Parrot (or other application) on this box not feasible", then I think it's
safe to say that this is "unbearably slow" -- but not broken.
Since Tuesday, bacek++ and fperrad++ have been making commits to trunk in
the hope of probing the build machine for the amount of memory and using
an algorithm to determine an appropriate GC threshold. We have successful
smolder reports mostly for Linux.
Alas, these more recent commits prevent a successful build on Darwin.
Here's the tail end of my build log:
{{{
config/gen/platform/generic/sysmem.c: In function 'Parrot_sysmem_amount':
config/gen/platform/generic/sysmem.c:44: error: '_SC_AVPHYS_PAGES'
undeclared (first use in this function)
config/gen/platform/generic/sysmem.c:44: error: (Each undeclared
identifier is reported only once
config/gen/platform/generic/sysmem.c:44: error: for each function it
appears in.)
make: *** [src/platform.o] Error 1
}}}
bacek has suggested that this GNU file
[http://www.opensource.apple.com/source/gcc/gcc-5646.1/libiberty/physmem.c
physmem.c] may have some code we can use for Darwin. I have not yet had
time to try this out.
So that's where things stand, at least for me, just before UTC 0000
Thursday Oct 21.
Thank you very much.
kid51
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1829#comment:3>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
