Results matching “smartmatch”

This week in PSC (191) | 2025-05-15

We were all present.

  • The status of smartmatch came up. It is in a weird position where it used to be part of the language, then was retroactively declared an experiment, then deprecated and slated for removal, and now it’s no longer being removed – in fact we’ve added a feature for it, and not an experimental one either. The bottom line is that it’s not deprecated any more and not experimental either, but is now just a negative feature like indirect and multidimensional: it’s a mistake we made that will remain part of older language versions but will not be included in future feature bundles.
  • Release blocker triage continues as ever. Quite a few new issues came in recently, of which we identified two issues and one pull request as blockers. One of the issues and the PR pertain to the documentation of the status of smartmatch; we expect that there may be more inconsistencies in the documentation which will need to be ironed out.

[P5P posting of this summary]

This week in PSC (190) | 2025-05-09

A meeting with full attendance.

  • We caught up with new issues and pull requests without finding any new release blockers.
  • We went over the state of the perldeprecation and perlexperiment POD pages. We found that perlexperiment does not yet reflect the change in direction regarding smartmatch. Other than that we saw nothing to do.
  • We went over our options regarding readline again at length. We concluded that we are not yet sure about the big across-the-board change to I/O functions, and are definitely too far into the release cycle to undertake a fishing expedition. But we don’t want to leave this problem entirely unaddressed during this cycle, and the change proposed by Tony Cook is a strict improvement, even if only a minimal one. So we decided to ship it, possibly with a slightly different implementation that we may suggest.

[P5P posting of this summary]

This week in PSC (167) | 2024-11-07

The three of us attended another long meeting:

  • We continued refining our plan for TLS in core. We will collect feedback on its feasibility from the maintainers of the relevant modules.
  • We reviewed the status of putting the apostrophe package separator behind a feature and approved the PR.
  • We confirmed that we want to deprecate smartmatch with a feature. This effectively means that we don’t plan for a “better smartmatch” at this time (but it can still be pursued in future, by way of the air gap strategy, if there is appetite). We will file an issue for this.
  • We agreed that “negative” features (rather than outright removal) is our preferred way to deprecate historical Perl quirks as the language continues to evolve.
  • We discussed our ongoing inadequacy at dealing with maintenance releases. We wrote down next steps to get back on track, and also started looking into capturing a checklist to document the process.

[P5P posting of this summary]

This week in PSC (163) | 2024-10-10

We had a guest this week: Olaf Alders.

  • We exchanged Perl (re)branding ideas with Olaf. We will be keeping in touch on that front.
  • We discussed the feedback on feature-guarding and unbundling apostrophe. We came up with a strategy to propose that we think should work, which will be posted on the relevant thread.
  • We discussed the fact that keeping the current smartmatch operator (as a feature) means we can’t have a meaningful air gap to prevent subtle bugs when moving to a future “good” smartmatch. This probably implies that we would be giving up on any future smart match operator, but there are usually better replacements.

[P5P posting of this summary]

This week in PSC (162) | 2024-10-03

Everyone was present this week.

  • We devised a strategy to deal with smartmatch, starting with reverting its removal. A separate email with details will follow.
  • We spent too much time talking about putting the apostrophe package separator behind a feature. That too will be outlined in a separate email. A github issue will follow.
  • We want to revert the open undef patch, for a variety of reasons, such as breaking autodie. We decided the steps to handle this.

[P5P posting of this summary]

This week in PSC (161) | 2024-09-27

We were all present this week:

  • We rehashed the Perl version number discussion from last meeting now that we are all present. We will put together a document with our thoughts on this.
  • We will create a GitHub issue to make apostrophe removal feature-guarded.
  • Smartmatch (not so surprisingly) turns out to be too big to fail. Given its unique history, we are considering options for how to proceed with it in a more gradual way without giving up on the deprecation.
  • Regarding open undef (GH #22490), we agreed that Perl should support undef as a value and not just as a literal for the filename (and warn for the useless modes)

[P5P posting of this summary]

This week in PSC (160) | 2024-09-12

Just Aristotle and Graham.

The notes from this meeting were lost, but have been reconstructed from memory.

  • We had a discussion about what future versioning (Perl 7) should look like.
  • Discussed if we will need to make changes to apostrophe as package separator, and smartmatch removal, given the fallout they have had.

[P5P posting of this summary]

This week in PSC (159) | 2024-09-05

All present, and this time the meeting actually ended on time.

  • We discussed the situation with the apostrophe package separator removal. We continue to keep an eye on things but it now feels close to inevitable that we will use a feature to disable it conditionally.
  • We briefly touched on the removal of smartmatch, where both the extent of the situation and our thoughts so far are much less clear.
  • Connected to all that, we discussed some general thoughts on how not to keep finding ourselves in the same situation with changes like this, but found we probably already have all the mechanisms we need.
  • We decided that the provisions of the PPC process are the right way for pre-PPC “Signature named parameters” to play out so it has now become PPC 0024 with status “Exploratory”.
  • We took another brief look at the closure memory leak which is now #22547 and resolved to prepare to put down a consensus next time we meet.

[P5P posting of this summary]

Sailing the Seven YAPCs


[This is my seventh YAPC / TPC.  If you like, you can read about my other YAPC experiences: YAPC 2011, YAPC 2013, YAPC 2014, YAPC 2015, YAPC 2016, YAPC 2018.]


Well, after taking a very long break inspired (to understate it a bit) by the pandemic, I’m back to attending in-person Perl events with my seventh YAPC.  Or, The Perl Conference, I suppose, but it still feels like YAPC to me.  As per usual, here are some reflections.

My 2023 in Perl

2023 was a rather productive year for me on CPAN. Aided by taking some time off I managed to release a whopping 18 new modules.

Passwords

Half of my new modules were related to my password framework Crypt::Passphrase. To be honest most of them are either small (± 100 LOC) glue two or three other pieces of code together. And then there was Crypt::HSM, a PKCS11 interface (to use cryptographic hardware without exposing cryptographic keys) that was probably more work (2600 LOC of XS) than the others combined.

Most of this was with the aim to add peppering support to Crypt::Passphrase, a subject extensive enough that I should probably dedicate a separate blogpost to it.

2 3 4 5 6 7  

About coke

user-pic Perl 6 hacker