Upcoming Release 4.1.0
Alvis Yardley
I am the release manager for the 4.1.0 release of Parrot, which will, if
everything goes smoothly, take place on Feb 21, 2012. Because this is the
firt time I've ever attempted a release, I thought I would _try_ to follow the
guidelines set out in 'docs/project/release_manager_guide.pod'.
The guide states, "[a] couple of weeks in advance of the release, ask people
to run "make fulltest" and report (and hopefully fix!) any problems they
discover." So, I'm asking folks to "run 'make fulltest'" and "report (and
hopefully fix!) any problems ... [you] discover."
The guide also states I should ask folks "to review any issues targeted for
the upcoming release at <https://github.com/parrot/parrot/issues>." So, are
there any of which anyone is aware and of which I should be made aware?
Thank you.
--
Alvis
P.S. I will also contact the Rakudo "language project leaders" to see if there
are "any potential release blockers."
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
James E Keenan
> Hello all:
>
> I am the release manager for the 4.1.0 release of Parrot, which will, if
> everything goes smoothly, take place on Feb 21, 2012. Because this is the
> firt time I've ever attempted a release,
Thanks for stepping up to the plate.
I thought I would _try_ to follow the
> guidelines set out in 'docs/project/release_manager_guide.pod'.
>
> The guide states, "[a] couple of weeks in advance of the release, ask people
> to run "make fulltest" and report (and hopefully fix!) any problems they
> discover." So, I'm asking folks to "run 'make fulltest'" and "report (and
> hopefully fix!) any problems ... [you] discover."
>
Note that you can now post the result of a fulltest run to Smolder via:
make smolder_fulltest
Thank you very much.
Jim Keenan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
James E Keenan
> Hello all:
> The guide states, "[a] couple of weeks in advance of the release, ask people
> to run "make fulltest" and report (and hopefully fix!) any problems they
> discover." So, I'm asking folks to "run 'make fulltest'" and "report (and
> hopefully fix!) any problems ... [you] discover."
>
So I have indeed been running 'make fulltest', and in the process have
encountered errors in 6 or 7 coding standards tests. I've fixed some of
them, but these still remain:
Test Summary Report
-------------------
t/codingstd/c_arg_assert.t (Wstat: 256 Tests: 2 Failed: 1)
Failed test: 1
Non-zero exit status: 1
t/codingstd/c_function_docs.t (Wstat: 256 Tests: 236 Failed: 1)
Failed test: 86
Non-zero exit status: 1
t/codingstd/c_parens.t (Wstat: 256 Tests: 3 Failed: 1)
Failed test: 3
Non-zero exit status: 1
t/codingstd/opcode_doc.t (Wstat: 256 Tests: 1 Failed: 1)
Failed test: 1
Non-zero exit status: 1
Files=33, Tests=453, 62 wallclock secs ( 0.16 usr 0.05 sys + 59.83 cusr
1.12 csys = 61.16 CPU)
Result: FAIL
make: *** [nocritic_codetest] Error 1
These failures represent a regression from our situation as of the 4.0
release three weeks ago. So people who have added the C functions and
the (experimental) opcodes that are undocumented should create some
basic documentation for them so that the c_functions_docs.t and
opcode_doc.t tests once again PASS.
I'll try to get the other tests to PASS, but others with more C-fu than
I are welcome to give them a shot as well.
James E Keenan
> Test Summary Report
> -------------------
> t/codingstd/c_arg_assert.t (Wstat: 256 Tests: 2 Failed: 1)
> Failed test: 1
> Non-zero exit status: 1
I was able to resolve all but this one. Can whoever nails it explain
the sense in which this instance of "argument guards generated by
headerizer" was not actually used?
Thank you very much.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Bruce Gray
On Feb 9, 2012, at 9:18 PM, James E Keenan wrote:
> On 2/9/12 9:20 PM, James E Keenan wrote:
>
>> t/codingstd/c_arg_assert.t (Wstat: 256 Tests: 2 Failed: 1)
>
> I was able to resolve all but this one.
> Can whoever nails it explain the sense in which this instance of
> "argument guards generated by headerizer" was not actually used?
--snip--
Fixed in:
https://github.com/parrot/parrot/commit/92745461c27be960c5bb0da450a8f8c5833c7431
The argument guard macro was defined in line 465 of include/parrot/
hash.h (generated by headerizer):
#define ASSERT_ARGS_Parrot_hash_flatten_hash_into
__attribute__unused__ int _ASSERT_ARGS_CHECK = (\
PARROT_ASSERT_ARG(interp) \
, PARROT_ASSERT_ARG(dest) \
, PARROT_ASSERT_ARG(src))
That argument guard macro should have then been used as
the first statement in the body of the definition of its
function (Parrot_hash_flatten_hash_into in src/hash.c), but it was
missing.
{
ASSERT_ARGS(Parrot_hash_flatten_hash_into) // This line was missing
const Hash * const src_hash = (Hash *)VTABLE_get_pointer(interp,
src);
--
Hope this helps,
Bruce Gray (Util of PerlMonks)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Jonathan "Duke" Leto
One at least some environments with LLVM/clang, Parrot fails
(horribly) to compile:
http://travis-ci.org/#!/parrot/parrot/jobs/656086
Can anybody give some love to this? I can't reproduce it on my
machine, but I haven't tried the exact OS and LLVM version that Travis
uses.
Travis is controlled by this file:
https://github.com/parrot/parrot/blob/master/.travis.yml
I know I haven't explained it much. Ask questions and I shall answer :)
Duke
--
Jonathan "Duke" Leto <jona...@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev