The Fn trait could be used, which prevents mutation, but allows a lot of useful closures. I should note, a motivated user could provide a junk function no matter what the type accepted is
It seems like it is lacking the functionality R's integrate has for handling infinite boundaries, but I suppose you could implement that yourself on the outside.
For what it's worth,
use integrate::adaptive_quadrature::simpson::adaptive_simpson_method;
use statrs::distribution::{Continuous, Normal};
fn dnorm(x: f64) -> f64 {
Normal::new(0.0, 1.0).unwrap().pdf(x)
}
fn main() {
let result = adaptive_simpson_method(dnorm, -100.0, 100.0, 1e-2, 1e-8);
println!("Result: {:?}", result);
}
prints Result: Ok(1.000000000053865)
It does seem to be a usability hazard that the function being integrated is defined as a fn, rather than a Fn, as you can't pass closures that capture variables, requiring the weird dnorm definition
It seems like he did everything! I first heard of Von Neumann in international relations & economics classes as the person who established game theory, then later in CS classes as the creator of mergesort, cellular automata, Von Neumann architecture, etc.
I think you're thinking of something different to the issue in the parent comment. The most vexing parse is, as the name suggests, a problem at the parsing stage rather than the earlier lexing phase. Unlike the referenced lexing problem, it does't require any hack for compilers to deal with it. That's because it's not really a problem for the compiler; it's humans that find it surprising.
Given all the things that were new to the author in the article, I wouldn’t be shocked at all. There’s just a huge number of things to know, or to have come across.
I wonder how much of this has to do with Covid interrupting a lot of recent grads’ time in college and forcing a large percentage of their courses to be online for a time
It seems pretty obvious to me that the quality of both teaching and assessment plummeted during this time, so I suspect that it’s even harder than usual to trust things like a transcript to see what an applicant really knows
It is possible provided some care. I was looking into this with WAForth which compiles the wasm and loads it via a host function (ie. it is the hosts responsibility to make it available). I wanted to enable dynamic loading of words from disk which requires some book keeping and shuffling a bunch of bytes around during compilation to write out the bits necessary to have the host do that linking. It isn't impossible to do, just tedious and in my case, having to write it in WAT is a pain.
It’s sadly a bit more of a proof of concept than a hackable project. The docker build in the readme did work last time I tried, and there is a demo site at https://jprendes.github.io/emception/, but I’ve failed to modify it in the past to do other things
The closest I’ve found in terms of description is https://github.com/feschber/lan-mouse, but the lack of encryption on the connection has discouraged me from using it.
I’m also a paid Synergy user, and it’s frankly comedic how long Wayland support has been on their road map. I’m not convinced it’s ever coming, which means I’m probably only 1-2 distro updates from being forced to use something else
A good question. The VS Code extension API is pretty powerful but extensions run separately from the main workbench process and they can't draw any meaningful UI on it. This was a great design decision IMHO as it is the core reason VS Code has a reputation for a minimalist UI and good performance despite being based on Electron.
However it also made it impossible to build the kinds of experiences we wanted to with Positron. Positron has a bunch of top-level UI as well as some integrated/horizontal services that don't make sense as extensions. We built those into the core of the system which is why a fork was necessary.
It's a goal for Positron to be extensible, so it has its own API alongside VS Code's API, and both the R and Python language systems are implemented as extensions.
I'm curious if you would be willing to elaborate on what your plans are for longer term feature parity with vscode? As in I can imagine as vscode receives continued development and new features you will have the development burden of having to integrate these updates into your fork. Are you planning to keep up-to-date with vscode or will the products essentially drift a part over time? If the latter would this mean extension developers have to build separate extensions for your IDE?
We merge upstream from VS Code every month and we plan to keep up to date with it, so extensions will continue to work and we'll continue to inherit new features as they become available.
It's a development burden for sure -- but still an order of magnitude cheaper than trying to build a good workbench surface from scratch.
reply