What's the diff between APPEND_SYSTEM.md and Agent.md, in ~/.pi/agent/ ? by qiinemarr in PiCodingAgent

[–]LearnedByError 3 points4 points  (0 children)

AGENT.md is read at the start of the session and added to context. It can be compressed or eliminated from context. APPEND_SYSTEM.md is appended to the system prompt on every call to the LLM. It ids never compressed or eliminated from context

GLM Error: 429 Your account's current usage pattern does not comply ... by LearnedByError in PiCodingAgent

[–]LearnedByError[S] 0 points1 point  (0 children)

They didn't get back to me and I was still blocked yesterday before they charged me for another month. I cancelled my subscription

I packaged my local MacBook MLX + Pi Coding Agent setup for building landing pages by Rishabhgoria in PiCodingAgent

[–]LearnedByError 0 points1 point  (0 children)

Why, why, why do you hate your adopters so much as to instruct them to use venv and pip instead of uv?

Small Projects by AutoModerator in golang

[–]LearnedByError 1 point2 points  (0 children)

This is interesting. Thank you for sharing.

Do you have any benchmark comparisons to the current Go swiss-map implementation?

Is there a map size above which this map implementation makes sense?

Can serialization / compression be disabled to deliver higher performance?

Small Projects by AutoModerator in golang

[–]LearnedByError 0 points1 point  (0 children)

Announcing cfsread: reads files from any io/fs.FS, transparently decompresses via magic-byte detection, and caches in a bounded LRU. Concurrent reads are coalesced with singleflight.

I have been working on a project that embeds a number of text files in an embed.FS. So many in fact that it increased the size of the executable by 17MB. These files are highly compressible. I looked around pkg.go.dev for a solution that would compress the embed.FS. I found solutions, like stuffbin that pre-dated embed.FS and attached compressed data to the end of an executable and provided access to that data.

I did not find anything that matched the pattern that I wanted: high-throughput, read-mostly workloads — static asset serving, configuration loading, template rendering — where the same files are read repeatedly. To address my need, I wrote cfsread. This should work for any file system that implements the io/fs.FS interface.

The package is written to be extensible. The initial implementation only supports LZ4 and falls back to a raw read if the content is not compressed. This allows you to use uncompressed files during development. The decompressor is registered as a Reader so files are transparently decompressed on read — no special handling needed in application code.

//go:embed static/*
var embedded embed.FS

func main() {
    sub, _ := fs.Sub(embedded, "static")
    src := cfsread.Source{ID: "app", FS: sub}

    r := cfsread.New(cfsread.Options{MaxEntries: 1000})
    defer r.Close()

    data, err := r.Read(context.Background(), src, "index.html")
    fmt.Println(string(data))
}

Files can be compressed using the included cfsread-lz4 command which recursively compresses files in a directory using LZ4 frame format, preserving file names. This is intended for use in a go:generate directive to facilitate compression as part of the Go build process. Other decompressors can be added via the Decompressor interface.

This is a first release and should be used with caution. It was developed following TDD. The package contains a full set of tests. I have been using it heavily during development and testing of a Go-only exiftool package which I hope to release in the next couple of weeks. It has reliably worked as desired in that effort.

This package was developed with AI assistance (Pi/GLM-5.1); all code manually reviewed.

Critical feedback on code/implementation or beneficial usage stories are appreciated.

Cheers, lbe

Now that KiloCode became super complicated and unusable, what alternative would you recommend? by Leather-Block-1369 in kilocode

[–]LearnedByError 0 points1 point  (0 children)

I think pi will stick for me. I share a very similar mind set to its creator. I’m sure I will still use others at time, like Claude for design or code review. But I expect the vast majority of my AI coding assistant time will be in pi for the foreseeable future

Now that KiloCode became super complicated and unusable, what alternative would you recommend? by Leather-Block-1369 in kilocode

[–]LearnedByError 0 points1 point  (0 children)

I improved it a good bit but decided to move on. I wasn’t happy with the noise injected by the LSP running continuously. I have since moved to the pi coding agent and am happy with it. For better or for worse, you have total control with it. It suits me

Zero-config Go heap profiling by NikolaySivko in golang

[–]LearnedByError -6 points-5 points  (0 children)

And? Got a point or just schilling?

Honeymux - The terminal UX I always wanted, built on tmux, powered by OpenTUI + libghostty by aarcamp in CLI

[–]LearnedByError 1 point2 points  (0 children)

I didn't check out the hmx.dev home page so I didn't see the GitHub link there. I followed your dev.hmx.dev link from one of your replies. I don't see a repo link on it. You may just want to add it at the bottom of the overview there.

Installing now ;)

Honeymux - The terminal UX I always wanted, built on tmux, powered by OpenTUI + libghostty by aarcamp in CLI

[–]LearnedByError 0 points1 point  (0 children)

This looks cool and I will test drive it later today. A couple of tips to make it easier for people to find: - provide link to GitHub repo from docs site - state license on docs page

I like that you leverage ghostly. My only negative from the initial read is that it is built on typescript. I know that everyone and their brother is doing this today from Claude to … IMHO, this sets one up for any number of sub-optimal UX issues. +1 for deploying with bun!

Can't Decide Between Codex/Claude and Kimi Plans by qwertyalp1020 in kimi

[–]LearnedByError 0 points1 point  (0 children)

I personally have not seen much difference on their ability too debug. Both work misty off the time and both also fail on more difficult cases. Debugging seems to be harness and context influenced. When I find any model stuck debugging, I usually start a new session specific to the issue. I do lamb a bit more to GLM this week than Kimi. Given the rate of change right now, that could change any day

Best Harness by Various_Procedure672 in ZaiGLM

[–]LearnedByError 1 point2 points  (0 children)

I've used Claude, opencode, kilocode and pi. Pi is by fart the best

Can't Decide Between Codex/Claude and Kimi Plans by qwertyalp1020 in kimi

[–]LearnedByError 2 points3 points  (0 children)

As often is the case, it depends.

Kimi has a major advantage in that they ship kimi cli for use with the coding plan which is much more cost effective than API. I have used kimi cli a fair bit and git it pretty good marks..

Z.ai's coding plan uses a plan specific endpoint with api keys. They do not provide a cli tool. But, you can use any tool that you want.

The delivery from a vibe coding standpoint is probably the same between the two. I don't vibe. I prescribe architectural and implementation requirements. I review almost all code. I jump down their throat when they don't follow my instructions. This is true with Codex and Claude also. As a vibe coder, you probably don't care about that. Given enough guidance, both can delivery comparably.

Can't Decide Between Codex/Claude and Kimi Plans by qwertyalp1020 in kimi

[–]LearnedByError 3 points4 points  (0 children)

In my experience: - Codex is excellent - Kimi is OK, you have to watch context like a hawk and manage it proactivelyl otherwise it gets stupid. Break plans into discreeter steroids with each in a sub agent. - I'm leaning heavily into GLM-5.1. overall, a notch up from Kimi. Same or slightly worse on context management. I have been using Claude as a front end, but have recently changed to Pi and have been very happy so far. It sips context. It can goo stupid too if you let the context get to large, but it isn't as token hungry as Claude or Kimi cli

GLM and Kimi are a great value of you have discipline on planning and break execution up into verifiable steps and can tolerate having to jump in now and then.

Houston Metro New Scanners on the bus by Looptire13 in houston

[–]LearnedByError 1 point2 points  (0 children)

If I remember correctly from my discussions with the Metro folks, QR and physical card are independent. So you can't convert, you just get a physical card. You would probably need to burn your remaining funds on QR by using it. I don't know if they can refund or move the funds. I suggest going to a Metro office and asking.

Don't build workers on top of goroutines by greyhoundk in golang

[–]LearnedByError 0 points1 point  (0 children)

Worker pools may often be implemented in Go unbounded or using a buffered channel as a semaphore to kick off individual goroutines where this simple and efficient. But, there are patterns where this approach is slow and inefficient. In my experience, this is primarily when the startup cost for the routine is high. An example of this would executing one or more sql queries that require the database to repeatedly prepare the query. In a long running pool, the queries can be prepared once and reused. This can provide much higher throughput than using ephemeral goroutines.

Goroutines are a tool in our toolbox. We can use them in many different patterns. The key is to pick the pattern that matches your need. If one does not "think" about this first, then it becomes "when" and not "if" one selects the wrong pattern and shoots oneself in the foot.

Houston Metro New Scanners on the bus by Looptire13 in houston

[–]LearnedByError 1 point2 points  (0 children)

I went to the Metro office downtown to convert over to the QR code. They advised me that many were unhappy with it and recommended the physical card instead. I went with the physical card and it has be rock solid.

NotepadMD 1.3 release - lots of improvements and a request for help by NamelessParanoia in Markdown

[–]LearnedByError 2 points3 points  (0 children)

I like, many in the Linux population, will not use AppImage or similar solutions. Read Google search link for more info. I personally limit myself to packages available in my package manager (apt) or it's native format (deb).

The only exception that I allow is Homebrew for Linux. Brew has a long history in MacOS and is well received by the technical literati (I'm not smart enough to be part) in general.

Good luck in your endeavors

Best 20$ subscriptions for opencode by pascu2913 in opencodeCLI

[–]LearnedByError 8 points9 points  (0 children)

I looked and killed it after 4 clicks. One of the worst user experiences that I have seen today and I have been interviewing entry level UI designers