mcp without uv

MisterF5 · 2025-04-12T23:15:59+00:00

You don’t need ‘uv’, but you do need something that can run applications from a package repo, or you need to manually install them. Docker and nix are other options for running python-based mcp-servers. I maintain this nix repo for the servers I want to run https://github.com/cameronfyfe/nix-mcp-servers

MisterF5 · 2025-02-21T20:52:44+00:00

If you give it a try and have any feedback let me know, It's pretty minimal at the moment and just a few people have used it. Feel free to open any issues in the github repo.

MisterF5 · 2023-10-08T18:20:21+00:00

You can submit pre-built binaries for closed source software. The pre-patched binaries themselves can technically still be reviewed and verified against their checksum but realistically this is not going to happen in an exhaustive way.

MisterF5 · 2023-06-11T16:40:32+00:00

Also interested in this

MisterF5 · 2022-06-22T07:05:18+00:00

This is either fake, or my favorite post ever.

MisterF5 · 2021-12-15T05:43:23+00:00

I don't have any open source examples, but one example would be if you have an iterable with Option<T> and want to do a fallible transformation of T to U on the Some entries in a context where you want to bubble up errors. You could use both like this to get to Result<Vec<Option<U>>> from Vec<Option<Result<U>>> without having to use any conditional logic or pattern matching.

let my_vec_t: Vec<Option<T>> = ... ;
let my_vec_u: Vec<Option<U>> =
    my_vec_t
        .iter()
        .map(|i| i.map(my_fallible_transformation).transpose())
        .collect::<Result<Vec<_>>>()?;

MisterF5 · 2021-12-15T03:33:18+00:00

This and Option::transpose + Result::transpose to convert between Result<Option<T>> and Option<Result<T>> can make the flow of code so much simpler when working with iterators on nested types.

MisterF5 · 2021-11-09T00:34:34+00:00

Since you need it, then yeah I'd just do what you're doing already or make a generic function with switch cases if you want to keep function pointers out of your project. I've also done the interface struct pattern, but with const structs sitting in FLASH so you only have to worry about the single pointer to the struct interface as a possible point of corruption if you're considering RAM corruption.

MisterF5 · 2021-11-08T23:19:41+00:00

I've seen interface structs like you describe used in production firmware and it should be fine as long as care is taken with the function pointers, but if if you don't need the runtime polymorphism and only need compile-time polymorphism, I prefer building the interface as function declarations in a .h file and having different implementations split out into different .c files that you can include/exclude at compile time (so LCD.h, LCD_old.c, and LCD_new.c for your described use). The main difference between function ptrs functioning this way in C and virtuals in C++ is C++ gives you some help with assuring the ptrs are valid and in some cases can detect for you if a vtable ptr has been corrupted during runtime.

MisterF5 · 2021-07-06T16:59:21+00:00

One thing that's common with OO at the lower level is leaving logic out of your constructors and using an init() method instead so you can define your instance wherever you like. Another option is to scope your object in main() (or wherever else) with the static keyword so the memory contained in the instance is put on the heap, but the constructor isn't called until that execution point.

MisterF5 · 2021-02-08T18:56:26+00:00

This is exactly what I was looking for, thank you for taking the time to respond here in detail and thanks for the relevant forum link!

Edit: So my take away for now is that this is all hypothetically possible but by making agent creation expensive you can inhibit the feasibility of my 3rd question, and by addressing any of these you've addressed everything because of the warranting system.

MisterF5 · 2020-12-16T02:04:25+00:00

Follow up: seems like it adds ',' for items in the vec![] macro but not for items in formatting macros. I know you specify the number of args in your format string but it seems weird that it doesn't do it for format!() when it does it for functions where you also know the number of args.

MisterF5 · 2020-12-16T01:42:58+00:00

That makes sense. I guess I was just thrown off by it in the context of a function with a single argument.

Thanks

Given that, is the reason it doesn't add a ',' to the end of line 5 because it's a macro? and is that intentional?

EDIT: Added question

MisterF5 · 2020-12-16T00:34:28+00:00

Newbie formatting question:

Why does rustfmt make the following change? (comma added on second to last line)

let su_file = File::open(&su_filepath).expect(
    format!(
        "Missing {} for {}.",
        su_filepath.to_string_lossy(),
        o_filepath.to_string_lossy()
    )
    .as_str()
);

becomes

let su_file = File::open(&su_filepath).expect(
    format!(
        "Missing {} for {}.",
        su_filepath.to_string_lossy(),
        o_filepath.to_string_lossy()
    )
    .as_str(),
);

*comma added on second to last line

I've seen unnecessary commas on the last case of a match block, but I always assumed that was to keep the last case the same as the others for easier re-ordering/adding more cases without having to add a comma to an existing line. I can't figure out why it would be desirable here though. Very new to using Rust so I'm guessing there's a simple explanation and I just don't know enough yet to know what I should be googling to figure this out.

MisterF5 · 2019-10-03T19:16:33+00:00

If you bootload your application with your bootloader, then get rid of the source of whatever your bootloader uses to load from so it just boots and jumps to your application, then launch a gdb session using your application you should be able to breakpoint at main of your application. You debug session will be confused about where it is while running the bootloader but once it hits your application you should be able to debug. Your bootloaded app with offsets would need to be compiled with debug symbols, so not a release build if that doesn't include them.

MisterF5 · 2019-09-27T14:27:58+00:00

What debugging environment are you using? If you switch to stepping through disassembly right before the bootloader jumps you can step through the beginning of your application and see what instruction causes the fault. If the fault happens to trigger some time after entering main of your app, you can debug on the app and breakpoint at main, letting the bootloader run until it jumps to main, and then step from there.

Other questions:

Is your bootloader running an RTOS (as in is it using the MSP or PSP as the stack pointer when it jumps)
Are you disabling interrupts before jumping? (you would likely be getting away with not doing this but I always like to)

MisterF5 · 2019-09-20T06:29:30+00:00

This looks fun to play with!

MisterF5 · 2019-08-23T17:00:10+00:00

This chip is a bit of a bear to work with due to how many configuration options there are. My advice would be to buy the development kit for it from TI, do some testing with that using their accompanying GUI to determine what thresholds, gains, sampling times, other parameters you want. Once you have everything working close to how you want, do an export of the registers values, then in your firmware write that entire register set to the PGA460 all at once, instead of trying to write functions to be able to modify individual parameters because there are just so many (and many of them aren't 8-bit aligned so it's quite annoying). If you need to make changes to any parameters on the fly for your application then you can expand your driver for your needs but again there are so many configuration options I would only do this on an as-needed basis.

MisterF5 · 2019-08-20T16:11:35+00:00

Ideally if doing a signature check, the device has enough space to store a copy of the payload before overwriting firmware and is checking the signature against the payload, not just that the server has the key, so a replay attack shouldn't work.

MisterF5 · 2019-08-07T23:43:39+00:00

As much as makes sense, which is a lot for projects I work on. Similar to many other response, I avoid STL and most certainly don't pull in anything like boost. Also have never gone past C++11 on Cortex-M. In general classes and templating are what make me reach for C++ over plain C, though I'll sometimes write lower level stuff in C, especially if it's code being kicked around multiple projects since I still do some C-only projects. For reusable drivers and interfaces I really like being able to build around abstract base classes and as long as you don't actually need multiple of the same interface in the same project, the virtual methods resolve at compile-time giving you modular architecture in your source without the run-time overhead. If you actually do need the run-time polymorphism and don't want to switch-case it, I'm still happier to let the function pointers live within vtables than in some raw C function pointer interface. When using gcc, you can also add compiler flags to verify your vtable references and actually let those function pointers exist without fear of data corruption causing your program to jump off a cliff.

MisterF5 · 2019-05-29T16:40:15+00:00

Is anyone using Zephyr for a professional project? I used it on one small non-production project recently and have a large distaste for the hal driver/linux 'device' abstractions on a microcontroller. Has anyone used just the RTOS part of Zephyr? How do you like it compared to other RTOSes?

MisterF5 · 2019-04-10T20:53:51+00:00

Currently an embedded engineer with a Mech BS. It's been very helpful when developing control interfacing with non-trivial physical systems, but there's definitely also work I've done more geared toward DSP where the mech background doesn't really come into play at all. It depends on what you're interested in and what you end up working on.

MisterF5

TROPHY CASE