jsd1982

The Bart, The.

I think the conclusion section should indicate that they are based entirely on GCC 16's behavior and current implementation. We should avoid generalizing one compiler's behavior and performance. Curious how this same test would behave once clang ships C++26 reflection.

It should be possible to have the PPU emulation capture all of the final register state per pixel (or scanline if accuracy isn't paramount) and have the GPU render each pixel using only that state, doing the layer blending, color math, and mode 7 calculations as necessary. Based on MVG's video breaking down the draw commands performed it doesn't look like that's how Super ZSNES have implemented their PPU - it seems to render tile by tile for BGs (and OBJ?) and line by line for mode 7. That'll be a bit inaccurate but it's likely necessary to implement some of their visual enhancement tricks.

Very cool! Checking out the Van Gogh painting in the viewer I can just barely see the depth of the brush strokes. Shame you can't look 90 degrees off axis to see the protrusion effect with the bulky outer frame in the way.

Very cool idea, but unfortunately the browser doesn't allow users to select which channel of their audio interface to use as input. So unless you're plugging your guitar into input 1 this doesn't work out. I have my microphone in input 1 and my guitar in input 2.

Reminds me of John Petrucci's Rock Discipline instructional video where he outlines exactly this technique on how to build up speed.

I love this idea! Just wanted to send a note of encouragement. Keep at it!

A real-time circuit-level simulation of the MESA Boogie Mark IIC+ guitar preamplifier.

https://www.youtube.com/watch?v=xEy34cuOPaY

Are we assuming that "testing" is limited to only exercising the single-threaded behavior of a function? I'm curious how others approach effective testing of multi-threaded behavior.

Yes, parameterization was implied.

Sanitization of data is such a strange security practice to me. It feels like any sort of vulnerability sensitive to data sanitization just boils down to a failure to properly encode or escape data into a target language that is susceptible to injection attacks e.g. SQL, HTML, javascript. Is there a real-world scenario where data sanitization is required where proper data encoding/escaping is not the better solution?

I think cognitive load has a lot more to do with the paradigm that the code is written in than any particular type of author's contribution to the code. For instance, the object-oriented paradigm by design increases cognitive load by encouraging breaking up otherwise straightforward logic into multiple interfaces, classes, and methods.

What's the most cost-effective NAS hardware/software combo lately?

Not sure, don't have any of those. The response feels very natural from my own playing.

Here's a little announcement video I put together a week ago for an earlier version:

https://m.youtube.com/watch?v=xEy34cuOPaY

I've built a VST3 plug-in that simulates a Mesa Boogie Mark IIC+ preamp purely from the circuit.

The approach doesn't seem popular for professional plug-ins likely because it wasn't viable for real time until modern CPU enhancements became available. Performance scales with frequency of the input which is interesting and seems to be a consequence of using an iterative solver on a system of equations and using the previous sample's state vector as a guess for the current sample.

On my MacBook M3 it requires between 50 to 70% of a single core to produce a 2x oversampled output at 48000Hz. This can be scaled back by reducing the solution tolerance bounds and get down near 25% with minimal quality loss.

Wouldn't this make it somewhat more challenging for assemblers/compilers to emit branch instructions with target PC offsets?

For instance, the offset of an instruction two instructions away would be calculated as `lfsr(lfsr(pc))` (off-by-one bugs notwithstanding), right?

The obvious solution to me is to implement streaming/buffered processing of the content while downloading it instead of downloading the entire content into memory to be processed in a single contiguous byte[].

Buffered IO would have the CPU processing acting as a natural backpressure mechanism to prevent downloading too much content and also prevent unbounded memory allocation. Each CPU worker only needs to allocate a single small buffer for what it processes and it can refill that same buffer with the next IO request. Your memory usage becomes entirely predictable and will only scale with how many concurrent threads you can actually execute at once.

Also, no matter how you artificially rate limit the virtual thread scheduling (e.g. via semaphore), if you still insist on downloading the entire content into memory before starting processing then obviously you cannot process any single piece of content larger than what can fit into available memory at any given time.

I fixed a recent Y38 bug in some classic ASP code. The bug was nothing more than a simple `Date() + 5000` computation (adding 5000 days to the current date) as a sort of expiry date applied to something; I don't recall the exact details. VB6 did not take kindly to computing any date value beyond the Y38 max and threw an error. In practice this error ended up denying service to everyone even though the Y38 max date was 14 years in the future. You never know what little bugs like that are lurking in such legacy code.

I tried to install Visual Basic 6 on it but couldn't get past SSL errors in the installed Firefox version to even download the ISO. Sad.

On mobile I couldn't make a mistake. Every tap was charitably interpreted as the correct action to take on that square whether it be flagging a mine or revealing empty space / numbers. I clicked every tile and never exploded a mine.

It feels a bit unfair to lay the blame for all of this on C. All other mainstream compilable languages compile to similar abstract machines in a similar fashion to C.

Only if your goal is to be an entrepreneur. Not everyone chases that goal nor considers success in that fashion.

Was it considered to separate each table into its own S3 object?

A touchscreen with an entire software engineering department behind its software is cheaper than buttons?

Just ran into a Y2038 bug in some classic ASP+VBScript code in production the other day. Someone long ago wrote `Date() + 5000` to set an expiry date far in the future (5000 days). As it turns out, 5000 days from now puts us past 1970-01-01 + 2**31 seconds (2038-01-19ish) and that causes VBScript to raise an error and abort the ASP page request with a 500 error.

I raised the issue that we have about 14 years left of ASP+VBScript literally being able to execute properly and calculate dates (sans any large date additions remaining). Guess it'll be sooner than that based on this post but 14 years is definitely the upper bound if your VBScript code even touches dates.

SMB3 is 3 Megabits in size, aka 384 KiB. You're likely thinking of the original Super Mario Bros which is just 40 KiB.

The smug is hard to get past; stopped reading a few paragraphs in.

Can you elaborate? I've been coding since the 90s and have never heard the term _A table before.

Did they _really_ need to call out that the man (victim) was homeless? Is that a significant identifier important to the story?

The go-compiled wasm is also extremely slow compared to tinygo's wasm. Doing simple things like `fmt.Printf()` degraded performance significantly.