my workaround for this was to make a wrapper mcp server which uses claude haiku to summarize the page snapshot returned in the response of each playwright mcp call, and that has worked pretty well for me: https://github.com/jsdf/playwright-slim-mcp
he doesn’t want experts, he wants people who will be subservient to him. expertise would get in the way of that, because experts would likely understand that he has no idea what he’s talking about, and not respect his dictates. see: everyone who knew how things worked at twitter.
modular synthesis isn't named 'modular' in reference to 'modulation', it's in reference to synth 'modules', which are units of functionality from which you can build a synthesizer. for example with an oscillator module, a couple of envelope modules, a gain module and a filter module you can build a typical monophonic subtractive synthesizer.
the ‘search box’ is not good at finding stations so i can check when the next train is coming. i typed in ‘34th st’ and it returned a bunch of addresses, none of which are in manhattan. this is probably because you require me to type ‘34 st’ exactly (no ‘th’) instead. if you can’t fuzzy match this, this search box is just unusable.
i also tried looking at ‘nearby stations’ and while standing on the 34th st A platform it didn’t list the 34th st subway station at all, just a bunch of bus stops.
please let me just look at a station list instead.
I see a lot of people asking why someone would distribute an Electron-wrapped version of a program you could run natively, and I see it as an extension of the the same reason why I ported these emulators to the browser in the first place: accessibility. While you can install BasiliskII natively, it's a bit of a pain, especially if you are not super technical. If you find a binary floating around online it may not work for your OS version. Wrapping it in Electron is one way to ameliorate the OS compatibility issue; Chromium has been battle-tested across many OS versions. Ideally BasiliskII would have a better OS compatibility story (as well as being more portably distributable with data files) but, like many open source projects, it doesn't have a lot of maintainer-time to make this happen.
If you're using SSR (or static generation) for the initial pageload, you can continue to do so. The payloads can just be used to update the page when the user performs subsequent interactions.
Additionally, you can always fall back to clickable links if you really want to support subsequent interactions for users with no JS, if you've built the routing infrastructure for that
can you describe the threat vector here? how exactly could it be used to do that? keeping in mind the cross origin limitations mentioned in the spec, and that the timing resolution is no different to JS timestamp methods already available to code run in this context
The author mentions that they didn't have a debugger and couldn't get MacsBug to work inside the emulator. A useful technique here is to use the emulator itself as the debugger: most emulators have features for setting breakpoints and single stepping through emulation and directly reading memory values from the emulated system's memory (by absolute memory address). For example, here is the documentation for 'hardware'-level debugging in the PCE emulator: https://github.com/jsdf/pce/blob/pcejs/doc/monitor.txt
One 'nice' thing about working with old architectures like classic Macintosh is that there is basically no abstraction between the software and the hardware, so manipulating the behavior of the emulated hardware becomes a powerful debugging tool.
You might be interested in this GDC talk about the PS4 Spiderman game, which dives into the performance optimizations they used, which are in a similar spirit (though at a higher level of abstraction): https://www.youtube.com/watch?v=KDhKyIZd3O8