text:
---
title: Service Components
summary: The Trees and Forests of Declarative Services
layout: tutorial
lprev: 216-design.html
lnext: 218-patterns.html
---

Components are created using _Declarative Services_ (DS) using annotations. In Declarative Services there is a rather large number of different mechanisms at work:

* PID
* Component service properties
* Default configuration
* Component Service Properties
* Factory configuration
* Mandatory configuration
* Singleton configuration
* PIDs are Public API
* Management Agent
* Metatypes
* Component Factory
* Targets, or how to Wire Services

This section attempts to explain how Declarative Services should be used without getting lost.

## Trees & Forest

The OSGi specifications are very cohesive and decoupled. Though this provides numerous benefits it clearly makes it hard for newcomers to see how the different parts interact. More importantly, how should you actually use them together?

The best advice is to start very simple and use defaults. This basically means the skeleton of your component is:

	package com.acme;
	@Component
	public class Foo implements Bar {

		@Reference
		EventAdmin eventAdmin;

		@Reference
		final List<Foo> foo = new CopyOnWriteArrayList<>();

		@interface Config {
			int port();
		}

		@Activate void activate( Config config ) {
		}

		@Deactivate void close() {
		}
	}

This gives you a static component that can be be fully configured through the `com.acme.Foo` PID with Configuration Admin whatever _Management Agent_ you pick.

	service.pid	: com.acme.Foo
	port		: 8080

If you use bndtools, use the osgi.enroute.configurer.simple.provider bundle. This allows you to specify the configuration data in JSON in a bundle in the `configuration/configuration.json` resource. The best practice is to create one ‘application’ project that only holds configuration data and no code. This application project pulls together the components that are used in a specific application and configures them. The OSGi enRoute templates create such a setup automatically.

If you run into a problem with this basic model (though realize that 95% of the components can get away with these defaults) that does not seem to have a simple solution then first try to see if you redefine the problem to fit the simple model. (Yes, numerous times people define the problem in terms of a specific solution and not of actual requirements. Taking a step back and trying to see what is really required can make a surprising difference.)

If that does not work, ask on a mailing list. Declarative Services are so widely used that is extremely unlikely there is no solution to your actual requirements.

## The PID

The core idea is the PID: an identifier that identifies the configuration for the a component _type_. For example, the following component has a PID of `com.acme.FooImpl`:

	package com.acme;

	@Component
	public class FooImpl { }

## Default Configuration

Let’s forget Configuration Admin for a moment. If you run this component without any configuration then the component will be started since by default it can live without configuration.

## Component Service Properties

If you want to create a service property to be registered (and provided to the `activate` method) then you can provide such a property in the @Component annotation:

	@Component(
		property=“foo=bar”
	)
	public class Foo {
		@Activate void activate( Map<String,Object> map) {
			assert “bar”.equals(map.get(“foo”));
		}
	}

## Configuration Properties Suck

Properties suck but are often a necessary evil. They do not refactor easily, are error prone in their spelling, require messy conversions to their desired Java types, require casting, and in general look awful in your code with their YELLING UPPER CASE (assuming you turn the keys into constants). How nice would it be if you could just use type safe constructs?

Well, you can. In the previous examples we used a `Map<String,Object>` to get the service properties in the `activate` method. However, we can also replace this map with any annotation type:

	@interface Config {
		String foo() default “bar”;
	}

	@Activate void activate( Foo.Config config ) {
		assert “bar”equals( config.foo() );
	}

## Factory Configuration

In most cases it makes sense to be able to create multiple instances of a component. For example, you are polling a host for some information in your application. It is common that you want the final application to be able to poll different hosts and not just one. Even if you want it to be just one, it is bad practice to choose a singleton configuration if it is theoretically possible that one day you need two or more.

This is where Configuration Admin comes in. Let’s ignore how we manage Configuration Admin but assume that there are two factory configurations for the ‘com.acme.Foo’ Factory PID:

	service.pid		:	com.acme.Foo-126121312-12112
	service.factoryPid	:	com.acme.Foo
	foo			:	one

	service.pid		:	com.acme.Foo-456781232-83622
	service.factoryPid	:	com.acme.Foo
	foo			:	two

With this configuration the `com.acme.Foo` component will be instantiated twice. One component will get foo=one and the other will get foo=two

	@Activate void activate( Foo.Config config) {
		String foo = config.foo();
		assert “one”.equals(foo) || “two”.equals(foo);
	}

## Singleton Configuration

There are cases where a singleton configuration is necessary. If it is logically impossible to have more than one instance then a singleton configuration should be used. However, these cases are more rare than most developers realize. For example, the Apache Felix jetty configuration is a singleton configuration but should likely have been a factory configuration because it is possible to have multiple web servers on different ports. This would have simplified the configuration and made it more flexible.

Assume that there is a singleton Configuration for the ‘com.acme.Foo’ PID:

	service.pid	:	com.acme.Foo
	foo		:	singleton

If we now run our system, the activate method gets called with `foo=singleton`

	@Activate void activate( Foo.Config config) {
		assert “singleton”.equals( config.foo() );
	}

## Mandatory Configuration

Maybe you’ve noticed, but factories now have a rather strange life cycle. If there is no configuration for the given PID, then the component gets instantiated once with the service properties defined in the @Component annotation. If you then create a factory configuration for that PID, the default component is deleted and the factory configuration is used to instantiate a new component. The consequence of this is that you cannot have zero components, there will always be at least one. Though a default instance is sometimes handy, in general it does not make sense. In that case you can make the configuration mandatory: only if the configuration is set (either singleton or factory) will the component be instantiated.

	@Component(
		configurationPolicy = ConfigurationPolicy.MANDATORY
	)

With a mandatory configuration the component is only instantiated when there is a Configuration for the corresponding PID. The following table shows how the configuration interacts with this policy:

				Mandatory	Optional	Ignore
	no config		no instance	default		default
	singleton config	1 instance      1 instance      default
	one factory config      1 instance      1 instance      default
	two factory config      2 instances     2 instances     default

## PIDs are Public API

PIDs are public API since external parties will be aware of them when they configure your component. For this reason it is sometimes better to create a name that can be kept constant over time even if implementations change.

	@Component( name = “com.acme.foo” )
	public class FooImpl { }

## Management Agent

The previous section should make it clear how the instances of a component can be controlled through the configurations associated with the component’s PID. Components follow Configuration Admin and, except for some default service properties, should never ever try to configure themselves. Things are a lot simpler if components just do what they are being told by Configuration Admin!

However, that leaves the question: Who sets the Configurations for a given PID? This role is in general fulfilled by the _management agent_. This is not magic entity in OSGi, it is just one or more bundles that perform the role of managing the framework. One of it is roles is to configure the components. This is not a single solution. On the contrary, there are lots of viable solutions. The following lists describes a list of popular management agents:

* FileInstall – Watches a directory and synchronizes any configuration in that directory to Configuration Admin. File Install allows you to manage singleton and factory configurations just by adding/removing/changing a file in a directory. In a cluster, a directory can be shared (even over for example Dropbox). Very convenient.
* Web Console – Apache Felix Web Console is a Web based tool that allows you manage configurations. The Web Console is excellent during debugging and small systems because it is very interactive.
* Configurer – The OSGi enRoute configurer reads JSON resources from active bundles and installs them as configurations. The Configurer is very suitable for production since it delivers configuration as a bundle, just as code bundles.
* Deployment Admin – Provides a means to deliver configuration through Deployment Packages and a Resource Processor. I think Apache Ace uses this.

Of course there is always the option to write your own management agent. The Configuration Admin API is quite flexible though be aware of some of the quirks (locations!). However, postponing the decision to handle your own configuration until there is no alternative and you’ve also become quite experienced is the recommended (in)action.

## Metatype

Using the annotation types significantly cleaned up our code. However, with File Install, Configurer, and Web Console we’re still having to use properties. Since properties are evil, we’d like to have a more elegant solution. This elegant solution is called _metatype_. It is an OSGi service that enables components to describe their configuration types. User agents can then use a metatype to automatically create a form for that configuration. Apache Felix Web Console fully supports metatypes in its web based user interface.

So how do we link our annotation type to a metatype? Though the metatypes are defined in XML there are fortunately (build) annotations for it.

	@ObjectClassDefinition
	@interface Config {
		@AttributeDefinition
		String foo();
	}

	@Designate( ocd = Config.class, factory=true )
	@Component
	public class Foo {}

The` @ObjectClassDefinition` and `@AttributeDefinition` can describe the ‘properties’ and provide additional information to control the user interface. The `@Designate` annotation links a configuration type (or as we call it: an Object Class Definition or ocd) to a component’s PID. This will create the proper XML for the Metatype service to link it all together.

## Targets, or how to Wire Services

Services are linked to each other by their object classes. I.e. one component requires an instance of the Foo service type. You create that dependency with the `@Reference` annotation. A `@Component` annotated type can then register this service. However, sometimes you cannot avoid but make the _wiring_ of the services more complicated. Sometimes you really need to ensure that a component Bar is really wired to a specific instance of Foo.

This can be done with the `target` field in the `@Reference` annotation.

	@Reference( target=“(foo=bar)” )
	Foo foo;

A component Foo can then register its service with a number of properties under Configuration Admin control.

	@Component public class FooImpl implements Foo {
	}

Another component can depend on this property.

	@Component public class Bar {
		@Reference( target=“(foo=bar)” )
		Foo foo;
	}

We can now create a configuration for FooImpl

	service.pid		:	com.acme.FooImpl-131231412-15322
	service.factoryPid	:	com.acme.FooImpl
	foo			:	‘bar’

This will create an instance of the `Foo` service with a service property ‘foo=bar’. The Bar service has a dependency on this service so it will be wired to it.

Obviously this is not symmetric. We need to know the name of the service property ahead of time in the Bar service. It is therefore possible to set the target field of the `@Reference` annotation with configuration admin:

	service.pid		:	com.acme.Bar
	foo.target		:	‘(foo=bar)’

## Component Factory

This part barely made it in the spec and in general it is not advised to use it except when you really know what you’re doing.

branch_name: refs/heads/gh-pages


text:
# intellijasyncdebug-reactor
exploring the async stacktrace feature of IntelliJ with Reactor

## `PublishOnTest`
Attempts at defining async stacktraces for scheduling is a bit too complicated, due to the number of possible execution model combinations.

egor from JetBrains offered this configuration, to be explored again:

```xml
<capture-points>
  <capture-point enabled="false" class-name="reactor.core.scheduler.Scheduler$Worker" method-name="schedule" capture-key-expression="param_0" insert-class-name="reactor.core.scheduler.WorkerTask" insert-method-name="call" insert-key-expression="task" />
</capture-points>
```

## `*DebuggingExample`
Async stacktraces may help during debugging when `Hooks.operatorDebugMode()` is activated.

These 2 configurations help by shortcircuiting the whole detail of the stacktrace back to the **assembly** point instead of the _subscription_ point :tada:

```xml
<capture-points>
  <capture-point enabled="false" class-name="reactor.core.publisher.Flux" method-name="onAssembly" capture-key-expression="param_0" insert-class-name="reactor.core.publisher.Flux" insert-method-name="subscribe" insert-key-expression="this" />
  <capture-point enabled="false" class-name="reactor.core.publisher.FluxOnAssembly" method-name="<init>" capture-key-expression="this" insert-class-name="reactor.core.publisher.FluxOnAssembly" insert-method-name="subscribe" insert-key-expression="param_1" />
</capture-points>
```

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# url-shortener
Simple service executes change the full url to little url.

## How Run ?

## Running the Server
1. Ensure you have MongoDB installed and running
2. Open a command line window and navigate to the "/server" folder below the project root folder
3. Run ``npm install or yarn install`` to install all required npm packages that are defined in the package.json file
4. Run node server.js to start the server, by default it runs at http://localhost:8000

## Running the Client
1. Open a command line window and navigate to the "/client" folder below the project root folder.
2. Run ``npm install or yarn install`` to install all required npm packages that are defined in the package.json file
3. See README.MD in the "/client" folder, how run the client side of the service.

## Running unit-tests the Server
1. Open a command line window and navigate to the "/server" folder below the project root folder
2. Run ``npm install or yarn install`` to install all required npm packages that are defined in the package.json file
3. Write in command line `npm run test`.

## Review coverage of unit-tests the Server
1. If you want to see coverage you write in command line `npm run test-coverage`.

license: MIT

repository: AlexeyKorkoza/url-shortener-mean-stack

repo_name: AlexeyKorkoza/url-shortener-mean-stack


text:
---
layout: page-breadcrumbs.html
title: Standard Disability Claims
display_title: Standard Claims
plainlanguage:
template: detail-page
order: 3
relatedlinks:
  - heading:
    links:
    - url:
      title:
      description:
aliases:
  - /disability-benefits/apply/evidence/standard-disability-claims/
---

Find out how to submit a standard disability claim if you’d like us to take more responsibility for gathering the evidence (supporting documents) we need to make a decision on your claim.

What do I need to do to submit a standard disability claim?

**You’ll need to:**
- Submit your completed Application for Disability Compensation and Related Compensation Benefits (VA Form 21-526EZ), **and**
- Let us know about related records not held by a federal agency, and give us any information we may need in order to get them, **and**
- Go to any medical exams that we schedule, if we decide these exams are needed to make a decision on your claim

**Note:** You should know that if a person or agency refuses to turn over the evidence we need, asks for money for the evidence, or can’t get the evidence, we’ll ask you to try to get it for us. It’s your responsibility to make sure we receive all requested records that aren’t at a federal agency or office.

What kinds of records might VA need that aren’t held by a federal agency?

**We need any records related to your claim from sources like these:**
  - State or local governments
  - Any private (non-VA) doctors who’ve treated you
  - Any private (non-VA) hospitals or other health facilities where you've been treated
  - Your current or former employers

### What evidence will VA take responsibility for gathering when I submit a standard disability claim?

**With your permission, we’ll get related records from:**
- Any federal agency (including the military)
- VA medical centers (including private facilities where we’ve authorized treatment)
- The Social Security Administration

**We’ll also:**
- Make every reasonable effort to request relevant records that you authorize us to get that aren’t at a federal facility (including records from non-VA doctors and hospitals), **and**
- Provide a medical exam for you, or get a doctor’s opinion if we need it to make a decision on your claim

**Example**

A Veteran filed a disability claim that included prior treatment from a private doctor and a prior Social Security disability award. In this case, we were responsible for getting the Social Security records. We also helped to get the private doctor’s records, but the Veteran was responsible for making sure we got those.

### When do I need to turn in my evidence to support my standard claim?

You’ll need to turn in the information and evidence as soon as you can.

You have up to 1 year from the date we receive your claim to turn in any information and evidence. If we decide your claim before this, you’ll have the rest of the one-year period to turn in more information or evidence to support your claim.

### How do I get started filing my standard claim?

You can start your online application right now, or find out how to apply by mail, in person, or with the help of a trained professional.

[Find out how to file a disability claim](/disability/how-to-file-claim/).

### Does it take longer to get a decision from VA on a standard claim than a fully developed claim?

Yes. The process is slower for getting a decision on a standard disability claim. This is because we need time to gather evidence for your claim.

If you'd like to get a decision on your claim faster, you can submit a fully developed claim. For this type of claim, you gather all of the evidence—or as much as you can get easily—and submit it at the same time as your claim.

[Learn more about submitting a fully developed disability claim](/disability/how-to-file-claim/evidence-needed/fully-developed-claims/).

For certain types of claims, you can work with an accredited Veterans Service Organization (VSO) to submit a decision-ready claim and get a decision within 30 days or less from when you file your claim.

[Learn more about submitting a decision-ready disability claim](/disability/how-to-file-claim/evidence-needed/decision-ready-claims/).

repository: jennilynhowell/vets-website

repo_name: jennilynhowell/vets-website


text:
# Analysis of food-conditioned phenotypic plasticity in echinoid larvae

## Introduction
This code was used to analyze data from a series of experiments on the expression of phenotypic plasticity in the larvae of two echinoid species. These experiments were part of a study that is described in Nilsson & Pernet (2022).

This code can be used to generate the figures and tables that appear in the article (less a few formatting details).

To see the most recent version - which may be updated to reflect URLs not known at the time this document was written - visit the [github page](https://github.com/PeterNilssonBio/NilssonPernet2022).

## Setup
To run this script, you need...
1. The [R language](https://www.r-project.org/) (version ≥ 4.1), along with the following R packages and their dependencies:
  [config](https://cran.r-project.org/web/packages/config/index.html),
  [emmeans](https://cran.r-project.org/web/packages/emmeans/index.html),
  [ggpubr](https://cran.r-project.org/web/packages/ggpubr/index.html),
  [kableExtra](https://cran.r-project.org/web/packages/kableExtra/index.html),
  [lmerTest](https://cran.r-project.org/web/packages/lmerTest/index.html),
  [multcomp](https://cran.r-project.org/web/packages/multcomp/index.html),
  [reticulate](https://cran.r-project.org/web/packages/reticulate/index.html),
  [rstatix](https://cran.r-project.org/web/packages/rstatix/index.html), and
  [tidyverse](https://cran.r-project.org/web/packages/tidyverse/index.html).

  2. [Python](https://www.python.org/downloads/) (version ≥ 3.8), along with the [Beautiful Soup 4](https://pypi.org/project/beautifulsoup4/) package.

  3. The two data files, which are stored in the Biological & Chemical Oceanography Data Management Office database as part of an NSF-funded [project](https://www.bco-dmo.org/project/727167). At the time of writing, the URLs at which this data will be located are not known, but the script will attempt to download them automatically. Should that fail, simply obtain the data files and place them in a subdirectory named `data` like this:
        ```
        NilssonPernet2022/
        ├── data/
        │   ├── density_morphometrics.csv <- Add this!
        │   └── density_counts.csv        <- Add this too!
        ├── main.R
        └── (various other files and directories...)
        ```

If you find some dependencies are missing, you can try running the `install_dependencies()` function in `code/setup.R`, which will attempt to download and install everything for you. I haven't really tested this; it is just for the convenience of anyone trying to run this script.

## Usage
Once everything is set up, simply source the file `main.R` in the R interpreter:

```r
source("main.R")
```

This should generate HTML output files for each of seven tables (Tables 1-2, S1-S5) and SVG output files for each of five figures (Figures 2-5, S1). It will also generate an HTML output file containing a small table of data on count control larvae, which is summarized in prose in the paper. You can customize the output by editing the `config.yml` file. Note that there is no output for Figure 1 because that figure is simply an illustration and is not generated from the data.

Output files are put in a directory named `output`:
```
NilssonPernet2022/
├── output/
│   ├── Fig_2.svg
│   ├── Fig_3.svg
│   └── (various other output files...)
├── main.R
└── (various other files and directories...)
```

## References
Nilsson P, Pernet B (2022) Echinoid larvae can express food-conditioned morphological plasticity at ecologically relevant culture densities. Marine Ecology Progress Series 694 (in press).

branch_name: refs/heads/main


text:
# Get started with driver development

This guide provides step-by-step instructions that walk you through the basic
workflows of building, running, debugging, and updating
[drivers][driver-concepts] in a Fuchsia system using the
[Fuchsia SDK][using-the-sdk].

Important: This guide is the driver equivalent of the
[_Get started with the Fuchsia SDK_][get-started-sdk] guide. If you haven't
already, it's strongly recommended that you first complete the _Get started
with the Fuchsia SDK_ guide to become familiar with the comprehensive set of
Fuchsia SDK-based workflows.

Complete the following sections:

1. [Prerequisites](#prerequisites).
2. [Clone the SDK driver samples repository](#clone-the-sdk-driver-samples-repository).
3. [Start the emulator](#start-the-emulator).
4. [Build and load the sample driver](#build-and-load-the-sample-driver).
5. [Build and run a tool](#build-and-run-a-tool).
6. [Debug the sample driver](#debug-the-sample-driver).
7. [Modify and reload the sample driver](#modify-and-reload-the-sample-driver).

Found an issue? Please [let us know][sdk-bug]{:.external}.

## 1. Prerequisites {:#prerequisites}

This guide requires that your host machine meets the following criteria:

*  An x64-based development machine running Linux or macOS.
*  Has at least 15 GB of storage space.
*  Supports [KVM][kvm]{:.external} (Kernel Virtual Machine) for running a
   [QEMU][qemu]{:.external}-based emulator.
*  IPv6 is enabled.
*  [Git][git-install]{:.external} is installed.

## 2. Clone the SDK driver samples repository {:#clone-the-sdk-driver-samples-repository}

Clone the [SDK driver samples repository][sdk-driver-sample-repo]{:.external}
on your host machine. This repository contains sample driver components and the
Bazel-based Fuchsia SDK.

The tasks include:

*   Bootstrap the SDK driver samples repository.
*   Verify that you can build the sample driver components and run `ffx`
    commands.

Do the following:

1. In a terminal, change to your home directory:

   Note: This guide uses the home directory (`$HOME`) as a base directory. This
   is where a new work directory (`drivers`) will be created for this guide. You
   may also select a different base directory (for instance,
   `cd $HOME/my-fuchsia-project`).

   ```posix-terminal
   cd $HOME
   ```

1. Clone the SDK driver samples repository:

   ```posix-terminal
   git clone https://fuchsia.googlesource.com/sdk-samples/drivers fuchsia-drivers --recurse-submodules
   ```

   This `git clone` command creates a new directory named `fuchsia-drivers` (see the
   command's second argument above) and clones the content of the SDK driver samples
   repository.

1. Go to the new directory:

   ```posix-terminal
   cd fuchsia-drivers
   ```

1. Run the bootstrap script to install Bazel and other required dependencies:

   ```posix-terminal
   scripts/bootstrap.sh
   ```

1. To verify the Fuchsia SDK environment setup, build the sample drivers:

   ```posix-terminal
   tools/bazel build --config=fuchsia_x64 //src/qemu_edu/drivers:qemu_edu
   ```

   The first build may take a few minutes to download dependencies, such as
   Bazel build rules, [Clang][clang], and [Fuchsia IDK][fuchsia-idk] (which
   includes the `ffx` tool).

   When finished successfully, it prints output similar to the following in the
   end:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel build --config=fuchsia_x64 //src/qemu_edu/drivers:qemu_edu
   ...
   INFO: Elapsed time: 246.794s, Critical Path: 49.78s
   INFO: 971 processes: 597 internal, 374 linux-sandbox.
   INFO: Build completed successfully, 971 total actions
   ```

5. To verify that you can use the `ffx` tool in your environment, run the
   following command:

   ```posix-terminal
   tools/ffx sdk version
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx sdk version
   9.20220919.2.1
   ```

   At this point, you only need to confirm that you can run `ffx` commands
   without error. (However for your information, the output above shows the version
   `9.20220919.2.1`, which indicates that this SDK was built and published on
   September 19, 2022.)

   Note: To ensure that you’re using the right version of `ffx` during development,
   consider updating your `PATH` to include the SDK's `tools` directory
   (for instance, `export PATH="$PATH:$HOME/fuchsia-drivers/tools"`). However,
   if you don't wish to update your `PATH`, ensure that you specify the relative path to
   this `ffx` tool (`tools/ffx`) whenever you run `ffx` commands.

## 3. Start the emulator {:#start-the-emulator}

Start the [Fuchsia emulator][femu] on the host machine while configuring the
emulator instance to use Fuchsia’s new [driver framework][driver-framework]
(DFv2).

The tasks include:

*   Download Fuchsia's Workstation prebuilt image from Google Cloud Storage.
*   Start the Fuchsia emulator.
*   Set the emulator instance as your host machine’s default target device.
*   Start the Fuchsia package server.
*   Register the system package repository to the emulator instance.

Do the following:

1. Download the latest Workstation image for the emulator:

   ```posix-terminal
   tools/ffx product-bundle get workstation_eng.qemu-x64 --repository workstation-packages
   ```

   This command may take a few minutes to download the image and product
   metadata.

   Note: If the `product-bundle` command fails with an error due to multiple product bundle
   instances or SDK versions, [clean up the environment](#clean-up-the-environment) before
   proceeding.

   Once the download is finished, the `ffx product-bundle get` command creates
   a local Fuchsia package repository named `workstation-packages` on your host machine.
   This package repository hosts additional system packages for this Workstation prebuilt image.
   Later in Step 8 you’ll register this package repository to the emulator instance.

1. Stop all emulator instances:

   ```posix-terminal
   tools/ffx emu stop --all
   ```

1. Start the Fuchsia emulator:

   ```posix-terminal
   tools/ffx emu start workstation_eng.qemu-x64 --headless \
     --kernel-args "driver_manager.use_driver_framework_v2=true" \
     --kernel-args "driver_manager.root-driver=fuchsia-boot:///#meta/platform-bus.cm" \
     --kernel-args "devmgr.enable-ephemeral=true"
   ```

   This command starts a headless emulator instance running the Workstation prebuilt image.

   When the instance is up and running, the command prints output similar to
   the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx emu start workstation_eng.qemu-x64 --headless \
     --kernel-args "driver_manager.use_driver_framework_v2=true" \
     --kernel-args "driver_manager.root-driver=fuchsia-boot:///#meta/platform-bus.cm" \
     --kernel-args "devmgr.enable-ephemeral=true"
   Creating SSH key pair: /home/alice/.ssh/fuchsia_ed25519
   Writing authorized_keys file: /home/alice/.ssh/fuchsia_authorized_keys
   Logging to "/home/alice/.local/share/Fuchsia/ffx/emu/instances/fuchsia-emulator/emulator.log"
   Waiting for Fuchsia to start (up to 60 seconds).
   Emulator is ready.
   ```

1. Verify that the new emulator instance is running:

   ```posix-terminal
   tools/ffx emu list
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx emu list
   [Active]  fuchsia-emulator
   ```

1. Set the default target device:

   ```posix-terminal
   tools/ffx target default set fuchsia-emulator
   ```

   This command exits silently without output.

1. Start the Fuchsia package server:

   ```posix-terminal
   tools/ffx repository server start
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx repository server start
   ffx repository server is listening on [::]:8083
   ```

1. Check the list of Fuchsia package repositories available on
   your host machine:

   ```posix-terminal
   tools/ffx repository list
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx repository list
   +-----------------------+------+-------------------------------------------------------------------------------------------------+
   | NAME                  | TYPE | EXTRA                                                                                |
   +=======================+======+=================================================================================================+
   | workstation-packages* | pm   | /home/alice/.local/share/Fuchsia/ffx/pbms/4751486831982119909/workstation_eng.qemu-x64/packages |
   +-----------------------+------+-------------------------------------------------------------------------------------------------+
   ```

   Notice a package repository (`workstation-packages`) is created
   for the Workstation prebuilt image.

1. Register the `workstation-packages` package repository to the target device:

   ```posix-terminal
   tools/ffx target repository register -r workstation-packages --alias fuchsia.com --alias chromium.org
   ```

   This command exits silently without output.

## 4. Build and load the sample driver {:#build-and-load-the-sample-driver}

The Fuchsia emulator (launched in the [Start the emulator](#start-the-emulator)
section above) is configured to create a virtual device named
[`edu`][edu-device], which  is an educational device for writing drivers.
In the previous section, when the emulator started, Fuchsia’s driver framework
detected this `edu` device in the system, but it wasn’t able to find a driver
that could serve the `edu` device. So the `edu` device was left unmatched.

In this section, we build and publish the [`qemu_edu`][qemu-edu] sample driver
(which is a Fuchsia component). Upon detecting a new driver, the driver
framework will discover that this new `qemu_edu` driver is a match for
the `edu` device. Once matched, the `qemu_edu` driver starts providing the `edu`
device’s services (capabilities) to other components in the system – one of the
services provided by the `edu` device is that it computes a factorial given
an integer.

The tasks include:

*   View the drivers that are currently loaded in the emulator instance.
*   Build and publish the `qemu_edu` driver component.
*   Verify that the `qemu_edu` driver is loaded to the emulator instance.
*   View detailed information on the `qemu_edu` component.

Do the following:

1. View the list of the currently loaded drivers:

   ```posix-terminal
   tools/ffx driver list --loaded
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx driver list --loaded
   fuchsia-boot:///#meta/block.core.cm
   fuchsia-boot:///#meta/bus-pci.cm
   fuchsia-boot:///#meta/display.cm
   fuchsia-boot:///#meta/fvm.cm
   fuchsia-boot:///#meta/goldfish-display.cm
   fuchsia-boot:///#meta/goldfish.cm
   fuchsia-boot:///#meta/goldfish_address_space.cm
   fuchsia-boot:///#meta/goldfish_control.cm
   fuchsia-boot:///#meta/goldfish_sensor.cm
   fuchsia-boot:///#meta/goldfish_sync.cm
   fuchsia-boot:///#meta/hid-input-report.cm
   fuchsia-boot:///#meta/hid.cm
   fuchsia-boot:///#meta/intel-hda.cm
   fuchsia-boot:///#meta/intel-rtc.cm
   fuchsia-boot:///#meta/netdevice-migration.cm
   fuchsia-boot:///#meta/network-device.cm
   fuchsia-boot:///#meta/pc-ps2.cm
   fuchsia-boot:///#meta/platform-bus-x86.cm
   fuchsia-boot:///#meta/platform-bus.cm
   fuchsia-boot:///#meta/qemu-audio-codec.cm
   fuchsia-boot:///#meta/ramdisk.cm
   fuchsia-boot:///#meta/sysmem.cm
   fuchsia-boot:///#meta/virtio_block.cm
   fuchsia-boot:///#meta/virtio_ethernet.cm
   fuchsia-boot:///#meta/virtio_input.cm
   fuchsia-pkg://fuchsia.com/virtual_audio#meta/virtual_audio_driver.cm
   fuchsia-boot:///#meta/ahci.cm
   ```

2. Build and publish the `qemu_edu` driver component:

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/drivers:pkg.component
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/drivers:pkg.component
   INFO: Analyzed target //src/qemu_edu/drivers:pkg.component (8 packages loaded, 514 targets configured).
   INFO: Found 1 target...
   Target //src/qemu_edu/drivers:pkg.component up-to-date:
     bazel-bin/src/qemu_edu/drivers/pkg.component_run_component.sh
   INFO: Elapsed time: 92.307s, Critical Path: 56.84s
   INFO: 989 processes: 606 internal, 382 linux-sandbox, 1 local.
   INFO: Build completed successfully, 989 total actions
   INFO: Build completed successfully, 989 total actions
   added repository bazel.pkg.component
   Registering fuchsia-pkg://bazel.pkg.component/qemu_edu#meta/qemu_edu.cm
   Successfully bound:
   Node 'root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl', Driver 'fuchsia-pkg://bazel.pkg.component/qemu_edu#meta/qemu_edu.cm'.
   ```

3. Verify that the `qemu_edu` driver is now loaded to the Fuchsia emulator
   instance:

   ```posix-terminal
   tools/ffx driver list --loaded
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx driver list --loaded
   fuchsia-boot:///#meta/block.core.cm
   fuchsia-boot:///#meta/bus-pci.cm
   fuchsia-boot:///#meta/display.cm
   fuchsia-boot:///#meta/fvm.cm
   fuchsia-boot:///#meta/goldfish-display.cm
   fuchsia-boot:///#meta/goldfish.cm
   fuchsia-boot:///#meta/goldfish_address_space.cm
   fuchsia-boot:///#meta/goldfish_control.cm
   fuchsia-boot:///#meta/goldfish_sensor.cm
   fuchsia-boot:///#meta/goldfish_sync.cm
   fuchsia-boot:///#meta/hid-input-report.cm
   fuchsia-boot:///#meta/hid.cm
   fuchsia-boot:///#meta/intel-hda.cm
   fuchsia-boot:///#meta/intel-rtc.cm
   fuchsia-boot:///#meta/netdevice-migration.cm
   fuchsia-boot:///#meta/network-device.cm
   fuchsia-boot:///#meta/pc-ps2.cm
   fuchsia-boot:///#meta/platform-bus-x86.cm
   fuchsia-boot:///#meta/platform-bus.cm
   fuchsia-boot:///#meta/qemu-audio-codec.cm
   fuchsia-boot:///#meta/ramdisk.cm
   fuchsia-boot:///#meta/sysmem.cm
   fuchsia-boot:///#meta/virtio_block.cm
   fuchsia-boot:///#meta/virtio_ethernet.cm
   fuchsia-boot:///#meta/virtio_input.cm
   fuchsia-pkg://fuchsia.com/virtual_audio#meta/virtual_audio_driver.cm
   {{ '<strong>' }}fuchsia-pkg://bazel.pkg.component/qemu_edu#meta/qemu_edu.cm{{ '</strong>' }}
   fuchsia-boot:///#meta/ahci.cm
   ```

   Notice that the `qemu_edu` driver is shown in the loaded drivers list.

4. View the `qemu_edu` component information:

   ```posix-terminal
   tools/ffx component show qemu_edu.cm
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx component show qemu_edu.cm
                  Moniker:  /bootstrap/universe-pkg-drivers:root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl
                      URL:  fuchsia-pkg://bazel.pkg.component/qemu_edu#meta/qemu_edu.cm
              Instance ID:  None
                     Type:  CML Component
          Component State:  Resolved
    Incoming Capabilities:  /svc/fuchsia.device.fs.Exporter
                            /svc/fuchsia.driver.compat.Service
                            /svc/fuchsia.logger.LogSink
     Exposed Capabilities:  fuchsia.examples.qemuedu.Service
              Merkle root:  df0fc9b427711e7a47dd286dc4f47d5dea8060607a7e968bf48f2e6fc8bdd4af
          Execution State:  Running
             Start reason:  Instance is in a single_run collection
    Outgoing Capabilities:  fuchsia.examples.qemuedu.Service
   ```

5. View the device logs of the `qemu-edu` driver:

   ```posix-terminal
   tools/ffx log --tags qemu-edu dump
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx log --tags qemu-edu dump
   [2022-10-03 23:34:07.972][<ffx>]: logger started.
   [161.225][universe-pkg-drivers:root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl][qemu-edu,driver][I]: [src/qemu_edu/drivers/qemu_edu.cc:179] edu device version major=1 minor=0
   ```

## 5. Build and run a tool {:#build-and-run-a-tool}

The `qemu_edu` driver sample includes [tools][eductl_tools] for interacting with the
`qemu_edu` driver. Developers often include binary executables in a Fuchsia package and
run those executables as a component for testing and debugging drivers running in a
Fuchsia system.

In this driver sample, an executable named `eductl_tool` provides two options: `live` and
`fact`. The `live` command checks for the liveness of the `qemu_edu` driver in the system.
The `fact` command takes an integer as an additional argument. The value of the integer is
passed to the `qemu_edu` driver to be used as input for computing the factorial. The
driver computes the factorial and returns the result to the `fact` command, which then
prints the result on the terminal.

The tasks include:

*   Build and run `eductl_tool`.
*   Verify that this tool can interact with the `qemu_edu` driver.

Do the following:

1. Build and run `eductl_tool` (and run the `live` command):

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- live
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- live
   INFO: Analyzed target //src/qemu_edu/tools:pkg.eductl_tool (0 packages loaded, 0 targets configured).
   INFO: Found 1 target...
   Target //src/qemu_edu/tools:pkg.eductl_tool up-to-date:
     bazel-bin/src/qemu_edu/tools/pkg.eductl_tool_run_driver_tool.sh
   INFO: Elapsed time: 0.286s, Critical Path: 0.01s
   INFO: 1 process: 1 internal.
   INFO: Build completed successfully, 1 total action
   INFO: Build completed successfully, 1 total action
   added repository bazel.pkg.eductl.tool
   {{ '<strong>' }}Liveness check passed!{{ '</strong>' }}
   ```

   Verify that the line `Liveness check passed!` is printed in the end.

1. Run `eductl_tool` using `fact` and `12` as input:

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ...
   INFO: Build completed successfully, 1 total action
   added repository bazel.pkg.eductl.tool
   {{ '<strong>' }}Factorial(12) = 479001600{{ '</strong>' }}
   ```

   The last line shows that the driver replied `479001600` as the result of the factorial
   to `eductl_tool`, which passed 12 as input to the driver.

1. View the device logs of the `qemu-edu` driver:

   ```posix-terminal
   tools/ffx log --tags qemu-edu dump
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx log --tags qemu-edu dump
   [2022-10-03 23:34:07.972][<ffx>]: logger started.
   [161.225][universe-pkg-drivers:root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl][qemu-edu,driver][I]: [src/qemu_edu/drivers/qemu_edu.cc:179] edu device version major=1 minor=0
   [434.054][universe-pkg-drivers:root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl][qemu-edu,driver][I]: [src/qemu_edu/drivers/qemu_edu.cc:108] Replying with result=true
   [444.714][universe-pkg-drivers:root.sys.platform.platform-passthrough.PCI0.bus.00_06_0_.pci-00_06.0-fidl][qemu-edu,driver][I]: [src/qemu_edu/drivers/edu_device.cc:124] Replying with factorial=479001600
   ```

   Notice that more messages are now logged from the `qemu-edu` driver.

## 6. Debug the sample driver {:#debug-the-sample-driver}

Use the Fuchsia debugger ([`zxdb`][zxdb-user-guide]) to step through the
sample driver’s code as the driver is running on the emulator instance.

The tasks include:

*   Identify the driver host (which is a component) that is running the
    `qemu_edu` driver.
*   Start the Fuchsia debugger and connect it to the emulator instance.
*   Attach the debugger to the driver host.
*   Set a breakpoint on the driver’s code.
*   Run `eductl_tool`, which triggers the driver to execute its
    instructions.
*   Step through the driver’s code.

Do the following:

1. View the list of the running driver hosts:

   ```posix-terminal
   tools/ffx driver list-hosts
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx driver list-hosts
   Driver Host: 5416
       fuchsia-boot:///#meta/bus-pci.cm
       fuchsia-boot:///#meta/display.cm
       fuchsia-boot:///#meta/goldfish-display.cm
       fuchsia-boot:///#meta/goldfish.cm
       fuchsia-boot:///#meta/goldfish_control.cm
       fuchsia-boot:///#meta/goldfish_sensor.cm
       fuchsia-boot:///#meta/goldfish_sync.cm
       fuchsia-boot:///#meta/hid.cm
       fuchsia-boot:///#meta/intel-hda.cm
       fuchsia-boot:///#meta/platform-bus-x86.cm
       fuchsia-boot:///#meta/platform-bus.cm
       fuchsia-boot:///#meta/qemu-audio-codec.cm
       fuchsia-boot:///#meta/ramdisk.cm
       fuchsia-boot:///#meta/sysmem.cm
       fuchsia-pkg://fuchsia.com/virtual_audio#meta/virtual_audio_driver.cm

   Driver Host: 8248
       fuchsia-boot:///#meta/intel-rtc.cm

   Driver Host: 8317
       fuchsia-boot:///#meta/pc-ps2.cm

   Driver Host: 9604
       fuchsia-boot:///#meta/block.core.cm
       fuchsia-boot:///#meta/fvm.cm
       fuchsia-boot:///#meta/virtio_block.cm

   Driver Host: 9781
       fuchsia-boot:///#meta/hid-input-report.cm
       fuchsia-boot:///#meta/hid.cm
       fuchsia-boot:///#meta/virtio_input.cm

   Driver Host: 10066
       fuchsia-boot:///#meta/netdevice-migration.cm
       fuchsia-boot:///#meta/network-device.cm
       fuchsia-boot:///#meta/virtio_ethernet.cm

   Driver Host: 10137
       fuchsia-boot:///#meta/hid-input-report.cm
       fuchsia-boot:///#meta/hid.cm
       fuchsia-boot:///#meta/virtio_input.cm

   Driver Host: 10344
       fuchsia-boot:///#meta/goldfish_address_space.cm

   Driver Host: 10387
       fuchsia-boot:///#meta/ahci.cm

   Driver Host: 134104
       fuchsia-pkg://bazel.pkg.component/qemu_edu#meta/qemu_edu.cm
   ```

   Make a note of the PID of the `qemu_edu` driver host (`134104` in the
   example above).

1. Start the Fuchsia debugger:

   ```posix-terminal
   tools/ffx debug connect
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/ffx debug connect
   Connecting (use "disconnect" to cancel)...
   Connected successfully.
   👉 To get started, try "status" or "help".
   [zxdb]
   ```

1. Attach the debugger to the `qemu_edu` driver host:

   <pre class="devsite-click-to-copy">
   <span class="no-select">[zxdb] </span>attach <var>PID</var>
   </pre>

   Replace `PID` with the PID of the `qemu_edu` driver host identified
   in Step 1, for example:

   ```none {:.devsite-disable-click-to-copy}
   [zxdb] attach 134104
   ```

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   [zxdb] attach 134104
   Attached Process 1 state=Running koid=134104 name=driver_host2.cm component=driver_host2.cm
   Downloading symbols...
   Symbol downloading complete. 2 succeeded, 0 failed.
   [zxdb]
   ```

1. Set a breakpoint at the driver’s `HandleIrq` function:

   <pre class="devsite-click-to-copy">
   <span class="no-select">[zxdb] </span>break QemuEduDevice::HandleIrq
   </pre>

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   [zxdb] break QemuEduDevice::HandleIrq
   Created Breakpoint 1 @ QemuEduDevice::HandleIrq
      94 void QemuEduDevice::HandleIrq(async_dispatcher_t* dispatcher, async::IrqBase* irq,
    {{ '<strong>' }}◉ 95                               zx_status_t status, const zx_packet_interrupt_t* interrupt) { {{ '</strong>' }}
      96   irq_.ack();
   [zxdb]
   ```

1. In different terminal, run `eductl_tool` (using `fact` and `12` as input)
   to interact with the driver:

   Note:  In this new terminal, make sure that you change to the same work
   directory (for instance, `cd $HOME/fuchsia-drivers`).

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ```

   Unlike in the previous section, after printing output similar to the following,
   the command now waits:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   INFO: Analyzed target //src/qemu_edu/tools:pkg.eductl_tool (0 packages loaded, 0 targets configured).
   INFO: Found 1 target...
   Target //src/qemu_edu/tools:pkg.eductl_tool up-to-date:
     bazel-bin/src/qemu_edu/tools/pkg.eductl_tool_run_driver_tool.sh
   INFO: Elapsed time: 0.348s, Critical Path: 0.01s
   INFO: 1 process: 1 internal.
   INFO: Build completed successfully, 1 total action
   INFO: Build completed successfully, 1 total action
   added repository bazel.pkg.eductl.tool
   ```

   In the `zxdb` terminal, verify that the debugger is stopped at the
   `HandleIrq` function, for example:

   ```none {:.devsite-disable-click-to-copy}
   🛑 thread 2 on bp 1 edu_device::QemuEduDevice::HandleIrq(edu_device::QemuEduDevice*, async_dispatcher_t*, async::IrqBase*, zx_status_t, zx_packet_interrupt_t const*) • edu_device.cc:95
      93 // Respond to INTx interrupts triggered by the device, and return the compute result.
      94 void QemuEduDevice::HandleIrq(async_dispatcher_t* dispatcher, async::IrqBase* irq,
    {{ '<strong>' }}▶ 95                               zx_status_t status, const zx_packet_interrupt_t* interrupt) { {{ '</strong>' }}
      96   irq_.ack();
      97   if (!pending_callback_.has_value()) {
   [zxdb]
   ```

1. In the `zxdb` terminal, view the source code around the current breakpoint:

   <pre class="devsite-click-to-copy">
   <span class="no-select">[zxdb] </span>list
   </pre>

   This command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   [zxdb] list
       90   pending_callback_ = std::move(callback);
       91 }
       92
       93 // Respond to INTx interrupts triggered by the device, and return the compute result.
       94 void QemuEduDevice::HandleIrq(async_dispatcher_t* dispatcher, async::IrqBase* irq,
    {{ '<strong>' }}▶  95                               zx_status_t status, const zx_packet_interrupt_t* interrupt) { {{ '</strong>' }}
       96   irq_.ack();
       97   if (!pending_callback_.has_value()) {
       98     FDF_LOG(ERROR, "Received unexpected interrupt!");
       99     return;
      100   }
      101   auto callback = std::move(*pending_callback_);
      102   pending_callback_ = std::nullopt;
      103   if (status != ZX_OK) {
      104     FDF_SLOG(ERROR, "Failed to wait for interrupt", KV("status", zx_status_get_string(status)));
      105     callback(zx::error(status));
   [zxdb]
   ```

1. In the `zxdb` terminal, step through the `HandleIrq` function
   using the `next` command until the value of `factorial` is computed and
   the callback is invoked (that is, until the line 126 is reached):

   <pre class="devsite-click-to-copy">
   <span class="no-select">[zxdb] </span>next
   </pre>

   The last `next` command prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   ...
   [zxdb] next
   🛑 thread 2 edu_device::QemuEduDevice::HandleIrq(edu_device::QemuEduDevice*, async_dispatcher_t*, async::IrqBase*, zx_status_t, zx_packet_interrupt_t const*) • edu_device.cc:126
      124   FDF_SLOG(INFO, "Replying with", KV("factorial", factorial));
      125   callback(zx::ok(factorial));
    {{ '<strong>' }}▶ 126 } {{ '</strong>' }}
      127 // [END compute_factorial]
      128
   [zxdb]
   ```

   In the other terminal, after the `HandleIrq` function invokes the callback,
   verify that `eductl_tool` prints the factorial result and exits:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ...
   INFO: Build completed successfully, 1 total action
   added repository bazel.pkg.eductl.tool
   {{ '<strong>' }}Factorial(12) = 479001600{{ '</strong>' }}
   $
   ```

1. In the `zxdb` terminal, type `exit` or press `Ctrl-D` to exit the debugger.

   Note: For more information on usages and best practices on `zxdb`, see the
   [zxdb user guide][zxdb-user-guide].

## 7. Modify and reload the sample driver {:#modify-and-reload-the-sample-driver}

Update the source code of the sample driver and reload it to the emulator
instance.

The tasks include:

*   Restart the emulator instance to unload the `qemu_edu` driver.
*   Update the source code of the `qemu_edu` driver.
*   Load the updated driver.
*   Run `eductl_tool` to verify the change.

Do the following:

1. Stop the emulator instance:

   ```posix-terminal
   tools/ffx emu stop
   ```

   This command stops the currently running emulator instance.

1. Start a new instance of the Fuchsia emulator:

   ```posix-terminal
   tools/ffx emu start workstation_eng.qemu-x64 --headless \
     --kernel-args "driver_manager.use_driver_framework_v2=true" \
     --kernel-args "driver_manager.root-driver=fuchsia-boot:///#meta/platform-bus.cm" \
     --kernel-args "devmgr.enable-ephemeral=true"
   ```

   This command starts a headless emulator instance running the Workstation
   prebuilt image.

1. Use a text editor to open the `edu_device.cc` file of the sample driver, for example:

   ```posix-terminal
   nano src/qemu_edu/drivers/edu_device.cc
   ```

1. In the `QemuEduDevice::HandleIrq` function,
   between the line `uint32_t factorial = mmio_->Read32(kFactorialComputationOffset);`
   (Line 123) and the line `FDF_SLOG(INFO, "Replying with", KV("factorial", factorial));`
   (Line 124), add the following line:

   ```
   factorial=12345;
   ```

   The function should look like below:

   ```none {:.devsite-disable-click-to-copy}
   void QemuEduDevice::HandleIrq(async_dispatcher_t* dispatcher, async::IrqBase* irq,
                                 zx_status_t status, const zx_packet_interrupt_t* interrupt) {
     irq_.ack();
     if (!pending_callback_.has_value()) {
       FDF_LOG(ERROR, "Received unexpected interrupt!");
       return;
     }
     auto callback = std::move(*pending_callback_);
     pending_callback_ = std::nullopt;
     if (status != ZX_OK) {
       FDF_SLOG(ERROR, "Failed to wait for interrupt", KV("status", zx_status_get_string(status)));
       callback(zx::error(status));
       return;
     }

     // Acknowledge the interrupt with the edu device.
     auto int_status = mmio_->Read32(kInterruptStatusRegisterOffset);
     mmio_->Write32(int_status, kInterruptAcknowledgeRegisterOffset);

     // Deassert the legacy INTx interrupt on the PCI bus.
     auto irq_result = pci_->AckInterrupt();
     if (!irq_result.ok() || irq_result->is_error()) {
       FDF_SLOG(ERROR, "Failed to ack PCI interrupt",
                KV("status", irq_result.ok() ? irq_result->error_value() : irq_result.status()));
       callback(zx::error(ZX_ERR_IO));
       return;
     }

     // Reply with the result.
     uint32_t factorial = mmio_->Read32(kFactorialComputationOffset);
     {{ '<strong>' }}factorial=12345;{{ '</strong>' }}
     FDF_SLOG(INFO, "Replying with", KV("factorial", factorial));
     callback(zx::ok(factorial));
   }
   ```

   The function is now updated to always return the value of `12345`.

1. Save the file and close the text editor.

1. Rebuild and run the modified sample driver:

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/drivers:pkg.component
   ```

1. Run `eductl_tool` using `fact` and `12` as input:

   ```posix-terminal
   tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ```

   This command now prints output similar to the following:

   ```none {:.devsite-disable-click-to-copy}
   $ tools/bazel run --config=fuchsia_x64 //src/qemu_edu/tools:pkg.eductl_tool -- fact 12
   ...
   INFO: Build completed successfully, 1 total action
   added repository bazel.pkg.eductl.tool
   {{ '<strong>' }}Factorial(12) = 12345{{ '</strong>' }}
   ```

   The last line shows that the `qemu_edu` driver replied with the
   hardcoded value of `12345` to `eductl_tool`.

**Congratulations! You’re now all set with the Fuchsia driver development!**

## Next steps {:#next-steps}

Learn more about how the `qemu_edu` driver works
in [Codelab: QEMU edu driver][codelab-qemu-edu-driver].

## Appendices

### Clean up the environment {:#clean-up-the-environment}

If you run into a problem while following this guide and decide to start over
from the beginning, consider running the commands below to clean up
your development environment (that is, to clean up directories, build artifacts,
downloaded files, symlinks, configuration settings, and more).

Remove the package repositories created in this guide:

```posix-terminal
tools/ffx repository remove workstation-packages
```

```posix-terminal
tools/ffx repository server stop
```

Remove all existing configurations and data of `ffx`:

```posix-terminal
tools/ffx daemon stop
```

```posix-terminal
rm -rf $HOME/.local/share/Fuchsia/ffx
```

When Bazel fails to build, try the commands below:

Caution: Running `bazel clean` or deleting the `$HOME/.cache/bazel` directory
deletes all the artifacts downloaded by Bazel, which can be around 4 GB.
This means Bazel will need to download those dependencies again
the next time you run `bazel build`.

```posix-terminal
tools/bazel clean --expunge
```

```posix-terminal
tools/bazel shutdown && rm -rf $HOME/.cache/bazel
```

Remove the `fuchsia-drivers` directory and its artifacts:

Caution: If the SDK samples repository is cloned to a different location
than `$HOME/fuchsia-drivers`, adjust the directory path in the command below.
Be extremely careful with the directory path when you run the `rm -rf
<DIR>` command.

```posix-terminal
rm -rf $HOME/fuchsia-drivers
```

Other clean up commands:

```posix-terminal
killall ffx
```

```posix-terminal
killall pm
```

<!-- Reference links -->

[using-the-sdk]: /docs/development/sdk/index.md
[get-started-sdk]: /docs/get-started/sdk/index.md
[sdk-bug]: https://bugs.fuchsia.dev/p/fuchsia/issues/entry?template=Bazel
[kvm]: https://www.linux-kvm.org/page/Main_Page
[qemu]: https://www.qemu.org/
[bazel]: https://bazel.build/docs
[git]: https://git-scm.com/
[git-install]: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
[bazel-install]: https://bazel.build/install
[bazelisk-download]: https://github.com/bazelbuild/bazelisk/releases
[fuchsia-ssh-keys]: /docs/development/sdk/ffx/create-ssh-keys-for-devices.md
[ticket-01]: https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=97909
[sdk-driver-sample-repo]: https://fuchsia.googlesource.com/sdk-samples/drivers
[clang]: https://clang.llvm.org/
[fuchsia-idk]: /docs/development/idk/README.md
[edu-device]: https://fuchsia.googlesource.com/third_party/qemu/+/refs/heads/main/docs/specs/edu.txt
[qemu-edu]: https://fuchsia.googlesource.com/sdk-samples/drivers/+/refs/heads/main/src/qemu_edu/
[eductl-cml]: https://fuchsia.googlesource.com/sdk-samples/drivers/+/refs/heads/main/src/qemu_edu/meta/eductl.cml
[zxdb-user-guide]: /docs/development/debugger/README.md
[driver-concepts]: /docs/concepts/drivers/README.md
[codelab-qemu-edu-driver]: /docs/get-started/sdk/learn/driver/introduction.md
[driver-framework]: /docs/concepts/drivers/driver_framework.md
[femu]: /docs/development/sdk/ffx/start-the-fuchsia-emulator.md
[eductl_tools]: https://fuchsia.googlesource.com/sdk-samples/drivers/+/refs/heads/main/src/qemu_edu/tools/

repository: lambdaxymox/fuchsia

repo_name: lambdaxymox/fuchsia


text:
---
kind: documentation
title: Browser support
cat: 1
---

Knockout is tested on the following browsers:

 * Mozilla Firefox (versions 2 - latest)
 * Google Chrome (versions 5 - latest)
 * Microsoft Internet Explorer (versions 6 - 11)
 * Apple Safari (tested on Windows Safari version 5, Mac OS X Safari version 3.1.2, and iPhone Safari for iOS 4-7; should work on newer/older versions too)
 * Opera (versions 10 - recent)

It's very likely that Knockout also works on older and newer versions of these browsers, but there's only so many combinations we can check regularly! At the time of the last check, Knockout was also found to work on the following browsers (though we don't recheck these for every release):

 * Opera Mini
 * Google Android OS browser

To get a good idea of how Knockout will run on another browser or platform, simply [run the test suite](../spec/runner.html). This will validate hundreds of behavioral specifications and produce a report of any problems. The pass rate should be 100% on all the browsers listed above.

repository: codenamejason/tko

repo_name: codenamejason/tko


text:
**[< Table Of Contents](https://github.com/lehner-lab/DiMSum#table-of-contents)**

# File Formats

* **[Experimental Design File](#experimental-design-file)**
* **[FASTQ Files](#fastq-files)**
* **[Variant Count File](#variant-count-file)**
* **[Barcode Design File](#barcode-design-file)**
* **[Variant Identity File](#variant-identity-file)**
* **[Synonym Sequences File](#synonym-sequences-file)**
* **[Output Files](#output-files)**

## Experimental Design File

**REQUIRED:** DiMSum requires a table (e.g. using Microsoft Excel) describing the experimental design that has been saved as tab-separated plain text file (see [arguments](ARGUMENTS.md#general)). You can download [this](../examples/example_experimentDesign.txt) file to use as a template.

Your file must have the following columns:
* **sample_name** A sensible sample name e.g. 'input1' (alphanumeric characters only).
* **experiment_replicate** An integer identifier denoting distinct experiments (e.g. distinct plasmid library transformations) i.e. a set of input and output replicates originating from the same input biological replicate (strictly positive integer).
* **selection_id** An integer inidicating whether samples were sequenced before (0) or after (1) selection.
* **selection_replicate** (Output samples only) An integer denoting distinct replicate selections (or biological output replicates) each derived from the same input sample (strictly positive integer). Entries should be blank (empty string) for all input samples (each input sample corresponds to a unique experiment).
* **technical_replicate** An integer denoting technical replicates (a strictly positive integer) corresponding to sample re-sequencing i.e. extracted DNA originating from the same sample split between separate sequencing lanes or files. Leave this column blank (empty string) when no technical replicates are present.
* **pair1** (_WRAP_ only) [FASTQ file](#fastq-files) name of the first read in a given pair.
* **pair2** (_WRAP_ only) [FASTQ file](#fastq-files) name of the second read in a given pair (omit for single-end library designs, see [arguments](ARGUMENTS.md#fastq-files)).

Optional columns for growth-rate based assays (download template file [here](../examples/example_experimentDesign_gr.txt)):
* **generations** (Output samples only) An estimate of the number of generations in order to normalize fitness and error estimates accordingly.
* **cell_density** An estimate of the cell density (optical density or similar) in order to estimate variant growth rates.
* **selection_time** (Output samples only) The selection time in hours in order to estimate variant growth rates.

Below is a schematic of a generic deep mutational scanning experiment indicating the corresponding entries which should be made in the experimental design file (red text).

In addition to these mandatory columns, additional columns may be included to specify [Stage 2](PIPELINE.md#stage-2-trim-constant-regions-wrap)-specific options (see [arguments](ARGUMENTS.md#trim-arguments)), which relate to constant region trimming. This allows sample-specific trimming behaviour if necessary. Options specified by columns in the experimental design file override global arguments provided on the command-line.

## FASTQ Files

**OPTIONAL:** If processing of raw sequencing reads is required (with *WRAP*), DiMSum requires FASTQ files saved in a common directory and with a common file extension (see [arguments](ARGUMENTS.md#fastq-files)). Either FASTQ files or a [Variant Count File](#variant-count-file) can be supplied (not both).

## Variant Count File

**OPTIONAL:** If raw sequencing reads have already been processed independently of DiMSum, processing and analysis of variant counts (with DiMSum *STEAM*) requires a table (e.g. using Microsoft Excel) with variant sequences and counts for all samples (see [arguments](ARGUMENTS.md#custom-variant-count-file)). You can download [this](../examples/example_variantCounts.txt) file to use as a template. Either [FASTQ Files](#fastq-files) or a Variant Count File can be supplied (not both).

## Barcode Design File

**OPTIONAL:** If [FASTQ files](#fastq-files) contain multiplexed samples, DiMSum requires a table (e.g. using Microsoft Excel) describing how index tags map to samples that has been saved as tab-separated plain text file (see [arguments](ARGUMENTS.md#barcoded-library-design)). You can download [this](../examples/example_barcodeDesign.txt) file to use as a template.

Your file must have the following columns:
* **pair1** [FASTQ file](#fastq-files) name of the first read in a given pair.
* **pair2** [FASTQ file](#fastq-files) name of the second read in a given pair (omit for single-end library designs, see [arguments](ARGUMENTS.md#fastq-files)).
* **barcode** Sample index tag (A/C/G/T characters only).
* **new_pair_prefix** [FASTQ file](#fastq-files) prefix of demultiplexed sample reads i.e. excluding file extension (alphanumeric and underscore characters only).

When including a Barcode Design File, ensure that all 'new_pair_prefix' column entries correspond to 'pair1' and 'pair2' column entries in the [Experimental Design File](#experimental-design-file) by appending '1.fastq' and '2.fastq' to the prefix for the first and second read respectively.

## Variant Identity File

**OPTIONAL:** If the supplied sequences (supplied in the [FASTQ Files](#fastq-files) or [Variant Count File](#variant-count-file)) contain variant barcodes, DiMSum requires a table (e.g. using Microsoft Excel) describing how barcodes map to variants that has been saved as tab-separated plain text file (see [arguments](ARGUMENTS.md#barcoded-library-design)). You can download [this](../examples/example_variantIdentity.txt) file to use as a template.

Your file must have the following columns:
* **barcode** DNA barcode (A/C/G/T characters only).
* **variant** Associated DNA variant (A/C/G/T characters only).

## Synonym Sequences File

**OPTIONAL:** In order to obtain fitness and error estimates for synonymous substitution variants corresponding to additional reference variants (other than the wild-type), simply include them in a plain text file with one coding nucleotide sequence per line (single column, no header, A/C/G/T characters only). You can download [this](../examples/example_synonymSequences.txt) file to use as a template.

## Output Files

Primary output files:

* **report.html** DiMSum pipeline summary report and diagnostic plots in html format.
* **DiMSum_Project_fitness_replicates.RData** R data object with replicate (and merged) fitness scores and associated errors.
* **DiMSum_Project_variant_data_merge.RData** R data object with variant counts and statistics.

Additional output files:

* **fitness_wildtype.txt** Wild-type fitness score and associated error.
* **fitness_singles.txt** Single amino acid or nucleotide substitution variant fitness scores and associated errors.
* **fitness_doubles.txt** Double amino acid or nucleotide substitution variant fitness scores and associated errors.
* **fitness_synonymous.txt** Synonymous substitution variant fitness scores and associated errors (for coding sequences only).
* **fitness_singles_MaveDB.csv** [MaveDB](https://www.mavedb.org/) compatible .csv file with single amino acid or nucleotide substitution variant fitness scores and associated errors.
* **DiMSum_Project_variant_data_merge.tsv** Tab-separated plain text file with variant counts and statistics.
* **DiMSum_Project_nobarcode_variant_data_merge.tsv** Tab-separated plain text file with sequenced barcodes that were not found in the variant identity file.
* **DiMSum_Project_indel_variant_data_merge.tsv** Tab-separated plain text file with rejected indel variants.
* **DiMSum_Project_rejected_variant_data_merge.tsv** Tab-separated plain text file with remaining rejected variants (internal constant region mutants, mutations inconsistent with the library design or variants with too many substitutions).

repository: lehner-lab/DiMSum

repo_name: lehner-lab/DiMSum


text:
## Rigging the Lottery: Making All Tickets Winners

**Paper**: [https://arxiv.org/abs/1911.11134](https://arxiv.org/abs/1911.11134)

In this repository we implement following dynamic sparsity strategies:

1.  SET: Implements Sparse Evalutinory Training (SET) which corresponds to
    replacing low magniture weights with new random new connections. For more
    info see https://www.nature.com/articles/s41467-018-04316-3.

2.  SNFS: Implements momentum based training with sparsity re-distribution:
    For more info see https://arxiv.org/abs/1907.04840.

3.  RigL: Our method,RigL, removes a fraction of connections based on weight
    magnitudes and activates new ones using instantaneous gradient information.
    After updating the connectivity, training continues with the updated
    network until the next update. See our ICLR submission for more details.

## Setup
First clone this repo.
```
git clone https://github.com/google-research/rigl.git
cd rigl
```
We use the counter used in [Neurips 2019 MicroNet Challenge](https://micronet-challenge.github.io/).
So we need the clone the google_research repo for that and change the name.
```
git clone https://github.com/google-research/google-research.git
mv google-research/ google_research/
```
Now we can run the test. Following script creates a virtual environments and
installs the necessary libraries. Then it runs few tests.
```
bash run.sh
```
We need to activate the virtual environment before running the experiment.
We also add the current folder manually to the python path. With that, we are
ready to run some trivial mnist experiments.

```
source env/bin/activate
export PYTHONPATH=$PYTHONPATH:$PWD

python rigl/mnist/mnist_train_eval.py
```

## Disclaimer
This is not an official Google product.

repository: polceanum/rigl

repo_name: polceanum/rigl


text:
It acts like a storage point for useful and reusable code for everyone using C++.
Libzeug is a cross-platform library licenced under the [MIT license](http://opensource.org/licenses/MIT).

The current modules in libzeug are:
 * [iozeug](#iozeug)
 * [loggingzeug](#loggingzeug)
 * [propertyguizeug](#propertyguizeug)
 * [reflectionzeug](#reflectionzeug)
 * [scriptzeug](#scriptzeug)
 * [signalzeug](#signalzeug)
 * [threadingzeug](#threadingzeug)

The current pre-release is [libzeug-v0.1.0](https://github.com/hpicgs/libzeug/releases/tag/libzeug-v0.1).
To find out more about libzeug and how to use it, check out our [wiki](https://github.com/hpicgs/libzeug/wiki).

### Documentation

A first basic libzeug documentation can be found [here](http://costumebrother.de/libzeug).

### Dependencies

The following dev-libraries and programs need to be provided for correct CMake configuration:
* C++11 compatible compiler (e.g. gcc 4.7, VS 2013)
* CMake (>=2.8.9, better 2.8.12): http://www.cmake.org/
* Qt5 (>= 5.0): http://www.qt-project.org/

## Development Notes

If you are contributing to this project, please keep the following notes in mind:
* Add your name and email to the AUTHORS file.
* Follow coding conventions according to google's [C++ Style Guide](http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml).
* Commits should provide a meaningful  message, which uses the imperative, present tense: "change", not "changed" nor "changes", AND start with a capital letter.
* Commits should always refer to an issue: use ```#xxx```, ```fix #xxx```, or ```close #xxx```.
* Pull Requests are reviewed by at least one other developer on another platform.
* Use lazy initialization as often as possible for time consuming tasks.
* Member Variables always start with ```m_```, ```g_```, and ```s_``` (e.g.,```m_member```, ```g_global```, and ```s_static```)..
* Interface or abstract class names always start with Abstract (e.g., ```AbstractPainter```).
* Enforce strict include sequence: gl, glew, std, glm, header, glow (there should be only a few exceptions).

iozeug
------

iozeug contains a function to read a file into an std::string.

loggingzeug
-----------

loggingzeug provides stream like logging functionality with customizable outputs (default output is to the console).

propertyguizeug
---------------

propertyguizeug contains the automatic generation of a GUI from a set of properties from [reflectionzeug](#reflectionzeug).

reflectionzeug
------------

reflectionzeug allows the definition of properties that can be used to parameterize a program.
It supports saving and loading properties to and from a file.
The currently implemented property types are `bool`, `float`, `double`, `std::string`, `FilePath`, `Color`, every integral type, user-defined enums and glm types. Every prior type can be wrapped in an `std::array`. You can extend reflectionzeug and add your own types.

scriptzeug
----------

configure V8 in Win with x64 and no i18n:
`python build\gyp_v8 -Dtarget_arch=x64 -Dv8_enable_i18n_support=0 -Dcomponent=shared_library`
build:
`msbuild /p:Configuration=Release tools\gyp\v8.sln`

signalzeug
----------

signalzeug is a small library that provides classes for a simple signal system.
Objects can define signals they can fire and other objects can register on those signals.
Arbitrary parameters and even signal chaining are allowed.

threadingzeug
-------------

threadingzeug provides a `parallel_for` function that uses either OpenMP or the `std::thread` classes to execute a for loop concurrently.


text:
# SemiCookie

A Cookie Clicker utility mod.

## Features

- Tracks ascensions
- Changes ascension meter to show progress toward target ascension
- Optionally auto clicks the cookie
- Optionally auto clicks shimmers (golden cookies, reindeers, wrath cookies, etc.)
- Optionally auto clicks news
- Integrates with Cookie Monster to optionally auto buy upgrades/buildings

repository: Semyazi/SemiCookie

repo_name: Semyazi/SemiCookie


text:
# Welcome to metaDMG

This website documents the features and options available in metaDMG.

The documentation is structured as follows:
## Documentation:

- [Introduction](introduction): Introducton to the field of metagenomics and the problem of estimating damage in the case of ancient DNA.

- [Getting Started](getting-started): Software requirements, installation explanation, and a short workflow introduction.

- [Tutorial](tutorial): How to classify ancient taxa in a metagenomic sample.

- [Command Line Interface](command-line-interface): The command line interface.

- [Results](results): Explanation of the fit results.

- [Dashboard](dashboard): Explanation of dashboard.

---

## Reference:

- [Main](api-main): The main functions to use if importing `metaDMG` as a package.
- [Utils](api-utils): General functions.
- [CLI](api-cli): Full API for the command line interface.

For the source code, see [Github](https://github.com/metaDMG-dev/metaDMG-core)

```{toctree}
---
caption: Documentation
maxdepth: 2
hidden:
---

introduction
getting-started
tutorial
command-line-interface
results
dashboard
```

```{toctree}
---
caption: Reference
maxdepth: 1
hidden:
---

api-main
api-utils
api-cli
```

repository: metaDMG-dev/metaDMG-core

gha_language: Python

gha_license_id: MIT

repo_name: metaDMG-dev/metaDMG-core


text:
# Getting results

* On every kind of failure libFuzzer prints a stack trace. It dumps reproducer file to disk and then exits the process. In libFuzzerfication fuzz.sh script takes care that fuzzer is started again and is running all the time.

* Every stub's container saves repro file on host machine's $HOME/results directory. Also log including stack trace and other information is saved to results directory.

* You can try to reproduce errors by starting a new container and mounting a repro file in it. After that you can run fuzzer stub with that repro.

repository: venlakatainen/libfuzzerfication

repo_name: venlakatainen/libfuzzerfication


text:
[![Express Logo](https://i.cloudup.com/zfY6lL7eFa-3000x3000.png)](http://expressjs.com/)

[Express](http://expressjs.com/) application generator.

- [Node.js](https://nodejs.org/en/)
- [Expressjs](https://www.npmjs.com/package/express)
- [Knex](https://knexjs.org/)

## Installation

```sh
$ npm install -g express-boilerplate-mvc
```

## Quick Start

The quickest way to get started with express is to utilize the executable `express(1)` to generate an application as shown below:

Create the app:

```bash
$ express-boilerplate --view=hbs /tmp/myapp && cd /tmp/myapp
```

Install dependencies:

```bash
$ npm install
```

Start your Express.js app at `http://localhost:3000/`:

```bash
$ npm start
```

## Command Line Options

This generator can also be further configured with the following command line flags.

				--version        output the version number
		-e, --ejs            add ejs engine support
				--pug            add pug engine support
				--hbs            add handlebars engine support
		-H, --hogan          add hogan.js engine support
		-v, --view <engine>  add view <engine> support (dust|ejs|hbs|hjs|jade|pug|twig|vash) (defaults to jade)
		-c, --css <engine>   add stylesheet <engine> support (less|stylus|compass|sass) (defaults to plain css)
				--git            add .gitignore
		-f, --force          force on non-empty directory
		-h, --help           output usage information

## License

[MIT](LICENSE)

Inspired/forked on [express-generator](https://npmjs.org/package/express-generator)

repository: cesarrdzs/express-boilerplate-mvc

repo_name: cesarrdzs/express-boilerplate-mvc


text:
# PS-FCN
**[PS-FCN: A Flexible Learning Framework for Photometric Stereo, ECCV 2018](https://guanyingc.github.io/PS-FCN/)**,

[Guanying Chen](https://guanyingc.github.io/), [Kai Han](http://www.hankai.org/), [Kwan-Yee K. Wong](http://i.cs.hku.hk/~kykwong/)

This paper addresses the problem of learning based photometric stereo for non-Lambertian surface.

### _Changelog_
- June 25, 2020: We have updated the code to support applying data normalization for handling surface with SVBRDFs, as introduced in the journal version of this work.
- July 27, 2019: We have already updated the code to support Python 3.7 + PyTorch 1.10. To run the previous version (Python 2.7 + PyTorch 0.40), please checkout to `python2.7` branch first (e.g., `git checkout python2.7`).

## Dependencies
PS-FCN is implemented in [PyTorch](https://pytorch.org/) and tested with Ubuntu 14.04, please install PyTorch first following the official instruction.
- Python 3.7
- PyTorch (version = 1.10)
- numpy
- scipy
- CUDA-9.0

## Overview
We provide:
- Datasets: Blobby dataset (4.7 GB), Sculpture dataset (19 GB)
- Trained models (on both the Blobby dataset and the Sculpture dataset with a per-sample input number of 32):
    - PS-FCN for calibrated photometric stereo
    - UPS-FCN for uncalibrated photometric stereo
- Code to test on DiLiGenT main dataset
- Code to train a new model

## Testing
#### Download the trained models
```shell
sh scripts/download_pretrained_models.sh
# You can find the downloaded model in ./data/models/
```
If the above command is not working, please manually download the trained models from One Drive ([PS-FCN and UPS-FCN](https://connecthkuhk-my.sharepoint.com/:f:/g/personal/u3004356_connect_hku_hk/Ehke8nHlpUdJmyVSw2ANUEEBnQf-aCaSxaNcTr2g274-PQ?e=feT9E2)) and put them in `./data/models/`.

#### Test on the DiLiGenT main dataset
```shell
# Download DiLiGenT main dataset
sh scripts/prepare_diligent_dataset.sh

# Test PS-FCN on DiLiGenT main dataset using all of the 96 image-light pairs
CUDA_VISIBLE_DEVICES=0 python eval/run_model.py --retrain data/models/PS-FCN_B_S_32.pth.tar --in_img_num 96
# You can find the results in data/Training/run_model/

# Test UPS-FCN on DiLiGenT main dataset only using images as input
CUDA_VISIBLE_DEVICES=0 python eval/run_model.py --retrain data/models/UPS-FCN_B_S_32.pth.tar --in_img_num 96 --in_light
```

## Training
To train a new PS-FCN model, please follow the following steps:
#### Download the training data
```shell
# The total size of the zipped synthetic datasets is 4.7+19=23.7 GB
# and it takes some times to download and unzip the datasets.
sh scripts/download_synthetic_datasets.sh
```
If the above command is not working, please manually download the training datasets from One Drive (PS Sculpture Dataset and PS Blobby Dataset) and put them in `./data/datasets/`.

#### Train PS-FCN and UPS-FCN
```shell
# Train PS-FCN on both synthetic datasets using 32 images-light pairs
CUDA_VISIBLE_DEVICES=0 python main.py --concat_data --in_img_num 32

# Train UPS-FCN on both synthetic datasets using 32 images
CUDA_VISIBLE_DEVICES=0 python main.py --concat_data --in_img_num 32 --in_light --item uncalib

# Please refer to options/base_opt.py and options/train_opt.py for more options

# You can find checkpoints and results in data/Training/
```

## Data Normalization for Handling SVBRDFs (TPAMI 2020)
#### Download the trained models
```shell
sh scripts/download_pretrained_TPAMI_models.sh
# You can find the downloaded model in ./data/models/
```
If the above command is not working, please manually download the trained model from One Drive (PS-FCN_normalize) and put it in `./data/models/`.

#### Test on the DiLiGenT main dataset
```shell
CUDA_VISIBLE_DEVICES=0 python eval/run_model.py --retrain data/models/PS-FCN_B_S_32_normalize.pth.tar --in_img_num 96 --normalize --train_img_num 32
# You can find the results in data/Training/run_model
```

#### Training
```shell
CUDA_VISIBLE_DEVICES=0 python main.py --concat_data --in_img_num 32 --normalize --item normalize
# You can find checkpoints and results in data/Training/normalize
```

## FAQ

#### Q1: How to test PS-FCN on other dataset?
- You have to implement a customized Dataset class to load your data. Please refer to `datasets/DiLiGenT_data.py` for an example that loads the DiLiGenT main dataset. Precomputed results on DiLiGenT main/test dataset, Gourd\&Apple dataset, Light Stage Dataset and Synthetic Test dataset are available upon request.

#### Q2: Which eight sculpture shapes were used in rendering the training datasets? Why?
- Normal maps of the eight selected sculpture shapes are shown in the below figure (filenames can be found in this [link](images/sculpture_list.txt)). We chose these 8 shapes for their high quality meshes and complex geometry. Other complex 3D objects can also be used.

#### Q3: What should I do if I have problem in running your code?
- Please create an issue if you encounter errors when trying to run the code. Please also feel free to submit a bug report.

#### Q4: Where can I download the Gourd&Apple dataset and Light Stage Data Gallery used in the paper?
- Gourd&Apple dataset is introduced in the paper [Photometric stereo with non-parametric and spatially-varying reflectance, Alldrin et al., CVPR 2008]. You may try to download this dataset from [Alldrin's homepage](http://vision.ucsd.edu/~nalldrin/research/). However, it seems that this link is not working now. You may send an email to the authors for this dataset. You can download the Light Stage Data Gallery from http://vgl.ict.usc.edu/Data/LightStage/. To test PS-FCN on these two datasets, please first preprocess and reorganize the images in a way similar to DiLiGent benchmark.

## Citation
If you find this code or the provided data useful in your research, please consider cite:
```
@inproceedings{chen2018ps,
  title={{PS-FCN}: A Flexible Learning Framework for Photometric Stereo},
  author={Chen, Guanying and Han, Kai and Wong, Kwan-Yee K.},
  booktitle={ECCV},
  year={2018}
  }
@article{chen2020deepps,
  title={Deep Photometric Stereo for Non-{Lambertian} Surfaces},
  author={Chen, Guanying and Han, Kai and Shi, Boxin and Matsushita, Yasuyuki and Wong, Kwan-Yee K.},
  journal={TPAMI},
  year={2020},
}
```

repository: guanyingc/PS-FCN

repo_name: guanyingc/PS-FCN


text:
# Multimedia Web Programming

In this course I was exposed to slightly more advanced concepts of creating a web page

## Project 1
This was just a simple web page stating who I was and some basic javascript to add in the current time that is constantly refreshed

## Project 2
This project was slightly more advanced and involved incorporating the google maps API into the page where you could move around the map, find your current location using the geolocation service, and lastly you could select pre-determined locations from a dropdown and the map will jump to the location and place a marker that you can click and have a brief blurb about the location that I hardcoded in

## Project 3
This project was to gain practice using JS canvas to draw things such as basic flowers, a vehicle, and an image

## Project 4
This project was dealing with animation. In this I have a troll sprite move across the screen with the arrow keys and when it reaches a certain point in the canvas a video will play in the bottom portion of the canvas.

## Project 5
This project was similar to a paint program, from a dropdown menu you can select a shape and color and by clicking on the screen or clicking and dragging on the screen, it will draw the shape with the color selected. This project also used caching so that you could leave the page and upon return, all the images that were drawn will remain unless the "clear" button is clicked which will clear the cache.

repository: adamcarlton/collegeCodeProjects

repo_name: adamcarlton/collegeCodeProjects


text:
# violet-air

## building and running

### prerequisites

You should have NodeJS and `yarn` (preferred) or `npm` installed.
Also, it's recommended to have `forever` installed globally to simplify development.

```
yarn global add forever
```

### building

```
yarn install
```

### running

```
yarn server
```

Then, start ngrok or any other tunnel like

```
ngrok http 8080
```

and adjust agent fullfilment webhook URL to `https://NGROKID.ngrok.io/google-assistant/webhook`

repository: codeminders/violet-air

repo_name: codeminders/violet-air