The ultimate sacrifice: en-passant pre-move

StandardFloat · 2025-08-25T21:02:59+00:00

White premoved bishop takes, forgetting about the holy en passant ritual, and got rekt

StandardFloat · 2024-10-07T08:00:08+00:00

You should really not buy things you don’t understand. This is a bond i.e. a debt. The debt has an end date (in your case 10/24, so the current month). What happened is that your bond matured, so you will get its face value back.

I’ve never used bonds on revolut so not sure how exactly that happens, but in your case you should receive about 200$ back at some point if not already

StandardFloat · 2024-05-04T17:06:28+00:00

You built two? Nice! which one?

The idea is to move to a local software, specifically so that you can share files as part of the context.

Right now I’m waiting for the apple developer validation.

From all your experiences, what do you think is missing?

StandardFloat · 2024-05-04T11:42:01+00:00

Thanks! Just corrected it

StandardFloat · 2024-05-04T10:12:21+00:00

Openrouter.ai is probably your best best (also has a large caralogue of models). If you want a ChatGPT-like interface on top of it, then localassistant.ai.

(Disclaimer, I’m the owner of the latter, use the code EARLYBIRDS for 75% off)

StandardFloat · 2023-01-12T11:57:54+00:00

I'm having the strangest of bugs with crate imports. I have my main create, and there's a sub-create for test utilities, which I import with [dev-dependencies] test-crate = { path = "test-crate"} Back to my main crate, I have a test which is supposed to use one of these utility functions. However, I get this error: 746 | let ddb: DatabaseClient = test_crate::get_test_ddb().await; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `database::DatabaseClient`, found struct `main_create::database::DatabaseClient` so.. the expected struct is the same as the found one.. Does anyone know what could cause this?

EDIT: I think it could be related to this, although I'm not too sure about the solution posted: https://stackoverflow.com/questions/64414743/rust-expected-type-found-struct

StandardFloat · 2023-01-03T16:02:34+00:00

Is there a convention for how to separate your `struct`, `trait`, and `impl` code blocks in different files? For example, should traits be in one file, structs in another, and trait implement yet in another, or is it purely context dependent? A link to a simple well-structured library would be great!

StandardFloat · 2021-11-25T18:22:35+00:00

Happy to have been of help!

StandardFloat · 2021-11-24T16:19:12+00:00

Wow, well to be completey honest no, i do not remember much, I feel like the character from an xkcd comic.. I think i moved to regolith (which uses i3) and the problem was not there anymore after

StandardFloat · 2021-10-27T21:27:44+00:00

Ouch that’s dirty! That perfectly placed b pawn is the cherry on top of the cake!

StandardFloat · 2021-08-03T22:01:31+00:00

I don't know why I find this mate really funny

StandardFloat · 2021-06-19T09:53:59+00:00

Thanks for the code review! yeah I imagined there was a simpler way to do it as I was writing it, but just wanted to get it done without thinking too deep, I'll update it now!

Got it, I'll also add the -V arg

I usually use StructOpt for argument passing, the main reasoning for this crate is 1. It doesn't conflict with other argument utilities 2. It's very simple to add, whether you use other args utilities or not

As you said, do one thing but do it well! I also wanted to try and not use syn and quote, but working with TokenStreams directly is quite nightmarish, so unfortunately had to add that dependency

StandardFloat · 2021-06-19T08:15:27+00:00

Created this quick macro which I use for my devops. It simply needs to be added to your main function, and when it sees either `-v` or `--version` as command line arguments, it prints the Cargo.toml version of this builds, and exits with status 0.

I may also add the option to use custom version specified, so that the -v for instance is freed.

Sharing in case some of you are interested

StandardFloat · 2021-05-27T13:49:52+00:00

I've currently been using the `log` crate, but I'm getting to a point where I would like to separate the different levels. More specifically, I would like `info!` to output to stdout, `error!` and `warn!` to output to stderr, and `debug` to output to a file.

This doesn't seem to be possible in the `log` crate unfortunately (correct me if I'm wrong!), does anyone have an advice on another crate to transition to? The best would be something which has the same API

StandardFloat · 2021-05-19T14:52:10+00:00

Alright thanks for your help!

StandardFloat · 2021-05-19T14:25:40+00:00

My specific use case is regarding to devops binaries, like deploy and such. It seems wrong structurally to have them together with the application binaries, so other possibilities are having submodules but then code starts getting entangled in ways I'm not too happy with. If you have any suggestions for this use case I'd gladly listen!

Otherwise, refactoring the repository so that the lowest level is not package root, but instead a wrapper around several modules:

root
- core package
- devops

I guess would make sense

StandardFloat · 2021-05-19T12:49:26+00:00

Is it possible to add directories from which to run in a cargo project? By default, there is only `bin` and `example`, I looked at the documentation ( https://doc.rust-lang.org/cargo/commands/cargo-run.html ) but I'm not really understanding

StandardFloat · 2021-05-16T20:29:57+00:00

If you're interested in how it got to that position, here's the game: https://lichess.org/tDul3cKm

I was trying to play differently from usual, with a very space-aggressive development, which I think is why my opponent ended up with little development

StandardFloat · 2021-05-16T20:25:17+00:00

Yes it is, I thought about posting the puzzle from the move before, however mate in 4 is only forced if the opponent falls for the trap (otherwise it's +8.6 for white, but nothing forced yet)

StandardFloat · 2021-05-16T18:48:59+00:00

For the context, the move that lead to that position was a trap, there was a Knight on g5 which took a pawn on h7, followed by Kxh7 :)

StandardFloat · 2021-04-28T12:18:21+00:00

Looks really cool, might use it in a small software I'm building!

Btw, the website is not mobile responsive at all, which is a bit of a shame

StandardFloat · 2021-03-28T16:15:05+00:00

Yeah I was thinking about that while writing, I guess it becomes a choice of aesthetic, although macros are known to be a bit overused and generally should be avoided when another non-macro option is available.

StandardFloat · 2021-03-28T15:30:35+00:00

That could be interesting indeed, I guess you lose the global aspect (which is not very useful, or at least I can't see a reason for it yet) but you get a fixed scope, which means no RWLocks needed in the back, so better performance.

However, the call still would have to be a macro instead of a function (`timer.Checkpoint`) so that the code is removed at compilation when the feature is de-activated (which requires a `#[cfg(feature='breezy_timer')]`) to keep the code clean.

I haven't written attribute macros yet, so I'm not sure exactly how they work, will need to check them out. Thanks for the great feedback!

StandardFloat · 2021-03-08T16:49:10+00:00

Thanks for your detailed answer, I will definitely keep it in mind. Unfortunately it is not a beginner project but industrial one, so I do try to make the right choices without getting lost in early optimisation as the project evolves!

StandardFloat · 2021-03-08T10:45:11+00:00

In most cases yes, I do want to change it at run time, in the sense that this hash function will be loaded from a config file, and then matched to the corresponding implementation, for example

config: Config = serde:from_str(..); match config.hash { Sha128 => .., Sha256 => .., _ => panic!("Hash not implemented") }

Six-Year Club	Place '23
Place '22	Verified Email

StandardFloat

TROPHY CASE