An anonymous reader quotes a report from Techdirt: Last week, hundreds of nurses protested the implementation of sloppy AI into hospital systems in front of Kaiser Permanente. Their primary concern: that systems incapable of empathy are being integrated into an already dysfunctional sector without much thought toward patient care: "No computer, no AI can replace a human touch," said Amy Grewal, a registered nurse. "It cannot hold your loved one's hand. You cannot teach a computer how to have empathy." There are certainly roles automation can play in easing strain on a sector full of burnout after COVID, particularly when it comes to administrative tasks. The concern, as with other industries dominated by executives with poor judgement, is that this is being used as a justification by for-profit hospital systems to cut corners further. From a National Nurses United blog post (spotted by 404 Media): "Nurses are not against scientific or technological advancement, but we will not accept algorithms replacing the expertise, experience, holistic, and hands-on approach we bring to patient care," they added. Kaiser Permanente, for its part, insists it's simply leveraging "state-of-the-art tools and technologies that support our mission of providing high-quality, affordable health care to best meet our members' and patients' needs." The company claims its "Advance Alert" AI monitoring system -- which algorithmically analyzes patient data every hour -- has the potential to save upwards of 500 lives a year. The problem is that healthcare giants' primary obligation no longer appears to reside with patients, but with their financial results. And, that's even true in non-profit healthcare providers. That is seen in the form of cut corners, worse service, and an assault on already over-taxed labor via lower pay and higher workload (curiously, it never seems to impact outsized high-level executive compensation).

Read more of this story at Slashdot.

Microsoft has many AI Assistants that leverage available OpenAI Large Language Models such as GPT4Turbo, the world’s leading AI model.  The brand “Copilot” is often used to describe these implementations.

Specifically, Copilots are simply “AI Assistants” specifically for information workers, developers, architects & IT professionals that augment existing tools to increase productivity & reduce repetition.  They are available for a broad set of Microsoft products & services – here’s a short list that you may be interested in:

• Microsoft Copilot (with Commercial Data Protection)
• Copilot for Windows (Overview)
• Copilot for Edge
• Copilot for Microsoft 365 (Overview, Productivity Demo)
  • Microsoft 365 Chat (Manage your inbox, Identity common themes, Update your team faster, Grow your knowledge)
  • Copilot for Word (Overview, Request tailored edits, Transform a document, Locate key information, Gain focus time, Get a headstart)
  • Copilot for Excel (Overview, Be more analytical, Quick conditional formatting, Identify key insights, Make engaging charts)
  • Copilot for PowerPoint (Overview, Quickly generate ideas, Create consistency, Tell impactful stories)
  • Copilot for Teams (Meeting Recap, Live Meetings, Ask better questions, Discern opinions quickly)
  • Copilot for OneNote (Optimize meeting follow up, Create adhoc meeting templates)
  • Copilot for Outlook (Translate an email, Draft effective emails, Manage your inbox, Keep up with Meetings)
  • Copilot in Forms (Create engaging forms)
  • Copilot in Whiteboard (Brainstorming)
  • Copilot in Loop (Bring people together in real time)
  • Copilot in Stream (Video AI in Action)
  • Copilot in OneDrive (Build a knowledge library)
  • Copilot for Planner (Streamline your work)
  • Copilot in SharePoint (Sharepoint in the AI era, Generate sites through chat, Create sites based on documents)
  • Copilot Studio (Build your own custom business Copilot)
• Copilot for Security
• Copilot for Azure
  • Copilot for Azure in CosmosDB (Overview docs, Enable natural language NoSQL queries)
• Copilot for Dynamics 365
  • Copilot in Field Service
  • Copilot in Finance (Drive performance & reduce repetition)
  • Copilot for Project Operations
  • Copilot in Dynamics 365 F&O Help & Guidance
  • Copilot in Dynamics 365 Commerce
  • Copilot in Dynamics 365 Supply Chain Management
  • Copilot for Dynamics 365 Sales & Microsoft Sales Copilot (Transform sales effectiveness)
  • Copilot in Dynamics 365 Customer Service & Copilot for Service
  • Copilot in Dynamics 365 Customer Insights
  • Copilot in Dynamics 365 Guides
• GitHub
  • GitHub Copilot
  • GitHub Copilot Enterprise
  • GitHub Copilot extension for Azure Data Studio
• Copilot for Power Platform
  • Copilot for Power Apps
  • Copilot for Power Automate
  • Copilot for Power Pages (Overview docs, Accelerate web site building)
  • Copilot for Power BI
• Copilot for Fabric
• Nuance DAX Copilot for Healthcare (Demo)

There are numerous OTHER Artificial Intelligence technologies that are not characterized as “Copilots”.

• Azure AI Platform
  • Azure OpenAI Service
  • Azure AI Studio
  • Azure Machine Learning
  • Azure AI Search
  • Azure AI Content Safety
  • Azure Cognitive Services
  • Azure AI Translator
  • Azure AI Speech
  • Azure AI Vision
  • Azure AI Language
  • Azure AI Document Intelligence

Fleet 1.34 is now available! Explore our latest release, which introduces many new features designed to improve your development experience. You can update to this latest version using the Toolbox App.

Let’s take a closer look at the highlights of this update.

Download Fleet 1.34

New features

• We’re excited to introduce AI code completion for Python and Kotlin! The new gray-text code completion, powered by JetBrains’ own model, provides great performance and accuracy. To explore the code completion feature, select AI Assistant from the Tools menu or invoke an AI-powered action from the Actions menu. Log in with your JetBrains account if needed. You can also start a free JetBrains AI trial (no credit card required).

• We’ve added the Force Step Into action to Fleet. This action lets you debug methods defined in the APIs or libraries. If the source code of the API or library is not available, Fleet decompiles and debugs it for you.

• It was already possible to debug Kotlin/Wasm applications in the browser. Now, you can debug applications built with Kotlin/Wasm right inside Fleet.

• You can now enable relative line numbering. Open Settings, go to Appearance, and you’ll find the Line numbers drop-down menu where you can choose between On, Off, and Relative.

• In this update, we also made many improvements to the Markdown preview. The most important one is the synchronized scrolling of the Markdown preview and the editor.

• You can now run simple Java applications without the need to create a project with a build tool, such as Maven or Gradle.

• Fleet already supported syntax highlighting for .env files. Starting with Fleet 1.34, .env.* files, such as .env.local, .env.example, etc., are now supported as well.

• Files can now be configured to end with a new line. To enable this, add insert_final_newline = true to your .editorconfig.

Improvements

• Fleet 1.34 introduces the option to enable smooth caret animation. Open Settings and go to Editor | Caret.

• Fleet no longer opens a new window when connecting to WSL or SSH.

• We’ve added aliases for programming languages when using the language dialog box. For example, you can now type c# or csharp, and you will find the language you are looking for.

• If you are running an Android application in Fleet, the log will be displayed in a separate window instead of a tab in the current Fleet window.

Bug fixes

We’ve also fixed a number of bugs:

• HTML and XML indentations now work as intended.

• Selected text now scrolls continuously beyond the boundaries of the editor.

• Gemfiles now have syntax highlighting.

• You can create a new file while following a collaborator.

See the full release notes for more details about the 1.34 update.

Please report any issues you encounter to our issue tracker, and stay tuned for further exciting announcements.

P.S. Support for plugins and plugin APIs is a work in progress, but the list of installed (bundled) plugins is now available and visible to everyone. To view it, simply select Plugins in the Actions menu.

---

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

Explore a new way to access experimental features in WinGet.

The Windows Package Manager (WinGet) is a command-line tool that allows you to install and manage applications on Windows. WinGet has been in development since 2020 and has been releasing new features and improvements regularly. However, to date, the use of experimental features has only been available in preview releases of WinGet, accessible via the WinGet repository on GitHub. With preview builds, the WinGet team has been able to test new and experimental features before releasing them to the production build, which is the stable and official version of WinGet. Anyone who wanted to try out the latest and greatest features of WinGet, therefore, had to install the preview release.

That's about to change with WinGet 1.9, scheduled to ship in October 2024. In this release, the WinGet team will be enabling the use of experimental features in production builds. This means that you will no longer have to switch between the two different builds of WinGet to access all the experimental features. However, this does not mean that the experimental features of WinGet will be enabled by default. Some features will still be in development or testing, in which case you will have to opt-in to enable them. This ensures that you can choose which features you want to use and which ones you want to avoid, depending on your preferences and needs.

How to enable and disable experimental features in WinGet

Enabling and disabling experimental features in WinGet is very easy and straightforward. Use the WinGet settings command to open the settings file of WinGet, which is in JSON format. In this file, you can add a section called Experimental Features, and include a list of experimental features you want enabled in WinGet. For example, if you want to enable the experimental feature called configureSelfElevate, which allows WinGet CLI to request elevation when running a WinGet Configure command and elevation is required, you would have to set the value of configureSelfElevate to true in the settings file. After saving the file, you will have access to the enabled experimental features.

For a complete list of experimental features, see WinGet CLI settings on GitHub.

You will be able to enable and disable experimental features in WinGet at any time as long as you have permission to edit the settings file. Please be aware that experimental features are not guaranteed to work as expected, and you may encounter bugs, errors, or unexpected behaviors when using them. We recommend that you read the descriptions of each feature carefully before enabling it as some features may have dependencies or requirements that need to be met before using them.

How to block the use of experimental features in WinGet

Some enterprises may not want to use or allow the use of experimental features in WinGet, either for security, stability, or compatibility reasons. If that is the case, you can block the use of experimental features in WinGet by disabling the Enable App Installer Experimental Features Group Policy Object (GPO), which will prevent the enabling of experimental features in WinGet. Anyone who tries to enable experimental features in WinGet after the WinGet GPO has been applied will receive an error message saying that the feature is blocked by policy.

If you want to block the use of experimental features in WinGet, you should enable the WinGet GPO before the WinGet 1.9 release, as experimental features will be enabled by default after this release. If you enable the WinGet GPO after the release, you will not need to disable any experimental features that were already enabled in WinGet before applying the policy. The policy will disable any experimental features that had been previously enabled.

Get more out of WinGet

The WinGet 1.9 release will bring a major change to the way you can access and use experimental features in WinGet. By offering experimental features in the production release of WinGet, our goal is to simplify the installation and update process of WinGet and give you more control and flexibility over the features you want to use. Users of WinGet will be able to enable and disable experimental features in WinGet using the settings file while IT pros can block the use of experimental features in WinGet using the GPO. Please make sure that both IT and users are aware of the risks and benefits of using experimental features.

For more information and updates on new and experimental features, be sure to check the WinGet documentation and the GitHub repository. Also, we’d love for you to provide feedback and report issues to the WinGet team to help improve the quality and functionality of WinGet.

---

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.

Rizel Scarlett is a Staff Developer Advocate at TBD, Block's newest business unit. TBD is an incubator operating within Block. They are building open source platforms and protocols that make it easy to exchange money internationally.  

Download audio: https://r.zen.ai/r/cdn.simplecast.com/audio/24832310-78fe-4898-91be-6db33696c4ba/episodes/d8a63851-6c41-4846-99d6-085e161e0ace/audio/495d610d-faad-4355-89ea-fbc55d167de7/default_tc.mp3?aid=rss_feed&feed=gvtxUiIf

Last time, we figured out how to await two handles with a common timeout. Armed with what we learned from that ordeal, we can try to generalize it to an arbitrary number of handles.

Our first attempt might go like this:

template<typename Iter>
wil::task<std::vector<bool>>
    resume_on_all_signaled(Iter first, iter last,
        winrt::Windows::Foundation::TimeSpan timeout = {})
{
    using BoolOp = winrt::Windows::Foundation::IAsyncOperation<bool>;

    std::vector<BoolOp> ops;
    std::transform(first, last, std::back_inserter(ops),
        [&](HANDLE handle) {
        return resume_on_one_signal(handle, timeout);
    });

    std::vector<bool> results;
    for (auto&& op : ops) {
        results.push_back(co_await winrt::resume_agile(op));
    }

    co_return std::move(results);
}

The first step is to take the incoming handles and convert them to async operations, which we gather in a vector.

Next, we await each of the awaiters and push the result onto a results vector.

Finally, we return the results.

Now, one of the really annoying things happening here is that we are using vector<bool>. As I noted some time ago, this specialization represents a packed bit array. This has made a lot of people very angry and has been widely regarded as a bad move.

So let’s use a C-style array of bool instead. C++/WinRT comes with one already, known as winrt::com_array. We’ll use that.

template<typename Iter>
wil::task<winrt::com_array<bool>>
    resume_on_all_signaled(Iter first, iter last,
        winrt::Windows::Foundation::TimeSpan timeout = {})
{
    using BoolOp = winrt::Windows::Foundation::IAsyncOperation<bool>;

    std::vector<BoolOp> ops;

    std::transform(first, last, std::back_inserter(ops),
        [&](HANDLE handle) {
        return resume_on_one_signal(handle, timeout);
    });

    if (ops.size() > ~0U / sizeof(bool)) {                   
      throw std::bad_alloc();                                
    }                                                        
    auto size = static_cast<uint32_t>(ops.size());           
    auto results = winrt::com_array{ size };                 
    for (auto index = 0U; index < size; ++index) {           
        results[index] =                                     
               co_await winrt::resume_agile(awaiters[index]);
    }                                                        

    co_return std::move(results);
}

There is a serious issue: We behave erratically if an exception is thrown from co_await.

An exception is possible because the awaiter returned by resume_on_signal will throw an exception if it cannot set up the threadpool wait. In that case, the state of the handles is indeterminate: Some of them may have been successfully waited, and others may not have been, and you don’t know which were and weren’t waited because the exception prevented you from receiving the results.

Knowing which ones were awaited is important if any of the things you are waiting for are consumable, such as semaphores or auto-reset events.

We’ll continue our investigation next time.

The post Awaiting a set of handles with a timeout, part 3: Going beyond two appeared first on The Old New Thing.