Add utf8 support #473
Add utf8 support #473
Conversation
|
@OpportunityLiu vs2008/xp 下测试 fgetws完全失效，实际上还是用的 fgets，里面read的数据 还是 mbs 的，得用 ReadConsoleW |
|
file_read里也用了 |
|
所以之前你说的dump出问题其实是这里出问题？ |
是的 |
|
file_read里面还有 file->std_xxx 这块，应该整个都换成 win std handle以及 ReadConsoleW/WriteConsoleW才行，还有一些 fwxx系列接口，在这里都是失效的。。我先临时处理了下 fwscanf。。不过还有点问题。。 |
|
得照着write那样写，readfile也要用起来 |
|
等会 昨天只是临时处理下，这块外面整有点乱 我得在tbox封下接口 支持下std file的各种读写，并改进下tb_file接口，尝试支持下std fgets fgetwc 我也会一并封下在tbox里，外面统一调用 |
|
那可非常脏了，你还要自己维护一个4B的缓冲区，把读到的数据转成u8等着给fgets |
|
io.write 对file/stdout在Win下，"\n" => "\r\n"也做了处理 |
|
真要考虑性能为啥不把内置的脚本全编译成bytecode呢 |
之前考虑过，主要因素还是懒。。而且有时候用户保障，不预编译，还能让用户自己改改lua脚本，做点小调试 方便查问题。。 如果是首次加载或者lua变动走编译，后期加载走bytecode，类似python这种也不错。。不过关键还是 没时间折腾。。 刚的改动先慢点测，io.write改的还有些问题 |
这玩意不是应该在tbox里面？ |
是啊，所以stdfile write就是在tbox里面处理的啊，read file对crlf的处理不是现在放在xmake里面处理么，writw file当然也要对应放在一起处理啊 除非之后tbox进一步对stdfile file封装fread fwrite，那么可以统一放置在tbox里面处理了，不过这个我暂时懒得弄了 目前这样也基本可用了，回头时间富裕 我再封装下 |
xmake/core/_xmake_main.lua
Outdated
| @@ -49,7 +49,7 @@ function loadfile(filepath) | |||
| end | |||
|
|
|||
| -- load script data from file | |||
| local data, rerrors = io.readfile(filepath) | |||
| local data, rerrors = io.readfile(filepath, {encoding = "binary"}) | |||
There was a problem hiding this comment.
应该只有 _PROGRAM_DIR 底下的脚本用binary，其他去探测，这样影响的脚本不多，还能支持用户使用其他的编码
|
之前测试read慢，应该跟我这边环境有关，我测试所在的工程 整个都是vbox里面通net挂载上去的。 其实c盘安装目录下，programdirs的脚本加载都非常快，只是当前net挂载的共享目录下的一些xmake.lua加载慢给影响了测试（瓶颈在io读写上，而原生的io.read在这块上可能的处理的比较好，所以稍快些）。。 而我吧整个测试工程全部移到本地C盘去测试，其实我们现在utf8分支的版本，在io.read以及整体xmake的加载上，还比之前的老版本快了30% = = 所以性能那块应该问题不太大了，更何况现在多programdirs的脚本做了binary加载优化。。 |
|
那就是跟 |
是的，瓶颈还是在net挂载的共享盘的io上。。crlf的处理效率 影响不大。。 |
|
我这边测试没啥问题了，你看看这边还有问题么。。一切都ok的话，我就merge到dev了。。 sourceforge经常抽风，ci上的一些urls我都放置到xmake-mirror上去了。。 |
|
这两天出差没法测，你要觉得没问题就合吧 |
|
我先merge了，回头你有时间 也可以测下 |
#467
#468
#478