Last of the link fixes (I hope)

This commit is contained in:
Jeff Parsons 2015-07-19 09:07:50 -07:00
commit 0962232a9a
4 changed files with 7 additions and 7 deletions

View file

@ -27,13 +27,13 @@ just ignore it.
Property names with all UPPER-CASE letters (with optional numbers and/or underscores) represent constants. Property names with all UPPER-CASE letters (with optional numbers and/or underscores) represent constants.
I originally adopted this rule in part because it's a popular C language convention, but also because it I originally adopted this rule in part because it's a popular C language convention, but also because it
made it easy to write a preprocessing script (see the PCjs Grunt task [prepjs](/modules/grunts/prepjs/)) made it easy to write a preprocessing script (see the PCjs Grunt task **prepjs** in /modules/grunts/prepjs/)
that replaced all such property references with the corresponding property values and then removed the original that replaced all such property references with the corresponding property values and then removed the original
property definitions. Of course, this convention also depended on the properties never being modified *or* enumerated. property definitions. Of course, this convention also depended on the properties never being modified *or* enumerated.
I later discovered that Google's Closure Compiler does an excellent job of automatically inlining properties I later discovered that Google's Closure Compiler does an excellent job of automatically inlining properties
that are never modified or enumerated, so the [prepjs](/modules/grunts/prepjs/) preprocessing script is no longer used, that are never modified or enumerated, so the **prepjs** preprocessing script is no longer used, but I've stuck
but I've stuck with the UPPER-CASE convention. with the UPPER-CASE convention.
I don't bother with JSDoc *@const* annotations, because 1) the project contains far too many constants, 2) I don't bother with JSDoc *@const* annotations, because 1) the project contains far too many constants, 2)
all the constants are already effectively annotated by virtue of being UPPER-CASE, and 3) there is no noticeable all the constants are already effectively annotated by virtue of being UPPER-CASE, and 3) there is no noticeable

View file

@ -133,7 +133,7 @@ All of the demos described above are available for [download](/docs/pcjs/demos/)
### Creating PCjs-Compatible Disk Images ### Creating PCjs-Compatible Disk Images
If you have (or find) an IMG disk image file on a server, [pcjs.org](http://www.pcjs.org/) provides a If you have (or find) an IMG disk image file on a server, [pcjs.org](http://www.pcjs.org/) provides a
[DiskDump API](/api/v1/dump) that creates PCjs-compatible disks in JSON: **DiskDump API** via endpoint "/api/v1/dump" that creates PCjs-compatible disks in JSON:
http://www.pcjs.org/api/v1/dump?disk=(file|url)&format=json http://www.pcjs.org/api/v1/dump?disk=(file|url)&format=json

View file

@ -13,7 +13,7 @@ component, the Color and Rectangle classes of the **Panel** component, etc) do n
so don't assume that every PCjs object has access to [component.js](../../shared/lib/component.js) methods. so don't assume that every PCjs object has access to [component.js](../../shared/lib/component.js) methods.
Examples of non-device components include UI components like [panel.js](panel.js) and [debugger.js](debugger.js), Examples of non-device components include UI components like [panel.js](panel.js) and [debugger.js](debugger.js),
and sub-components like [x86opxx.js](x86opxx.js) and [x86func.js](x86func.js) that separate the CPU and sub-components like [x86ops.js](x86ops.js) and [x86func.js](x86func.js) that separate the CPU
functionality of [x86.js](x86.js) into more manageable pieces. functionality of [x86.js](x86.js) into more manageable pieces.
These components should always be loaded or compiled in the order listed by the *pcJSFiles* property in These components should always be loaded or compiled in the order listed by the *pcJSFiles* property in

View file

@ -8,12 +8,12 @@ At the moment, only a few files are completely agnostic; eg: [strlib.js](strlib.
One give-away is that neither contain references to any globals (although references to each other One give-away is that neither contain references to any globals (although references to each other
would be fine). would be fine).
[netlib.js](netlib.js) is appropriate only for Node modules, because it contains code that relies on Node's **netlib.js** is appropriate only for Node modules, because it contains code that relies on Node's
global *Buffer* object, as indicated by: global *Buffer* object, as indicated by:
/* global Buffer: false */ /* global Buffer: false */
And [weblib.js](weblib.js) is appropriate only for client modules, because it contains code that relies on the [weblib.js](weblib.js) is appropriate only for client modules, because it contains code that relies on the
browser's global *window* object, as indicated by: browser's global *window* object, as indicated by:
/* global window: true */ /* global window: true */