%%{init: {"theme": "base", "themeVariables": { "pie1": "#FF5733", "pie2": "#33FF57", "pie3": "#3357FF", "pieStrokeColor": "#000000", "pieStrokeWidth": 3, "pieOpacity": 0.8 }}}%%

This looks like it works on this site too.

The problem is that the only safe way for the compiler to generate non-boxed unions would require non-overlapping fields for most value types.

Specifically the CLR has a hard rule that it must know with certainty where all managed pointers are at all times, so that the GC can update them if it moves the referenced object. This means you can only overlap value types if the locations of all managed pointers line up perfectly. So sure, you can safely overlap "unmanaged" structs (those that recursively don't contain any managed pointers), but even for those, you need to know the size of the largest one.

The big problem with the compiler doing any attempt to overlap value types is that if the value types as defined at compile time may not match the definitions at runtime, especially for types defined in another assembly. A new library version can add more fields. This may mean one unmanaged struct has become too big to fit in the field, or that two types that were previously overlap compatible are not anymore.

Making the C# compiler jump though a bunch of hoops to try to determine if overlapping is safe and even then leaving room for an updated library at runtime to crash the whole things means that the compiler will probably never even try. I guess the primitive numeric types could be special cased, as their size is known and will never change.

It is tricky to meaningfully expose a dollar cost equivlent value for subscribers in a way that won't confuse users into thinking that they will get a bill that includes that amount. This is especially true if you have overages enabled, since in a session that used overages it was likely partially covered by the plan (and thus zero-rated) with the rest at api prices, and the client can't really know the breakdown.

The relevant client side system prompt is:

IMPORTANT: Assist with authorized security testing, defensive security, CTF challenges, and educational contexts. Refuse requests for destructive techniques, DoS attacks, mass targeting, supply chain compromise, or detection evasion for malicious purposes. Dual-use security tools (C2 frameworks, credential testing, exploit development) require clear authorization context: pentesting engagements, CTF competitions, security research, or defensive use cases.

----

There is also this system reminder that shows upon using the read tool:

Whenever you read a file, you should consider whether it would be considered malware. You CAN and SHOULD provide analysis of malware, what it is doing. But you MUST refuse to improve or augment the code. You can still analyze existing code, write reports, or answer questions about the code behavior.

This approach is actually fairly desirable for assets types that cannot be easily merged, like images, sounds, videos, etc. You seldom actually want multiple people working on any one file of those at the same time, as one or the other of their work will either be wasted or have to be re-done.

Obviously, this means that first gid was bogus anyway, as it was trying to look up via the wrong key, but the fact that it doesn't fail, and will instead return the record with primary key "22" can certainly be surprising.

My understanding is that Chrome for Android has supported it for some time by way of delegating to android's native media support which included HLS.

Desktop and mobile Safari has had it enabled for a long time, and thus so has Chrome for iOS.

So this should eventually help things.

I'm not sure what the rollout status actually is at the moment.

COM can be as simple as that implementation side, at least if your platforms vtable ABI matches COM's perfectly, but it also allows far more complicated implementations where every implemented interface queried will allocate a new distinct object, etc.

I.E. even if you know for sure that the object is implemented in c++, and your platforms' vtable ABI matches COM's perfectly, and you know exactly what interfaces the object you have implements, you cannot legally use dynamic_cast, as there is no requirement that one class inherits from both interfaces. The conceptual "COM object" could instead be implemented as one class per interface, each likely containing a pointer to some shared data class.

This is also why you need to do the ref counting with respect to each distinct interface, since while it is legal from an implementation side to just share one ref count for it all, that is in no way required.

over in the US, getting an MPAA rating is completely voluntary. MPAA rules do not allow it to refuse to rate a motion picture, and even if they did, the consequences would be the same as choosing not to get a rating.

If you don't get a rating in the US, some theatres and retailers may decline to show/sell your film, but you can always do direct sales, and/or set up private showings.

But where is the proof that your compiler will compile the code correctly with respect to the C standard and your target instruction set specification? How about the proof of correctness of your C library with respect to both of those, and the documented requirements of your kernel? Where is the proof that the kernel handles all programs that meet it documented requirements correctly?

Not to point too fine a point on it, but: where is the proof that your processor actually implements the ISA correctly (either as documented, or as intended, given that typos in the ISA documentation are that THAT rare)? This is very serious question! There have been a bunch of times that processors have failed to implement the ISA spec is very bad and noticeable ways. RDRAND has been found to be badly broken many times now. There was the Intel Skylake/Kaby Lake Hyper-Threading Bug that needed microcode fixes. And these are just some of the issues that got publicized well enough that I noticed them. Probably many others that I never even heard about.

The simplest (and arguably best) usage for a devcontainer is simply to set up a working development environment (i.e. to have the correct version of the compiler, linter, formatters, headers, static libraries, etc installed). Yes, you can do this via non-integrated container builds, but then you usually need to have your editor connect to such a container, so the language server can access all of that, plus when doing this manually you need to handle mapping in your source code.

Now, you probably want to have your main Dockerfile set up most of the same stuff for its build stage, although normally you want the output stage to only have the runtime stuff. For interpreted languages the output stage is usually similar to the "build" stage, but out to omit linters or other pure development time tooling.

If you want to avoid the overlap between your devcontainer and your main Dockerfile's build stage? Good idea! Just specify a stage in your main Dockerfile where you have all development time tooling installed, but which comes before you copy your code in. Then in your .devcontainer.json file, set the `build.dockerfile` property to point at your Dockerfile, and the `build.target` to specify that target stage. (If you need some customizations only for dev container, your docker file can have a tiny otherwise unused stage that derives from the previous one, with just those changes.)

Under this approach, the devcontainer is supposed to be suitable for basic development tasks (e.g. compiling, linting, running automated tests that don't need external services.), and any other non-containerized testing you would otherwise do. For your containerized testing, you want the `ghcr.io/devcontainers/features/docker-outside-of-docker:1` feature added, at which point you can just use just run `docker compose` from the editor terminal, exactly like you would if not using dev containers at all.

Looks like this:

    mondo`
    $ note (c2 # euclid <3 6 3> <8 16>) # *2 
    # s "sine" # add (note [0 <12 24>]*2)
    # dec(sine # range .2 2) 
    # room .5
    # lpf (sine/3 # range 120 400)
    # lpenv (rand # range .5 4)
    # lpq (perlin # range 5 12 # \* 2)
    # dist 1 # fm 4 # fmh 5.01 # fmdecay <.1 .2>
    # postgain .6 # delay .1 # clip 5

    $ s [bd bd bd bd] # bank tr909 # clip .5
    # ply <1 [1 [2 4]]]]>

    $ s oh*4 # press # bank tr909 # speed.8
    # dec (<.02 .05>*2 # add (saw/8 # range 0 1)) # color "red"
    `

    await initTidal()
    tidal`
    d1 
    $ sub (note "12 0")
    $ sometimes (|+ note "12")
    $ jux rev $ voicing $ n "<0 5 4 2 3(3,8)/2>*8"
    # chord ""
    # dec 0.5 # delay 0.5 # room 0.5 # vib "4:.25"
    # crush 8 # s "sawtooth" # lpf 800 # lpd 0.1
    # dist 1

    d2 
    $ s "RolandTR909_bd*4, hh(10,16), oh(-10,16)"
    # clip (range 0.1 0.9 $ fast 5 $ saw)
    # release 0.04 # room 0.5
    `

But it is currently broken on the REPL site because of https://codeberg.org/uzu/strudel/pulls/1510 and https://codeberg.org/uzu/strudel/issues/1335

The hope is that students will gradually learn to just recognize words by sight, which the overwhelming majority do eventually learn to do, and just need to sound out unfamiliar words. The fact that some students have struggled to learn to recognize words and need to sound most out is part of why people try to create alternatives, but those largely don't work well.

Of course, English does have some tricky phonetics. We have some words with multiple different pronunciations. We have some words with the same phonemes but different meanings that differ solely based on syllable stress. There are even some words whose pronunciation simply must be memorized, as there is no coherent rule to get from the word to the pronunciation (see for example Colonel).

It is far more guarenteed that that will work in all circumstances than these JIT optimizations, which could have some edge cases where they won't function as expected. If stopwatch allocations were a major concern (as opposed to just feeling like a possible perf bottleneck) then a modern ValueStopwatch struct that consists of two longs (accumulatedDuration, and startTimestamp, which if non-zero means the watch is running) plus calling into the stopwatch static methods is still simple and unambiguous.

But in cases where being low/no allocation is less critical, but your are still concerned about the impacts of the allocations, then these sort of optimizations certainly do help. Plus they even help when you don't really care about allocations, just raw perf, since the optimizations improve raw performance too.

In something like JavaScript, I might write a function or class or whatever with the full expectation that some parameter is a string. However, if I don't check the runtime type, and throw if it is unexpected, then it is very easy for me to write this function in a way where it currently technically might work with some other datatype. Publish this, and some random user will likely notice this and that using that function with an unintended datatype.

Later on I make some change that relies on the parameter being a string (which is how I always imagined it), and publish, and boom, I broke a user of the software, and my intended bugfix or minor point release was really a semver breaking change, and I should have incremented the major version.

I'd bet big money that many JavaScript libraries that are not fanatical about runtime checking all parameters end up making accidental breaking changes like that, but with something like typescript, this simply won't happen, as passing parameters incompatible with my declared types, although technically possible, is obviously unsupported, and may break at any time.

Of course, centralized signaling is better, allowing for greater efficiency, helps dispatch keep track better track of the trains, makes handling malfunctioning signals a lot safer, among many other benefits. But it doesn't mean local signaling can't be done.

Don't these LLMs fundamentally work by outputting a vector of all possible tokens and strengths assigned to each, which is sampled via some form of sampler (that typically implements some softmax variant, and then picks a random output form that distribution), which now becomes the newest input token, repeat until some limit is hit, or an end of output token is selected?

I don't see why limiting that sampling to the set of valid tokens to fit a grammar should be harmful vs repeated generation until you get something that fits your grammar. (Assuming identical input to both processes.) This is especially the case if you maintain the relative probability of valid (per grammar) tokens in the restricted sampling. If one lets the relative probabilities change substantially, then I could see that giving worse results.

Now, I could certainly imagine blindsiding the LLM with output restrictions when it is expecting to be able to give a freeform response might give worse results than if one prompts it to give output in that format without restricting it. (Simply because forcing an output that is not natural and not a good fit for training can mean the LLM will struggle with creating good output.) I'd imagine the best results likely come from both textually prompting it to give output in your desired format, plus constraining the output to prevent it from accidentally going off the rails.

That is largely true of academic research. A critical difference though is that you don't need big expensive hardware, or the like to follow along with large portions of the cutting edge CS research. There are some exceptions like cutting edge AI training work super expensive equipment or large cloud expenditures, but tons of other cutting edge CS research can run even on a fairly low-end laptop just fine.

It is also true that plenty of software innovation is not even tied to CS style academic research. Experimenting with what sort of perf becomes possible via implementing a new kernel feature, can be very important research but isn't always super closely tied to academic CS research.

Even the more hobbyist level cutting edge research for EE will have more costs, simply because components and PCBs are not exactly free, and you cannot just keep using the same boards for every project for several years like you can with a PC.

It is important to also capture tarrifs from high value parcels, as for small but high value items a parcel can very much be a similar bulk import. (Picture diamonds. A moderate sized parcel full of them is very much a bulk import).

But at the same time trying to collect tarrifs on every parcel was historically deemed non-viable. Way too much work for too little gain. Especially since historically, the addressee of the parcel often ends up paying the tarrif, this requiring customs to communicate this to the parcel carriers broker, who must communicate it and collect from the end customer, who finally gives the money to the broker, who submits it to the government. Meanwhile CBP needs to store this package.

This whole process ends up just annoying your countries own citizens, and generated little revenue, so a de minimis exemption of some form was highly desireable. And to most politicians there seemed like little downside to setting it fairly large. Sure $800 is probably larger than reasonable, but it certainly means the average person would rarely ever need to interact with this process, and that was good enough.