Meta 开源 Intermediate Graphics Library

2023-07-08 19:21 by 影舞

Meta 宣布开源 Intermediate Graphics Library（IGL）。IGL 为开发者提供了一组强大的工具为其应用创建高质量的视效和图形，能满足游戏、3D 建模等应用的需求。IGL 是一个跨平台图形库，支持 OpenGL、OpenGL ES、WebGL 和 Vulkan 等图形 API，它的开销小，外部依赖少。Meta 称 IGL 的特性包括：跨平台兼容，高性能渲染，易于使用的 API，可扩展，完全开源，可用于任何项目，没有任何许可限制。

https://www.khronos.org/blog/meta-uses-khronos-open-standards-in-new-intermediate-graphics-library

#开源

#py https://t.me/NewlearnerChannel/11324

#ai #tencent 通过应用 embedding 技术并结合 AST 解释器 #tool https://astexplorer.net/ ，实现了对 TDesign 代码知识库的自然语言查询。在 30 个常见用例的测试下，查询精度达到了 90%。
https://mp.weixin.qq.com/s/MpF9xBHYjgnCHNkFn1AsOA

ISON(Interchange Str Obj Num) 表示层：
- Map或T依据 Pair<KV>, Send.Idx<T> 流对接到传输层
- List,Array <- T(流.use=方括号, N=size提示)
- 1L 1f<-CharSeq, Date<-Str
- Any 才依据"type"(如 {}[]0~9 接口的内定) 加载子类。 RwEq<T>之格式, 依内定或查询项的 SendT. 含泛型

'T'type RwEq
- cat T //read,load
- cut(:T) //write,dump
at type: Type<T>

'this'type Send
- empty
-named TYPE SendT
named nodef
/* 编号查找 {k:v} 式语法的默认值 */
'T'data Idx(read:T, :Idx)

'this'type SendT
/* Any=this? 或nodef */
at vars: KV<Str Pair3<Sender Any Idx>>
- empty (size:CntM1=NO)this
- this.get(:Idx)Any
- this.set(:Idx,:Any)

/* 比如List<Any>项, 保留类名。sealed class 也需注册子类"type" */


  at typedTag: FnKV<Str SendT>?

从语言层建模了强类型static vars 与 Send.typedArg[List]={impl(Targ[0]) as RwEq SendT }
无需新建class ，就能支持新格式。只覆盖 Pair<KV>, Send.Idx<T> 的读写逻辑，且自带流式读写

#statement #PLT
编程造成问题 vs 解答造成编程
现况带来问题 vs 审美带来现况

软件的价值很有限，思想的复杂很空虚；不以自己的价值观拉黑人，是最大的尊重

我们有时难相理解🧐
“那你的 IDE 做的怎么样了，带类型的补全有么，还是笔记本没高亮?”
(“IDE支持? parser写完了当然会自带高亮和变量寻址/空缺提示啊? 什么叫能解析，但没高亮?”)

这是因为我草稿的PRR 里，输入流就是用高亮-区间嵌套来实现增量解析；没有高亮你连 unparse(ast) 都做不到
—诶，就连这个“反函数”，许多人也是手写的！

你会把学到的概念堆砌，以“你们能做到的”代码复杂度为傲
我会另起炉灶设计， 联动其他领域和元编程，做简单强大的框架，以用户的功能为傲

你的起手，是解决 好大喜功所造成的问题 ，说复杂很是哲学
我的终笔，是把已解决的问题，靠编程， 随手「对接」到既有API上

心智模型、语言、文字(翻译)，我能分清这每一层表象的最大公约数，所以知道领域和语言该占多大份量，懒得贪占一丝一毫。

编程语言是我的母语。我最不需要的，就是像alien一样，在这知识基建上耍花招
如果语言是解药，其特性就是对“症状”，而不是“病因”
对于用户，少即是多：别让他们发现自己有用到框架
对于框架，多即是少：涉足的问题越多，孤岛化的“特殊功能”就越少。

同样是优雅和简短，有些人大道至简，另些人大道智减

习惯写层层嵌套、滥用配置的人，就会觉得 Python 的缩进是反人类的，毕竟它用人的语感，暴露了代码之丑
无论语种，文字都有雅俗之别，编程不应该是墓碑上的雅，它必须与时俱进。

我的课题不是懂不懂，是已知和未知
毕竟，我以重复前人的技术和缺陷为耻
https://t.me/kotlin_cn/81052

#Kotlin #design 谈这我就想到，绝句的 KV<Int Str> 和 [1 2 3].lets:"+$this" 的 Fn1<Int Str>
就是两回事，避免歧义
[1 2 3](Sum)
[1 2 3](Sum{*}) 才真正应该是函数调用
get(Idx)T 就应该是方括号
设计语言时要顾虑一致性，不能为了理论优雅，就抛弃语文美感

"a".mayAs<Int>?.Str !
(1~9)(Sum{+}.byStep )

(1~100 by 2~101) ( Sum{[a b]a+b } by: it%10 } )
vs

("a" as? Int)?.toString !!

(1..9).scan{A+B}
1..100.zip(2..101).reduce{a,b->a+b).groupBy{it%10}

复杂不一定坏，只要扩展性和性能上有优势
最开始我只是把 py 的缩进给了 Kotlin，但最后，我没有把新手可读性 放在考量里
- 'TR' T lets(:Fun1<T R>) = fn()
fun<T,R> T.lets(fn: T.()->R)=fn()
at N id= +0
val N.id get()=this+0
—
正则和DFA
说起来对同T 的多个 fun T.xx ，是可以像Scala那样用 implicit inline class ?
Scala的优点和败笔同时是implicit。不知道怎么评价，就像你提供了技巧，但没约定好写法

^ val by 可以用 provideDelegate()=ReadOnlyProperty 定义
你没有把defaultFn 传到非 inline 的 fun/var (如forEach {}? ) 里，所以不应该加 crossinline
{cross,no}inline 只是用来禁用函数式参数的ret跳转内联的

好奇在 nonlocal return@ 上， kt 是如何内联的，假如参数内联可以靠IR模板的话
很好奇 List<get T> 在Go里为何不存在

OOP是强求了继承关系，或许正常来看 'T'(T Num Sort) 才是List<Int>的类型
但我讨厌滥用接口trait，应该 type Num Sort
感觉py的渐有类型换成全局infer 会更快（？ TS 可能有(infer from usage)，但是作为IDE功能了

我喜欢用成员交、成员并 表达 union 和 intersection types
java里成员并对接口(&)有点用, 甚至能为 tuple实现Func
—
现在用GPT， 有时感觉编程语言是没必要逐个去学的

但其实语言也能简化问题，方便编程创作；微调时用中文写需求，就很烂
这种有方向特色的创作，是GPT暂时做不到的；目前我只写这种代码
—
#Java圈莫名其妙的不做代码复用，像 Logger 和 Repo 这样就可以依赖注入进去

但变量是应该由 abstract class 来声明 ，不应该留样板代码，否则要设计模式干啥？

Javaer 的设计模式，除了Builder这种解决语法贫瘠的，都是做了一半， 留了一半给人当CV boy
PYer 虽然又蠢又冗，但至少不会贩卖问题；它解决过的都没有什么复制粘贴和坑

#java #PLT #code Expr/visitor problem
type Exp
- eval Any

data N(lit:N) Exp
^-eval=lit
data Add(e:PairOf<Exp>, k="+") Exp“

树结构

”
^-eval=e.lets: A.eval+B.eval

''Value=Either<Int Bool>
“没必要用 VInt VBool 来实现sealed class”

type Exp
-'R' accept(: .Vis) R


  'R'type Vis
    - N(:N)R
    - Add(:PairOf<R>)R

“Exp 本身就可二次遍历，省略建立树结构的Vis”

named IntOps Exp.Vis<Int>
  ^- N(n)=n.Int
  ^- Add(e,k)=e.lets: A+B
  
Add(N(3),N(5)).accept(IntOps)==8 

...

🤦🏻好吧，我服了， 10页纸也没讲到重点
要学习这种大佬的文章， 开销还蛮大的 。果然自己从根源问题来解，是最好的选择

直接说 把eval 改成 visit(:为各子类重载)R 就能解偶，
把R改成Eval接口就能用新类型添加操作，例如 Op(EvalX,EvalX)=>可toStr的树
正如把 eval:Int 改为 eval:Any 就能做更多事
哪来那么多破事

#statement #ai BV1UN411U7nG
现在用GPT(最近还添加了视觉、代码生成+调用器❤️ 的功能,强过 Windows Copilot)， 有时感觉语言是没必要逐个去学的

程序员是「漫画家」而非「绘画匠」
语言本该是用以「帮助思考」，而不是「允许你表达」，
《一拳超人》自小学馆走向世界
《流浪地球》的世界级特效，却遮不住脸谱化的小学内核

语言是要简化问题、建立心智模型，方便编程创作。所以，微调时用中文写需求，仍不如有专业特质的人
这种有技术方向的创作，GPT暂时做不到，目前我只写这种代码

今天许多程序员的知识资本，
无非是默写“特色”术语或用法，或是在样板class上，加啰啰嗦嗦的验证逻辑

这种无聊的「护城河」，只是让App们越来越混杂臃肿
语言并不是「程序员特供」的Excel，并不是用来“编译”和“访问接口”的破鞋，

编程是归纳再思绪飞扬的「创造力」之习惯、是教育性的人类语言

parser 一族的本质是json.loads() ，是算法思想的传输形式、绘画的线条、小说的中文译本；这些避重就轻的“零件和表示”
并不属于设计或创作

优秀的程序员会在编程前解决问题。“实践”，只是让心智模型能够对接API 而已

代码是程序「设计」的最后一环

作为在“计算机还未发明”时代的编程者 #history
Dijkstra 的名言：

编程无关计算机，就像天文无关望远镜

简单是可靠的先决条件，不是可靠的牺牲品

编程的艺术就是藏绌的技术。
程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是谦卑的，重点是要象逃避瘟疫那样逃避 “聪明的技巧”。——1972年图灵奖演讲

我们所使用的工具深刻地影响我们的思考习惯，从而也影响了我们的思考能力。
根本不可能用一把钝斧子削好铅笔，而换成十把钝斧子，会让事情变成大灾难。
--

「使用了 GOTO 语句的程序员乞求 Dijkstra 的宽恕」，伦勃朗 1669
“他为并不存在的机器写了五年程序”
“1957 年，他结婚的时候在申请的职业一栏写上了「程序员」，结果被政府拒绝，因为当时荷兰没有这个职业”

我的母亲是一个优秀的数学家。有一次我问她几何难不难，她说一点也不难，只要你用“心”来理解所有的公式。如果你需要超过5行公式，那么你就走错路了。

当没有计算机的时候，编程不是问题。当有了比较弱的计算机时，编程成了中等程度的问题。现在我们有了巨大的计算机，编程就成了巨大的问题。

研究物理的人如果遇到不理解的事情，总是可以责怪上帝，世界这么复杂不是你的错。但是如果你的程序有问题，那就找不到替罪羊了。0就是0，1就是1，就是你把它搞砸了。
为什么这么少的人追求优雅？这就是现实。如果说优雅也有缺点的话，那就是你需要艰巨的工作才能得到它，需要良好的教育才能欣赏它。
https://www.yinwang.org/blog-cn/2014/02/18/dijkstra-interview

如果十年以后，你以快而脏的方式做什么事的时候，能想象我在你的肩后看着，然后对自己说：「Dijkstra 不会希望这样的。」那么对我来说，这就和永生一样了。

-- Edsger Wybe Dijkstra

“编程语言是我的母语。
我的课题不是懂不懂，是已知和未知
我以重复前人的技术和缺陷为耻”--动苏

> https://t.me/dsuse/1064
https://bellard.org/otcc/otccn.c 是tccboot所用JIT编译的最简版

呃.. 第一次见到 wiki 编辑战
小时候（高中） 很喜欢 #mozilla #Rust ，还写了这个(列表处理)程序

大概就是暗暗觉得……高性能又开源（根正描红的那种，练习时长两年半只为开源语言，太感人了）

后来看的就淡了，因为rust真的很（烧脑？）
—
我觉得能和 C FFI 的某种意义上都是系统，比如 py 的嵌入式GPIO libs
.Net 有P/Invoke和struct{}, 栈分配 啊，他们可能觉得入选 osdev.wiki 才叫系统编程

无非就是FFI和struct指针的问题，既然 py (cffi能读写指针), .Net unsafe marshall 支持二进制，也是能实现OSkrnl的需求

但KN 不是，因为强类型强检查 弱框架，写着麻烦

系统级就是你可以用来写内核和驱动
这个 lunatik 能在内核层开启 #Lua REPL
这个 https://duskos.org/#operator 类似 tccboot, 但是嵌入式的

GPT-4 有 1.8 万亿参数

2023-07-11 19:30 by 天堂的喷泉

OpenAI 今年初公布的新一代大模型 GPT-4 的技术细节泄露，它有 1.8 万亿个参数，利用了 16 个混合专家模型（mixture of experts），每个有 1110 亿个参数，每次前向传递路由经过两个专家模型。它有 550 亿个共享注意力参数，使用了包含 13 万亿 tokens 的数据集训练，tokens 不是唯一的，根据迭代次数计算为更多的 tokens。GPT-4 预训练阶段的上下文长度为 8k，32k 版本是对 8k 微调的结果。如果是在云端进行训练，以 每 A100 小时 1 美元计算，那么一次的训练成本就高达 6300 万美元。不过今天的训练成本能降至 2150 万美元。

https://threadreaderapp.com/thread/1678545170508267522.html

#人工智能

#PLT #statement 《程序员的阶梯》
知其变，守其恒，为天下式
穷其变，知不穷，以明我志
这世间唯一不变的，只有变化本身。

那种无论谁来写，效果都一样的程序；即便作者在纸笔键盘里锋芒毕露，也泯然众人

那种无论什么功能，都有面向和巧思的笔者；虽其文章和软件一览无遗，也望尘莫及

我们崇拜技巧，但赋予代码意义的，只是对问题的改良和创作，是技术的选型。
我们不是编程接口的服务生

没有呼之即来的心智模型，难成有趣的作品；但无数把「守其恒」的归纳法视作求知的人，徘徊在不思则罔的迷雾

我所追求的编程，不是拣起芝麻忘记西瓜的X-Y问题，而是一开始就观四海之利弊、弃古今之高低；为靠近根源问题，
不惜移掉自以为精妙的“原创”算法，不惜永远“泯然众人”；才能突破领域的桎梏，用「人」的方法定义软件，用问题的本来面貌来解题

我所创作的编程，汗水和灵感将「治未病」，有余力方知「天下事」

我早已决定，不为雄伟和磨难的价值去编程，只是欣赏作品、享受当下。

#js #web #ai #tool 生成的 blog Planet
基于 React & WASP
https://dev.to/wasp/gpt-web-app-generator-let-ai-create-a-full-stack-react-nodejs-codebase-based-on-your-description-2g39

#cg #tool https://www.recraft.ai/
#plt #book http://composingprograms.com/
#web react https://tanstack.com/
https://arwes.dev/play?code=&type=predefined&sandbox=Components%7C%40arwes%2Freact-bgs%7CMovingLines%7Ccomposition
jotai.org 状态管理

duangsuse:
voicepeak 就是synthv.华裔作者开发的啊，不开源，但是基于 VITS,diffsinger 的 OpenUTAU 和 moetts 开源
https://t.me/wtmsd/43486

支持的 https://huggingface.co/spaces/skytnt/moe-tts

应该信任系统tts，或者用connectNative 连接py的各种模型啊

是国人，但公司在日本

#py #code 缩进列表 ; YAML版本
#bing 并没有帮我避坑 😒，Group(匹配是否成功) 这玩意它也理解不了；不过 indentedBlock 自带嵌套深度倒是挺巧妙，我以为应该有 流.字典.. 活到老学到老

import pyparsing as P
item = P.Forward()# 递归

LB,RB,LS = map(P.Suppress, "[]:")

item <<= P.pyparsing_common.number() \
|P.Group(LB + P.delimitedList(item, delim=P.Empty()) + RB) \
|LS+P.indentedBlock(ls:=P.ungroup(item), nTabs:=[1]) #不分组会平铺delim

ls.parseString('[1 2]').asList()

周刊文章

#china #history #life 通缩造成的影响体感不明显🤔
失业率带来的恶果要在3~5年后产生
“中国不会失去多少年，一切都是伟大的探索”
https://m.youtube.com/watch?v=CWT1UfQa3co
6:00 奥姆教的地铁毒气事件
15:00 日本在2002年左右才流行“失去了十年”的反思
Leonard: 🐻微服私访，为何没有安全感：党大于法，猎人亦猎物
https://m.youtube.com/watch?v=8doj1q1RKhM&t=7m

#plt 这几天灵感非常乱， 但修正了 改同/file.RwEq<T>, 可见/可定性 (abstract 啥的,语序改后缀)
我最喜欢的就是基于 tailrec 的无限循环:

lets:
  say("hello")
  loop()

有灵感是好事，但设计稿经常变动也是让实现者相当困扰的。 作为既要设计也要实现的人，重复学习的痛苦不可避免。

不过话说回来这个 emoji 😋 翻译真是太有趣了。原来跨语言的编程语言.. 不用语言来思考问题， 是真的可以有的！

原先 .ju 的文化是 .ju_zh(cn) ，我打算改成默认英文了。 尽管初期都是中文在出力(包括统一 operator fun 为 受XX, 可为Either 可同Eq)，就目前看来英文对OOP 简化(data type let lets 比 Kt 的 class interf run apply 高到不知哪去) 的贡献比中文还要大

从长远看， emoji❤️ 或许在API枚举时有大作用，表情化能揭露“设计的逻辑指数”，如同苔藓害怕雾霾。意想不到的收获