Create accountLogin

Recent searches

No recent searches

Search options

Not available on musician.social.
musician.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon site for Musicians and people into Music

Administered by:

Server stats:

155
active users

musician.social: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#ascii

1 post1 participant0 posts today
Public
Paolo Amoroso

What sets apart the Cascii web-based ASCII diagram editor from similar tools is it manipulates whole shapes, not just individual characters, and can save them for further modification. Plus it's shokingly easy to self-host and run locally.

github.com/casparwylie/cascii-

GitHubGitHub - casparwylie/cascii-core: A web-based ASCII and Unicode diagram builder written in vanilla JavascriptA web-based ASCII and Unicode diagram builder written in vanilla Javascript - casparwylie/cascii-core
#diagrams#ascii#unicode
Public *
Light🐧⁂

I think I found an easter egg in neovim :neovim: just by chance, I typed ":smile" as a command and it gave me an ASCII art as the output. 🤩
Video below shows the output, I had to record the output because if I took only a screenshot more then half of the output would had been cut off. I know a screen cast is a bit too much just to show an ASCII art, but this is the only way that I can show the whole output. 😅

GIF
#neovim#nvim#easteregg
Public
Olly 👾

Porting Doom to Typescript Types took 3.5 Trillion Lines, 90GB of RAM and a full Year of Work.

The feat was devised by Software Engineer Dmitri Mitropoulos, founder of Michigan Typescript and co-founder of Squiggleconf. He released a video showcasing the results of a year-long effort to get Doom running inside of Typescript's Types system.

youtu.be/0mCsluv5FXA

Dmitri Mitropoulos explains that the project was a year-long struggle, due to having to write his own tools, including 12,364 handwritten tests, learning C, C++, WebAssembly & other languages. "I did develop what I believe to be the largest Typescript codebase ever", the developer explained. Before optimization, he calculated that the project could take up to 1.25 Petabytes of data, with the first frame compiling after three months of continuous type instantiation. Every type within the project was thousands of lines long, and the project involved developing a virtual machine inside of the Types system, complete with elements like RAM and Disk Space. "The computer is made of Typescript Types that serve as logical implementations of all 116 WebAssembly instructions Doom needs to run."
[ImageSource: Dmitri Mitropoulos] Typescript is a language built on top of Javascript, that add static typing to catch many errant mistakes before your executes, think of it as guardrails which check that functions and other variables are being used correctly. While this is commonly used in all kinds of development, it's unheard of to run a game within Typescript's Type system. The port itself runs inside three and a half trillion lines of types, totalling a gargantuan size of 177 TB. This is run through Typescript's Type tracker, which takes 12 days to compile the first frame of Doom (0.0000009645 fps). This meant that 20 million type instantiations were running every second in order to get the output. Mitropoulos explained in the Michigan TypeScript Discord server that this could be improved to take "1 to 12 hours", as long as someone works on it, with the developer noting that he has notes for where potential performance optimizations could be made. <https://discord.gg/pfKUSmSY> This was done by running the project within a custom WASM runtime, which is then processed through Typescript within an editor to display a frame. <https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime>
Dmitri Mitropoulos further explained that each value within the Typescript Types system equates to a line of pixels [totalling 128,000 lines of pixels in total], resulting in a "resolution" of 320x200, displayed in ASCII. To do this, the developer needed to remove limitations within the Typescript compiler itself, highlighting just how large the project got, with the Type tracker runtime consuming over 90 GB of RAM while it was running. This huge overhead meant that common tools within Typescript could not be used, which meant that the herculean task of encoding every element of Doom in types. This required learning to develop elements like an L1 CPU cache, within Typescript Types itself. Due to Typescript requiring iteration on a single string from the left-hand side, binary algorithms had to be input in reverse. "Oh, and AI can't help" Dmitri Mitropoulos added, describing that the work was so low level that AI couldn't possibly assist with any of the tasks. Too bad, Grok 3. Mitropoulos said that he undertook the challenge after completing "every other" Types challenge, and wanted to understand why Doom wouldn't be able to run within Types. However, he managed to find "ridiculous" workarounds to make it all work, despite his own disbelief in the project.
#doom#port#typescript
ExploreLive feeds
About