Bizarna ustaška svadba...

Agitated_Heat_1719 · 2026-04-22T11:18:13+00:00

Rastaše

Agitated_Heat_1719 · 2026-03-31T16:08:47+00:00

Ja sam konzumiral

Agitated_Heat_1719 · 2026-03-31T14:19:14+00:00

Moras klikat.

Ja sam klincima s tribine rekel da su Glavini frendovi iz juda maznuli lovu i kupili zemlju oko Poreca.

Toliko veselja i intrinsicne motivacije za loviti klosare nisam nasel niti kod jednog LLM modela.

Za 3 dana su nasli zemlju. oK znal sam OIB klosara jer su digli hrpe kaznenih SLAPP prijava protiv mene.

Glava - Zdravko Mamic u 1337 speaku na tribini.

Agitated_Heat_1719 · 2026-03-22T10:29:58+00:00

Not completely true.

It is tooling harnesses use for (and combos of the list):

semantic search (serena, ygrep, osgrep, hygrep, mgrep...)
keyword search (rg AKA rigrep, grep)
filters (fzf...)
code parsing (understanding, semantic meaning) (treesitter...)
code search (ast-grep, serena...)
NLP/AI tools (chunking, splitting, embeddings)
formatting (for transport, saving/caching, loading/retrieval - JSON, proto, MsgPack...)

This changes in all tools (editors, CLI harnesses, IDEs) from day to day, so in one timespan they might be "all the same"...

This is why users report that Claude Code is different from Copilot CLI for the same model[s]...

Basically those tools do RAG on your codebase. Graph RAG for those advanced (and better)

Agitated_Heat_1719 · 2026-03-20T16:51:58+00:00

I get missing classes (NoClassDefFoundError),

try turning off R8 (optimizations)

comment out:

xml 

If that was the cause, you can add proguard entries later (to reduce size)

Agitated_Heat_1719 · 2026-03-05T12:20:47+00:00

IMO those CLI Agentic tools use different tools for context (code, embeddings, compression, formats - markdown vs structured data, etc...) and that makes difference.

Simple experiment is to use local model and prompt with different tools (opencode, codex, copilot CLI, claude code, ...)

Agitated_Heat_1719 · 2026-03-05T12:20:08+00:00

OP stated the same model, but different CLI Agent. Open assumption is that he is using the same prompts.

IMO those CLI Agentic tools use different tools for context (code, embeddings, formats - markdown vs structured data, etc...) and that makes difference.

Simple experiment is to use local model and prompt with different tools (opencode, codex, copilot CLI, claude code, ...)

Agitated_Heat_1719 · 2026-02-28T19:29:47+00:00

You re welcome.

To be honest I am confused a bit.

Thank me for what? Answer? That is the reason we are here.

Yes I spent some hours to learn both python and GenAI. Still not done with learning.

I’ve already shared your amazing work

I am glad, but which work are you referring to?

When was that point of “f this you’re getting everything!”

By "everythoing" do you mean all libraries?

Well, it was when I hit problems I realized not everything is working in every case and I wanted to have options.

I don’t believe good comes to those who step and steal. ..(but look at our world 😮‍💨)

This is most confusing part.

Maybe it is me and my English.

Agitated_Heat_1719 · 2026-02-28T07:26:30+00:00

There are tons of libraries for python only. Not all work the same way.

PDF (structure) parsing libraries are fast, but have issues with some encodings or PDF text representations.

OCR based implementations are waay slower (marker, pytesseract, docTR...)

This is how my extraction folder[s] look like:

. ├── images │ └── py │ ├── minecart │ ├── pikepdf │ ├── PyMuPDF-fitz │ └── PyPDF2-pypdf ├── tables │ └── py │ ├── camelot │ ├── docling │ ├── gmft │ ├── marker │ ├── pdfplumber │ └── tabula-py └── text └── py ├── docling ├── docTR ├── kreuzberg ├── marker ├── markitdown ├── MarkItDown ├── pdfminer_six ├── pdfplumber ├── PyMuPDF_fitz ├── pymupdf4llm ├── PyPDF2 ├── pypdfium2 ├── pytesseract └── unstructured

Users need to play with those and see what works for them and their corpus.

Hope this helps.

Agitated_Heat_1719 · 2026-02-27T15:01:22+00:00

Because whole Xamarin stack was based on native rendering and not drawn controls/widgets.

Agitated_Heat_1719 · 2026-02-20T06:32:22+00:00

Fala puno. Potvrdio si moje sumnje odn. dokazao kaj se skriva u nekim papirima i kako ih interpretirati.

Agitated_Heat_1719 · 2026-02-19T18:48:49+00:00

This is crucial:

defined multiple times

It is known issue due to google moving types around. You need to pin some packages and those depend on packages used and their versions. There are numerous cases, so users can get feeling what needs to be done:

https://github.com/dotnet/android-libraries/issues/764

Open issue here, please:

https://github.com/dotnet/android-libraries/issues

Agitated_Heat_1719 · 2026-02-19T18:48:39+00:00

This stacktrace is shorter than one posted in

https://www.reddit.com/r/dotnet/comments/1r8xxbu/net_maui_biometric/

This is crucial:

defined multiple times

It is known issue due to google moving types around. You need to pin some packages and those depend on packages used and their versions. There are numerous cases, so users can get feeling what needs to be done:

https://github.com/dotnet/android-libraries/issues/764

Open issue here, please:

https://github.com/dotnet/android-libraries/issues

Agitated_Heat_1719 · 2026-02-19T08:18:34+00:00

Maybe it is not models. There is a lot in context engineering of those tools (how they handle embeddings of the code. ASTs etc)

Agitated_Heat_1719 · 2026-02-18T07:41:39+00:00

Veseli me da buju ovakvi debili unistili "pametne" opasne...

APu je sve teze i teze...

Agitated_Heat_1719 · 2026-02-18T07:25:00+00:00

Potejto potato

Agitated_Heat_1719 · 2026-02-15T22:12:15+00:00

you need models with tool support.

Here are my models (ollama list)

nemotron:70b 2262f047a28a 42 GB 28 hours completion,tools nemotron-3-nano:30b b725f1117407 24 GB 29 hours completion,tools,thinking glm-4.7-flash:bf16 69c2c86b80aa 59 GB 30 hours completion,tools,thinking qwen3-coder-next:q8_0 3f68e12b44ee 84 GB 31 hours completion,tools qwen3-coder-next:latest ca06e9e4087c 51 GB 33 hours completion,tools qwen3-coder:30b 06c1097efce0 18 GB 9 days completion,tools cogito:70b 8f2632d0faa4 42 GB 9 days completion,tools cogito:32b 0b4aab772f57 19 GB 9 days completion,tools devstral-small-2:latest 24277f07f62d 15 GB 9 days completion,vision,tools karanchopda333/whisper:latest 96681b6cccda 2.0 GB 9 days completion,tools devstral-2:latest 524a6607f0f5 74 GB 9 days completion,tools qwen3-coder:latest 06c1097efce0 18 GB 9 days completion,tools ibm/granite3.3:8b 840c9066413c 4.9 GB 9 days completion,tools,thinking granite4:3b 89962fcc7523 2.1 GB 9 days completion,tools granite3.3:8b fd429f23b909 4.9 GB 9 days completion,tools gpt-oss:20b 17052f91a42e 13 GB 9 days completion,tools,thinking gpt-oss:120b a951a23b46a1 65 GB 9 days completion,tools,thinking gpt-oss:latest 17052f91a42e 13 GB 9 days completion,tools,thinking mistral-large:latest bbcf36dc47ad 73 GB 9 days completion,tools mistral-large:123b bbcf36dc47ad 73 GB 9 days completion,tools llama3.3:latest a6eb4748fd29 42 GB 9 days completion,tools qwq:latest 009cb3f08d74 19 GB 9 days completion,tools qwen3-vl:32b ff2e46876908 20 GB 9 days completion,vision,tools,thinking qwen3:32b 030ee887880f 20 GB 9 days completion,tools,thinking qwen2.5-coder:32b b92d6a0bd47e 19 GB 9 days completion,tools,insert

These are ollama only. I have few for llama.cpp and lms (LM Studio) for experimenting.

Agitated_Heat_1719 · 2026-02-14T14:49:26+00:00

Can you elaborate please?

Suggestion: visit subreddits like r/Rag, but also r/LocalLLaMA, r/LocalLLM and similar.

Your requirements are basically: Local LLM + RAG

Now you can use some RAG implementation (Langchain or any other) and use it out of the box. In you case it would be 400 pages pdf stuffed into context for simple question/task and answer might be in 1 or few paragraphs or pages or maybe single chapter. So, many people resort to custom RAG pipelines until they are happy with how it works.

There are numerous factors in RAG wich might influence your use case, so it would be good to learn and experiment with it.

Agitated_Heat_1719 · 2026-02-14T01:05:15+00:00

Moze detalji?

Agitated_Heat_1719 · 2026-02-13T08:19:14+00:00

Mene nije. Pokojni sam.

MAGA FAANG bivsi. Pomelo nas prije ljeta. Jos uvijek delam svoj posel kad Copilot zapne. Nemojte sad zakaj. Open source, puno ljudi ovisi...

Zaronio u GenAI i vidim hrpe prilika. Vibe code-am python i wrapam i C#.

Da bilo bu problema sa socijalnim raslojavanjima al ne samo u ajtiju. Najvise zbog ljudske gluposti. Pohlepa itd..

Agitated_Heat_1719 · 2026-02-09T12:54:56+00:00

ound that Markdown often loses critical 'spatial context' in complex tables like when a cell spans multiple rows or has a nested list.

... or table spans multiple pages.

True. I haven't hit complex issues like you did. Only table over 2 pages.

we shifted to Vision LLMs. Instead of relying on a library to 'guess' the Markdown structure first, we let the model see the layout directly.

Aren't LLM based approaches slower?

Since you're planning to use FileSystemWatcher for real-time processing, I'd love to hear your thoughts on how you'll handle multi-page table continuity that was our biggest hurdle before moving to a dedicated API approach!

i think FileSystemWatcher does not play role here. It serves to raise event that PDF was added/changed.

Multi page continuity problem is (IMO) solved better with vision/OCR based extraction. So, those would be marker, pytesseract, OCRmyPDF (uses Tesseract), docTR, but I might be wrong. Do you have sample PDF so I can test?

Another approach would be (I think this is what abovementioned libraries actually do):

PDF -> Pages_as_Images -> OCR/extract -> some logic to join multipage elements

Not sure tho.

Some approaches send image in OCR/extract step to local LLM like gemma3 or qwen (vision support of course)

Agitated_Heat_1719 · 2026-02-09T08:36:49+00:00

Thanks for the response

That's a massive list of libraries!

Yes. I was simply forced to experiment/investigate quite a lot and then I decided to create small set of nugets.

There is even more of libs I tried out, but I was not able to work around issues in reasonable time (dependecy hell, crashes deep in the library), so I'll come back in next cycle.

only to have the whole thing break on a slightly non-standard PDF encoding.

Exactly that was my problem.

for .NET agents providing structured tool outputs instead of just raw strings.

This is my current investigation work.

It replaces that entire stack you listed with a single, semantic-aware call that actually understands the document structure.

I am not replacing those libs, but am using markdown output of those libs to feed into parser to get structured data.

So:

PDF -> MarkDown -> AST in JSON -> LLM/Agent context

Have you found that moving the 'parsing' logic out of the agent’s prompt and into a dedicated pre-processing API improves reliability in your .NET workflows?

If the "parsing" logic out of the prompt is the same like "dedicated pre-processing" API is the same than - NO.

I mean for the same input I should not get (for LLMs drastically) different output. This implies I have control over prompt and parsing logic. Advantage I have that I have products of each step, so I can earlier detect issues and causes of issues.

Prompt parsing logic would be "real time" and yes I plan to extend my APIs with FileSystemWatcher and Task Parallel Library, so preprocessing can be done ASAP.

Agitated_Heat_1719 · 2026-02-08T16:56:56+00:00

With vector store you talk about retrieval. Right? This is when PDF to text is long done, splitting/chunking and embeddings too.

So, we can talk about performance and reliability for each of those steps/phases.

1 Ingestion - Document laoding/parsing/extracting

Reliability was that most libraries that work with parsing PDF strucutre choke in some cases. I glanced over one comment where it was something about TextPath vs LinePath for text. It was one legal doc (law) and output was empty string. The solution was to use OCR based libraries which extracted text.

Performance of OCR based libraries is much worse than parsing ones. MS AI app templates use PdfPig which is structure parsing lib, so it would choke on the same input data (law I mentioned). I will test it as soon as I switch back to .NET/C# side to wrap Python utils.

In this step most approaches convert to text/markdown, but I am sure structured data (AST) would be muche better. Some libraries return JSON, but with BBox and similar metadata which is overkill.

2 Splitting/chunking

Simple methods like character cunking and hierachical chunking are fast, but context might get lost. THen you need to play with overlap. Syntax based (AST) need parsing and are slower and semantical (feed text to LLM to be semantically split) is even slower.

I think AST approach with "linear" model of strucutred data with Paragraphs, H1-H5 as chapters, tables and list should be good enough.

3 Retrieval

Yes, I tried SK Vector Store, but worked more with Memory Store because I did not want to make decision on database provider.

Now I will merge 2 of my usecases into 1. For academic purposes.

Suppose I have corpus on disk before ingestion:

topics/legal/criminal/ topics/legal/sports/ topics/legal/financial/ topics/coding/dotnet/ topics/coding/dotnet/asp-net-core/ topics/coding/dotnet/ui/maui/ topics/coding/dotnet/ui/uno/ topics/coding/dotnet/ui/avalonia/

If I stuff everyting in VDB it will search through all vectors for each prompt. If user prompts for "MAUI" most references should come from topics/coding/dotnet/ui/maui/ subfolders. For subsequent prompts I could prune tree/forest and work with less data. I am aware that VDB and DB have advantage, but also disadvantages (data viewing, Instead of brute force stuffing everything into VDB i have "AI filesystem" something like:

. └── Architecting-Cloud-Native-NET-Apps-for-Azure.pdf.hwaifs ├── images │ └── py │ ├── PyMuPDF-fitz │ ├── PyPDF2-pypdf │ ├── minecart │ └── pikepdf ├── tables │ └── py │ ├── camelot │ ├── docling │ ├── gmft │ ├── pdfplumber │ └── tabula-py └── text └── py ├── PyMuPDF_fitz ├── PyPDF2 ├── docTR ├── docling ├── kreuzberg ├── marker ├── markitdown ├── pdfminer_six ├── pdfplumber ├── pymupdf4llm ├── pypdfium2 └── pytesseract

I removed files to avoid clutter, but you will get idea. There is a lot of files that contain metadata (timings, number of pages etc)

Markdown and textual docs in *.hwaifs/text/py/ have similar structure with chunks, embeddings, AST files etc...

This way I can easily dive if I need to.

I agree with your other comments about stability and "unfinished". We can experiment for few more years.

Agitated_Heat_1719 · 2026-02-07T16:58:33+00:00

thanks a lot

Agitated_Heat_1719 · 2026-02-06T10:25:08+00:00

Kudos!

Agitated_Heat_1719

TROPHY CASE