The Perl and Raku Conference in Houston

Elevator Pitch
Can Perl possibly be faster? YES! How to improve the performance of your Perl scripts using mostly minor changes to your code. Performance often comes at a cost–more memory! So we’ll also look at techniques to shrink your Perl script/module footprint.

Description
This is a followup to my “Perl Optimization Tidbits” talk in 2018. Then we looked at many minor performance differences in expressions like ++$x vs. $x++, “abc” vs. ‘abc’, etc. We go into more depth with more comparisons, but also cover larger strategies–algorithmic, structural, and other optimization techniques to get the best performance. In addition we’ll look at various ways of profiling your code so you can see where your slow places are. Some of these techniques and strategies can be applied to improving performance of other languages as well.

Data types are hints to a computer language, telling the language’s interpreter or compiler how best to allocate resources and optimize performance.

We will introduce the type system provided by the Perl compiler, and the many benefits of utilizing Perl data types.
Let’s explore types together!

The Perl interpreter itself is written in C, and implements data types for its own internal use, including:

• IV, integer value
• NV, number value
• PV, pointer value AKA string
• AV, array value
• HV, hash value
• SV, scalar value
• RV, reference value

The Perl interpreter does not provide programmers with access to these pre-defined types, and instead it encourages us not to use data types at all.
Perl does allow programmers to create user-defined data types, but none of the (numerous & incompatible) data type systems actually utilizes the underlying C data types implemented in the Perl interpreter.
The Perl compiler finally provides developers with direct access to real C data types and their C++ equivalents.
Upgrade your Perl, start utilizing data types today!

There’s More Than One Way to Screw It Up!
This talk will cover common problems and solutions when dealing with Unicode. Attendees will learn how to handle Unicode safely and reliably, in both Perl and XS.


Perl excels at text processing, so why are Unicode bugs so common when using it? If you’ve ever chased encoding problems in Perl, attend this talk to learn effective techniques for diagnosing and avoiding Unicode bugs. You’ll also learn how to help users of your Perl and XS modules in the same way.

Let’s explore what it’s like to be inspired and migrate a feature from Perl to another language, and then to bring it back with improvements

I will demonstrate in this talk a trivial but useful behavior in Perl

perl -E 'my $foo = "a"; say $foo++ for 0..100;'

We’ll take this feature to another language (Rust), and then bring it back to Perl improved and optimized!

Many of us are tied to really old Perl distributions, for a variety of reasons. Just because you’re using Perl from 1998 doesn’t mean you have to develop software like it’s 1998! This talk aims to help developers apply modern, maintainable approaches, even when you use 5.005;.

We’ll briefly discuss a bit of why people might be using ancient Perls, but mostly focus on some practical code examples. For example:

• named captures were introduced in Perl 5.10, but you can get a lot of their advantages by putting a hash slice on the left side of a capturing regex
• lexical filehandles were introduced in Perl 5.8, but you can use the Symbol module (in the standard distro!) to make your own lexical filehandles and dirhandles.

We’ll also talk about future-proofing (future resisting maybe..) your code. Maybe someday you’ll be able to update to a contemporary Perl release. If that day comes, you’ll be glad you:

• added use-version pragmas: use 5.005;
• use strict; Always. use warnings; except before 5.8. Then use #!perl -w

This talk is meant to serve as a primer for the talk later in the conference that discusses using OpenMP, which is supported by default in modern gcc (C, Fortran, C++) via the GOMP project, in your Perl code.

This talk is meant to serve as a primer for the later in the conference that discusses using OpenMP in your Perl code. It covers: what OpenMP is, what it can do, and why Perl programmers might care to consider it for your next computationally intense application. It covers the basics of OpenMP in C code; including what it does, and how to use it - parallel constructs, compiling, and running the code.

Talk slides, images & code used: https://github.com/dkechag/ImagePHash-Talk

This talk will take you through a novel Perl implementation of perceptual hashes for “similar image” searches. I'll start with the basics, if you don't know what a Discrete Cosine Transform is, you'll find out with a visual demo - no math required (although math is always encouraged!). After DCTs and p-hashing basics, I will go through the implementation’s new features that make it efficient and easy to integrate with our large MySQL-based image database.


At SpareRoom, the world’s largest roommate finding service, we handle tens of millions of images, mostly of customer rooms/properties. When tasked with adding an internal ability for a “similar image” search, I first looked at existing solutions and found out that some did not work as expected, while others were either slow or required changes to our infrastructure (mainly Perl, with the data - including the image index - on a large MySQL database).
In the end, I went with a solution initially based on Image::Hash, but with p-hashes reimplemented to fix collision issues and add speed (over 10x faster than pHash.org’s equivalent DCT-based hash). Then, I added features such as support for mirroring, as well as “index/reduced” hashes, in order to effectively use MySQL indices (and thus easily fit in our existing setup).
After an intro to the theory behind the DCT and perceptual hashes in general, I will discuss the abilites of this implementation and the experiences from developing and using it. The module will be released to CPAN before my talk, although the XS part responsible for the fast DCT calculation has been available for a while as Math::DCT.

Meet The Perl Foundation Board members face to face and find out what has been achieved, with your help, over the last few years. Hear about plans for the future and how you could get involved. You can also participate in open discussions.

Language Servers provide language intelligence features such as autocomplete via standardized protocol that can be consumed by different editors. This allows developers to use their preferred code editor and still receive the same high quality code intelligence as any other editor. In this talk, I’ll go through the basics of the Language Server Protocol as well as the architecture of the Perl Navigator, a new language server for Perl.

The Perl Navigator supports syntax checking, code navigation, autocompletion, hover, Perl::Critic and Perl::Tidy. It works on Linux, MacOS, Windows, and can be used in Visual Studio Code, Vim, NeoVim, Emacs and Sublime Text, and supports back to Perl 5.8. I’ll discuss the architecture of the Perl Navigator, including symbol table parsing and how it leverages the B:: compiler backend. I’ll also discuss the roadmap for new integrations and contribution opportunities for those interested. A simplified Raku Navigator exists as well for those who need Raku support. 

TBA

Filters are the basic tools of command-line data munging. `grep` `head` `cut` `sort` `uniq` `wc` `diff`, pipes + redirects, intro + advanced tips. Why stop there? You can write your own. Perl, Raku, & Python have strong support for writing filters. Existing code often works better when refactored as a filter.

These techniques are my bread-and-butter for exploratory programming and data analysis, and include a few of my best tricks.

Due to the overwhelming interest in the 2021 lightning talk on the same subject, we will discuss the current options available for including OpenMP into your Perl programs for computationally intensive applications. No XS will be harmed during this talk. Modules discussed include,

• OpenMP::Environment
• Alien::OpenMP
• Inline::C

Because OpenMP is meant to be “environmentally aware”, it presents some challenges; these challenges and their solutions will be discussed. The ultimate goal of this talk is to promote the fledgling Perl-OpenMP effort and encourage exploration on the best ways to present SMP programming interfaces within Perl programs.

This talk is based on the six-month project completed under Season of Docs 2021. The aim was to identify the major problems in Perl’s existing documentation and to devise a strategy for its improvement. The project was completed successfully with a clear roadmap for the future.

Perl – an open-source, general-purpose programming language – has a lot of documentation, organized in the form of articles, FAQs, and web pages. Such detailed documentation, if not organized well, is overwhelming and frustrating for the audience. With over 100 core documentation pages, the users can easily get lost in the volume of the information, resulting in a bad user experience. This project aimed at resolving these issues and improving the structure of Perl’s core documentation. The project, divided into four major phases, was completed over the course of six months under the Google Season of Docs 2021.

1. Content Audit It all began with a comprehensive content audit. Every single document in Perl’s core documentation was thoroughly analyzed to identify the shortcomings of the existing documentation and the areas for improvement. A content audit spreadsheet was created, recording the traits of individual documents including but not limited to the date when a document was updated, the intended audience, and cross-referencing. The audit served as a first step in improving the documentation.
2. Gap Analysis The second phase was that of Gap Analysis, where insights from the Perl community came in handy. Individuals participated in informal user research and shared their feedback on the existing documentation. This gap analysis made the target audience a part of the project and provided clarification on the smaller, task-based, projects that could then be created to help improve the overall documentation.
3. Information Architecture Content audit and gap analysis, followed by discussions with the contributors at Perl, identified the ways in which the documentation could be made more useful and usable. In order to give a structure to the documentation, it was essential to improve the existing information architecture (IA). A new IA was proposed, which then went through a series of revisions, to incorporate the needs of the users in the structure and presentation of Perl’s core documentation.
4. Roadmap for the Future The final phase of the project was to devise a roadmap for the future of the documentation. This roadmap brought the findings of content audit, gap analysis, and information architecture together. Specific tasks and projects, along with possible limitations, were created and shared with the contributors of Perl to help improve the documentation in the days to come.

Quality documentation is imperative for the success of an engineering tool like a programming language. The existing documentation of Python, Prettier, and ESLint is a case in point. This project brought technical communication principles to documentation practices in the engineering discipline. The suggested improvements to Perl’s documentation will add value to the user experience by providing better navigation, ease of access, and a useful structure. The findings of this project highlight the best practices in engineering communication, serving as an example that documentation teams can follow in the future.

Perl’s Documentation: https://perldoc.pl/perl Google Season of Docs Proposal by Perl: https://gist.github.com/jmacdotorg/f306d9b0d4eae1dba879cad9cb8d2ace

Elevator Pitch
NEXT provides some nice features but was written long before mro, which has some nice features but lacks EVERY & EVERY::LAST. This talk describes why you’d care, how to graft mro into NEXT, and how mro::EVERY makes it easy.


Description
NEXT and mro provide useful features but not play nice together: NEXT uses its own depth-first search and cannot use “c3”. Unfortunately, mro is missing to of the more useful features of NEXT: the EVERY & EVERY::LAST pseudo-classes for automatic cross-class dispatch up and down the inheritance tree. This is especially painful because c3 makes so much more sense but modules that use the pseudo-classes can’t convert.
The pseudo-classes simplify cooperative operations like construction & destruction by passing a call up or down the inheritance stack to each class implementing the required method. This saves every class from having to knowingly participate in the process – and saves us all from people leaving it out or doing it wrong – and really simplifies creating generic base classes that are easy to use.
This talk looks at mro::EVERY and how the pseudo-classes were implemented using mro and what they offer, also how we can graft mro into NEXT, and how they can be used to simplify your life.

Intro
Juggling patterns are described by a mathematical language named Siteswap, with names such as:

• 333 AKA “Cascade”
• 4444 AKA “Fountain” AKA “Can’t You Juggle More Than 3?”
• 55555 AKA “5 Cascade” AKA “Can’t You Juggle More Than 4?”
• 51 AKA “Shower”
• 52515 AKA “Passing The Baby”

DescriptionI’m the founder of Circus Texas, and I’m friends with some of the guys who invented Siteswap notation in 1981.
In this presentation, you will see both the software and real-life on-stage versions of several Siteswap patterns, including:

• 333 AKA “Cascade”
• 4444 AKA “Fountain” AKA “Can’t You Juggle More Than 3?”
• 55555 AKA “5 Cascade” AKA “Can’t You Juggle More Than 4?”
• 51 AKA “Shower”
• 441 AKA “Half-Box”
• 531 AKA “Tower”
• 52515 AKA “Passing The Baby”

Free juggling lessons will be provided after the talk!