January 7th Wednesday 2009 (一月 七日 水曜日)

   The dattrcol and dathstdt.cgi program were both modified.  This morning I tested them.  The next step is to
write the test reports.

module (name [, ...])

  Creates a module. If there is a table in package.loaded[name], this table is the module. Otherwise, if there
is a global table t with the given name, this table is the module. Otherwise creates a new table t and sets it
as the value of the global name and the value of package.loaded[name]. This function also initializes t._NAME
with the given name, t._M with the module (t itself), and t._PACKAGE with the package name (the full module name
minus last component; see below). Finally, module sets t as the new environment of the current function and the
new value of package.loaded[name], so that require returns t.

  If name is a compound name (that is, one with components separated by dots), module creates (or reuses, if
they already exist) tables for each component. For instance, if name is a.b.c, then module stores the module
table in field c of field b of global a.

  This function may receive optional options after the module name, where each option is a function to be applied
over the module.

require (modname)

  Loads the given module. The function starts by looking into the package.loaded table to determine whether modname
is already loaded. If it is, then require returns the value stored at package.loaded[modname]. Otherwise, it tries
to find a loader for the module.

  To find a loader, first require queries package.preload[modname]. If it has a value, this value (which should be
a function) is the loader. Otherwise require searches for a Lua loader using the path stored in package.path. If that
also fails, it searches for a C loader using the path stored in package.cpath. If that also fails, it tries an all-in-one
loader.

  When loading a C library, require first uses a dynamic link facility to link the application with the library. Then
it tries to find a C function inside this library to be used as the loader. The name of this C function is the string
"luaopen_" concatenated with a copy of the module name where each dot is replaced by an underscore. Moreover, if the
module name has a hyphen, its prefix up to (and including) the first hyphen is removed. For instance, if the module name
is a.v1-b.c, the function name will be luaopen_b_c.

  If require finds neither a Lua library nor a C library for a module, it calls the all-in-one loader. This loader searches
the C path for a library for the root name of the given module. For instance, when requiring a.b.c, it will search for
a C library for a. If found, it looks into it for an open function for the submodule; in our example, that would be luaopen_a_b_c.
With this facility, a package can pack several C submodules into one single library, with each submodule keeping its original
open function.

  Once a loader is found, require calls the loader with a single argument, modname. If the loader returns any value, require
assigns the returned value to package.loaded[modname]. If the loader returns no value and has not assigned any value to package.loaded[modname],
then require assigns true to this entry. In any case, require returns the final value of package.loaded[modname].

  If there is any error loading or running the module, or if it cannot find any loader for the module, then require signals
an error.

package.cpath

  The path used by require to search for a C loader.

  Lua initializes the C path package.cpath in the same way it initializes the Lua path package.path, using the environment variable
LUA_CPATH (plus another default path defined in luaconf.h).

package.loaded

  A table used by require to control which modules are already loaded. When you require a module modname and package.loaded[modname]
is not false, require simply returns the value stored there.

package.loadlib (libname, funcname)

  Dynamically links the host program with the C library libname. Inside this library, looks for a function funcname and returns this
function as a C function. (So, funcname must follow the protocol (see lua_CFunction)).

  This is a low-level function. It completely bypasses the package and module system. Unlike require, it does not perform any path
searching and does not automatically adds extensions. libname must be the complete file name of the C library, including if necessary
a path and extension. funcname must be the exact name exported by the C library (which may depend on the C compiler and linker used).

  This function is not supported by ANSI C. As such, it is only available on some platforms (Windows, Linux, Mac OS X, Solaris, BSD,
plus other Unix systems that support the dlfcn standard).

package.path

  The path used by require to search for a Lua loader.

  At start-up, Lua initializes this variable with the value of the environment variable LUA_PATH or with a default path defined in
luaconf.h, if the environment variable is not defined. Any ";;" in the value of the environment variable is replaced by the default path.

  A path is a sequence of templates separated by semicolons. For each template, require will change each interrogation mark in the template
by filename, which is modname with each dot replaced by a "directory separator" (such as "/" in Unix); then it will try to load the resulting
file name. So, for instance, if the Lua path is

     "./?.lua;./?.lc;/usr/local/?/init.lua"

the search for a Lua loader for module foo will try to load the files ./foo.lua, ./foo.lc, and /usr/local/foo/init.lua, in that order.

package.preload

  A table to store loaders for specific modules (see require).

package.seeall (module)

  Sets a metatable for module with its __index field referring to the global environment, so that this module inherits values from the global
environment. To be used as an option to function module.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 《Windows Internals》第七版是一本深入剖析Windows操作系统技术的权威指南。书中深入介绍了Windows操作系统的内核架构、进程管理、线程调度、内存管理、硬件驱动、安全机制等关键技术和概念。此外,书中还探讨了Windows NT操作系统的演进过程,以及Windows 7和Windows Server 2008 R2等最新版本的新特性。本书内容通俗易懂,但又不失深入,是软件工程师、系统管理员、网络工程师、安全工程师等技术人员必备的参考书籍。 ### 回答2: Windows Internals 7th是一本涵盖Windows操作系统架构、设计、实现及优化的参考书籍,被认为是了解Windows操作系统内部机制的必读书籍之一。本书分为4部分,依次介绍Windows操作系统背后的基础知识、内核模式、系统进程、设计与实现。 在第一部分,读者将了解Windows操作系统的演变历史、操作系统概述、体系结构以及Windows产品族的各种特点。第二部分是Windows操作系统的核心部分,讲解了支持操作系统运行的内核模块,如安全管理、进程调度、内存管理、文件系统、驱动程序和网络管理等。第三部分涵盖了系统进程的设计以及系统相互作用的机制分析,如统一消息传递、组件对象模型(COM)、Windows管理器、控件和辅助技术等。最后一部分涉及系统设计与实现,探讨了安全、可靠性和可维护性的完备处理,以及性能监测和优化的一些策略和技术。 Windows Internals 7th全面深入地介绍了Windows操作系统的各个方面,无论您是操作系统的开发人员、软件工程师还是系统管理员,都能从中获取自己需要的信息。读者将获取到Windows操作系统的内部工作方式的深刻理解,有助于更好地了解操作系统的性能、运行情况和故障原因,也能使系统管理员们更好地完成对系统的常管理和优化。 ### 回答3: 《Windows Internals》是一本关于操作系统Windows内部结构和运作机制的权威指南,最新的版本是第7版,集合了大量的专业知识和实践经验,可以让读者更加全面深入地了解Windows操作系统。 本书从操作系统内部的基础和进程调度机制开始,又讲解了内存管理、I/O子系统、系统调用、安全模型、内核调试等问题,以及Windows的演变历史和未来方向。本书对操作系统领域的研究者、存储和网络专家、驱动程序和嵌入式设备开发者等都极具参考价值。 此外,本书还提供了大量实用技巧和案例,如如何进行内存分析和调试,如何使用Windows高级调试工具等。它是任何对Windows操作系统有兴趣的技术人员必备的工具书,可以帮助读者更深入地掌握Windows操作系统的内部工作原理,从而在系统开发、优化和调试方面更加得心应手。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值