mach VS devdocs

Myself and many others are betting on Zig in major ways, I truly think it has a bright future ahead.

In spare time, myself and a few others are working on a game engine in Zig[0], and the Zig core team has been very receptive to addressing issues our project faces and supporting us.

Others are working on pixel art editors[1], open source 2D RPG games[2], there's a group of independent folks working on a 3D massive immersive sim game[3], a group working on making Zig an amazing language for micro-controllers[4], etc.

Please consider donating $5-10 a month to the ZSF! They are a great group of people, and it has so many knock-on effects for others in the FOSS community. :)

[0] https://machengine.org/

[1] https://github.com/foxnne/pixi

[2] https://github.com/foxnne/aftersun

[3] https://github.com/Srekel/tides-of-revival

[4] https://github.com/ZigEmbeddedGroup

I don't know if there's anything better than a zip. For our website[0] which includes a bunch of docs for our game engine, Zig packages, etc. we just offer a link "offline version of this site" in the footer which is an ~80MB zip file.

I think the challenge with zip files is.. do you want all the images? do you want all versions of the docs, or just a specific version of the docs? It's hard to tailor the zip to the user's desire. But zip still seems to be the best.

[0] https://machengine.org/

Cool to see others working on this problem. I hope more people do.

Funnily I've seen a lot of programmers and math folks who express how truly, genuinely beautiful Beziers and the math behind them are. But I've never met an artist or graphic designer who didn't express some deep frustration at Bezier controls and how hard they are to work with.

There are even games[0] which make a mockery out of how hard Bezier controls are to use, where the game is purely using the controls.

Controls are just one side of the problem, in my view; the other side is that cubics are terrible for GPUs, they don't understand them - and I believe many of the best 2D graphics libraries today are not even fully GPU accelerated, e.g. Skia. There are folks working on compute shader-based approaches, where we try to shoe-horn this CPU-focused algorithm into GPUs and pray - but it still isn't really suitable.

The controls suck for artists, and the math sucks for GPUs. This is only true of cubics, if you restrict yourself to quadratics (although that brings other challenges), both the control issue goes away (you can just click+drag the curve!) and the performance issue goes away (quadratics are triangles, GPUs love them)

That's the summary of the talk[1] I gave at SYCL'22. In that talk, I didn't have time to present the downsides of quadratics (which are real) - so if you watch it please keep that in mind - but my overall point I think is a solid one: the controls suck, and GPUs can't handle them.

The only reason we stick with cubics in its current form is because of SVG, compatibility with existing tooling, etc. But isn't it crazy? We have new bitmap image formats all the time, and so few vector graphics formats.

In Mach engine[2] we're continuing to explore this space, end-to-end, from author tooling -> format -> rendering. I'm not claiming we have a perfect solution, we don't, but we're at least thinking about this problem. Kudos to the authors of this article for thinking about this space as well.

[0] https://bezier.method.ac/

[1] https://www.youtube.com/watch?v=QTybQ-5MlrE

[2] https://machengine.org

A game engine https://machengine.org is being written in zig, there's also https://microzig.tech as zig is well suited to embedded development.

https://github.com/hexops/mach (shameless plug)

Zig fits pretty naturally here too. We've got ~19 WebGPU examples[1] which use Dawn natively (no browser support yet), and we build it using Zig's build system so it 'just works' out of the box with zero fuss as long as you grab a recent Zig version[2]. No messing with cmake/ninja/depot_tools/etc.

WASM support in Zig, Rust, and C++ is also not equal. C++ prefers Emscripten which reimplements parts of popular libraries like SDL, for me personally that feels a bit weird as I don't want my compiler implementing my libraries / changing how they behave. Rust I believe generally avoids emscripten(?), but Zig for sure lets me target WASM natively and compile C/C++ code to it using the LLVM backend and soon the custom Zig compiler backend.

[1] https://github.com/hexops/mach-examples

[2] https://github.com/hexops/mach#supported-zig-version

We're building Mach which aims to be competitive with Unity/Unreal/Godot in spriti, but super modular / let you pick and choose which parts to use or build yourself.

git clone --recursive https://github.com/hexops/mach-examples cd mach-examples/ zig build run-sprite2d

Hi HN,

I am Jiayuan, and I'm here to introduce a tool we've been building over the past few months: Devv (https://devv.ai). In simple terms, it is an AI-powered search engine specifically designed for developers.

Now, you might ask, with so many AI search engines already available—Perplexity, You.com, Phind, and several open-source projects—why do we need another one?

We all know that Generative Search Engines are built on RAG (Retrieval-Augmented Generation)[1] combined with Large Language Models (LLMs). Most of the products mentioned above use indexes from general search engines (like Google/Bing APIs), but we've taken a different approach.

We've created a vertical search index focused on the development domain, which includes:

- Documents: These are essentially the single source of truth for programming languages or libraries; I believe many of you are users of Dash (https://kapeli.com/dash) or devdocs (https://devdocs.io/).

- Code: While not natural language, code contains rich contextual information. If you have a question related to the Django framework, nothing is more convincing than code snippets from Django's repository.

- Web Search: We still use data from search engines because these results contain additional contextual information.

Our reasons for doing this include:

- The quality of the index is crucial to the RAG system; its effectiveness determines the output quality of the entire system.

- We focus more on the Index (RAG) rather than LLMs because LLMs evolve rapidly; even models performing well today may be superseded by better ones in a few months, and fine-tuning an LLM now has relatively low costs.

- All players are currently exploring what kind of LLM product works best; we hope to contribute some different insights ourselves (and plan to open source parts of our underlying infrastructure in return for contributions back into open source communities).

Some brief product features:

- Three modes: - Fast mode: Offers quick answers within seconds. - Agent mode: For complex queries where Devv Agent infers your question before selecting appropriate solutions. - GitHub mode(currently in beta): Links directly with your own GitHub repositories allowing inquiries about specific codebases.

- Clean & intuitive UI/UX design.

- Currently only available as web version but Chrome extension & VSCode plugin planned soon!

Technical details regarding how we build our Index:

- Documents section involves crawling most documentation sources using scripts inspired by devdocs project’s crawler logic then slicing them up according function/symbol dimensions before embedding into vector databases;

- Codes require special treatment beyond just embeddings alone hence why custom parsers were developed per language type extracting logical structures within repos such as architectural layouts calling relationships between functions definitions etc., semantically processed via LMM;

- Web searches combine both selfmade indices targeting developer niches alongside traditional API based methods. We crawled relevant sites including blogs forums tech news outlets etc..

For the Agent Mode, we have actually developed a multi-agent framework. It first categorizes the user's query and then selects different agents based on these categories to address the issues. These various agents employ different models and solution steps.

Future Plans:

- Build a more comprehensive index that includes internal context (The Devv for Teams version will support indexing team repositories, documents, issue trackers for Q&A)

- Fully localized: All of the above technologies can be executed locally, ensuring privacy and security through complete localization.

Devv is still in its very early stages and can be used without logging in. We welcome everyone to experience it and provide feedback on any issues; we will continue to iterate on it.

[1]: https://arxiv.org/abs/2005.11401

> I've started to preface all python searches with 'site:python.org'

You might find DevDocs to be useful: https://devdocs.io/

DevDocs - Aggregates documentation from various sources into a single, easy-to-navigate interface, covering frontend and backend technologies. DevDocs

DevDocs, an offline API documentation browser, supports multilingual, offering developers a quick and efficient way to access tech docs. From front-end to back-end and mobile development, it integrates official documentation, providing a sleek, user-friendly interface.

Environmental lighting conditions rule the day! I have astigmatism and I prefer bright backgrounds; #000 text on #fff backgrounds works great for me, but that's because I work in a room lit by a 250W 30,000 lumen corn-cob LED bulb[0] that makes my small office as bright on the inside as the shaded ground from a tree on an overcast day (which is quite bright compared to usual indoor lighting). In a room that bright, high contrast text works great and is highly readable, with "dark mode" often looking washed out and muddy. Even small reductions in contrast (such as what https://devdocs.io does with text of #333 in light mode) can make me notice and wish for greater contrast.

[0] - https://www.benkuhn.net/lux/

Here's how to add a new scraper: https://github.com/freeCodeCamp/devdocs/blob/main/.github/CO...

Or open an issue and wait for somebody else to implement the scraper.

Imagine a single, intuitive platform where you can access comprehensive documentation for a vast array of programming languages, frameworks, libraries, and tools. That's the magic of DevDocs. This exceptional resource eliminates the frustration of juggling multiple tabs and websites in your quest for information. DevDocs brings everything together into one easy-to-use interface.

Mosh for a stable connection, Offline documentation such as msdn, wikipedia (via kiwi etc), zeal for local access to https://devdocs.io/; Self host tabby for ai autocompletion. For many shell programs check what mulinux was using back then, and what are the modern replacements such as elinks instead of links. Mutt for mail, for irc doesn't matter much, use a desktop one but setup a bouncher on a vps, I used to have one on a raspberry pi 1, you can use rss reader for reddit (not sure if still works) and blogs