2017年12月

最近玩巫师之昆特牌,近期合了一张“伊森格林:冥想”(貂蝉),使用过程中深感计算不便,于是做了个计算器。
3.png
其中“貂蝉收益”是指该回合下伊森格林:冥想后能打出的总点数;“决斗哥收益”是指该回合下赛尔奇克(北方金卡)后能打出的点数(攻击方战力和攻击方护甲填赛尔奇克的数值)。“决斗哥收益”也可以作为店店12力骑士状态决斗的收益。
可以用手机或者pc端登录昆特牌决斗计算器来进行计算,推荐使用手机端访问,一边运行游戏,一边计算。

它是怎样工作的
WebAssembly的一个基本原则是与现有的JavaScript世界很好地集成。这包括从技术上的事情,如可集成性和共享安全策略(相同来源),到工具集成,例如支持Web浏览器的View Source功能。

为了实现这一目标,WebAssembly为工具和人工阅读器定义了二进制格式和等效文本格式。从技术上讲,文本格式使用S表达式(S-expressions),因此它看起来如下所示。
1.png
然而,这些工具可能会显示出更类似于这种表达式的东西(例如来自文档)。
2.png
您可能想知道为什么使用C++作为示例。这是因为WebAssembly最初发布(MVP)的目的是支持C/C++。其他语言稍后才会出现,目前它们正在发展中。这是出于几个技术和实际原因而选择的:

  1. WebAssembly的MVP不支持垃圾收集(它正在进行中)。
  2. C/C++到WebAssembly编译器的实现可以依赖于一个现成的测试工具,比如LLVM(最常用的编译器工具之一)。
    WebAssembly开发人员使用LLVM来减少获得工作产品所需的工作量。此外,这使得它们能够轻松地与其他与LLVM一起工作的工具集成,比如Emscripten。

有了MVP,真正的程序员就可以进行测试和使用,从而可以相应地改进WebAssembly。

WebAssembly Tools
目前,官方的WebAssembly工具只能编译C / C ++到WebAssembly,尽管其他开发者已经开始着手增加对其他语言和平台的支持(以前我们提到.NET和Rust)。但是,即使使用官方工具,也可以通过两种方式将其用于Web开发:

以文本格式编写WebAssembly并使用提供的工具将其转换为二进制文件
使用基于这些工具的第三方工具
第一种选择对于常见的应用来说并不实用,但是如果您想要了解这种格式的内容,或者开始将它们集成到自己的工具中,那么这种方法就是一种方法。实际上有两个工具包:WebAssembly二进制工具包和Binaryen。

WABT包含开发工具和/或用于与WebAssembly一起工作的工具:

它完全支持格式规范
它可以从文本格式转换
它包括一个解释器
简而言之,它确保了对WebAssembly格式数据的干净而方便的访问,以便您可以使用它。

另一方面,Binaryen是一个在编译器基础结构中使用的工业级工具包:

它可以与WebAssembly代码或用于编译器的控制流图形式一起使用
它优化了许多代码,包括标准优化和针对WebAssembly的特定代码
它可以编译from / to asm.js(JavaScript的子集),Rust MIR(Rust的中间语言)和LLVM
所以,这个工具包已经被集成到你的生产后端。

从本质上讲,两者都允许您创建操作WebAssembly的工具,但是WABT是为在开发(例如静态分析)期间使用的工具而设计的,而Binaryen则用于创建生产WebAssembly(例如编译器)。
这些工具非常适合开发工具和编译器相关产品的人:他们提供开发工具和即用型生产工具。 但是,它们对于普通的开发人员来说并不理想,因为他们有一个更简单的方法。

如果你需要建立这样的工具,还有第二个选择:从零开始构建所有东西。 如果您需要自定义编译器或解释器来使用您自己的语言,则需要使用最佳性能或轻量级工具。 由于我们已经使用了WebAssembly,所以我们已经创建了一个库来帮助您(和我们)使用WebAssembly:WasmCompilerKit。 它基本上是一个Kotlin库,可以用来加载WASM文件,修改它们并生成它们。 鉴于它是用Kotlin编写的,您可以从Java和Scala中使用它。 我们正在考虑在一个针对JavaScript的多平台Kotlin项目中进行转型。

简介
有一个新的武器,让javascript开发人员在提高性能和生产力的同时,选择他们最喜欢的编程风格。这种武器就是WebAssembly,它将彻底改变客户端的Web开发。
WebAssembly,或wasm,是一种用于浏览器客户端脚本的底层的字节码格式。如果您使用过JVM或.NET,就知道JVM或.NET会将您使用的语言(java、c#等)编译到目标字节码。WebAssembly也扮演着同样的角色,所以当您将软件编译到WebAssembly时,您的软件就可以在所有支持它的平台上使用,换句话说,所有浏览器都可以使用。
实际上,WebAssembly是由浏览器开发人员在现有JavaScript引擎的支持下实现的。本质上,它是用来代替JavaScript作为网站上编译器和转发器的目的地。例如,它的开发人员现在可以编译到WebAssembly,而不是将类型记录编译成JavaScript。简而言之,它不是一个新的虚拟机,它是每个浏览器中包含的相同的JavaScriptVM的新格式。这将使得不使用JavaScript就可以利用现有的JavaScript基础设施。
最小可行产品的设计于2017年3月完成,现在已经为每个主要浏览器准备好了实现。

首先,新的WebAssembly格式承诺在解析性能方面取得显著的进步:

为WebAssembly所考虑的二进制格式可以本机解码,比解析JavaScript快得多(实验显示,速度超过20×10)。在移动平台上,大型编译代码只需20-40秒就能解析,因此本机解码(尤其是与其他技术结合起来,比如流传输以获得比gzip更好的压缩)对于提供良好的冷负载用户体验至关重要。
-WebAssembly FAQ

请注意,我们讨论的是解析性能,而不一定是执行性能。因为在许多情况下,它将在现有的JavaScript引擎上运行。然而,仅仅是解析性能的提高就允许在以前开发的Web软件上使用。例如:虚拟机、虚拟现实、图像识别等。

第一批生产用户可能会成为游戏引擎开发人员,因为他们总是在寻找最佳的性能。在WebAssembly之前,他们所希望的最好的是asm.js(一种简化的JavaScript,为速度优化),这是一种很酷的技术,但实际上并不适用于许多游戏。我记得我尝试过著名的演示史诗城堡(现在离线)由虚拟技术。它实际上运行平稳,但是下载和解析代码需要大约15分钟,这显然不适合快速游戏。

事实上,Autodesk计划支持WebAssembly,支持他们的Stingray游戏引擎和团结技术,他们是团结游戏引擎的创建者,早在2015就开始试验WebAssembly。Rust开发人员也已经在努力支持WebAssembly在Web上运行Rust代码。

它能为你做些什么?
在更大的方案中,WebAssembly的出现意味着您将不再被迫在Web上使用JavaScript,因为它是浏览器中唯一运行的东西。JavaScript名声不好,但实际上它是一种很好的语言,用于快速编写小脚本。问题是,目前您被迫使用所有您需要在网上运行的其他东西,这对于许多大型项目来说是一个问题。

确实,您可以使用更好的JavaScript版本,比如类型记录,甚至是新的语言,比如Kotlin。但是,最终它们都必须编译成JavaScript。反过来,这也给JavaScript开发人员带来了问题,这些问题基本上必须支持所有场景和所有编程风格。WebAssembly将改变这种状况,让每个人都专注于他们能做得更好的事情。

这还不是全部:将WebAssembly移植到其他平台是可能的。这意味着,如果您用编译成WebAssembly的语言编写软件,那么您可能能够在.NET上运行它。事实上,它允许重用Web上已有的JavaScript基础设施,这意味着您已经可以在生产中使用它。

然而,这并不是唯一的选择。您可以为您的需要创建自己的特定实现。您可以为您的语言创建一个优化的编译器。您可以从头创建它,也可以将WebAssembly支持添加到现有的编译器中。因此,您可以利用所有其他WebAssembly模块。

例如,您可以为公司内部使用的DSL创建一个WebAssembly编译器,并使其在客户端的Web上运行,而无需使用诸如Oracle Java插件或AdobeFlash之类的自定义插件。

本文翻译自introduction-to-webassembly

问题呈现
在windows环境下,从anaconda上下载的安装包,发现安装不成功。

allusers is False
Traceback (most recent call last):
  File "_nsis.py", line 176, in <module>
    main()
  File "_nsis.py", line 148, in main
    mk_menus(remove=False)
  File "_nsis.py", line 50, in mk_menus
    import menuinst
  File "E:\deve\anaconda\lib\site-packages\menuinst\__init__.py", line 23, in <m
odule>
    from .win32 import Menu, ShortCut
  File "E:\deve\anaconda\lib\site-packages\menuinst\win32.py", line 58, in <modu
le>
    "documents": get_folder_path(FOLDERID.Documents),
  File "E:\deve\anaconda\lib\site-packages\menuinst\knownfolders.py", line 215,
in get_folder_path
    return get_path(folder_id, user)
  File "E:\deve\anaconda\lib\site-packages\menuinst\knownfolders.py", line 206,
in get_path
    path = path.decode(codec)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 3-6: ordin
al not in range(128)

原因分析
检查源代码后发现是因为创建菜单时,有一处路径带有中文“我的文档”引起的。
以下为出错地方的python代码:
1.png
Python在进行编码转换时,会将 unicode 作为中间编码,但 unicode 最大只有128,所以这里当尝试将 ascii 编码字符串转换成中间编码(unicode)时由于超出了其范围,就报出了如上错误。

解决方案
解决方法1:在anacondaLibsite-packagesmenuinstknownfolders.py文件开头添加如下代码

import sys
defaultencoding = 'utf-8'
if sys.getdefaultencoding() != defaultencoding:
  reload(sys)
  sys.setdefaultencoding(defaultencoding)

解决方法2:在anacondaLibsite-packages目录下添加一个sitecustomize.py文件,文件内容如下:

import sys
sys.setdefaultencoding('utf-8')