原文
总结
卡斯滕
Carsten说,Decard一直在大量试验WebAssembly.他们一直在把d运行时挖出来,直到它工作.他们在浏览器中运行了一些库函数,并试了不同虚机.
他们在移动方面遇见了很多问题,因为不同芯片按不同方式工作.他们想让他们的整个SDK在WASM上运行,但可能需要一年时间才能完成,因为WASM中有很多东西在到处移动.
Robert问他们是否让GC正常工作.卡斯滕说,他们没有关注它.他们只是在调用函数.他们不知道如何编写GC,因此想最终使用WASMGC.
他说,一直烦人一件事是WASM接口基本上是POSIX,但编译器并没有按POSIX版本对待控制.他必须实现大量版本化的虚代码才能使它正常工作.
他想看到编译器按POSIX识别WASM.
Robert说他看到标准化机构已接受了GC的提案.Carsten说他们也接受了多线程.WASM正在进入虚机等领域,因此它最终会变成来进出浏览器的VM.
Robert说这是一个非常好的接口.
巴斯蒂安
巴斯蒂安说,他仍在为SARC搞D翻译.他时不时地遇见难以解决或难以理解的问题.那是他的生活,但这里无大事可提.
马蒂斯啤酒
Mathis说,Funkwerk有史以来第一次使用编译器的修补版本,因为可重绑定的区间析构错误太可怕了.不过,他说这很常见,因为这主要是他的错.
应该弃用破坏函数.它造成了很大的伤害,但他觉得这不值得辩论.
Dennis问他是否指的是一般的核心析构器.马蒂斯澄清说,他指的是对象版本.他说它有个问题,当它处理一个值类型时,它会处理值,但是当处理一个类时,它实际上会很难注意到的析构类值,不是引用,而是实际的对象自身.
然后,注意虚表指针已变为零,因此你必须知道意思并找出发生的位置.
一般,它几乎从来都不是你想要调用的函数.他觉得这很困惑.
Walter认为析构的目的是,不必等待GC收集对象.你可以说你已完成了它.马蒂斯说不,甚至没有释放它.
Walter问,如果不再用虚表,则设置虚表为零,又有什么关系呢.Mathis说,问题是他在通用环境中使用它,并想为值调用语义上适当的析构操作.
对构,即调用析构器,因为值的生命期结束了.但是当结束类引用的生命期时,因为可能还有其他该类实例引用,不应这样.
但实际是,无论剩余多少引用,都会析构类实例.
沃尔特说这就是破坏的要点.马蒂斯说,它并没有对其他类型这样做.如果他在某个地方有一个结构,并传递了要破坏的一个副本,则不应影响原版本.
Dennis说这是真的,但是如果有该结构的指针,则就会挂起该指针.Mathis说,他实际上并不知道破坏是如何处理指针的.
它认为它啥也没干.
沃尔特说,如果你要破坏某样东西,则就不应再引用它了.即,由你确保不再引用它.Mathis说,此时,他必须负责生命期,他用它来补偿可重绑定中数据对象的生命期管理.
他想他会调用破坏来结束它的生命期.
Walter说,不,当你知道这是目标值的结尾时,你根据指定的类型,调用了破坏.因此,如果你在通用函数中使用它,如果它是一个结构,则它是一个复制的值,所以说你想结束该值的生命期是对的.
但是,如果它是一个类,复制构造器实际上只是复制引用.如果在那时调用破坏,即没有更多引用它了.
马蒂斯说这就是他的要点.在语义上行为是不同.他不是专门在类上调用的.他在一个T任意模板参数上调用它.
Walter说,这样做是说不再有该T实例的引用.但在会议中,他说有更多的引用,它们会变坏,但这不是破坏的重点.
关键是没有更多的引用了.
Mathis说,该行为对类和结构有意义,但对类和结构一起没有意义.这是不同.Walter说,这就是类对象的工作方式.调用破坏是不安全的.
马蒂斯说,基本上,不必重载.应该有一个破坏和一个destroyClass.Walter再次重复说这就是该函数的意义所在:调用它表明你说没有更多的引用.
Martin说,类的问题是,不能确定你正在析构的引用实际上是最终的引用.他建议应该为类设置一个单独的终结器.
即破坏性更改,但可为类对象添加终结器,然后在版本中,可更改破坏的语义.
Walter认为这很好,但表示分开终止器和破坏的问题是,人们会搞混,不理解区别,会用错,然后会不高兴.无法避免.
他说Mathis可以用"这是类"来包装调用破坏.马蒂斯说他一直在这样做.他都不记得不包装它就调用破坏.
Walter说,好,它正在按它设计的方式工作,不应改变该行为.
Lu认为这里的问题之一是类的特例.不仅破坏,而且很多东西都是类的特例,因为它们只是隐藏对象加虚表的指针.
另一件事是类暗示了有GC,但也可在没有GC时分配它们.因为有特例,Weka不使用类.大多数情况都可用结构来解决.
Walter说Lu说得对,类和结构彼此不同.忽视这些差异的算法会导致麻烦.Lu理解它,但认为设计可更类似结构,而不是模板编程中总是需要特例的差异.
Walter说,在C++中,对引用必须有特例.当你有值类型和引用类型时,它们会有所不同.没办法.
马蒂斯同意.他说他真很喜欢D中的类设计.当简单编写时,标准区间算法可很好地处理类和结构.唯一觉得有问题的函数是析构.
他觉得,如果他有一个需要使用静如来调用一个函数的模板函数,则实际上是恰好有相同名字的两个函数.
Walter说很好观点,但如果你使用的是值类型,你应该依赖RAII来析构,而不是实际的破坏函数.而对类没有RAII.
马蒂斯说明,他的例子是个特例.他有这样神奇的可重绑定的东西,他必须手动控制生命期.这是不经常出现的事情.
Walter说,当你按特例手动管理生命期时,它是一个特例,你必须在其中放一个如.
我注意到Java中,因为很容易误用它,而已弃用的Object.finalize.我记得Sun过去总是告诉人们在final中不要这样或那样,因为它不是一个析构器,但人们仍会这样或那样.
在D中遇见了相反的问题,因为析构器也是终结器.
沃尔特说不要把火和水插件在一起.引用类型和值类型彼此间难以理解地不同.
Mathis说,之所以这样,是因为他必须在std.algorithm中添加可重绑定,来支持不变,这一切都可跟踪到他的DConf'22演讲.
然后,他报告说Funkwerk到处都在使用DMD2.108和LDC1.38,并且他们运行良好.他们在内部管理代码,没有主要的外部依赖.
他们很高兴离开vibe.d,不再处理编译器更新中的问题.他们对2.108满意.
路易斯
Lu说他无新东西,但他想了解AST重构项目的状态.Weka仍有因模板和属性推导错误而导致的链接问题.
这主要是因为问AST的方式有点混乱.如果可让他更好,则它就会让其他事情更好.
我说Razvan知道这一切.我知道现在主要是Razvan在做这件事,尽管包括Bastiaan在内的别人也做出了贡献.
Lu最后说,他最近看到语言中出现了一些他等待了很久的好函数,比如串插值和命名参数.他觉得这真的很酷.
更新:SAOC2024的一位参与者,当前正在重构AST这里,
这是个影响很大的项目.如果想了解如何贡献,请读D博客上Razvan的战争号召.
马里奥
Mario没有编程问题要报告,但表示今年有三名Funkwerk员工参加DConf.
Mathis说,Lu提到命名参数,只是提醒他Funkwerk想使用它们,但当前因为在dfmt中不支持它们,不能使用它们.
他们曾经允许一名员工在dfmt上花一些时间,但该员工不再为他们工作,他们现在有问题.他不知道该怎么做.也许可花几天时间来研究一下,他们在所有项目中都使用了dfmt,所以使得对他们来说命名参数是不可能的.
Dennis说他最近开始在自己的代码中使用dfmt,并注意到了一些错误.他打开了一些问题,但似乎没人积极关注它.他说他可能会花时间来弄清楚它工作原理,这样就可解决这些问题.
当格式化程序压缩属性中的内容,命名参数中的冒号混淆,并完全析构参数列表时,这真的很烦人.
马里奥说他没有指派马蒂斯修复dfmt,因为他不确定这是否会浪费时间和金钱.他知道SDC也有sdfmt,他还知道dfmt在按库对待DMD上已做了一些工作,但他不知道进度如何.
他不想让Mathis修复dfmt,因为在被其他东西替换时,这些修复不重要.
Dennis说,Razvan的一名学生曾参与过该项目,按DMD按库替换dfmt的使用libdparse的,但默认没有启用它.
他上次听说只有一个开关可启用它,而且现在还太早.该改变不会影响格式逻辑,但必须看看.
我注意到,过去曾讨论过与编译器一起提供格式化程序.同意它是dfmt,因为它会使用按库DMD,如果用DMD发布它,这是有意义的.
因此,修复格式化逻辑不会浪费时间.
Lu说,Weka还没测试dfmt的更改,因为它们落后了几个编译器版本,但应该能很快完成.他会报告他们发现的问题.
Johan
Johan说Weka可能有一些问题要谈,但他在会议前没有收集它们,所以他下次会带来几个.
他确实有一些消息要告诉.他说,Weka一直对用musllibc链接可执行文件感兴趣.他已修复了实现它期望的最后部分.
他几乎把所有的东西都移动到了d运行时上游.他说,很好的成功故事.现在可创建不依赖libc实现的静态链接可执行文件,这就是目标.
接着,他请求在编译器仓库中包含语言规范,以避免那种并行拉请,即如果必须恢复另一个,你最终必须恢复一个.他确信前面已讨论了,但他想看看.
Robert说,如果规范是单元测试,即实际上是可测试的文档,那就更棒了.那可能会有更多的工作,但真的很酷.即使编译器仓库中有规范,你仍必须记住更新它.
但是,如果是不可编译的规范,且文档是由此生成的,那将是一个更大的胜利.
沃尔特说这很好.
Dennis说明,如果规范中的示例有正确的宏,则当前会运行这些示例.他说Nick一直在努力按可运行的示例转换原来的未经测试的代码.
Robert说这太棒了,并问它是否包括该语言的其他测试用例.有时,当他读规范时,发现有些事情不清楚,他会去测试,来查看最后的实际结果.
如果包括它们,则会大大收紧规范.
Dennis问他是否打算用规范关联DMD测试包,Robert说是.
Walter说,该测试包不适合公众使用.它不是那样设计的.它为了易于调试编译器.
Walter说Robert是对的,但他说明,每次读计算机软件规范(包括语言规范)时,在调用函数ABI如何工作的规范,总是让他感到困惑.
所以会编写一些小的测试用例,编译它们,看看会怎样.
Walter说,一旦他编写了代码,编译了它,并看到了结果,然后他就会回去再次读规范,这样就会理解了.他希望可以在规范和理解规范有更好的方法.
路易斯说,他与沃尔特的经历恰恰相反.如,读D规范,假设ABI按描述工作,然后试验DMD并找到ABI未按规范工作.
如,逆转了参数.在调用约定中,参数应该是一个方式,但在编译器中,它们是另一个方式.
他说对编译器,有两个不同类型的测试.对特定的编译器错误,有各种奇怪的测试.Robert描述的测试只是示例,但这也证实了该规范符合想表达的.
Walter说,如果编译器和规范不匹配,那就是个应该报告的错误.他们确实报告了,就可以一个一个打倒他们.
Lu说他曾试修复调用约定错误,但这是个很难的问题,因为它在DMD后端无处不在.
Walter同意调用约定是复杂性的一个重要源,尤其是在后端,因为它支持多个调用约定.这是一大堆代码.
Lu说,他看到的问题之一是DMD的数学内部函数.它们是基于调用约定实现的,但是因为参数顺序实际上是相反的,现在需要更改所有这些内部函数.
他提交了一些PR来试修复它们,但测试失败了.从Iain对话得知,GDC是最符合ABI的D编译器.
Johan让回到了他的原点:如果编译器和规范放在同一个仓库中,则更容易知道哪种语言规范与你的编译器版本匹配.
至于测试规范,他说有一些公司为C语言制作了测试包.这很难.这与在同一个仓库中放置规范和编译器是完全不同问题.
编写单行规范后的所有测试代码行的工作是巨大的.这很好,但肯定是个巨大的项目.
至于ABI,他觉得这超出了语言规范.对他来说,规范应在更高的位置.实现CABI是因为必须,但除此外,ABI是相当开放的.
那是在较低的层面上.对程序员来说,更有趣的是更高的规范级,这与你的特定编译器版本有关.当它们在不同仓库中时,你必须弄清楚哪些日期与哪个匹配,这很快就会变得非常麻烦.
Walter同意语言规范和ABI规范是两个截然不同东西.他说明,在标准化C语言后,一家公司测试C规范中的每一段代码制作了一个包,然后发布它.
每个C编译器都失败了.所有C编译器都花了数年时间才成功运行从规范中取的测试.这就是整个问题.
Mathis建议,当你在查看语言规范时,发现某些内容对你没有意义,但随后查看测试后发现它的意义,则这就是应该进入规范的测试.
你不必在那一刻把它放进去,但你可为它提交一个问题.沃尔特同意.
Lu举了一例,Weka遇见过它,在同一仓库中放置规范和编译器是有用的.
沃尔特说他对此没有异议.整合它们没问题.
最后,Johan报告说,Weka仍在使用LDC1.30,但他们已接近升级到1.38,即D2.108.他已看到了2.109中的一些变化,他们花了时间来适应,因此分发先升级到2.108,然后再从那里继续.
Lu说,他很高兴能使用一些DIP1000特征.DIP1000的变化是因为析构而使它们一直用旧版本,但现在已修复了.
马蒂亚斯.朗
Mathias想重申工具的重要性,他提前感谢Dennis可愿意查看一下dfmt.Symmetry也使用了格式化程序,尽管他们使用的是sdfmt,因为Amaury维护了它.
但是,使用工具可做更多事情,它会很好地整合他们的项目.按库DMD可以实现很多好东西,而AST重构项目可以允许它.
如果必须在DMD的ARM后端,和不变的AST间做出选择,他会投给不变的AST.
丹尼斯
Dennis最近一直在与COM打交道.它有个带命名参数的特殊调用约定,而D有命名参数,所以他想试组合它们在一起会很好.
但是opDispatch和opCall不支持命名参数,且DIP没有为它提供机器.
他有个想法,可添加按串数组按模板参数压命名参数的,类似opNamedDispatch的东西.这样就可以了.沃尔特觉得这似乎很有趣.
沃尔特
Walter说他一直在向X发布他在AAarch64代码生成器上的每日进度更新.他当前正在处理调用函数返回序列.
花了一些时间后,他慢慢开始理解ARM指令集.它的某些部分仍很怪.对一个本应简单的指令集,它非常复杂.他必须编写一些代码片,并在godbolt上试用它们,看看它们到底做了什么.
他已到了它会管用的地步,但完成细节需要一点时间.他期望的很快就会运行基本的.
Johan问Walter是否有机器可运行它.沃尔特说他只是在用godbolt.他会编写个两行左右的函数,并想看看它发出了哪些指令.
他们是怎么处理pushs和pops?他们是如何调用函数的?Godbolt非常适合这些.
他说他还有一个RaspberryPi.他期望RaspberryPi用户可变成简单AArch64DMD后端的潜在用户组.这就是他分发的目标机器.
编译器当前发出的代码没有处理elf目标文件中的修复,因此不能试运行生成的代码.
可惜,elf生成器代码是个老鼠窝.他一直在重构它以使其更易于处理.重构,与x86修复完全不同,应该更容易修复AArch64.
他已为它编写了个目标文件转储程序和一个反汇编器,因此正在慢慢地组合这些部分.一旦他在RaspberryPi上工作,他就会得到一台带ARM芯片的最新Mac,并让它在那里工作.
Johan说他以为Walter是窗口用户.他了解到现在有些不错的窗口版的ARM笔记本电脑.但有时,如果Walter有一台机器来运行它就好了.
Walter说窗口后端可能是最后一步,主要是因为他发现窗口ABI的文档很差,而且要使它正常工作需要付出更多努力.
他也不喜欢使用微软SDK.它太大太复杂了,很难在里面找到东西.它有太多的目录和文件,他就是不喜欢到处找它.
这也是窗口支持,只是实现ImportC的最后原因.
他说Linux开发工具要好得多.它们更易于理解,且面向命令行,而不是GUI.他发现它们更容易开发代码,也更容易理解正在发生的事情.
因此,他打算把微软问题延迟到最后.
Martin说明,d运行时很可能需要为窗口的AArch64工作.Johan说,事实上,LDC可能无法在窗口ARM笔记本电脑上运行.
如果有一些开发者可从事这项工作,那就太好了.不一定是沃尔特.也许是核心贡献者之一,或是参与游戏并有动力修复最后点点滴滴的人.
Dennis问Walter打算用PR做什么.他打算继续添加并在测试包通过后整合整个事情,还是要合并一个最小的工作版本并在此基础上构建?
沃尔特知道它越来越大,而且看不到尽头.他不断地重定基,这样它就不会无可救药地分歧.它现在是如此之大,坦率地说,不可能审查它.
他问Dennis即使它还不是一个全功能的后端,简单把它主线化是否是合理的?这样更容易管理并避免无法合并它,同时更容易审查未来添加.
Dennis认为,如果有依赖的标志和框架来构建实际的生成代码,那就太好了.Walter说,此时,如果它通过了测试包,他会很高兴合并它.
Dennis问测试包中是否有实际运行生成代码的ARM测试.沃尔特说没有.
Dennis问这是否只是根据期望的汇编测试,Walter说就是.他正在目视检查汇编.表明,-vasm开关对此非常有用.
他使用-vasm编译,查看反汇编的代码,并用godbolt发布的代码比较它.他甚至会取godbolt发出的代码,按测试包的一部分放进反汇编器中.
丹尼斯说他可花点时间看看.他想看看代码,但这不是他一个晚上可以完成的事情.Walter说这正是问题所在,所以他完全支持合并它并从那里继续.