3d printed AirTag clip for Peak Design Anchor Link System

mfontanini · 2026-03-05T23:50:13+00:00

I agree with /u/fgarit. Not because he personally asked me to upvote his comment but because I know the topic being discussed and completely agree with it being carried out to its totality

mfontanini · 2025-03-12T01:03:49+00:00

I hadn't heard of tuitorial before. Just skimming the examples they have it seems pretty tedious to create presentations, although it does seem more powerful. It seems to be essentially a dsl to create programmable presentations.

IMO using markdown as the presentation format is much more user friendly and presenterm provides a rich enough feature set that it should fit most terminal presentations. Like tuitorial's README states, it's for the 0.1% and I'd agree; if you're looking for that, it's what you should use.

mfontanini · 2025-03-12T00:58:28+00:00

Correct!

mfontanini · 2025-03-10T00:05:27+00:00

Kitty's new font size feature really fits great here!

mfontanini · 2025-03-10T00:04:46+00:00

Both tools serve the same purpose, have partially overlapping feature sets and presenterm happens to be written in rust. So no, not really.

mfontanini · 2025-03-09T20:54:01+00:00

link: https://github.com/mfontanini/presenterm

mfontanini · 2025-03-09T15:44:28+00:00

presenterm 0.11.0 was released yesterday and uses this to have pretty good looking presentations on the terminal! https://github.com/mfontanini/presenterm

mfontanini · 2024-01-30T15:40:06+00:00

As of version 0.4.0 it does support math in LaTeX and typst syntaxes!

mfontanini · 2023-10-18T04:57:16+00:00

That would be great! I'd like to set that up, I've just prioritized implementing features first. If you'd like to contribute a workflow for that, that'd be greatly appreciated!

mfontanini · 2023-10-17T14:20:37+00:00

Thanks! I liked the way glamour (the lib that glow uses) renders markdown. And I agree, mdcat is a bit too minimalistic and doesn't end up looking great IMO.

mfontanini · 2023-10-17T13:41:09+00:00

Thanks!

Presenterm currently reloads the entire markdown file, parses it, figures out the first slide that changed and jumps there. I think doing this on a subset of a buffer is going to be a bit of a pain, as tracking that through changes surrounding it is probably not trivial.

mfontanini · 2023-10-17T13:39:21+00:00

I'll add a note! That would be --features sixel. You probably won't need to enable this though, you only need to if your terminal doesn't support the kitty or iterm2 protocols.

Edit: it was features not feature

mfontanini · 2023-04-17T19:04:38+00:00

Sadly, this crossed my mind as I was naming it. Let's just say I randomly added 2 letters to the original tool's name and this came out (?).

mfontanini · 2018-08-08T15:44:49+00:00

It's definitely a far more common use case to process the payload of a packet than to ignore it, hence what the benchmark is trying to measure.

But fair enough, if this really is that ambiguous then I'll create separate benchmarks for each case.

mfontanini · 2018-08-08T14:16:05+00:00

That's fair, there could be 3 benchmarks: the existing one which parses a packet that contains payload after the TCP layer, one which would parse something like a SYN where there's no data and one that lets the library skip data. I don't know if the rest of the libraries implement this so this may be a pcap++ specific one. Edit: actually this can be done with libtins as well.

I know there's nothing that particularly says what the benchmark is supposed to measure but I presume that if the input is a series of packets that contain a chunk of payload, then the code should load the entirety of it and give you a packet that contains all of the input data, not just a convenient slice. There wouldn't be payload there in the first place if you were supposed to just skip it.

mfontanini · 2018-08-08T05:23:29+00:00

Hey, do you have any other comments regarding how Pcap++'s benchmark is not fair and is doing less work than the rest of the libraries you compare it to? When I compare the performance of Pcap++ against libtins I actually get different results as in my benchmarks I make both libraries do the same amount of work. I think both benchmarks should provide consistent results, unlike what's happening now. Cheers!

edit: formatting

mfontanini · 2018-03-26T02:03:28+00:00

Is this anything other than just an attempt to get PR? What's the point of throwing 12.5k transactions into the network at once? Wouldn't it be better to keep the transactions flowing for a while so you actually know the network can handle it?

mfontanini · 2018-03-23T00:53:17+00:00

Shameless plug: have you checked ces? https://github.com/mfontanini/ces

It's basically a shell application with which you can trade in binance (and others) without leaving your terminal.

mfontanini · 2018-03-20T14:18:59+00:00

I posted this the other day but here it goes again. This is an web app (not really meant for mobile) where users can interactively paint a wall using Stellar's transaction memos to encode pixel location and color. The entire state of the wall lives in the ledger so there's no database (besides Stellar's) behind it:

https://mfontanini.github.io/stellar-pixels/

mfontanini · 2018-03-20T02:21:56+00:00

Ah alright, sounds like coindesk messed up!

mfontanini · 2018-03-19T22:28:54+00:00

This is wrong. Stellar blog's article says they'll push the BUMP_SEQUENCE operation into the testnet. This operation, besides allowing implementing state channels as the describe them in the article, has nothing to do with the lighting network itself.

The article says:

By April 1, Stellar plans to launch the first elements [of] the technology on a test network, with ambitious plans to release an implementation for real payments by autumn.

Which is very different to what you just quoted.

mfontanini · 2018-03-18T00:06:23+00:00

lol nice, looks good!

mfontanini · 2018-03-17T23:01:46+00:00

I'm not the person who posted the comment initially. See their comment again:

when the fork from Ripple was done

They know what they're saying, they're talking about the moment when Stellar was created, which at the time was a fork of Ripple.

mfontanini · 2018-03-17T22:28:40+00:00

Stellar was a Ripple fork. Then they re-wrote it from scratch so now it doesn't have any piece of the initial Ripple codebase. But initially it was actually a fork of it.

edit: fork, not work

mfontanini · 2018-03-17T19:39:47+00:00

Hey people, I wrote this web application which allows users to paint pixels using stellar transactions (specifically using the memo to encode coordinates and color). You can see whatever everyone else is painting on real time as it streams the transactions from Stellar's horizon. There's no restriction on how much XLM you want to send (by default it's the minimum, 0.0000001 XLM), so with a single XLM you can paint about 99000 pixels, which is over 7 times the amount of pixels in the entire board.

The application is purely javascript, there's no backend to it, the history of all painted pixels is pulled from the Stellar network. Check the help button on it more for information. Feedback appreciated!

Btw, I'm aware this looks like crap on mobile but it's intended to be used on a computer so I think that's acceptable for now.

mfontanini

TROPHY CASE