Feeds
Doug Hellmann: sphinxcontrib-sqltable 2.1.1 - db cursor fix
Python Bytes: #383 Why aren’t devs shipping faster?
Taavi Väänänen: Wikimedia Hackathon Tallinn 2024
This year's Wikimedia Hackathon was held in early May in Tallinn, Estonia. Like last year, it was a great opportunity to both see people I work with regularly, including people in my own team that I had not seen in person before, and to work with and help people that I have had very limited interactions with before.
Image by Olari Pilnik is licensed under CC BY-SA 4.0.
I presented a session about Puppet (slides), the configuration management tool used on Wikimedia infrastructure (and some other projects I've been involved on) which I think went quite well. I also organized (read: picked a spot for in the schedule) the cuteness meetup.
In addition to the sessions, the main focus of the event was, of course, hacking. As usual, I didn't make any major plans beforehand, and instead ended up working on several smaller projects as they popped up.
Here is a list of things I can remember working on:
- I fixed several small issues in LibUp that makes it pass on more MediaWiki repositories (including core.git). James and I also migrated the LibUp configuration to GitLab.
- I finished up an MR to grunt-banana-checker to add support for automatically fixing some common issues that were causing LibUp failures and to fix some minor bugs.
- I worked with Piotr to get some of my patches to the OATHAuth and WebAuthn MediaWiki extensions merged. This is a part of my project to add support for more than one two-factor authentication device at a time that I was also working on during the Wikimania 2023 hackathon. Next up on this project is writing some UI code.
- I fixed Wikimedia Gerrit twice after it had some issues that needed SRE intervention.
- I sent a patch to Wikimedia's Phabricator/Phorge fork to add a new fox token. This ended up being deployed on Sunday and I got to showcase this during the hackathon showcase.
- Reedy and I implemented support for foxes in WikiLove. I also wrote a bot to spam foxes to Sammy's talk pages on the beta cluster.1 (This also involved a fun side quest to get a working thumbnail for the fox image we used to show up on Beta since the thumbnailing there is broken.)
- I removed some deprecated code from core to earn the MediaWiki track T-shirt. I also reviewed a bunch of patches by others trying to earn that T-shirt.2
- I found and reported some bugs relating to Parsoid read views on Commons.
- I processed some Toolforge account approval requests and Cloud VPS project requests. I also helped some people debug some Cloud VPS issues.
- I helped Bryan debug and fix an issue with HTTP/1.1 streams through the Toolforge front proxy.
- I made some queries on the Wiki Replicas accidentally very slow and then fixed them to be fast again on the next day.
- Got a 100% helpful, harmless, useful, etc. patch merged to something. I will provide no more details on this one.
Finally, a conversation I had at the hackathon resulted in me nominating Novem Linguae for mediawiki/* +2 access a few days after the hackathon.
I had a great time, and the ferry trip to Tallinn was much nicer than the very early flight I had last year. I can't wait to see you all again :-)
Disclosure: I am currently a Wikimedia Foundation contractor, and the Foundation did pay for my travel to Tallinn. This is my personal blog and these are my own opinions.
-
Since backporting this change felt too risky to do on the weekend, and also I have a feeling I'd get in troble if I ran an unapproved bot that edited on random wikis on our production wiki farm. ↩︎
-
Anyone who got 5 or more patches to core.git merged during the Hackathon got a cool MediaWiki T-shirt. ↩︎
Freexian Collaborators: Monthly report about Debian Long Term Support, April 2024 (by Roberto C. Sánchez)
Like each month, have a look at the work funded by Freexian’s Debian LTS offering.
Debian LTS contributorsIn April, 19 contributors have been paid to work on Debian LTS, their reports are available:
- Abhijith PA did 0.5h (out of 0.0h assigned and 14.0h from previous period), thus carrying over 13.5h to the next month.
- Adrian Bunk did 35.75h (out of 17.25h assigned and 40.5h from previous period), thus carrying over 22.0h to the next month.
- Bastien Roucariès did 25.0h (out of 25.0h assigned).
- Ben Hutchings did 24.0h (out of 9.0h assigned and 15.0h from previous period).
- Chris Lamb did 18.0h (out of 18.0h assigned).
- Daniel Leidert did 10.0h (out of 10.0h assigned).
- Emilio Pozuelo Monfort did 46.0h (out of 12.0h assigned and 34.0h from previous period).
- Guilhem Moulin did 14.75h (out of 20.0h assigned), thus carrying over 5.25h to the next month.
- Lee Garrett did 51.25h (out of 0.0h assigned and 60.0h from previous period), thus carrying over 8.75h to the next month.
- Markus Koschany did 40.0h (out of 40.0h assigned).
- Ola Lundqvist did 22.5h (out of 19.5h assigned and 4.5h from previous period), thus carrying over 1.5h to the next month.
- Roberto C. Sánchez did 11.0h (out of 9.25h assigned and 2.75h from previous period), thus carrying over 1.0h to the next month.
- Santiago Ruano Rincón did 20.0h (out of 20.0h assigned).
- Sean Whitton did 9.5h (out of 4.5h assigned and 5.5h from previous period), thus carrying over 0.5h to the next month.
- Stefano Rivera did 1.5h (out of 0.0h assigned and 10.0h from previous period), thus carrying over 8.5h to the next month.
- Sylvain Beucler did 12.5h (out of 22.75h assigned and 35.0h from previous period), thus carrying over 45.25h to the next month.
- Thorsten Alteholz did 14.0h (out of 14.0h assigned).
- Tobias Frost did 10.0h (out of 12.0h assigned), thus carrying over 2.0h to the next month.
- Utkarsh Gupta did 3.25h (out of 28.5h assigned and 29.25h from previous period), thus carrying over 54.5h to the next month.
In April, we have released 28 DLAs.
During the month of April, there was one particularly notable security update made in LTS. Guilhem Moulin prepared DLA-3782-1 for util-linux (part of the set of base packages and containing a number of important system utilities) in order to address a possible information disclosure vulnerability.
Additionally, several contributors prepared updates for oldstable (bullseye), stable (bookworm), and unstable (sid), including:
- ruby-rack: prepared for oldstable, stable, and unstable by Adrian Bunk
- wpa: prepared for oldstable, stable, and unstable by Bastien Roucariès
- zookeeper: prepared for stable by Bastien Roucariès
- libjson-smart: prepared for unstable by Bastien Roucariès
- ansible: prepared for stable and unstable, including autopkgtest fixes to increase future supportability, by Lee Garrett
- wordpress: prepared for oldstable and stable by Markus Koschany
- emacs and org-mode: prepared for oldstable and stable by Sean Whitton
- qtbase-opensource-src: prepared for oldstable and stable by Thorsten Alteholz
- libjwt: prepared for oldstable by Thorsten Alteholz
- libmicrohttpd: prepared for oldstable by Thorsten Alteholz
These fixes were in addition to corresponding updates in LTS.
Another item to highlight in this month’s report is an update to the distro-info-data database by Stefano Rivera. This update ensures that Debian buster systems have the latest available information concerning the end-of-life dates and other related information for all releases of Debian and Ubuntu.
As announced on the debian-lts-announce mailing list, it is worth to point out that we are getting close to the end of support of Debian 10 as LTS. After June 30th, no new security updates will be made available on security.debian.org.
However, Freexian and its team of paid Debian contributors will continue to maintain Debian 10 going forward for the customers of the Extended LTS offer. If you still have Debian 10 servers to keep secure, it’s time to subscribe!
Thanks to our sponsorsSponsors that joined recently are in bold.
- Platinum sponsors:
- TOSHIBA (for 104 months)
- Civil Infrastructure Platform (CIP) (for 72 months)
- Gold sponsors:
- Roche Diagnostics International AG (for 115 months)
- Linode (for 109 months)
- Babiel GmbH (for 98 months)
- Plat’Home (for 98 months)
- CINECA (for 72 months)
- University of Oxford (for 54 months)
- Deveryware (for 41 months)
- VyOS Inc (for 36 months)
- EDF SA (for 25 months)
- Silver sponsors:
- Domeneshop AS (for 119 months)
- Nantes Métropole (for 114 months)
- Univention GmbH (for 105 months)
- Université Jean Monnet de St Etienne (for 105 months)
- Ribbon Communications, Inc. (for 99 months)
- Exonet B.V. (for 89 months)
- Leibniz Rechenzentrum (for 83 months)
- Ministère de l’Europe et des Affaires Étrangères (for 67 months)
- Cloudways by DigitalOcean (for 56 months)
- Dinahosting SL (for 54 months)
- Bauer Xcel Media Deutschland KG (for 48 months)
- Platform.sh SAS (for 48 months)
- Moxa Inc. (for 42 months)
- sipgate GmbH (for 39 months)
- OVH US LLC (for 37 months)
- Tilburg University (for 37 months)
- GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 29 months)
- Soliton Systems K.K. (for 26 months)
- THINline s.r.o.
- Bronze sponsors:
- Evolix (for 120 months)
- Seznam.cz, a.s. (for 120 months)
- Intevation GmbH (for 117 months)
- Linuxhotel GmbH (for 117 months)
- Daevel SARL (for 115 months)
- Bitfolk LTD (for 114 months)
- Megaspace Internet Services GmbH (for 114 months)
- NUMLOG (for 114 months)
- Greenbone AG (for 113 months)
- WinGo AG (for 113 months)
- Ecole Centrale de Nantes - LHEEA (for 109 months)
- Entr’ouvert (for 104 months)
- Adfinis AG (for 102 months)
- GNI MEDIA (for 96 months)
- Laboratoire LEGI - UMR 5519 / CNRS (for 96 months)
- Tesorion (for 96 months)
- Bearstech (for 87 months)
- LiHAS (for 87 months)
- Catalyst IT Ltd (for 82 months)
- Supagro (for 77 months)
- Demarcq SAS (for 76 months)
- Université Grenoble Alpes (for 62 months)
- TouchWeb SAS (for 54 months)
- SPiN AG (for 51 months)
- CoreFiling (for 46 months)
- Institut des sciences cognitives Marc Jeannerod (for 41 months)
- Observatoire des Sciences de l’Univers de Grenoble (for 38 months)
- Tem Innovations GmbH (for 33 months)
- WordFinder.pro (for 32 months)
- CNRS DT INSU Résif (for 31 months)
- Alter Way (for 24 months)
- Institut Camille Jordan (for 13 months)
Matthew Palmer: "Is This Project Still Maintained?"
If you wander around a lot of open source repositories on the likes of GitHub, you’ll invariably stumble over repos that have an issue (or more than one!) with a title like the above. Sometimes sitting open and unloved, often with a comment or two from the maintainer and a bunch of “I’ll help out!” followups that never seemed to pan out. Very rarely, you’ll find one that has been closed, with a happy ending.
These issues always fascinate me, because they say a lot about what it means to “maintain” an open source project, the nature of succession (particularly in a post-Jia Tan world), and the expectations of users and the impedence mismatch between maintainers, contributors, and users. I’ve also recently been thinking about pre-empting this sort of issue, and opening my own issue that answers the question before it’s even asked.
Why These Issues Are CreatedAs both a producer and consumer of open source software, I completely understand the reasons someone might want to know whether a project is abandoned. It’s comforting to be able to believe that there’s someone “on the other end of the line”, and that if you have a problem, you can ask for help with a non-zero chance of someone answering you. There’s also a better chance that, if the maintainer is still interested in the software, that compatibility issues and at least show-stopper bugs might get fixed for you.
But often there’s more at play. There is a delusion that “maintained” open source software comes with entitlements – an expectation that your questions, bug reports, and feature requests will be attended to in some fashion.
This comes about, I think, in part because there are a lot of open source projects that are energetically supported, where generous volunteers do answer questions, fix reported bugs, and implement things that they don’t personally need, but which random Internet strangers ask for. If you’ve had that kind of user experience, it’s not surprising that you might start to expect it from all open source projects.
Of course, these wonders of cooperative collaboration are the exception, rather than the rule. In many (most?) cases, there is little practical difference between most projects that are “maintained” and those that are formally declared “unmaintained”. The contributors (or, most often, contributor – singular) are unlikely to have the time or inclination to respond to your questions in a timely and effective manner. If you find a problem with the software, you’re going to be paddling your own canoe, even if the maintainer swears that they’re still “maintaining” it.
A Thought AppearsWith this in mind, I’ve been considering how to get ahead of the problem and answer the question for the software projects I’ve put out in the world. Nothing I’ve built has anything like what you’d call a “community”; most have never seen an external PR, or even an issue. The last commit date on them might be years ago.
By most measures, almost all of my repos look “unmaintained”. Yet, they don’t feel unmaintained to me. I’m still using the code, sometimes as often as every day, and if something broke for me, I’d fix it. Anyone who needs the functionality I’ve developed can use the code, and be pretty confident that it’ll do what it says in the README.
I’m considering creating an issue in all my repos, titled “Is This Project Still Maintained?”, pinning it to the issues list, and pasting in something I’m starting to think of as “The Open Source Maintainer’s Manifesto”.
It goes something like this:
Is This Project Still Maintained?Yes. Maybe. Actually, perhaps no. Well, really, it depends on what you mean by “maintained”.
I wrote the software in this repo for my own benefit – to solve the problems I had, when I had them. While I could have kept the software to myself, I instead released it publicly, under the terms of an open licence, with the hope that it might be useful to others, but with no guarantees of any kind. Thanks to the generosity of others, it costs me literally nothing for you to use, modify, and redistribute this project, so have at it!
OK, Whatever. What About Maintenance?In one sense, this software is “maintained”, and always will be. I fix the bugs that annoy me, I upgrade dependencies when not doing so causes me problems, and I add features that I need. To the degree that any on-going development is happening, it’s because I want that development to happen.
However, if “maintained” to you means responses to questions, bug fixes, upgrades, or new features, you may be somewhat disappointed. That’s not “maintenance”, that’s “support”, and if you expect support, you’ll probably want to have a “support contract”, where we come to an agreement where you pay me money, and I help you with the things you need help with.
That Doesn’t Sound Fair!If it makes you feel better, there are several things you are entitled to:
-
The ability to use, study, modify, and redistribute the contents of this repository, under the terms stated in the applicable licence(s).
-
That any interactions you may have with myself, other contributors, and anyone else in this project’s spaces will be in line with the published Code of Conduct, and any transgressions of the Code of Conduct will be dealt with appropriately.
-
… actually, that’s it.
Things that you are not entitled to include an answer to your question, a fix for your bug, an implementation of your feature request, or a merge (or even review) of your pull request. Sometimes I may respond, either immediately or at some time long afterwards. You may luck out, and I’ll think “hmm, yeah, that’s an interesting thing” and I’ll work on it, but if I do that in any particular instance, it does not create an entitlement that I will continue to do so, or that I will ever do so again in the future.
But… I’ve Found a Huge and Terrible Bug!You have my full and complete sympathy. It’s reasonable to assume that I haven’t come across the same bug, or at least that it doesn’t bother me, otherwise I’d have fixed it for myself.
Feel free to report it, if only to warn other people that there is a huge bug they might need to avoid (possibly by not using the software at all). Well-written bug reports are great contributions, and I appreciate the effort you’ve put in, but the work that you’ve done on your bug report still doesn’t create any entitlement on me to fix it.
If you really want that bug fixed, the source is available, and the licence gives you the right to modify it as you see fit. I encourage you to dig in and fix the bug. If you don’t have the necessary skills to do so yourself, you can get someone else to fix it – everyone has the same entitlements to use, study, modify, and redistribute as you do.
You may also decide to pay me for a support contract, and get the bug fixed that way. That gets the bug fixed for everyone, and gives you the bonus warm fuzzies of contributing to the digital commons, which is always nice.
But… My PR is a Gift!If you take the time and effort to make a PR, you’re doing good work and I commend you for it. However, that doesn’t mean I’ll necessarily merge it into this repository, or even work with you to get it into a state suitable for merging.
A PR is what is often called a “gift of work”. I’ll have to make sure that, at the very least, it doesn’t make anything actively worse. That includes introducing bugs, or causing maintenance headaches in the future (which includes my getting irrationally angry at indenting, because I’m like that). Properly reviewing a PR takes me at least as much time as it would take me to write it from scratch, in almost all cases.
So, if your PR languishes, it might not be that it’s bad, or that the project is (dum dum dummmm!) “unmaintained”, but just that I don’t accept this particular gift of work at this particular time.
Don’t forget that the terms of licence include permission to redistribute modified versions of the code I’ve released. If you think your PR is all that and a bag of potato chips, fork away! I won’t be offended if you decide to release a permanent fork of this software, as long as you comply with the terms of the licence(s) involved.
(Note that I do not undertake support contracts solely to review and merge PRs; that reeks a little too much of “pay to play” for my liking)
Gee, You Sound Like an AssholeI prefer to think of myself as “forthright” and “plain-speaking”, but that brings to mind that third thing you’re entitled to: your opinion.
I’ve written this out because I feel like clarifying the reality we’re living in, in the hope that it prevents misunderstandings. If what I’ve written makes you not want to use the software I’ve written, that’s fine – you’ve probably avoided future disappointment.
Opinions SoughtWhat do you think? Too harsh? Too wishy-washy? Comment away!
ThinkDrop Consulting: Run CI/CD with preview environments anywhere with self-hosted Git runners.
GitHub Actions and BitBucket Pipelines are amazing. You can control what is run using yaml files in your codebase.
You can run just about any command, and they provide a really powerful interface for browsing jobs and logs.
Many people are unaware, you can also control where your scripts are run. If you setup a tool called a Git Runner, you can run Git Actions anywhere, including from your local machine.
ListenData: How to Use Gemini in Python
In this tutorial, you will learn how to use Google's Gemini AI model in Python.
Steps to Access Gemini APIFollow the steps below to access the Gemini API and then use it in python.
- Visit Google AI Studio website.
- Sign in using your Google account.
- Create an API key.
- Install the Google AI Python library for the Gemini API using the command below : pip install google-generativeai.
Nonprofit Drupal posts: May Drupal for Nonprofits Chat: Recapping DrupalCon and Nonprofit Summit
Join us THURSDAY, May 16 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
This month we'll be recapping DrupalCon Portland and the Nonprofit Summit!
And we'll of course also have time to discuss anything else that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
-
Join the call: https://us02web.zoom.us/j/81817469653
-
Meeting ID: 818 1746 9653
Passcode: 551681 -
One tap mobile:
+16699006833,,81817469653# US (San Jose)
+13462487799,,81817469653# US (Houston) -
Dial by your location:
+1 669 900 6833 US (San Jose)
+1 346 248 7799 US (Houston)
+1 253 215 8782 US (Tacoma)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago) -
Find your local number: https://us02web.zoom.us/u/kpV1o65N
-
- Follow along on Google Docs: https://nten.org/drupal/notes
libtool @ Savannah: libtool-2.5.0 released [alpha]
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.5.0, a alpha release.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.
There have been 91 commits by 29 people in the 113 weeks since 2.4.7.
See the NEWS below for a brief summary.
Thanks to everyone who has contributed!
The following people contributed changes to this release:
Albert Chu (1)
Alex Ameen (3)
Antonin Décimo (3)
Brad Smith (2)
Bruno Haible (2)
Dmitry Antipov (1)
Florian Weimer (1)
Gilles Gouaillardet (1)
Ileana Dumitrescu (24)
Jakub Wilk (1)
Jonathan Wakely (2)
Manoj Gupta (1)
Mike Frysinger (23)
Mingli Yu (2)
Oliver Kiddle (1)
Olly Betts (1)
Ozkan Sezer (2)
Paul Eggert (2)
Paul Green (1)
Raul E Rangel (1)
Richard Purdie (5)
Sam James (4)
Samuel Thibault (1)
Stephen Webb (1)
Tijl Coosemans (1)
Tim Rice (1)
Uwe Kleine-König (1)
Vadim Zeitlin (1)
Xiang.Lin (1)
Ileana
[on behalf of the libtool maintainers]
==================================================================
Here is the GNU libtool home page:
https://gnu.org/s/libtool/
For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.5.0
or run this command from a git-cloned libtool directory:
git shortlog v2.4.7..v2.5.0
Here are the compressed sources:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.gz (1.9MB)
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.xz (1008KB)
Here are the GPG detached signatures:
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.gz.sig
https://alpha.gnu.org/gnu/libtool/libtool-2.5.0.tar.xz.sig
Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html
Here are the SHA1 and SHA256 checksums:
fb3ab5907115b16bf12a0d3d424c79cb0003d02e libtool-2.5.0.tar.gz
1DjDF0VdhVVM4vmYvkiGb9QM/L+DTWCzAm9PwO1YPSM= libtool-2.5.0.tar.gz
70e2dd113a9460c279df01b2eee319adb99ee998 libtool-2.5.0.tar.xz
fhDMhjgj1AjsX/6kHUPDckqgiBZldXljydsL77LIecw= libtool-2.5.0.tar.xz
Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.
Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:
gpg --verify libtool-2.5.0.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa4096 2021-09-23 [SC]
FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid Ileana Dumitrescu <ileanadumi95@protonmail.com>
uid Ileana Dumitrescu <ileanadumitrescu95@gmail.com>
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg --locate-external-key ileanadumi95@protonmail.com
gpg --recv-keys 6570EA01146F7354
wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1' | gpg --import -
As a last resort to find the key, you can try the official GNU
keyring:
wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.5.0.tar.gz.sig
This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.16.5
Gnulib v0.1-6995-g29d705ead1
NEWS
- Noteworthy changes in release 2.5.0 (2024-05-13) [alpha]
** New features:
- Pass '-fdiagnostics-color', '-frecord-gcc-switches',
'-fno-sanitize*', '-Werror', and 'prefix-map' flags.
- Pass the '-no-canonical-prefixes' linker flag.
- Pass '-fopenmp=*' for Clang to allow choosing between libgomp and
libomp.
- Pass '-shared-libsan', '-static-libsan', 'rtlib=*', and
'unwindlib=*' for Clang.
- Expanded process.h inclusion on Windows for more than the
proprietary MSVC compiler. Other alternative Windows compilers
also require process.h.
- Pass 'elf32_x86_64' and 'elf64_x86_64' to the linker on hurd-amd64.
- Recognize --windows* config triplets.
** Important incompatible changes:
- Removed test_compile from command line options.
- By default executables are created with the RUNPATH property for
the Android linker. RUNPATH works for libraries which are not
installed in system locations.
- Removed AC_PROG_SED fallback, as the macro has been supported
in Autoconf since the 90's.
** Bug fixes:
- Check for space after -l, -L, and -R linker flags.
- Updated documentation for tests, the demo directory, and
elsewhere.
- Fixed Solaris 11 builds.
- Clean trailing "/" from sysroot path.
- Fixed shared library builds for System V.
- Added mingw to the list of systems not requiring libm.
- Fixed support for nios2 systems.
- Fixed linker check for '--whole-archive' support for linkers other
than ld.
- Use -Fe instead of -o with MSVC to avoid deprecation warnings.
- Improved reproducibility of libtool scripts.
- Avoided MinGW warning by adding CRTIMP.
- Improved grep portability.
- Fixed cross-building warnings when checking for file.
** Changes in supported systems or compilers:
- Removed support for bitrig (--bitrig*).
- Added support for flang (Fortran LLVM-based) compilers.
Enjoy!
Gábor Hojtsy: Drupal 11 deep dive: watch the recording, present your own (free slides!)
I presented my first ever Drupal 11 deep dive session at DrupalCon Portland 2024 last week. It turned out to not just be about Drupal 11 but also about Starshot and even about Drupal 12 thanks to the coolest future-proofing technology I announced in this talk. Unfortunately not all of the attendees fit in, that wanted to attend, as the room was standing space only and many turned around and left. But here we go!
I strongly believe in open content. I came to open source from open content 24 or so years ago. So in good tradition, I built this slide deck on slides.com in way that is easy to share and fork. You can create your own or present directly from my deck with my speaker notes. The content is licensed with a Creative Commons license. I'll keep updating this slideshow, but under different URLs, so people can catch the latest edition of this presentation at Drupal Devdays Burgas next month for example. See some of you there!
If you can't make it there or plan to present this at your organization or meetup in the meantime, check out the open source slides.
The recording from DrupalCon Portland is below. Unfortunately I was not well prepared with a subtitling set up. I am exploring good tools and will do better next time! The conference tech crew tried to help in the middle of the session, but unfortunately they could not make it work either. At least managed to discuss some current Starshot questions while that was attempted. I promised a video with subtitles, which turns out Youtube nicely delivered, so I will not create a separate recording now. Hope this helps!
Gábor Hojtsy Mon, 05/13/2024 - 21:33Talking Drupal: Talking Drupal #450 - Certification & Exam Prep
Today we are talking about Certification & Exam Prep, Resources for studying, and tips to get a passing grade with guests Chad Hester & Martin Anderson-Clutz. We’ll also cover Quiz Maker as our module of the week.
For show notes visit: www.talkingDrupal.com/450
Topics- Why are exams and certifications important to dev's
- After going through the Talking Drupal Skills Upgrade mini series do you feel preparted to take an Acquia certification
- How should someone get ready
- What are some struggles people may have getting ready
- What does the plan look like for someone getting ready
- Does Acquia provide pre tests
- Did Skills Upgrade prepare you for this type of assessment
- What happens if you do not pass
- How do you know you're ready
- Tips and tricks for taking a test
- Where do you take the test
- Questions to someone who has taken the test
- Special surprise
- Acquia Certification Study Guides
- Acquia Certification Information
- Widgets Burritos D8 Certification Study Guide
- certification@acquia.com for questions
- Chad Hester - chadkhester.com chadhester
- Martin Anderson-Clutz - mandclu.com mandclu
Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Matthew Grasmick - grasmash
MOTW CorrespondentMartin Anderson-Clutz - mandclu
- Brief description:
- Have you ever wanted to build and deliver interactive quizzes on your Drupal website?
- Module name/project name:
- Brief history
- How old: created in Apr 2024 (the last couple of weeks) by Roman Chekhaniuk (r_cheh)
- Versions available: 1.0.5, which works with Drupal 9, 10, and 11
- Maintainership
- Actively maintained
- Not yet opted into Security coverage, but being so new it’s possible they started the process of getting the project reviewed
- Number of open issues: 0
- Usage stats:
- Not currently installed on any sites yet, according to Drupal.org
- Module features and usage
- The module defines a number of of custom entities to allow your site to define very flexible quizzes, that can include options like the amount of time allowed, pass rate, maximum number of attempts, randomizing the sequence of the questions, and more
- The module also defines custom plugins for questions, responses, and answers, so you can extend it to handle very custom use cases
- The Quiz module is very popular in this space but the version you can use with modern versions of Drupal is still in alpha, so it’s great to see another option available, especially for sites that don’t need anything as complex as the Opigno LMS
Introducing the Formatting plugin
So this is not quite an introduction since the plugin has been around for almost a year now, having been released in the 23.04 release but since I never got around to writing a blog about it, here I am.
In simple words, the formatting plugin allows one to format code easily and quickly. Well the "quickness" depends on the underlying code formatter but we try to be as quick as possible. So far if you wanted to do code formatting from within Kate, the only way to do that was to configure a tool in the External Tools plugin and then invoke it whenever you wanted to format the code. While this works it wasn't great for a few reasons. Firstly, you would loose undo history. Secondly, the buffer would jump and you would most likely loose your current position in the document. Thirdly, for every language you get a different tool and you need to remember the right tool to invoke on the right document type.
To simplify this, I decided to write a plugin that would expose a minimal UI but still provide a lot of features.
There are basically two ways to use this plugin:
- Manually using the "Format Document" action.
- Automatically on save
The correct formatter is invoked based on the document type in all cases. Additionally the plugin will preserve the document's undo history and user's cursor position when formatting the code so that the formatting of code doesn't disrupt user's workflow. This is especially important for automatic formatting on save.
Supported languages:The current list of supported languages and formatters are as follows:
- C/C++/ObjectiveC/ObjectiveC++/Protobuf
- clang-format
- Javascript/Typescript/JSX/TSX
- Prettier
- Json
- clang-format
- Prettier
- jq
- Dart
- dartfmt
- Rust
- rustfmt
- XML
- xmllint
- Go
- gofmt
- Zig
- zigfmt
- CMake
- cmake-format
- Pythong
- autopep8
- ruff
The plugin can be configured in two ways:
- Globally, from the Configure dialog
- On a per project basis using the .kateproject file
When reading the config, the plugin will first try to read the config from .kateproject file and then read the global config.
Example:
{ "formatOnSave": true, "formatterForJson": "jq", "cmake-format": { "formatOnSave": false }, "autopep8": { "formatOnSave": false } }The above
- enables "format on save" globally
- specifies "jq" as the formatter for JSON
- disables "format on save" for cmake-format and autopep8
To configure formatting for a project, first create a .kateproject file and then add a "formatting" object to it. In the "formatting" object you can specify your settings as shown in the previous example. Example:
{ "name": "My Cool Project", "files": [ { "git": 1 } ], "formatting": { "formatterForJson": "clang-format", "autopep8": { "formatOnSave": false } } }Tryton News: Release 1.5.0 of python-sql
We are proud to announce the release of the version 1.5.0 of python-sql.
python-sql is a library to write SQL queries in a pythonic way. It is mainly developed for Tryton but it has no external dependencies and is agnostic to any framework or SQL database.
In addition to bug-fixes, this release contains the following improvements:
- Add MERGE query
- Support “UPSERT” with ON CONFLICT clause on INSERT query
- Remove default escape char on LIKE and ILIKE
- Add GROUPING SETS, CUBE, and ROLLUP clauses for GROUP BY.
python-sql is available on PyPI: python-sql 1.5.0.
2 posts - 2 participants
Redfin Solutions: DrupalCon Portland: A Recap from Redfin CTO, Chris Wells
Mike Driscoll: How to Annotate a Graph with Matplotlib and Python
The Matplotlib package is great for visualizing data. One of its many features is the ability to annotate points on your graph. You can use annotations to explain why a particular data point is significant or interesting.
If you haven’t used Matplotlib before, you should check out my introductory article, Matplotlib – An Intro to Creating Graphs with Python or read the official documentation.
Let’s get started!
Installing MatplotlibIf you don’t have Matplotlib on your computer, you must install it. Fortunately, you can use pip, the Python package manager utility that comes with Python.
Open up your terminal or command prompt and run the following command:
python -m pip install matplotlibPip will now install Matplotlib and any dependencies that Matplotlib needs to work properly. Assuming that Matplotlib installs successfully, you are good to go!
Annotating Points on a GraphMatplotlib comes with a handy annotate()method that you can use. As with most of Matplotlib’s methods, annotate()can take quite a few different parameters.
For this example, you will be using the following parameters:
- text – The label for the annotation
- xy – The x/y coordinate of the point of interest
- arrowprops – A dictionary of arrow properties
- xytext – Where to place the text for the annotation
Now that you know what you’re doing, open up your favorite Python IDE or text editor and create a new Python file. Then enter the following code:
import matplotlib.pylab as plt import numpy as np def annotated(): fig = plt.figure(figsize=(8, 6)) numbers = list(range(10)) plt.plot(numbers, np.exp(numbers)) plt.title("Annotating an Exponential Plot using plt.annotate()") plt.xlabel("x-axis") plt.ylabel("y-axis") plt.annotate("Point 1", xy=(6, 400), arrowprops=dict(arrowstyle="->"), xytext=(4, 600)) plt.annotate("Point 2", xy=(7, 1150), arrowprops=dict(arrowstyle="->", connectionstyle="arc3,rad=-.2"), xytext=(4.5, 2000)) plt.annotate("Point 3", xy=(8, 3000), arrowprops=dict(arrowstyle="->", connectionstyle="angle,angleA=90,angleB=0"), xytext=(8.5, 2200)) plt.show() if __name__ == "__main__": annotated()Here, you are creating a simple line graph. You want to annotate three points on the graph. The arrowprops define the arrowstyleand, in the latter two points, the connectionstyle. These properties tell Matplotlib what type of arrow to use and whether it should be connected to the text as a straight line, an arc, or a 90-degree turn.
When you run this code, you will see the following graph:
You can see how the different points are located and how the arrowprops lines are changed. You should check out the full documentation to learn all the details about the arrows and annotations.
Wrapping UpAnnotating your graph is a great way to make your plots more informative. Matplotlib allows you to add many different labels to your plots, and annotating the interesting data points is quite nice.
You should spend some time experimenting with annotations and learning all the different parameters it takes to fully understand this useful feature.
The post How to Annotate a Graph with Matplotlib and Python appeared first on Mouse Vs Python.
The Drop Times: Reflecting on DrupalCon Portland: A Note of Appreciation to Our Volunteers
mark.ie: Does your agency want to contribute more to Drupal?
Lots of agencies want to contribute more to Drupal, but don't have the time due to client work. Let's fix that.
Real Python: What Is the __pycache__ Folder in Python?
When you develop a self-contained Python script, you might not notice anything unusual about your directory structure. However, as soon as your project becomes more complex, you’ll often decide to extract parts of the functionality into additional modules or packages. That’s when you may start to see a __pycache__ folder appearing out of nowhere next to your source files in seemingly random places:
project/ │ ├── mathematics/ │ │ │ ├── __pycache__/ │ │ │ ├── arithmetic/ │ │ ├── __init__.py │ │ ├── add.py │ │ └── sub.py │ │ │ ├── geometry/ │ │ │ │ │ ├── __pycache__/ │ │ │ │ │ ├── __init__.py │ │ └── shapes.py │ │ │ └── __init__.py │ └── calculator.pyNotice that the __pycache__ folder can be present at different levels in your project’s directory tree when you have multiple subpackages nested in one another. At the same time, other packages or folders with your Python source files may not contain this mysterious cache directory.
Note: To maintain a cleaner workspace, many Python IDEs and code editors are configured out-of-the-box to hide the __pycache__ folders from you, even if those folders exist on your file system.
You may encounter a similar situation after you clone a remote Git repository with a Python project and run the underlying code. So, what causes the __pycache__ folder to appear, and for what purpose?
Get Your Code: Click here to download the free sample code that shows you how to work with the pycache folder in Python.
Take the Quiz: Test your knowledge with our interactive “What Is the __pycache__ Folder in Python?” quiz. You’ll receive a score upon completion to help you track your learning progress:
Interactive Quiz
What Is the __pycache__ Folder in Python?In this quiz, you'll have the opportunity to test your knowledge of the __pycache__ folder, including when, where, and why Python creates these folders.
In Short: It Makes Importing Python Modules FasterEven though Python is an interpreted programming language, its interpreter doesn’t operate directly on your Python code, which would be very slow. Instead, when you run a Python script or import a Python module, the interpreter compiles your high-level Python source code into bytecode, which is an intermediate binary representation of the code.
This bytecode enables the interpreter to skip recurring steps, such as lexing and parsing the code into an abstract syntax tree and validating its correctness every time you run the same program. As long as the underlying source code hasn’t changed, Python can reuse the intermediate representation, which is immediately ready for execution. This saves time, speeding up your script’s startup time.
Remember that while loading the compiled bytecode from __pycache__ makes Python modules import faster, it doesn’t affect their execution speed!
Bytecode vs Machine CodeShow/Hide
Why bother with bytecode at all instead of compiling the code straight to the low-level machine code? While machine code is what executes on the hardware, providing the ultimate performance, it’s not as portable or quick to produce as bytecode.
Machine code is a set of binary instructions understood by your specific CPU architecture, wrapped in a container format like EXE, ELF, or Mach-O, depending on the operating system. In contrast, bytecode provides a platform-independent abstraction layer and is typically quicker to compile.
Python uses local __pycache__ folders to store the compiled bytecode of imported modules in your project. On subsequent runs, the interpreter will try to load precompiled versions of modules from these folders, provided they’re up-to-date with the corresponding source files. Note that this caching mechanism only gets triggered for modules you import in your code rather than executing as scripts in the terminal.
In addition to this on-disk bytecode caching, Python keeps an in-memory cache of modules, which you can access through the sys.modules dictionary. It ensures that when you import the same module multiple times from different places within your program, Python will use the already imported module without needing to reload or recompile it. Both mechanisms work together to reduce the overhead of importing Python modules.
Next, you’re going to find out exactly how much faster Python loads the cached bytecode as opposed to compiling the source code on the fly when you import a module.
How Much Faster Is Loading Modules From Cache?The caching happens behind the scenes and usually goes unnoticed since Python is quite rapid at compiling the bytecode. Besides, unless you often run short-lived Python scripts, the compilation step remains insignificant when compared to the total execution time. That said, without caching, the overhead associated with bytecode compilation could add up if you had lots of modules and imported them many times over.
To measure the difference in import time between a cached and uncached module, you can pass the -X importtime option to the python command or set the equivalent PYTHONPROFILEIMPORTTIME environment variable. When this option is enabled, Python will display a table summarizing how long it took to import each module, including the cumulative time in case a module depends on other modules.
Suppose you had a calculator.py script that imports and calls a utility function from a local arithmetic.py module:
Python calculator.py from arithmetic import add add(3, 4) Copied!The imported module defines a single function:
Python arithmetic.py def add(a, b): return a + b Copied!As you can see, the main script delegates the addition of two numbers, three and four, to the add() function imported from the arithmetic module.
Note: Even though you use the from ... import syntax, which only brings the specified symbol into your current namespace, Python reads and compiles the entire module anyway. Moreover, unused imports would also trigger the compilation.
The first time you run your script, Python compiles and saves the bytecode of the module you imported into a local __pycache__ folder. If such a folder doesn’t already exist, then Python automatically creates one before moving on. Now, when you execute your script again, Python should find and load the cached bytecode as long as you didn’t alter the associated source code.
Read the full article at https://realpython.com/python-pycache/ »[ 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 ]
KDE Goals April 2024 sprint
A few weeks ago I attended the KDE Goals April 2024 sprint
I was there as part of the Automation & Systematization sprint given my involvement in the release process, the "not very automatized" weekly emails about the status of CI about KDE Gear and KDE Frameworks, etc. but I think that maybe I was there more as "person that has been around a long time, ask me if you have questions about things that are documented through oral tradition"
I didn't end up doing lots of work on sprint topics themselves (though I participated in various discussions, did a bit of pair-programming with Aleix on QML accessibility issues, inspired DavidR to do the QML-text-missing-i18n check that he describes in his blog); instead I cheated a bit and used the sprint to focus on some of the KDE stuff I had a bit on my backlog, creating the KDE Gear release/24.05 branches and lots of MR reviewing and more!
Thanks KDE e.V. for sponsoring the trip, if you would like such events to continue please we need your continued donations
And remember Akademy talk submission period ends in 10 days, send your talk now!
Pages
Recent Publications
- Managing Hidden Dependencies in OO Software: a Study Based on Open Source Projects
- Open Source Communities as Liminal Ecosystems
- Investigating developers' email discussions during decision-making in Python language evolution
- Developers, Quality Control and Download Volume in Open Source Software (OSS) Projects
More...