我正在从了解你一些Erlang中学习Erlang ,我已经[_|_]两次见过这个模式但是找不到任何关于它的信息.这种用法似乎是多余的,因为从(1)中省略它并用_ in(2)中的_舍入它会产生相同的结果,而不会降低可读性.这是我与Erlang的第一周,所以我可能完全错了.
(1)来自bestest_qsort:
bestest_qsort(L=[_|_]) ->
bestest_qsort(L, []).
Run Code Online (Sandbox Code Playgroud)
(2)从这里:
error:{badmatch,[_|_]} -> ok
Run Code Online (Sandbox Code Playgroud) 从mix deps文档中:
:runtime-依赖项是否是运行时应用程序的一部分。如果您的mix.exs文件中:applications没有提供密钥def application,则Mix会自动将所有依赖项作为运行时应用程序包括在内,除非runtime: false给出了。默认为true。
根据mix compile.app文档:
:applications-您的应用程序在运行时依赖的所有应用程序。默认情况下,此列表是根据您的依赖项自动推断出来的。Mix和其他工具使用应用程序列表来启动依赖关系,然后再启动应用程序本身。
这是否意味着添加runtime: false依赖项将使其不能作为应用程序监视树的一部分启动,但其功能将在编译时可用?
当尝试恢复旧项目时,有时我必须四处寻找较旧的 Nixpkgs 承诺才能开始工作。
例如,我的大多数shell.nix文件都是这样开始的,
{pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
# ...
}
Run Code Online (Sandbox Code Playgroud)
这将从当前通道指向的提交中导入所有表达式,但一段时间后,发生了太多更改,我的项目将不再构建;然后我必须找到一个仍然有效的提交,然后从那里开始。
$ nix-shell --arg pkgs \
> 'import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/0c0fe6d85b92c4e992e314bd6f9943413af9a309.tar.gz") {}'
Run Code Online (Sandbox Code Playgroud)
如果我当时能够从通道中保存工作提交,并在以后需要时有一些可靠的东西可以回退,那可能是最好的。
通过“安装包”,我的意思是评估 Nix 构建表达式(使用nix-env、nix-shell -p等)从源代码构建,而不是使用替代品。
还交叉发布到 Unix 和 Linux,因为正如Charles Duffy 指出的那样,如果它是关于命令行工具或配置的,那么它更符合主题。仍然将其留在这里,因为我假设仅使用 Nix 语言就可以强制包始终从源代码进行编译,我只是还不知道如何操作。(或者如果实际上不可能,有人会指出,那么这个问题就属于这里。)
我有关于分布式消息发送和发送操作员的问题."erlang 用户指南"将发送操作符描述为
Expr1 ! Expr2
Run Code Online (Sandbox Code Playgroud)
并解释了Expr1是两个原子的元组的情况,第二个表示节点名称,但我不清楚第一个原子代表远程节点或进程的代码.
非常感谢您的帮助.
我见过的大多数书籍或在线资源都使用记录来保持一个过程的状态(可能因为这是多于(?)十年的方式).另一方面,map有效地用于替换stdlib中的元组(例如,supervisor模块中的childspecs).
作为一个例子,我正在通过Learn You Some Erlang的有限状态机章节工作,state记录可以替换为在init/1需要的回调中声明的映射gen_fsm.
.hrl文件使得跟踪错误变得更加困难.此外,它会更有效吗?
我知道一个经过深思熟虑的基准测试可以回答我的问题,但我只用了几个星期就学习了Erlang,而地图 模块相当新,而且还在变化.
更新:感谢我给出了可怕的建议,我更彻底地阅读了地图上的LYSE章节,答案很明确:
使用记录的优点是密钥在编译时是已知的,这带来了优势
- 快速访问特定值(比动态更快)
- 额外的安全(早期崩溃而不是腐败状态)
- 更容易检查类型
这些记录绝对适合进程的内部状态,尽管偶尔会编写更冗长的code_change函数.
另一方面,Erlang用户将使用记录来表示复杂的嵌套键/值数据结构(奇怪地类似于面向对象语言中的对象),这些数据结构经常跨越模块边界,因此地图将有很大帮助.记录是该工作的错误工具.
在一个新的 Phoenix 应用程序中,Plug.Head插件默认存在,我对它的重要性很感兴趣。
我知道“ HEAD 方法与 GET 相同,只是服务器不得在响应中发送消息正文”。
我认为凤凰城的官方指南是一流的,但这让我在路由指南中感到失望:
Plug.Head - 将 HEAD 请求转换为 GET 请求并剥离响应正文
如果 HEAD 请求没有正文,那么为什么需要这样做?我想也许可以控制格式错误的请求,但查看Plug.Head 实现,它只是将 HEAD 方法切换为 GET。
def call(%Conn{method: "HEAD"} = conn, []), do: %{conn | method: "GET"}
def call(conn, []), do: conn
end
Run Code Online (Sandbox Code Playgroud)
我能在这个主题上找到的最接近的事情是关于 ServerFault 的一个问题,但它与 NGINX 和有缺陷的应用程序逻辑有关,其中 HEAD 请求需要转换为 GET,并且相应的 GET 响应返回到 HEAD。
我正在尝试学习如何在浏览器中记录媒体,我可能会过度复杂化.有大量直接的例子,但是当记录被推送到Blob具有任意选择的媒体类型的对象时,我陷入了困境,而没有检查是否支持该格式.因此,我假设有一个列表或人们只是继续建立过去的经验.
例如,来自Mido22/MediaRecorder-sample:
mediaOptions = {
video: {
tag: 'video',
type: 'video/webm',
ext: '.mp4',
gUM: {video: true, audio: true}
},
audio: {
tag: 'audio',
type: 'audio/ogg',
ext: '.ogg',
gUM: {audio: true}
}
};
media = mv.checked ? mediaOptions.video : mediaOptions.audio;
//...
function makeLink(){
let blob = new Blob(chunks, {type: media.type })
//...
Run Code Online (Sandbox Code Playgroud)
或者来自MDN的使用媒体流录制API:
var blob = new Blob(chunks, { 'type' : 'audio/ogg; codecs=opus' });
Run Code Online (Sandbox Code Playgroud)
在规格和他们的 各种 单证大多是通用的描述为用户代理需要实现他们这是完全可以理解的.
这个问题的第一个答案就是我的想法,但我想知道某处是否有更容易访问和更新的列表?
更新:我几乎觉得好像我只是从岩石下爬出来,因为我一发布这个就意识到了最明显的两种方式......
我认为 NixOS 很棒,但无法弄清楚如何从源代码构建包。理解Nix 表达式语言不是问题,而是知道要default.nix构建一个包要放入什么内容。
以 Nix 表达式为例gedit:
{ stdenv, intltool, fetchurl, enchant, isocodes
, pkgconfig, gtk3, glib
, bash, wrapGAppsHook, itstool, libsoup, libxml2
, gnome3, librsvg, gdk_pixbuf, file, gspell }:
stdenv.mkDerivation rec {
inherit (import ./src.nix fetchurl) name src;
propagatedUserEnvPkgs = [ gnome3.gnome_themes_standard ];
nativeBuildInputs = [ pkgconfig wrapGAppsHook ];
buildInputs = [ gtk3 glib intltool itstool enchant isocodes
gdk_pixbuf gnome3.defaultIconTheme librsvg libsoup
gnome3.libpeas gnome3.gtksourceview libxml2
gnome3.gsettings_desktop_schemas gnome3.dconf file gspell ];
enableParallelBuilding = true; …Run Code Online (Sandbox Code Playgroud) 即使在阅读了 Nix 手册之后,仍然对 Nix 表达式的真正含义感到困惑。有时它们被称为派生,但存储派生也有其他含义。
nix ×4
erlang ×3
nixos ×3
elixir ×1
elixir-mix ×1
endpoint ×1
erlang-otp ×1
http ×1
javascript ×1
mediastream ×1
nixpkgs ×1
plug ×1
web ×1