Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Last of the link fixes (I hope)

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

6
blog/2014/09/30/README.md
View file

@ -27,13 +27,13 @@ just ignore it.
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
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
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
that are never modified or enumerated, so the [prepjs](/modules/grunts/prepjs/) preprocessing script is no longer used,
but I've stuck with the UPPER-CASE convention.
that are never modified or enumerated, so the **prepjs** preprocessing script is no longer used, but I've stuck
with the UPPER-CASE convention.
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

2
docs/pcjs/README.md
View file

@ -133,7 +133,7 @@ All of the demos described above are available for [download](/docs/pcjs/demos/)
### 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
[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

2
modules/pcjs/lib/README.md
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.
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.
These components should always be loaded or compiled in the order listed by the *pcJSFiles* property in

4
modules/shared/lib/README.md
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
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: 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:
/* global window: true */