One of GitHub’s core values is Diverse and Inclusive. It is a guiding thought for how we operate, reminding us that GitHub serves a developer community that spans a wide range of geography and ability.

Putting diversity and inclusivity into practice means incorporating a wide range of perspectives into our work. To that point, disability and accessibility are an integral part of our efforts.

This consideration has been instrumental in crafting resilient, accessible components at GitHub. These components, in turn, help to guarantee that our experiences work regardless how they are interacted with.

Using GitHub should be efficient and intuitive, regardless of your device, circumstance, or ability. To that point, we have been working on improving the accessibility of our lists of issues and pull requests, as well as our information tables.

Our list of issues and pull requests are some of the most high-traffic experiences we have on GitHub. For many, it is the “homepage” of their open source projects, a jumping off point for conducting and managing work.

Our tables help to communicate, and facilitate taking action with confidence on complicated information relationships. These experiences are workhorses, helping to communicate information about branches, repositories, secrets, attestations, configurations, internal documentation, etc.

Nothing about us without us

Before we discuss the particulars of these updates, I would like to call attention to the most important aspect of the work: direct participation of, and input from daily assistive technology users.

Disabled people’s direct involvement in the inception and development stages is indispensable. It’s crucial for us to go beyond compliance and weave these practices into the core of our organization. Only by doing so can we create genuinely inclusive experiences.

With this context established, we can now talk about how this process manifests in component work.

Improvements we’re making to lists of issues and pull requests

Lists of issues and pull requests will continue to support methods of navigation via assistive technology that you may already be familiar with—making experiences consistent and predictable is a huge and often overlooked aspect of the work.

In addition, these lists will soon be updated to also have:

• A dedicated subheading for quickly navigating to the list itself.
• A dedicated subheading perissue or pull request.
• List and list item screen reader keyboard shortcut support.
• Arrow keys and Home/End to quickly move through each list item.
• Focus management that allows using Tab to explore individual list item content.
• Support for Space keypresses for selecting list items, and Enter for navigating to the issue or pull request the list item links to.

This allows a wide range of assistive technologies to efficiently navigate, and act on these experiences.

Improvements we’re making to tables

We are in the process of replacing one-off table implementations with a dedicated Primer component.

Primer-derived tables help provide consistency and predictability. This is important for expected table navigation, but also applies for other table-related experiences, such as loading content, sorting and pagination requests, and bulk and row-level actions.

At the time of this blog post’s publishing, there are 75 bespoke tables that have been replaced with the Primer component, spread across all of GitHub.

The reason for this quiet success has been due entirely to close collaboration with both our disabled partners and our design system experts. This collaboration helped to ensure:

1. The new table experiences were seamlessly integrated.
2. Doing so, improved and enhanced the underlying assistive technology experience.

Progress over perfection

Meryl K. Evans’ Progress Over Perfection philosophy heavily influenced how we approached this work.

Accessibility is never done. Part of our dedication to this work is understanding that it will grow and change to meet the needs of the people who rely on it. This means making positive, iterative change based on feedback from the community GitHub serves.

More to come

Tables will continue to be updated, and the lists should be released publicly soon. Beyond that, we’re excited about the changes we’re making to improve GitHub’s accessibility. This includes both our services and also our internal culture.

We hope that these components, and the process that led to their creation, help you as both part of our developer community and as people who build the world’s software.

The post How we’re building more inclusive and accessible components at GitHub appeared first on The GitHub Blog.

Last time, we created an awaiter that could await a [first, last) range of handles. It did so by pushing onto a vector for each such handle, but this is inefficient in the case where the number of handles is known in advance. Let’s add a constructor for the case where the iterators support the subtraction operator.¹

struct awaiter
{
    ⟦ data members unchanged ⟧

    template<typename Iter,                 
        typename = std::void_t<             
            decltype(std::declval<Iter>() - 
                     std::declval<Iter>())>>
    awaiter(Iter first, Iter last,          
        std::optional<TimeSpan> timeout,    
        int) :                              
        m_timeout(timeout)                  
    {                                       
        auto count = last - first;          
        m_states.resize(count);             
        for (auto& s : m_states) {          
            m_states.m_handle = *first;     
            ++first;                        
        }                                   
        create_waits();                     
    }                                       

    template<typename Iter, typename = void>
    awaiter(Iter first, Iter last,
        std::optional<TimeSpan> timeout,
        unsigned) :
        m_timeout(timeout)
    {
        std::transform(first, last, std::back_inserter(m_states),
            [](HANDLE h) { state s; s.m_handle = h; return s; });
        create_waits();
    }

    ⟦ other methods unchanged ⟧
};

template<typename Iter>
auto resume_on_all_signaled(Iter first, Iter last,
    std::optional<winrt::Windows::Foundation::TimeSpan> timeout
        = std::nullopt)
{
    return resume_all_awaiter(first, last, timeout, 0);
}

We add another constructor that is enabled via SFINAE if the iterator type supports subtraction. If so, then we use that subtraction operator to get the number of handles, then resize the vector directly to that size, so that we can fill in the handles without having to do any reallocating. This significantly reduces code size because the compiler doesn’t have to generate any resize logic.

Note that if the iterator supports subtraction, then both constructors become available, so we use an unused parameter to steer the compiler toward the int version if it is available, since int is considered a better match for 0 than unsigned.

¹ Why do we look for a subtraction operator, rather than checking the iterator category for random_access_iterator_tag? Because not all subtractable iterators satisfy the requirements of a random access iterator. In particular, dereferencing a random access iterator must produce a reference, which rules out things like IVectorView since the Get­At method returns a copy, not a reference. The C++ iterator library doesn’t have a built-in way to detect a random-access output iterator, so we have to make up our own.

The post Awaiting a set of handles with a timeout, part 6: Capturing the handles efficiently appeared first on The Old New Thing.

New OLED iPad Pros, bigger iPad Airs, and new accessories.

Continue reading…

In an email to staff sent this morning, head of Xbox Game Studios Matt Booty announced the closure of several game studios, including Redfall developer Arkane Austin, Hi-Fi Rush developer Tango Gameworks, Alpha Dog Games, and more. According to the email, as first reported by IGN, Booty wrote the reason for the closures was due to a “reprioritization of titles and resources.” Some staff at the affected studios will be relocated while other studios will completely shut down.

Redfall developer Arkane “will close with some members of the team joining other studios to work on projects across Bethesda,” says Booty. Redfall’s previous update will be its last as Microsoft is ending all development on the game. Servers “will remain online for...

Continue reading…

Microsoft has donated $1 million to The Rust Foundation to do whatever it sees fit.

Microsoft, a Rust Foundation Platinum Member, made an unrestricted donation in December 2023 to help the organization advance the performance, safety, and sustainability of the Rust programming language.

However, the announcement of the donation was delayed because the foundation needed time to democratically decide how to best allocate the funds to support the Rust maintainers and the language itself, Dr. Rebecca Rumbul, the Rust Foundation’s executive director and CEO, told The New Stack.

Two Years

Microsoft’s donation will be invested over a two year period and applied to high-priority areas of need in the Rust ecosystem, including hiring an additional Rust Foundation infrastructure engineer (now closed to applications), funding the Rust Foundation’s capstone “Fellowship” program, and developing new systems and programs to support the work of Rust Project maintainers and reduce workload strain, Rumbul said.

In January 2024, the Rust Foundation’s Board of Directors approved a motion to put $350,000 of this funding towards employing a new Infrastructure Engineer for two years, and to ringfence $650,000 for the Rust Project to directly fund priorities of their choosing over a period of two years.

The Rust Foundation spent the first quarter of 2024 in close collaboration with the Rust Foundation Project Directors and the Rust Project Leadership Council to identify the most pressing areas of need within the Rust Project. The Leadership Council is currently considering a plan that would involve using a large portion of the first $325,000 reserved for the Rust Project to make key process improvements, including the development of new collaboration mechanisms to help support maintainer workflow efficiency.

“By making this unrestricted $1M contribution to the Rust Foundation, Microsoft has demonstrated its ongoing commitment to the Rust programming language, the Rust Foundation’s stewardship, and the Leadership Council’s status as an advocate for the wider Rust Project,” she said in a statement. “The Rust Foundation looks forward to supporting emerging priorities within the Project, in addition to hiring a second Infrastructure Engineer and continuing our direct support of Rust maintainers through the Fellowship program.”

Long-Time Supporter

Microsoft has been a long-time supporter of the Rust programming language and the Rust Foundation, especially through the Azure division and Mark Russinovich, Microsoft’s CTO for Azure, Rumbul noted.

“This contribution demonstrates Microsoft’s commitment to the Rust programming language, and its continued success through the Rust Foundation,” said Nell Shamrell-Harrington, Rust Foundation Member Director for Microsoft and Board Vice-Chair, in a statement. “Microsoft is pleased to see its $1M investment being used to hire Rust Foundation infrastructure engineers, support the Rust Foundation Community Grants Program, and directly support critical areas of need identified by leaders within the Rust Project.”

Microsoft’s donation was not only unrestricted but also unexpected, demonstrating the company’s faith in the foundation to allocate the funds effectively, she said.

Google Donation

In February, Google donated $1M to The Rust Foundation to fund efforts to make C++ and Rust more interoperable. However, this Microsoft donation is different.

For one thing, it came to the foundation a couple of months before Google’s donation, and it was for the foundation to choose what to do with the funding.

“This donation is different from Google’s $1 million donation, which was specifically earmarked for studying the interoperability between C++ and Rust,” Rumbul said.

That two major tech vendors are investing in Rust says a lot, according to Brad Shimmin, an analyst at Omdia.

He argues that two companies that have their own vested interests in the likes of C#/TypeScript and Golang, all strongly typed languages are donating to the Rust language is significant.

“I honestly think this sort of investment points to two important thoughts. First it underscores the value of the Rust language, which has found its way into many important projects, such as the Linux kernel itself. Even though the language may be difficult to learn, it has proven Itself to be well suited to software that operates close to the hardware, delivering both performance and stability,” Shimmin told The New Stack. “And second, I think it calls attention to the need for guidance and stability within the Rust community itself, which has proven to be somewhat volatile over the last year or two.”

Safety and Security

Meanwhile, Rumbul said memory safety and secure programming have been key to organizations adopting Rust.

“I feel like two or three years ago and before that, no one was really talking about security like now, as security was always kind of a bolt-on after the fact,” she said. “Whereas now the attitude has shifted, and you should be building secure software by default. You need to be baking in security at the time of coding.”

Rumbul mentioned directives from organizations like the Cybersecurity and Infrastructure Security Agency (CISA) and the White House looking at Rust due to its focus on security and performance.

“Cloud providers need memory-effective code — and this one of the Rust fortes,” said Holger Mueller, an analyst at Constellation Research. “And Rust is just popular with developers, as it is ‘the most loved language,’” according to Stack Overflow, he said. “It makes sense as a foundation member for Microsoft to be a good citizen.”

Overall, the unrestricted donation from Microsoft is seen as a significant vote of confidence in the Rust Foundation and its ability to effectively support and grow the Rust ecosystem.

The post Microsoft’s $1M Vote of Confidence in Rust’s Future appeared first on The New Stack.