A crackme is a small computer program designed to test a programmer's reverse engineering skills. Crackmes are made as a legal way to crack software, since no intellectual property is being infringed. == Description == Crackmes often incorporate protection schemes and algorithms similar to those used in proprietary software. However, they can sometimes be more challenging because they may use advanced packing or protection techniques, making the underlying algorithm harder to analyze and modify. == Keygenme == A keygenme is specifically designed for the reverser to not only identify the protection algorithm used in the application but also create a small key generator (keygen) in the programming language of their choice. Most keygenmes, when properly manipulated, can be made self-keygenning. For example, during validation, they might generate the correct key internally and compare it to the user's input. This allows the key generation algorithm to be easily replicated. Anti-debugging and anti-disassembly routines are often used to confuse debuggers or render disassembly output useless. Code obfuscation is also used to further complicate reverse engineering.
Language Server Protocol
The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source-code editors or integrated development environments (IDEs) and servers that provide "language intelligence tools": programming language-specific features like code completion, syntax highlighting and marking of warnings and errors, as well as refactoring routines. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE. In the early 2020s, LSP quickly became a "norm" for language intelligence tools providers. == History == LSP was originally developed for Microsoft Visual Studio Code and is now an open standard. On June 27, 2016, Microsoft announced a collaboration with Red Hat and Codenvy to standardize the protocol's specification. Its specification is hosted and developed on GitHub. == Background == Modern IDEs provide programmers with sophisticated features like code completion, refactoring, navigating to a symbol's definition, syntax highlighting, and error and warning markers. For example, in a text-based programming language, a programmer might want to rename a method read. The programmer could either manually edit the respective source code files and change the appropriate occurrences of the old method name into the new name, or instead use an IDE's refactoring capabilities to make all the necessary changes automatically. To be able to support this style of refactoring, an IDE needs a sophisticated understanding of the programming language that the program's source is written in. A programming tool without such an understanding—for example, one that performs a naive search-and-replace instead—could introduce errors. When renaming a read method, for example, the tool should not replace the partial match in a variable that might be called readyState, nor should it replace the portion of a code comment containing the word "already". Neither should renaming a local variable read, for example, end up altering identically-named variables in other scopes. Conventional compilers or interpreters for a specific programming language are typically unable to provide these language services, because they are written with the goal of either transforming the source code into object code or immediately executing the code. Additionally, language services must be able to handle source code that is not well-formed, e.g. because the programmer is in the middle of editing and has not yet finished typing a statement, procedure, or other construct. Additionally, small changes to a source code file which are done during typing usually change the semantics of the program. In order to provide instant feedback to the user, the editing tool must be able to very quickly evaluate the syntactical and semantical consequences of a specific modification. Compilers and interpreters therefore provide a poor candidate for producing the information needed for an editing tool to consume. Prior to the design and implementation of the Language Server Protocol for the development of Visual Studio Code, most language services were generally tied to a given IDE or other editor. In the absence of the Language Server Protocol, language services are typically implemented by using a tool-specific extension API. Providing the same language service to another editing tool requires effort to adapt the existing code so that the service may target the second editor's extension interfaces. The Language Server Protocol allows for decoupling language services from the editor so that the services may be contained within a general-purpose language server. Any editor can inherit sophisticated support for many different languages by making use of existing language servers. Similarly, a programmer involved with the development of a new programming language can make services for that language available to existing editing tools. Making use of language servers via the Language Server Protocol thus also reduces the burden on vendors of editing tools, because vendors do not need to develop language services of their own for the languages the vendor intends to support, as long as the language servers have already been implemented. The Language Server Protocol also enables the distribution and development of servers contributed by an interested third party, such as end users, without additional involvement by either the vendor of the compiler for the programming language in use or the vendor of the editor to which the language support is being added. LSP is not restricted to programming languages. It can be used for any kind of text-based language, like specifications or domain-specific languages (DSL). == Technical overview == When a user edits one or more source code files using a language server protocol-enabled tool, the tool acts as a client that consumes the language services provided by a language server. The tool may be a text editor or IDE and the language services could be refactoring, code completion, etc. The client informs the server about what the user is doing, e.g., opening a file or inserting a character at a specific text position. The client can also request the server to perform a language service, e.g. to format a specified range in the text document. The server answers a client's request with an appropriate response. For example, the formatting request is answered either by a response that transfers the formatted text to the client or by an error response containing details about the error. The Language Server Protocol defines the messages to be exchanged between client and language server. They are JSON-RPC preceded by headers similar to HTTP. Messages may originate from the server or client. The protocol does not make any provisions about how requests, responses and notifications are transferred between client and server. For example, client and server could be components within the same process exchanging JSON strings via method calls. They could also be different processes on the same or on different machines communicating via network sockets. == Registry == There are lists of LSP-compatible implementations, maintained by the community-driven Langserver.org or Microsoft.
Lisp machine
Lisp machines are general-purpose computers designed to efficiently run Lisp as their main software and programming language, usually via hardware support. They are an example of a high-level language computer architecture. In a sense, they were the first commercial single-user workstations. Despite being modest in number (perhaps 7,000 units total as of 1988) Lisp machines commercially pioneered some now-commonplace technologies, including networking innovations such as Chaosnet, and effective garbage collection. Several firms built and sold Lisp machines in the 1980s: Symbolics (3600, 3640, XL1200, MacIvory, and other models), Lisp Machines Incorporated (LMI Lambda), Texas Instruments (Explorer, MicroExplorer), and Xerox (Interlisp-D workstations). The operating systems were written in Lisp Machine Lisp, Interlisp (Xerox), and later partly in Common Lisp. == History == === Historical context === Artificial intelligence (AI) computer programs of the 1960s and 1970s intrinsically required what was then considered a huge amount of computer power, as measured in processor time and memory space. The power requirements of AI research were exacerbated by the Lisp symbolic programming language, when commercial hardware was designed and optimized for assembly- and Fortran-like programming languages. At first, the cost of such computer hardware meant that it had to be shared among many users. As integrated circuit technology shrank the size and cost of computers in the 1960s and early 1970s, and the memory needs of AI programs began to exceed the address space of the most common research computer, the Digital Equipment Corporation (DEC) PDP-10, researchers considered a new approach: a computer designed specifically to develop and run large artificial intelligence programs, and tailored to the semantics of the Lisp language. To provide consistent performance for interactive programs, these machines would often not be shared, but would be dedicated to a single user at a time. === Initial development === In 1973, Richard Greenblatt and Thomas Knight, programmers at Massachusetts Institute of Technology (MIT) Artificial Intelligence Laboratory (AI Lab), began what would become the MIT Lisp Machine Project when they first began building a computer hardwired to run certain basic Lisp operations, rather than run them in software, in a 24-bit tagged architecture. The machine also did incremental (or Arena) garbage collection. More specifically, since Lisp variables are typed at runtime rather than compile time, a simple addition of two variables could take five times as long on conventional hardware, due to test and branch instructions. Lisp Machines ran the tests in parallel with the more conventional single instruction additions. If the simultaneous tests failed, then the result was discarded and recomputed; this meant in many cases a speed increase by several factors. This simultaneous checking approach was used as well in testing the bounds of arrays when referenced, and other memory management necessities (not merely garbage collection or arrays). Type checking was further improved and automated when the conventional byte word of 32 bits was lengthened to 36 bits for Symbolics 3600-model Lisp machines and eventually to 40 bits or more (usually, the excess bits not accounted for by the following were used for error-correcting codes). The first group of extra bits were used to hold type data, making the machine a tagged architecture, and the remaining bits were used to implement compressed data representation (CDR) coding (wherein the usual linked list elements are compressed to occupy roughly half the space), aiding garbage collection by reportedly an order of magnitude. A further improvement was two microcode instructions which specifically supported Lisp functions, reducing the cost of calling a function to as little as 20 clock cycles, in some Symbolics implementations. The first machine was called the CONS machine (named after the list construction operator cons in Lisp). Often it was affectionately referred to as the Knight machine, perhaps since Knight wrote his master's thesis on the subject; it was extremely well received. It was subsequently improved into a version called CADR (a pun; in Lisp, the cadr function, which returns the second item of a list, is pronounced /ˈkeɪ.dəɹ/ or /ˈkɑ.dəɹ/, as some pronounce the word "cadre") which was based on essentially the same architecture. About 25 of what were essentially prototype CADRs were sold within and without MIT for ~$50,000; it quickly became the favorite machine for hacking – many of the most favored software tools were quickly ported to it (e.g. Emacs was ported from ITS in 1975). It was so well received at an AI conference held at MIT in 1978 that Defense Advanced Research Projects Agency (DARPA) began funding its development. === Commercializing MIT Lisp machine technology === In 1979, Russell Noftsker, being convinced that Lisp machines had a bright commercial future due to the strength of the Lisp language and the enabling factor of hardware acceleration, proposed to Greenblatt that they commercialize the technology. In a counter-intuitive move for an AI Lab hacker, Greenblatt acquiesced, hoping perhaps that he could recreate the informal and productive atmosphere of the Lab in a real business. These ideas and goals were considerably different from those of Noftsker. The two negotiated at length, but neither would compromise. As the proposed firm could succeed only with the full and undivided assistance of the AI Lab hackers as a group, Noftsker and Greenblatt decided that the fate of the enterprise was up to them, and so the choice should be left to the hackers. The ensuing discussions of the choice divided the lab into two factions. In February 1979, matters came to a head. The hackers sided with Noftsker, believing that a commercial venture-fund-backed firm had a better chance of surviving and commercializing Lisp machines than Greenblatt's proposed self-sustaining start-up. Greenblatt lost the battle. It was at this juncture that Symbolics, Noftsker's enterprise, slowly came together. While Noftsker was paying his staff a salary, he had no building or any equipment for the hackers to work on. He bargained with Patrick Winston that, in exchange for allowing Symbolics' staff to keep working out of MIT, Symbolics would let MIT use internally and freely all the software Symbolics developed. A consultant from CDC, who was trying to put together a natural language computer application with a group of West-coast programmers, came to Greenblatt, seeking a Lisp machine for his group to work with, about eight months after the disastrous conference with Noftsker. Greenblatt had decided to start his own rival Lisp machine firm, but he had done nothing. The consultant, Alexander Jacobson, decided that the only way Greenblatt was going to start the firm and build the Lisp machines that Jacobson desperately needed was if Jacobson pushed and otherwise helped Greenblatt launch the firm. Jacobson pulled together business plans, a board, a partner for Greenblatt (one F. Stephen Wyle). The newfound firm was named LISP Machine, Inc. (LMI), and was funded by CDC orders, via Jacobson. Around this time Symbolics (Noftsker's firm) began operating. It had been hindered by Noftsker's promise to give Greenblatt a year's head start, and by severe delays in procuring venture capital. Symbolics still had the major advantage that while 3 or 4 of the AI Lab hackers had gone to work for Greenblatt, 14 other hackers had signed onto Symbolics. Two AI Lab people were not hired by either: Richard Stallman and Marvin Minsky. Stallman, however, blamed Symbolics for the decline of the hacker community that had centered around the AI lab. For two years, from 1982 to the end of 1983, Stallman worked by himself to clone the output of the Symbolics programmers, with the aim of preventing them from gaining a monopoly on the lab's computers. Regardless, after a series of internal battles, Symbolics did get off the ground in 1980/1981, selling the CADR as the LM-2, while Lisp Machines, Inc. sold it as the LMI-CADR. Symbolics did not intend to produce many LM-2s, since the 3600 family of Lisp machines was supposed to ship quickly, but the 3600s were repeatedly delayed, and Symbolics ended up producing ~100 LM-2s, each of which sold for $70,000. Both firms developed second-generation products based on the CADR: the Symbolics 3600 and the LMI-LAMBDA (of which LMI managed to sell ~200). The 3600, which shipped a year late, expanded on the CADR by widening the machine word to 36-bits, expanding the address space to 28-bits, and adding hardware to accelerate certain common functions that were implemented in microcode on the CADR. The LMI-LAMBDA, which came out a year after the 3600, in 1983, was compatible with the CADR (it could run CADR microcode), but hardware differences existed. Texas Instruments (TI) joined the fray whe
Computer Power and Human Reason
Computer Power and Human Reason: From Judgment to Calculation is a 1976 nonfiction book by German-American computer scientist Joseph Weizenbaum in which he contends that while artificial intelligence may be possible, we should never allow computers to make important decisions, as they will always lack human qualities such as compassion and wisdom. == Background == Before writing Computer Power and Human Reason, Weizenbaum had garnered significant attention for creating the ELIZA program, an early milestone in conversational computing. His firsthand observation of people attributing human-like qualities to a simple program prompted him to reflect more deeply on society's readiness to entrust moral and ethical considerations to machines. == Reception and legacy == Computer Power and Human Reason sparked scholarly debate on the acceptable scope of AI applications, particularly in fields where human welfare and ethical considerations are paramount. Early academic reviews highlighted that Weizenbaum's stance pushed readers to recognize that even as computers grow more capable, they lack the intrinsic moral compass and empathy required for certain kinds of judgment. The book caused disagreement with, and separation from, other members of the artificial intelligence research community, a status the author later said he'd come to take pride in.
BRFplus
BRFplus (Business Rule Framework plus) is a business rule management system (BRMS) offered by SAP AG. BRFplus is part of the SAP NetWeaver ABAP stack. Therefore, all SAP applications that are based on SAP NetWeaver can access BRFplus within the boundaries of an SAP system. However, it is also possible to generate web services so that BRFplus rules can also be offered as a service in a SOA landscape, regardless of the software platform used by the service consumers. BRFplus development started as a supporting tool that was part of SAP Business ByDesign, an ERP solution targeted at small and medium size companies. By that time, the tool was called "Formula and Derivation Tool" (FDT). Later on, it was decided to maintain BRFplus on those codelines that serve as the basis for SAP Business Suite. With that, business rules that have been created for Business ByDesign can easily be taken over in a full-size SAP system where they are ready for use without any changes. == Overview == BRFplus offers a unified modeling and runtime environment for business rules that addresses both technical users (programmers, system administrators) as well as business users who take care of operational business processes (like procurement, bidding, tax form validation, etc.). The different requirements and usage scenarios of the different target groups can be covered with the help of the SAP authorization system and a user interface that can be individually customized. Being integrated into SAP NetWeaver, BRFplus-based applications can look at, and model, business rules from a strictly business-oriented perspective, rather than starting with the underlying technical artifacts. This is because the integration allows for direct access to the business objects available in the SAP dictionary (like customer, supplier, material, bill, etc.). In addition to the predefined expression types (decision table, decision tree, formula, database access, loops, etc.) and actions (sending e-mails, triggering a workflow, etc.), BRFplus can be extended by custom expression types. Also, direct calls of function modules as well as ABAP OO class methods are supported so that the entire range of the ABAP programming language is available for solving business tasks. BRFplus comes with an optional versioning mechanism. Versioning can be switched on and off for individual objects as well as for entire applications. Versioned business rules are needed in certain use cases for legal reasons, but they also allow for simulating the system behavior as it would have been at a particular point in time. Once the rule objects are in a consistent state and active, the system automatically generates ABAP OO classes that encapsulate the functional scope of the underlying rule object. This is done on an on-demand base and speeds up processing. The execution of functions as well as of single expressions can be simulated. The processing log of the simulation is useful for checking the implementation and for investigating problems. BRFplus applications can be exported and imported as an XML file. This is an easy way of creating a data backup. XML files can also be used for deploying rule applications throughout the company. == Main object types == === Application === The application object serves as a container for all the BRFplus objects that have been assembled to solve a particular business task. It is possible to define certain default settings on application level that are inherited by all objects that are created in the scope of that application. === Function === A function is used to connect a business application with the rule processing framework of BRFplus. The calling business application passes input values to the function which are then processed by the expressions and rulesets that are associated with the called function. The calculated result is then returned to the calling business application. === Expression types and action types === Boolean BRMS Connector Case Database Lookup Decision Table Decision Tree Formula Function Call Loop Procedure Call Random Number Search Tree Step Sequence Value Range1 XSL Transformation === Ruleset === A ruleset is a container for an arbitrary number of rule objects which in turn carry out the necessary calculations with the help of assigned expressions and actions. Instead of assigning an expression to a function, it is also possible to assign any number of rulesets to a function. When the function is called, all assigned rulesets are subsequently processed. === Data objects === BRFplus supports elementary data objects (text, number, boolean, time point, amount, quantity) as well as structures and tables. Structures can be nested. For all types of data objects it is possible to reference data objects that reside in the data dictionary of the backend system. With that, a BRFplus data object does not only inherit the type definition of the referenced object but can also access associated data like domain value lists or object documentation. === Other objects === With catalogs, it is possible to define business-specific subsets of the rule objects that reside in the system. This is helpful for hiding the complexity of a rule system, thus improving usability. Object filters are used by system administrators to ensure that for selected users, only a predefined subset of object types is visible. This is useful to enforce access rights as well as modeling policies. == Other BRM solutions offered by SAP == BRFplus is positioned as the successor product of an older business rule solution known as BRF (Business Rule Framework). For a longer transition phase, both solutions exist in parallel. However, an increasing number of SAP applications that used to be based on BRF are migrating to BRFplus. While BRFplus supports business rules for applications based on the SAP NetWeaver ABAP stack, SAP is offering another product named SAP NetWeaver Business Rules Management (BRM). BRM supports business rule modeling for the SAP NetWeaver Java stack. Both products do not compete. They are available in parallel and can be used in a collaborative approach to deal with use cases where both technology stacks are used in parallel. BRFplus comes with a special expression type that helps bridging the gap between the two different technologies. == Availability == BRFplus has been delivered to the public with SAP NetWeaver 7.0 Enhancement Package 1 for the first time. Being part of SAP NetWeaver, the usage of BRFplus is covered by the "SAP NetWeaver Foundation for Third Party Applications" license, with no additional costs. == Literature == Carsten Ziegler, Thomas Albrecht: BRFplus – Business Rule Management for ABAP Applications. Galileo Press 2011. ISBN 978-1-59229-293-6
Instance selection
Instance selection (or dataset reduction, or dataset condensation) is an important data pre-processing step that can be applied in many machine learning (or data mining) tasks. Approaches for instance selection can be applied for reducing the original dataset to a manageable volume, leading to a reduction of the computational resources that are necessary for performing the learning process. Algorithms of instance selection can also be applied for removing noisy instances, before applying learning algorithms. This step can improve the accuracy in classification problems. Algorithm for instance selection should identify a subset of the total available data to achieve the original purpose of the data mining (or machine learning) application as if the whole data had been used. Considering this, the optimal outcome of IS would be the minimum data subset that can accomplish the same task with no performance loss, in comparison with the performance achieved when the task is performed using the whole available data. Therefore, every instance selection strategy should deal with a trade-off between the reduction rate of the dataset and the classification quality. == Instance selection algorithms == The literature provides several different algorithms for instance selection. They can be distinguished from each other according to several different criteria. Considering this, instance selection algorithms can be grouped in two main classes, according to what instances they select: algorithms that preserve the instances at the boundaries of classes and algorithms that preserve the internal instances of the classes. Within the category of algorithms that select instances at the boundaries it is possible to cite DROP3, ICF and LSBo. On the other hand, within the category of algorithms that select internal instances, it is possible to mention ENN and LSSm. In general, algorithm such as ENN and LSSm are used for removing harmful (noisy) instances from the dataset. They do not reduce the data as the algorithms that select border instances, but they remove instances at the boundaries that have a negative impact on the data mining task. They can be used by other instance selection algorithms, as a filtering step. For example, the ENN algorithm is used by DROP3 as the first step, and the LSSm algorithm is used by LSBo. There is also another group of algorithms that adopt different selection criteria. For example, the algorithms LDIS, CDIS and XLDIS select the densest instances in a given arbitrary neighborhood. The selected instances can include both, border and internal instances. The LDIS and CDIS algorithms are very simple and select subsets that are very representative of the original dataset. Besides that, since they search by the representative instances in each class separately, they are faster (in terms of time complexity and effective running time) than other algorithms, such as DROP3 and ICF. Besides that, there is a third category of algorithms that, instead of selecting actual instances of the dataset, select prototypes (that can be synthetic instances). In this category it is possible to include PSSA, PSDSP and PSSP. The three algorithms adopt the notion of spatial partition (a hyperrectangle) for identifying similar instances and extract prototypes for each set of similar instances. In general, these approaches can also be modified for selecting actual instances of the datasets. The algorithm ISDSP adopts a similar approach for selecting actual instances (instead of prototypes).
DAYDREAMER
DAYDREAMER is a goal-based agent and cognitive architecture developed at the University of California, Los Angeles by Erik T. Mueller and Michael G. Dyer beginning in 1983. The system models the human stream of thought and how it is triggered and directed by emotions, simulating human daydreaming. Taking situational descriptions as input, DAYDREAMER produces English-language daydreams as output and encodes new daydreams, plans, and planning strategies for later reuse. The program comprises five components: a scenario generator based on relaxed planning, a dynamic episodic memory, a collection of personal goals and control goals, an emotion component, and domain knowledge of interpersonal relations and everyday occurrences. The source code was released under a free software license in 2015. == History == Erik Mueller began DAYDREAMER in 1983 while he was a doctoral student in the Artificial Intelligence Laboratory of the Computer Science Department at the University of California, Los Angeles, studying under Michael G. Dyer. Initial development of the project was supported by a grant from the W. M. Keck Foundation with matching funds from the UCLA School of Engineering and Applied Sciences. Additionally, Mueller was supported by an Atlantic Richfield Doctoral Fellowship and Dyer by an IBM Faculty Development Award. The first published descriptions of the program appeared in 1985 at the Ninth International Joint Conference on Artificial Intelligence in Los Angeles and at the Seventh Annual Conference of the Cognitive Science Society in Irvine. Work on the program continued, and a book, Daydreaming in Humans and Machines, was published by Ablex Publishing in 1990. The program was implemented on top of GATE, a knowledge-representation and inference substrate developed by Mueller and Uri Zernik at UCLA, and was originally written in T, a dialect of Scheme. In 2015, Mueller released the DAYDREAMER source code, version 3.5, a Common Lisp rewrite of the original T implementation, on GitHub under the GNU General Public License version 2. The release comprised approximately 12,000 lines of Common Lisp code, along with the GATE knowledge-representation substrate on which DAYDREAMER had originally been built. == Architecture == The program operates in two modes. In daydreaming mode it daydreams continuously until interrupted, while performance mode allows it to demonstrate behavior it has learned through daydreaming. === Emotion and control goals === Emotions and daydreaming form a feedback loop for DAYDREAMER. Emotions activate goals that produce daydreams, and the resulting daydreams modify existing emotions and trigger new ones, which prompt subsequent daydreaming. Recall of a goal success produces a positive emotion whereas recall of a goal failure produces a negative emotion. Emotions activate a set of goals, called control goals, which direct the course of a daydream. The program has four control goals. "Rationalization" generates reasons why an unsatisfactory outcome is in fact acceptable, in order to reduce a negative emotion and maintain self-esteem. "Revenge" is activated by anger when a failure is caused by another and reduces negative emotion through imagined retaliation. "Failure/success reversal" imagines alternative scenarios in which a failure was prevented or a success did not occur as a means of learning planning strategies for future situations. "Preparation" generates hypothetical future scenarios in order to rehearse plans and actions for events that have not yet occurred. === Scenario generator and relaxed planning === The scenario generator produces the sequence of events that make up a daydream. It operates under multiple, often conflicting personal goals rather than pursuing a single goal, applies relaxation rules that permit the generation of non-realistic scenarios, and it draws on episodic memory of past experiences both as subject matter and as a source of planning knowledge. The personal goals that guide the scenario generator include health, food, sex, friendship, love, possessions, self-esteem, social esteem, enjoyment, and achievement. These goals are organized into a goal tree that specifies their relative importance at any given time. Relaxation rules allow the program to set aside its ordinary constraints when generating a scenario. The four constraints that may be relaxed are the behavior of others, the daydreamer's own attributes, physical constraints, and social constraints. The degree of relaxation varies with the active control goal. For example a failure-reversal goal aimed at alternatives uses a low level of relaxation, whereas a revenge goal aimed at a retaliation uses a high level. === Episodic memory and analogy === DAYDREAMER's episodic memory stores its personal and vicarious experiences along with the daydreams it generates. The memory is described as dynamic because it is continually modified during daydreaming such that previously daydreamed episodes become available alongside real ones. As it daydreams, the program indexes daydreams, future plans or actions, and planning strategies into memory. Episodes are organized and retrieved using surface-level similarities, emotions, abstract themes, and Plot Units which are abstract configurations of positive and negative outcomes developed by Wendy Lehnert. A recalled episode is adapted to the current situation through analogy, which requires less effort than generating an equivalent scenario from scratch. == Sample output == In the sample experience from the source code, called LOVERS1, DAYDREAMER begins from an initial situation in which it has a job, is not romantically involved, and is at home. Starting in daydreaming mode, it activates a top-level goal to be in a romantic relationship because it is not currently in one, and a positive motivating emotion of interest becomes associated with that goal. The program then activates a goal to be entertained and pursues seeing a film as a way to achieve it. Facts asserted into memory are converted to English and produced as output, such as "I want to be going out with someone" and "I have to go see a movie". == Reception and influence == DAYDREAMER has been cited in research on computational models of creativity, emotion, and narrative. Linda Wills and Janet Kolodner cite the program as an example of work on opportunism in their study of serendipitous recognition in design. Joseph Bates, A. Bryan Loyall, and W. Scott Reilly of the Carnegie Mellon Oz Project cite DAYDREAMER among prior work in their description of an architecture combining action, emotion, and social behavior. Rafael Pérez y Pérez, Ricardo Sosa, and Christian Lemaitre cite Mueller's DAYDREAMER as one of the few computer models at the time to model daydreaming during the creative process. Jichen Zhu and D. Fox Harrell likewise cite the program in their work on imagining and agency in generative interactive narrative.