mailto: blog -at- heyrick -dot- eu

Canicule

While this part of France has not missed the drought - everything looks so dry and half dead - we do appear to have been spared the worst of the heatwave, though for a somewhat odd reason. That reason is that the sky is a murky colour that gives the light a distinctly orange hue.
A photo with a weird looking sky.
Such a peculiar sky.
I don't know if this is because of dust particles in the air, smoke particles, dandruff from decomposing zombies, or just everybody farting as they enjoy their special summer meals. Whatever, AccuWeather says the air quality is fair, and I'm looking at that sky and thinking "you sure about that?".
It is also supposed to be 34°C but it is only 31°C along with a fairly stiff breeze, which no doubt is whipping up even more dust from the recently ploughed fields.

You can also see in the photo above that the weeping willow is struggling with the heat and lack of water.

Another photo with a weird looking sky.
Are we about to enter the Upside Down?

 

RISC OS load/run actions

I noticed a post on the ROOL forum today. It said at the end:
If you can "double click" on a BASIC file, the OS, based on an embedded pragma or filetype, should choose the right BASIC interpreter with the requested options (some mandatory; e.g. Unicode).

This is entirely the wrong way to handle this situation. It will require either some nasty collusion within FileSwitch to be able to recognise and understand tokenised BASIC to parse out the options, or some sort of mechanism to hand the program to BASIC prior to running it in order to do the same thing, which requires the different versions of BASIC to know about each other or some ugly collusion to pass the option around to see what will handle it.
All of which is wholly unnecessary because a method for handling this has existed since 1987.

When you double-click a BASIC file, the default run action is executed, which will load the program into regular BASIC. If you want something special, put it into an application directory and perform the special setup required within the application's !Run file.
For example, !SciCalc needs the extra precision of BASIC64, so the !Run file checks for the presence of BASIC64, and then passes the program to BASIC64 thus overriding the standard load-this-in-normal-BASIC behaviour.

That is how this sort of thing should be handled. If it is to be desired to implement all of the different versions of BASIC in one executable, it should be a command line parameter.

 

ESP32-Cam fault

I have recently installed the ESP32 toolkit into the Arduino IDE. It's Arduino IDE version 1.8.19 because that's the one Mint's repository offers, and ESP version 3.3.0 which was the latest.

I noticed that I needed to knock back the quality on larger images when playing with the negative scanner, and in doing some testing today with the camera outputting to the serial port, I saw this appearing on the serial terminal:

Starting up
This firmware built at 14:32:49 on Aug 13 2025
Allocating PSRAM buffer.
Initialising camera
PSRAM size is 2097152, image buffer is 768032.
WiFi connecting, to AP Livebox-XXXX......
WiFi connected, starting server
Camera Ready! Use 'http://192.168.1.24' to connect
E (60978) cam_hal: DMA overflow
E (61077) cam_hal: DMA overflow
E (61177) cam_hal: DMA overflow
Capture requested
E (61276) cam_hal: DMA overflow
E (61375) cam_hal: DMA overflow
E (61475) cam_hal: DMA overflow
E (61575) cam_hal: DMA overflow
E (61675) cam_hal: DMA overflow
E (61774) cam_hal: DMA overflow
E (61874) cam_hal: DMA overflow
E (61974) cam_hal: DMA overflow
E (62074) cam_hal: DMA overflow
E (62175) cam_hal: DMA overflow
E (62274) cam_hal: DMA overflow
E (62374) cam_hal: DMA overflow
E (62474) cam_hal: DMA overflow
Sent image of 88996 bytes
E (62574) cam_hal: DMA overflow
E (62674) cam_hal: DMA overflow
E (62774) cam_hal: DMA overflow
E (62874) cam_hal: DMA overflow

What this is telling me is that my PSRAM (fast memory separate from the microcontroller) is 2MiB in size, and that 768,032 bytes has been allocated for images from the camera. I think it might currently be two buffers, but that'll be about 375KiB per image. It used to work, I could set the full 1600×1200 image size and push the quality right up (though, to be honest, given the rather antiquated camera technology, beyond a certain point it just made larger images with no noticeable increase in visual quality).
Now it doesn't work.

In fact, I need to drop the quality quite a bit to get useful images from the device.

With the serial logging enabled, it looks like it fails and throws DMA overflow errors when the image would be larger than around 92KiB or so.

Even worse, pushing the quality to the max would sometimes cause this to happen.

Guru Meditation Error: Core  0 panic'ed (Unhandled debug exception). 
Debug exception reason: Stack canary watchpoint triggered (cam_task) 
Core  0 register dump:
PC      : 0x4008e31a  PS      : 0x00060b36  A0      : 0x80092658  A1      : 0x3ffb2550
A2      : 0x3ffb0300  A3      : 0xffffffff  A4      : 0xb33fffff  A5      : 0x3f434604
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x00060b23  A9      : 0x3ffb2550  
A10     : 0x00000003  A11     : 0x00060b23  A12     : 0x00060b23  A13     : 0x0000001f  
A14     : 0x3ffb2ab0  A15     : 0xff000000  SAR     : 0x00000004  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x4008aaf1  LEND    : 0x4008ab01  LCOUNT  : 0xfffffffe  


Backtrace: 0x4008e317:0x3ffb2550 0x40092655:0x3ffb2580 0x4009268a:0x3ffb25a0
0x40092800:0x3ffb25c0 0x400830df:0x3ffb25e0 0x400830f9:0x3ffb2610 0x40082d75:0x3ffb2630
0x4008e804:0x3ffb2650 0x4008d895:0x3ffb2670 0x4008db0c:0x3ffb2690 0x4008375e:0x3ffb26b0
0x400837a6:0x3ffb26d0 0x40083909:0x3ffb2700 0x400e2b39:0x3ffb2720 0x400e7105:0x3ffb2750
0x4000bd83:0x3ffb2770 0x4000182a:0x3ffb2790 0x400e67ad:0x3ffb27b0 0x400e7105:0x3ffb27d0
0x4008a7aa:0x3ffb27f0 0x40089c4d:0x3ffb2810 0x40089c9e:0x3ffb2830 0x4008a19d:0x3ffb2850
0x40175b5f:0x3ffb2880 0x40175576:0x3ffb28a0 0x4016c29d:0x3ffb2bc0 0x400938d5:0x3ffb2bf0
0x40119e49:0x3ffb2c50 0x4008e1f5:0x3ffb2ca0

A bit of DuckDuckGo later, and it turns out that there was a bug introduced in the library. I guess I'm going to have to either revert to 3.2.0 or wait for a new release, and then tidy up the mess of installing that. 🤦

 

The Arduino IDE sucks

It is so slow.

With Java set to run at high priority (the next step above normal), opening the Library manager takes about three minutes (2:53) before anything appears (I wonder if it's because it is downloading a list of libraries from a slow server?) and a further two minutes before the dialogue is available for use.
Switch to write this, and go back, it'll be frozen for about two and a half minutes (2:33). Search for something, it'll take just under two minutes (1:47) to show results. And since it doesn't seem to understand the idea of temporal caching, if you close the window and reopen it, you'll have to wait as the entire process repeats.

The idea of having all of the sources loaded at the same time in different tabs. This might make sense with small projects, but the camera server alone uses four tabs so I can see larger projects getting out of control. And removing a tab removes the code from the project...

Speaking of which, shall we talk about the farcical file extensions? The lead file is .ino, you might come across code in a .cpp file, but you're just as likely to find it in a .h one.

I'm not sure what's going on under the hood, but being able to 'see' symbols and variables declared in other bits of code is peculiar. Then again, the language used seems peculiar - it's mostly, but not quite, C++.

I've found how to change the tab width to 3 characters, you need to edit the preferences file directly. You're out of luck when it comes to the colours used, they're fixed. This is especially egregious for those of us who prefer coding on a dark screen.

It is worth noting that when I performed the above tests, Java (which underpins the Arduino IDE) was hitting a fairly constant 25% processor utilisation. What this means is that it doesn't support threads and so was just maxing out one of the cores.

 

htop

In working out what was going on with the Arduino IDE taking so long, I came across the htop command. It might need to be installed first - sudo apt install htop thing will do it.

Screenshot of htop running.
htop is a far better top.

Not only do you get a much more detailed look at what's going on inside, you can fiddle with the processes, though clearly this is power user stuff...but then this has been created for power users, who else would care or understand what this is saying?

 

Tuning the swap file

I don't run heavy duty applications on this machine. Most of the extravagant memory (ab)use is Firefox. So I have added two lines to the file /etc/sysctl.conf (must be done as root) to adjust the swap file behaviour.

vm.swappiness=1
vm.vfs_cache_pressure=50

The first line controls the "swappiness", that is to say, how eager Linux is to swap out applications to virtual memory. Since I am not a power user and my primary device is an SSD, I have adjusted the preference right down to "only when necessary". The default is sixty, and a hundred means "behave like Windows and swap all the damn time". ☺

Note that this is a perceptual thing. If you are short of memory then something has to be swapped out. So your choice is:

  • Click on a button, nothing appears to happen for a moment as the relevant code for that application is brought out of the swap and executed.
  • Click on a button, you can see it being actioned but it will take a little longer as the necessary data is pulled out of the swap into memory.
What our swappiness does is to tell Linux to strongly favour the second option. You want applications to be responsive, and for them to be responsive, you don't want them being passed off to swap.

For a normal user, you may find dropping the value to something around 10-15 improves perceptual performance as it'll keep processes (that is to say, application code) in memory for longer. Plus a lower value means that large file operations won't cause the kernel to toss everything into swap to make space for the file cache. Sure, the copy will take longer, but on the other hand, with the normal setting, every application that got booted would stall when you first try to use it as it gets retrieved from swap, and that is what makes a system feel slow.
Windows doesn't provide an easy (or any?) means to control how the swapping works. So I'm sure we've all clicked a button and nothing happens, clicked it again, nothing, clicked it a third time and suddenly the action happens three times and it's a mess. This is a natural consequence of pushing programs to swap. When they're wanted, they must be reloaded, and there is no magic to make them "do stuff" until they have been reloaded.

Note that this does not disable swapping until memory is full. It balances the degree of swapping between memory pages used applications and internal caching.
If you want to disable swapping entirely, you can use sudo swapoff -a, but note that without a swap when you're out of memory you're out of memory and, well, that's when bad things happen. sudo swapon -a turns it back on again and unless you're overly paranoid about emptying your swap for some reason, it's probably best to just not touch this. It's not a beer glass, leave it alone!

The second line... there is a lot of internal caching in Linux, I'm not going to go into details but look up "dentries" and "inode cache". This helps the system work better as, say, file metadata for a directory you're looking at is cached so can be pulled from memory in the future rather than having to read the directory from the filesystem over and over. Also buffers for files that are being loaded. That's very simplified, but you get the idea.
Anyway, the second line balances how the kernel chooses which cache to throw away. A cache pressure of 50 (default is 100) strongly favours the inode/dentry (filsystem) cache over the other caches.
You don't want to drop this too low as Linux follows the "everything is a file" philosophy of UNIX, so too low a value and strongly hurt filesystem performance.

 

Full moon

A few days ago, the 9th of August, was the full moon. As my sleep schedule is such a mess, I went out at 5am and took some photos. Fed Anna, made a tea, went back to bed until... late. ☺

Looking towards the East from the East. The bright dot is Venus. The less bright dot is Jupiter. I think the dot at the top is Capella but I'm too lazy to go look it up.

Looking east at the night sky.
This is a long exposure, it's not this light.

Looking towards the West. The bright dot just above the roof is Vega, and tucked into the open gap in the pine is Altair. The streak, some SpaceX junk?

Looking west at the night sky.
Back to chiaroscuro.

Looking Southwest. The bright dot is a distant thermonuclear explosion. Oh well, sucks to live in Nantes, I guess...

Looking southwest at the night sky.
¿Soy Luna? ¡No, tú eres Luna!

Now looking East-northeast from the West. You can see Jupiter, Venus, Capella (maybe), and up at the top right the bright star is Aldebaran. If you look carefully, there's another bright dot nestling down by the trees on the right. That's Bellatrix, one of the stars at the top of Orion (basically the one that isn't Beetlejuice Betelgeuse).

Looking ENE at the night sky.
Yes, Orion is returning to the night sky.

And, finally, this one I took at 11pm, six hours earlier. It clearly shows the mothership hovering behind the trees.

Looking at the full moon from behind trees.
Take me to your larder, I'll see your leader later.

 

Two weeks down

Two weeks done, one week to go. What have I done? Well, thanks to the heat, not a lot really. The grass got cut, and I did (mostly) hack back the bit of bramble that I had planned to. I had intended to do more but, well, that didn't happen.
I did a little bit of stuff inside, but not that much.

I have given Windows the boot and fully adopted Linux. That has taken a fair bit of time and whilst I'm a little depressed-emoji about parking my arse in front of a computer, it has largely been too hot to do much heavy lifting outside, and when I sat out with my ebook, I had to give it up sharpish as the heat made the eink fade too much to be readable. A spell in the fridge brought back the contrast, but it's something that afflicted older generations of eink.

Then there's the learning curve. A lot of Linux stuff meant looking up solutions in multiple sources, primarily to avoid being caught out by something out of date again. And, well, I played with LibreOffice Draw for a few hours, didn't really get anywhere, then went back to RISC OS via VNC and knocked this up in about ten minutes.

A crudely drawn diagram.
NiMH charge pattern diagram
from a few days back.

Granted, it's a question of familiarity, but it's still time.

Oh, and I watched this.

A screenshot from Wednesday.
Oh my god, fangirls...
© Copyright 2025 Netflix.

And this...some three years later...

A screenshot from The Witcher.
I wonder how many takes this required.
© Copyright 2021 Netflix.

Finally got around to the second season. I hear the third season made the grunting hero say "to hell with this" and leave. So, um...
On the other hand, I'm not familiar with the books so I don't get to scream "you changed it now it sucks!" at the screen.
After a bit of DDGing, I was able to find a map that I could throw at the printer so I'd know how all of these places relate to each other.

 

I have just received an email from FDJ informing me of my Euromillions jackpot - all €6,10 of it.
I take this to mean that I won't be retiring just yet...

 

 

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺
As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP.
It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.

 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

No comments yet...

Add a comment (v0.12) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 95380 backwards.
UK resident
Your comment
French flagSpanish flagJapanese flag
Calendar
«   August 2025   »
MonTueWedThuFriSatSun
    13
459
12131415
20
2526272829

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index

Geekery
 
Alphabetical:

Search

Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.

Etc...

Last read at 20:10 on 2025/12/06.

QR code


Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0

 

© 2025 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.

 

Have you noticed the watermarks on pictures?
Next entry - 2025/08/17
Return to top of page