Read more of this story at Slashdot.
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:
There are numerous OTHER Artificial Intelligence technologies that are not characterized as “Copilots”.
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.
.env
files. Starting with Fleet 1.34, .env.*
files, such as .env.local
, .env.example
, etc., are now supported as well.insert_final_newline = true
to your .editorconfig.We’ve also fixed a number of bugs:
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.
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.
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.
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.
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.