Программирование[11]

Encantador написал 4 минуты назад:

Vova написал 1 час назад:

Давай ты сначала будешь спрашивать у ИИ прежде чем писать хуйню?

 

Я специально тебе долбаебу написал про миллиард строчек кода

Какой же ты тупой и упертый хуесос, последний раз отвечаю на твой понос тупости. 

 

1. Какая нахуй разница сколько у тебя строк кода? Эти тулы существуют десятки лет и всегда могли работать и нормально искать в больших кодовых базах. То что для тебя это открытие лишь показывает какой ты ограниченный еблан. Я хуй знает как ты вообще работаешь в этой сфере и тебя до сих не сменили ИИшкой.  

 

2. С какого хуя ИИ будет тебе сливать как у него работает internal tools в деталях? Всю эту инфу люди сливают разными методами в обход system prompts. Меня больше поражает что ты не понимаешь таких банальных вещей и выставляешь себя дауном пытаясь со мной спорить. Я понимаю если бы ты пиздел разбираясь в чем-либо. Ты же пиздишь просто чтобы пиздеть.  Не квоть меня уебище сука. 

 

https://gist.github.com/anthfgreco/87718fbbf313bcf7f5ca3f36fedb372a#grep_search

 

@Just.Doit

Вот систем промпт, где описывается нативный тул поиска по кодбазе у антигравити.

 

is it possible to do ripgrep on this whole repository

No, it is 

not possible to use ripgrep (or any standard local search tool) on the entire Google repository in the way you would on a normal project.

Why it won't work

Physical Scale: The repository is approximately 86 Terabytes. A typical ripgrep scan relies on files being present on your local disk. Downloading 86TB of data is impractical for almost any workstation.

Virtual Filesystem: Google uses CitC (Clients in the Cloud), a virtual filesystem that only "materializes" files on your machine when you actually open or modify them. Since most files don't physically exist on your drive, ripgrep would have nothing to scan.

Performance Limits: Even if you had the hardware, ripgrep is optimized for multi-gigabyte directories, not multi-terabyte distributed systems. Scanning 2 billion lines of code linearly would take hours or days, even with ripgrep's speed. 

Тупой ебанат я же тебя попросил сначала спрашивать ИИ прежде чем писать бред

Блять я не могу просто, это пиздец, пиздец

Encantador написал 11 минут назад:

Всю эту инфу люди сливают разными методами в обход system prompts. Меня больше поражает что ты не понимаешь таких банальных вещей и выставляешь себя дауном пытаясь со мной спорить. Я понимаю если бы ты пиздел разбираясь в чем-либо. Ты же пиздишь просто чтобы пиздеть.  Не квоть меня уебище сука. 

 

https://gist.github.com/anthfgreco/87718fbbf313bcf7f5ca3f36fedb372a#grep_search

 

@Just.Doit

Вот систем промпт, где описывается нативный тул поиска по кодбазе у антигравити.

Кто и что сливает долбаеб?

Это буквально открытая информация

does antigravity use ripgrep

Yes, 

Google Antigravity uses ripgrep (rg) as its internal engine for code search. 

Поздравляю, ты меня забайтил, молодец Вован, в следующий раз я буду умнее 

Encantador написал Только что:

Поздравляю, ты меня забайтил, молодец Вован, в следующий раз я буду умнее 

Я тебя не байтил

Ты просто слился обосравшись и обоссавшись

Можешь спросить других людей работающих в крупных компания - можно ли сделать grep по всей кодобазе

what if my codebase is terabytes of code

If your codebase is in the 

terabyte range, neither ripgrep nor a standard IDE-based AI agent can handle it by simply "scanning" everything on the fly. At that scale, traditional file-system searching hits a wall.

To handle a repository of that size, the workflow shifts from local searching to distributed indexing. Here is how a tool like Antigravity (and similar enterprise-grade AI systems) manages massive scales:

1. The "Search" Problem: From ripgrep to Indexed Search

While ripgrep is incredibly fast, it still has to read files from the disk. For a terabyte-scale codebase:

The Bottleneck: Disk I/O and CPU cycles become prohibitive.

The Solution: Antigravity typically interfaces with an enterprise-grade search index (like Google's internal "Kythe" or "Sourcegraph"). Instead of running rg on your local machine, the AI sends a query to a remote server that has already indexed the code into a searchable database.

2. The "Context" Problem: Retrieval-Augmented Generation (RAG)

A terabyte of code cannot fit into a large language model's (LLM's) context window, even with Gemini's 1M+ token limit. Antigravity uses RAG:

Embeddings: Code is broken into small chunks and turned into mathematical vectors.

Vector Database: These vectors are stored in a database.

Semantic Retrieval: When a question is asked, Antigravity searches the database for the most relevant snippets of code, rather than trying to read the whole repo.

3. Structural Graphing (Symbol Maps)

For very large repos, understanding "where a function is defined" is more important than "where a string exists."

Global Symbol Maps: The system uses pre-computed graphs of how different services and libraries interact.

Dependency Analysis: Antigravity relies on these maps to jump between relevant files without needing to "search" every folder in the terabyte-sized directory.

4. Selective "Ghosting" or Sparse Checkouts

In massive monorepos (common at Google-scale), the entire terabyte is rarely on a local SSD.

Virtual File Systems: Only the metadata for the files might be local.

On-Demand Fetching: When Antigravity needs to read a file it found via index, it fetches that specific file from the cloud, analyzes it, and then discards it to save space.

Vova написал 45 минут назад:

Kant написал 1 час назад:

когда уже меня заменят, и я смогу не пойти на работу 

 

Есть хоть один пруф что ты не ИИ?

ты хуй

Kant написал 12 минут назад:

Vova написал 58 минут назад:

Kant написал 1 час назад:

когда уже меня заменят, и я смогу не пойти на работу 

 

Есть хоть один пруф что ты не ИИ?

ты хуй

Хорошая попытка но нет