This week on the Perl 6 mailing lists
"For the first time in the two months I've been working on Parrot, 'make test' completely succeeded -- and with some TODO tests passing, to boot!"
-- James Keenan, sharing the good news in 'All tests passing!'
When we last looked at this thread, a subthread discussing Euclidean versus conventional definitions of modulus was underway. The original thread started when Luke Palmer asked for a clear definition of when math should use floating points and when it should be integer-based.
The subthread was further expanded, with TSa suggesting that all rounding
functions such as floor, round and trunc take an optional second argument
which defines the jump size. TSa also proposed a number of division
function pairs, such as
fmod for flooring division and modulus,
tmod for truncating division and modulus. Smylers felt
that this would introduce far too many functions in to the Perl core,
given that few people would use them. Smylers felt that it was more
appropriate to have them as modules. Jonathan Lang added that it was
unlikely anyone would need multiple definitions of division and modulus
at any given time, so modules made sense. The only question he saw was
which definition was default, the mathematically elegant one or the
industry standard one.
Meanwhile, the main thread was revived when TSa replied to Luke Palmer's
question of whether 1 is different from 1.0. TSa wanted 1 to be an Int
and 1.0 to be a Num. There was some discussion with Jonathan Lang over
the relationship between Int and Num, specifically which one
Earlier, Jerry Gay created ticket [perl #41237] to address an item in DEPRECATED.pod about PMC Class name IDs. He felt that either it should use one syntax or the other, but not both.
Allison Randal preferred eliminating the dot in classname IDs. Matt Diephouse, on the other hand, liked the dot. Klaas-Jan Stol added that the dot indicates that it is PIR not pure PASM.
Allison thought that if Matt used it to disambiguate between types and local variables, it was a matter of sigils. She asked why put sigils on types instead of putting them in variables, and if a dot was the ideal sigil for types.
Patrick R. Michaud also spoke out in favor of the dot.
James Keenan wondered if he should look at refactoring
Following his successful refactor of
pmc2c.pl, he has had requests to
look at other build tools. His primary suggestion was to eliminate
global variables, but first he hoped to hear suggestions from people who
had worked on the file, in case there was a reason for the global variables.
Jerry Gay felt that the global variables were a result of lax coding practices early in the project. He agreed with refactoring.
Allison Randal added specifications for the I/O object iterator API, which closed ticket [perl #33962].
In ticket [perl #41263], Allison Randal split out part of the problem described in ticket [perl #40443]. The issue is that classes are only constructed at runtime, which has negative impacts. She suggested possible workarounds.
Patrick R. Michaud created ticket [perl #41265]. He would like
to have a common rule in PGE::Util which can be imported in to individual
grammars. The rule would describe how to use a
pod_comment rule for
In ticket [perl #41266], Allison Randal made a note to consider object instantiation as a method call on a class object instead of an opcode on a type ID. Kevin Tew voiced his support for the idea.
In ticket [perl #41267], Jerry Gay proposed that the
be renamed as
draft because the directory is now being used for drafts
rather than notes.
Lee Duhem reported an error seen when doing a
make world. A patch to
fix this was attached to ticket [perl #41268].
Lee Duhem attached a patch to fix some failing tests to ticket [perl #41269]. Patrick R. Michaud asked Lee to verify the bug in the current revision; he thought it had been fixed in r16520.
An excited James Keenan reported that he had just seen his first instance
of all tests passing, with the added bonus of some
TODO tests also passing.
This summary was prepared using Mail::Summary::Tools, available on CPAN.
If you appreciate Perl, consider contributing to the Perl Foundation to help support the development of Perl.
Thank you to everyone who has pointed out mistakes and offered suggestions for improving this series. Comments on this summary can be sent to Ann Barcomb, email@example.com.
This summary can be found in the following places: