From the website:
Pinup Player: a program the can be controlled and triggered to play various types media. This can be played on multiple “screens and layers” and displayed on many different “monitors / TVs” in Windows.
#!/usr/bin/python3 | |
import os | |
import csv | |
romPath = 'ROMs/dsprom.rom' | |
csvPath = 'dsprom.csv' | |
with open(romPath, 'rb') as file: | |
output = open(csvPath, 'w') |
' Copy nvram_log.vbs in your vpinball scripts folder (or next to the table). | |
' put this before any controller / LoadVPM code | |
Const UseVPMNVRAM = true | |
' put this after LoadVPM | |
' Set this to False to disable printing of old bytes | |
Dim printOldBytes: printOldBytes = False |
From the website:
Pinup Player: a program the can be controlled and triggered to play various types media. This can be played on multiple “screens and layers” and displayed on many different “monitors / TVs” in Windows.
The multi-monitor support information below is based on personal experimentation and is not supported by the Batocera team. Please do not contact them for assistance with this setup.
Start with an Armbian image 24.2.1 Jammy Gnome image available here:
https://www.armbian.com/orangepi-5/
sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.
An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.
Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty
I'm going to do something that I don't normally do, which is to say I'm going to talk about comparative benchmarks. In general, I try to confine performance discussion to absolute metrics as much as possible, or comparisons to other well-defined neutral reference points. This is precisely why Cats Effect's readme mentions a comparison to a fixed thread pool, rather doing comparisons with other asynchronous runtimes like Akka or ZIO. Comparisons in general devolve very quickly into emotional marketing.
But, just once, today we're going to talk about the emotional marketing. In particular, we're going to look at Cats Effect 3 and ZIO 2. Now, for context, as of this writing ZIO 2 has released their first milestone; they have not released a final 2.0 version. This implies straight off the bat that we're comparing apples to oranges a bit, since Cats Effect 3 has been out and in production for months. However, there has been a post going around which cites various compar
I was recently asked to explain why I felt disappointed by Haskell, as a language. And, well. Crucified for crucified, I might as well criticise Haskell publicly.
First though, I need to make it explicit that I claim no particular skill with the language - I will in fact vehemently (and convincingly!) argue that I'm a terrible Haskell programmer. And what I'm about to explain is not meant as The Truth, but my current understanding, potentially flawed, incomplete, or flat out incorrect. I welcome any attempt at proving me wrong, because when I dislike something that so many clever people worship, it's usually because I missed an important detail.
Another important point is that this is not meant to convey the idea that Haskell is a bad language. I do feel, however, that the vocal, and sometimes aggressive, reverence in which it's held might lead people to have unreasonable expectations. It certainly was my case, and the reason I'm writing this.
I love the concept of type class
#include <stdio.h> | |
#include <SDL.h> | |
int main(void) { | |
SDL_Init(SDL_INIT_AUDIO); | |
// the representation of our audio device in SDL: | |
SDL_AudioDeviceID audio_device; | |
// opening an audio device: |