D语言基金会2022年10月的会议是季度性的,即有几个行业代表参加了会议.会议在2022年10月7日14:00UTC的JitsiMeet举行.
以下人员参加了会议(名字旁边有DLF的人或为D语言基金会董事会成员,或为受薪员工,或为附属志愿者):
1,安德烈.亚历山大雷斯库(AA)
2,Mathis Beer (Funkwerk)
3,沃尔特.布莱特(DLF)
4,伊恩.布克劳(DLF/GDC)
5,Ali,Cehreli(DLF/梅赛德斯奔驰北美研发部)
6,Max豪顿(DLF/对称)
7,马丁.金克林(dlf/ldc)
8,丹尼斯.科佩尔(DLF)
9,马里奥.克洛普林(Funkwerk)
10,MathiasLang(DLF/Symmetry)
11,RobertSchadek(DLF/Symmetry)
12,巴斯蒂安.韦洛(SARC)
马丁说,很高兴看到dub最近工作.
在LDC方面,他目前正在合并dmd和d运行时库前,合并D运行时和D前端的中间步骤,这是改变如何合并D运行时,D前端和DMD测试套件到LDC的第一步.
他报告说NicholasWilson接受了些外部帮助来赶上LLVM中累积变化.它总结了些变化,并指出这很重要,因为它为支持LLVM15和16奠定了基础,这两个版本都有重大变化.
关于ImportC,目前支持还不错,但希望不要在胶水层中出现太多特例.已完成位字段了.
现在,他已看到了一些与获取,在D中按常量分配而在C中在栈上分配的结构体字面地址相关的测试用例.在DMD中,这是通过更改胶水层来修复.他希望这类事情越少越好.
ImportC初化器列表仍然在AST中,但另一个胶水层问题是C中多维静态数组的初化器.该初化器仍然有一些LDC不支持的C初化器列表.因此,他认为可转换它们为D初化器,这样就不必担心C初化器列表.他给的另一个示例是,当串字面长度比数组长度短时,用串字面初化静态数组.
只要特例数不增加,Martin就很高兴.因为已修复ImportC的问题,他不希望每个版本都需要更多代码.而LDC是D编译器.可编译C不错,但主要用例是可导入C头文件,以便与外部编译的C代码互操作.
关于,切换根导入顺序可能会编译错误.他说,他已微调整DMD了来修复特定测试用例,但打开了前向引用问题,主要问题是@safe推导似乎依赖语义分析的顺序.属性推导还有其他问题.
Bastiaan报告说,随着代码库增长,SARC经常遇见DMD崩溃的问题.好消息是,LDC编译得很好,他认为可能是DMD耗尽了栈空间,LDC只是分配了更多的栈空间.Martin说他最近已把栈限制从8MB增加到16MB,可能就是原因.即将发布的DMD2.101.0版本包括相同的栈限制增加.)
上次会议上,允许更改可抛的内部跟踪信息,给栈跟踪加了些颜色,他有了概念验证,但还要准备.
还更新了构建包的问题.会议前几天,构建包已完全坏了.D机器人在10月1日左右崩溃,所以没有计划,构建包一直不工作.会议前,搞定,它比以前慢了一点.但是可工作.现在可更新它了.以前问题是依赖项列表是静态的:无法控制它.如,因为无法更新LLVM,一直在使用LDC1.29版本.
他认为构建包是拥有的最好的CI之一,因为它在实践中测试了其他人的代码,并抓住了大量的回归.前进的方向是同吉动作整合.现在,几乎每个人在他们的GitHub仓库中都有动作,所以如果可以他们的动作定义作为测试基础,那将是惊人的.这不是很简单的.但他认为这可行.
丹尼斯已实现DIP1035系统变量,参考,并要求沃尔特审查.沃尔特已合并,在此,而Dennis开始实现命名参数DIP,1,2.
还偶然发现了循环推导属性问题,检查函数调用是否安全可能会导致认为它是不安全的悲观假设.他已考虑过修复该问题,他认为此时,乐观假设函数是安全的是可能的.他希望确保从悲观向乐观方法转变不会造成很大的安全漏洞.
接着提出指示起始地址.Iain已在D的GitHub项目中发现了它的一些用途,而它只支持32位窗口OMF目标.维护不麻烦,Walter回忆说,人们经常在32位版本中使用它,并且它是所有x86的C编译器都支持的扩展.Mathias不认为删除它会给带来好处,Walter同意了.
他报告说,GCC内部在编译器的发展方向上有些非常有趣的,如,添加了自动初化所有静态变量为0或位掩码的选项.这对他来说是个好消息,因为他现在必须在GDC中手工memset.如果中端可做这些,那就是个胜利.
马西斯说,现在Funkwerk的编译器状态相当不错,他没有发现严重的编译器问题.
现在有了librebindable,可扩展不变功能.所以现在他们正在,处理以前是"伪右值结构体"的内部数据类型,并把它们变成完全不变结构体,看看效果.
他发现它破坏了关联数组.#22244问题总结了该问题.从而使用不爽的大量的强制转换.
如何允许关联数组修改数组,但同时防止再次修改数组,且禁止对它的可变视图?他在找反馈.
Robert建议不要修复,因为修复它会产生漏洞.且可跟踪变量,Walter同意.
马西斯说,这提出了不变数组和关联数组应如何一起工作的问题.Robert认为它们不应一起工作,并建议最好用自己的哈希映,常也有同样问题.
马西斯说Funkwerk,有内部hashmap类型,可很好解决该问题.他只是说语言可放松来减少痛苦.
Robert提到了头常,但坚持认为不应去那里.Andrei建议为了保证C和C++的兼容性,需要头常.Walter说ImportC不支持头常.他的C经验是人们一般认为C中的常是可传递的.所以在ImportC中,他把头常变成了可传递的常,效果不错.
马西斯说真正需要的是可变头.Walter说头常不错,但头不变不行.他曾多次考虑添加头常,但这会破坏D的类型系统,而且可能会引入一大堆编译器错误.有几个头点头表示同意.
dip10002
丹尼斯,准备了一些为dmd贡献的视频教程.
项目面板
最后,马克斯正专注于完成浮点模拟.
Andrei会带着他的财政部帽子来请行业代表向雇主要些赞助.
接着,他提到了Walter和Dennis为消除DIP1000错误的工作.他很好奇业界人士是否在找更安全的D语言.他还认为,应考虑重命名"DIP1000"来方便外部人士理解.这触发了DIP1000和@live关系讨论,然后是沃尔特的DIP1000PR数,挂起的构建包失败,头常,C和C++兼容性,rust营销成功,等等.
马西斯,关于不用"@live":他认为Rust制造了认为只有活(live)和借用检查才能保证代码安全的错误印象,但是,他相信通过复制,或信任引用计数器或垃集也可保证代码安全.
他说借用检查器可在性能和安全之间平衡.对那些追求新语言性能的人来说很重要.但Funkwerk的所有性能提升,都是通过算法实现的.它们运行在内存为80GB的服务器上,因此不需要微优化安全性.即,他认为从语言,用户和市场角度来看,这是个好主意.
Walter说,使用GC,不需要借用检查器,但是有个借用检查器可保证,不使用GC时也没有泄漏.因此,尽管在D中这些问题应该是罕见的,但可能会发生.他想弥补该漏洞.Rust的想法已100%成功地解决了内存安全,为了竞争,也应该这样做.
Andrei谈到了Rust如何非常有效地把内存安全作为优秀系统软件的最终目标来销售,并引用了微软Azure首席技术官MarkRussinovich的一条推文作为示例,该推文称是时候放弃C和C++而支持Rust了.我们也在@live上工作,为什么不利用他们的市场营销呢?
Bastiaan说,SARC原则上对安全感兴趣,但不会持续很久.由于他们的代码库是从Pascal编译为D,依赖大量不安全的侵改.删除这些侵改并实现@安全还很早.
还讨论了D的可选@live与完整借用检查器,Dennis转述了AdamRuppe和TimonGehr之前在论坛上发表的评论,他们认为不可能拥有100%内存安全及可选的@live.
Walter说Rust也有不安全代码,如果愿意,可用Rust借助不安全代码并禁止借用检查器,来写完整程序.他认为在@live函数中,让借用检查器保证就足够了.
Martin认为在谈论100%的内存安全时应该谨慎,因为编译器问题不断太多.Walter强调,因此测试套件很重要.每个被修复的漏洞都会进入测试套件,就像只会向前移动的轮子.马西斯指出,如果编译器功能增加,可能特例会成倍增加.沃尔特同意这是潜在问题.
接着,他说他已检查了ImportC的bug列表.他从最严重的bug开始,然后工作.仍然有一些PR因为构建包而卡住.他认为ImportC状态很好,很满意,并且相信它给D带来了竞争优势.
导入C漏洞少些后,就会去DIP1000抓漏洞.接着就是@live.
Walter希望社区中人们,在DConf之外展示D.只需要宣传D中如何干这件工作.
Walter谈到了最近的一个尴尬.有人遇见了DMD在分配时随机崩溃的问题.Walter确信他在调用时总是在检查溢出,然后他和Dennis检查了代码库,发现DMD中有很多分配没有检查溢出.他刚刚发布了几个PR来修复该问题,所以现在,当DMD耗尽内存时,它总是会打印错误消息来说明该点,而不是产生其他类型的随机失败.