One of the Facebook groups I’m part of is Sony a7iii/a7riii setup Tips. It’s a relatively quiet group but it’s chock full of great tips for Sony’s latest cameras. One of those tips was posted yesterday and Daniel Ockeloen, the group administrator, made a video of it which I have embedded above.
In manual mode, the AEL button can be used to maintain the exposure while you change settings. With AEL activated changing the shutter speed will change the aperture and vice versa. In effect it’s the same as going back to Aperture or Shutter Priority modes but it does allow more flexibility since AEL can be deactivated and you get full manual control again, with the same exposure.
Sometimes you accidentally dive down a rabbit hole of your own making. I came across the Retro Computer Scene search engine a few days ago and accidentally clicked on a link to a Commodore 64 disk image. Those files are small at 175KB so I decided to keep it and look at it later.
This morning I did and found Noice Driver v3.0a, a music disk for the Commodore 64 released in 1993. There are some great tunes on there but the name JEDININJA leapt out at me. It’s a good tune too!
The filename of the disk image is sb130978-1fbef9.d64 so I guessed it might have something to do with Scene Base. I downloaded their metadata list and found it there in the c64disk set!
Since MacOS High Sierra has been out for a long time this is probably old news to the tiny minority using coreutils. When you upgrade you might find that “df” and other commands don’t work properly.
Every time I opened a terminal after upgrading I saw errors saying commands had been aborted. When I ran “df” it would abort immediately.
I thought the upgrade had damaged my filesystem, especially since it introduced APFS. I ran “First Aid” in Disk Utility several times, both live and in recovery.
It then occurred to me to try the MacOS df in /bin/. It worked!
Coreutils is the package that includes lots of command line tools like “df”. I installed it using brew so the following fixed the problem:
brew reinstall coreutils
I noticed it put everything in /usr/local where my original commands were in /opt/ so changing the PATH in my .zshrc was necessary too. Everything was back to normal again! 🙂
EDIT: Some other commands were messed up. “find” had changed, but then I realised it probably isn’t in coreutils and I was using the MacOS version. This page led me to the right package names and the following command line:
Listening to it in a Youtube video doesn’t have quite the same impact. It cuts off a bit too early as well. Perhaps rose tinted glasses and all that? It does bring back memories of typing “left arrow” L to load games from a tape and “Turbo Tape by Jeff”, the tape loader used to pack more games on to one cassette. Piracy was rife on the C64, but I still have a box of (original) game cassettes and disks in the attic.
Vice, the Commodore 64 emulator is a cross platform emulator that works on Windows, Linux, MacOS and other operating systems. It also allows you to emulate the Vic 20, C128 and other early Commodore machines.
Double clicking on a Commodore d64 disk image file will load x64, the Commodore 64 emulator and load the first programme on the disk image.
Quite often I want to look at a D64 image directory listing instead of running the first programme on the disk.
You can do this by unchecking the “autostart” box on the file open box of course but it’s not as convenient.
So, last Friday I asked on Twitter if it was possible to drag and drop a D64 image onto Vice to display the disk contents. Logiker replied and helped me by DM to handle double clicking on a C64 disk image.
#c64 fans. Is there any way to drag/drop a d64 image onto Vice so it does NOT autostart with LOAD "*",8,1 ? I'd much rather a directory listing most of the time. I know about the autostart checkbox in the file dialog.
What I needed to do was load the disk image and then feed the directory listing command to the C64.
Getting MacOS to accept the command line was harder to achieve. In Windows you can change the start up parameters for a programme. In MacOS it should be possible to modify the emulator “package” with a script that calls the real executable but I couldn’t get that working. In Linux I would have just created a shell script that called the emulator. 🙂
What did work in MacOS was using Automator. I created a “Run Shell Script” action and filled it in with the following. If you want to follow along at home you’ll have to change the path to x64.
I saved that as a new app in ~/bin/ called “Vice64”, and associated all D64 images with that application. Now double clicking on a disk image shows me a directory listing!
It doesn’t work unfortunately when I have an Action Replay cartridge loaded. Maybe I need to add F3 or F7 to the keyboard buffer?
One of the advantages of looking at the directory structure is the directory art some demos have. Here’s one from Pearls for Pigs, a D64 I happened to use while testing this but there are loads of them. I saw that Logiker has a page dedicated to directory art!
WP Super Cache is a full page caching plugin for WordPress. When a page is cached almost all of WordPress is skipped and the page is sent to the browser with the minimum amount of code executed. This makes the page load much faster.
1.6.3 is the latest release and is mostly a bugfix release but it also adds some new features.
This release makes it much easier for plugin developers to interact with WP Super Cache. In the past a file had to be placed in the “WP Super Cache plugins directory” so that it would be loaded correctly but in this release I’ve added new actions that will allow you to load code from other directories too.
Use the wpsc_add_plugin action to add your plugin to a list loaded by WP Super Cache. Use it like this:
You can give it the full path, with or without ABSPATH. Use it after “init”. It only needs to be called once, but duplicates will not be stored.
In a similar fashion, use wpsc_delete_plugin to remove a plugin.
The release also makes it much simpler to modify the cookies used by WP Super Cache to identify “known users”. This is useful to identify particular types of pages such as translated pages that should only be shown to certain users. For example, visitors who have the English cookie will be shown cached pages in English. The German cookie will fetch German cached pages. The action wpsc_add_cookie makes this possible.
do_action( 'wpsc_add_cookie', 'language' );
Execute that in your plugin and WP Super Cache will watch out for the language cookie. The plugin will use the cookie name and value in determining what cached page to display. So “language = irish” will show a different page to “language = french”.
Use wpsc_delete_cookie to remove a cookie. Cache files won’t be deleted. It’s doubtful they’d be served however because of the hashed key used to name the filenames.
do_action( 'wpsc_delete_cookie', 'language' );
If you’re going to use either of the plugin or cookie actions here I recommend using Simple Caching. While the plugin will attempt to update mod_rewrite rules, it is much simpler to have PHP serve the files. Apart from that, any plugins loaded by WP Super Cache will be completely skipped if Expert mode is enabled.
More sites use cookie banners now that the GDPR is active but some are finding that their banners are misbehaving once they enable caching.
This is a similar issue to the one that happened to some page counter plugins in the past. The page counter wouldn’t increment.
When a cookie banner is clicked a cookie is set in the browser so the website knows this visitor has agreed to accept cookies. If the cookie is set then the cookie banner html is not sent to the browser.
I suspect the main issue is that the code that sets and checks if the cookie is set is PHP. Unfortunately because the page is cached then no PHP code is executed, and the cookie banner is displayed because it was originally cached that way.
Since WP Super Cache only knows about certain WordPress cookies it assumes everyone who doesn’t have those cookies is a first time “anonymous” visitor. It doesn’t know about your cookie banner cookie.
You have two options:
Otherwise, use PHP to get WP Super Cache to play nicely with your existing code:
Substitute the name of the cookie for your cookie name, change the name of the function, and the text it adds to the string. There is an intentional PHP fatal error in the code above to discourage copy/pasting.
Your cookie banner plugin could automate setting this up, but it may have unforeseen consequences if not done correctly. It should check if $wp_cache_plugins_dir is set already, and use that location, otherwise it will have to make a directory and update the WP Super Cache configuration, where ABC is the new location for the plugins.
The new code can be copied into a file in that directory. The files in the original WP Super Cache plugins directory (found at WPCACHEHOME . 'plugins') should be copied into that directory too and a warning shown to the user. They may need to set up one of those plugins again.
The reason it is this convoluted is because this code will run before all of WordPress loads. You can’t rely on blog options or most of the nice configuration tools WordPress provides.
When your plugin is uninstalled it should of course restore the plugins directory to the way it was before.
For future reference, since cookie banners will hopefully not be around forever, here’s what they looked like in the deep, distant past of 2018. 🙂
Dan’s coverage of the Manchurian Incident reminded me I have to re-read the Tintin story, “The Blue Lotus“. Hergé definitely applied his imagination when recounting how the train track was blown up but I’d never have known about that period of time if I had never read that book.
And similarly, I wouldn’t have known the railway track was barely damaged if I hadn’t listened to Hardcore History!
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.