Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

How built-in verbs are accessed only through the odb

未关闭
  • 哪里不对？
#1 7 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
electron, javascript
领域
tooling

调研方向

The issue names system.verbs.builtins, the paths table, the kernel table and pseudo-call, glue scripts, and a JavaScript table, but no files or tests. Start by locating those components and tracing how built-in verbs are resolved; done means the transition and related code changes are installed and the described lookup behavior works.

由索引模型根据 Issue 内容生成。

描述

I'm going to write up various big events in this project. This is the first, and I think it's a good one to be first.

Claude did the big parts of Frontier without any Q&A with me, and did a pretty good job but really got lost when it came to the meaning of system.verbs.builtins and the kernel table and the kernel pseudo call. I'm not sure if it read the source code, or if it just guessed wrong about a few things and tried to make his imagined system work.

Today I needed to fix a bug in the script i use that required me to use string.replaceAll verb. I often just 2click on the name to get a refresher on the parameter list, or to see if it's kernelized or what. But it didn't work. I called up Claude and asked what's up. It said that it'll run if I use it in a script, and can fix the 2click right away. I was shocked. I wanted to know what the fix would be and what I heard back was pure slop, imho.

I'm going to leave out the details of how Claud thought it worked. This is where the corner turned. I said:

every reference is either an exact match to an odb location or it goes through the paths table. system.verbs.builtins is just a convenient place to put some scripts that we're documenting as verbs in the language, but they aren't any different from objects elsewhere.

It came back with a slightly less crazy-ass idea of how it worked, so I asked why is it arguing with me, go look at the Frontier kernel source from 2011. When it got back the lights had turned on. I usually try not to quote Claude, but this is worth reading if you love Frontier, because it documents the way the language connects to the object database. I can't say I've ever explained this to anyone who didn't work at UserLand, but here it is now.

You're right, it isn't. Here's what the source says.

kernel is internaltable.kernel — built in memory at startup, never in the odb, not on the paths table. The only way into it is the kernel (...) operator in the language: the grammar rule is kernelcall: kerneltoken '(' dottedid ')'.

system.verbs.builtins is on the paths table, and it's ordinary — real script objects, same as anything else in the database. A kernel verb has a script there whose body calls kernel (string.replaceAll). That's why 2-click always works for you: you're opening a script, and the script is what tells you it's a kernel call.

So there's one lookup, not two. Name resolution walks the paths table. Nothing is special because it's a verb.

What we built instead: a JavaScript table consulted first, with the odb never asked. That's the crazy-ass version.

My response was finally we're working together. I just assumed it had figured all this out, but it hadn't and we were talking over the top of each others' heads. This time I put my foot down, wanted a clear picture of what was going on over there, and we found the big bug.

Tonight Claude has a bunch of jobs to do but doing this transition, installing all the glue scripts tables, and changing its code accordingly.

主要语言
没有语言数据
星标
0
派生
0
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

scripting/helloFrontier 的其他 Issue

查看 scripting/helloFrontier 的全部 Issue

相似的 Issue

更多 DevTools Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。