AI 资讯

Someone asked us a sharp question on X this week. Tokenized stocks will drop dividends straight on-chain, so do we see any downsides? It's a fair question, and the honest answer is yes, one big one. The downside isn't the dividend itself. Instant, programmatic, no broker statement to wait for: that part is genuinely good. The downside is that you can't see it. On-chain dividends for tokenized equities are silent. They arrive without a transaction, without a notification, without anything landing in your wallet history. And a payment you never see is a payment you never declare. That's not a tracking annoyance. It's a tax problem, and it gets expensive. The dividend that never sent a transaction Backed Finance's xStocks (the Xs-prefixed mints like AAPLx, TSLAx, NVDAx) and Ondo Global Markets equities (the ondo-suffixed mints) both use the SPL Token-2022 ScaledUiAmount extension. It's an elegant piece of engineering. When the underlying stock pays a dividend, the issuer doesn't airdrop tokens to thousands of wallets. It updates a single number, a multiplier, on the mint account itself. The instant that multiplier changes, every wallet holding the token shows a larger balance. Your 10 shares are now worth the equivalent of 10 shares plus the reinvested dividend. No transfer hit your wallet. No transaction was signed. Nothing appeared in your activity feed. The number simply went up. Compare that with a traditional brokerage. When Apple pays a dividend, you get a line on a statement, an email, a figure on a 1099 or an annual tax summary. The paperwork chases you. On-chain, nothing chases you. The dividend is real, it's yours, and the only evidence it happened is a multiplier value buried in an on-chain mint account that almost nobody thinks to read. Why a number going up is a taxable event Here's the part that catches people. Dividend income is ordinary income. It's taxable in the year you receive it, at your marginal rate, in every jurisdiction we serve: Australia, the

AI image tools rarely make me feel like I'm part of the creative process. They are, afterall, mostly designed so that people with no design experience can type in a few words and get back a usable result. So I was pleasantly surprised by Adobe's latest take on an AI image assistant: it's a bot […]

Martin Fowler's May 27 Fragments brings together four arguments with direct implications for teams working with AI agents. All four are worth covering. Ian Johnson: build quality gates before releasing the agent Ian Johnson published a series about restructuring a gnarly codebase: three months, 258 commits, moving from a Laravel monolith with no tests to an application with automated quality gates and an AI agent shipping production code with minimal supervision. The insight Fowler highlights is about the transition from in-the-loop to on-the-loop: "For the first two months of this project, I used Claude Code with auto-approve turned off. Every file edit, every terminal command, every change… I reviewed it before it executed. The results were good. The code was clean. But I was doing most of the thinking and half the typing. The agent was a fancy autocomplete with better suggestions." Ian Johnson Manual review of every change is not how you build trust in the agent. Trust comes from building the structure that ensures the agent will do the right thing, then stepping back. The sequence: characterization tests first, static analysis, architectural patterns that make things flow correctly. Fowler notes this is exactly the sequence he would use himself. Adam Tornhill: roughly 2 hours of cognitive endurance Adam Tornhill observes that agentic work has a decision density that is mentally more expensive than it appears. The estimate is roughly two hours as a sustainable limit, not a full day of work. The implication: adding more parallel agents does not solve the problem, because the bottleneck is the coordinating engineer's cognitive capacity, not available processing volume. The solutions are smaller tasks, automation, and verification mechanisms, not more parallelism. NHS: closing open source repositories NHS (UK National Health Service) closed open source repositories citing LLM threats to code security. The UK Government Data Services countered directly: making code p

Pope Leo XIV’s new encyclical on artificial intelligence includes a statement that warrants serious attention from technologists and policymakers: “Technology is never neutral.” Magnifica Humanitas (“Magnificent Humanity”) is a clarion call to all people to act with courage and solidarity as we enter an age already being transformed by artificial intelligence, the greatest change in…

When I first connected to a precious metals WebSocket API, I expected to get a clean stream of prices. What I actually got was a firehose of mixed ticks—gold, silver, platinum—all arriving through the same callback. If you’ve ever tried to build a trading bot or a custom chart, you know this is a recipe for disaster. In this post, I’ll share how I solved the problem with a few lines of Python and a clear mapping strategy. The scenario: You have one WebSocket URL that pushes quotes for multiple metals. You need to separate them so you can update different UI components, run independent strategies, or store them in distinct database tables. The data pain point: every message uses the same JSON structure, and the only differentiator is a field like symbol . If you don’t act on it immediately, everything gets mixed up. Identify Assets via the Symbol Field Start by checking the API docs for the field that carries the instrument code. Usually it’s symbol , but instrumentId or type are also used. Here’s a typical reference table: Field Description Example symbol Asset code XAUUSD, XAGUSD instrumentId Internal platform ID 1001, 1002 type Asset class gold, silver I turn this into a dictionary mapping each symbol to a human-readable category: asset_map = { " XAUUSD " : " gold " , " XAGUSD " : " silver " , " XPTUSD " : " platinum " } Buffer Messages by Type Because these streams are high-frequency, I avoid processing every tick individually. Instead, the WebSocket callback just updates an in-memory store that is already grouped by asset type: # Keep the hot path extremely light def on_message ( msg ): symbol = msg [ ' symbol ' ] price = msg [ ' price ' ] asset_type = asset_map . get ( symbol , " unknown " ) cache [ asset_type ][ symbol ] = price Then, a background timer fetches the latest prices from cache["gold"] and cache["silver"] separately and does the actual work—like computing indicators or rendering charts. The key benefit is complete isolation: your gold logic never t

In modern application development, exposing database logic as REST APIs is a powerful way to integrate systems. Oracle REST Data Services (ORDS) makes it easy to turn PL/SQL into RESTful APIs without needing a separate backend service. In this blog, we’ll walk through how to create a simple POST API using ORDS and PL/SQL to insert data into a table. Pre-requisites A cloud-based ATP wallet (I prefer) Let's start how we create the APIs on the top of any custom table which relies on databases Create a table in the oracle SQL Developer and followed by create an ORDS Module 1.Create an ORDS Module A module is a logical container for related REST endpoints. What this Module does ?? Creates a module named nj_api Defines base URL: http://server_name/ords/table_Schema/nj_api/ 2: Define a Template (Endpoint Path) A template represents the API endpoint path. It defines how Endpoint URL:/ords/table_schema/nj_api/insert_data 3: Define the Handler (Business Logic) The handler contains the logic executed when the API is called. Key Concepts: p_method => 'POST': Defines HTTP method p_source_type => ORDS.source_type_plsql: Uses PL/SQL block Bind variables (:name, :num, etc.) map directly to JSON request body parameters 4: Testing the API Using Tools like Postman,cURL,ORDS REST Workshop I tested with Postman FYR Let's call same in Oracle VBCS in new blog. .. Try other methods like Delete, PATCH & GET

Podlite 2.0 is tagged. Podlite is a block-based markup language built around typed blocks and explicit boundaries — the same document is meant to read cleanly whether a person or a tool parses it. This release adds eight blocks and attributes and changes two parsing rules. The specification is at podlite.org/specification ; the full changelog sits inside the spec under =head2 v2.0 . The Coming in Podlite 2.0 article from the review window covered what is new in depth. This post focuses on what to do now: how to migrate existing documents and where to find the rest. For most documents the answer is short — a well-formed v1.0 document renders unchanged under v2.0. Breaking changes Two changes parse differently than before. Neither touches a well-formed document — if anything needs updating, it is a parser, not your text. Legacy attribute syntax removed A few outdated string attribute formats are gone. The bracket form ( :key<value> ) and the parenthesized form ( :key('value') ) remain. If a document uses the current syntax, nothing changes. =include is now a directive =include always behaved like a directive, but the spec previously listed it under block types. Tokenization rules differ between directives and blocks. Parsers built against the v1.0 spec must move =include into the directive dispatch path alongside =config and =alias . For document authors: no change. =include still takes the same syntax and produces the same output. The reclassification matters only for tools that build ASTs. New features at a glance Eight additions ship in v2.0. Existing documents render unchanged. =boundary : a typed section divider. Renders as a horizontal rule, exposes structure to tools. =set : pre-configure attributes for the next block. Multiline values, inline markup, lexical scope. G<> + :masked : content masking. Inline mark or whole-block attribute; hidden by default, revealed by render condition. =data-table block: renders CSV or TSV as a table. Three source forms (inline b

A complete ML pipeline: engine, backprop, binary format, and a live browser demo. Zero dependencies. Under 200 KB total. If you have built machine-learning projects before, you have probably done it by importing PyTorch, TensorFlow, or scikit-learn and calling .fit() . Those are excellent libraries. This article is about what happens when you deliberately do not use them — when you build every piece of the pipeline yourself, in a language that compiles to WebAssembly, and the result runs live in the browser with no server, no Python, and no cloud bill. Here is the live demo: move four sliders, watch the predicted Iris species update in real time. The model is running entirely inside your browser tab, loaded from a 1.1 KB binary file, powered by ~100 KB of WebAssembly compiled from pure Rust. This is the story of how I built it and why the engineering choices made it work. Why Rust? Why WebAssembly? Why zero dependencies? Three constraints drove every design decision. WASM requires no_std or a carefully limited std . The wasm32-unknown-unknown target has no operating system, no file system, and no libc. A crate that links against rand , ndarray , or any library that makes OS calls will not compile to it without significant plumbing. An engine built from nothing but the Rust standard library compiles cleanly to every target, including WASM. A zero-dependency std -only crate is uniquely auditable. There are no transitive dependency trees to vet, no supply-chain risks, no version conflicts. Every line of code that runs in the user's browser lives in this repository. The deployment story becomes the technical story. A 100 KB WASM blob that runs locally in the browser is not just a cost optimisation — it is a privacy guarantee (user inputs never leave the machine) and a latency guarantee (inference is microseconds, not a round trip to a cloud API). That story is only possible because the engine has no external dependencies that would bloat the binary. The architecture: ei

Welcome back to Day 3, Python dynamic duo! 🚀 If you survived Day 2 , you now know how to create variables and throw strings, integers, floats, and booleans into their own little cardboard boxes. 📦 But what happens when you’re building a game and your character needs an inventory? Or you're making a shopping list app? Creating 50 different variables like item1, item2, item3 will make you want to throw your router out the window. 🪟💻 Today, we are leveling up our storage game. We are moving out of single cardboard boxes and packing a Virtual Backpack: Enter Lists! 🎒🎉 🎒 What is a List? In Python, a List is a data structure used to store a collection of items in one single variable. Think of it like a backpack where you can stuff multiple things inside, keep them in a specific order, and pull them out whenever you need them. Creating a list is simple. You use square brackets [] and separate your items with commas: # Packing our survival backpack 🗺️ backpack = [ " map " , " flashlight " , " water bottle " , " protein bar " ] print ( backpack ) # Prints: ['map', 'flashlight', 'water bottle', 'protein bar'] The coolest part? Python lists don’t care what you put inside. You can mix strings, integers, and booleans all in one single backpack (though usually, it makes the most sense to keep similar things together). 🤯 The First Rule of Coding Club: We Start Counting at Zero! Here is where programming turns your brain upside down. 🧠🙃 If I asked you what the first item in our backpack list is, you’d logically say "map". And you'd be right in human language. But in Python-speak, computer memory starts counting at 0. This is called Indexing. To pull a specific item out of your backpack, you write the name of the list followed by the item's position (index) inside square brackets: backpack = [ " map " , " flashlight " , " water bottle " , " protein bar " ] # Pulling out the items using their index 🔍 print ( backpack [ 0 ]) # Prints: map (The absolute first item!) print ( backpack [

One unified API for Gemini, OpenAI, Anthropic, HuggingFace, Ollama, on-device Gemma, and GGUF models — with tool calling, memory, and safety guardrails built in. The Problem Building AI agents in Flutter is fragmented. Every provider has a different API shape. There's no standard way to switch between cloud and on-device inference. Tool calling, persistent memory, and safety guardrails are always custom implementations. The result: developers rebuild the same plumbing for every project. What It Is genesis_ai_sdk is a universal Flutter SDK for building AI agents that run locally and in the cloud. One clean API. Seven providers. Zero vendor lock-in. Supports: Gemini (Google) OpenAI (GPT-4o) Anthropic (Claude) HuggingFace (any public model, no download needed) Ollama (local server, no API key) On-device Gemma (fully offline) On-device GGUF via llama.cpp (fully offline) Switch providers by changing one line. Your agent code stays the same. Quick Start — 10 Lines of Code import 'package:genesis_ai_sdk/genesis_ai_sdk.dart' ; final agent = GenesisAgent ( provider: GeminiProvider ( apiKey: 'YOUR_KEY' ), systemPrompt: 'You are a helpful assistant.' , tools: [ GenesisTools . calculator , GenesisTools . dateTime ], ); final response = await agent . chat ( 'What is 1337 * 42, and what day is it?' ); print ( response ); The agent figures out which tool to call, executes it, and returns the answer. No prompt engineering needed. The Features That Actually Matter Real Tool Calling — Not Just Text The ReAct loop is fully implemented. The agent reasons → calls tools → observes results → repeats until it has a complete answer. An onStep callback fires for every intermediate step — perfect for building a "thinking…" UI. Custom tools are five lines: final weatherTool = GenesisTool . define ( name: 'get_weather' , description: 'Returns weather for a city.' , params: { 'city' : ToolParam . string ( description: 'City name' )}, execute: ( args ) async = > fetchWeather ( args [ 'city' ]), )

Suppose you have ever woken up to an inbox full of spam from your own contact form; you know how frustrating it is. Random gibberish. Fake email addresses. Crypto scams. All arriving because a bot found your form and started hitting it automatically. The usual advice is to add a captcha. But most captcha tutorials assume you have a backend server to verify the token. If you are running a static site, a Webflow site, a GitHub Pages project, or any HTML form without your own server, you are stuck. This tutorial shows you how to add a working captcha to any HTML form in under 5 minutes. No backend required. No server setup. No PHP. Just a form that blocks bots automatically and turns every real submission into a tracked lead. What You Will Need You need two things: A free Formgrid account at formgrid.dev . Formgrid is an open-source form backend and lead pipeline that handles all the captcha verification on the server side for you. An existing HTML form on your website or a new one you are about to build. That is it. No Cloudflare account. No hCaptcha account. No API keys to manage yourself. Step 1: Sign Up for Formgrid Go to formgrid.dev and click Sign Up Free . No credit card required. Once you are logged in, you will see your dashboard. This is where all your forms and leads live. Step 2: Create a New Form Click Create Form and give your form a name. Something like "Contact Form" or "Quote Request" works fine. You do not need to use the form builder for this tutorial. You already have your own HTML form. You are just using Formgrid as the backend that receives your submissions, verifies the captcha, and tracks your leads. After creating the form, you will be taken to the form details page. Step 3: Copy Your Form Endpoint URL On the form details page you will see your unique endpoint URL. It looks like this: https://formgrid.dev/api/f/your-form-id Copy this URL. You are going to use it as the action attribute of your HTML form. Update your HTML form to point to this

I am currently doing a research internship (2 months) in VLA and I have come across the Hopfield network based on the paper Hopfield Networks is All You Need and seeing the potential advantages of using this as a memory module over the transformer architecture based HAMLET module, I have decided to implement this on top of a SmolVLA backbone to see how it works in comparison to the current memory modules which we have now. How is the feasibility of this idea and would this even work in VLAs? (I was previously working on Equivariant VLA based on equivariant CNN , but it was already published so I moved to this) submitted by /u/No_Mixture5766 [link] [留言]

submitted by /u/viks98 [link] [留言]

We built a monokernel that runs the full decode sequence as one GPU-resident program on AMD MI300X, with some neat optimizations. The die topology is central to the result, we map memory access patterns to the physical layout, compute units group by their associated IOD, and the hardware runs at its full design performance. Up to 3,300 output tokens/s per request, batch size 1, no speculative decoding, no quantization, on 8x MI300X. This preview runs a small 2B coding model, and we plan to support large frontier MoE in the future. Technical deep dive: https://blog.kog.ai/building-a-single-kernel-latency-optimized-llm-inference-engine-on-amd-mi300x-gpus Try it: https://playground.kog.ai submitted by /u/averne_ [link] [留言]

GitHub reports cutting token costs in agentic CI workflows by up to 62% by pruning unused MCP tools, swapping some MCP calls for gh CLI, and running daily “auditor” and “optimizer” agents. A token-usage.jsonl artefact and an Effective Tokens metric help track spend across models and spot regressions. By Mark Silvester

FastAPI released an official VSCode extension, which includes features such as route exploration, endpoint search, and CodeLens-style navigation. This tool aims to enhance the development experience for FastAPI users. submitted by /u/Top-Rush83 [link] [留言]