GitHub Lua Weekly Trending Repositories

koreader/koreader

An ebook reader application supporting PDF, DjVu, EPUB, FB2 and many more formats, running on Cervantes, Kindle, Kobo, PocketBook and Android devices

KOReader is a document viewer primarily aimed at e-ink readers.

Download • User guide • Wiki • Developer docs

Main features

portable: runs on embedded devices (Cervantes, Kindle, Kobo, PocketBook, reMarkable), Android and Linux computers. Developers can run a KOReader emulator in Linux and MacOS.
multi-format documents: supports fixed page formats (PDF, DjVu, CBT, CBZ) and reflowable e-book formats (EPUB, FB2, Mobi, DOC, RTF, HTML, CHM, TXT). Scanned PDF/DjVu documents can also be reflowed with the built-in K2pdfopt library. ZIP files are also supported for some formats.
full-featured reading: multi-lingual user interface with a highly customizable reader view and many typesetting options. You can set arbitrary page margins, override line spacing and choose external fonts and styles. It has multi-lingual hyphenation dictionaries bundled into the application.
integrated with calibre (search metadata, receive ebooks wirelessly, browse library via OPDS), Wallabag, Wikipedia, Google Translate and other content providers.
optimized for e-ink devices: custom UI without animation, with paginated menus, adjustable text contrast, and easy zoom to fit content or page in paged media.
extensible: via plugins
fast: on some older devices, it has been measured to have less than half the page-turn delay as the built in reading software.
and much more: look up words with StarDict dictionaries / Wikipedia, add your own online OPDS catalogs and RSS feeds, over-the-air software updates, an FTP client, an SSH server, …

Please check the user guide and the wiki to discover more features and to help us document them.

Screenshots

Installation

Please follow the model specific steps for your device:

Android • Cervantes • Kindle • Kobo • Linux • Pocketbook • reMarkable

Development

Setting up a build environment • Collaborating with Git • Building targets • Porting • Developer docs

Support

KOReader is developed and supported by volunteers all around the world. There are many ways you can help:

fix bugs and implement new features
translate the program into your language or improve an existing translation
document lesser-known features on the wiki
help others with your knowledge on the forum

Right now we only support liberapay donations.

Contributors

amzxyz/rime-wanxiang

「万象拼音」：把算法留在幕后，把纯粹还给指尖，用更优质的数据，接管你的候选。Q群：11033572 / 11631066

🌳 万象拼音

重塑 Rime 生态，带来极致的输入体验。

🌌 万象拼音——基于深度优化的词库和语法模型

💎 核心基石： 万象词库经 AI 与海量语料深度优化(目前已进入手动维护期)，是一款专为“语句流”“类大厂”打造的全方案立体词库。它将带调拼音标注、词组构成与精准词频作为体验基石，以日常与专业词汇为主体，结合语法模型，为您带来精准、流畅的输入体验。

开放生态：支持高度自定义，鼓励通过“词库 + 转写”打造您的专属输入方案。
持续打磨：我们极度重视数据准确与时效，欢迎随时反馈。
📝 万象词库问题收集反馈表

✨ 效果预览

🧭 探索万象

🚀 快速上手从零开始，为您在 Windows、macOS 以及 iOS/Android 移动端部署万象。 ➡️ 立即安装	⌨️ 核心输入体系深入解析万象独特的“带调拼音标注”、强大的辅码系统（小鹤、自然码等）以及中英混输机制。 ➡️ 了解核心
🪄 Lua 魔法扩展计算器、超级注释、符号包裹、动态时间戳、超级符号库（按名输入数千 Unicode 符号）... 探索让 Rime 拥有“超能力”的数十种微创新脚本。 ➡️ 探索魔法	⚙️ 词库与模型深度解析万象的现代数据工程。算一笔隐形的“时间账”，彻底告别低效的候选翻页，让输入如呼吸般自然。 ➡️ 揭秘底层逻辑

💎 标准版 vs 增强版

万象提供两个主要版本，请根据您的输入习惯选择。为了获得最佳体验，请务必了解您所选版本的特性：

特性对比	🟢 标准版 (Base)	🔵 增强版 (Pro)
适用人群	新手、全拼用户、追求省心的双拼用户	硬核双拼用户、重度辅码与造词需求者
方案文件	`wanxiang.schema.yaml`	`wanxiang_pro.schema.yaml`
支持类型	全拼、任意双拼	仅支持双拼
自动调频	默认开启	默认关闭 (精准控制)
用户词记录	自动记录，无差别积累	手动/无感造词，词库绝对可控
辅助码支持	仅基于声调的辅助	8 种辅助码可选 + 声调辅助
全场景辅筛	支持两分、多分、笔画、声调	全面支持 + 专属辅助码筛选

生态：

薄荷拼音 :使用万象词库的综合性方案，特别是其修改的地球拼音能够继承万象的词库声调编码。

鸢鸣万象 :一个基于万象拼音生态融合李氏三拼与辅助码能力的手机用方案。

万象虎 : 一个基于万象生态的虎码整句方案。

如果觉得项目好用，欢迎在 GitHub 为我们点亮 Star！

用更优质的数据，接管你的候选词。

miscusi-peek/cheatengine-mcp-bridge

Connect Cursor, Copilot & Claude AI directly to Cheat Engine via MCP. Automate reverse engineering, pointer scanning, and memory analysis using natural language.

Demo

Cheat Engine MCP Bridge

Let multibillion $ AI datacenters analyze the program memory for you.

Create mods, trainers, security audits, game bots, accelerate RE, or do anything else with any program and game in a fraction of a time.

Note

Thanks everyone for the stars, much appreciated! ❤️

Specially a big thank you to all the contributors!!

@libangli218, @lauralex, @iamtyroon, @HachiroSan, @Attacktive

The Problem

You're staring at gigabytes of memory. Millions of addresses. Thousands of functions. Finding that one pointer, that one structure takes days or weeks of manual work.

What if you could just ask?

"Find the packet decryptor hook."
"Find the OPcode of character coordinates."
"Find the OPcode of health values."
"Find the unique AOB pattern to make my trainer reliable after game updates."

That's exactly what this does.

- Stop clicking through hex dumps and start having conversations with the memory.

What You Get:

Before (Manual)	After (AI Agent + MCP)
Day 1: Find packet address	Minute 1: "Find RX packet decryption hook"
Day 2: Trace what writes to it	Minute 3: "Generate unique AOB signature to make it update persistent"
Day 3: Find RX hook	Minute 6: "Find movement OPcodes"
Day 4: Document structure	Minute 10: "Create python interpreter of hex to plain text"
Day 5: Game updates, start over	Done.

Your AI can now:

Read any memory instantly (integers, floats, strings, pointers)
Follow pointer chains: [[base+0x10]+0x20]+0x8 → resolved in ms
Auto-analyze structures with field types and values
Identify C++ objects via RTTI: "This is a CPlayer object"
Disassemble and analyze functions
Debug invisibly with hardware breakpoints + Ring -1 hypervisor
And much more!

How It Works

flowchart TD
    AI[AI Agent: Claude/Cursor/Copilot]
    
    AI -->|MCP Protocol - JSON-RPC over stdio| MCP
    
    MCP[mcp_cheatengine.py - Python MCP Server]
    
    MCP <-->|Named Pipe - Async| PIPE
    
    PIPE["\\.\\pipe\\CE_MCP_Bridge_v99"]
    
    PIPE <--> CE
    
    subgraph CE[Cheat Engine - DBVM Mode]
        subgraph LUA[ce_mcp_bridge.lua]
            WORKER[Worker Thread - Blocking I/O]
            MAIN[Main Thread - GUI + CE API]
            WORKER <-->|Sync| MAIN
        end
    end
    
    MAIN -->|Memory Access| TARGET[Target .exe]

Installation

pip install -r MCP_Server/requirements.txt

Or manually:

pip install mcp pywin32

Note

Native pipe mode is Windows only because it uses Named Pipes (pywin32). Use TCP relay transport when the MCP server runs outside the Windows environment that hosts Cheat Engine and cannot open the named pipe directly.

Quick Start

1. Load Bridge in Cheat Engine

Enable DBVM in Cheat Engine if you plan to use DBVM tools.
Open Cheat Engine's Lua Engine or script executor.
- Preferred: File -> Execute Script -> open MCP_Server/ce_mcp_bridge.lua -> Execute.
- If your Cheat Engine build does not show File -> Execute Script, use Table -> Show Cheat Table Lua Script, paste the dofile(...) line below, and execute it:

dofile([[C:\path\to\cheatengine-mcp-bridge\MCP_Server\ce_mcp_bridge.lua]])

Look for: [MCP v12.0.0] MCP Server Listening on: CE_MCP_Bridge_v99

2. Configure MCP Client

Add to your MCP configuration (e.g., mcp_config.json):

{
  "servers": {
    "cheatengine": {
      "command": "python",
      "args": ["C:/path/to/MCP_Server/mcp_cheatengine.py"]
    }
  }
}

Restart the IDE to load the MCP server config.

For Codex, add a TOML server block to ~/.codex/config.toml:

[mcp_servers.cheatengine]
command = "python"
args = ['C:\path\to\cheatengine-mcp-bridge\MCP_Server\mcp_cheatengine.py']

Use single quotes for the Windows path so TOML treats backslashes literally.

TCP relay transport

The TCP relay lets mcp_cheatengine.py talk to Cheat Engine through a TCP socket instead of opening the Windows named pipe itself. Cheat Engine and the Lua bridge still run on Windows, while the MCP server can run anywhere that can reach the relay: another Windows process, a VM, a container, a Linux host, or a remote machine. This can also be used with WSL without changing the Lua bridge.

On Windows, load MCP_Server/ce_mcp_bridge.lua in Cheat Engine as usual.
On Windows, start the relay:

python C:\path\to\cheatengine-mcp-bridge\MCP_Server\ce_tcp_relay.py --host 127.0.0.1 --port 9876

In the environment where the MCP server will run, install the MCP dependency without pywin32, then run/configure the MCP server with TCP transport:

python3 -m pip install -r MCP_Server/requirements-tcp.txt

CE_MCP_TRANSPORT=tcp \
CE_MCP_HOST=127.0.0.1 \
CE_MCP_PORT=9876 \
python3 /path/to/cheatengine-mcp-bridge/MCP_Server/mcp_cheatengine.py

For MCP client configs that support environment variables:

{
  "servers": {
    "cheatengine": {
      "command": "python3",
      "args": ["/path/to/cheatengine-mcp-bridge/MCP_Server/mcp_cheatengine.py"],
      "env": {
        "CE_MCP_TRANSPORT": "tcp",
        "CE_MCP_HOST": "127.0.0.1",
        "CE_MCP_PORT": "9876"
      }
    }
  }
}

Set --host on the relay and CE_MCP_HOST on the MCP server to addresses that match your network setup. Keep the relay bound to trusted interfaces only, because anyone who can reach it can control the Cheat Engine bridge.

3. Verify Connection

Use the ping tool to verify connectivity:

{"success": true, "version": "12.0.0", "message": "CE MCP Bridge Active"}

4. Start Asking Questions

"What process is attached?"
"Read 16 bytes at the base address"
"Disassemble the entry point"

~180 MCP Tools Available

Memory

Tool	Description
`read_memory`, `read_integer`, `read_string`	Read any data type
`read_pointer_chain`	Follow `[[base+0x10]+0x20]` paths
`scan_all`, `aob_scan`	Find values and byte patterns

Analysis

Tool	Description
`disassemble`, `analyze_function`	Code analysis
`dissect_structure`	Auto-detect fields and types
`get_rtti_classname`	Identify C++ object types
`find_references`, `find_call_references`	Cross-references

Debugging

Tool	Description
`set_breakpoint`, `set_data_breakpoint`	Hardware breakpoints
`start_dbvm_watch`	Ring -1 invisible tracing

Process Lifecycle

Tool	Description
`open_process`, `get_process_list`	Attach to or enumerate running processes
`create_process`	Launch a new process under CE's control
`pause_process`, `unpause_process`	Suspend / resume target execution

Memory Allocation

Tool	Description
`allocate_memory`, `free_memory`	Reserve and release memory in the target
`set_memory_protection`, `full_access`	Adjust page protection flags

Code Injection

Tool	Description
`inject_dll`	Load a DLL into the target process
`execute_code`, `execute_method`	Run shellcode or CE Lua methods remotely

Symbol Management

Tool	Description
`register_symbol`, `get_symbol_info`	Create and query named symbols
`enable_windows_symbols`	Enable PDB symbol resolution

Assembly / Compilation

Tool	Description
`assemble_instruction`	Assemble a single x86/x64 instruction to bytes
`compile_c_code`	Compile C source into injected shellcode
`generate_api_hook_script`	Generate a CE auto-assembler API hook template

Window / GUI Automation

Tool	Description
`find_window`	Locate a window by title or class
`send_window_message`	Post `WM_*` messages to a target window

Input Automation

Tool	Description
`get_pixel`	Sample a pixel color at screen coordinates
`is_key_pressed`, `do_key_press`	Query and simulate keyboard input

Cheat Table

Tool	Description
`load_table`, `save_table`	Load / save `.CT` cheat table files
`get_address_list`	Enumerate entries in the active cheat table

Kernel Mode (DBK / DBVM)

Tool	Description
`dbk_get_cr3`	Read the CR3 register for the target process
`read_process_memory_cr3`	Read physical memory via CR3 bypass

And many more at AI_Context/MCP_Bridge_Command_Reference.md

Critical Configuration

BSOD Prevention

Caution

You MUST disable: Cheat Engine → Settings → Extra → "Query memory region routines"

Enabled: Causes CLOCK_WATCHDOG_TIMEOUT BSODs due to conflicts with DBVM/Anti-Cheat when scanning protected pages.

Troubleshooting

Cheat Engine says "too many local variables"

Load the bridge from disk with dofile(...) instead of pasting the full script into a cheat table script. The bridge also declares command handlers as global functions intentionally; this avoids Cheat Engine's Lua chunk limit of 200 local variables when the complete bridge is compiled at once.

MCP client cannot connect

Check these in order:

Cheat Engine is open and shows MCP Server Listening on: CE_MCP_Bridge_v99.
The MCP client was restarted after adding the server config.
The configured mcp_cheatengine.py path exists.
pip install -r MCP_Server/requirements.txt has installed both mcp and pywin32.
Run the MCP ping tool. A successful connection returns success: true and the bridge version. process_id: 0 is normal until Cheat Engine is attached to a target process.

Environment Variables

Variable	Default	Purpose
`CE_MCP_TIMEOUT`	`30`	Timeout (seconds) for each MCP tool call.
`CE_MCP_ALLOW_SHELL`	unset	Set to `1` to enable `run_command` / `shell_execute` tools. Arbitrary code execution risk — leave unset by default.

Example Workflows

Finding a value:

You: "Scan for gold: 15000"  →  AI finds 47 results
You: "Gold changed to 15100"  →  AI filters to 3 addresses
You: "What writes to the first one?"  →  AI sets hardware BP
You: "Disassemble that function"  →  Full AddGold logic revealed

Understanding a structure:

You: "What's at [[game.exe+0x1234]+0x10]?"
AI: "RTTI: CPlayerInventory"
AI: "0x00=vtable, 0x08=itemCount(int), 0x10=itemArray(ptr)..."

Project Structure

CLAUDE.md                               # Claude Code agent guidance (this repo)
README.md                               # User-facing documentation

MCP_Server/
├── mcp_cheatengine.py                  # Python MCP Server (FastMCP)
├── ce_mcp_bridge.lua                   # Cheat Engine Lua Bridge
└── test_mcp.py                         # Test Suite

AI_Context/
├── BATCH_WORKER_BRIEFING.md            # Parallel-worker task specifications (v12 overhaul)
├── MCP_Bridge_Command_Reference.md     # MCP Commands reference
├── CE_LUA_Documentation.md             # Full CheatEngine 7.6 official documentation
└── AI_Guide_MCP_Server_Implementation.md  # Full technical documentation for AI agent

Testing

Running the test:

python MCP_Server/test_mcp.py

Expected output:

✅ Memory Reading: 6/6 tests passed
✅ Process Info: 4/4 tests passed  
✅ Code Analysis: 8/8 tests passed
✅ Breakpoints: 4/4 tests passed
✅ DBVM Functions: 3/3 tests passed
✅ Utility Commands: 11/11 tests passed
⏭️ Skipped: 1 test (generate_signature)
────────────────────────────────────
Total: 36/37 PASSED (100% success)

The Bottom Line

You no longer need to be an expert. Just ask the right questions.

⚠️ EDUCATIONAL DISCLAIMER

This code is for educational and research purposes only. It's created to show the capabilities of the Model Context Protocol (MCP) and LLM-based debugging. I do not condone the use of these tools for malicious hacking, cheating in multiplayer games, or violating Terms of Service. This is a demonstration of software engineering automation.

neovim/nvim-lspconfig

Quickstart configs for Nvim LSP

nvim-lspconfig

nvim-lspconfig is a collection of LSP server configurations for the Nvim LSP client.

View all configs, or run :help lspconfig-all from Nvim.

Important ⚠️

require('lspconfig') (the legacy "framework" of nvim-lspconfig) is deprecated in favor of vim.lsp.config (Nvim 0.11+).
- The lspconfig.lua module will be dropped. Calls to require('lspconfig') will show a warning, which will later become an error.
nvim-lspconfig itself is NOT deprecated. It provides server-specific configs.
- The configs live in the lsp/ directory. vim.lsp.config automatically finds them and merges them with any local lsp/*.lua configs defined by you or a plugin.
- The old configs in lua/lspconfig/ are deprecated and will be removed.

Migration instructions

Upgrade to Nvim 0.11+
(Optional) Use vim.lsp.config('…') (not require'lspconfig'.….setup{}) to customize or define a config.
Use vim.lsp.enable('…') (not require'lspconfig'.….setup{}) to enable a config, so that it activates for its filetypes.

Support

These configs are best-effort and supported by the community (you). See contributions.

Ask questions on GitHub Discussions, not the issue tracker.
If you found a bug in Nvim LSP (:help lsp), report it to Neovim core.
- Do not report it here. Only configuration data lives here.

Install

Requires Nvim 0.11.3+.
- Support for Nvim 0.10 will be removed. Upgrade Nvim and nvim-lspconfig before reporting an issue.

With Nvim 0.12+, you can use the builtin vim.pack plugin manager:

vim.pack.add{
  { src = 'https://github.com/neovim/nvim-lspconfig' },
}

Or install nvim-lspconfig using Vim's "packages" feature:

git clone https://github.com/neovim/nvim-lspconfig ~/.config/nvim/pack/nvim/start/nvim-lspconfig

Or use a 3rd-party plugin manager.

Quickstart

Install a language server, e.g. pyright
```
npm i -g pyright
```
Enable its config in your init.lua (:help lsp-quickstart).
```
vim.lsp.enable('pyright')
```
Ensure your project/workspace contains a root marker as specified in :help lspconfig-all.
Open a code file in Nvim. LSP will attach and provide diagnostics.
```
nvim main.py
```
Run :checkhealth vim.lsp to see the status or to troubleshoot.

See :help lspconfig-all for the full list of server-specific details. For servers not on your $PATH (e.g., jdtls, elixirls), you must manually set the cmd parameter:

vim.lsp.config('jdtls', {
  cmd = { '/path/to/jdtls' },
})

Commands

:LspInfo (alias to :checkhealth vim.lsp) shows the status of active and configured language servers.
:lsp enable [<config_name>] (:LspStart for Nvim 0.11 or older) Start the requested server name. Will only successfully start if the command detects a root directory matching the current config.
:lsp disable [<config_name>] (:LspStop for Nvim 0.11 or older) Stops the given server. Defaults to stopping all servers active on the current buffer. To force stop use :LspStop!
:lsp restart [<client_name>] (:LspRestart for Nvim 0.11 or older) Restarts the given client, and attempts to reattach to all previously attached buffers. Defaults to restarting all active servers.

Configuration

Nvim sets default options and mappings when LSP is active in a buffer:

To customize, see:

Extra settings can be specified for each LSP server. With Nvim 0.11+ you can extend a config by calling vim.lsp.config('…', {…}).

vim.lsp.config('rust_analyzer', {
  -- Server-specific settings. See `:help lsp-quickstart`
  settings = {
    ['rust-analyzer'] = {},
  },
})

Config priority

Configs are sourced in this order:

lsp/ in 'runtimepath'
after/lsp/ in 'runtimepath'
vim.lsp.config()

If you install nvim-lspconfig or similar plugins, the order that configs are applied depends on the load order. To ensure that your own config "wins" and overrides the others, use after/lsp/ and/or vim.lsp.config() to override/extend the defaults.

Creating a config

As code

Run :lua vim.lsp.config('foo', {cmd={'true'}})
Run :lua vim.lsp.enable('foo')
Run :checkhealth vim.lsp, the new config is listed under "Enabled Configurations". 😎

As a file

Create a file after/lsp/foo.lua somewhere on your 'runtimepath'.
```
:exe 'edit' stdpath('config') .. '/after/lsp/foo.lua'
```
Add this code to the file (or copy any of the examples from the lsp/ directory in this repo):
```
return {
  cmd = { 'true' },
}
```
Save the file (with ++p to ensure its parent directory is created).
```
:write ++p
```
Enable the config.
```
:lua vim.lsp.enable('foo')
```
Run :checkhealth vim.lsp, the new config is listed under "Enabled Configurations". 🌈

LSP Settings Type Annotations

nvim-lspconfig generates Lua type definitions for each supported LSP server. By manually adding annotations (e.g., ---@type lspconfig.settings.server_name), you enable auto-completion and diagnostics for your server settings.

Example:

---@type vim.lsp.Config
local config = {
  ---@type lspconfig.settings.lua_ls
  settings = {
    Lua = {
      runtime = {
        version = 'LuaJIT',
      },
      workspace = {
        preloadFileSize = 10000,
        library = {
          vim.env.VIMRUNTIME,
        }
      },
    },
  },
}

vim.lsp.config('lua_ls', config)

Troubleshooting

Start with :checkhealth vim.lsp to troubleshoot. The most common reasons a language server does not start or attach are:

Language server is not installed. nvim-lspconfig does not install language servers for you. You should be able to run the cmd defined in the config from the command line and see that the language server starts. If the cmd is a name instead of an absolute path, ensure it is on your $PATH.
Missing filetype plugins. Some languages are not detected by Nvim because they have not yet been added to the filetype detection system. Ensure :set filetype? shows the filetype and not an empty value.
Not triggering root detection. Some language servers require a "workspace", which is found by looking for an ancestor directory that contains a "root marker". The most common root marker is .git/, but each config defines other "root marker" names. Root markers/directories are listed in :help lspconfig-all.

You can also explicitly set a root instead of relying on automatic detection by enabling 'exrc' and adding an .nvim.lua at the desired root dir with the following code:
```
vim.lsp.config('<client name>', {
  root_dir = vim.fn.fnamemodify(debug.getinfo(1, 'S').source:sub(2), ':p:h'),
})
```
Note that prior to nvim 0.12 exrc file is executed only if it's inside of a cwd where you start nvim.

Bug reports

If you found a bug with LSP functionality, report it to Neovim core.

Before reporting a bug, check your logs and the output of :checkhealth vim.lsp. Add this to your init.lua to enable verbose logging:

vim.lsp.log.set_level('debug')

Attempt to run the language server, then run :LspLog to open the log. Most of the time, the reason for failure is present in the logs.

Contributions

If a language server is missing from configs.md, contributing a new configuration for it helps others, especially if the server requires special setup. Follow these steps:

Read CONTRIBUTING.md.
Create a new file at lsp/<server_name>.lua.
- Copy an existing config to get started. Most configs are simple. For an extensive example see texlab.lua.
Ask questions on GitHub Discussions or in the Neovim Matrix room.

Release process

To publish a release:

Create and push a new tag.
After pushing the tag, a GitHub action will automatically package the plugin and publish the release to LuaRocks.

License

nvim-lspconfig is licensed under the terms of the Apache 2.0 license.

See LICENSE.md

Kong/kong

🦍 The API and AI Gateway

Kong or Kong Gateway is a cloud-native, platform-agnostic, scalable API 𖧹 LLM 𖧹 MCP Gateway distinguished for its high performance and extensibility via plugins. It also provides advanced AI traffic capabilities with multi-LLM support, semantic security, MCP traffic security and analytics, and more.

By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central layer for orchestrating microservices or conventional API traffic - and agentic LLM and MCP as well - with ease.

Kong runs natively on Kubernetes thanks to its official Kubernetes Ingress Controller.

Getting Started

If you prefer to use a cloud-hosted Kong, you can sign up for a free trial of Kong Konnect and get started in minutes. If not, you can follow the instructions below to get started with Kong on your own infrastructure.

Let’s test drive Kong by adding authentication to an API in under 5 minutes.

We suggest using the docker-compose distribution via the instructions below, but there is also a docker installation procedure if you’d prefer to run the Kong Gateway in DB-less mode.

Whether you’re running in the cloud, on bare metal, or using containers, you can find every supported distribution on our official installation page.

To start, clone the Docker repository and navigate to the compose folder.

  $ git clone https://github.com/Kong/docker-kong
  $ cd docker-kong/compose/

Start the Gateway stack using:

  $ KONG_DATABASE=postgres docker-compose --profile database up

The Gateway is now available on the following ports on localhost:

:8000 - send traffic to your service via Kong
:8001 - configure Kong using Admin API or via decK
:8002 - access Kong's management Web UI (Kong Manager) on localhost:8002

Next, follow the quick start guide to tour the Gateway features.

Getting started with AI Gateway for LLM and MCP

If you would like to get started with Kong AI Gateway capabilities including LLM and MCP features, please refer to the official AI documentation.

Features

By centralizing common API, AI and MCP functionality across all your organization's services, Kong Gateway creates more freedom for engineering teams to focus on the challenges that matter most.

The top Kong features include:

Advanced routing, load balancing, health checking - all configurable via a RESTful admin API or declarative configuration.
Authentication and authorization for APIs using methods like JWT, basic auth, OAuth, ACLs and more.
Universal LLM API to route across multiple providers like OpenAI, Anthropic, GCP Gemini, AWS Bedrock, Azure AI, Databricks, Mistral, Huggingface and more.
MCP traffic governance, MCP security and MCP observability in addition to MCP autogeneration from any RESTful API.
60+ AI features like AI observability, semantic security and caching, semantic routing and more.
Proxy, SSL/TLS termination, and connectivity support for L4 or L7 traffic.
Plugins for enforcing traffic controls, rate limiting, req/res transformations, logging, monitoring and including a plugin developer hub.
Sophisticated deployment models like Declarative Databaseless Deployment and Hybrid Deployment (control plane/data plane separation) without any vendor lock-in.
Native ingress controller support for serving Kubernetes.

Plugin Hub

Plugins provide advanced functionality that extends the use of the Gateway. Many of the Kong Inc. and community-developed plugins like AWS Lambda, Correlation ID, and Response Transformer are showcased at the Plugin Hub.

Contribute to the Plugin Hub and ensure your next innovative idea is published and available to the broader community!

Contributing

We ❤️ pull requests, and we’re continually working hard to make it as easy as possible for developers to contribute. Before beginning development with the Kong Gateway, please familiarize yourself with the following developer resources:

Community Pledge (COMMUNITY_PLEDGE.md) for our pledge to interact with you, the open source community.
Contributor Guide (CONTRIBUTING.md) to learn about how to contribute to Kong.
Development Guide (DEVELOPER.md): Setting up your development environment.
CODE_OF_CONDUCT and COPYRIGHT

Use the Plugin Development Guide for building new and creative plugins, or browse the online version of Kong's source code documentation in the Plugin Development Kit (PDK) Reference. Developers can build plugins in Lua, Go or JavaScript.

Releases

Please see the Changelog for more details about a given release. The SemVer Specification is followed when versioning Gateway releases.

Join the Community

Check out the docs
Join the Kong discussions forum
Join the Kong discussions at the Kong Nation forum: https://discuss.konghq.com/
Join our Community Slack
Read up on the latest happenings at our blog
Follow us on X
Subscribe to our YouTube channel
Visit our homepage to learn more

Konnect Cloud

Kong Inc. offers commercial subscriptions that enhance the Kong Gateway in a variety of ways. Customers of Kong's Konnect Cloud subscription take advantage of additional gateway functionality, commercial support, and access to Kong's managed (SaaS) control plane platform. The Konnect Cloud platform features include real-time analytics, a service catalog, developer portals, and so much more! Get started with Konnect Cloud.

License

Copyright 2016-2026 Kong Inc.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

PathOfBuildingCommunity/PathOfBuilding

Offline build planner for Path of Exile.

Path of Building Community

Welcome to Path of Building, an offline build planner for Path of Exile!

Features

Comprehensive offence + defence calculations:
- Calculate your skill DPS, damage over time, life/mana/ES totals and much more!
- Can factor in auras, buffs, charges, curses, monster resistances and more, to estimate your effective DPS
- Also calculates life/mana reservations
- Shows a summary of character stats in the side bar, as well as a detailed calculations breakdown tab which can show you how the stats were derived
- Supports all skills and support gems, and most passives and item modifiers
  - Throughout the program, supported modifiers will show in blue and unsupported ones in red
- Full support for minions
- Support for party play and support builds
Passive skill tree planner:
- Support for jewels including most radius/conversion and timeless jewels
- Features alternate path tracing (mouse over a sequence of nodes while holding shift, then click to allocate them all)
- Fully integrated with the offence/defence calculations; see exactly how each node will affect your character!
- Can import PathOfExile.com and PoEPlanner.com passive tree links; links shortened with PoEURL.com also work
Skill planner:
- Add any number of main or supporting skills to your build
- Supporting skills (auras, curses, buffs) can be toggled on and off
- Automatically applies Socketed Gem modifiers from the item a skill is socketed into
- Automatically applies support gems granted by items
Item planner:
- Add items from in game by copying and pasting them straight into the program!
- Automatically adds quality to non-corrupted items
- Search the trade site for the most impactful items
- Fully integrated with the offence/defence calculations; see exactly how much of an upgrade a given item is!
- Contains a searchable database of all uniques that are currently in game (and some that aren't yet!)
  - You can choose the modifier rolls when you add a unique to your build
  - Includes all league-specific items and legacy variants
- Features an item crafting system:
  - You can select from any of the game's base item types
  - You can select prefix/suffix modifiers from lists
  - Custom modifiers can be added, with Master and Essence modifiers available
- Also contains a database of rare item templates:
  - Allows you to create rare items for your build to approximate the gear you will be using
  - Choose which modifiers appear on each item, and the rolls for each modifier, to suit your needs
  - Has templates that should cover the majority of builds
Other features:
- You can import passive tree, items, and skills from existing characters
- Share builds with other users by generating a share code
- Automatic updating; most updates will only take a couple of seconds to apply

Download

Head over to the Releases page to download the install wizard or portable zip.

Changelog

You can find the full version history here.

Contribute

You can find instructions on how to contribute code and bug reports here.

Licence

MIT

For 3rd-party licences, see LICENSE. The licencing information is considered to be part of the documentation.

jitsi/docker-jitsi-meet

Jitsi Meet on Docker

Jitsi is a set of Open Source projects that allows you to easily build and deploy secure videoconferencing solutions.

Jitsi Meet is a fully encrypted, 100% Open Source video conferencing solution that you can use all day, every day, for free — with no account needed.

This repository contains the necessary tools to run a Jitsi Meet stack on Docker using Docker Compose.

All our images are published on the GitHub Container Registry (GHCR).

Tag	Description
`stable`	Points to the latest stable release
`stable-NNNN-X`	A stable release
`unstable`	Points to the latest unstable release
`unstable-YYYY-MM-DD`	Daily unstable release

Installation

The installation manual is available here.

Kubernetes

If you plan to install the jitsi-meet stack on a Kubernetes cluster you can find tools and tutorials in the project Jitsi on Kubernetes.

finlater/weread.koplugin

微信读书 koreader 插件，在 koreader 里阅读微信读书里的书籍、公众号文章，支持阅读进度同步，阅读时长上报和统计，本地书籍支持获取微信读书划线和想法内容，支持Kindle、Kobo等设备。

WeRead KOReader Plugin

免责声明：本项目仅供个人学习和技术研究使用，不得用于商业用途。使用本项目所产生的一切后果（包括但不限于账号封禁、数据丢失等）由使用者自行承担，项目作者概不负责。请遵守微信读书的用户协议和相关法律法规。

在 KOReader 上阅读微信读书中的书籍、公众号文章的插件。支持同步进度同步，阅读时长同步和统计，查看书评、划线和想法。让Kindle、Kobo等封闭系统设备也能体验微信读书！

其它项目推荐

插件	简介
kindlebtcontroller.koplugin	蓝牙手柄/遥控器控制 Kindle —— 翻页、调节亮度、章节跳转等 20+ 操作，按键完全可自定义。
one.koplugin	在 KOReader 上离线阅读「ONE · 一个」每日更新：一图、一文、一问答。

功能

主菜单	书架	公众号

阅读时间上报	阅读统计	阅读进度同步

多选章节下载	章节预下载	下载全书

书籍详情	书评	划线和想法

搜索书籍	快捷菜单	设置

安装

⚠️ 建议使用 KOReader 2026.03 或更高版本。旧版本可能无法正常加载或使用插件，例如「工具」菜单中找不到「微信读书」。详见 #14。

前往 GitHub Releases 下载最新的 weread.koplugin-vX.Y.Z.zip 安装包。
解压安装包，得到 weread.koplugin 文件夹。
将该文件夹复制到 KOReader 的 plugins 目录：

koreader/plugins/weread.koplugin/

重启 KOReader，在菜单中找到：

工具 → 微信读书

后续更新插件可在 微信读书 → 设置 → 更新管理 菜单中在线更新。

登录与认证

插件只支持微信扫码登录，扫码前需要先为账号开通微信读书 Skill：

手机打开微信读书 App。
进入 我 → 设置 → 微信读书 Skill。
点击 获取 API Key，确认已经生成个人官方 API Key。
在 KOReader 打开 工具 → 微信读书 → 微信扫码登录。
使用微信扫码并在手机端确认；若手机显示四位验证码，请在 KOReader 中输入。

SimpleUI / Zen_UI 集成

插件提供统一的“微信读书书架”入口并支持集成到 SimpleUI和 ZenUI的快捷按钮中。(需要安装最新版 SimpleUI 和 ZenUI插件)。

SimpleUI：进入 快捷操作 新建操作，类型选择 插件 → 微信读书，再把该操作加入底部栏即可。如需使用本项目图标，将 icons/weread-w-book.svg 或 icons/weread-ink.png 复制到 SimpleUI 的自定义图标目录koreader/setting/simpleui/sui_icons后，在快捷操作中选中它。
Zen_UI 底栏：进入 控件 → 按钮 → ➕ → 插件 → 微信读书，点击后直接打开微信读书书架。注册时会把 weread-w-book.svg 同步到 KOReader 用户图标目录，供 ZenUI 自动匹配或手动选择；不会自动修改、添加或启用 Tab。
Zen_UI 首页：进入 主页 → 小组件，启用“微信读书”组件。组件默认关闭，可由用户自行排序。

原生 KOReader 的 “工具 → 微信读书” 菜单保持不变。

SimpleUI	Zen_UI

菜单结构

微信读书
├── 微信扫码登录 / 已经登录 · 账号名
├── 立即同步进度       （阅读微信读书缓存书籍时显示）
├── 书籍详情           （阅读微信读书缓存书籍时显示）
├── 显示划线和想法     （阅读书籍时显示，开关）
├── 书架               书籍 / 公众号 Tab；书架内搜索、离线缓存、手动更新
├── 本地书架            已下载书籍（不包含单章）的本地入口
├── 搜索               搜索微信读书
├── 阅读时间上报        后台上报阅读时长
│   ├── 启用阅读时间上报
│   ├── 仅在阅读时上报
│   ├── 选择目标书籍
│   │   ├── 自动关联微信读书书籍
│   │   └── 手动设置上报书籍
│   └── 上报状态
├── 阅读统计            阅读时长/天数/排行/偏好可视化（页内 周/月/年/总 tab 切换，可翻阅历史周期）
├── 设置
│   ├── 缓存管理
│   │   ├── 扫描并关联本地书籍
│   │   ├── 缓存清理
│   │   └── 缓存目录
│   ├── 进度管理
│   │   ├── 打开时拉取进度（默认关闭）
│   │   └── 关闭时上传进度（默认关闭）
│   ├── 下载设置
│   │   ├── 书籍图片（默认开启）
│   │   ├── 公众号文章图片（默认关闭）
│   │   └── 章节预下载
│   │       ├── 自动预下载下一章（默认关闭，开启时会确认网络卡顿风险）
│   │       ├── 预下载划线和想法（默认关闭，总开关关闭时不可操作）
│   │       └── 显示预下载提示（默认开启，总开关关闭时不可操作）
│   ├── 划线设置
│   │   ├── 划线边缘防误触（默认开启）
│   │   └── 边缘区域：20%（可调 10%–40%）
│   ├── 账号管理
│   │   ├── 账号状态
│   │   ├── 立即续期 Cookie
│   │   └── 清除账号数据
│   └── 关于
│       ├── 版本 x.y.z
│       ├── 作者：finlater
│       ├── 检查更新
│       ├── 每天自动检查一次（默认关闭）
│       └── 更新时优先使用代理（默认开启；代理失败会自动回退 GitHub）

贡献

欢迎提交 issue 和 PR。提交前请阅读 CONTRIBUTING.md。

许可证

本项目代码采用 GNU Affero General Public License v3.0，SPDX 标识为 AGPL-3.0-only，与 KOReader 使用的许可证保持一致。

修改、整合或再分发本项目时，必须遵守 AGPL-3.0，保留版权和许可证声明，并按许可证要求将本项目代码或其衍生作品开源。

fonts/NotoEmoji-Regular.ttf 是第三方字体，采用 SIL Open Font License 1.1，不适用本项目的 AGPL-3.0。

tarantool/tarantool

Get your data in RAM. Get compute close to data. Enjoy the performance.

Tarantool

Tarantool is an in-memory computing platform consisting of a database and an application server.

It is distributed under BSD 2-Clause terms.

Key features of the application server:

Heavily optimized Lua interpreter with incredibly fast tracing JIT compiler, based on LuaJIT 2.1.
Cooperative multitasking, non-blocking IO.
Persistent queues.
Sharding.
Cluster and application management framework.
Access to external databases such as MySQL and PostgreSQL.
A rich set of built-in and standalone modules.

Key features of the database:

MessagePack data format and MessagePack based client-server protocol.
Two data engines: 100% in-memory with complete WAL-based persistence and an own implementation of LSM-tree, to use with large data sets.
Multiple index types: HASH, TREE, RTREE, BITSET.
Document oriented JSON path indexes.
Asynchronous master-master replication.
Synchronous quorum-based replication.
RAFT-based automatic leader election for the single-leader configuration.
Authentication and access control.
ANSI SQL, including views, joins, referential and check constraints.
Connectors for many programming languages.
The database is a C extension of the application server and can be turned off.

Supported platforms are Linux (x86_64, aarch64), Mac OS X (x86_64, M1), FreeBSD (x86_64).

Tarantool is ideal for data-enriched components of scalable Web architecture: queue servers, caches, stateful Web applications.

To download and install Tarantool as a binary package for your OS or using Docker, please see the download instructions.

To build Tarantool from source, see detailed instructions in the Tarantool documentation.

To find modules, connectors and tools for Tarantool, check out our Awesome Tarantool list.

Please report bugs to our issue tracker. We also warmly welcome your feedback on the discussions page and questions on Stack Overflow.

We accept contributions via pull requests. Check out our contributing guide.

Thank you for your interest in Tarantool!

xmake-io/xmake

🔥 A cross-platform build utility based on Lua

xmake

A cross-platform build utility based on Lua
Modern C/C++ build tool: Simple, Fast, Powerful dependency package integration

Support this project

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. 🙏

Introduction (中文)

What is Xmake?

Xmake is a cross-platform build utility based on the Lua scripting language.
Xmake is very lightweight and has no dependencies outside of the standard library.
Uses the xmake.lua file to maintain project builds with a simple and readable syntax.

Xmake can be used to directly build source code (like with Make or Ninja), or it can generate project source files like CMake or Meson. It also has a built-in package management system to help users integrate C/C++ dependencies.

Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache

Although less precise, one can still understand Xmake in the following way:

Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache

If you want to know more, please refer to the Documentation, GitHub or Gitee. You are also welcome to join our community.

The official Xmake repository can be found at xmake-io/xmake-repo.

Installation

With cURL

curl -fsSL https://xmake.io/shget.text | bash

With Wget

wget https://xmake.io/shget.text -O - | bash

With PowerShell

irm https://xmake.io/psget.text | iex

Other installation methods

If you don't want to use the above scripts to install Xmake, visit the Installation Guide for other installation methods (building from source, package managers, etc.).

Simple Project Description

target("console")
    set_kind("binary")
    add_files("src/*.c")

Creates a new target console of kind binary, and adds all the files ending in .c in the src directory.

Package dependencies

add_requires("tbox 1.6.*", "zlib", "libpng ~1.6")

Adds a requirement of tbox v1.6, zlib (any version), and libpng v1.6.

The official xmake package repository exists at: xmake-repo

Command line interface reference

The below assumes you are currently in the project's root directory.

Build a project

$ xmake

Run target

$ xmake run console

Debug target

$ xmake run -d console

Run test

$ xmake test

Configure platform

$ xmake f -p [windows|linux|macosx|android|iphoneos ..] -a [x86|arm64 ..] -m [debug|release]
$ xmake

Menu configuration

$ xmake f --menu

Supported platforms

Windows (x86, x64, arm, arm64, arm64ec)
macOS (i386, x86_64, arm64)
Linux (i386, x86_64, arm, arm64, riscv, mips, 390x, sh4 ...)
FreeBSD (i386, x86_64)
NetBSD (i386, x86_64)
OpenBSD (i386, x86_64)
DragonflyBSD (i386, x86_64)
Solaris (i386, x86_64)
Android (x86, x86_64, armeabi, armeabi-v7a, arm64-v8a)
iOS (armv7, armv7s, arm64, i386, x86_64)
WatchOS (armv7k, i386)
AppleTVOS (armv7, arm64, i386, x86_64)
AppleXROS (arm64, x86_64)
MSYS (i386, x86_64)
MinGW (i386, x86_64, arm, arm64)
Cygwin (i386, x86_64)
Wasm (wasm32, wasm64)
Haiku (i386, x86_64)
Harmony (x86_64, armeabi-v7a, arm64-v8a)
Cross (cross-toolchains ..)

Supported toolchains

$ xmake show -l toolchains
xcode         Xcode IDE
msvc          Microsoft Visual C/C++ Compiler
clang-cl      LLVM Clang C/C++ Compiler compatible with msvc
yasm          The Yasm Modular Assembler
clang         A C language family frontend for LLVM
go            Go Programming Language Compiler
dlang         D Programming Language Compiler (Auto)
dmd           D Programming Language Compiler
ldc           The LLVM-based D Compiler
gdc           The GNU D Compiler (GDC)
gfortran      GNU Fortran Programming Language Compiler
flang         LLVM Fortran Compiler
zig           Zig Programming Language Compiler
zigcc         Use zig cc/c++ as C/C++ Compiler
sdcc          Small Device C Compiler
cuda          CUDA Toolkit (nvcc, nvc, nvc++, nvfortran)
ndk           Android NDK
rust          Rust Programming Language Compiler
swift         Swift Programming Language Compiler
llvm          A collection of modular and reusable compiler and toolchain technologies
cross         Common cross compilation toolchain
nasm          NASM Assembler
gcc           GNU Compiler Collection
mingw         Minimalist GNU for Windows
gnu-rm        GNU Arm Embedded Toolchain
envs          Environment variables toolchain
fasm          Flat Assembler
tinycc        Tiny C Compiler
emcc          A toolchain for compiling to asm.js and WebAssembly
icc           Intel C/C++ Compiler
ifort         Intel Fortran Compiler
ifx           Intel LLVM Fortran Compiler
muslcc        The musl-based cross-compilation toolchain
fpc           Free Pascal Programming Language Compiler
wasi          WASI-enabled WebAssembly C/C++ toolchain
nim           Nim Programming Language Compiler
dotnet        .NET SDK Toolchain
circle        A new C++20 compiler
armcc         ARM Compiler Version 5 of Keil MDK
armclang      ARM Compiler Version 6 of Keil MDK
c51           Keil development tools for the 8051 Microcontroller Architecture
icx           Intel LLVM C/C++ Compiler
dpcpp         Intel LLVM C++ Compiler for data parallel programming model based on Khronos SYCL
masm32        The MASM32 SDK
iverilog      Icarus Verilog
verilator     Verilator open-source SystemVerilog simulator and lint system
cosmocc       build-once run-anywhere
hdk           Harmony SDK
ti-c2000      TI-CGT C2000 compiler
ti-c6000      TI-CGT C6000 compiler
iararm        IAR ARM C/C++ Compiler
kotlin-native Kotlin Native Programming Language Compiler
filc          A memory safe implementation of the C and C++ programming languages (https://fil-c.org/)
ascendc       Huawei Ascend C (bisheng compiler driver)

Supported languages

C and C++
Objective-C and Objective-C++
Swift
Assembly
Golang
Rust
Dlang
Fortran
Cuda
Zig
Vala
Pascal
Nim
Verilog
FASM
NASM
YASM
MASM32
Cppfront
Kotlin
C#
Ascend C

Features

Xmake exhibits:

Simple yet flexible configuration grammar.
Quick, dependency-free installation.
Easy compilation for most all supported platforms.
Supports cross-compilation with intelligent analysis of cross toolchain information.
Extremely fast parallel compilation support.
Supports C++ modules (new in C++20).
Supports cross-platform C/C++ dependencies with built-in package manager.
Multi-language compilation support including mixed-language projects.
Rich plug-in support with various project generators (ex. Visual Studio/Makefiles/CMake/compile_commands.json)
REPL interactive execution support
Incremental compilation support with automatic analysis of header files
Built-in toolchain management
A large number of expansion modules
Remote compilation support
Distributed compilation support
Local and remote build cache support

Supported Project Types

Xmake supports the below types of projects:

Static libraries
Shared libraries
Console/CLI applications
CUDA programs
Qt applications
WDK drivers (umdf/kmdf/wdm)
WinSDK applications
MFC applications
Darwin applications (with metal support)
Frameworks and bundles (in Darwin)
SWIG modules (Lua, Python, ...)
LuaRocks modules
Protobuf programs
Lex/Yacc programs
Linux kernel modules

Package management

Download and build

Xmake can automatically fetch and install dependencies!

Supported package repositories

Official package repository xmake-repo (tbox >1.6.1)
Official package manager Xrepo
User-built repositories
Conan (conan::openssl/1.1.1g)
Conda (conda::libpng 1.3.67)
Vcpkg (vcpkg:ffmpeg)
Homebrew/Linuxbrew (brew::pcre2/libpcre2-8)
Pacman on archlinux/msys2 (pacman::libcurl)
Apt on ubuntu/debian (apt::zlib1g-dev)
Clib (clib::clibs/bytes@0.0.4)
Dub (dub::log 0.4.3)
Portage on Gentoo/Linux (portage::libhandy)
Nimble for nimlang (nimble::zip >1.3)
Cargo for rust (cargo::base64 0.13.0)
Zypper on openSUSE (zypper::libsfml2 2.5)
NuGet (nuget::Humanizer.Core 2.14.1)

Package management features

The official repository provides nearly 500+ packages with simple compilation on all supported platforms
Full platform package support, support for cross-compiled dependent packages
Support package virtual environment using xrepo env shell
Precompiled package acceleration for Windows (NT)
Support self-built package repositories and private repository deployment
Third-party package repository support for repositories such as: vcpkg, conan, conda, etc.
Supports automatic pulling of remote toolchains
Supports dependency version locking

Processing architecture

Below is a diagram showing roughly the architecture of Xmake, and thus how it functions.

Distributed Compilation

Cross-platform support.
Support for MSVC, Clang, GCC and other cross-compilation toolchains.
Support for building for Android, Linux, Windows NT, and Darwin hosts.
No dependencies other than the compilation toolchain.
Support for build server load balancing scheduling.
Support for real time compressed transfer of large files (lz4).
Almost zero configuration cost, no shared filesystem required, for convenience and security.

For more details see: Distributed Compilation

Remote Compilation

For more details see: Remote Compilation

Local/Remote Build Cache

For more details see: Build Cache Acceleration

Benchmark

Xmake's speed on is par with Ninja! The test project: xmake-core

Multi-task parallel compilation

buildsystem	Termux (8core/-j12)	buildsystem	MacOS (8core/-j12)
xmake	24.890s	xmake	12.264s
ninja	25.682s	ninja	11.327s
cmake(gen+make)	5.416s+28.473s	cmake(gen+make)	1.203s+14.030s
cmake(gen+ninja)	4.458s+24.842s	cmake(gen+ninja)	0.988s+11.644s

Single task compilation

buildsystem	Termux (-j1)	buildsystem	MacOS (-j1)
xmake	1m57.707s	xmake	39.937s
ninja	1m52.845s	ninja	38.995s
cmake(gen+make)	5.416s+2m10.539s	cmake(gen+make)	1.203s+41.737s
cmake(gen+ninja)	4.458s+1m54.868s	cmake(gen+ninja)	0.988s+38.022s

More Examples

Debug and release profiles

add_rules("mode.debug", "mode.release")

target("console")
    set_kind("binary")
    add_files("src/*.c")
    if is_mode("debug") then
        add_defines("DEBUG")
    end

Custom scripts

target("test")
    set_kind("binary")
    add_files("src/*.c")
    after_build(function (target)
        print("hello: %s", target:name())
        os.exec("echo %s", target:targetfile())
    end)

Automatic integration of dependent packages

Download and use packages in xmake-repo or third-party repositories:

add_requires("tbox >1.6.1", "libuv master", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8")
add_requires("conan::openssl/1.1.1g", {alias = "openssl", optional = true, debug = true})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("tbox", "libuv", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8", "openssl")

In addition, we can also use the xrepo command to quickly install dependencies.

Qt QuickApp Program

target("test")
    add_rules("qt.quickapp")
    add_files("src/*.cpp")
    add_files("src/qml.qrc")

Cuda Program

target("test")
    set_kind("binary")
    add_files("src/*.cu")
    add_cugencodes("native")
    add_cugencodes("compute_75")

WDK/UMDF Driver Program

target("echo")
    add_rules("wdk.driver", "wdk.env.umdf")
    add_files("driver/*.c")
    add_files("driver/*.inx")
    add_includedirs("exe")

target("app")
    add_rules("wdk.binary", "wdk.env.umdf")
    add_files("exe/*.cpp")

For more WDK driver examples (UMDF/KMDF/WDM), please visit WDK Program Examples

Darwin Applications

target("test")
    add_rules("xcode.application")
    add_files("src/*.m", "src/**.storyboard", "src/*.xcassets")
    add_files("src/Info.plist")

Framework and Bundle Program (Darwin)

target("test")
    add_rules("xcode.framework") -- or xcode.bundle
    add_files("src/*.m")
    add_files("src/Info.plist")

OpenMP Program

add_requires("libomp", {optional = true})
target("loop")
    set_kind("binary")
    add_files("src/*.cpp")
    add_rules("c++.openmp")
    add_packages("libomp")

Zig Program

target("test")
    set_kind("binary")
    add_files("src/main.zig")

Automatically fetch remote toolchain

fetch a special version of LLVM

Require the Clang version packaged with LLM-10 to compile a project.

add_requires("llvm 10.x", {alias = "llvm-10"})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    set_toolchains("llvm@llvm-10")

Fetch a cross-compilation toolchain

We can also pull a specified cross-compilation toolchain in to compile the project.

add_requires("muslcc")
target("test")
    set_kind("binary")
    add_files("src/*.c")
    set_toolchains("@muslcc")

Fetch toolchain and packages

We can also use the specified muslcc cross-compilation toolchain to compile and integrate all dependent packages.

add_requires("muslcc")
add_requires("zlib", "libogg", {system = false})

set_toolchains("@muslcc")

target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("zlib", "libogg")

Plugins

Generate IDE project file plugin（makefile, vs2002 - vs2026 .. ）

$ xmake project -k vsxmake -m "debug,release" # New vsproj generator (Recommended)
$ xmake project -k vs -m "debug,release"
$ xmake project -k cmake
$ xmake project -k ninja
$ xmake project -k compile_commands

Run a custom lua script plugin

$ xmake l ./test.lua
$ xmake l -c "print('hello xmake!')"
$ xmake l lib.detect.find_tool gcc
$ xmake l
> print("hello xmake!")
> {1, 2, 3}
< {
    1,
    2,
    3
  }

To see a list of builtin plugins, please visit Builtin plugins.

Please download and install other plugins from the plugins repository xmake-plugins.

IDE/Editor Integration

xmake-vscode

xmake-sublime

xmake-idea

xmake-zed (thanks @jeleferai)
xmake.vim (third-party, thanks @luzhlon)
xmake-visualstudio (third-party, thanks @HelloWorld886)
xmake-qtcreator (third-party, thanks @Arthapz)

Xmake Gradle Plugin (JNI)

We can use the xmake-gradle plugin to compile JNI libraries via gradle.

plugins {
  id 'org.tboox.gradle-xmake-plugin' version '1.1.5'
}

android {
    externalNativeBuild {
        xmake {
            path "jni/xmake.lua"
        }
    }
}

The xmakeBuild task will be injected into the assemble task automatically if the gradle-xmake-plugin has been applied.

$ ./gradlew app:assembleDebug
> Task :nativelib:xmakeConfigureForArm64
> Task :nativelib:xmakeBuildForArm64
>> xmake build
[ 50%]: cache compiling.debug nativelib.cc
[ 75%]: linking.debug libnativelib.so
[100%]: build ok!
>> install artifacts to /Users/ruki/projects/personal/xmake-gradle/nativelib/libs/arm64-v8a
> Task :nativelib:xmakeConfigureForArmv7
> Task :nativelib:xmakeBuildForArmv7
>> xmake build
[ 50%]: cache compiling.debug nativelib.cc
[ 75%]: linking.debug libnativelib.so
[100%]: build ok!
>> install artifacts to /Users/ruki/projects/personal/xmake-gradle/nativelib/libs/armeabi-v7a
> Task :nativelib:preBuild
> Task :nativelib:assemble
> Task :app:assembleDebug

CI Integration

GitHub Action

The github-action-setup-xmake plugin for GitHub Actions can allow you to use Xmake with minimal efforts if you use GitHub Actions for your CI pipeline.

uses: xmake-io/github-action-setup-xmake@v1
with:
  xmake-version: latest

Who is using Xmake?

The list of people and projects who are using Xmake is available here.

If you are using Xmake, you are welcome to submit your information to the above list through a PR, so that other users and the developers can gauge interest. This also lets users use xmake more confidently and gives us motivation to continue to maintain it.

This will help the Xmake project and it's community grow stronger and expand!

Contacts

Email：waruqi@gmail.com
Homepage：xmake.io
Community
- Chat on Reddit
- Chat on Telegram
- Chat on Discord
- Chat on QQ Group: 343118190, 662147501
Source Code：GitHub, Gitee
WeChat Public: tboox-os

Thanks

This project exists thanks to all the people who have contributed:

TitanSnow: Provide the xmake logo and install scripts
uael: Provide the semantic versioning library sv
OpportunityLiu: Improve cuda, tests and ci
xq144: Improve xrepo env shell, and contribute a lot of packages to the xmake-repo repository.
star-hengxing: Contribute a lot of packages to the xmake-repo repository.
Arthapz: Contribute new C++ Modules implementation.
SirLynix: Contributed many packages and let more people know about xmake.
enderger: Helped smooth out the edges on the English translation of the README

Powered by

beyond-all-reason/Beyond-All-Reason

Main game repository for Beyond All Reason.

Beyond-All-Reason

Open source RTS game built on top of the Recoil RTS Engine

Where to download

https://www.beyondallreason.info/download

How to play

https://www.beyondallreason.info/guides

Development Quick Start

Beyond All Reason (BAR), consists of 2 primary components, the lobby (Chobby - https://github.com/beyond-all-reason/BYAR-Chobby) and the game code itself (this repository).

The game runs on top of the Recoil engine https://github.com/beyond-all-reason/spring.

In order to develop the game (this repository) you first need a working install of the lobby/launcher. There are 2 ways to do this:

Download the full BAR application from the website and run it. This is probably what you will have done if you have previously installed and played the game.
OR if you want to develop the lobby client, follow the guide in the Chobby README. First download a release of Chobby and then launch Chobby, this will automatically download and install the engine and other dependencies.

Once you have a working install of BAR you need a local development copy of the game code to work with. This code will live in the BAR install directory.

To find the BAR install directory simply open the launcher (not full game) and click the "Open install directory" button. This is one of the 3 buttons (Toggle log and Upload log are the other 2). For Windows installs this might be your user's AppData/Local/Programs/Beyond-All-Reason/data directory, for Linux it might be your user's .local/state/Beyond All Reason/ directory.
In the BAR install directory create the empty file devmode.txt. E.g: AppData/Local/Programs/Beyond-All-Reason/data/devmode.txt or .local/state/Beyond All Reason/devmode.txt.
In the BAR install directory (inside the data folder on Windows) in the games sub-directory (create games if it doesn't exist) clone the code for this repository into a directory with a name ending in .sdd. For example:

git clone --recurse-submodules https://github.com/beyond-all-reason/Beyond-All-Reason.git BAR.sdd

Ensure that you have the correct path by looking for the file Beyond-All-Reason/data/games/BAR.sdd/modinfo.lua on Windows, or .local/state/Beyond All Reason/games/BAR.sdd/modinfo.lua on Linux.

Now you have the game code launch the full game from the launcher as normal. Then go to Settings > Developer > Singleplayer and select Beyond All Reason Dev.
Now you can launch a match normally through the game UI. This match will use the dev copy of the LUA code which is in BAR-install-directory/data/games/BAR.sdd.
If developing Chobby also clone the code into the games directory. Follow the guide in the Chobby README.
(Optional, Advanced) If you want to run automated integration tests, see the testing documentation

More on the .sdd directory to run raw LUA and the structure expected by Spring Engine is documented here.

Automated Testing

Prereqs

Lua 5.1

debian/linux

sudo apt install -y lua5.1

windows (MSYS2 UCRT64)

pacman -S --needed mingw-w64-ucrt-x86_64-lua51

macOS

brew install lua@5.1

Lux Package Manager Follow the Lux Getting Started Guide.

Or follow the Cargo instructions to manually build on the Lux Github

Install Project Packages

From the repo root (where lux.toml lives):

lux --max-jobs=2 update

Note: in my testing --max-jobs was super specific to my machine and anything above that number would sometimes cause deadlocks.

Running Tests

Run the full suite (via Busted):

# preferred for predictable CLI behavior
busted

Filter by tag:

busted -t focus

Optionally, run through Lux’s wrapper:

lx test
# run the emmylua type check
lx check
# or to drop into a shell so you can run `busted` manually
lx shell --test
busted
8 successes / 0 failures / 0 errors / 0 pending : 0.246881 seconds

See Lux Guides for more information.

Inspect objects inline while debugging:

print(VFS.Include("inspect.lua")(someObject))

VS Code Test Switcher (optional)

This handy plugin lets you switch between the test and the code-being-tested just by tapping Cmd+Shift+Y.

VSCode Plugin: https://marketplace.visualstudio.com/items?itemName=bmalehorn.test-switcher

Then open User Settings (JSON) and add:

"test-switcher.rules": [
    {
        "pattern": "spec/(.*)_spec\\.lua",
        "replacement": "$1.lua"
    },
    {
        "pattern": "spec/builder_specs/(.*)_spec\\.lua",
        "replacement": "spec/builders/$1.lua"
    },
    {
        "pattern": "spec/builders/(.*)\\.lua",
        "replacement": "spec/builder_specs/$1_spec.lua"
    },
    {
        "pattern": "(luarules|common|luaui|gamedata)/(.*)\\.lua",
        "replacement": "spec/$1/$2_spec.lua"
    }
],

Footagesus/WindUI

WindUI is a open source UI library for Roblox Script Hubs

Warning

This WindUI was not inspired by, and the name has nothing to do with UI Frameworks

Warning

WindUI is currently in Beta. This project is still under active development. Bugs, issues, and unstable features may occur. We’re constantly working on improvements, so please be patient and report any problems you encounter.

Credits

Icons (https://github.com/Footagesus/Icons)

Links

Discord Server
Documentation
Installation

Example (wip)

loadstring(game:HttpGet('https://raw.githubusercontent.com/Footagesus/WindUI/refs/heads/main/main_example.lua'))()

saghen/blink.lib

Shared library for blink.* neovim plugins

Blink Lib (blink.lib)

blink.lib provides generic utilities for all other blink plugins and looks to fill the gaps in the neovim standard library, particularly around async, config, native libraries, git, regex and so on.

Installation

-- lazy.nvim
{ 'saghen/blink.lib' }

-- vim.pack
vim.pack.add({ 'https://github.com/saghen/blink.lib' })

Modules

All APIs are unstable until v1!

blink.lib: Utilities and lazy export of top level modules
blink.lib.config: Schema based config validation with dynamic per-mode/buffer lookup (merge vim.g/vim.b/config({}, { mode = 'cmdline' })/setup())
blink.lib.native: Build and download APIs for native libraries
blink.lib.task: Async task API with support for cancellation
blink.lib.fs: Filesystem APIs using blink.lib.task
blink.lib.log: Notifications and logging to file and/or console
blink.lib.nvim: Re-exported nvim APIs (nvim.create_buf(...))
blink.lib.timer: Timers with automatically schedule callbacks with support for cancellation, without racing
blink.lib.bench: Statistics-driven micro-benchmarking API (see benches/**/*.lua)

Roadmap

Modules that are planned but not yet implemented:

blink.lib.lsp: In-process LSP client wrapper
blink.lib.git: Git APIs using gix
blink.lib.regex: Regex using regex
blink.lib.persist: KV store with namespaces

`blink.lib`

Utilities and lazy export of top level modules

-- all modules re-exported
lib.config
lib.fs
lib.log
lib.nvim
lib.task
lib.timer

-- lazy require
local require = lib.require -- rename to `require` to trick the LSP into thinking it's the real `require`
-- or
local require = require('blink.lib.lazy_require')
local some_module = require('some_module') -- lazily required on first use

-- table/list utils
lib.list.dedup({ 1, 2, 3, 2 }) -- { 1, 2, 3 }
lib.list.reverse({ 1, 2, 3 }) -- { 3, 2, 1 }
lib.list.equal({ 1, 2, 3 }, { 1, 2, 3 }) -- true
lib.list.filter_map({ 1, 2, 3 }, function(v) return v > 1 and v + 10 end) -- { 12, 13 }
-- ...

lib.tbl.equal({ a = 1, b = 2 }, { a = 1, b = 2 }) -- true
lib.tbl.pick({ a = 1, b = 2, c = 3 }, { 'a', 'c' }) -- { a = 1, c = 3 }
lib.tbl.omit({ a = 1, b = 2, c = 3 }, { 'a', 'c' }) -- { b = 2 }
-- ...

`blink.lib.config`

Schema based config validation with dynamic per-mode/buffer lookup. Merges vim.g[module], vim.b[module], per-mode/bufnr configs and top level config.

local types = require('blink.lib.config').types
local config = require('blink.lib.config').new('my_plugin', {
  enabled = { true, 'boolean' },
  some_setting = { 'foo', types.enum({ 'foo', 'bar' }) },
  other_setting = { { 1, 2, 'bar' }, types.list({ 'number', types.enum({ 'foo', 'bar' }) })}
  nested = {
    setting = { nil, { 'function', 'nil' } },
  }
})

-- per buffer config, `vim.g` also works
vim.b.my_plugin = { some_setting = 'bar' }
config({ nested = { setting = function() end } }, { bufnr = 0 })

-- per mode config
config({ enabled = false }, { mode = 'cmdline' })

-- global config
config({ other_setting = { 3, 'foo' }})

-- access values in the config
print(config.enabled) -- true (would be `false` if `mode` was `c`)
print(config.some_setting) -- 'bar' (from vim.b.my_plugin)
print(config.other_setting) -- { 3, 'foo' } (from config(...))
print(config.nested.setting) -- function (from config(..., { bufnr = 0 }))

`blink.lib.native`

Most blink plugins use native libraries which are fetched from github releases when on a git tag (versioned release) or built on the user's device. This module provides utilities for resolving/downloading/building/loading libraries, fetching platform information and reading git commit/tags.

You may either use the blink.lib.native.managed module, an opinionated setup used in blink.* plugins, or the low level APIs directly (blink.lib.native).

`blink.lib.native.managed`

An example from blink.pairs:

local logger = require('blink.lib.log').new({ module = 'blink.pairs' })
local native = require('blink.lib.native.managed').new({
  module_name = 'blink.pairs',
  library_name = 'blink_pairs_parser',
  current_file_path = debug.getinfo(1, 'S').source:sub(2),
  logger = logger,
})

local pairs = {}

function pairs.setup()
  if not pairs.library_available() then
    return logger:notify(vim.log.levels.ERROR, {
      { 'Please add ' },
      { " build = function() require('blink.pairs').build():pwait(60000) end ", 'DiagnosticVirtualTextInfo' },
      { ' OR ' },
      { " build = function() require('blink.pairs').download():pwait(60000) end ", 'DiagnosticVirtualTextInfo' },
      { ' to your lazy.nvim config. For vim.pack, simply call either function before calling setup().' },
    })
  end

  -- plugin setup
end

function pairs.library_available() return native:library_available() end

--- Builds the precompiled library if it's not already available
--- @param opts? { force?: boolean, dev?: boolean }
--- @return blink.lib.Task
function pairs.build(opts)
  return native:build(
    { 'cargo', 'build', '--release' },
    function(repo_root, platform)
      return {
        repo_root .. '/target/release/libblink_pairs_parser' .. platform.lib_extension,
        repo_root .. '/target/release/blink_pairs_parser' .. platform.lib_extension,
      }
    end,
    opts
  )
end

--- Downloads the precompiled library if it's not already available
--- @param opts? { force?: boolean, dev?: boolean }
--- @return blink.lib.Task
function pairs.download(opts)
  return native:download(
    function(git_tag, platform)
      return 'https://github.com/saghen/blink.pairs/releases/download/'
        .. git_tag
        .. '/'
        .. platform.triple
        .. platform.lib_extension
    end,
    opts
  )
end

`blink.lib.native` low level APIs

Must more control allows for building with just about any build system.

local native = require('blink.lib.native')
local logger = require('blink.lib.log').new({ module = 'my_module' })

local current_file = debug.getinfo(1, 'S').source:sub(2)
local lib_name = 'some_library'
local your_repo = 'foobar/some_repo'

function load()
  return native.load(lib_name, native.try_git_commit(current_file))
end

function library_available()
  return native.resolve(lib_name, native.try_git_commit(current_file)) ~= nil
end

function build(opts)
  local platform = native.platform()
  local repo_root = native.git_repo_root(current_file)
  if repo_root == nil then error('Missing git repo root, did you install via a package manager?') end

  local system = native.exec_async(repo_root, { 'cargo', 'build', '--release' }, logger, callback):wait(60000)
  native.mv(repo_root .. '/target/release/lib' .. lib_name .. platform.lib_extension, native.library_path(lib_name))

  if not lib.native.load('blink_cmp_fuzzy', lib.native.git_commit(current_file)) then
    error('Failed to load built blink.cmp native library')
  end
end

--- Downloads the precompiled library if it's not already available
--- @param opts? { force?: boolean }
--- @return blink.lib.Task
function download(opts)
  local git_tag = native.git_tag(current_file)
  if git_tag == nil then error("Missing git tag, have you pinned the version? Set `version = '*'` for lazy.nvim or `version = vim.version.range('*')` for vim.pack") end

  local platform = native.platform()
  if platform.triple == nil then
    error(string.format('Unknown platform (os: %s, arch: %s)', platform.os, platform.arch))
  end

  local url = 'https://github.com/ ' .. your_repo .. '/releases/download/'
    .. git_tag
    .. '/'
    .. platform.triple
    .. platform.lib_extension
  local library_path = native.library_path('blink_cmp_fuzzy', native.git_commit(current_file))
  native.download_async(url, library_path):wait(30000)

  if not native.load(lib_name, native.git_commit(current_file)) then
    error('Failed to load downloaded blink.cmp precompiled library')
  end
end

`blink.lib.task`

Allows chaining of cancellable async operations without callback hell. You may want to use lewis's async.nvim instead which will likely be adopted into the core.

local lib = require('blink.lib')

lib.task.wrap(function(callback) vim.uv.fs_readdir(vim.uv.cwd(), callback) end)
  :map(function(entries) return lib.tbl.map(function(entry) return entry.name end, entries) end)
  :catch(function(err) vim.print('failed to read directory: ' .. err) end)

local tag = lib.task.new(function(resolve, reject)
  vim.system({ 'git', 'describe', '--tags', '--exact-match' }, { cwd = root_dir }, function(out)
    if out.code == 128 then return resolve({}) end
    if out.code ~= 0 then
      return reject('While getting git tag, git exited with code ' .. out.code .. ': ' .. out.stderr)
    end

    local lines = vim.split(out.stdout, '\n')
    if not lines[1] then return reject('Expected atleast 1 line of output from git describe') end
    return resolve({ tag = lines[1] })
  end)
end):wait(1000)

Note that lua language server cannot infer the type of the task from the resolve call. You may need to add the type annotation explicitly via an @return annotation on a function returning the task, or via the @cast/@type annotations on the task variable.

`blink.lib.fs`

Filesystem APIs using blink.lib.task

fs.list_dir(path, max_entries)
fs.read(path, size, offset)
fs.write(path, data, offset)
fs.rm(path)
fs.exists(path)
fs.stat(path)
fs.mkdir(path, mode)
fs.mkdirp(path, mode)
fs.rename(old_path, new_path)

-- path utilities
fs.basename(path)
fs.dirname(path)
fs.abspath(path)
fs.ext(path)
fs.join_path(path1, path2)
fs.normalize(path)
fs.parents(path)
fs.relpath(path1, path2)
fs.root(path)
fs.ensure_trailing_slash(path)
fs.remove_leading_slash(path)

`blink.lib.log`

Notifications and logging to file and/or console. Waits for UIEnter event to ensure the user sees messages.

local logger = require('blink.lib.log').new({
  module = 'my_module',
  -- defaults
  console = { enabled = true, min_log_level = vim.log.levels.INFO },
  file = { enabled = true, min_log_level = vim.log.levels.INFO, path = vim.fn.stdpath('log') .. '/my_module.log' },
})

logger:notify(vim.log.levels.INFO, { { 'message' } }) -- same api as `vim.api.nvim_echo`
logger:info('message %s', { foo = true }) -- "message { foo = true }"
logger:write_to_file('message\n')

`blink.lib.nvim`

Re-exported nvim APIs (%s/vim.api.nvim_/nvim./g)

nvim.create_buf(name, options)
nvim.open_win(bufnr, enter, config)
nvim.get_current_buf()
nvim.get_current_line()
-- ...

`blink.lib.timer`

Timers with automatically schedule callbacks with support for cancellation, without racing. Same API as vim.uv.new_timer().

local old_timer = vim.uv.new_timer()
old_timer:start(0, 0, vim.schedule_wrap(function() print('hello') end))
old_timer:stop()
-- timer stopped but callback already scheduled, races

local new_timer = require('blink.lib.timer').new()
new_timer:start(0, 0, function() print('hello') end)
new_timer:stop()
-- timer stopped and scheduled callback cancelled

`blink.lib.bench`

Statistics-driven micro-benchmarking API inspired by criterion. Bench files live in benches/**/*.lua and are run in a clean headless Neovim instance with manual GC and JIT.

:BlinkBench [filter]: run all benches/**/*.lua files (optionally filtered by substring) in a terminal split to the right
require('blink.lib.bench').setup(): register the :BlinkBench command
require('blink.lib.bench').run_file(): run benches for the current file only
require('blink.lib.bench').run_files(filter): run all benches/**/*.lua files programmatically

local b = require('blink.lib.bench')

b.run('my bench', function()
  -- code to measure
end)
b.run('customized bench', function()
  -- code to measure
end, { warmup = '100ms', measurement = '1s', output = 'verbose', save = false })

-- receive a report and comapre two runs
local fast_report = b.run('fast bench', function() end)
local slow_report = b.run('slow bench', function() end)
fast_report:compare(slow_report)

-- groups (can set options for all nested benches)
local group = b.group('table insertion')
-- local group = b.group('table insertion', { warmup = '500ms', measurement = '5s', output = 'verbose', save = false })
group.run('tbl[#tbl + 1] = val', function()
  local tbl = {}
  for i = 1, 100 do tbl[#tbl + 1] = i end
end)
group.run('table.insert', function()
  local tbl = {}
  for i = 1, 100 do table.insert(tbl, i) end
end)

Results are saved to {stdpath('state')}/blink/bench/{module}/{group}.{name}.json and compared against the previous run automatically. Set save = false to disable this behavior.

🚀 快速上手从零开始，为您在 Windows、macOS 以及 iOS/Android 移动端部署万象。 ➡️ 立即安装	⌨️ 核心输入体系深入解析万象独特的“带调拼音标注”、强大的辅码系统（小鹤、自然码等）以及中英混输机制。 ➡️ 了解核心
🪄 Lua 魔法扩展计算器、超级注释、符号包裹、动态时间戳、超级符号库（按名输入数千 Unicode 符号）... 探索让 Rime 拥有“超能力”的数十种微创新脚本。 ➡️ 探索魔法	⚙️ 词库与模型深度解析万象的现代数据工程。算一笔隐形的“时间账”，彻底告别低效的候选翻页，让输入如呼吸般自然。 ➡️ 揭秘底层逻辑

GitHub Lua Weekly Trending Repositories

koreader/koreader

KOReader is a document viewer primarily aimed at e-ink readers.

Main features

Screenshots

Installation

Development

Support

Contributors

amzxyz/rime-wanxiang

🌳 万象拼音

🌌 万象拼音——基于深度优化的词库和语法模型

✨ 效果预览

🧭 探索万象

🚀 快速上手

⌨️ 核心输入体系

🪄 Lua 魔法扩展

⚙️ 词库与模型

💎 标准版 vs 增强版

生态：

miscusi-peek/cheatengine-mcp-bridge

Cheat Engine MCP Bridge

The Problem

What You Get:

How It Works

Installation

Quick Start

1. Load Bridge in Cheat Engine

2. Configure MCP Client

TCP relay transport

3. Verify Connection

4. Start Asking Questions

~180 MCP Tools Available

Memory

Analysis

Debugging

Process Lifecycle

Memory Allocation

Code Injection

Symbol Management

Assembly / Compilation

Window / GUI Automation

Input Automation

Cheat Table

Kernel Mode (DBK / DBVM)

Critical Configuration

BSOD Prevention

Troubleshooting

Cheat Engine says "too many local variables"

MCP client cannot connect

Environment Variables

Example Workflows

Project Structure

Testing

The Bottom Line

neovim/nvim-lspconfig

nvim-lspconfig

Important ⚠️

Migration instructions

Support

Install

Quickstart

Commands

Configuration

Config priority

Creating a config

As code

As a file

LSP Settings Type Annotations

Troubleshooting

Bug reports

Contributions

Release process

License

Kong/kong

Getting Started

Getting started with AI Gateway for LLM and MCP

Features

Plugin Hub

Contributing