amd

I'm working on a new module for an existing project that still uses requireJS for module loading. I'm trying to use new technologies for my new module like webpack (which allows me to use es6 loaders using es6 imports). It seems like webpack can't reconcile with requireJS syntax. It will say things like: "Module not found: Error: Can't resolve in ". Problem : Webpack won't bundle files with requireJS/AMD syntax in them. Question : Is there any way to make webpack play nice with requireJS? My final output must be in AMD format in order for the project to properly load it. Thanks. I had the same

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 由 翻译 强力驱动 问题: I have an EC2 instance. It's specs are: g2 . 2xlarge Instance . Intel ( R ) Xeon ( R ) CPU E5 - 2670 0 @ 2.60GHz NVIDIA GRID GPU ( Kepler GK104 ) with Ubuntu 14.04 - 64 bit . I have two questions: 1. After installing the CUDA toolkit on this system, I have the following output when using clinfo : clinfo : /usr/ local / cuda - 8.0 / targets / x86_64 - linux / lib / libOpenCL . so . 1 : no version information available ( required by clinfo ) Platform Version : OpenCL 1.2 CUDA 8.0 . 46 Platform Name : NVIDIA CUDA Platform Vendor :

对于一般环境，我们直接将模块函数运行后端的返回值赋值给一个window下的变量就可以了。 对于AMD环境下，刚才我们说过要用define来定义函数。所以对于这两种情况我们可以这样处理： ;(function (factory){ 2 if ( typeof define === "function" && define.amd ) { 3 4 // AMD. Register as an anonymous module. 5 define(factory); 6 } else { 7 8 // Browser globals 9 // 以我的库为例 返回mTools 10 window.mTools = factory(); 11 } 12 })(function(){ 13 我们的js库 14 return { 15 //模块返回值 16 } 17 18 }); 原文：https://www.cnblogs.com/zyy-bk/p/9217300.html

CommonJS Node.js是 commonJS 规范的主要实践者，它有四个重要的环境变量为模块化的实现提供支持： module、exports、require、global 。实际使用时，用 module.exports 定义当前模块对外输出的接口，用 require 加载模块。 // 定义模块 area.js function area ( radius ) { return Math . PI * radius * radius; } // 在这里写上需要向外暴露的函数、变量 module . exports = { area : area } // 引用自定义的模块时，参数包含路径 var math = require ( ' ./math ' ); math . area ( 2 ); 但是我们并没有直接定义 module、exports、require 这些模块，以及 Node 的 API 文档中提到的 __filename、__dirname 。那么是从何而来呢？其实在编译的过程中，Node 对我们定义的 JS 模块进行了一次基础的包装： ( function ( exports , require , modules , __filename , __dirname )) { ... }) 这样我们便可以访问这些传入的 arguments 以及隔离了彼此的作用域

<! DOCTYPE html > < html lang = "en" > < head > < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < meta http-equiv = "X-UA-Compatible" content = "ie=edge" > < title > test </ title > </ head > < body > < h1 > CMD AMD规范 </ h1 > < pre > < p >< span > 前言: </ span > 伴随着js应用的强大和广泛，对象，函数的封装，IIFE等已经不能够满足业务需求，模块化被提出，即AMD和CMD </ p > < h1 > CMD规范 </ h1 > < p > 就近依赖，推崇的是as lazy as possible CMD的API推崇职责单一，没有全局的require </ p > < p > 前期，只是下载下来 各个依赖包，并不执行各个包， 都下载完成，则执行，进入住逻辑， </ p > < p > 优点 ： 用户点击才会加载 </ p > < h1 > AMD规范 </ h1 > < p > AMD的API默认是一个当多个用

<! DOCTYPE html > < html lang = "en" > < head > < meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < meta http-equiv = "X-UA-Compatible" content = "ie=edge" > < title > test </ title > </ head > < body > < h1 > CMD AMD规范 </ h1 > < pre > < p >< span > 前言: </ span > 伴随着js应用的强大和广泛，对象，函数的封装，IIFE等已经不能够满足业务需求，模块化被提出，即AMD和CMD </ p > < h1 > CMD规范 </ h1 > < p > 就近依赖，推崇的是as lazy as possible CMD的API推崇职责单一，没有全局的require </ p > < p > 前期，只是下载下来 各个依赖包，并不执行各个包， 都下载完成，则执行，进入住逻辑， </ p > < p > 优点 ： 用户点击才会加载 </ p > < h1 > AMD规范 </ h1 > < p > AMD的API默认是一个当多个用

一、CPU 生产CPU的厂家，主要有英特尔和AMD。 酷睿：面向普通消费级用户 至强：面向企业级用户，一般用于组件服务器 凌动：移动设备、高能效小服务器 酷睿CPU等级:i3、i5、i7、i9、酷睿x 2、AMD CPU 锐龙：面向普通消费级用户 CPU等级:r3、r5、r7、r9、线程撕裂者 sysctl machdep . cpu . brand_string machdep . cpu . brand_string : Intel ( R ) Core ( TM ) i7 - 4770HQ CPU @ 2.20GHz 几个重要参数：插槽类型、架构、核心数、频率、热功耗设计 插槽类型决定CPU可以插在哪个主板上。 架构 - 核心代号，越先进，工作效率越高。 架构 - 制作工艺，越小越好，晶体管越小，CPU内可放入的晶体管就越多。14nm的制作工艺要比32nm的先进。 核心数越多，运算速度越快。一般来说，1个核心只有一个线程，如果使用超线程技术，1个核心可以有2个线程。 频率 - 基础频率，也叫主频，是CPU在正常工作时的频率，频率越高越好。 频率 - 睿频频率，是CPU在超负荷执行任务时的频率，频率越高越好。 主板的一线品牌：华硕、技嘉、微星、华擎。 主版的版型：超大主板、大主板、小主板、mini主板，大主板和小主板只是pci接口少一些，性能上就没有孰强孰弱的关系。 m

什么是模块 将一个复杂的程序依据一定的规则(规范)封装成几个块(文件), 并进行组合在一起 块的内部数据与实现是私有的, 只是向外部暴露一些接口(方法)与外部其它模块通信 模块化规范 根据平台划分 ƽ̨ 规范 特性 浏览器 AMD、CMD 存在网络瓶颈，使用异步加载 非浏览器 CommonJS 直接操作 IO，同步加载 根据同步异步划分 特性 规范 同步加载 CommonJS 异步加载 AMD、CMD AMD、CMD两大规范 规范 约束条件 代表作 AMD 依赖前置 requirejs CMD 就近依赖 seajs 模块化的好处 避免命名冲突(减少命名空间污染) 更好的分离, 按需加载 更高复用性 高可维护性

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。 CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。 对于依赖的模块，AMD 是提前执行，CMD 是延迟执行。 不过 RequireJS 从 2.0 开始，也改成可以延迟执行（根据写法不同，处理方式不同）。 CMD 推崇 as lazy as possible. CMD 推崇依赖就近，AMD 推崇依赖前置。 // CMD define(function(require, exports, module) { var a = require('./a') a.doSomething() // 此处略去 100 行 var b = require('./b') // 依赖可以就近书写 b.doSomething() }) // AMD 默认推荐的是 define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好 a.doSomething() // 此处略去 100 行 b.doSomething() ... }) AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一。比如 AMD 里，require 分全局 require 和局部 require，都叫 require。 CMD 里，没有全局 require，而是根据模块系统的完备性

前端模块化 模块化： 是具有特定功能的一个对象（ 广义理解 ） 模块定义的流程： 1.定义模块（对象） 2.导出模块 3.引用模块 好处：可以存储多个独立的功能块，复用性高 种类： AMD（ require.js） CMD ( sea.js ) Common.js CommonJs用在服务器端，AMD和CMD用在浏览器环境 三者的一个详细介绍： https://www.jianshu.com/p/d67bc79976e6 AMD定义一个模块：使用define来定义，用require来使用模块 // AMD /* 目录 admDir a.js index.js */ // AMD定义 a.js define ( { a : 1 , b : 2 , add : function ( ) { } } ) // AMD引用 index.js require ( [ . / a . js ] , function ( moduleA ) { //moduleA指的就是定义来的对象 } ) CMD定义模块：使用define来定义，用require来使用模块 //CMD /* 目录结构 b.js index.js */ // 模块定义 b.js define ( function ( require , exports , module ) { // 模块代码 } ) ; //模块引用