FLOSS Project Planets

Explore the transformative vision behind Drupal Starshot through the insights of Gábor Hojtsy and Pamela Barone. This ambitious initiative addresses Drupal's past criticisms by enhancing user experience and accessibility with innovative UI improvements and pre-packaged feature sets. Delve into the potential and challenges of Starshot and understand how the leadership team is steering Drupal towards a more user-friendly future.

 

I'm pleased to announce the release of Python 3.13 beta 3.

https://www.python.org/downloads/release/python-3130b3/

 

This is a beta preview of Python 3.13

Python 3.13 is still in development. This release, 3.13.0b3, is the third of four beta release previews of 3.13.

Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release.

We strongly encourage maintainers of third-party Python projects to test with 3.13 during the beta phase and report issues found to the Python bug tracker as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Tuesday 2024-07-30). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.13.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.13 as possible during the beta phase.

 

Please keep in mind that this is a preview release and its use is not recommended for production environments.

 Major new features of the 3.13 series, compared to 3.12

Some of the new major new features and changes in Python 3.13 are:

New features

• A new and improved interactive interpreter , based on PyPy’s, featuring multi-line editing and color support, as well as colorized exception tracebacks .
• An experimental free-threaded build mode , which disables the Global Interpreter Lock, allowing threads to run more concurrently. The build mode is available as an experimental feature in the Windows and macOS installers as well.
• A preliminary, experimental JIT , providing the ground work for significant performance improvements.
• The (cyclic) garbage collector is now incremental , which should mean shorter pauses for collection in programs with a lot of objects.
• A modified version of mimalloc is now included, optional but enabled by default if supported by the platform, and required for the free-threaded build mode.
• Docstrings now have their leading indentation stripped, reducing memory use and the size of .pyc files. (Most tools handling docstrings already strip leading indentation.)
• The dbm module has a new dbm.sqlite3 backend that is used by default when creating new files.
• The minimum supported macOS version was changed from 10.9 to 10.13 (High Sierra). Older macOS versions will not be supported going forward.
  

Typing

• Support for type defaults in type parameters.
• A new type narrowing annotation , typing.TypeIs.
• A new annotation for read-only items in TypeDicts .

Removals and new deprecations

• PEP 594 (Removing dead batteries from the standard library) scheduled removals of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.
• Many other removals of deprecated classes, functions and methods in various standard library modules.
• C API removals and deprecations. (Some removals present in alpha 1 were reverted in alpha 2, as the removals were deemed too disruptive at this time.)
• New deprecations, most of which are scheduled for removal from Python 3.15 or 3.16.

(Hey, fellow core developer, if a feature you find important is missing from this list, let Thomas know.)

For more details on the changes to Python 3.13, see What’s new in Python 3.13 . The next pre-release of Python 3.13 will be 3.13.0b4, currently scheduled for 2024-07-16.

 More resources

• Online Documentation
• PEP 719 , 3.13 Release Schedule
• Report bugs at Issues · python/cpython · GitHub .
• Help fund Python directly (or via GitHub Sponsors), and support the Python community.

 Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.

Your release team,
Thomas Wouters
Łukasz Langa
Ned Deily
Steve Dower 

 

What an exciting list! Please take a look at who is running for the PSF Board this year on the PSF Board Election 2024 Nominees page. This year there are 3 seats open on the PSF board. You can see who is currently on the board on the PSF Officers & Directors page. (Débora Azevedo, Kwon-Han Bae, and Tania Allard are at the end of their current terms.)

Board Election Timeline

• Nominations open: Tuesday, June 11th, 2:00 pm UTC
• Nomination cut-off: Tuesday, June 25th, 2:00 pm UTC
• Voter application/affirmation cut-off date: Tuesday, June 25th, 2:00 pm UTC
• Announce candidates: Thursday, June 27th
• Voting start date: Tuesday, July 2nd, 2:00 pm UTC
• Voting end date: Tuesday, July 16th, 2:00 pm UTC

Not sure what UTC is for you locally? Check using this timezone converter! 

Voting

Voting opens on Tuesday, July 2nd at 2:00 pm UTC, through Tuesday, July 16th, 2024 2:00 pm UTC. Check the Elections page to see how much time you have left to vote. 

If you are a voting member of the PSF that affirmed your intention to participate in this year’s election, you will receive an email from “OpaVote Voting Link <noreply@opavote.com>” with your ballot, the subject line will read “Python Software Foundation Board of Directors Election 2024”. If you haven’t seen your ballot by Wednesday, please first check your spam folder for a message from “noreply@opavote.com”. If you don’t see anything get in touch by emailing psf-elections@python.org so we can look into your account and make sure we have the most up-to-date email for you.

If you have questions about your membership status or the election, please email psf-elections@python.org. You are welcome to join the discussion about the PSF Board election on the PSF Discuss forum.

We are happy to announce the release of Qt Creator 14 Beta2!

 So... recently I was working for a bit (sweat equity or so I thought) for a company by the name of ImmortalData.  The company is headed by a man by the name of Dale Amon.  I have worked, on and off, for them for about 2-3 years.   They are developing a piece of software that is used to extract data from their proprietary black box systems.  This piece of software uses GNUstep.   They were born from a previous company known as XCOR which was developing a space plane at the Mojave space port.   That company is now defunct.

Okay, so with that bit of history, I worked for a while for XCOR and then, because ImmortalData inherited the software, for them as well.  When I worked for XCOR it was as a contractor.  There have been issues with the software (some GNUstep bugs and some bugs due to problems introduced by Dale) that I have been asked to address.

At the end of a meeting a few weeks ago Dale made a comment like "Well, this issue seems like a GNUstep bug, so there is no reason we should have to pay for any of this" which hit an EXTREMELY sour note with me.

Later on that week I tried to clarify it with Dale, and it seems as though he was under the impression that since I was working on Free Software any changes or fixes TO that software should not be billable.   This is NOT true.  Additionally, the issue that they are experiencing is because of something THEY did, and it is not a GNUstep bug. 

I mentioned this in the previous post, but I feel strongly that this needs to be called out explicitly.   Free Software is free as in FREEDOM.  This means you are free to look at, examine, and modify the software as you see fit.   It does NOT mean services performed on that software on your behalf by someone other than you are free.

This development was VERY upsetting to me and I feel the need to make the above VERY clear.

⚠️ Only one day left to buy a @DrupalConEur Early Bird ticket. Join the Starshot track to learn about the Admin UI redesign process, what's behind the Launch button, how will package security be improved further, what will recipes allow you to do and more! https://events.drupal.org/barcelona2024/drupal-starshot-track

The Biggest Challenges in Drupal 10 Migration and How to Overcome Them bhavinhjoshi Thu, 06/27/2024 - 15:34 Drupal 10

Welcome to the world of Drupal 10, a cutting-edge iteration of one of the most powerful and feature-rich content management systems (CMS) available today. Launched in December 2022, Drupal 10 builds on the strengths of its predecessors while offering a range of exciting new features and improvements.

But what makes Drupal 10 stand out? First and foremost, it comes packed with the latest innovations in technology, security, and design, ensuring your website meets the modern-day demands of online users.

One of the most significant advantages of Drupal 10 over previous versions is its improved performance. Drupal 10 is faster and more efficient, providing an enhanced user experience which can lead to higher user engagement, lower bounce rates, and ultimately, increased conversions.

Drupal 10 also provides better security with its automatic updates feature, without relying on third-party plugins. This means you can rest easy knowing your website is always up-to-date and protected against potential cyber threats.

Furthermore, Drupal 10 comes with a new administrative theme, Olivero, that is more accessible and user-friendly. This makes it easier for website administrators to manage and edit content.

Inclusivity is also a major focus in Drupal 10. The CMS is designed to be more accessible, addressing the needs of users with disabilities and making the internet a more inclusive space for everyone.

Migrating to Drupal 10 may present some challenges, but the benefits far outweigh the hurdles. In this post, we will explore some of these challenges and provide practical solutions to ease the migration process. So, let's get started.

 

The Challenge of Deprecated Modules

One of the key challenges you might face when migrating to Drupal 10 is dealing with deprecated modules. “Deprecated” in this sense means that these modules are no longer recommended for use and are slated for removal in future versions of Drupal.

In previous versions of Drupal, you may have installed certain modules to extend the functionality of your site. These modules could range from image sliders and SEO tools, to custom field types and formatting options. However, since Drupal 10 is a step forward in terms of technology and usability, some of these modules might not be compatible with the new version.

When these deprecated modules are not supported by Drupal 10, they can cause disruption to the functionality of your website during the migration process. It's as if you're trying to fit a square peg into a round hole. The two are simply not compatible, and forcing them together won't work.

For example, you may find that a custom field type provided by a deprecated module no longer works in Drupal 10. This could lead to data loss, or perhaps certain sections of your website not displaying correctly. If your website heavily relies on such deprecated modules, this could potentially cause significant disruption to your site's functionality and user experience.

 

The Solution: Identifying and Replacing Deprecated Modules

Addressing the issue of deprecated modules requires a two-step process: identifying them and then replacing them with suitable alternatives in Drupal 10.

Identifying Deprecated Modules

The first step is to identify which modules on your site are deprecated. Drupal makes this process relatively straightforward with the use of the Upgrade Status module. This module provides a comprehensive report of all the deprecated code that your site is using, including modules.

To use the Upgrade Status module, you simply need to install it on your Drupal site and run a scan. The module will produce a list of deprecated modules you're currently using, making it easy for you to see what needs changing.

Replacing Deprecated Modules

Once you've identified the deprecated modules, the next step is to find suitable replacements.

Start by researching if there are updated versions of these modules that are compatible with Drupal 10. Module maintainers often release updated versions for new Drupal releases. You can usually find this information on the module's page on the Drupal website.

If a deprecated module doesn't have an updated version, you'll need to find an alternative module that offers similar functionality. The Drupal community is a good place to start your search. You can also ask for recommendations from other Drupal users. It's likely that others have faced a similar issue and can recommend a suitable module.

In some cases, you might find that the functions provided by a deprecated module have been incorporated into Drupal 10's core. In this case, you simply need to enable the corresponding functionality in Drupal 10.

Remember, always test new modules on a development version of your site before installing them on your live site. This way, you can ensure that the new module works correctly and doesn't cause any issues.

While dealing with deprecated modules can be a bit of a headache, it can also be an opportunity to streamline your site and improve its functionality.

 

The Challenge of Custom Code

If you've been operating a Drupal site for some time, it's likely that you or your development team have written custom code to tailor the website to your specific needs. This custom code could include anything from unique themes to specific functionalities that are critical to your website's operation. While this helps make your site uniquely yours, it can pose challenges during the migration process to Drupal 10.

Primarily, some of your custom code may not be compatible with Drupal 10 due to the differences in code requirements and standards between different Drupal versions. Your custom code may be using functions or methods that are deprecated in Drupal 10, or the architecture of Drupal 10 may simply not support your custom code.

This incompatibility can lead to errors during your site's migration to Drupal 10, causing certain functionalities to break or not function as intended. In worst-case scenarios, incompatible custom code can even make your website inaccessible. This can lead to a poor user experience, potentially causing lost audience engagement or revenue.

The challenge posed by custom code, therefore, is twofold: you need to identify the custom code that's causing issues, and then update or rewrite this code to be compatible with Drupal 10. This process can be time-consuming and complex, requiring a deep understanding of Drupal's coding requirements and standards.

 

The Solution: Identifying and Refactoring Custom Code

Managing custom code for a Drupal 10 migration can seem daunting, but with the right approach, it doesn't have to be. Here's how to go about it:

Identifying Problematic Custom Code

Much like identifying deprecated modules, the first step is to identify which parts of your custom code may be problematic in Drupal 10. The Upgrade Status module comes in handy here as well. Beyond just identifying deprecated modules, this tool can also scan your custom code to find deprecated API use and other potential issues that could cause problems in Drupal 10.

Another tool you can use is the Drupal-check command-line tool. This tool uses the same underlying library as the Upgrade Status module to check custom code for deprecations and other potential pitfalls.

Refactoring Custom Code:

After identifying the troublesome parts of your custom code, the next step is to refactor them to be compatible with Drupal 10. Simply put, refactoring is the process of altering the code without changing its external behavior.

If the Upgrade Status module flagged some code as deprecated, the report will usually include suggestions for what to replace the deprecated code with. If it doesn't, the Drupal API documentation can be a helpful resource. You'll have to replace deprecated function calls, alter data structures, or even rearchitect some parts of your code to ensure compatibility.

In some cases, the changes required might be quite extensive, especially for code written for earlier versions of Drupal. If you're not comfortable doing this on your own, it may be worth hiring a Drupal developer with experience in migrations.

Finally, it's crucial to thoroughly test your changes to ensure that they work correctly and have not altered the expected behavior of your website. Automated testing tools can be a great help in this regard, ensuring your code is robust and ready for migration to Drupal 10.

Refactoring custom code for Drupal 10 can be an involved process, but it's a vital step in preparing your site for the migration. With careful planning and diligent testing, you can make your transition to Drupal 10 smoother and more successful.

 

The Challenge of Ensuring Consistent Performance

As with any major update or migration, moving to Drupal 10 can potentially impact the performance of your website. Performance, in this context, relates to how quickly your website loads, how smoothly it operates, and how well it manages the resources of the server it's hosted on.

While Drupal 10 is designed to be faster and more efficient than its predecessors, the migration process itself can lead to unexpected dips in performance. For instance, new modules or updated versions of existing ones may not be as optimised as those on your current site, slowing down load times. Similarly, potential compatibility issues with custom code may lead to increased server load, impacting website speed and overall performance.

Besides the technical aspects, user experience can also be affected during the migration process. Changes in layout due to a new theme or variations in navigational structures can disorient regular visitors, affecting user engagement and bounce rates.

These performance risks are a vital concern during migration because an optimally performing website is crucial for maintaining user engagement, SEO rankings, and overall user satisfaction.
 

 

The Solution: Monitoring Performance and Identifying Areas for Improvement

Monitoring your site’s performance pre, mid and post migration can play a pivotal role in ensuring a successful transition to Drupal 10. Here is how you can stay on top of it:

Benchmarking Performance Pre-Migration

Before you begin the migration process, document your website's current performance. This includes page load times, server response times, error rates, and any other relevant metrics. Use tools like Google PageSpeed Insights, GTMetrix, or Pingdom to gather this data. Having this information will allow you to compare performance before and after the migration, and identify any areas that need improvement.

Maintaining Performance During Migration

During the migration process, ensure that your website remains in an operational state. Regularly check for any potential performance drops or system errors. Drupal’s built-in watchdog logs and your server’s error logs are critical tools for this.

Optimising Performance Post-Migration

Once the migration is complete, return to your benchmark data and conduct the same tests again. If performance has dropped in any area, take steps to address this. Your solutions might include enabling caching, optimising images, reducing the number of HTTP requests, updating or replacing inefficient modules, or refactoring custom code for better performance.

Ensuring User Experience

Remember, performance isn't just about speed. User experience, which includes factors like site navigation and layout consistency, also plays a huge role. Use heat maps, session recording tools, and user feedback to understand how changes in Drupal 10 have affected the user experience and adjust accordingly.

Involving SEO

Ensure that your website's SEO hasn't been negatively impacted by the migration. Tools like Google Search Console can alert you to any crawl errors that might have occurred due to the migration. Also, ensure that any URLs that have changed due to the migration are properly redirected to prevent 404 errors.

By keeping a close eye on performance and being ready to take corrective action, you can ensure that your Drupal 10 migration is seamless and minimises disruption to your site's performance and user experience.

 

Conclusion

In this blog post, we have navigated through the challenges and solutions of migrating to Drupal 10, covering deprecated modules, custom code, and ensuring consistent performance.

Undeniably, the migration process can seem daunting, with the potential for bumps along the way. However, with meticulous planning, problem-solving, and performance monitoring, these hurdles can be overcome. The Upgrade Status module, refactoring custom code, and constant performance tracking are essential tools in your migration toolbox.

But, it's crucial to remember that while the migration to Drupal 10 requires effort, the rewards are absolutely worthwhile. With Drupal 10, you gain a faster, more secure, and highly efficient website that is designed to provide an enhanced user experience and keep you ahead in the digital space. It also ensures that your website is on the most recent and supported version of Drupal, protecting your online presence in the long run.

So, prepare yourself, embrace the upgrade, and take your website to new heights with Drupal 10. Remember, every challenge is an opportunity in disguise. Happy migrating!

Drupal Drupal 10 Drupal Planet Drupal migration

If you’ve been following our blog, you’re likely aware of Rust’s growing presence in embedded systems. While Rust excels in safety-by-design, it’s also common to find it integrated with C++. This strategic approach leverages the strengths of both languages, including extensive C++ capabilities honed over the years in complex embedded systems. Let’s delve into some key concepts for integrating Rust and C++.

Adding Rust to C++

If you’re adding Rust to an existing C++ project, you need to start in the right place. Begin by oxidizing (that is, converting code to Rust) areas that are bug-prone, difficult to maintain, or with security vulnerabilities. These are where Rust can offer immediate improvements. Focus on modules that are self-contained, have clean interfaces, and are primarily procedural rather than object-oriented. For example, libraries that handle media or image processing can be prime candidates for rewriting in Rust as these are often vulnerable to memory safety issues. Parsers and input handling routines also stand to benefit from Rust’s guarantees of safety.

Deciding between Rusting outside-in or inside-out

As your project scales, weigh the merits of maintaining a C++ core with Rust components versus a Rust-centric application with C++ libraries. For smaller, newer projects, starting with Rust may help you avoid the complexities of dealing with C foreign function interfaces (FFIs). This decision may hinge on your safety priorities: if your project’s core tenant is safety, then a Rust-centric approach may be preferable. Conversely, if safety is needed only in certain areas of C++ project, keeping the core in C++ could be more practical.

Another consideration is how your project handles multi-threading. Mixing threading and memory ownership between Rust and C++ is very complex and prone to mistakes. Depending on how your application uses threads, this may tilt the decision in the direction of either C++ or Rust as the main “host” application.

Keeping C++ where it excels

While Rust offers many advantages, particularly in safety, C++ has its own merits that shouldn’t be hastily dismissed. The decision to rewrite should be strategic, based on actual needs rather than a pursuit of language purity since the risk of introducing new bugs through rewriting well-tested and stable C++ code outweigh the benefits of a Rust rewrite. Time-tested C++ code, particularly in areas like signal processing or cryptography, might be best left as is. Such code is often highly optimized, stable, and less prone to memory-related issues. As the saying goes, if it’s not broken, don’t “fix” it.

Navigating Rust limitations

Despite its growing ecosystem, Rust is still relatively young. Relying on packages maintained by small teams or single individuals carries inherent risks. Moreover, as Rust is still in a period of rapid language evolution, this could result in frequent updates, posing challenges for large-scale or long-lived projects. In certain scenarios, such as very large codebases, specific embedded support requirements, or projects with long development cycles, C++ may remain the more practical choice. It is wise to use C++ where stability and longevity are important, and Rust where safety is critical but some development fluidity is acceptable.

Summary

By combining the reliability of C++ with the safety of Rust, developers can engineer systems that endure while minimizing the risk of common programming pitfalls. If you’re interested in reading more about this topic, you’ll want to read our best practice guide on Rust/C++ integration, which was created in collaboration with Ferrous Systems co-founder Florian Gilcher.

About KDAB

If you like this article and want to read similar material, consider subscribing via our RSS feed.

Subscribe to KDAB TV for similar informative short video content.

KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.

The post The Smarter Way to Rust appeared first on KDAB.

Explore the latest CKEditor 5 Plugin Pack 1.1.0 and CKEditor 5 Premium Features 1.2.9 for Drupal 10.3. Enhance your content creation with new features like Templates, Auto Image, and Multi-level List. Discover seamless integration and improved editing tools.

Previously, we explored generating migrations using the Migrate Upgrade module and managing them with Migrate Plus. Today, we cover migration plugins from Drupal Core. The two main methods differ in file patterns, locations, and change detection. Learn how to organize your code effectively and customize your approach for optimal results. This article is packed with practical tips and insights to make your migration smoother and more efficient. Get ahead of the curve – read our guide and migrate with confidence!

Read more mauricio Thu, 06/27/2024 - 04:00

Review: Lyorn, by Steven Brust

Series: Vlad Taltos #17 Publisher: Tor Copyright: 2024 ISBN: 1-4668-8971-3 Format: Kindle Pages: 274

Lyorn is the 17th Vlad Taltos book and a direct sequel to 2014's Hawk. (Yes, actual main story progress!) You do not want to start reading here; you would be hopelessly confused. When this series is complete, I want to re-read the entire thing from the beginning and pick up more of the bits I missed the first time.

Vlad is not, in fact, free to see his friends and get entangled in imperial politics again as I thought after Hawk. Despite the successes of that story, there is one remaining small problem: incredibly powerful magic users still want to kill him. His immediate solution is to shelter in a theater, since Draegaran theaters are well-known for their excellent magical shielding. This works well enough at first, but the theater is rehearsing a play about Draegaran politics that is highly offensive to the Lyorn and the theater may be shut down because of it. Vlad's enemies are also willing to lean on his friends to find him and kill him.

This series continues to be thoroughly enjoyable. Lyorn is "just" more of Vlad being Vlad, meddling in everyone's business and coming up with elaborate plans with too many moving parts that he somehow manages to pull off, but I'll happily read lots of books like that. Vlad is both anxious and grumpy, both of which give the plot some needed tension without being overwhelming. There are no truly major world-building revelations here (or, if there are, I missed them), but there's a lot of processing of what the reader learned in Tsalmoth. It's increasingly looking like the payoff from those revelations is going to be the series finale.

This is the first Vlad book that contains solid confirmation of where the series as a whole is headed. Brust mentioned some time ago that the last book is titled The Last Contract, and Lyorn comes close to stating explicitly what that contract will be. I am sure that it will be more complicated than it appears now and there are misdirections yet to come, but I am excited to see where Brust takes this idea.

Vlad has been insistently apolitical for much of the series, meddling in politics only when he has to or to help his friends and otherwise treating it as a system that he has to navigate and survive. That was the root of the conflict in Teckla, all the way back at the start of the series. This may be starting to change, and when Brust ties it together with the Jenoine, the Great Weapon Godslayer, and the rest of the world-building he's cued up, the results are going to be explosive.

Two books left: Chreotha and The Last Contract. I can hardly wait.

In every Vlad book, Brust plays some sort of structural game. This time, befitting the setting, it's a musical. The action is interspersed with quotes from a fictional history about the play the theater is putting on, a work called Song of the Presses about political censorship during the reign of a Lyorn emperor in the 14th cycle, thousands of years before the time of this book. This was, at times, nearly as interesting as the main plot. The chapters are also numbered like the acts and scenes of a play, although this I didn't notice as much since books often have that structure anyway.

Since this is a musical, there are also songs. Specifically, each chapter is introduced by a parody of songs from various musicals in our world, rewritten so that they fit within Brust's fictional musical. Brust is a also musician and a filker, so these songs are actually good, or at least they amused me a great deal. I'm not much of a musical fan and I still could hear the tune playing when I read most of them.

Lyorn is not so good that I would rave about it. It's one of those functional connective books of a series that advances the plot, tells a good story, and has some fun along the way. The guns on the mantelpiece of this world have not gone off yet, and Vlad is still maneuvering into position. But it's looking like we're going to get the conclusion, and it's going to be spectacular. If you have read this far, you will want to keep reading.

Followed by Chreotha, which may be a bit of a wait because apparently Brust is going to write The Last Contract first to make sure he ties up loose ends properly.

Rating: 7 out of 10

I have just released version 0.9.9 of Shed Skin, a restricted-Python-to-C++ compiler. It comes with many changes under the hood to improve the code base. For example, Shakeeb has started adding type annotations to Shed Skin itself, whereas I have fixed many C++ compiler warnings. We have also replaced the old CPython-based dict and set implementations with STL unordered_map and unordered_set. While this may cost some performance for especially small toy programs, it really helps with maintainability.

There was also a type inference improvement, which hasn't happened in a while since it wasn't needed. It was however needed to add a cool new example called "pycsg", which shows how one can perform CSG (constructive solid geometry) using binary space partitioning (BSP). After some investigation I decided to make the type inference slightly less "optimistic", which should make it scale a lot better, at the cost of being slower overall. In the end this new example runs about 15 times faster after compilation on my system (not 15%.. 15 times!).

Most notably on the outside, Shed Skin now comes with --floatXX/--intXXX options, which allow you to specify the desired float/int precision. Unfortunately under windows, --int128 does not yet work, since C++ has not yet standardized 128-bit integers.. The relatively new othello2 and collatz examples now require --int64 and --int128, respectively, to function properly.

For the full list of changes, please see the release notes.

I would like to take this opportunity to (once again) invite others to help out in Shed Skin development. There is always enough to do, also low-hanging fruit, on both the Python and the C++ side of things. I at least think it is rather fun to work on.. :) Let me know if you'd like to contribute but aren't sure what you could bring to the table.

Of course just sending in feedback or new example programs (especially if they fail!) can be very motivating as well to keep improving things.

Authored by Nadiia Nykolaichuk.

Your Drupal website is an advanced, powerful, and intelligent system capable of performing remarkable tasks. One of them is triggering automatic actions in response to certain events, which opens a treasure trove of options to meet your needs.

Date: 2024-June-26Description: 

Following on from previous PSAs on 3rd Party code in the Drupal ecosystem:

• PSA-2011-002 - External libraries and plugins
• Various 3rd Party Vulnerabilities - PSA-2019-09-04 | Drupal.org

It is the policy of the Drupal Security Team that site owners are responsible for monitoring and maintaining the security of 3rd party libraries.

Supply chains are increasingly complex, and managing the associated risks is challenging. Website owners should actively manage their dependencies, potentially leveraging a Software Bill of Materials (SBOM) or scanner services. Other relevant tools include CSP and SRI.

Concerns around polyfill.io

The most recent case that has affected some contributed Drupal projects relates to the polyfill.io service.

Recently, a new organization acquired and updated the polyfill.io service. The new service appears to be serving malicious content from the polyfill.io endpoints under specific circumstances.

• https://thehackernews.com/2024/06/over-110000-websites-affected-by.html
• https://sansec.io/research/polyfill-supply-chain-attack
• https://github.com/polyfillpolyfill/polyfill-service/issues/2873

In response to these concerns, several trusted providers of Javascript libraries are now also serving replacements for the polyfill.io service. Website owners should update their site to incorporate a newer, more reliable source for the polyfill.io files.

• https://community.fastly.com/t/new-options-for-polyfill-io-users/2540
• https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-yo...

On the other hand, the polyfills may no longer be necessary in many cases, and it may be possible to remove them from sites rather than rely on a new source.

Multiple Drupal projects utilize this service in various ways; several of which require code changes and new releases to switch to alternative providers. As this relates to 3rd party libraries, the Drupal Security Team will not be issuing Security Advisories for these projects and work has been done in the public issue queues (note this may not be a complete list of all affected projects).

There have been significant changes in the way that 3rd party code is utilized in the Drupal ecosystem since PSA-2011-002 linked to above, but the remit of the Drupal Security Team remains limited to code hosted on drupal.org’s systems.

Reported By: 

• Heikki Ylipaavalniemi
• jpieper
• drupalam

Coordinated By: 

• Drew Webber of the Drupal Security Team
• Greg Knaddison of the Drupal Security Team
• Cathy Theys of the Drupal Security Team
• Juraj Nemec of the Drupal Security Team
• Michael Hess of the Drupal Security Team

Django 5.1 beta 1 is now available. It represents the second stage in the 5.1 release cycle and is an opportunity for you to try out the changes coming in Django 5.1.

Django 5.1 brings a kaleidoscope of improvements which you can read about in the in-development 5.1 release notes.

Only bugs in new features and regressions from earlier versions of Django will be fixed between now and the 5.1 final release. Translations will be updated following the "string freeze", which occurs when the release candidate is issued. The current release schedule calls for a release candidate in a month from now, and a final release to follow about two weeks after that, scheduled for August 7th.

Early and frequent testing from the community will help minimize the number of bugs in the release. Updates on the release schedule are available on the Django forum.

As with all alpha and beta packages, this is not for production use. But if you'd like to take some of the new features for a spin, or to help find and fix bugs (which should be reported to the issue tracker), you can grab a copy of the beta package from our downloads page or on PyPI.

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E.

Python’s unittest.mock library is a tool that helps you create mock objects to simulate complex logic and unpredictable dependencies. This helps you write valuable tests that verify your application logic is correct, reliable, and efficient.

By the end of this tutorial, you’ll be able to:

• Create Python mock objects using Mock
• Assert that you’re using objects as you intended
• Inspect usage data stored on your Python mocks
• Configure certain aspects of your Python mock objects
• Substitute your mocks for real objects using patch()
• Avoid common problems inherent in Python mocking

You’ll begin by learning about what mocking is and how you can use it to improve your tests.

Get Your Code: Click here to download the free sample code that you’ll use to learn about Python’s mock object library.

Take the Quiz: Test your knowledge with our interactive “Understanding the Python Mock Object Library” quiz. You’ll receive a score upon completion to help you track your learning progress:

Interactive Quiz

Understanding the Python Mock Object Library

In this quiz, you'll test your understanding of Python's unittest.mock library. With this knowledge, you'll be able to write robust tests, create mock objects, and ensure your code is reliable and efficient.

What Is Mocking?

A mock object substitutes and imitates a real object within a testing environment. Using mock objects is a versatile and powerful way to improve the quality of your tests. This is because by using Python mock objects, you can control your code’s behavior during testing.

For example, if your code makes HTTP requests to external services, then your tests execute predictably only so far as the services are behaving as you expected. Sometimes, a temporary change in the behavior of these external services can cause intermittent failures within your test suite.

Because of this, it would be better for you to test your code in a controlled environment. Replacing the actual request with a mock object would allow you to simulate external service outages and successful responses in a predictable way.

Sometimes, it’s difficult to test certain areas of your codebase. Such areas include except blocks and if statements that are hard to satisfy. Using Python mock objects can help you control the execution path of your code to reach these areas and improve your code coverage.

Another reason to use mock objects is to better understand how you’re using their real counterparts in your code. A Python mock object contains data about its usage that you can inspect, such as:

• If you called a method
• How you called the method
• How often you called the method

Understanding what a mock object does is the first step to learning how to use one. Next, you’ll explore the Python mock object library to see how to use Python mock objects.

The Python Mock Library

Python’s built-in mock object library is unittest.mock. It provides an easy way to introduce mocks into your tests.

Note: The standard library includes unittest.mock starting from Python 3.3 and in all newer versions. If you’re using an older version of Python, then you’ll need to install the official backport of the library.

To do so, install mock from the Python Package Index (PyPI) using pip:

Shell $ python -m pip install mock Copied!

You may want to create and activate a virtual environment before installing the package.

unittest.mock provides a class called Mock, which you’ll use to imitate real objects in your codebase. Mock, along with its subclasses, offers incredible flexibility and insightful data that will meet most of your Python mocking needs.

The library also provides a function called patch(), which replaces the real objects in your code with Mock instances. You can use patch() as either a decorator or a context manager, giving you control over the scope in which the object will be mocked. Once the designated scope exits, patch() will clean up your code by replacing the mocked objects with their original counterparts.

Finally, unittest.mock provides solutions for some of the issues inherent in mocking objects, which you’ll explore later in this tutorial.

Now that you have a better understanding of what mocking is and the library you’ll be using, it’s time to dive in and explore the features and functionalities unittest.mock has to offer.

The Mock Object

unittest.mock offers a base class for mocking objects called Mock. The use cases for Mock are practically limitless because Mock is so flexible.

Begin by instantiating a new Mock instance:

Python >>> from unittest.mock import Mock >>> mock = Mock() >>> mock <Mock id='4561344720'> Copied! Read the full article at https://realpython.com/python-mock-library/ »

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

When a new major version of Drupal is released, custom code often requires updates to align with API changes, including the removal of deprecated APIs.

Because I keep forgetting certain aspects of this workflow, I decided to document it for future reference.

Tools overview Tool Interface Functionality Target Audience Upgrade Status module UI in Drupal Identifies deprecated code, hosting environment compatibility, and more Site administrators and developers Drupal Check Command-line Identifies deprecated code Developers, especially during coding and continuous integration (CI) Upgrade Status module

The Upgrade Status module assesses a Drupal site's readiness for major version upgrades by checking for deprecated code and other compatibility issues.

Screenshot of a Drupal upgrade status report showing hosting environment compatibility checks.

1. Install the Upgrade Status module like you would install any other Drupal module:

   [code bash]$ ddev composer require –dev drupal/upgrade_status[/code]

   Here, ddev is the tool I prefer for managing my local development environment. composer is a dependency manager for PHP, commonly used to install Drupal modules. The –dev option specifies that the module should be installed as a development requirement, meaning it is necessary for development environments but not installed on production environments.

2. Enable the Upgrade Status module:

   [code bash]$ ddev drush pm-enable upgrade_status[/code]

   drush stands for "Drupal shell" and is a command-line utility for managing Drupal sites. The command pm:enable (where pm stands for "package manager") is used to enable a module in Drupal.

3. After enabling the module, you can access its features by navigating to the Admin > Reports > Upgrade status page at /admin/reports/upgrade-status.

Upgrading PHP and MySQL using DDEV

The Upgrade Status module might recommend updating PHP and MySQL, per Drupal's system requirements.

To update the PHP version of DDEV, use the following command:

[code bash]$ ddev config –-php-version 8.3[/code]

To upgrade the MySQL version of DDEV and migrate your database content, use the following command:

[code bash]$ ddev debug migrate-database mariadb:10.11[/code]

After updating these settings, I restart DDEV and run my PHPUnit tests. Although these tests are integrated into my CI/CD workflow, I also run them locally on my development machine using DDEV for immediate feedback.

Drupal Check

Drupal Check is a command-line tool that scans Drupal projects for deprecated code and compatibility issues.

I always run drupal-check before updating my Drupal site's code and third-party dependencies. This helps ensure there are no compatibility issues with the current codebase before upgrading. I also run drupal-check after the update to identify any new issues introduced by the updated code.

Output of Drupal Check command indicating no deprecated code was found.

1. Installation:

   [code bash]$ ddev composer require –dev mglaman/drupal-check[/code]

2. Run Drupal Check from the root of your Drupal installation:

   [code bash]$ ./vendor/bin/drupal-check –-memory-limit 500M docroot/modules/custom[/code]

   I usually have to increase the memory limit, hence the --memory-limit 500M.

Kirigami Addons 1.3.0 is out. Kirigami Addons is a collection of components to enhance your Kirigami/QML application. This release contains many change related to the settings module.

ConfigurationView

The current way to create a settings page in your application is to use CategorizedSettings with some SettingAction for each setting page. This was based on Kirigami.PageRow which was then either pushed on a layer on mobile or to a seperate page on desktop. This turned out to be quite unreliable in practice as Kirigami.PageRow is a visual element.

The new ConfigurationView is based on a plain non-visual QtObject with for the moment two backends:

• One for mobile which looks similar to the Plasma Settings application of Plasma Mobile.
• One for desktop which looks similar to the System Settings application of Plasma Desktop.

The API is almost the same as the previous CategorizedSettings which made porting quite easy. Here is for example a button that open the settings.

import QtQuick.Controls as Controls import org.kde.kirigamiaddons.settings as KirigamiSettings Controls.Button { id: button KirigamiSettings.ConfigurationView { id: configuration window: button.Controls.ApplicationWindow.window as Kirigami.ApplicationWindow modules: [ KirigamiSettings.ConfigurationModule { moduleId: "appearance" text: i18nc("@action:button", "Appearance") icon.name: "preferences-desktop-theme-global" page: () => Qt.createComponent("org.kde.tokodon", "AppearancePage") }, ... KirigamiSettings.ConfigurationModule { moduleId: "about" text: i18nc("@action:button", "About Tokodon") icon.name: "help-about" page: () => Qt.createComponent("org.kde.kirigamiaddons.formcard", "AboutPage") category: i18nc("@title:group", "About") } ] } icon.name: 'settings-configure-symbolic' text: i18nc("@action:button", "Settings") onClicked: configuration.open() }

With this change, both CategorizedSettings and SettingAction are now deprecated.

ConfigurationView on desktop

ConfigurationView on mobile

SpellcheckingConfigurationModule

With ConfigurationView each page is a ConfigurationModule and Kirigami Addons provides a ConfigurationModule for the spellchecking configuration of your application. This will allow to reduce code duplication between NeoChat, Tokodon, Marknote and more applications which uses Sonnet.

KirigamiSettings.ConfigurationView { modules: [ KirigamiSettings.SpellcheckingConfigurationView {} ] } FormCard

FormCard design was slighly updated and now uses shadows as you might have already noticed from the previous screenshots.

SearchPopupField

Another component which is getting deprecated in SearchPopupField, there is now a replacement for that in Kirigami with the same behavior and I added an example how to port away to Kirigami.SearchDialog and I also ported all the know usage already.

Maintainance work

Aside from this major changes, there is ongoing maintaince works. This includes:

• Removing the accidental QtWidgets on Android caused by QtLabs.ColorDialog (me: Carl Schwan)
• Ensure all translated strings are loaded from the correct translation domain (me: Carl Schwan)
• The license dialog in the AboutPage is now opened in the correct window (Jack Hill)
• Fix the focus in the FormComboBoxDelegate (Joshua Goins)
• Fix the capitalization in the AboutPage (Joshua Goins)
• Increase the padding in FormCardDialog to match the other FormCard components

Packager Section

You can find the package on download.kde.org and it has been signed with my GPG key.