cek

Mermaider is a dotnet lib for generating Mermaid diagrams. I love it because it is self-contained and fully AOT.

I recently submitted PRs to flush out the types it supports; v0.9.0 now supports all 24 major Mermaid diagram types.

From the report:

> This time, we used the free/consumer versions of ChatGPT, Copilot, Perplexity and Gemini.

IOW, they tested ChatGPT twice (Copilot uses ChatGPT's models) and didn't test Grok (or others).

"In matters of taste, there can be no dispute." -dad

I know this is HN, and my instincts tell me posters here predominately are either ICs or managers "in the small" (line level, or at the most at the scale of the OP, in which the company is ~300).

That said, asserting that most meetings are either brainstorming or decision making, is naive. When an organization grows beyond ~100-150 people (Dumbar's Number) the org must metastasize into smaller, "self-contained", orgs that are far less than that number. Once this happens, there is need for meetings that drive accountability, closure, and alignment at scale. For example, monthly or quarterly business reviews.

These are NOT brainstorming meetings or decision-making meetings. They are meetings where leadership drives accountability and alignment by ensuring light is shined (in a way visible cross-org) on the right topics for the biz.

Interesting grammar and spelling (or lack thereof):

> "OpenAI's GPT-3 learns commen-sense knowledge"

I want this, but for MrCool units!

Instead of viewing Dunbar's number as a law, I view it as a sometimes useful, mental model. This article is about how Dunbar's number, as a mental model, breaks down when applied to social media. It makes a strong case for that.

Like all mental models, Dunbar's number is not perfect. However, readers who stop after the introduction of this article may be left thinking it's not useful at all.

I find it very useful in helping leaders in early-stage organizations that are growing fast recognize why the tools & techniques they've used to get to 30-80 people are breaking down as they approach 100-150 people. It helps frame why new tools & techniques for organization and communication are required.

Came here to say same thing.

There's actually a near-infinite amount of land.

We just haven't yet gotten to the point where we can access any of the land not on this planet.

Bummed these don't seem to have the powerline symbols.

But <3 anyway.

Really?

Graphical.

Duh.

Just the latest .NET Core runtime.

Terminal.Gui really has become "WinForms-in-the-terminal". A lot of the capabilities borrow from WinForms and other popular GUI frameworks. We're not afraid of plagerising.

Check out the list of built-in View classes:

https://gui-cs.github.io/Terminal.Gui/articles/views.html

I'll work on updating the history section of the README to make this more clear.

Do you happen to use "F7 History" [1] which is based on `Out-ConsoleGridView`, which, in-turn is built on Terminal.Gui?

If not, why not? (Because I'd love to make it even better).

[1] https://github.com/gui-cs/F7History

This is NOT "literally a port of an older curses lib to the latest .net". It is a complete API for building terminal UI applications using .NET that leverages curses under the covers when running in a non-Windows environment (on Windows it uses the native Windows console APIs).

For completeness, Terminal.Gui is built on top of a "Console Abstraction Layer" (CAL; I just invented that term), via the "ConsoleDriver" base class. There are four subclasses provided:

- CursesDriver: Uses curses and is the default on Linux/Mac.

- WindowsDriver: Uses the Windows console API and is the default on Windows (only works on Windows)

- NetDriver: Uses the .NET console API and works on all platforms

- FakeDriver: Used for unit testing.

NetDriver is the slowest. WindowsDriver is the fastest. CursesDriver is the biggest bugfarm ;-).

The Terminal.Gui library itself doesn't provide any special means for dealing with state. However, the full power of .NET Core is available for devs to do whatever they please.

Because I (apparently incorrectly) assumed a lot of people would appreciate the fact the mouse works so well.

Also, because getting the mouse to work well (across Windows, Mac, Linux, etc...) is freaking hard and the Terminal.Gui team is proud of their work ;-).

I posted this above too, but for completeness... Blazor support is under development:

https://github.com/Blazor-Console/HACC/blob/main/README.md

Terminal.Gui maintainer here...

We view the mouse as optional. We want the mouse to work perfectly, but it should be optional. If any of the library doesn't work well with just a keyboard, please submit an issue!

Terminal.Gui maintainer here...

We're working on it [1]

[1] https://github.com/Blazor-Console/HACC/blob/main/README.md

Definitely ranks up there.

My favorite is still INTERCAL [1] since the result is actually useful, and it ranks high on the levity meter.

[1] https://en.wikipedia.org/wiki/INTERCAL

"has left some of the more complicated use cases for later."

Er, Stacey, you mean "most interesting".

But better late and lame, than never.

Remember, the great thing about Smart Home standards is there are so many to choose from.

Wild coincidence or destiny?

I’m in the space industry. I’ve wanted to visit NZ for ever. Here now, finally. 3 days ago I toured the Ashburton museum and saw this ball.

Now this gets posted on HN which I’ve been ignoring for the last year.

As I was reading the article (in which I learned a ton about Rust, of which I know little), I kept thinking "I know that guy!".

Then I realized the OP was THE "Bunnie" of Xbox reverse engineering fame [1]. <3

[1] https://en.wikipedia.org/wiki/Andrew_Huang_(hacker)

While we're piling on the TUI renaissance, check out Terminal.Gui, a cross-platform library that makes building great terminal UI's easy:

https://github.com/migueldeicaza/gui.cs

(Disclaimer, I maintain Terminal.gui).

I built a cross platform app to print 'pretty formatted' source code [1]. I didn't want to re-invent the wheel on formatting source code, so looked at all the existing libraries. Originally I figured formatting to HTML, and then building a print-friendly HTML render would work. But this proved super challenging. I tried a dozen HTML engines (including Chromium) but none gave me enough control to render just a single page of the original source file.

Then I noticed Pygments, a Python-based library for pretty formatting source code, has an option to output an ANSI formatted file. I quickly found a bunch of libraries that could render ANSI formatted text to a print canvas.

In the end, I put the original source code file through 'pygmentize -16m -o tempfile.an` (`16m` is the 16M color terminal ANSI formatter) and pipe the `tempfile.an` through a print-optimized renderer to actually print the source code.

ANSI escapes FTW!

[1] WinPrint - https://github.com/tig/winprint [2] https://pygments.org/

Kindel's 2nd Law – Companies with a subscriptions-based business model eventually behave in ways hostile to that company's customers.[1]

[1] https://ceklog.kindel.com/2019/07/30/kindels-2nd-law/

Also, who else noticed the poster is @fortran77? Oh, the irony.

(I cut my teeth with Fortran 77 on a VAX 11/780).

There's no real data behind this article. It's basically ageism fueled by self-doubt.

It really comes down to the tenets I posted above from Amazon. At MS there was a propensity for folks in these roles to just pontificate. We called them "Architecture Astronauts". As an example, they were rarely practitioners (they rarely wrote code).