text:
# The Boost web site provides free peer-reviewed portable
# C++ source libraries. The emphasis is on libraries which
# work well with the C++ Standard Library. The libraries are
# intended to be widely useful, and are in regular use by
# thousands of programmers across a broad spectrum of applications.
DESCRIPTION = "Free peer-reviewed portable C++ source libraries"
HOMEPAGE = "http://www.boost.org/"
MAINTAINER = "John Bowler <jbowler@acm.org>"
SECTION = "libs"
DEPENDS = "boost-jam-native zlib"
PRIORITY = "optional"
LICENSE = "Boost Software License"
PR = "r1"

# need debian package naming for the libs
inherit debian

BOOST_VER = "${@"_".join(bb.data.getVar("PV",d,1).split("."))}"
BOOST_MAJ = "${@"_".join(bb.data.getVar("PV",d,1).split(".")[0:2])}"
BOOST_P = "boost_${BOOST_VER}"
SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
#SRC_URI += "file://unit_test_log10f.patch;patch=1"
SRC_URI += "file://linux-uclibc.patch;patch=1"

S = "${WORKDIR}/${BOOST_P}"

# Make a package for each library, plus -dev and -python
PACKAGES =

PACKAGES += "boost-date-time"
FILES_boost-date-time = "${libdir}/libboost_date_time.so.${PV}"

PACKAGES += "boost-filesystem"
FILES_boost-filesystem = "${libdir}/libboost_filesystem.so.${PV}"

PACKAGES += "boost-prg-exec-monitor"
FILES_boost-prg-exec-monitor = "${libdir}/libboost_prg_exec_monitor.so.${PV}"

PACKAGES += "boost-program-options"
FILES_boost-program-options = "${libdir}/libboost_program_options.so.${PV}"

PACKAGES += "boost-regex"
FILES_boost-regex = "${libdir}/libboost_regex.so.${PV}"

PACKAGES += "boost-signals"
FILES_boost-signals = "${libdir}/libboost_signals.so.${PV}"

PACKAGES += "boost-test-exec-monitor"
FILES_boost-test-exec-monitor = "${libdir}/libboost_test_exec_monitor.so.${PV}"

PACKAGES += "boost-thread-mt"
FILES_boost-thread-mt = "${libdir}/libboost_thread-mt.so.${PV}"

PACKAGES += "boost-unit-test-framework"
FILES_boost-unit-test-framework = "${libdir}/libboost_unit_test_framework.so.${PV}"

PACKAGES += "boost-iostreams"
FILES_boost-iostreams = "${libdir}/libboost_iostreams.so.${PV}"

PACKAGES += "boost-serialization"
FILES_boost-serialization = "${libdir}/libboost_serialization.so.${PV}"

PACKAGES += "boost-wserialization"
FILES_boost-wserialization = "${libdir}/libboost_wserialization.so.${PV}"

# Python - remove this and set:
#PYTHON_ROOT = "/dev/null"
# to remove the python build
DEPENDS += "python"
PYTHON_ROOT = "${STAGING_DIR}/${HOST_SYS}"
PYTHON_VERSION = "2.4"

PACKAGES += "boost-python"
FILES_boost-python = "${libdir}/libboost_python.so.${PV}"

# -dev last to pick up the remaining stuff
PACKAGES += "${PN}-dev"
FILES_${PN}-dev = "${includedir} ${libdir}/libboost_*.so ${libdir}/libboost_*.a"

# Oh yippee, a new build system, it's sooo cooool I could eat my own
# foot.  inlining=on lets the compiler choose, I think.  At least this
# stuff is documented...
# NOTE: if you leave <debug-symbols>on then in a debug build the build sys
# objcopy will be invoked, and that won't work.  Building debug apparently
# requires hacking gcc-tools.jam
#
# Sometimes I wake up screaming.  Famous figures are gathered in the nightmare,
# Steve Bourne, Larry Wall, the whole of the ANSI C committee.  They're just
# standing there, waiting, but the truely terrifying thing is what they carry
# in their hands.  At first sight each seems to bear the same thing, but it is
# not so for the forms in their grasp are ever so slightly different one from
# the other.  Each is twisted in some grotesque way from the other to make each
# an unspeakable perversion impossible to perceive without the onset of madness.
# True insanity awaits anyone who perceives all of these horrors together.
#
# Quotation marks, there might be an easier way to do this, but I can't find
# it.  The problem is that the user.hpp configuration file must receive a
# pre-processor macro defined as the appropriate string - complete with "'s
# around it.  (<> is a possibility here but the danger to that is that the
# failure case interprets the < and > as shell redirections, creating
# random files in the source tree.)
#
#bjam: '-DBOOST_PLATFORM_CONFIG=\"config\"'
#do_compile: '-sGCC=... '"'-DBOOST_PLATFORM_CONFIG=\"config\"'"
SQD = '"'
EQD = '\"'
#boost.bb:   "...  '-sGCC=... '${SQD}'-DBOOST_PLATFORM_CONFIG=${EQD}config${EQD}'${SQD} ..."
BJAM_CONF = "${SQD}'-DBOOST_PLATFORM_CONFIG=${EQD}boost/config/platform/${TARGET_OS}.hpp${EQD}'${SQD}"

# bzip2 and zip are disabled because... they're broken - the compilation simply
# isn't working with bjam.  I guess they will fix it, but who needs it?  This
# only affects the (new in 33) iostream library.
BJAM_TOOLS   = "-sTOOLS=gcc \
		'-sGCC=${CC} '${BJAM_CONF} \
		'-sGXX=${CXX} '${BJAM_CONF} \
		'-sGCC_INCLUDE_DIRECTORY=${STAGING_INCDIR}' \
		'-sGCC_STDLIB_DIRECTORY=${STAGING_LIBDIR}' \
		'-sNO_BZIP2=1' \
		'-sNO_ZLIB=1' \
		'-sBUILD=release <optimization>space <inlining>on <debug-symbols>off' \
		'-sPYTHON_VERSION=${PYTHON_VERSION}' \
		'--layout=system' \
		"

BJAM_OPTS    = '${BJAM_TOOLS} \
		--builddir=${S}/${TARGET_SYS} \
		--with-python-root=${PYTHON_ROOT} \
		${BJAM_EXTRA}'

do_configure_prepend() {
	cp -f boost/config/platform/linux.hpp boost/config/platform/linux-gnueabi.hpp
}

do_compile() {
	set -ex
	bjam ${BJAM_OPTS} --prefix=${prefix} \
		--exec-prefix=${exec_prefix} \
		--libdir=${libdir} \
		--includedir=${includedir}
}

do_stage() {
	set -ex
	bjam ${BJAM_OPTS} \
		--libdir=${STAGING_LIBDIR} \
		--includedir=${STAGING_INCDIR} \
		install
}

do_install() {
	set -ex
	bjam ${BJAM_OPTS} \
		--libdir=${D}${libdir} \
		--includedir=${D}${includedir} \
		install
}


text:
%%% -*-BibTeX-*-
@inproceedings{Kong2021ICRA,
   author    = {Lingtong Kong  and  Chunhua Shen  and  Jie Yang},
   title     = {{FastFlowNet}:  A Lightweight Network for Fast Optical Flow Estimation},
   booktitle = {International Conference on  Robotics and Automation (ICRA'21)},
   year      = {2021},
   volume    = {},
   month     = {},
   pdf       = {},
   url       = {},
   eprint    = {2103.04524},
   project   = {https://git.io/fastflow},
   venue     = {ICRA},
}

license_type: permissive

branch_name: refs/heads/master

extension: bib


text:
"use strict";

import { gl } from "./gl.js";
import { ShaderProgram } from "./shaderProgram.js";
import { Texture } from "./texture.js";
import { Buffer, buffer_vert } from "./buffer.js";
import { VAO } from "./vao.js";
import { Sprite } from "./spriteInstanced.js";
import { view } from "./view.js";
class SpriteBatch {
  constructor(count, img) {
    this.show = true;
    this.buffer = buffer_vert;
    this.buffer_inst = new Buffer(
      new Int16Array(count * Sprite.ELEMENTS_PER_SPRITE),
      Sprite.ELEMENTS_PER_SPRITE,
      0
    );
    this.sprites = [];
    this.tex = new Texture(img, null, null, img.src);
    this.prog = new ShaderProgram(vert, frag, "sprite");
    this.vao = new VAO("sprite");
    const a = this.prog.attribs;
    this.vao.setAttributes(this.buffer, [a.aVert], false);
    this.vao.setAttributes(
      this.buffer_inst,
      [a.aPos, a.aSize, a.aDir, a.aTex, a.aAnim],
      true
    );
    gl.bindVertexArray(null);
  }

  addSprite() {
    const spr = new Sprite(
      this.sprites.length * Sprite.ELEMENTS_PER_SPRITE,
      this.buffer_inst.data
    );
    this.sprites.push(spr);
    return spr;
  }

  removeSprite(idx, x, y) {
    let spr = this.sprites[idx];
    if (!idx) {
      spr = this.getSprite(x, y);
      idx = spr.i / Sprite.ELEMENTS_PER_SPRITE;
    }
    const last = this.sprites[this.sprites.length - 1];
    spr.overwriteWith(last);
    this.sprites[idx] = last;
    this.sprites.length = this.sprites.length - 1;
  }

  getSprite(x, y) {
    for (var i = 0; i < this.sprites.length; i++) {
      const spr = this.sprites[i];
      if (
        spr.x <= x &&
        x <= spr.x + spr.w &&
        spr.y <= y &&
        y <= spr.y + spr.h
      ) {
        return spr;
      }
    }
    return null;
  }

  getSprites(x, y, w, h) {
    const results = [];
    for (var i = 0; i < this.sprites.length; i++) {
      const spr = this.sprites[i];
      if (
        spr.x <= x + w &&
        x <= spr.x + spr.w &&
        spr.y <= y + h &&
        y <= spr.y + spr.h
      ) {
        results.push(spr);
      }
    }
    return results;
  }

  draw(progress) {

    gl.bindVertexArray(this.vao.id);
    gl.useProgram(this.prog.id);
    gl.uniform1i(this.prog.uniforms.uTex.id, this.tex.number);
    gl.uniform2fv(this.prog.uniforms.uTexSizeInv.id, this.tex.sizeInv);
    gl.uniform1f(this.prog.uniforms.uProgress.id, progress);
    gl.uniform2f(this.prog.uniforms.uView.id, view.x, view.y);
    gl.uniform2f(
      this.prog.uniforms.uResInv.id,
      2 / gl.drawingBufferWidth,
      2 / gl.drawingBufferHeight
    );
    gl.drawArraysInstanced(gl.TRIANGLES, 0, 6, this.sprites.length);
    gl.bindVertexArray(null);
  }
}

const vert = `#version 300 es
  in vec4 aVert;
  in vec2 aPos;
  in vec2 aSize;
  in vec2 aDir;
  in vec2 aTex;
  in vec2 aAnim;
  out vec2 vTexCoord;
  uniform vec2 uTexSizeInv;
  uniform vec2 uResInv;
  uniform vec2 uView;
  uniform float uProgress;
void main() {

  float step = floor(aAnim.x * aAnim.y * uProgress);

  vec2 v = aVert.xy;
  if (aAnim.x < 0.0) v.x *= -1.0;
// resize and move to position
  v = v * 0.5 * aSize.xy + aPos.xy - uView;
// move into direction by progress
  v = v + aDir * step / (aAnim.x * aAnim.y);
//flip y
  v.y *= -1.0;
  // convert to clipspace realign to topleft corner
  gl_Position = vec4(v * uResInv + vec2(-1.0,1.0), 0.0, 1.0);
  //set texture
  v = aAnim;
  if (step < 0.0) step *= -1.0;
  //if (v.x < 0.0) v.x *= -1.0;
  v = (aVert.zw + aTex + vec2(mod(step, 8.0), 0.0)) * aSize.xy;
  //select animation frame
  vTexCoord = v * uTexSizeInv;

}`;

const frag = `#version 300 es
  precision mediump float;
  in vec2 vTexCoord;
  out vec4 outColor;
  uniform sampler2D uTex;
void main() {
    outColor = texture(uTex, vTexCoord);
    if(outColor.a < 0.1) discard;
}
`;

export { SpriteBatch };

license: MIT

extension: js


text:
@inproceedings{10.1145/97426.97944,
author = {Dameron, Deborah},
title = {The Editorial Role in Developing an Online User Interface},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97944},
doi = {10.1145/97426.97944},
abstract = {As the quality of online systems escalates as a marketing issue, the Editor becomes proportionately more important to the development of a usable and consistent user interface. Editors are vital to the development of a quality user interface for any online system, be it a software product, its accompanying help, or more extensive online documentation. Editors negotiate for quality, lending an experienced eye for detail to each stage of product development, working as part of the Development Team to build a consistent product that meets user needs.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {1–16},
numpages = {16},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97944,
author = {Dameron, Deborah},
title = {The Editorial Role in Developing an Online User Interface},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97944},
doi = {10.1145/97435.97944},
abstract = {As the quality of online systems escalates as a marketing issue, the Editor becomes proportionately more important to the development of a usable and consistent user interface. Editors are vital to the development of a quality user interface for any online system, be it a software product, its accompanying help, or more extensive online documentation. Editors negotiate for quality, lending an experienced eye for detail to each stage of product development, working as part of the Development Team to build a consistent product that meets user needs.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {1–16},
numpages = {16}
}

@inproceedings{10.1145/97426.97986,
author = {McDuffee, Julie S.},
title = {HELPing Writer and Product Team Communication through Online Document Design},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97986},
doi = {10.1145/97426.97986},
abstract = {As technology advances, software companies must reevaluate and adapt their policies toward product development. The specific product addressed in this paper is an Asset/Liability Management System (ALMS) for the financial industry. The project involves three programmers, who will design and code the ALMS application and one writer, who will design and code an online help system. The end users sees one product, a diskette, that contains both the application and the documentation.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {17–21},
numpages = {5},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97986,
author = {McDuffee, Julie S.},
title = {HELPing Writer and Product Team Communication through Online Document Design},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97986},
doi = {10.1145/97435.97986},
abstract = {As technology advances, software companies must reevaluate and adapt their policies toward product development. The specific product addressed in this paper is an Asset/Liability Management System (ALMS) for the financial industry. The project involves three programmers, who will design and code the ALMS application and one writer, who will design and code an online help system. The end users sees one product, a diskette, that contains both the application and the documentation.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {17–21},
numpages = {5}
}

@inproceedings{10.1145/97426.97987,
author = {Braz, Lisa M.},
title = {Visual Syntax Diagrams for Programming Language Statements},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97987},
doi = {10.1145/97426.97987},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {23–27},
numpages = {5},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97987,
author = {Braz, Lisa M.},
title = {Visual Syntax Diagrams for Programming Language Statements},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97987},
doi = {10.1145/97435.97987},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {23–27},
numpages = {5}
}

@inproceedings{10.1145/97426.97988,
author = {Sullivan, Patricia A. and Porter, James E.},
title = {How Do Writers View Usability Information? A Case Study of a Developing Documentation Writer},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97988},
doi = {10.1145/97426.97988},
abstract = {As Dieli (1989) notes, writers sometimes have trouble focusing their concerns into questions that usability groups can test. As teachers of future documentation writers, we have observed that writers also have trouble turning the results of those usability tests into strategies for document revision. Our first investigation into these issues—see Sullivan & Porter (1990)—described a class of fifteen professional writing students employing usability information to write computer documentation. That study indicated that the writer's use of information is guided by that writer's rhetorical orientation, particularly his/her view of the audience/user. Though all the writers in the study conducted the same type of usability test (modeled after Atlas' “user edit”—see Atlas, 1981), they interpreted their test results in different ways.This investigation continues the Sullivan & Porter (1990) study using a longitudinal case study of one professional writer, called “Max.” This follow-up study aims to probe how the writer's rhetorical orientation guides that writer's interpretation of usability test results.We take a slightly uncommon view of usability. We have opted to focus on the writer's view of users' actions—both what is noticed and how it is interpreted. Typically, usability studies have examined the interaction between texts/systems and readers/users (see McDonald & Schvaneveldt, 1988; Ramey, 1988; Rubens & Rubens, 1988), subordinating the important variable of how the writer interprets and uses results. Although both Sullivan (March, 1985) and Schriver (1987) suggest that writers can be trained to successfully use user information in revising documents they do not author, usability studies still have not examined how writers view the findings from usability studies run on their own work.Our study examines how, and to what degree, one writer's rhetorical orientation filters results from usability tests.
what is his rhetorical orientation?what value does he place on, and how does he classify and apply, usability test information?},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {29–35},
numpages = {7},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97988,
author = {Sullivan, Patricia A. and Porter, James E.},
title = {How Do Writers View Usability Information? A Case Study of a Developing Documentation Writer},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97988},
doi = {10.1145/97435.97988},
abstract = {As Dieli (1989) notes, writers sometimes have trouble focusing their concerns into questions that usability groups can test. As teachers of future documentation writers, we have observed that writers also have trouble turning the results of those usability tests into strategies for document revision. Our first investigation into these issues—see Sullivan & Porter (1990)—described a class of fifteen professional writing students employing usability information to write computer documentation. That study indicated that the writer's use of information is guided by that writer's rhetorical orientation, particularly his/her view of the audience/user. Though all the writers in the study conducted the same type of usability test (modeled after Atlas' “user edit”—see Atlas, 1981), they interpreted their test results in different ways.This investigation continues the Sullivan & Porter (1990) study using a longitudinal case study of one professional writer, called “Max.” This follow-up study aims to probe how the writer's rhetorical orientation guides that writer's interpretation of usability test results.We take a slightly uncommon view of usability. We have opted to focus on the writer's view of users' actions—both what is noticed and how it is interpreted. Typically, usability studies have examined the interaction between texts/systems and readers/users (see McDonald & Schvaneveldt, 1988; Ramey, 1988; Rubens & Rubens, 1988), subordinating the important variable of how the writer interprets and uses results. Although both Sullivan (March, 1985) and Schriver (1987) suggest that writers can be trained to successfully use user information in revising documents they do not author, usability studies still have not examined how writers view the findings from usability studies run on their own work.Our study examines how, and to what degree, one writer's rhetorical orientation filters results from usability tests.
what is his rhetorical orientation?what value does he place on, and how does he classify and apply, usability test information?},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {29–35},
numpages = {7}
}

@inproceedings{10.1145/97426.97989,
author = {Northrop, Mary Jane},
title = {The Role of Indexing in Technical Communication},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97989},
doi = {10.1145/97426.97989},
abstract = {The success of a technical document depends heavily on the index. The task of indexing a technical document often cannot begin until insufficient time remains to do a good job. However, for many users of the document, a good index is mandatory to its usability.A good index is especially crucial for technical documents because readers tend to look up specific topics instead of reading the document from cover to cover. A poor index often frustrates readers and taints their view of the entire document.To create a good index, you have to know what makes a good index, understand the indexing tools available, and follow the steps to producing a good index. Additionally, you must make many process decisions that affect the quality of the final index you produce. The skills and processes for creating a good index are similar to those required for most technical communication projects: methodical approach, knowledge of the users' needs, collaboration with colleagues, and testing.This paper discusses how to create a good index and how to make decisions about using personal computer word-processing tools to create an index. It also discusses the feasibility of creating maintainable indexes using these tools.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {37–40},
numpages = {4},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97989,
author = {Northrop, Mary Jane},
title = {The Role of Indexing in Technical Communication},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97989},
doi = {10.1145/97435.97989},
abstract = {The success of a technical document depends heavily on the index. The task of indexing a technical document often cannot begin until insufficient time remains to do a good job. However, for many users of the document, a good index is mandatory to its usability.A good index is especially crucial for technical documents because readers tend to look up specific topics instead of reading the document from cover to cover. A poor index often frustrates readers and taints their view of the entire document.To create a good index, you have to know what makes a good index, understand the indexing tools available, and follow the steps to producing a good index. Additionally, you must make many process decisions that affect the quality of the final index you produce. The skills and processes for creating a good index are similar to those required for most technical communication projects: methodical approach, knowledge of the users' needs, collaboration with colleagues, and testing.This paper discusses how to create a good index and how to make decisions about using personal computer word-processing tools to create an index. It also discusses the feasibility of creating maintainable indexes using these tools.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {37–40},
numpages = {4}
}

@inproceedings{10.1145/97426.97991,
author = {Simpson, Mark},
title = {How Usability Testing Can Aid the Development of Online Documentation},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97991},
doi = {10.1145/97426.97991},
abstract = {Over the past five years, usability testing has become a more accepted part of the software development process as writers, managers, and programmers recognize the need for evaluating their products from the user's point of view. As the application of usability testing has grown, so has the interest in procedures and methods. One indication of that is the number of presentations on usability testing at conferences and the increased number of publications on usability testing. Last year, for instance, an entire issue of the IEEE Transactions on Technical Communications devoted to usability testing. As Ramey (1989a) explains in that issue, “the question of whether to has yielded to the question of how to” (p. 207).The interest in procedures and methods has also brought about a concern for applying usability testing not just to validate computer products but also to provide feedback to product developers (Sullivan, 1987). In fact, theorists and practitioners of usability testing argue that iterative testing (that is, testing a product frequently during its development cycle) is the most productive application of usability testing (Dieli, 1989a). By testing iteratively, usability testing can have the greatest effect on the development of the product. One problem, of course, is finding methods that can be used to test products at each stage of the development process. For example, how can writers usability test an online help system before a working prototype has been created? And how do they test semi-functional prototypes?The problem is especially acute for developers of online documentation. In general, the development process of online documentation contains more variables than print documentation, which means that more things can go wrong. For instance, online must be integrated with a product, yet it may be developed separately and “put together” near the end of the development cycle. In addition, development can be slower, because online depends on several technologies (the text, the help engine, perhaps multimedia), whereas print documentation generally depends on one. The testing “toolbox” therefore needs to be especially responsive to a product's developmental stages.In this article I describe how testing methodologies can be used to test online help systems iteratively. Specifically, I discuss a framework for visualizing usability testing of online documentation through the development cycle. But first, two limitations on the scope of the article. The discussion is intended for writers and online developers who are new to usability testing and for students and teachers in documentation writing courses, although experienced researchers may find it helpful as a planning aid. Second, the article focuses on exploratory or “feedback” kinds of tests, rather than tests that confirm or validate products.Before going any further, let me define what I mean by “online documentation.” Horton (1990), in his textbook on designing online documentation, explains that online documentation can encompass a number of forms, from on-screen error messages to computer-based tutorials. My discussion will be restricted to two kinds of online documentation. The first is what often is called “help”—basically a reference document online. In many of the Microsoft Help systems, for instance, users can find information on program commands (analogous to a reference manual) as well as information about procedures (analogous to a user's manual). The other type of online documentation is an online tutorial, computer-based training (CBT). The tutorial describes basic procedures and commands and it interactive so that there is a major “hands-on” component to the training.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {41–48},
numpages = {8},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97991,
author = {Simpson, Mark},
title = {How Usability Testing Can Aid the Development of Online Documentation},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97991},
doi = {10.1145/97435.97991},
abstract = {Over the past five years, usability testing has become a more accepted part of the software development process as writers, managers, and programmers recognize the need for evaluating their products from the user's point of view. As the application of usability testing has grown, so has the interest in procedures and methods. One indication of that is the number of presentations on usability testing at conferences and the increased number of publications on usability testing. Last year, for instance, an entire issue of the IEEE Transactions on Technical Communications devoted to usability testing. As Ramey (1989a) explains in that issue, “the question of whether to has yielded to the question of how to” (p. 207).The interest in procedures and methods has also brought about a concern for applying usability testing not just to validate computer products but also to provide feedback to product developers (Sullivan, 1987). In fact, theorists and practitioners of usability testing argue that iterative testing (that is, testing a product frequently during its development cycle) is the most productive application of usability testing (Dieli, 1989a). By testing iteratively, usability testing can have the greatest effect on the development of the product. One problem, of course, is finding methods that can be used to test products at each stage of the development process. For example, how can writers usability test an online help system before a working prototype has been created? And how do they test semi-functional prototypes?The problem is especially acute for developers of online documentation. In general, the development process of online documentation contains more variables than print documentation, which means that more things can go wrong. For instance, online must be integrated with a product, yet it may be developed separately and “put together” near the end of the development cycle. In addition, development can be slower, because online depends on several technologies (the text, the help engine, perhaps multimedia), whereas print documentation generally depends on one. The testing “toolbox” therefore needs to be especially responsive to a product's developmental stages.In this article I describe how testing methodologies can be used to test online help systems iteratively. Specifically, I discuss a framework for visualizing usability testing of online documentation through the development cycle. But first, two limitations on the scope of the article. The discussion is intended for writers and online developers who are new to usability testing and for students and teachers in documentation writing courses, although experienced researchers may find it helpful as a planning aid. Second, the article focuses on exploratory or “feedback” kinds of tests, rather than tests that confirm or validate products.Before going any further, let me define what I mean by “online documentation.” Horton (1990), in his textbook on designing online documentation, explains that online documentation can encompass a number of forms, from on-screen error messages to computer-based tutorials. My discussion will be restricted to two kinds of online documentation. The first is what often is called “help”—basically a reference document online. In many of the Microsoft Help systems, for instance, users can find information on program commands (analogous to a reference manual) as well as information about procedures (analogous to a user's manual). The other type of online documentation is an online tutorial, computer-based training (CBT). The tutorial describes basic procedures and commands and it interactive so that there is a major “hands-on” component to the training.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {41–48},
numpages = {8}
}

@inproceedings{10.1145/97426.97992,
author = {Dautermann, Jennie},
title = {Putting a Local Information System Online Using Pre-Packaged Software},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97992},
doi = {10.1145/97426.97992},
abstract = {Many small organizations have the need for information storage and retrieval systems which they dream of putting on-line for ease of access. Such a project designed with modest equipment and pre-packaged software can achieve three important objectives:
allow users to design their own access toolsclarify the information needs of a communityimprove information access.These goals may be sufficient in themselves in many situations, but they may also become interim steps which prepare users for involvement in larger institutional projects at some later time by enabling them to think through their information needs in concrete and manageable terms.During an information management project with the nursing department of a Midwest community hospital, a standard PC data base became the vehicle for introducing each of these benefits to the department and for preparing the department to participate in a larger main frame project already in progress in their hospital.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {49–53},
numpages = {5},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97992,
author = {Dautermann, Jennie},
title = {Putting a Local Information System Online Using Pre-Packaged Software},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97992},
doi = {10.1145/97435.97992},
abstract = {Many small organizations have the need for information storage and retrieval systems which they dream of putting on-line for ease of access. Such a project designed with modest equipment and pre-packaged software can achieve three important objectives:
allow users to design their own access toolsclarify the information needs of a communityimprove information access.These goals may be sufficient in themselves in many situations, but they may also become interim steps which prepare users for involvement in larger institutional projects at some later time by enabling them to think through their information needs in concrete and manageable terms.During an information management project with the nursing department of a Midwest community hospital, a standard PC data base became the vehicle for introducing each of these benefits to the department and for preparing the department to participate in a larger main frame project already in progress in their hospital.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {49–53},
numpages = {5}
}

@inproceedings{10.1145/97426.97990,
author = {Johnson, Bob},
title = {User-Centeredness, Situatedness, and Designing the Media of Computer Documentation},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97990},
doi = {10.1145/97426.97990},
abstract = {User-centeredness has become a concept of much interest in a number of fields. Systems engineering, architecture, usability research and computer documentation, to name a few, are all areas of study which have, to one degree or another, adopted the terminology of user-centered philosophy in order to come to grips with the problem of how to design for users' needs.While there is much positive to be said about applying user-centered concepts to any discipline that wishes to pursue it, there is also a danger that the concept and philosophy of user-centered design could become, at best, empty rhetoric, and, at worst, fuel for lip service that could serve to undermine the humanitarian goals of a user-centered ethic.One concept which has already suffered a similar fate is that of “problem-solving.” Problem-solving has become, essentially, a hollow term when used by certain disciplines or institutions. For example, it is commonplace to hear representatives of business and industry refer to the need for 'good problem-solvers' in the world of business.One answer to this call has been the adoption of the terminology of problem-solving by the business curricula of many college and university business schools. At least one critic of current business school curricula has mentioned that theories of problem-solving have been diluted by the time they reach students (1). My own experience in teaching business writing at two universities has shown similar characteristics. Many of the business majors want to refer to themselves as “good problem-solvers” in their job application letters, but when asked to elaborate on or give an example of this, they often have simplified or inaccurate ideas of what should constitute an understanding of rich and powerful strategies.Certainly, the research and theory-building of Simon and Newell (2), or G. Polya (3) is applicable to the academic and workplace settings of business, but somehow the terminology of the theory lost its relevance during the translation.My purpose in this article is to discuss how user-centered computer documentation can avoid a similar fate. At present I fear our direction is veering in the direction of such a fate, and that one step toward correcting our course is to develop a clear theoretical understanding of what user-centeredness means to documentation. This means that although there may be a tacit theory which underlies current applications, it is important to make the theory visible, and thereby illuminate the gaps that may exist.In addition, my focus will also be upon the contribution that user-centered theory can bring to our understanding of how to design for the different media of computer documentation. As we all know, online and hypermedia documentation is becoming a central charge of our profession, and user-centered theory can go a long way in helping us understand the similarities and differences among the different media.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {55–61},
numpages = {7},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97990,
author = {Johnson, Bob},
title = {User-Centeredness, Situatedness, and Designing the Media of Computer Documentation},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97990},
doi = {10.1145/97435.97990},
abstract = {User-centeredness has become a concept of much interest in a number of fields. Systems engineering, architecture, usability research and computer documentation, to name a few, are all areas of study which have, to one degree or another, adopted the terminology of user-centered philosophy in order to come to grips with the problem of how to design for users' needs.While there is much positive to be said about applying user-centered concepts to any discipline that wishes to pursue it, there is also a danger that the concept and philosophy of user-centered design could become, at best, empty rhetoric, and, at worst, fuel for lip service that could serve to undermine the humanitarian goals of a user-centered ethic.One concept which has already suffered a similar fate is that of “problem-solving.” Problem-solving has become, essentially, a hollow term when used by certain disciplines or institutions. For example, it is commonplace to hear representatives of business and industry refer to the need for 'good problem-solvers' in the world of business.One answer to this call has been the adoption of the terminology of problem-solving by the business curricula of many college and university business schools. At least one critic of current business school curricula has mentioned that theories of problem-solving have been diluted by the time they reach students (1). My own experience in teaching business writing at two universities has shown similar characteristics. Many of the business majors want to refer to themselves as “good problem-solvers” in their job application letters, but when asked to elaborate on or give an example of this, they often have simplified or inaccurate ideas of what should constitute an understanding of rich and powerful strategies.Certainly, the research and theory-building of Simon and Newell (2), or G. Polya (3) is applicable to the academic and workplace settings of business, but somehow the terminology of the theory lost its relevance during the translation.My purpose in this article is to discuss how user-centered computer documentation can avoid a similar fate. At present I fear our direction is veering in the direction of such a fate, and that one step toward correcting our course is to develop a clear theoretical understanding of what user-centeredness means to documentation. This means that although there may be a tacit theory which underlies current applications, it is important to make the theory visible, and thereby illuminate the gaps that may exist.In addition, my focus will also be upon the contribution that user-centered theory can bring to our understanding of how to design for the different media of computer documentation. As we all know, online and hypermedia documentation is becoming a central charge of our profession, and user-centered theory can go a long way in helping us understand the similarities and differences among the different media.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {55–61},
numpages = {7}
}

@inproceedings{10.1145/97426.97993,
author = {Berghel, Hal and Roach, David},
title = {Documentation Design Based upon Intuitive Feature Taxonomy and Use Logging},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97993},
doi = {10.1145/97426.97993},
abstract = {Although the quality of documentation of office automation software has increased significantly in the past few years, current offerings are not without problems. Those difficulties which have to do with the design and organization of the documentation are addressed in this paper.To illustrate, consider the following situations: 1) the command and control information which is commonly needed is either omitted or hard to find on the 'command card' or 'keyboard template' provided by the vendor, 2) the command or control information which we intuitively feel should be discussed in one section of the manual is actually located in an unrelated section, 3) the manual's table of contents does not seem to correspond well with the functional characteristics of the product, 4) the most appropriate command is not to be found in the manual's index, and 5) the 'help' facility frequently wastes rather than conserves time by providing the user with inappropriate alternatives. We maintain that these sorts of obstructions arise in many cases because insufficient attention has been given to an common sensical and intuitive analysis of the product's functionality as well as empirical use studies. We describe how these difficulties may be overcome by appeal to research results reported in the literature. Word processing software will be used to illustrate the technique.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {63–68},
numpages = {6},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97993,
author = {Berghel, Hal and Roach, David},
title = {Documentation Design Based upon Intuitive Feature Taxonomy and Use Logging},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97993},
doi = {10.1145/97435.97993},
abstract = {Although the quality of documentation of office automation software has increased significantly in the past few years, current offerings are not without problems. Those difficulties which have to do with the design and organization of the documentation are addressed in this paper.To illustrate, consider the following situations: 1) the command and control information which is commonly needed is either omitted or hard to find on the 'command card' or 'keyboard template' provided by the vendor, 2) the command or control information which we intuitively feel should be discussed in one section of the manual is actually located in an unrelated section, 3) the manual's table of contents does not seem to correspond well with the functional characteristics of the product, 4) the most appropriate command is not to be found in the manual's index, and 5) the 'help' facility frequently wastes rather than conserves time by providing the user with inappropriate alternatives. We maintain that these sorts of obstructions arise in many cases because insufficient attention has been given to an common sensical and intuitive analysis of the product's functionality as well as empirical use studies. We describe how these difficulties may be overcome by appeal to research results reported in the literature. Word processing software will be used to illustrate the technique.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {63–68},
numpages = {6}
}

@inproceedings{10.1145/97426.97994,
author = {Mirel, Barbara},
title = {Usability and Hardcopy Manuals: Evaluating Research Designs and Methods},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97994},
doi = {10.1145/97426.97994},
abstract = {For the past decade, testing the usability of print software manuals has become a mature area of study, characterized by a wide range of qualitative and quantitative methods. Some of the most common methods include field observations, surveys, interviews, protocol analyses, focus groups, iterative testing, and quasi-experimental lab simulations [1]. Such diverse approaches to usability testing offer an opportunity for complementary inquiries and analyses. For example, findings from focus groups can provide key questions for experimental researchers to pursue in greater depth and with greater possibility for generalizability. Essentially, this complementary approach envisions an interaction between the academy, with its propensity toward pure, experimental research, and industry, with its more applied approaches for alpha and beta testing.Patricia Wright, a specialist in usability studies, has long argued that integrating pure and applied research is the best means for expanding our knowledge about effective document design [2; 3]. Such integration reveals both the immediately applicable aspects of effective manuals and the more theoretical boundaries in textual features that make a difference for general types of tasks, readers, and contexts of use.In order to realize the potential of conducting a conversation between pure and applied research, documentation researchers and practitioners must clearly understand the limitations that exist in the conclusions that investigators derive from specific methods of inquiry. In this article, I look solely at experimental usability tests that rely on quantitative methods of analysis. I analyze the ways in which the research designs and questions of the past ten years of experimental studies affect the strength of cumulative conclusions and the confidence we can have in those conclusions. My purpose is not to give preference to experimental research as the most important approach to usability testing. Far from it. Rather my critical review has two purposes: (1) to facilitate the dialogue between academic and industrial researchers by identifying the limits of current experimental findings; and (2) to propose research agendas and designs for future experimental usability tests that can strengthen the conclusions that such researchers offer for practical consideration.My evaluation of ten years of experimental usability studies shows that many of the conclusions of these studies are not strong enough to serve as valid, generalizable, and replicable foundations for subsequent research, be it pure or applied. These conclusions can be strengthened by designing studies that pay more attention to the sequencing and integration of related investigations and that institute better controls for sample selection, size, and composition. This article discusses my overall findings, the details of which I will develop more fully in my presentation.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {69–77},
numpages = {9},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97994,
author = {Mirel, Barbara},
title = {Usability and Hardcopy Manuals: Evaluating Research Designs and Methods},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97994},
doi = {10.1145/97435.97994},
abstract = {For the past decade, testing the usability of print software manuals has become a mature area of study, characterized by a wide range of qualitative and quantitative methods. Some of the most common methods include field observations, surveys, interviews, protocol analyses, focus groups, iterative testing, and quasi-experimental lab simulations [1]. Such diverse approaches to usability testing offer an opportunity for complementary inquiries and analyses. For example, findings from focus groups can provide key questions for experimental researchers to pursue in greater depth and with greater possibility for generalizability. Essentially, this complementary approach envisions an interaction between the academy, with its propensity toward pure, experimental research, and industry, with its more applied approaches for alpha and beta testing.Patricia Wright, a specialist in usability studies, has long argued that integrating pure and applied research is the best means for expanding our knowledge about effective document design [2; 3]. Such integration reveals both the immediately applicable aspects of effective manuals and the more theoretical boundaries in textual features that make a difference for general types of tasks, readers, and contexts of use.In order to realize the potential of conducting a conversation between pure and applied research, documentation researchers and practitioners must clearly understand the limitations that exist in the conclusions that investigators derive from specific methods of inquiry. In this article, I look solely at experimental usability tests that rely on quantitative methods of analysis. I analyze the ways in which the research designs and questions of the past ten years of experimental studies affect the strength of cumulative conclusions and the confidence we can have in those conclusions. My purpose is not to give preference to experimental research as the most important approach to usability testing. Far from it. Rather my critical review has two purposes: (1) to facilitate the dialogue between academic and industrial researchers by identifying the limits of current experimental findings; and (2) to propose research agendas and designs for future experimental usability tests that can strengthen the conclusions that such researchers offer for practical consideration.My evaluation of ten years of experimental usability studies shows that many of the conclusions of these studies are not strong enough to serve as valid, generalizable, and replicable foundations for subsequent research, be it pure or applied. These conclusions can be strengthened by designing studies that pay more attention to the sequencing and integration of related investigations and that institute better controls for sample selection, size, and composition. This article discusses my overall findings, the details of which I will develop more fully in my presentation.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {69–77},
numpages = {9}
}

@inproceedings{10.1145/97426.97995,
author = {Wilkin, Lorraine and Wulff, Wendie and Richardson Smith, Fitch},
title = {Document Means More than Manual: Document Design Outside the Computer Industry},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97995},
doi = {10.1145/97426.97995},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {79–86},
numpages = {8},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97995,
author = {Wilkin, Lorraine and Wulff, Wendie and Richardson Smith, Fitch},
title = {Document Means More than Manual: Document Design Outside the Computer Industry},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97995},
doi = {10.1145/97435.97995},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {79–86},
numpages = {8}
}

@inproceedings{10.1145/97426.97996,
author = {Ressler, Duane and Stribling, Dee},
title = {Designing and Prototyping a Portable Hypertext Application},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97996},
doi = {10.1145/97426.97996},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {87–94},
numpages = {8},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97996,
author = {Ressler, Duane and Stribling, Dee},
title = {Designing and Prototyping a Portable Hypertext Application},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97996},
doi = {10.1145/97435.97996},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {87–94},
numpages = {8}
}

@inproceedings{10.1145/97426.97997,
author = {Carlson, Patricia A.},
title = {Artificial Neural Networks as Cognitive Tools for Professional Writing},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97997},
doi = {10.1145/97426.97997},
abstract = {Computers are cognitive tools — they extend the capabilities of the human mind. Paper and pencil are also cognitive tools — they enhance human memory by acting as a permanent record, and they mediate the formation of thought by serving as a scratchpad or rehearsal device. However, there is a qualitative difference between these cognitive tools: the computer as a writing environment can become an active participant in the process while paper and pencil must remain passive instruments. Because this fundamental difference seems obvious to me, I'm surprised that most computer-aided writing (CAW) software available today is based on a model derived from writing with traditional tools.Such computer tools as spelling checkers, “style” checkers (actually, they check usage) and outliners, have been around in one form or another for a long time now. Yet they have not really had much of an impact. Most of these packages share three major drawbacks: their analysis is based on statistical measurements of simple surface features of writing; they provide “after-the-fact” profiling; and, in general, they treat all text as equal.As Shoshana Zuboff points out (In the Age of the Smart Machine), the computer — unlike the tools of the Industrial Revolution — not only automates, it also informates. When it comes to text technology, we've done a great deal to automate the process — as illustrated by word processing and desktop publishing. But we're only starting to use the computer's capacity to informate the process.A quick review of four categories of CAW tools indicates the state-of-the-art.Statistical Text Analysis: I'll use Bell Lab's Writer's Workbenchtm to cover a broad category of software which makes use of patterns to analyze prose. The Workbench is a collection of small programs to measure surface features of writing. For example, the user can find out readability level, average sentence length, word length, percentage of sentence types, percentage of passive-voice verbs, jargon, wordiness, sexist language, spelling errors, and improper usage. Other programs are intended to analyze rhetoric structures. For example, a program displays only the first and last sentence in each paragraph, with the idea that this representation will allow the user to check for logical transitions.Though the package has been around for some time now, it never really caught on. Its UNIX requirement and relatively high cost lessened the likelihood of widespread use. Additionally, the forty-or-more programs are all discrete — meaning that a truly cumulative analysis of a passage, taking into account the interaction of stylistic features, isn't possible. And, as a third limitation, because the analysis works at such a low level in the composing process, writers sometimes become obsessed with the accidents (surface errors) of their prose rather than the essence (strengthening the logic and content).Prewriting: Planning what to say and how to say it takes time. Professional writers have developed strategies for making this “prewriting” stage of composing more efficient. The journalist's “who, what, when, where, and why” litany is an example of a heuristic intended to help focus thoughts. There are many such heuristics, some dating back to Aristotle.Typically, software in this category automates an established strategy. The earliest invention software was modeled on Joseph Weizenbaum's ELIZA. Even today, implementation frequently takes the form of a dialogue, with the program asking significant questions and making appropriate comments on the writer's responses. The writer then uses the recorded information as the raw materials for the paper.Two drawbacks show up in current systems. First, many strategies when used by professional writers are comparable to a rule-of-thumb; thus, the effectiveness and appropriateness of a heuristic varies with the task. They lose most of their spontaneity and flexibility when automated. Second, the dialogue metaphor — which attributes a personality to the computer — is an embarrassing affectation in most programs.Outliners: This category has generated more commercial interest than the other three. Though frequently called “idea processors,” the label seems more honorific than earned. Most use a top-down (general-to-specific) knowledge representation as their bases. In other words, the writer is encouraged to find hierarchical relationships in her raw material by filling in an open-ended tree-structure. On some systems, levels can be hidden, thus focusing attention and reducing the cognitive load inherent in the writing process.Writing Environments: The more interesting of these programs are still in their infancy, and can be represented by WE (Writing Environment developed at the University of North Carolina—Chapel Hill) and CICILE (developed at the Center for Applied Cognitive Science in Toronto, Ontario). In something like the Writer's Workbenchtm, analytical programs are separate entities, and the writer is free to pick and choose among them. On the other hand, the suite of tools in a “writing environment” is integrated and part of a rigorously structured cognitive model of the writing process. In essence, a well-designed writing environment orchestrates the writing process by emulating stages of thinking. Few, if any, writing environments include AI applications as we normally define them (e.g. expert systems). Nevertheless, because the whole system supports and guides the activities of thinking, these knowledge-making habitats should be characterized as “intelligent.”I like the concept, but I am just a bit uneasy with the implementation. First, all of the examples I am aware of are theory-laden and exit as heavily-funded projects at large research universities or government-sponsored laboratories. In fact, these systems seem to be testbeds for doing high-powered research on the writing process more than practical tools for professionals. Second, because of the amount of “scaffolding” each system provides for the writer, they seem more appropriate as a learning environment. In short, they are more tutors than tools. And third, their heavy commitment to a definitive cognitive model of writing seems to ignore what historians of technology have taught us: new tools engender new habits of mind, and the tool — over time — can change the nature of the task.In summary then, word processing precipitated interest in computer-aided writing (CAW). Once text could be represented as bits and bytes, computational software for analyzing prose patterns became feasible. My objection is that the patterns used are too fine-grained and that the evaluation is too rigorous to qualify as a comfortable cognitive tool. I have never used a CAW product that, eventually, didn't pinch and constrain my writing process by being distractingly intrusive, nit-pickingly atomistic, or down-right tedious and misleading in the advice it returned.I view writing as one manifestation of the controlled creativity we call design. The cognitive activities of design take place in a cyclical rather than linear fashion. First, we decompose or partition the task into its components to get an idea of what we are trying to do. Then, we work on the pieces for a while, step back to compare interim results with higher-level goals, consolidate gains, jettison unrealistic expectations or excessive constraints, reorder plans, and move back to working on the pieces again. The cycle takes place over and over during the writing session. Good writers excel where poor writers fail because of this flexibility, this ability to move smoothly between top-down and bottom-up strategies. To my mind, a good cognitive tool for composing has two functions: (1) to serve as a peripheral brain that helps with the cognitive overload inherent in a complex task, and (2) to act as an expert associate that provides counsel in the iterative, “prototype and feedback” process of design.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {95–110},
numpages = {16},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97997,
author = {Carlson, Patricia A.},
title = {Artificial Neural Networks as Cognitive Tools for Professional Writing},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97997},
doi = {10.1145/97435.97997},
abstract = {Computers are cognitive tools — they extend the capabilities of the human mind. Paper and pencil are also cognitive tools — they enhance human memory by acting as a permanent record, and they mediate the formation of thought by serving as a scratchpad or rehearsal device. However, there is a qualitative difference between these cognitive tools: the computer as a writing environment can become an active participant in the process while paper and pencil must remain passive instruments. Because this fundamental difference seems obvious to me, I'm surprised that most computer-aided writing (CAW) software available today is based on a model derived from writing with traditional tools.Such computer tools as spelling checkers, “style” checkers (actually, they check usage) and outliners, have been around in one form or another for a long time now. Yet they have not really had much of an impact. Most of these packages share three major drawbacks: their analysis is based on statistical measurements of simple surface features of writing; they provide “after-the-fact” profiling; and, in general, they treat all text as equal.As Shoshana Zuboff points out (In the Age of the Smart Machine), the computer — unlike the tools of the Industrial Revolution — not only automates, it also informates. When it comes to text technology, we've done a great deal to automate the process — as illustrated by word processing and desktop publishing. But we're only starting to use the computer's capacity to informate the process.A quick review of four categories of CAW tools indicates the state-of-the-art.Statistical Text Analysis: I'll use Bell Lab's Writer's Workbenchtm to cover a broad category of software which makes use of patterns to analyze prose. The Workbench is a collection of small programs to measure surface features of writing. For example, the user can find out readability level, average sentence length, word length, percentage of sentence types, percentage of passive-voice verbs, jargon, wordiness, sexist language, spelling errors, and improper usage. Other programs are intended to analyze rhetoric structures. For example, a program displays only the first and last sentence in each paragraph, with the idea that this representation will allow the user to check for logical transitions.Though the package has been around for some time now, it never really caught on. Its UNIX requirement and relatively high cost lessened the likelihood of widespread use. Additionally, the forty-or-more programs are all discrete — meaning that a truly cumulative analysis of a passage, taking into account the interaction of stylistic features, isn't possible. And, as a third limitation, because the analysis works at such a low level in the composing process, writers sometimes become obsessed with the accidents (surface errors) of their prose rather than the essence (strengthening the logic and content).Prewriting: Planning what to say and how to say it takes time. Professional writers have developed strategies for making this “prewriting” stage of composing more efficient. The journalist's “who, what, when, where, and why” litany is an example of a heuristic intended to help focus thoughts. There are many such heuristics, some dating back to Aristotle.Typically, software in this category automates an established strategy. The earliest invention software was modeled on Joseph Weizenbaum's ELIZA. Even today, implementation frequently takes the form of a dialogue, with the program asking significant questions and making appropriate comments on the writer's responses. The writer then uses the recorded information as the raw materials for the paper.Two drawbacks show up in current systems. First, many strategies when used by professional writers are comparable to a rule-of-thumb; thus, the effectiveness and appropriateness of a heuristic varies with the task. They lose most of their spontaneity and flexibility when automated. Second, the dialogue metaphor — which attributes a personality to the computer — is an embarrassing affectation in most programs.Outliners: This category has generated more commercial interest than the other three. Though frequently called “idea processors,” the label seems more honorific than earned. Most use a top-down (general-to-specific) knowledge representation as their bases. In other words, the writer is encouraged to find hierarchical relationships in her raw material by filling in an open-ended tree-structure. On some systems, levels can be hidden, thus focusing attention and reducing the cognitive load inherent in the writing process.Writing Environments: The more interesting of these programs are still in their infancy, and can be represented by WE (Writing Environment developed at the University of North Carolina—Chapel Hill) and CICILE (developed at the Center for Applied Cognitive Science in Toronto, Ontario). In something like the Writer's Workbenchtm, analytical programs are separate entities, and the writer is free to pick and choose among them. On the other hand, the suite of tools in a “writing environment” is integrated and part of a rigorously structured cognitive model of the writing process. In essence, a well-designed writing environment orchestrates the writing process by emulating stages of thinking. Few, if any, writing environments include AI applications as we normally define them (e.g. expert systems). Nevertheless, because the whole system supports and guides the activities of thinking, these knowledge-making habitats should be characterized as “intelligent.”I like the concept, but I am just a bit uneasy with the implementation. First, all of the examples I am aware of are theory-laden and exit as heavily-funded projects at large research universities or government-sponsored laboratories. In fact, these systems seem to be testbeds for doing high-powered research on the writing process more than practical tools for professionals. Second, because of the amount of “scaffolding” each system provides for the writer, they seem more appropriate as a learning environment. In short, they are more tutors than tools. And third, their heavy commitment to a definitive cognitive model of writing seems to ignore what historians of technology have taught us: new tools engender new habits of mind, and the tool — over time — can change the nature of the task.In summary then, word processing precipitated interest in computer-aided writing (CAW). Once text could be represented as bits and bytes, computational software for analyzing prose patterns became feasible. My objection is that the patterns used are too fine-grained and that the evaluation is too rigorous to qualify as a comfortable cognitive tool. I have never used a CAW product that, eventually, didn't pinch and constrain my writing process by being distractingly intrusive, nit-pickingly atomistic, or down-right tedious and misleading in the advice it returned.I view writing as one manifestation of the controlled creativity we call design. The cognitive activities of design take place in a cyclical rather than linear fashion. First, we decompose or partition the task into its components to get an idea of what we are trying to do. Then, we work on the pieces for a while, step back to compare interim results with higher-level goals, consolidate gains, jettison unrealistic expectations or excessive constraints, reorder plans, and move back to working on the pieces again. The cycle takes place over and over during the writing session. Good writers excel where poor writers fail because of this flexibility, this ability to move smoothly between top-down and bottom-up strategies. To my mind, a good cognitive tool for composing has two functions: (1) to serve as a peripheral brain that helps with the cognitive overload inherent in a complex task, and (2) to act as an expert associate that provides counsel in the iterative, “prototype and feedback” process of design.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {95–110},
numpages = {16}
}

@inproceedings{10.1145/97426.97998,
author = {Brockmann, R. John},
title = {The Why, Where and How of Minimalism},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97998},
doi = {10.1145/97426.97998},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {111–119},
numpages = {9},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97998,
author = {Brockmann, R. John},
title = {The Why, Where and How of Minimalism},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97998},
doi = {10.1145/97435.97998},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {111–119},
numpages = {9}
}

@inproceedings{10.1145/97426.97999,
author = {Stimely, Gwen L.},
title = {A Stepwise Approach to Developing Software Documentation},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.97999},
doi = {10.1145/97426.97999},
abstract = {Published documentation development processes clearly explain how to break up the process into parts and which parts to do when. What they do not explain is how to merge documentation and software development so that documentation rework and catch-up are minimized. They also do not explicitly account for developing a document from one version to the next, or how to integrate multiple authors into the development process.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {121–124},
numpages = {4},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.97999,
author = {Stimely, Gwen L.},
title = {A Stepwise Approach to Developing Software Documentation},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.97999},
doi = {10.1145/97435.97999},
abstract = {Published documentation development processes clearly explain how to break up the process into parts and which parts to do when. What they do not explain is how to merge documentation and software development so that documentation rework and catch-up are minimized. They also do not explicitly account for developing a document from one version to the next, or how to integrate multiple authors into the development process.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {121–124},
numpages = {4}
}

@inproceedings{10.1145/97426.98000,
author = {Hopkins, June S. and Jernow, Jean M.},
title = {Documenting the Software Development Process},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98000},
doi = {10.1145/97426.98000},
abstract = {The Software Engineering Process Group (SEPG) at the Data Systems Division of Litton Systems, Inc., was given the task of documenting the software development process used within the division. This paper describes how the SEPG at Litton accomplished this task. It discusses the sources we used for guidance and describes the resulting documentation for defining the software development process and the methods and tools that support the process.After reviewing the existing software process documentation at Litton, the SEPG concluded that three separate documents were required: a revised set of Software Policies and Procedures (PPGs), a Software Engineering Handbook, and a Software Management Handbook. The SEPG established working groups to develop these documents. The working group responsible for the Software Engineering Handbook decided to develop it as a user manual for the software development process. Following Weiss' guidelines for developing a usable user manual, the working group developed storyboards for sections of the manual. A model initially developed at IBM and refined by SEI and others was used to describe the software development process as a series of work tasks, each of which has entry criteria, exit criteria, objectives, and steps to perform.Several authors developed the storyboards and the corresponding modules of the handbook. The handbook was partitioned into short modules, each of which has a topic sentence and a figure (where applicable). The result is a modular Software Engineering Handbook that is easy to read and maintain.The use of working groups and the development of the Software Engineering Handbook as a user manual proved to be efficient and effective methods for generating high quality software process documentation.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {125–133},
numpages = {9},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98000,
author = {Hopkins, June S. and Jernow, Jean M.},
title = {Documenting the Software Development Process},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98000},
doi = {10.1145/97435.98000},
abstract = {The Software Engineering Process Group (SEPG) at the Data Systems Division of Litton Systems, Inc., was given the task of documenting the software development process used within the division. This paper describes how the SEPG at Litton accomplished this task. It discusses the sources we used for guidance and describes the resulting documentation for defining the software development process and the methods and tools that support the process.After reviewing the existing software process documentation at Litton, the SEPG concluded that three separate documents were required: a revised set of Software Policies and Procedures (PPGs), a Software Engineering Handbook, and a Software Management Handbook. The SEPG established working groups to develop these documents. The working group responsible for the Software Engineering Handbook decided to develop it as a user manual for the software development process. Following Weiss' guidelines for developing a usable user manual, the working group developed storyboards for sections of the manual. A model initially developed at IBM and refined by SEI and others was used to describe the software development process as a series of work tasks, each of which has entry criteria, exit criteria, objectives, and steps to perform.Several authors developed the storyboards and the corresponding modules of the handbook. The handbook was partitioned into short modules, each of which has a topic sentence and a figure (where applicable). The result is a modular Software Engineering Handbook that is easy to read and maintain.The use of working groups and the development of the Software Engineering Handbook as a user manual proved to be efficient and effective methods for generating high quality software process documentation.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {125–133},
numpages = {9}
}

@inproceedings{10.1145/97426.98001,
author = {Hallgren, Chris},
title = {The Mythical Task},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98001},
doi = {10.1145/97426.98001},
abstract = {We confront a time in society when phrases such as “information anxiety” have become cliches. As documentation developers, we have a mission to sort information into structures that help users perform their work on computers. Task-based documentation has emerged as one of the most popular models for explaining the principals of sorting information into useful instructions or learning materials. This paper deals with environments where standard task-analysis flounders, either due to the conflicts between different audiences who use the same task elements in different ways, or the complexity of the domain, which makes discrete task modules nearly impossible to define. Under these conditions, we equate the definition of clear tasks with myth -- meaning a symbolic goal more than a real possibility.This paper will explore ways to track down the mythical tasks in the information that describes a large, open computer graphics system. This discussion will also serve as a model for analyzing the use of open systems. First we supply the technological history that has led to this information breakdown. Then we present two models from the computer graphics field to use as examples in the application of the theories in this paper. Following this, the paper discusses Tour Books, Tool Books, Job Books, and the importance of both precise and alternate terminology. Finally, it will discuss the usefulness and limitations of indexes, cross references, alphabetic references and hyper text (extended indexes and cross references).},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {135–139},
numpages = {5},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98001,
author = {Hallgren, Chris},
title = {The Mythical Task},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98001},
doi = {10.1145/97435.98001},
abstract = {We confront a time in society when phrases such as “information anxiety” have become cliches. As documentation developers, we have a mission to sort information into structures that help users perform their work on computers. Task-based documentation has emerged as one of the most popular models for explaining the principals of sorting information into useful instructions or learning materials. This paper deals with environments where standard task-analysis flounders, either due to the conflicts between different audiences who use the same task elements in different ways, or the complexity of the domain, which makes discrete task modules nearly impossible to define. Under these conditions, we equate the definition of clear tasks with myth -- meaning a symbolic goal more than a real possibility.This paper will explore ways to track down the mythical tasks in the information that describes a large, open computer graphics system. This discussion will also serve as a model for analyzing the use of open systems. First we supply the technological history that has led to this information breakdown. Then we present two models from the computer graphics field to use as examples in the application of the theories in this paper. Following this, the paper discusses Tour Books, Tool Books, Job Books, and the importance of both precise and alternate terminology. Finally, it will discuss the usefulness and limitations of indexes, cross references, alphabetic references and hyper text (extended indexes and cross references).},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {135–139},
numpages = {5}
}

@inproceedings{10.1145/97426.98002,
author = {Roach, David and Berghel, Hal and Talburt, John R.},
title = {An Interactive Source Commenter for Prolog Programs},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98002},
doi = {10.1145/97426.98002},
abstract = {Prolog meta-circular interpreters, i.e., interpreters for Prolog written in Prolog, perform at least two operations on an object program - they parse it and execute its instructions. There is a useful variant of the meta-circular interpreter, the meta-circular parser, which as its name suggests, parses an object program without executing its instructions. The value of such a parser is that it provides an elegant means to modify Prolog source code. As the object program is parsed, new information in the form of additional instructions, comments, etc., can be selectively inserted.The Prolog source code commenter we describe is a meta-circular parser with facilities added to allow a user to interactively enter comments. As a Prolog program is parsed into its basic components, the user is allowed to view that component and enter an appropriate comment. The result is a new fully commented (and formatted) source program.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {141–145},
numpages = {5},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98002,
author = {Roach, David and Berghel, Hal and Talburt, John R.},
title = {An Interactive Source Commenter for Prolog Programs},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98002},
doi = {10.1145/97435.98002},
abstract = {Prolog meta-circular interpreters, i.e., interpreters for Prolog written in Prolog, perform at least two operations on an object program - they parse it and execute its instructions. There is a useful variant of the meta-circular interpreter, the meta-circular parser, which as its name suggests, parses an object program without executing its instructions. The value of such a parser is that it provides an elegant means to modify Prolog source code. As the object program is parsed, new information in the form of additional instructions, comments, etc., can be selectively inserted.The Prolog source code commenter we describe is a meta-circular parser with facilities added to allow a user to interactively enter comments. As a Prolog program is parsed into its basic components, the user is allowed to view that component and enter an appropriate comment. The result is a new fully commented (and formatted) source program.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {141–145},
numpages = {5}
}

@inproceedings{10.1145/97426.98003,
author = {Talburt, John R. and Roach, David},
title = {RAP: Relocation Allowance Planner, a Rule-Based Expert System with Self-Defining Documentation Features},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98003},
doi = {10.1145/97426.98003},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {147–150},
numpages = {4},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98003,
author = {Talburt, John R. and Roach, David},
title = {RAP: Relocation Allowance Planner, a Rule-Based Expert System with Self-Defining Documentation Features},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98003},
doi = {10.1145/97435.98003},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {147–150},
numpages = {4}
}

@inproceedings{10.1145/97426.98004,
author = {M\'{e}nard, Marlene},
title = {Writing Instructional Materials for Computing Service Courses},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98004},
doi = {10.1145/97426.98004},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {151–156},
numpages = {6},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98004,
author = {M\'{e}nard, Marlene},
title = {Writing Instructional Materials for Computing Service Courses},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98004},
doi = {10.1145/97435.98004},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {151–156},
numpages = {6}
}

@inproceedings{10.1145/97426.98005,
author = {Raymond, Darrell R. and Fawcett, Heather J.},
title = {Playing Detective with Full Text Searching Software},
year = {1990},
isbn = {0897914147},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
url = {https://doi.org/10.1145/97426.98005},
doi = {10.1145/97426.98005},
abstract = {Searching large text databases often resembles detective work. We explored this notion with an experiment in which subjects used powerful full text searching software to solve problems about the Arthur Conan Doyle story The Hound of the Baskervilles. The experiment was conducted in two parts: in the first part subjects attempted to teach themselves about the software using only the documentation; in the second part, subjects used the software to answer questions such as What brand of cigarette does Watson smoke? The experiment provided a great deal of feedback about the usability of the software and the documentation. Among the results that have wider implications are the need for better display of context, and a need for careful documentation of the characteristics of full text searching.},
booktitle = {Proceedings of the 8th Annual International Conference on Systems Documentation},
pages = {157–166},
numpages = {10},
location = {Little Rock, Arkansas, USA},
series = {SIGDOC '90}
}

@article{10.1145/97435.98005,
author = {Raymond, Darrell R. and Fawcett, Heather J.},
title = {Playing Detective with Full Text Searching Software},
year = {1990},
issue_date = {1990},
publisher = {Association for Computing Machinery},
address = {New York, NY, USA},
volume = {14},
number = {4},
issn = {0731-1001},
url = {https://doi.org/10.1145/97435.98005},
doi = {10.1145/97435.98005},
abstract = {Searching large text databases often resembles detective work. We explored this notion with an experiment in which subjects used powerful full text searching software to solve problems about the Arthur Conan Doyle story The Hound of the Baskervilles. The experiment was conducted in two parts: in the first part subjects attempted to teach themselves about the software using only the documentation; in the second part, subjects used the software to answer questions such as What brand of cigarette does Watson smoke? The experiment provided a great deal of feedback about the usability of the software and the documentation. Among the results that have wider implications are the need for better display of context, and a need for careful documentation of the characteristics of full text searching.},
journal = {SIGDOC Asterisk J. Comput. Doc.},
month = sep,
pages = {157–166},
numpages = {10}
}

license: Unlicense

repository: goyalkaraniit/acm-cr

repo_name: goyalkaraniit/acm-cr

branch_name: refs/heads/main


text:
DESCRIPTION = "wxWidgets is a cross platform application framework utilizing native widgets."
HOMEPAGE = "http://www.wxwidgets.org"
SECTION = "x11/libs"
LICENSE = "GPL"
DEPENDS = "gtk+"
PR = "r0"

SRC_URI = "${SOURCEFORGE_MIRROR}/wxwindows/wxWidgets-${PV}.tar.gz"
S = "${WORKDIR}/wxWidgets-${PV}"

inherit autotools pkgconfig

do_configure() {
	oe_runconf
}

#FIXME add sane packaging

repository: jdegges/gumstix-pip-oe

repo_name: jdegges/gumstix-pip-oe

extension: bb


text:
require qt5-${PV}.inc
require ${PN}.inc

SRC_URI[md5sum] = "027bc7d05fe740b21284dc909c9f11ac"
SRC_URI[sha256sum] = "eb03a69402576984d588923e994c3cb672d8479ac9b68ed90da15d0c2fd82aac"


text:
DESCRIPTION = "Minimal initramfs init script for initrd flashing"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "\
    file://init-flash.sh \
    file://program-boot-device.sh \
    file://initrd-flash.scheme.in \
"

COMPATIBLE_MACHINE = "(tegra)"

S = "${WORKDIR}"

do_install() {
    install -m 0755 ${WORKDIR}/init-flash.sh ${D}/init
    install -m 0555 -d ${D}/proc ${D}/sys
    install -m 0755 -d ${D}/dev ${D}/mnt ${D}/run ${D}/usr
    install -m 1777 -d ${D}/tmp
    mknod -m 622 ${D}/dev/console c 5 1
    install -d ${D}${bindir}
    install -m 0755 ${WORKDIR}/program-boot-device.sh ${D}${bindir}/program-boot-device
    install -d ${D}${sysconfdir}/initrd-flash
    install -m 0644 ${WORKDIR}/initrd-flash.scheme.in ${D}${sysconfdir}/initrd-flash/
}

FILES:${PN} = "/"
RDEPENDS:${PN} = "util-linux-blkdiscard tegra-flash-reboot mtd-utils e2fsprogs-mke2fs libusbgx-tegra-initrd-flash watchdog-keepalive gptfdisk"
RRECOMMENDS:${PN} = "kernel-module-spi-tegra114 kernel-module-loop"

repository: lfdmn/meta-tegra

repo_name: lfdmn/meta-tegra

gha_license_id: MIT


text:
DESCRIPTION = "The .NET Core runtime and SDK"
HOMEPAGE = "http://dot.net/"
LICENSE = "MIT"
SECTION = "devel"

LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=42b611e7375c06a28601953626ab16cb"

SRC_URI = "https://dotnetcli.blob.core.windows.net/dotnet/Sdk/${PV}/dotnet-sdk-${PV}-linux-x64.tar.gz"
SRC_URI[md5sum] = "07d9d978f8a84684f3adb6c2d5952385"
SRC_URI[sha256sum] = "d33cdcd784ed5503ab66d771cc8d28d5493bc8bbc596e4276db9856453c069e3"

SRC_URI_append_class-native = " file://dotnet-native"

DEPENDS += "patchelf-native jq-native"
RDEPENDS_${PN} = "libicuuc libicui18n libcurl libssl krb5"
RDEPENDS_${PN}_class-native = "icu-native curl-native openssl-native"

S = "${WORKDIR}/dotnet-sdk-${PV}-linux-x64"

python base_do_unpack() {
    src_uri = (d.getVar('SRC_URI') or "").split()
    if len(src_uri) == 0:
        return
    try:
        fetcher = bb.fetch2.Fetch(src_uri, d)
        fetcher.unpack(d.getVar('S'))
    except bb.fetch2.BBFetchException as e:
        bb.fatal(str(e))
}

INSANE_SKIP_${PN} += "already-stripped file-rdeps staticdev libdir"
INSANE_SKIP_${PN}-dbg += "libdir"
INSANE_SKIP_${PN}-dev += "already-stripped file-rdeps staticdev libdir"
SKIP_FILEDEPS_${PN} = '1'
SKIP_FILEDEPS_${PN}-dev = '1'

do_install() {
    # Change the interpreter for all the executables.
    # The onces in the tarball are "/lib64/ld-linux-x86-64.so.2", we need "/lib/ld-linux-x86-64.so.2"
    find -type f -executable -exec sh -c "file -i '{}' | grep -q 'x-executable; charset=binary'" \; -print | xargs -L1 patchelf --set-interpreter /lib/ld-linux-x86-64.so.2

    # Remove libcoreclrtraceptprovider.so
    rm -f ${S}/shared/Microsoft.NETCore.App/2.2.2/libcoreclrtraceptprovider.so
    # Remove the reference to libcoreclrtraceptprovider.so in the deps.json file.
    rm -f ${WORKDIR}/tmp.json
    cat ${S}/shared/Microsoft.NETCore.App/2.2.2/Microsoft.NETCore.App.deps.json | \
      jq 'del(."targets".".NETCoreApp,Version=v2.2/linux-x64"."runtime.linux-x64.Microsoft.NETCore.App/2.2.2"."native"."runtimes/linux-x64/native/libcoreclrtraceptprovider.so")' \
      > ${WORKDIR}/tmp.json
    cp ${WORKDIR}/tmp.json ${S}/shared/Microsoft.NETCore.App/2.2.2/Microsoft.NETCore.App.deps.json

	install -d ${D}${datadir}/dotnet
    cp -av --no-preserve=ownership ${S}/* ${D}${datadir}/dotnet

    install -d ${D}${bindir}
    ln -s ../..${datadir}/dotnet/dotnet ${D}${bindir}/dotnet
}

do_install_append_class-native() {
    # Use our custom dotnet script that unloads psuedo
    rm ${D}${bindir}/dotnet
    cp -av --no-preserve=ownership ${S}/dotnet-native ${D}${bindir}/dotnet
    rm ${D}${datadir}/dotnet/dotnet-native
}

FILES_${PN}-dev += "/usr/share/dotnet/sdk"

BBCLASSEXTEND = "native"

repository: pauldotknopf/meta-dotnet

repo_name: pauldotknopf/meta-dotnet