119 resultados para Programmer
Resumo:
Mode of access: Internet.
Resumo:
National Highway Traffic Safety Administration, Washington, D.C.
Resumo:
National Highway Traffic Safety Administration, Washington, D.C.
Resumo:
Transportation Department, Office of University Research, Washington, D.C.
Resumo:
Mode of access: Internet.
Resumo:
"April 1969."
Resumo:
Includes index.
Resumo:
Includes index.
Resumo:
"This manual supersedes TM 9-1430-495-34P, 28 June 1983"--P. [i]
Resumo:
Includes index.
Resumo:
In New Zealand and Australia, the BRACElet project has been investigating students' acquisition of programming skills in introductory programming courses. The project has explored students' skills in basic syntax, tracing code, understanding code, and writing code, seeking to establish the relationships between these skills. This ITiCSE working group report presents the most recent step in the BRACElet project, which includes replication of earlier analysis using a far broader pool of naturally occurring data, refinement of the SOLO taxonomy in code-explaining questions, extension of the taxonomy to code-writing questions, extension of some earlier studies on students' 'doodling' while answering exam questions, and exploration of a further theoretical basis for work that until now has been primarily empirical.
Resumo:
This paper proposes and describes an architecture that allows the both engineer and programmer for defining and quantifying which peripheral of a microcontroller will be important to the particular project. For each application, it is necessary to use different types of peripherals. In this study, we have verified the possibility for emulating the behavior of peripheral in specifically CPUs. These CPUs hold a RAM memory, where code spaces specifically written for them could represent the behavior of some target peripheral, which are loaded and executed on it. We believed that the proposed architecture will provide larger flexibility in the use of the microcontrolles since this ""dedicated hardware components"" don`t execute to a special function, but it is a hardware capable to self adapt to the needs of each project. This research had as fundament a comparative study of four current microcontrollers. Preliminary tests using VHDL and FPGAs were done.
Resumo:
The refinement calculus is a well-established theory for deriving program code from specifications. Recent research has extended the theory to handle timing requirements, as well as functional ones, and we have developed an interactive programming tool based on these extensions. Through a number of case studies completed using the tool, this paper explains how the tool helps the programmer by supporting the many forms of variables needed in the theory. These include simple state variables as in the untimed calculus, trace variables that model the evolution of properties over time, auxiliary variables that exist only to support formal reasoning, subroutine parameters, and variables shared between parallel processes.
Resumo:
Object-oriented programming languages presently are the dominant paradigm of application development (e. g., Java,. NET). Lately, increasingly more Java applications have long (or very long) execution times and manipulate large amounts of data/information, gaining relevance in fields related with e-Science (with Grid and Cloud computing). Significant examples include Chemistry, Computational Biology and Bio-informatics, with many available Java-based APIs (e. g., Neobio). Often, when the execution of such an application is terminated abruptly because of a failure (regardless of the cause being a hardware of software fault, lack of available resources, etc.), all of its work already performed is simply lost, and when the application is later re-initiated, it has to restart all its work from scratch, wasting resources and time, while also being prone to another failure and may delay its completion with no deadline guarantees. Our proposed solution to address these issues is through incorporating mechanisms for checkpointing and migration in a JVM. These make applications more robust and flexible by being able to move to other nodes, without any intervention from the programmer. This article provides a solution to Java applications with long execution times, by extending a JVM (Jikes research virtual machine) with such mechanisms. Copyright (C) 2011 John Wiley & Sons, Ltd.
Resumo:
Este trabalho teve o intuito de testar a viabilidade da programação offline para tarefas de lixamento na empresa Grohe Portugal. Para tal era necessário perceber o que é a programação offline e para isso foi efectuada uma pesquisa referente a essa temática, onde ficou evidente que a programação offline é em tudo semelhante à programação online, tendo apenas como principal diferença o facto de não usar o robô propriamente dito durante o desenvolvimento do programa. Devido à ausência do robô, a programação offline exige que se conheça detalhadamente a célula de trabalho, bem como todas as entradas e saídas associadas à célula, sendo que o conhecimento das entradas e saídas pode ser contornada carregando um backup do robô ou carregando os módulos de sistema. No entanto os fabricantes habitualmente não fornecem informação detalhada sobre as células de trabalho, o que dificulta o processo de implementação da unidade no modelo 3D para a programação offline. Após este estudo inicial, foi efectuado um estudo das características inerentes a cada uma das células existentes, com o objectivo de se obter uma melhor percepção de toda a envolvente relacionada com as tarefas de lixamento. Ao longo desse estudo efectuaram-se vários testes para validar os diversos programas desenvolvidos, bem como para testar a modelação 3D efectuada. O projecto propriamente dito consistiu no desenvolvimento de programas offline de forma a minimizar o impacto (em especial o tempo de paragem) da programação de novos produtos. Todo o trabalho de programação era até então feito utilizando o robô, o que implicava tempos de paragem que podiam ser superiores a três dias. Com o desenvolvimento dos programas em modo offline conseguiu-se reduzir esse tempo de paragem dos robôs para pouco mais de um turno (8h), existindo apenas a necessidade de efectuar algumas afinações e correcções nos movimentos de entrada, saída e movimentações entre rotinas e unidades, uma vez que estes movimentos são essenciais ao bom acabamento da peça e convém que seja suaves. Para a realização e conclusão deste projecto foram superadas diversas etapas, sendo que as mais relevantes foram: - A correcta modelação 3D da célula, tendo em conta todo o cenário envolvente, para evitar colisões do robô com a célula; - A adaptação da programação offline para uma linguagem mais usual aos afinadores, ou seja, efectuar a programação com targets inline e criar diferentes rotinas para cada uma das partes da peça, facilitando assim a afinação; - A habituação à programação recorrendo apenas ao uso de módulos para transferir os programas para a célula, bem como a utilização de entradas, saídas e algumas rotinas e funcionalidades já existentes.