DEV Community: Maple

The Mention File Myth in Code Agents

Maple — Sun, 19 Jul 2026 12:55:25 +0000

Disclaimer: This post was written by me, but I used GLM 5.6 to restructure and polish the text. Parts of the investigation behind it were also done with GLM 5.6.

How it started

When Claude Code first came out, I picked up two habits from the official blog post¹ that immediately felt like upgrades: using ! to run shell commands inline, and using @ to mention a file.

Both felt handy. ! let me run commands I was comfortable with myself and feed the output into Claude's context, or simply take over the follow-up work by hand while Claude kept the full context of what happened. @ felt just as good: it let me tell Claude exactly where a file was. If I only gave it a file name, it would have to generate content to call tools and go look for the file, the location might not be accurate, and it could take several rounds of operations before it found the right one.

For a while, this was simply how I worked.

The "wasted tokens" take

A few months later, I started seeing people on X arguing against @. The argument was simple and, at the time, felt obviously correct: @ is not magic. It is a deterministic piece of client-side code that reads the file from disk, expands its contents into the user's prompt, and sends the whole thing to the LLM.² So if you @ a very large file, you are wasting an enormous amount of tokens.

That clicked for me. Of course that is how mention file had to be implemented: like ! invoking the shell, it is at heart a deterministic program, so this kind of problem is hard to avoid.

The vibe coding shift

Then vibe coding became a thing, models got noticeably stronger, and I found myself no longer using @ most of the time. Every time I watched the model work, it checked the directory structure whenever it needed to, and when I asked it to read some file, it usually already knew where the file was. Context windows had also grown across the board, so letting the model spend a few extra tool calls and round trips was not much of a cost; in exchange, I got the efficiency of describing files vaguely instead of typing exact paths. (Yes: I had discovered that the bottleneck was now me, and my typing speed.)

I didn't think about how @ was implemented again for a long time.

Building my own agent

That changed when I started building paimon, my own code agent. When it came time to implement mention file, the old question came back to me. I thought it through carefully, and suddenly it seemed the old conclusion wasn't necessarily right.

What if @ is just a local convenience for the user at input time (an autocomplete for file paths), and the program never reads any content into the prompt at all?
Or, thinking about it more: mention file really is a deterministic behavior. If the code agent has actually read a file once, could it send the full content along with more information, like a sha256 of the contents? Then the next time the file is read, if it finds it was sent before and the sha256 hasn't changed, could it send only the metadata, letting the model know it has already read this file and the hash is unchanged?
And if so, when the content does need to be expanded, how should compaction be handled? Would this need some complicated machinery to manage?

After thinking it over, I came up with a design based on passing metadata. Each mentioned file would be wrapped in an XML envelope that tells the model the file path, a sha256 of the contents, whether the enclosed content is the full file or only part of it, which lines are included, and how many lines the file actually has. Roughly:

<file path="src/parser.py" sha256="3f6a…" content="partial" lines="1-200" total-lines="1240">
...
</file>

If the full content had already been sent in the current session and the hash was unchanged, only the reference metadata would go out, letting the model know it had already read this file and nothing had changed; files over a size threshold would only get their head sent, with the real length in the metadata. Since no model has ever seen this convention, the rules would be spelled out in the system prompt. Underneath, the agent would keep an in-memory table of every file sent so far (the hash, and what exactly had been transmitted), and reset it after compaction, when "already sent in full" no longer holds. It added up to a rather complex state transition diagram.

It sounds like a bit of a hassle, but with the help of ChatGPT 5.6 sol, the states and flows got sorted out quickly. It even thoughtfully added one more design on top: when the user pins line numbers with the @filename:10-20 syntax, the fully transmitted ranges are recorded too; when a later mention of another range overlaps with what was sent before and is fully covered, the ranges can be merged. Computing those overlaps (which ranges are already covered, which partially intersect, which should be merged into one) was the genuinely fiddly part of the whole design.

Wait, didn't Cursor try this?

That was the moment it suddenly hit me: isn't this mechanism getting way too complex?

It reminded me of when Cursor first launched, and people were analyzing and guessing at how it must work under the hood. The story went: LLM context windows were small, so the code was retrieved with RAG and only the relevant snippets were sent³; some analyses went further, speculating that after a tool call finished operating on files or commands, the context around the call was dropped entirely, with just the result stitched back in. Whether or not that second part was ever true, the design people believed in looked extremely clever. But in my own use at the time, the results on longer agent-style tasks were underwhelming. Then Claude Code came out and did almost the opposite: it hunted for code bluntly with rg and other plain commands, never rolled context back, and just kept pushing everything forward until the window filled up and compaction kicked in. For me it worked dramatically better.⁴

I don't claim to fully understand how LLMs work, but seeing Claude Code's approach made me realize what that rumored design was essentially doing: treating the context window as a kind of database, assuming that anything sent to the LLM would be reliably remembered. But the attention-based LLMs popular today make no such guarantee. Content that has already appeared in the context is not reliably used, especially once it sits deep in a long history⁵, which is why the model will try to read things again.

And now I was designing exactly that kind of clever mechanism. The overlap merging, the hash-based dedup, the "just send metadata if the hash matches" trick. All of it was treating the context window as a database of record, and maybe I was making the same mistake.

Checking the facts

Fortunately, open-source code agents are everywhere now, and quite a few of them are well known. So instead of theorizing, I decided to actually investigate whether the conclusions I had reached last year were true. Using opencode with GLM 5.6, I went through five well-known open-source agents: pi, opencode, gemini-cli, grok-build, and codex.⁶

Even the very first question, whether @ sends file contents at all, splits the field. Four of the five read the file and inline it into the user message: pi wraps it in <file name="..."> (though only for files passed as CLI startup arguments; in its interactive TUI, @ is just path autocomplete and the literal path text is sent), grok-build in <file_contents path="..."> with line numbers, gemini-cli between --- Content from referenced files --- markers, and opencode fakes a tool call — the model sees Called the Read tool with the following input: {...} followed by standard Read output, as if it had called the tool itself. And then there is codex, which does not read the file at all: @ is a fuzzy filename search, and picking a result just inserts the path as plain text. The model is expected to cat or rg it when it cares. That is exactly the "maybe @ is just autocomplete" possibility from my first bullet point.

Agent	What `@` sends	Metadata beyond the path	Line-range syntax	Tracks what was sent
pi	Full content, no truncation (CLI args only)	None	❌	❌
opencode	Content through its own Read tool (2000 lines / 50 KB cap), faked as a tool call	Truncation notes: "Use offset=N to continue"	✅ `@file#12-18`	❌
gemini-cli	Full content (2000-line cap, 20 MB hard reject)	A truncation warning pointing at `read_file`	❌	❌
grok-build	Full content up to ~5,000 est. tokens, then a metadata-only stub	`skipped="true"` + reason on oversized files	✅ `@foo.rs:10-20`	❌
codex	Nothing, just the path as plain text	—	❌	❌

Then I held my paimon design up against these implementations, point by point.

Nobody sends a hash, and a file's true size surfaces only in truncation hints. The envelopes carry a path and the content, and that is essentially it (opencode's Read-style output does close with a total line count). The closest thing to my metadata design is grok-build's handling of oversized files: past ~5,000 estimated tokens it drops the body entirely and sends a stub like <file_contents path="..." skipped="true" reason="file too large (~5800 estimated tokens, limit 5000). Use read_file tool to read specific sections."/>. The truncating agents all do some version of this: tell the model it got cut off and point it back at its own read tool. Metadata as a "go read it yourself" hint, never as a dedup key.

Nobody tracks what was already sent. No hash, no mtime, no in-memory table, no "you already have this file" path. Every mention re-reads the disk and re-sends in full; the only dedup anywhere is a Set that collapses duplicate mentions within a single message. The one sha256 I found in a mention path (grok-build's) is used to name spill files on disk and never reaches the model. The one genuine counterexample is buried in gemini-cli: a ContextCompressionService that hashes file contents and asks a small model to route each old file to FULL / PARTIAL / SUMMARY / EXCLUDED, startlingly close to a chunk of my design. Except it sits behind a default-off experimental flag, nothing in the runtime actually instantiates it at the commit I read, and even if it ran, it only processes read-tool responses, not @-mention inlines. Someone had the same idea, and it has not shipped.

Line-range syntax exists; overlap bookkeeping does not. opencode supports @file#12-18 (translated into a Read call with offset and limit) and grok-build supports @foo.rs:10-20. Neither records which ranges were sent, and neither merges overlapping ones; every mention is an independent read. The overlap-merging machinery ChatGPT and I sketched exists nowhere.

Nobody explains the convention in the system prompt. All five system prompts are silent about what a mention looks like. pi and grok-build rely on the XML being self-describing; a comment in grok-build's source calls its format "the training format we have been using". opencode's fake Read call is the cleverest dodge: nothing needs to be documented, because the model already knows what Read output looks like. And codex has nothing to explain, because it sends nothing but a path.

Compaction does nothing special with mentions. In all five, when history gets summarized, inlined file content is treated as ordinary user text and fed to the summarizer wholesale: no hash routing, no placeholder substitution. My worry about "how does the state survive compaction" dissolves completely: there is no state to survive.

Nobody watches for staleness. If a mentioned file changes on disk afterwards, nothing marks the old copy in the context as expired. The model finds out whenever it next happens to read the file.

And the most telling discovery: codex used to do it the other way. In its TypeScript CLI era, codex's @ worked exactly like the others: "file contents automatically expanded into XML blocks before being sent to the LLM", in the words of the pull request that introduced it, with @path[50:80] line selection listed as a next step. The Rust rewrite replaced all of that with the path-only fuzzy search, without a word in the commit history about why content expansion was dropped, and the TypeScript implementation was later deleted outright. The only agent that demonstrably walked the "expand and enrich" road turned around and walked all the way back to the most minimal design possible.

Closing thought

So my old understanding was wrong on just about every count. In one direction, today's code agents are smarter than I imagined: most of them will not naively shovel an entire file at the LLM in one go; past a certain size they truncate, refuse, or swap in a stub that tells the model to go read the file itself. In the other direction, none of them needed the elaborate system I had been so pleased with designing. However precise the state diagram looked, the LLM does not want any of it. The model does not fail because we re-sent a file; it fails when it cannot find the file, or when we sent less than it needed. The complexity was for my own satisfaction, not the model's.

As for where this is heading: models keep getting smarter, and codex's design is a straight bet on that. Send nothing but the filename, and let the model fetch whatever it cares about. Given how well agentic search already works, I suspect this is the better way, and I would not be surprised to see more agents drift toward it.

And there is a bigger difficulty hiding behind this small one, which I only appreciated by building an agent myself. Questions like "expand the file or just send the path" cannot be settled by reading code or by taste: you have to evaluate them against real tasks, and evaluation burns tokens at a scale my previous side projects never did. A CLI tool can be verified locally in seconds, for free; an agent design decision costs real money per data point.

Worse, the answer may not transfer between models. Reinforcement learning is doing a lot of the work in making models better, and it also stamps each model with its own working style, so each vendor's CLI will naturally ship whatever mechanism its own model was trained toward and scores best on its own evals. grok-build's source says this out loud: its XML format exists because it is "the training format we have been using". For anyone building a general-purpose agent on top of other people's models, that is a quiet, permanent source of trouble: the best mechanism is not universal, and you cannot afford to measure everything.

"Claude Code: Best practices for agentic coding", originally published on Anthropic's engineering blog, now maintained as part of the official docs. ↩
The official docs still describe @ this way: "Reference files with @ instead of describing where code lives. Claude reads the file before responding." ↩
This part of the guess was roughly right, except for the "local": Cursor chunks files locally, but computes embeddings on its servers and stores them in a remote vector database, while the code itself stays on your machine. See How Cursor Indexes Codebases Fast. The "drop the tool-call context" part, as far as I can tell, was never confirmed; early Cursor didn't even have agent-style tool calls. ↩
A detail I only learned while fact-checking this post: early Claude Code had also tried RAG with a local vector database, and dropped it in favor of plain agentic search. Boris Cherny, its creator: "Early versions of Claude Code used RAG + a local vector db, but we found pretty quickly that agentic search generally works better." Another Anthropic engineer in the same thread: "In our testing we found that agentic search outperformed [it] by a lot, and this was surprising." ↩
This is a measured phenomenon, not just a vibe: models use information in the middle of a long context significantly worse than information at the beginning or end. See Lost in the Middle: How Language Models Use Long Contexts. ↩
All five checked in mid-July 2026, at commits: pi 87ad8243, opencode efb6cc2d4, gemini-cli 3ff5ba2, grok-build 98c3b24, codex 315195492c. These are moving targets; details below may have changed by the time you read this. ↩

Building a Python-requests-style HTTP Client in Haskell

Maple — Sat, 14 Mar 2026 11:16:08 +0000

The Problem with Learning Haskell

When I started learning Haskell, I always struggled to find a suitable scenario to apply it. Without a concrete problem to solve, it is difficult to make real progress.

At some point I had some practical work to do: fetch data from HTTP APIs, process the results, and post them to other endpoints. My instinct was to reach for Python and the requests library, because it is genuinely handy for this kind of task. You grab a URL, get back some JSON, transform it, and send it somewhere else. The whole thing can be done in a few lines.

But I thought: this is exactly the kind of real problem I need. Why not try Haskell?

Exploring the Existing Ecosystem

The first thing I reached for was http-client. It is powerful and the foundation for most other Haskell HTTP libraries. But using it directly requires quite a bit of setup for simple tasks. You need to create a manager, parse a request, and work with a set of low-level types. It is a great library, but it is designed for cases where you need precise control.

There are some lighter alternatives. wreq is a popular one, built on a lens API. Lenses are a fascinating part of the Haskell ecosystem and many people find them worth learning. req is another option with a clean, type-safe API. I used req to finish the work I was doing, and it worked well. But I still missed the simplicity of Python's requests, and I kept thinking about whether something like it was possible in Haskell.

Finding http-dispatch and Deciding to Build Something

Some time later, I came across http-dispatch. It was much closer to what I had in mind. The API was straightforward and the concepts were familiar. Unfortunately the library had not been maintained for a long time. There were some bugs, and some fixes in the source code had never made it to Hackage.

That is when I decided to build my own.

The goal was simple: a library for scenarios where you do not need fine-grained control over the HTTP lifecycle. For those cases, http-client is the right tool. But for the common case of making a request and getting back a response, I wanted something that felt closer to the Python experience.

The Core Abstraction

I started from the most basic mental model of an HTTP interaction: you have a request, you send it to a server, and you get back a response.

This became the core API:

data Request a = Request
  { method  :: Method
  , url     :: String
  , headers :: Headers
  , body    :: Maybe a
  }

data Response a = Response
  { status  :: Int
  , headers :: Headers
  , body    :: a
  }

send :: (ToRequestBody a, FromResponseBody b) => Request a -> IO (Response b)

The send function takes a Request and produces a Response in IO. The type parameters carry the body types, and the typeclass constraints handle serialization and deserialization automatically.

For common HTTP methods, there are simple shortcuts:

-- A simple GET request
resp <- get "https://example.com" :: IO (Response String)
print resp.status  -- 200
print resp.body    -- HTML content as String

-- POST with a plain text body
resp <- post "https://httpbin.org/post" ("hello" :: String) :: IO (Response String)
print resp.status  -- 200

You can also construct a Request manually when you need custom headers:

let req = Request
      { method  = GET
      , url     = "https://api.example.com/data"
      , headers = [("Authorization", "Bearer my-token")]
      , body    = Nothing :: Maybe BS.ByteString
      }
resp <- send req :: IO (Response String)

The library supports modern Haskell record dot syntax (resp.status, resp.body) as well as traditional accessor functions (responseStatus resp, responseBody resp) for those who prefer not to enable language extensions.

JSON Integration

The feature I most wanted to replicate from Python's requests is its JSON handling. In Python, you pass json= to your request and call .json() on the response. It handles the content type header, the serialization, and the deserialization for you. Most API work is exactly this: send JSON, receive JSON.

Haskell's type system makes this possible in a way that is, I think, even nicer than Python. Because we declare our data types upfront, we get static guarantees about the shape of the data.

Here is an example of parsing a JSON response:

{-# LANGUAGE DeriveGeneric #-}

import Data.Aeson (FromJSON)
import GHC.Generics (Generic)
import Network.HTTP.Request

data Date = Date
  { __type :: String
  , iso     :: String
  } deriving (Show, Generic)

instance FromJSON Date

main :: IO ()
main = do
  response <- get "https://api.leancloud.cn/1.1/date" :: IO (Response Date)
  print response.status  -- 200
  print response.body    -- Date { __type = "Date", iso = "2026-03-14T..." }

There is no explicit parsing step. The type annotation :: IO (Response Date) is enough to tell the library to decode the JSON body into a Date value. If decoding fails, an AesonException is thrown.

Sending JSON works the same way:

data Message = Message { content :: String } deriving (Generic)

instance ToJSON Message

main :: IO ()
main = do
  resp <- post "https://api.example.com/messages" (Message "Hello")
            :: IO (Response String)
  print resp.status

Any type with a ToJSON instance is automatically serialized, and Content-Type: application/json is set on the request. You do not need to think about it.

This gives you the simplicity of Python's requests combined with the compile-time guarantees of a static type system. You define your API shapes as types, and the compiler helps you use them correctly.

Using It for an LLM Agent

With the library in a working state, I wanted to build something more substantial with it. I decided to implement a small LLM agent. That became hasuke, a CLI tool for interacting with Claude.

Calling an Anthropic-style API is exactly the use case this library was built for. You construct a JSON request body, send it to the endpoint, and get back a JSON response. The library handled all of this without any friction.

But after building the first version, I noticed that it would sit silently until the full response was generated, then display everything at once. Modern LLM providers support streaming responses to address this: they send partial results incrementally using Server-Sent Events, so you start seeing output right away.

Adding Streaming and SSE Support

I extended the library to support streaming. The key was to express this within the existing type system without changing the core API. I introduced a StreamBody type:

data StreamBody a = StreamBody
  { readNext    :: IO (Maybe a)
  , closeStream :: IO ()
  }

To receive a streaming response, you just change the type annotation:

let req = Request GET "https://example.com/stream" [] (Nothing :: Maybe BS.ByteString)
resp <- send req :: IO (Response (StreamBody BS.ByteString))

let loop = do
      mChunk <- resp.body.readNext
      case mChunk of
        Nothing    -> return ()
        Just chunk -> BS.putStr chunk >> loop
loop
resp.body.closeStream

For SSE, the library parses the event stream protocol automatically. Each SseEvent has fields for the data, event type, and event id:

data SseEvent = SseEvent
  { sseData :: T.Text
  , sseType :: Maybe T.Text
  , sseId   :: Maybe T.Text
  }

Using it looks like this:

let req = Request POST "https://api.anthropic.com/v1/messages" headers (Just body)
resp <- send req :: IO (Response (StreamBody SseEvent))

let loop = do
      mEvent <- resp.body.readNext
      case mEvent of
        Nothing    -> return ()
        Just event -> T.putStr event.sseData >> loop
loop
resp.body.closeStream

The send function signature did not change at all. When the target type is StreamBody SseEvent, the library keeps the connection open and streams events through an internal buffer. From the caller's side, you are just getting a different kind of response body.

This is where Haskell's type system earns its keep. Adding a completely different data transfer mode required almost no changes to the existing API. The same send function, the same Request type, the same conventions. It is now working well in hasuke.

Where Things Stand

The library is published on Hackage under the name request and can be installed with cabal or stack in the usual way. The source code is on GitHub at https://github.com/aisk/request. It powers the streaming output in hasuke, which you can find at https://github.com/aisk/hasuke.

There are features still missing, such as support for HTML form encoding and some other less common use cases. I plan to add these gradually over time. If you run into something you need, feel free to open an issue on GitHub. Feedback and contributions are very welcome.

For the common case of calling JSON APIs, whether in a single response or as a stream, the library does what it was built to do. If you are learning Haskell and looking for a practical project, or you just need a lightweight HTTP client, it might be worth a try.

Making Python Modules Callable: Introducing Cadule

Maple — Fri, 26 Dec 2025 15:02:37 +0000

When writing Python code, I often find myself missing a feature from Node.js: the ability to directly require a module and have it become callable. In Node.js, you can export a function from a module and call it immediately:

const messUpThings = require('./mess-up-things');
messUpThings(); // Works!

I know some developers aren't fond of this pattern, but there are legitimate use cases for it.

The Problem

Consider a scenario where you need to write a helper function with a self-descriptive name, like mess_up_things. The function name itself tells you what it does. You have a few options:

Create a util or helper module: Put it in a util.py or helper.py module. But many developers dislike these generic names, especially Go developers who prefer more descriptive package names.
Create a dedicated file: Put it in mess_up_things.py. But then you need to write verbose import statements like:

from mess_up_things import mess_up_things

This repetition feels unnecessary. Wouldn't it be nice if you could just do:

import mess_up_things
mess_up_things()

Exploring Solutions

If you're familiar with Python's magic methods, you might know that any object with a __call__ method becomes callable. Since modules are instances of types.ModuleType, and they support magic methods like __getattr__, couldn't we just define a __call__ method directly on a module?

Unfortunately, Python doesn't support this out of the box. There was actually PEP 713 that proposed adding module-level __call__ support, but it was rejected.

However, if you're familiar with Python's runtime, you'll find there's a trick to achieve this behavior:

import sys

class MyModule(sys.modules[__name__].__class__):
    def __call__(self):
        print("Messing up things...")

sys.modules[__name__].__class__ = MyModule

This works by dynamically replacing the module's __class__ at runtime. But who wants to copy-paste this boilerplate every time?

Enter Cadule

To avoid repeating this boilerplate, I've encapsulated this simple mechanism into a package called Cadule (short for Callable [Mo]dule Less).

Installation

pip install cadule

Usage

Create a file called mess_up_things.py:

import cadule

@cadule
def __call__():
    print("Messing up things...")

Then in your Python REPL or another script:

>>> import mess_up_things
>>> mess_up_things()
Messing up things...
>>> callable(mess_up_things)
True

That's it! The entire mess_up_things module is now a callable object. When you call it, it executes the decorated __call__ function.

You can also pass arguments and return values:

import cadule

@cadule
def __call__(target):
    return f"Messing up {target}!"

>>> import mess_up_things
>>> mess_up_things("the database")
'Messing up the database!'

When to Use It

Cadule is particularly useful for:

Single-purpose modules: When a module's main purpose is to expose one function
DSL and fluent interfaces: Creating more natural-looking APIs
Scripts and utilities: Making command-line tools more intuitive

Github: https://github.com/aisk/cadule

Bringing timeout to macOS Without Installing All of GNU Coreutils

Maple — Sun, 21 Sep 2025 07:21:11 +0000

Not long ago, I was writing a shell script on macOS and ran into a small but surprising issue: there was no built-in timeout command. If you’ve spent time on Linux, you’ve probably taken timeout for granted, it’s part of GNU coreutils and is incredibly handy when you want to limit how long a command can run.

On macOS, though, the situation is different. macOS ships with a BSD-flavored set of core utilities, and GNU’s version of timeout simply isn’t there. My first instinct was to install GNU coreutils through Homebrew:

brew install coreutils

This does work—but it comes with a catch. To avoid conflicts with the BSD commands that ship with macOS (like ls and cat), Homebrew installs GNU coreutils under names prefixed with a g. So instead of ls, you get gls; instead of timeout, you get gtimeout.

That’s fine if you’re working in a personal environment, but it creates headaches for writing portable shell scripts. If I write a script that calls gtimeout on macOS, it won’t run out-of-the-box on Linux, where the command is just timeout. Homebrew does provide a way to remove the g prefix, but that’s a pretty heavy-handed solution—suddenly your system’s default ls, cat, and other tools are replaced by GNU versions, which can break expectations in subtle ways.

So, instead of going down that path, I decided to build a standalone timeout command that behaves like GNU’s version but doesn’t bring along the entire coreutils package. This way, you can install just what you need without worrying about side effects.

The project is open source and lives here:
👉 https://github.com/aisk/timeout

And to make installation easier, I also set up a Homebrew tap. You can install it directly with:

brew install aisk/homebrew-tap/timeout

That’s it—you’ll get a drop-in replacement for timeout, without the g prefix, and without swapping out your other system tools.

I built this mainly to solve my own problem, but if it helps you too, I’d really appreciate a star on the GitHub repo. Every bit of support means a lot and helps me keep the project alive.

Build and Modify Linux System Image for C-sky based Gx6605s Board

Maple — Sun, 11 Aug 2024 12:02:03 +0000

The Gx6605s is a very cheap development board (39 Chinese Yuan with free shipping), which has a C-sky instruction set based CPU. The support for Linux kernel, GCC, and even Greenlet, is upstreamed.

I have a Gx6605s board which I bought years ago, and I only tried to run it with C-sky's official system image. It's a Buildroot-based Linux system, and there is no package manager for it. I can't install more packages / software on it, thus it is not useful for me, so I quickly lost interest in it.

When I found it in a box after moving to another city, I thought maybe I could do something with it, so I decided to give it a try.

But sadly, the company behind the development of the dev board and instruction set has abandoned the development for the dev board and C-sky instructions, and has continued their work on RiscV.

They have a Buildroot fork on GitLab which can produce the root file system for the image, but the support for this board and C-sky instruction set was dropped some time ago. Now this repo can't produce a system image for Gx6605s.

I made a dig into the repo and found that there is a branch called master_backup, which was once their development branch capable of building C-sky CPU based system images. The build processes were run on GitLab Pipeline. So, you can fork this repo, and then run the GitLab Pipeline on the web page to get the generated system image.

But unfortunately, there is a file that Gx6605s Buildroot depended on, hosted at https://github.com/c-sky/tools, which has been deleted and changed to a new unrelated repo. Luckily, I found a mirror site that has this repo, so you can just apply this patch to get the file:

diff --git a/package/csky-debug/csky-debug.mk b/package/csky-debug/csky-debug.mk
index 241755019e..a318247ebf 100644
--- a/package/csky-debug/csky-debug.mk
+++ b/package/csky-debug/csky-debug.mk
@@ -6,7 +6,7 @@

 CSKY_DEBUG_VERSION = V4.2.0-tmp-20170411
 CSKY_DEBUG_SOURCE = DebugServerConsole-linux-x86_64-$(CSKY_DEBUG_VERSION).tar.gz
-CSKY_DEBUG_SITE = https://github.com/c-sky/tools/raw/master
+CSKY_DEBUG_SITE = https://isrc.iscas.ac.cn/gitlab/mirrors/github.com/c-sky_tools/-/raw/master

 define HOST_CSKY_DEBUG_INSTALL_CMDS
        mkdir -p $(HOST_DIR)/csky-debug

With this, you can build a system image for the Gx6605s board, and it's a little newer than the one provided on the C-sky official site. However, I want to modify the system image by adding more packages, such as MicroPython and even a GCC compiler. Therefore, I need to build it locally.

Take a look at the .gitlab-ci.yml. I believe it's using a Docker image called maohan001/ubuntu-buildroot as the building environment. Please note that since they dropped support for the C-sky instruction set, if you want to build the image in the future, please pull and backup this image. It's not Dockerfile-based, so we don't know how to reproduce it.

I've never used Buildroot before, but from the GitLab Pipeline's log and the .gitlab-ci.yml, I assume one should run make {config-name} inside the Docker image with the buildroot root path to create a configuration for the specified development board. Then, run make to download all necessary files and build the compiler, kernel, libc, and userland.

So, for the Gx6605s, we should use $ make csky_610_gx6605s_4.9_uclibc_br_defconfig, and then $ make. You will get a usb.img.xz in the output/images folder. This should be exactly what you got in the GitLab Pipeline.

And as the Buildroot's official website says, now we can run $ make menuconfig to customize the build process, such as adding MicroPython to the system.