TypeError: handle_get_file_code() got an unexpected keyword argument 'save_all'

I get following error when I want to run any code in spyder in Anaconda.Do you know how can I resolve this?!:
This command failed to be executed because an error occurred while trying to get the file code from Spyder's editor. The error was:

An exception has occurred, use %tb to see the full traceback.

TypeError: handle_get_file_code() got an unexpected keyword argument 'save_all'

Anaconda
Versions

Spyder version: 4.1.3
Python version: 3.6.9
Qt version: 5.9.7
Operating System name/version: Ubuntu

Hey @mmahdavian, please update to Spyder 4.1.5 and try again. That should fix your problem.

Updating to 4.1.5 is what caused the problem, for me.  And it isn't fixed by downgrading back to 4.1.3 where I was before.

This happened to three of my computers as well. I fixed it by completely uninstalling anaconda and reinstalling the latest version. Not a great solution but it worked for me.

This sounds related to #13679 .
I was hit by this, and was able to fix it by installing spyder-kernels==1.9.3. I'm on spyder==4.1.2.

This problem is solved by running
conda install spyder-kernels 1.9.4

Same thing happened to me in a pip3 environment.  Reinstalling spyder-kernels worked for me (1.9.4 is the latest on pypi).

This problem is solved by running
conda install spyder-kernels=1.9.4

I have got the issue but this solution did not solve the problem

I was hit by this, and was able to fix it by installing spyder-kernels==1.9.3

Note that the workaround for spyder==4.1.2 is downgrading to this specific version.

Spyder: 4.1.4
spyder-kernels: 1.9.4
Python 3.7.7 64-bit | Qt 5.9.6 | PyQt5 5.9.2 | Windows 10
So I'm trying to debug a file. With F9 (Run selection) it runs, but with F5 (Run file) or Ctrl+F5 (Debug file) the same error occurs. Now reading these comments I'm not sure whether I should downgrade spyder-kernels or Spyder.

@theinexorable, Spyder 4.1.4 works with spyder-kernels 1.9.3, not with 1.9.4

update to the new version, its work for me
conda install spyder=4.1.5

edit the File spydercustomize.py:
lib/python3.7/site-packages/spyder_kernels/customize/spydercustomize.py", line 463, in get_file_code function:
file_code = frontend_request().get_file_code(
filename, save_all=save_all)
to:
file_code = frontend_request().get_file_code(filename)

update to the new version, its work for me
conda install spyder=4.1.5

Worked for me!

C Cordoba....what the hell have u done to spyder?????
its has been two months it all messed up
nothing works
have tried re-installing it...re-installing spyder kernels, and all the help on stackoverflow
nothing works
spyder doesnt just work at all
i want to throw it into dustbin

Got the same problem after upgrading to 4.1.3 and moved to 4.1.5 and it is now ok. thanks for the tip.

update to the new version, its work for me
conda install spyder=4.1.5

This worked for me! Thank You!

Thanks!

update to the new version, its work for me
conda install spyder=4.1.5

Thanks!

Getting this problem with spyder 4.1.6 and spyder-kernels 1.9.4

I dont know if it was uninstalling / reinstalling spyder or downgrading but now it works with 4.1.5

update to the new version, its work for me
conda install spyder=4.1.5

Thanks it work now. In case someone failed to insatll version 4.1.5 try to uninstall spyder completely then install it again.

yes upgrade from 4.1.3 to 4.1.5 works. Thanks a lot!!!

@kmanflickr
The latest version is 4.2.4 which has resolved a number of irritants.  I would recommend installing it.

@kmanflickr
The latest version is 4.2.4 which has resolved a number of irritants. I would recommend installing it.

Hey Thanks for your help. I think 4.2.3 is the last for windows OS. 4.2.4 is probably mac only

4.2.4 runs on MacOS and Linux.  I have no idea about Windows.

update to the new version, its work for me
conda install spyder=4.1.5

Thanks, this works for me


allow engine/name support in volumes

Fix https://github.com/docker/swarm/issues/1302

ping @mbentley can you please try this one ?

Looks great!  Thanks @vieux!
$ docker -H tcp://<IP_ADDRESS>:3375 info
Containers: 1
Images: 62
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 1
 localdev: <IP_ADDRESS>:2375
  └ Status: Healthy
  └ Containers: 1
  └ Reserved CPUs: 0 / 1
  └ Reserved Memory: 0 B / 2.061 GiB
  └ Labels: executiondriver=native-0.2, kernelversion=3.16.0-4-amd64, operatingsystem=Debian GNU/Linux stretch/sid (containerized), storagedriver=aufs
  └ Error: (none)
  └ UpdatedAt: 2016-01-22T02:30:26Z
CPUs: 1
Total Memory: 2.061 GiB
Name: 34f77f63050b
$ docker -H tcp://<IP_ADDRESS>:3375 volume ls
DRIVER              VOLUME NAME
local               localdev/haproxy
local               localdev/aa7d97f5ff6f4f60d64f5e19b3ca573938a27d5a803bea5e3560ce1a50f8c305

@abronan @dongluochen failure unrelated, I'm going to fix that in another version.
Please review

LGTM

LGTM.


fix(alert): use imported instead of inline classes

Depends on respective @warp-ds/component-classes changes and last-child class support

 Move inline classes from components to component-classes


Read worker harness image name from pipeline option for portable runners

The Environment is hardcoded in the container which makes it impossible for the user to provide a custom container.
Reading the container from PortablePipelineOptions.
Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.
 Exposing such a method will remove some repeated code.

Okay, this is fine with me for now, so I'm going to merge it, thanks!
However, I'm highly tempted to refactor things to make sure that, instead of repeatedly re-creating SdkComponents, we use them as a single "translation context" sort of object. I'll give this a shot after merging this PR.

Kenn is out on Paternity.
To my knowledge, the original idea was to go from PTransform/PCollection/... to proto form, create the job and then turn that proto back into a PTransform/PCollection/... when executing on a runner so a runner could re-use everything that was written for runner translation. This solution didn't work out great for a few reasons and was dropped in favor of trimming down to a set of utilities that runners actually need and that either work on the protos directly or create new runner specific interfaces/classes that simplify working with the protos.
So for portable runners, they should preferably use runner specific utilities or the protos directly. I have started to clean-up/delete code that shouldn't be used/relied on by runners for example in this PR but there is still a lot to go.

Amusingly, this conversation and #5833 finally came back around. Today I needed to serialize, transmit, then rehydrate an all-Java pipeline so I could pass it to a non-portable runner across a process boundary. 😉

I feel the need to cite the hypothetical #???? Drop support for non-portable runners.


Extended styled-component styles get overwritten with SSR

When using styled-components with V5 + NextJS, when extending core components the styles are overwritten by defaults.

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When using this theme:
const theme = createTheme({
  palette: {
    primary: {
      main: '#f00',
    },
    secondary: {
      main: '#00f',
    },
  },
});

With these components
import { ThemeProvider, Box, Button } from '@material-ui/core';
import styled from 'styled-components';

const Example = styled(Box)`
  ${({ theme }) => {
    return {
      backgroundColor: theme.palette.primary.main,
      width: '200px',
      height: '200px',
    }
  }}
`;

const Example2 = styled(Button)`
  border: none;
`;

<ThemeProvider>
  <Example bgcolor="secondary.main" />
  <Example2 variant="outlined">Test</Example2>
</ThemeProvider>

I get this result:

The problem happens with <StyledEngineProvider injectFirst /> and without.
Expected Behavior 🤔
The styles given in the styled() definitions should take priority and be injected after the defaults.
Steps to Reproduce 🕹
Using the new nextjs styled-components example:
https://codesandbox.io/s/festive-dew-kh20g (content in pages/_app.js)
Steps:

Clone the
Create a styled component that extends off a core component with base styles

Context 🔦
This has happened when I was trying to change a button border from within styled-components. I'm aware this is possible through the theme but I needed some extra customisation.
Your Environment 🌎

`npx @material-ui/envinfo`
  Chrome 91.0.4472.164
  System:
    OS: macOS 11.2.3
  Binaries:
    Node: 12.22.1 - ~/.nvm/versions/node/v12.22.1/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v12.22.1/bin/yarn
    npm: 6.14.12 - ~/.nvm/versions/node/v12.22.1/bin/npm
  Browsers:
    Chrome: 91.0.4472.164
    Edge: Not Found
    Firefox: 89.0.2
    Safari: 14.0.3
  npmPackages:
    @material-ui/core: next => 5.0.0-beta.1
    @material-ui/private-theming:  5.0.0-beta.1
    @material-ui/styled-engine:  5.0.0-beta.1
    @material-ui/styled-engine-sc: next => 5.0.0-beta.1
    @material-ui/system:  5.0.0-beta.1
    @material-ui/types:  6.0.1
    @material-ui/unstyled:  5.0.0-alpha.40
    @material-ui/utils:  5.0.0-beta.0
    @types/react: latest => 17.0.14
    react: latest => 17.0.2
    react-dom: latest => 17.0.2
    styled-components: latest => 5.3.0
    typescript: latest => 4.3.5

@finleygn I've created a clean repository - https://github.com/mnajdova/27412-nextjs-with-styled-components Could we iterate on this? I don't think code sandbox is very reliable, got failing errors as soon as I tried importing something more from core.
I've added Button components on the index page, both using styled from styled-components and @material-ui/core/styles and it looks like it works. Can you check?

The issue may be related to https://github.com/styled-components/styled-components/issues/3321 I was able to randomly reproduce the issue when refreshing the page.

I've found out that the babel-plugin-styled-components allows defining top level import paths, so I tried defining the option:
"topLevelImportPaths": ["@material-ui/core/styles"]

in the options, but it didn't help. Will spend some more time on this next week.

@finleygn I've created a clean repository - https://github.com/mnajdova/27412-nextjs-with-styled-components Could we iterate on this? I don't think code sandbox is very reliable, got failing errors as soon as I tried importing something more from core.
I've added Button components on the index page, both using styled from styled-components and @material-ui/core/styles and it looks like it works. Can you check?

styled-components works on first load then consistently breaks on refresh, seemingly always works with build.
No problems with @material-ui/core/styles.

@finleygn would be great if you can upgrade to the latest styled-components version that would include https://github.com/styled-components/styled-components/pull/3563 and see if the issue still persists.


Code refactoring

Codecov Report

Merging #88 (b7d9402) into master (64aa217) will decrease coverage by 1.02%.
The diff coverage is 95.50%.

:exclamation: Current head b7d9402 differs from pull request most recent head bbb3bfa. Consider uploading reports for the commit bbb3bfa to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##           master      #88      +/-   ##
==========================================
- Coverage   97.09%   96.07%   -1.02%
==========================================
  Files          14       27      +13
  Lines        1409     1403       -6
==========================================
- Hits         1368     1348      -20
- Misses         41       55      +14

Impacted Files
Coverage Δ

source/argparse/config.d
87.50% <ø> (ø)

source/argparse/internal/commandinfo.d
0.00% <0.00%> (ø)

source/argparse/internal/utils.d
100.00% <ø> (ø)

source/argparse/internal/argumentuda.d
77.04% <33.33%> (-21.29%)
:arrow_down:

source/argparse/internal/arguments.d
97.08% <62.50%> (-2.92%)
:arrow_down:

source/argparse/internal/hooks.d
66.66% <62.50%> (-33.34%)
:arrow_down:

source/argparse/internal/argumentparser.d
86.66% <86.66%> (ø)

source/argparse/api/cli.d
91.17% <91.17%> (ø)

source/argparse/internal/valueparser.d
93.84% <91.30%> (ø)

source/argparse/internal/command.d
93.75% <93.75%> (ø)

... and 17 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Fix the build for the master branch for synapse.

When the master branch of complement is built we want to run against the default homeserver branch, not the master branch (which will most likely always exist).

I don't know for sure this will work until it's on master though. 😢

Isn't the default branch HEAD? I use this in Dendrite upgrade tests.

From the GitHub docs:

GITHUB_HEAD_REF: Only set for pull request events. The name of the head branch.

So yes, this doesn't seem correct. The other option is:

GITHUB_REF: The branch or tag ref that triggered the workflow. For example, refs/heads/feature-branch-1. If neither a branch or tag is available for the event type, the variable will not exist.

I suspect I need to use that one.
I'm not sure what you mean by the default branch being HEAD though. HEAD is just a pointer to the commit you have checked out.

I think the updated version I have now will work correctly.


tensorbaord graph broken for multi-gpu (cifar10 example)

GitHub issues are for bugs / installation problems / feature requests.
For general support from the community, see StackOverflow.
To make bugs and feature requests more easy to find and organize, we close issues that are deemed
out of scope for GitHub Issues and point people to StackOverflow.
For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
Environment info
CentOS 6 (64 bit) + NVidia K80
Installed version of CUDA and cuDNN:
CUDA 7.5, cuDNN v4
If installed from binary pip package, provide:

Which pip package you installed.
The lateset (0.9 with GPU)
The output from python -c "import tensorflow; print(tensorflow.__version__)".
0.9.0

Steps to reproduce

Locate the cifar10 example https://github.com/tensorflow/tensorflow/tree/master/tensorflow/models/image/cifar10
run "python cifar10_multi_gpu_train.py --num_gpus=2"
Check the tensorboard results from events. The "GRAPHS" doesn't look right

What have you tried?

I tried to run the single GPU version of cifar10 example "python cifar10_train.py", Tensorboard graph looks normal
I tried "python cifar10_multi_gpu_train.py --num_gpus=1", Tensorboard graph broken
I didn't try a early version of tensorflow this time, but I remember the Tensorboard used to work with the cifar10 multi-gpu example

Logs or other output that would be helpful
(If logs are large, please upload as attachment).

Same problem for imagenet multi-GPU training.

Hi @JianbangZ ! Thanks for reporting.
The reason why the multi-GPU graph looks like that is because the namescoping in the multi-GPU version creates tower_N namespaces that have incoming edges (tensors) above a certain threshold, at which point we extract those nodes on the side since usually they end up being auxiliary and not part of the main net architecture.
If we don't extract nodes on the side, many graphs will be highly intertwined and un-readable. The current threshold for incoming edges was decided empirically, but as this example suggest, it is not ideal. We will try out different thresholds and heuristics and get back to you!

Hi @dsmilkov  is this issue fixed in 0.10.0?

Assuming this was fixed in later versions. Feel free to open a new issue if the problem persists with new code.


Does the extension need the presence of PowerShell?

hi, i wonder if the tool strictly needs PowerShell as it is disabled on my laptop, and any commend to related to GHCI does not work.

Oh
Yeah this needs powershell to work
Sorry


Redis equivalent of DatabaseURLValue?

We have a DatabaseURLValue() which uses dj_database_url.
What about something for Redis that uses dj_redis_url?  That'd be cool.
Right now, I just do:
REDIS_URL = values.Value()

If we're agreed, will submit a PR for it.

Not sure if it's worth the overhead (of installing some package etc) - since Redis URLs are simpler in general and have no password even often.
But then it is your (or the user's) decision.. ;)
I'm +0.
(for reference)

Oh, you can already do it with https://github.com/ghickman/django-cache-url and CacheURLValue.


Add tests to validate ra-management routes permissions

https://www.pivotaltracker.com/n/projects/1163646/stories/163692589


Add json and yaml (encode/decode) to starlark function context

I want to be able to read and write yaml ad json strings in starlark functions.
My specific use case is to write a json or yaml payload to a KRM annotation string value.

Fixed by #570
Thanks!


Parser Error: Cannot find property "rotated" on base "Basis"

Godot version:
v4.0.dev.custom_build.ea21b8ff8
OS/device including version:
Windows 10 version 2004
Issue description:
I am trying a code that works on v3.2.3 to use gyroscope to rotate an object
func rotate_by_gyro(p_gyro, p_basis, p_delta):
	var b = Basis()

	b = b.rotated(p_basis.x, -p_gyro.x * p_delta)
	b = b.rotated(p_basis.z, -p_gyro.z * p_delta)

	return b * p_basis

but I get an error Parser Error: Cannot find property "rotated" on base "Basis". this used to work on previous builds of godot v4.0
also when I check the help for Basis I get this:

Steps to reproduce:
use the following code to reproduce
func rotate_by_gyro(p_gyro, p_basis, p_delta):
	var b = Basis()

	b = b.rotated(p_basis.x, -p_gyro.x * p_delta)
	b = b.rotated(p_basis.z, -p_gyro.z * p_delta)

	return b * p_basis

func _physics_process(delta):
	var gyro = Input.get_gyroscope()
	var new_basis = rotate_by_gyro(gyro, $Area3D.transform.basis, delta).orthonormalized()
	print(new_basis)

This is likely a regression from https://github.com/godotengine/godot/pull/42826.

String class have 3 missing functions:

begins_with
find
replace

In code they look different than others:
https://github.com/godotengine/godot/blob/c8716734ebad5fd34ead55bd0106b0f6cba16d9d/core/variant_call.cpp#L1365-L1369


DefaultCommandPrefix confuses auto-completion and breaks install-module

I'm the maintainer of a small Powershell Module called "ACME-PS", the module uses DefaultCommandPrefix in it's psd1.
This seems to have downsides, and should at least be documented or event "not recommended to use" (or maybe even marked obsolete)
Steps to reproduce
Install-Module ACME-PS # will fail, because missing, but misleading -AllowClobber
Install-Module ACME-PS -AllowClobber

Type "Get-Ord[TAB]" (completes to get-order)
Press [Enter].
Expected behavior
Auto-Completion should not complete to Get-Order, since DefaultCommandPrefix is ACME
Actual behavior
Don't Auto-Complete the command, since it should be "Get-ACMEOr[TAB]" which auto-completes.
Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

PoweShellGet module is being rewritten and command clobbering is on by default so -AllowClobber will no longer be a parameter, however there are some issues with it. I've open a couple of them when trying to reproduce your issue.
https://github.com/PowerShell/PowerShellGet/issues/204
https://github.com/PowerShell/PowerShellGet/issues/203
Here is a related issue when using DefaultCommandPrefix and module loading: https://github.com/PowerShell/PowerShell/issues/12858
cc: @mklement0

Do we have any idea, if the problems will be fixed?
I prepared a new module version, which ditches the DefaultCommandPrefix for a static one (as seen in PSDbaTools, e.g.), but I'm unsure, if I want to go down that road or not.

It looks to me the module analysis code can be improved to take into account the DefaultCommandPrefix setting in .psd1 file.
@ThomasNieto Can you please explain to me why -AllowClobber is required in this case?

@daxian-dbw I tested with PSGet v3 and -NoClobber command producing these two issues:
PowerShell/PowerShellGet#204
PowerShell/PowerShellGet#203
I was not able to reproduce requiring -AllowClobber in PSGet v2 as the OP indicated. There might be something on the OP system that is causing that.
I did do some tests on PS 5.1 and PS 7.0.3 with PSGet <IP_ADDRESS>. Command conflict checking is working as expected on PS 5.1 but does not properly check on PS 7.0.3. My testing methodology is below:
I tested by checking if there any commands with *acme* prior to install, confirmed there were none, then installed as normal. Then I created a module manifest with FunctionsToExport with a value of Get-Account which is one of the command shipped in acme-ps with default command prefix of acme and still installed as expected.
To test the command conflict I updated the module to have the command Get-AcmeAccount and then installing acme-ps produced the command conflict error only on PS 5.1 but didn't on PS 7.0.3.
The last test was to see if DefaultCommandPrefix was working so I updated the function to Get-Account with a DefaultCommandPrefix of amce, both PS 5.1 and 7.0.3 threw the error as expected.
I know this was a lot but I can put it in a pester test if needed.

The -AllowClobber message came from the module having Export-(ACME)Certificate clashing with Export-Certificate.
(This also affects Invoke-ScriptAnalyzer as it'll warn about clobbering Export-Certificate.)
Nevertheless I cannot reproduce it again, but I had issues with PowerShellGet, making me remove all modules and clear $env:PSModulePath, so it might really be something on my machine, or an older PSGet Version, which issued that error.
Thanks for your analysis so far 👍


fixed typo in README. retrofit was typed as retriofit as gradle depen…

…dency. also removed gson requirement. that is included with retrofit.

:+1:

looks good thanks!


[tr] new contributors are added to _index.md page

Describe your changes
Related issue number or link (ex: resolves #issue-number)
Checklist before opening this PR (put x in the checkboxes)

[ ] This PR does not contain plagiarism

don’t copy other people’s work unless you are quoting and contributing it to them.

[ ] I have signed off on all commits

signing off (ex: git commit -s) is to affirm that commits comply DCO. If you are working locally, you could add an alias to your gitconfig by running git config --global alias.ci "commit -s".

@aliok Please feel free to open a new PR for dev-tr -> main to apply the ack names in this PR. :)

@0ZeKa0
Now that dev-tr branch is merged to main, can you rebase your commit onto main and create this PR against main? Or start from scratch ;)

Does changes work as expected @aliok ?

I might have misdirected you folks. Let's see the answer for this comment: https://github.com/cncf/glossary/pull/2939#issuecomment-1972774029

@0ZeKa0
Sorry, I was wrong earlier. I thought we can now work against the main branch, but the Glossary development workflow requires us to still work against the dev-tr branch.
See https://cloud-native.slack.com/archives/C02N2RGFXDF/p1709745926614219
Can you change this PR to target dev-tr again? Sorry for the inconvenience.

done

@0ZeKa0 we're almost there :) Can you sign off your commits and push them again please?


Inline storage for instance fields and frame locals

Currently (before this PR), in the bytecode interpreter, instance fields and frame locals are stored within vectors (as Vec<Value>).
This means that to reach them, one needs to first dereference two pointers.
In the example of a class instance (stored as SOMRef<Instance>), one needs to:

dereference once to get to the instance struct.
dereference again to get to the field value within the vector of fields.

Due to the vector being a separate allocation, it is very likely that this causes cache misses, slowing down the program.
This PR uses raw pointer arithmetic, a bit of unsafe, and coordination with the GC to allocate additional space right besides the class instance (or stack frame) to store the fields (or locals) into, rather than into a separate vector, and uses pointer offsets to implement accesses, hopefully improving locality and therefore improving cache hit rates.
Depends on #33.

Current results on our machines: https://rebench.stefan-marr.de/som-rs/compare/aa52b413ea453d496882546092419c839d56633f..a596c147c4b629fa1feaa89be2767744fb34e134
Assuming I didn't mess up the comparison (I don't think I did), it's a big slowdown - though not on FieldLoop for some reason?


Localize last value timestamp on measurements tab

The timestamp of the last value's transmission is not localized according to the chosen site language. Especially the 12-hour time format is annoying to German visitors. Also, it would be nice to right-align the timestamp so that both value and timestamp can be read more easily.

Using localized timestamps, determined by your browser's locale (Javascript's "short" timestamp format)


User/sachinta/add microsoft internal telemetry nuget package config

Add microsoft internal telemetry nuget package config
Remove unnecessary inclusion of microsofttelemetry.h as <wil/traceloggingconfig.h> provides the same stub functionality from public WIL nuget package
Update search for WindowsAppSDK-VersionInfo.h header includes current directory as the build pipeline is updated to copy the file to installer project folder for it's inclusion.

Testing:
These changes have been tested by verifying the installer from the build pipeline is generating the telemetry events as expected.
NOTE: These changes will need to be pulled into 1.1-preview1 branch after it's merged to main.

/azp run


Add unittest to check for specific repo files

This repo should have the following list of files included:

./Docker or docker/Docker
./docker-compose.yml or ./docker/docker-compose.yml
./.env_sample
./.gitignore
./.travis.yml
./.codeclimate.yml
./CHANGELOG.md
./CODE_OF_CONDUCT.md
./CONTRIBUTING.md
./.github/ISSUE_TEMPLATE
./LICENSE.md
./.github/PULL_REQUEST_TEMPLATE
./README.md
./TROUBLESHOOTING.md
./USAGE.md
./USE_CASES.md

This PR is only asking for tests of the existence of these files, if the files do not exist when you run the tests - do not worry about the tests not passing. We will identify this and create a new PR for the issue.
Thank you!

@thinkingserious Can I take this issue to fix?

All you @luan-cestari

Hi, Created the PR  #55


[T3A5][W15-A2] Gng Jia Hui

ready for review

Some comments added. Feel free to add more comment if you have any questions. Once you are done, you may close the PR after reading comments.


Add print link component

What
This component adds a link that includes a print icon and can be used to help users print a page. By default this component relies on JavaScript by calling the browser print action via JavaScript in the href and is automatically hidden in non-JavaScript environments.
To support applications (e.g. Government Frontend) with print links that do not need JavaScript i.e. href=blah/print, this component allows a custom href to be defined and makes sure the link is displayed in non-JavaScript environments.
Why
This pattern was originally implemented in the Government Frontend application, however we'd like to re-use this component in Smart Answers.
We considered using a onclick event handler to call window.print(), however it was unclear what value to set the href  - as some browsers have different behaviour with links without hrefs.
Visual Changes

@andysellick Thanks for the review! I've addressed the suggested changes.

@andysellick, @alex-ju - I've PR with a button/link implementation.


Retired pages being served from the API

This request from my Science Gossip browser session (user tfmorris):
https://api.zooniverse.org/projects/illustratedlife/groups/54f4b81b30017b04c9000009/subjects?limit=10
returned the following response, which, as far as I can tell, includes 10 pages that shouldn't be displayed because they're all complete/retired.
Perhaps the front end should be sanity checking the data that receives to help catch backend API bugs like this.
[
{
"id": "54f4b8a230017b04c9003685",
"activated_at": "2015-03-07T07:05:47Z",
"classification_count": 13,
"coords": [
],
"created_at": "2015-03-03T19:21:00Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b8a230017b04c9003685.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b8a230017b04c9003685.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45554",
  "no_illustrations_count": 13,
  "original_size": {
    "width": 1680,
    "height": 2974
  },
  "page_id": "12643735",
  "page_no": null,
  "page_seq": "441",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.33=no.99-102 (1903-1904)",
  "year": "1904 - 1904",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.1300746338013,
"state": "complete",
"updated_at": "2015-05-14T14:07:44Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000tcf"
},
{
"id": "54f4b89930017b04c9003295",
"activated_at": "2015-03-07T07:06:11Z",
"classification_count": 24,
"coords": [
],
"created_at": "2015-03-03T19:21:45Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b89930017b04c9003295.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b89930017b04c9003295.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "has_illustrations_count": 1,
  "item_id": "45543",
  "no_illustrations_count": 21,
  "original_size": {
    "width": 1670,
    "height": 2765
  },
  "page_id": "12639979",
  "page_no": "Page 325",
  "page_seq": "375",
  "retire_reason": "detected_no_illustrations",
  "skip_count": 2,
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.30=no.89-92 (1898-1899)",
  "year": "1899 - 1899"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.24718672008463,
"state": "complete",
"updated_at": "2015-05-14T14:12:49Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000tw5"
},
{
"id": "54f4b8e630017b04c9005281",
"activated_at": "2015-03-07T07:04:10Z",
"classification_count": 16,
"coords": [
],
"created_at": "2015-03-03T19:17:48Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b8e630017b04c9005281.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b8e630017b04c9005281.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "has_illustrations_count": 1,
  "item_id": "45628",
  "no_illustrations_count": 15,
  "original_size": {
    "width": 1716,
    "height": 2750
  },
  "page_id": "12676413",
  "page_no": "Page 239",
  "page_seq": "271",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.21=no.61-63 (1883-1884)",
  "year": "1884 - 1884",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.23190000775097,
"state": "complete",
"updated_at": "2015-05-14T13:46:39Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000r1z"
},
{
"id": "54f4b86630017b04c9001c51",
"activated_at": "2015-03-07T07:07:36Z",
"classification_count": 6,
"coords": [
],
"created_at": "2015-03-03T19:24:08Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b86630017b04c9001c51.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b86630017b04c9001c51.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45246",
  "no_illustrations_count": 6,
  "original_size": {
    "width": 1690,
    "height": 2781
  },
  "page_id": "12541446",
  "page_no": "Page 41",
  "page_seq": "61",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.16=no.46-48 (1876)",
  "year": "1876 - 1876",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.18323028438107,
"state": "complete",
"updated_at": "2015-05-14T14:29:07Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000vqe"
},
{
"id": "54f4b91a30017b04c9006999",
"activated_at": "2015-03-07T07:02:17Z",
"classification_count": 12,
"coords": [

],
"created_at": "2015-03-03T19:13:21Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b91a30017b04c9006999.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b91a30017b04c9006999.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "has_illustrations_count": 3,
  "item_id": "47884",
  "no_illustrations_count": 8,
  "original_size": {
    "width": 1757,
    "height": 2785
  },
  "page_id": "13375087",
  "page_no": "Page 211",
  "page_seq": "233",
  "retire_reason": "detected_no_illustrations",
  "skip_count": 1,
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.6=no.16-18 (1859-1860)",
  "year": "1860"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.72890073079946,
"state": "complete",
"updated_at": "2015-05-14T13:22:33Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000ogk"
},
{
"id": "54f4b8c430017b04c9004667",
"activated_at": "2015-03-07T07:04:43Z",
"classification_count": 20,
"coords": [
],
"created_at": "2015-03-03T19:19:05Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b8c430017b04c9004667.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b8c430017b04c9004667.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45620",
  "no_illustrations_count": 20,
  "original_size": {
    "width": 1706,
    "height": 2792
  },
  "page_id": "12673562",
  "page_no": null,
  "page_seq": "402",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.23=no.67-69 (1886-1887)",
  "year": "1887 - 1887",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.6954472069182,
"state": "complete",
"updated_at": "2015-05-14T13:54:40Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000rva"
},
{
"id": "54f4b91130017b04c90065ab",
"activated_at": "2015-03-07T07:02:32Z",
"classification_count": 10,
"coords": [
],
"created_at": "2015-03-03T19:13:57Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b91130017b04c90065ab.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b91130017b04c90065ab.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "47627",
  "no_illustrations_count": 10,
  "original_size": {
    "width": 1674,
    "height": 2827
  },
  "page_id": "13271520",
  "page_no": "Page 104",
  "page_seq": "140",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.1=no.1-3 (1854)",
  "year": "1854",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.2077528770939,
"state": "complete",
"updated_at": "2015-10-15T00:21:12Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000osn"
},
{
"id": "54f4b84830017b04c9001039",
"activated_at": "2015-03-07T07:08:29Z",
"classification_count": 25,
"coords": [
],
"created_at": "2015-03-03T19:25:34Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b84830017b04c9001039.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b84830017b04c9001039.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45242",
  "no_illustrations_count": 25,
  "original_size": {
    "width": 1705,
    "height": 2812
  },
  "page_id": "12539898",
  "page_no": "Page 111",
  "page_seq": "137",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.10=no.28-30 (1866-1867)",
  "year": "1867 - 1867",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.92739502965752,
"state": "complete",
"updated_at": "2015-05-14T14:39:02Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000wva"
},
{
"id": "54f4b86b30017b04c9001ea9",
"activated_at": "2015-03-07T07:07:08Z",
"classification_count": 13,
"coords": [
],
"created_at": "2015-03-03T19:23:24Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b86b30017b04c9001ea9.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b86b30017b04c9001ea9.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45246",
  "no_illustrations_count": 12,
  "original_size": {
    "width": 1690,
    "height": 2781
  },
  "page_id": "12541746",
  "page_no": "Page 299",
  "page_seq": "361",
  "retire_reason": "detected_no_illustrations",
  "skip_count": 1,
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.16=no.46-48 (1876)",
  "year": "1876 - 1876"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.019743549360336,
"state": "complete",
"updated_at": "2015-05-14T14:23:51Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000v62"
},
{
"id": "54f4b87930017b04c90024a9",
"activated_at": "2015-03-07T07:07:06Z",
"classification_count": 8,
"coords": [
],
"created_at": "2015-03-03T19:23:21Z",
"group": {
  "_id": "54f4b81b30017b04c9000009",
  "zooniverse_id": "GSC0000007",
  "name": "wiltshirearchaeo"
},
"group_id": "54f4b81b30017b04c9000009",
"location": {
  "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b87930017b04c90024a9.jpg",
  "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b87930017b04c90024a9.jpg"
},
"metadata": {
  "contributor": "Natural History Museum Library, London",
  "item_id": "45248",
  "no_illustrations_count": 8,
  "original_size": {
    "width": 1664,
    "height": 2750
  },
  "page_id": "12542514",
  "page_no": "Page 265",
  "page_seq": "295",
  "sponsor": "Natural History Museum Library, London",
  "volume": "v.12=no.34-36 (1869-1870)",
  "year": "1870 - 1870",
  "retire_reason": "detected_no_illustrations"
},
"project_id": "54f42c0ab35d2e06bd000001",
"random": 0.59960723848995,
"state": "complete",
"updated_at": "2015-05-14T14:23:27Z",
"workflow_ids": [
  "54f42c32b35d2e06bd000002"
],
"zooniverse_id": "ASC0000v4g"
}
]

Here's a summary of the classification stats for the pages.  Some empty pages have been classified as empty 25 out of 25 times!  Also below is the request/response header data in case it's needed.
zooniverse_id	state	classification_count	no_illustrations_count	has_illustrations_count	skip_count	updated_at	retire_reason ASC0000tcf	complete	13	13			2015-05-14T14:07:44Z	detected_no_illustrations ASC0000tw5	complete	24	21	1	2	2015-05-14T14:12:49Z	detected_no_illustrations ASC0000r1z	complete	16	15	1		2015-05-14T13:46:39Z	detected_no_illustrations ASC0000vqe	complete	6	6			2015-05-14T14:29:07Z	detected_no_illustrations ASC0000ogk	complete	12	8	3	1	2015-05-14T13:22:33Z	detected_no_illustrations ASC0000rva	complete	20	20			2015-05-14T13:54:40Z	detected_no_illustrations ASC0000osn	complete	10	10			2015-10-15T00:21:12Z	detected_no_illustrations ASC0000wva	complete	25	25			2015-05-14T14:39:02Z	detected_no_illustrations ASC0000v62	complete	13	12		1	2015-05-14T14:23:51Z	detected_no_illustrations ASC0000v4g	complete	8	8			2015-05-14T14:23:27Z	detected_no_illustrations
Remote Address:<IP_ADDRESS>:443
Request URL:https://api.zooniverse.org/projects/illustratedlife/groups/54f4b81b30017b04c9000009/subjects?limit=10
Request Method:GET
Status Code:200 OK
Response Headers
view source
Access-Control-Allow-Headers:Origin,Accept,Content-Type,X-Requested-With,X-CSRF-Token,Authorization,Authentication,X-Zooniverse-Origin
Access-Control-Allow-Methods:GET,POST,PUT,DELETE
Access-Control-Allow-Origin:*
Cache-Control:must-revalidate, private, max-age=0
Connection:keep-alive
Content-Length:11121
Content-Type:application/json; charset=utf-8
Date:Wed, 21 Oct 2015 18:44:27 GMT
ETag:"48727871349146c93d78ecc625557839"
Server:nginx/1.4.6 (Ubuntu)
Status:200 OK
Strict-Transport-Security:max-age=31536000
X-Rack-Cache:miss
X-Request-Id:8c044901caf351f9c387422e890bc989
X-Runtime:0.040934
Request Headers
view parsed
GET /projects/illustratedlife/groups/54f4b81b30017b04c9000009/subjects?limit=10 HTTP/1.1
Host: api.zooniverse.org
Connection: keep-alive
Accept: application/json, text/javascript, /; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Authorization: Basic dGZtb3JyaXM6MjYwZDdhODIyMTZjNWIyNTA1MGM=
X-Zooniverse-Origin: http://www.sciencegossip.org
DNT: 1
Referer: https://api.zooniverse.org/proxy
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: _ga=GA1.2.1407205209.1440527985; current_user=BAgiHTUwYmUxOTg2OTE3N2QwNjM5NjAwMGUyYQ%3D%3D--a71e04b05d43cb417064ac30718a187a799ff643; _Ouroboros_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFVEkiJTZlZjRiOTY1NTM1Y2RlOWY1ZGI4NWFjMDRmOGNhZjAxBjsAVEkiEWN1cnJlbnRfdXNlcgY7AEZ7CjoSem9vbml2ZXJzZV9pZEkiDDExNTQ1MjkGOwBUOgluYW1lSSINdGZtb3JyaXMGOwBUOgxhcGlfa2V5SSIZMjYwZDdhODIyMTZjNWIyNTA1MGMGOwBUOgplbWFpbEkiF3RmbW9ycmlzQGdtYWlsLmNvbQY7AFQ6B2lkbzoTQlNPTjo6T2JqZWN0SWQGOgpAZGF0YVsRaVVpAb5pHmkBhmkBkWl8aQHQaWhpAZZpAGkTaS8%3D--12ac77cc838d3835d45b400f97c1873172b181ce
If-None-Match: "4cfde5e75473135c872133fe98d5ff98"
Query String Parameters
view parsed
limit=10

I was originally working on a single periodical and thought perhaps that had something to do with the problem (it was also 95%+ complete), but when I tried again asking for a random pages, I got a similar result:
https://api.zooniverse.org/projects/illustratedlife/groups/random/subjects?limit=10
This batch has 6/10 marked as complete, although strangely one of the complete ones only has a single classification.
[
  {
    "id": "54f4baaa30017b04c9011725",
    "activated_at": "2015-03-03T20:06:26Z",
    "classification_count": 7,
    "coords": [

    ],
    "created_at": "2015-03-03T19:49:26Z",
    "group": {
      "_id": "54f4b81b30017b04c9000005",
      "zooniverse_id": "GSC000000a",
      "name": "quarterlyjourna"
    },
    "group_id": "54f4b81b30017b04c9000005",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4baaa30017b04c9011725.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4baaa30017b04c9011725.jpg"
    },
    "metadata": {
      "contributor": "Smithsonian Libraries",
      "has_illustrations_count": 2,
      "item_id": "108770",
      "no_illustrations_count": 5,
      "original_size": {
        "width": 1955,
        "height": 3223
      },
      "page_id": "34985294",
      "page_no": "Page 281",
      "page_seq": "339",
      "sponsor": "Biodiversity Heritage Library",
      "volume": "v.28 (1872)",
      "year": "1872",
      "retire_reason": "detected_no_illustrations"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.86838392882597,
    "state": "complete",
    "updated_at": "2015-05-14T16:06:48Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0001g29"
  },
  {
    "id": "55e96aeaa71c5200410081f1",
    "activated_at": "2015-10-13T20:03:35Z",
    "classification_count": 0,
    "coords": [

    ],
    "created_at": "2015-09-04T13:52:50Z",
    "group": {
      "_id": "55e969fca71c52004100000b",
      "zooniverse_id": "GSC000000g",
      "name": "journalofquekett"
    },
    "group_id": "55e969fca71c52004100000b",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/55e96aeaa71c5200410081f1.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/55e96aeaa71c5200410081f1.jpg"
    },
    "metadata": {
      "contributor": "MBLWHOI Library",
      "item_id": "18445",
      "original_size": {
        "width": 2325,
        "height": 3786
      },
      "page_id": "2032371",
      "page_no": "Page 293",
      "page_seq": "345",
      "sponsor": "MBLWHOI Library",
      "volume": "ser. 2, v. 3 (1886-1888)",
      "year": "1886-1888"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.82844050971594,
    "state": "active",
    "updated_at": "2015-09-04T13:52:50Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0003ekh"
  },
  {
    "id": "5527afb3a092de04cc003e8d",
    "activated_at": "2015-05-14T12:02:41Z",
    "classification_count": 2,
    "coords": [

    ],
    "created_at": "2015-04-10T12:47:41Z",
    "group": {
      "_id": "54f4b81b30017b04c9000003",
      "zooniverse_id": "GSC0000009",
      "name": "gardenersmagazin2"
    },
    "group_id": "54f4b81b30017b04c9000003",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/5527afb3a092de04cc003e8d.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/5527afb3a092de04cc003e8d.jpg"
    },
    "metadata": {
      "contributor": "Smithsonian Libraries",
      "item_id": "100602",
      "no_illustrations_count": 2,
      "original_size": {
        "width": 1830,
        "height": 3177
      },
      "page_id": "32278967",
      "page_no": "Page 743",
      "page_seq": "757",
      "sponsor": "Biodiversity Heritage Library",
      "volume": "v. 8 (1832)",
      "year": "1832"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.52932118833473,
    "state": "active",
    "updated_at": "2015-04-10T12:47:41Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0002rqk"
  },
  {
    "id": "55e96b39a71c52004100aed3",
    "activated_at": "2015-10-13T20:01:01Z",
    "classification_count": 1,
    "coords": [

    ],
    "created_at": "2015-09-04T13:40:40Z",
    "group": {
      "_id": "55e969fca71c52004100000b",
      "zooniverse_id": "GSC000000g",
      "name": "journalofquekett"
    },
    "group_id": "55e969fca71c52004100000b",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/55e96b39a71c52004100aed3.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/55e96b39a71c52004100aed3.jpg"
    },
    "metadata": {
      "contributor": "MBLWHOI Library",
      "item_id": "28111",
      "no_illustrations_count": 1,
      "original_size": {
        "width": 2214,
        "height": 3648
      },
      "page_id": "5509071",
      "page_no": null,
      "page_seq": "532",
      "sponsor": "MBLWHOI Library",
      "volume": "ser. 2, v. 13 (1916-1918)",
      "year": "1916-1918"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.61351394370011,
    "state": "active",
    "updated_at": "2015-09-04T13:40:40Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC00030hi"
  },
  {
    "id": "5527afa5a092de04cc003699",
    "activated_at": "2015-05-14T12:02:06Z",
    "classification_count": 3,
    "coords": [

    ],
    "created_at": "2015-04-10T12:46:53Z",
    "group": {
      "_id": "54f4b81b30017b04c9000003",
      "zooniverse_id": "GSC0000009",
      "name": "gardenersmagazin2"
    },
    "group_id": "54f4b81b30017b04c9000003",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/5527afa5a092de04cc003699.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/5527afa5a092de04cc003699.jpg"
    },
    "metadata": {
      "contributor": "Smithsonian Libraries",
      "has_illustrations_count": 3,
      "item_id": "100547",
      "original_size": {
        "width": 1836,
        "height": 3178
      },
      "page_id": "32255927",
      "page_no": "Page 247",
      "page_seq": "261",
      "sponsor": "Biodiversity Heritage Library",
      "volume": "v. 2",
      "year": null
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.21774655131351,
    "state": "active",
    "updated_at": "2015-04-10T12:46:53Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0002qul"
  },
  {
    "id": "54f43a8aefc50104c300300d",
    "activated_at": "2015-03-30T15:02:14Z",
    "classification_count": 1,
    "coords": [

    ],
    "created_at": "2015-03-02T13:26:57Z",
    "group": {
      "_id": "54f4302befc50104c3000001",
      "zooniverse_id": "GSC0000001",
      "name": "hardwickesscien"
    },
    "group_id": "54f4302befc50104c3000001",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f43a8aefc50104c300300d.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f43a8aefc50104c300300d.jpg"
    },
    "metadata": {
      "contributor": "MBLWHOI Library",
      "item_id": "18288",
      "no_illustrations_count": 1,
      "original_size": {
        "width": 2397,
        "height": 3672
      },
      "page_id": "1955147",
      "page_no": "Page 230",
      "page_seq": "242",
      "retire_reason": "detected_no_illustrations",
      "sponsor": "MBLWHOI Library",
      "volume": "v. 19 (1883)",
      "year": "1883"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.096228907837044,
    "state": "complete",
    "updated_at": "2015-05-14T12:03:56Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC00004yy"
  },
  {
    "id": "54f43a50efc50104c3001867",
    "activated_at": "2015-03-30T15:00:55Z",
    "classification_count": 9,
    "coords": [

    ],
    "created_at": "2015-03-02T13:21:58Z",
    "group": {
      "_id": "54f4302befc50104c3000001",
      "zooniverse_id": "GSC0000001",
      "name": "hardwickesscien"
    },
    "group_id": "54f4302befc50104c3000001",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f43a50efc50104c3001867.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f43a50efc50104c3001867.jpg"
    },
    "metadata": {
      "contributor": "MBLWHOI Library",
      "item_id": "17703",
      "no_illustrations_count": 8,
      "original_size": {
        "width": 2307,
        "height": 3612
      },
      "page_id": "1678096",
      "page_no": "Page 277",
      "page_seq": "289",
      "retire_reason": "detected_no_illustrations",
      "skip_count": 1,
      "sponsor": "MBLWHOI Library",
      "volume": "v. 9 (1873)",
      "year": "1873"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.64186778573991,
    "state": "complete",
    "updated_at": "2015-05-14T11:58:19Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC00002n8"
  },
  {
    "id": "54f4b88b30017b04c9002cd1",
    "activated_at": "2015-03-07T07:06:41Z",
    "classification_count": 12,
    "coords": [

    ],
    "created_at": "2015-03-03T19:22:37Z",
    "group": {
      "_id": "54f4b81b30017b04c9000009",
      "zooniverse_id": "GSC0000007",
      "name": "wiltshirearchaeo"
    },
    "group_id": "54f4b81b30017b04c9000009",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b88b30017b04c9002cd1.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b88b30017b04c9002cd1.jpg"
    },
    "metadata": {
      "contributor": "Natural History Museum Library, London",
      "item_id": "45542",
      "no_illustrations_count": 12,
      "original_size": {
        "width": 1691,
        "height": 2781
      },
      "page_id": "12639241",
      "page_no": "Page 65",
      "page_seq": "79",
      "sponsor": "Natural History Museum Library, London",
      "volume": "v.31=no.93-95 (1900-1901)",
      "year": "1901 - 1901",
      "retire_reason": "detected_no_illustrations"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.623129744848,
    "state": "complete",
    "updated_at": "2015-05-14T14:18:41Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0000uke"
  },
  {
    "id": "54f4b8cd30017b04c9004a8f",
    "activated_at": "2015-03-07T07:04:25Z",
    "classification_count": 6,
    "coords": [

    ],
    "created_at": "2015-03-03T19:18:27Z",
    "group": {
      "_id": "54f4b81b30017b04c9000009",
      "zooniverse_id": "GSC0000007",
      "name": "wiltshirearchaeo"
    },
    "group_id": "54f4b81b30017b04c9000009",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b8cd30017b04c9004a8f.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b8cd30017b04c9004a8f.jpg"
    },
    "metadata": {
      "contributor": "Natural History Museum Library, London",
      "item_id": "45624",
      "no_illustrations_count": 6,
      "original_size": {
        "width": 1716,
        "height": 2786
      },
      "page_id": "12674566",
      "page_no": "Page 86",
      "page_seq": "100",
      "sponsor": "Natural History Museum Library, London",
      "volume": "v.22=no.64-66 (1884-1885)",
      "year": "1885 - 1885",
      "retire_reason": "detected_no_illustrations"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.56986821475911,
    "state": "complete",
    "updated_at": "2015-05-14T13:50:52Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0000rg6"
  },
  {
    "id": "54f4b8de30017b04c9004f09",
    "activated_at": "2015-03-07T07:04:11Z",
    "classification_count": 14,
    "coords": [

    ],
    "created_at": "2015-03-03T19:17:51Z",
    "group": {
      "_id": "54f4b81b30017b04c9000009",
      "zooniverse_id": "GSC0000007",
      "name": "wiltshirearchaeo"
    },
    "group_id": "54f4b81b30017b04c9000009",
    "location": {
      "standard": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/standard\/54f4b8de30017b04c9004f09.jpg",
      "thumb": "http:\/\/zooniverse-static.s3.amazonaws.com\/www.sciencegossip.org\/subjects\/thumb\/54f4b8de30017b04c9004f09.jpg"
    },
    "metadata": {
      "contributor": "Natural History Museum Library, London",
      "item_id": "45625",
      "no_illustrations_count": 13,
      "original_size": {
        "width": 1685,
        "height": 2770
      },
      "page_id": "12675139",
      "page_no": "Page 215",
      "page_seq": "253",
      "retire_reason": "detected_no_illustrations",
      "skip_count": 1,
      "sponsor": "Natural History Museum Library, London",
      "volume": "v.20=no.58-60 (1881-1882)",
      "year": "1882 - 1882"
    },
    "project_id": "54f42c0ab35d2e06bd000001",
    "random": 0.44614099944098,
    "state": "complete",
    "updated_at": "2015-05-14T13:47:06Z",
    "workflow_ids": [
      "54f42c32b35d2e06bd000002"
    ],
    "zooniverse_id": "ASC0000r36"
  }
]

@parrish thoughts?

In the meantime, I've added a line to skip past completed subjects on subject load.

Pinging @chrissnyder for his thoughts too.

Guessing that the redis keys for those completed subjects were never removed, which would keep them in circulation. One sec while I look for broken redis sets...

Yea, some of the batches were wildly out of sync. Should be good now.

@chrissnyder Any thoughts on a root cause? Seems like this could have resulted in a fair bit of wasted work and manual intervention isn't very efficient.
@eatyourgreens Thanks for the front end fix.

I don't have a great feeling for why it occurred in the first place. Could be something like our redis server was unavailable for a brief time, when database entries were updated to "complete" but the redis key was never removed (which is what drives actual selection).
Also don't know how much effort went above our specified classification limits, but that'll be easy to check in the data dumps. Might not be all bad, as more data points might help data quality.

A number of projects had their active subjects get out of sync when Panoptes was crashing the database (and Ouroboros) every few minutes.
Assuming everything worked like it was supposed to, the subject would have retired properly after the next classification.

I fixed the formatting for the table of counts in my first comment above.  If you look at some of the counts for the subjects like 25 of 25 classifications as no_illustration, it makes it seem like any catchup/resync algorithm for the retirement process isn't working.
https://api.zooniverse.org/projects/illustratedlife/subjects/ASC0000wva

The API hasn't served me any completed subjects since those redis keys were removed, so I think it's safe to say this bug is closed.
I think those high classification counts are a holdover from an early bug (since fixed) where subjects without illustrations weren't retired unless no_illustration_count was exactly 3. I've found 508 subjects with classification_count > 20 in the database, so I think that bug only affected a small fraction of the full set (1 in 300 images.)


Crash related to function pointer call

Nondeterministic crash in CallResolver for this code:
#include <iostream>

class A {
  public:
    void fun() {
      std::cout << "Hello" << std::endl;
    }

    int mainA() {
      A a;

      void (A::* f_ptr) () = &A::fun;
      a.fun();
      (a.*f_ptr)();
    }
};

int main() {
  A a;

  void (A::* f_ptr) () = &A::fun;
  a.fun();
  (a.*f_ptr)();
}

Additionally, some quick checks showed some further problems in this snippet:

[x] (a.*f_ptr)() has name ".", which makes totally no sense
[ ] a.fun() is currently not resolved as the member call on class A that it actually is
[ ] Function pointer handling needs to be added to the call resolver

For me it is still confusing why CDT is resolving this as the Binary Operator . instead of something like a field expression. Did you check how LLVM handles this?

Here is the relevant part:
`-FunctionDecl 0x10f03c278 <line:11:1, line:17:1> line:11:5 main 'int ()'
  `-CompoundStmt 0x10f03c968 <col:12, line:17:1>
    |-DeclStmt 0x10f03c648 <line:12:3, col:6>
    | `-VarDecl 0x10f03c320 <col:3, col:5> col:5 used a 'A' callinit
    |   `-CXXConstructExpr 0x10f03c620 <col:5> 'A' 'void () throw()'
    |-DeclStmt 0x10f03c828 <line:14:3, col:33>
    | `-VarDecl 0x10f03c748 <col:3, col:30> col:14 used f_ptr 'void (A::*)()' cinit
    |   `-UnaryOperator 0x10f03c810 <col:26, col:30> 'void (A::*)()' prefix '&' cannot overflow
    |     `-DeclRefExpr 0x10f03c7e0 <col:27, col:30> 'void ()' CXXMethod 0x10f038b78 'fun' 'void ()'
    |-CXXMemberCallExpr 0x10f03c890 <line:15:3, col:9> 'void'
    | `-MemberExpr 0x10f03c860 <col:3, col:5> '<bound member function type>' .fun 0x10f038b78
    |   `-DeclRefExpr 0x10f03c840 <col:3> 'A' lvalue Var 0x10f03c320 'a' 'A'
    `-CXXMemberCallExpr 0x10f03c948 <line:16:3, col:14> 'void'
      `-ParenExpr 0x10f03c928 <col:3, col:12> '<bound member function type>'
        `-BinaryOperator 0x10f03c908 <col:4, col:7> '<bound member function type>' '.*'
          |-DeclRefExpr 0x10f03c8b0 <col:4> 'A' lvalue Var 0x10f03c320 'a' 'A'
          `-ImplicitCastExpr 0x10f03c8f0 <col:7> 'void (A::*)()' <LValueToRValue>
            `-DeclRefExpr 0x10f03c8d0 <col:7> 'void (A::*)()' lvalue Var 0x10f03c748 'f_ptr' 'void (A::*)()'

And this is actually something I would prefer as well. Is it important for us to distinguish this explicitly as a function pointer call expression? Or is it just a regular MemberCallExpression in this case? (and a regular call expression in any other?) I fear that we add too many different kind of call expressions that then are specific to the language.

The problem is that the member we would be calling is the function pointer variable and not the method itself. A normal MemberCallExpression has no dedicated member property but we rather use its name to identify the method to be called. For function pointer calls this is not sufficient, as we need to have the full member node (a DeclaredReferenceExpression in this case), as we need to traverse it until we get the actual declaration it refers to. For now I created a new class that has this dedicated field, as I was unsure how it would need to be handled for normal member calls. I will migrate it to the original MemberCallExpression and check whether I  can find a consistent solution for both normal member calls, C++ function pointer calls on base objects and C function pointer calls that do not have a base object.

If there are function pointers that are not called at some point, we currently have no way of telling which function exactly they are referencing (if there are multiple overloaded variants for a specific function name). The actual signature is only known at call-time. In order to represent this in the graph, we would need to have multiple outgoing refers_to edges from DeclaredReferenceExpressions. For now I will not do it this way but rather wait for dedicated function pointer types that should be added in #35. This will enable us to exactly pinpoint the correct target of a function pointer, as the desired signature is part of a function pointer's type


Info popups are cut in table views on smartphones

When reporting a bug, please provide more information and a reproduction to help us understand and triage. Screenshots are pretty hard to debug in many cases. I can't be sure this is a problem with Clarity or with something specific in your application.
In this case, this is likely because of position relative clipping issues that will be solved when we migrate signposts to our new popovers logic (coming soon). In the meantime, this looks like a custom tree/table? For the signpost on Auto Config 3.1, you could put the signpost into a different orientation to give it more space and avoid clipping. You could also consider a different pattern, mobile signposts are more difficult to use than perhaps using a modal due to sizing constraints of the screen.

We definitely need a reproduction for this. Smart popovers won't fix content that is too large (so tall or wide it goes offscreen on two sides of the viewport) to have a valid position.

I believe this will be best solved by the work in #1757, so closing in favor of it.


ApiErrors: Backend Error

Getting a generic Backend Error. Not sure if its worth verifying the status of datastore.
I was accessing datastore from my dev box, as well as from GCE.
I can still view Datastore Entities from https://console.developers.google.com/datastore/entities/query, but I also saw a Backend Error popup when I tried to access the "Admin" section.
Also saw messages on AppEngine admin logs, but now I can't find them, not sure if related.
Message below from GCE:
    at new util.ApiError (.../node_modules/gcloud/lib/common/util.js:92:10)
    at Object.parseHttpRespMessage (.../node_modules/gcloud/lib/common/util.js:134:33)
    at Request._callback (.../node_modules/gcloud/lib/datastore/request.js:813:31)
    at Request.self.callback (.../node_modules/gcloud/node_modules/request/request.js:199:22)
    at Request.emit (events.js:98:17)
    at Request.<anonymous> (.../node_modules/gcloud/node_modules/request/request.js:1036:10)
    at Request.emit (events.js:117:20)
    at IncomingMessage.<anonymous> (.../node_modules/gcloud/node_modules/request/request.js:963:12)
    at IncomingMessage.emit (events.js:117:20)
    at _stream_readable.js:929:16
    at process._tickCallback (node.js:419:13)

Message below from my dev box:
ApiError: Service Unavailable
    at new util.ApiError (.../node_modules/gcloud/lib/common/util.js:92:10)
    at Object.parseHttpRespMessage (.../node_modules/gcloud/lib/common/util.js:134:33)
    at Request._callback (.../node_modules/gcloud/lib/datastore/request.js:813:31)
    at Request.self.callback (.../node_modules/gcloud/node_modules/request/request.js:199:22)
    at Request.<anonymous> (.../node_modules/gcloud/node_modules/request/request.js:1036:10)
    at IncomingMessage.<anonymous> (.../node_modules/gcloud/node_modules/request/request.js:963:12)
    at _stream_readable.js:908:16

PS
Don't know if this is the appropriate forum for these types of issues.
"gcloud": "^0.27.0",

Its responsive now

Sounds like an API hiccup, but glad to hear it's working smoothly again.

Don't know if this is the appropriate forum for these types of issues.

@jgeewax is there a good place for users to submit issues like this (and this)?

Appreciate the help! This didn't seem like a post for stackoverflow either...
I found a more appropriate link in the support documentation
Non-paid support customers
Submit a Cloud Datastore production issue


RxSwift 3.0 Support

[x] Updates to support RxSwift ~> 3.0
[x] Adds CoreMotion as a dependent framework in .podspec
[x] Fixes some 'target overrides ... build setting' CocoaPods warnings
[x] Bumps the version number to 0.2.0 in the .podspec

@esttorhe made those changes 👍

🎉 can't release the Pod though; I'm not part of the maintainers
maybe one of the @RxSwiftCommunity/contributors could help with that 😇

I'm sorry for all user. I forgot all it. Thanks @esttorhe by the warning. There are new release and the pod has been pushed.

Cool thanks @carlosypunto! Do you want to add @esttorhe and/or myself as owners to the pod? It'd be pod trunk add-owner RxCoreMotion [email address].

Of course @ashfurrow! Done

Good to have more people to bug when releasing a new pod. Thanks

Thanks to you @esttorhe for warning for it. I love that we are a good team


Add mujoco assets

See the README for description of changes

@mewtwoshaurd I've tagged you in the locations that require specific attention. The actuator parameters is where we define how the joints are simulated. Please take note of the locations of these parameters, as they define how realistic the robot performance will be.
I believe I copy-pasted the correct/best values from the various configs, but this is the part of the PR that mat require further tuning


How do you get the result image?

Thanks to open your implementation!
I want to know how to save the visualization image like https://github.com/jiwoon-ahn/irn/blob/master/outline.jpg
thanks.

Hi @UdonDa,
This code already provides those functions. Please look up: https://github.com/jiwoon-ahn/irn/blob/master/misc/imutils.py#L193-L272

Thanks!
I will try it!

Sorry， I don't know how to save the images， fig6 (C) and (D) in the https://arxiv.org/pdf/1904.05044.pdf
Please teach us.

Consider adding the following lines around here https://github.com/jiwoon-ahn/irn/blob/master/step/make_ins_seg_labels.py#L125
For (c),
colorize_displacement(dp)
For (d),
edge

Hi,
How can I get the Instance Map from the Displacement field (As in Figure 1)?

考虑在此处添加以下几行https://github.com/jiwoon-ahn/irn/blob/master/step/make_ins_seg_labels.py#L125 对于（c）， colorize_displacement(dp) 对于（d）， edge

请问对于d用哪个函数

How can i get fig6 (e) Pseudo labels? Thank you

############Visual offset field
from PIL import Image
rgb_image = colorize_displacement(dp)
if rgb_image.dtype != np.uint8:
rgb_image = (rgb_image * 255).astype(np.uint8)
image = Image.fromarray(rgb_image)
image.save(os.path.join("/disk4/xjt/irn-master/cam/","_" + str(img_name)+"offset" + ".png"))
###############


Try to apply Profile-Guided Optimization (PGO) to SPIRV tooling

Hi!
I think SPIRV tools can get performance improvement by using Profile-Guided Optimization (PGO). I think so because, from my experience, compiler-like things get up to a 20% boost with it (according to Clang and Rustc tests).
Did anyone try to do such optimization on the project? Not sure, if is it possible or not to use tests as a profile since a good profile should work on a "hot" path in general cases.

We have not tried it. I agree that it would probably give a good improvement, but the tests would not be good training data. To build usefully with PGO we would need a good set of shaders from a variety of source that have the correct licence.
This is not something that the maintainers are interested in perusing at this time. We could accept a PR from someone else, but we would have to look it over carefully.


ergoCubSN001: simplify collision shape of feet

It fixes #179

Just to understand, what are the other changes related to?

cc @akhilsathuluri

Just to understand, what are the other changes related to?

The changes in the yaml are related to the fact creo2urdf does not support sensorName default clause

Just to understand, what are the other changes related to?

The changes in the yaml are related to the fact creo2urdf does not support sensorName default clause

Ack, can you add a sentence on that in PR description? Thanks!


Update deno.land module

First at all, thank you so much for the module, it helped me a lot :)
However, the latest version(0.2.0) of the module on https://deno.land still on commit #82d2e64.
The BotProps doesn't have the timeout property.

Thank you @piero0920 for your feedback! Sorry, I didn't check my GitHub for the last few weeks. Did you find this library useful? I would be down to build it up more with lot more advanced functionalities.

Yeah, the library is very useful, I been using it ever since I found out about it.
It would be great to see more advanced functionalities.


Build fails on issue in pypy.sh downloading compressed file

Hi,
our build is failing after the last commit 330e62a on this file.
/virtual-environments/images/linux/scripts/installers/pypy.sh
After some investigation, I found a problem in line 76
In the pypy.sh install bash script there is an issue downloading the https://downloads.python.org/pypy/ file. The server responds by giving a compressed gzip file.
on line 76 the code states:
pypyVersions="$(cat /tmp/pypyUrls.html | grep 'linux64' | awk -v uri="$uri" -F'>|<' '{print uri$5}')"
the grep command receives the compressed gzip file through the standard input from the cat command standard out. This can not work as the grep command cannot find any pattern of linux64 in the compressed input.
line 76 should be changed to decompress the /tmp/pypyUrls.html file and pipe its outcome to the grep command, like:
pypyVersions="$(gzip -cd /tmp/pypyUrls.html | grep 'linux64' | awk -v uri="$uri" -F'>|<' '{print uri$5}')"
I hope this can be fixed as this brakes our releases of new build agents.
Best regards,
Thomas Kwaks

Hi @tkwaks , thank you for your report! I've checked this code and it works correctly:
https://github.com/vsafonkin/check-pypy-versions/runs/780207913?check_suite_focus=true
We get html content from pypyUrls.html that contains urls for downloading. Cat command send simple html text to standard output that grep handle correctly.

We still have the same issue:

running your code on ubuntu 18.04 I see this issue still occurring

In this commit  the code to fetch this data changed from
curl -4 -s --compressed https://downloads.python.org/pypy/
to
wget https://downloads.python.org/pypy/  --output-document=pypy.html --no-verbose
Running these in a Ubuntu 20.04 environment gives different results:
Diederick$ curl -4 -s --compressed https://downloads.python.org/pypy/
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
...

Diederick$ wget https://downloads.python.org/pypy/  --output-document=pypyUrls.html --no-verbose
2020-06-18 08:11:04 URL:https://downloads.python.org/pypy/ [12513/12513] -> "pypyUrls.html" [1]
Diederick$ file pypyUrls.html
pypy.html: gzip compressed data, from Unix, original size modulo 2^32 167824
It seems you get different results. Can this be platform dependent?

@tkwaks , I'm really confused, on GitHub Actions this code works correctly:
wget https://downloads.python.org/pypy/ --output-document=pypyUrls.html --no-verbose
file pypyUrls.html
cat pypyUrls.html

https://github.com/vsafonkin/check-pypy-versions/runs/783432659?check_suite_focus=true
I've tested it on Azure DevOps and it works too. I've tested it on Ubuntu 18.04 and 20.04
Could you please check your wget version? I believe the problem may be in the default settings for different wget versions.

I would expect that it works for you, therefore also my confusion and suggestion it is platform dependent. I am running this in WSL 2, Ubuntu 20.04.
What is the machine you are using to run the Packer build in?
Here my environment:
Diederick$ wget --version
GNU Wget 1.20.3 built on linux-gnu.

-cares +digest -gpgme +https +ipv6 +iri +large-file -metalink +nls
+ntlm +opie +psl +ssl/openssl

Wgetrc:
    /etc/wgetrc (system)
Locale:
    /usr/share/locale
Compile:
    gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
    -DLOCALEDIR="/usr/share/locale" -I. -I../../src -I../lib
    -I../../lib -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_LIBSSL -DNDEBUG
    -g -O2 -fdebug-prefix-map=/build/wget-OYIfr9/wget-1.20.3=.
    -fstack-protector-strong -Wformat -Werror=format-security
    -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall
Link:
    gcc -DHAVE_LIBSSL -DNDEBUG -g -O2
    -fdebug-prefix-map=/build/wget-OYIfr9/wget-1.20.3=.
    -fstack-protector-strong -Wformat -Werror=format-security
    -DNO_SSLv2 -D_FILE_OFFSET_BITS=64 -g -Wall -Wl,-Bsymbolic-functions
    -Wl,-z,relro -Wl,-z,now -lpcre2-8 -luuid -lidn2 -lssl -lcrypto -lz
    -lpsl ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a

Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Originally written by Hrvoje Niksic<EMAIL_ADDRESS>Please send bug reports and questions to<EMAIL_ADDRESS>
Diederick$ cat /etc/wgetrc | grep -v "^#" | grep -v "^$"
passive_ftp = on

@DiederickA , could you please try to execute this code?
wget https://downloads.python.org/pypy/ --header 'Accept-encoding: identity' --output-document=pypyUrls.html --no-verbose
file pypyUrls.html
cat pypyUrls.html

I've tested wget 1.19.4 and 1.20.3 and it works.

That does not seem to make a difference:
Diederick$ wget https://downloads.python.org/pypy/ --header 'Accept-encoding: identity' --output-document=pypyUrls.html --no-verbose
2020-06-19 09:15:05 URL:https://downloads.python.org/pypy/ [12513/12513] -> "pypyUrls.html" [1]
Diederick$ file pypyUrls.html
pypyUrls.html: gzip compressed data, from Unix, original size modulo 2^32 167824
Diederick$ more pypyUrls.html
�
u���~�?�yt������������l|~�?����?�����㿎

u501@u501-Virtual-Machine:~$ wget https://downloads.python.org/pypy/ --header 'Accept-encoding: identity' --output-document=pypyUrls.html --no-verbose -d
DEBUG output created by Wget 1.20.3 on linux-gnu.
Reading HSTS entries from /home/u501/.wget-hsts
URI encoding = ‘UTF-8’
Caching downloads.python.org => <IP_ADDRESS> 2a04:4e42:9::175
Created socket 4.
Releasing 0x0000561225b07a10 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 4 to SSL handle 0x0000561225b07c20
certificate:
subject: CN=*.c.ssl.fastly.net,O=Fastly\, Inc.,L=San Francisco,ST=California,C=US
issuer:  CN=GlobalSign CloudSSL CA - SHA256 - G3,O=GlobalSign nv-sa,C=BE
X509 certificate successfully verified and matches host downloads.python.org
---request begin---
GET /pypy/ HTTP/1.1
User-Agent: Wget/1.20.3 (linux-gnu)
Accept: /
Accept-encoding: identity
Host: downloads.python.org
Connection: Keep-Alive
---request end---
---response begin---
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 12513
Server: nginx/1.10.3 (Ubuntu)
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Via: 1.1 varnish
Cache-Control: max-age=365000000, immutable, public
Accept-Ranges: bytes
Date: Fri, 19 Jun 2020 08:08:06 GMT
Via: 1.1 varnish
Age: 2670135
X-Served-By: cache-fra19144-FRA, cache-ams21072-AMS
X-Cache: HIT, HIT
X-Cache-Hits: 1, 1
X-Timer: S1592554087.964050,VS0,VE6
Strict-Transport-Security: max-age=31557600
---response end---
Registered socket 4 for persistent reuse.
Parsed Strict-Transport-Security max-age = 31557600, includeSubDomains = false
Updated HSTS host: downloads.python.org:443 (max-age: 31557600, includeSubdomains: false)
URI content encoding = ‘utf-8’
2020-06-19 10:08:06 URL:https://downloads.python.org/pypy/ [12513/12513] -> "pypyUrls.html" [1]
Saving HSTS entries to /home/u501/.wget-hsts

Hi @vsafonkin,
Could you please add the following code on line 76 (after the download_with_retries) or something similar.
file -s /tmp/pypyUrls.html | grep gzip && mv /tmp/pypyUrls.html /tmp/pypyUrls.html.gz && gunzip /tmp/pypyUrls.html.gz
This will ensure that our build will work again and yours will not break. (I know this is a kludge ;-) )

@tkwaks , @DiederickA , I've created PR to use curl instead wget, it should solve the problem.

That is indeed less of a kludge than the suggested solution, so (for a part) reverting back to previous setup.

@DiederickA , thank you for your help!

@tkwaks , pull request was merged, please, check your build.

I'm afraid the curl command needs the --compressed flag. As it was before in pypy.sh :
       result="$(curl -4 -s --compressed $uri | grep 'linux64' | awk -v uri="$uri" -F'>|<' '{print uri$5}')"
Testing in bash directly:
Diederick$ curl https://downloads.python.org/pypy/ --compressed -4 -s -o pypyUrls.html
Diederick$ ls -l pypyUrls.html
-rwxrwxrwx 1 died died 167824 Jun 19 21:42 pypyUrls.html
Diederick$ file  pypyUrls.html
pypyUrls.html: HTML document, ASCII text

Diederick$ curl https://downloads.python.org/pypy/ -4 -s -o pypyUrls.html
Diederick$ file  pypyUrls.html
pypyUrls.html: gzip compressed data, from Unix, original size modulo 2^32 167824
Diederick$ ls -l pypyUrls.html
-rwxrwxrwx 1 died died 12513 Jun 19 21:43 pypyUrls.html

@DiederickA , fixed, please check it.

Hi @vsafonkin,
Our build is still failing and I believe that I found the reason.
In the file /images/linux/scripts/helpers/install.sh
on line 19 the code states:       curl $URL -4 -s -compressed -o "$DEST/$NAME"
The code should be:                 curl $URL -4 -s --compressed -o "$DEST/$NAME"
u501@Silverline-iT:~$ curl https://downloads.python.org/pypy/ -compressed -4 -s -o pypyUrls.html
u501@Silverline-iT:~$ file pypyUrls.html
pypyUrls.html: gzip compressed data, from Unix
u501@Silverline-iT:~$ curl https://downloads.python.org/pypy/ --compressed -4 -s -o pypyUrls.html
u501@Silverline-iT:~$ file pypyUrls.html
pypyUrls.html: HTML document, ASCII text
u501@Silverline-iT:~$
Cloud you please change the code?

The builds have failed in fetching the tar.bz file.
I believe we have now the issue that your curl command needs the --compressed for the fetch of the html page. However, it needs to be without it for the download of the tar.bz.
Diederick$ curl https://downloads.python.org/pypy/pypy2.7-v7.3.1-linux64.tar.bz2 -4 --compressed -o pypy2.7-v7.3.1-linux64.tar.bz2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 30.4M    0  1371    0     0  19585      0  0:27:09 --:--:--  0:27:09 19869
curl: (61) Unrecognized content encoding type. libcurl understands deflate, gzip, br content encodings.
Diederick$ echo $?
61
Diederick$ curl https://downloads.python.org/pypy/pypy2.7-v7.3.1-linux64.tar.bz2 -4 -o pypy2.7-v7.3.1-linux64.tar.bz2
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30.4M  100 30.4M    0     0  9785k      0  0:00:03  0:00:03 --:--:-- 9788k
Diederick$ echo $?
0
Diederick$ file pypy2.7-v7.3.1-linux64.tar.bz2
pypy2.7-v7.3.1-linux64.tar.bz2: bzip2 compressed data, block size = 900k

I think you should either go back to the original set up (two different downloads) or add an extra argument to the helper function to enable passing on extra flags.

Hi @DiederickA , @tkwaks , PR with fix was merged, could you please check your builds?

Thanks @vsafonkin this now works again. This call may be closed.


Add Architecture section to rust/basic_dao/README.md

hello and thank you for contribution. as this PR is quite outdated, I would like to close it. if you would still like to include this change, I encourage you to create a new PR. thank you for your understanding.


execute: write INFO message to log when stage/step begins/ends

Signed-off-by: Nathan Cutler<EMAIL_ADDRESS>

test this please


Changed the message property type of Roggle.log() from `Object' to 'Object?'

Issue #9

Codecov Report

Merging #10 (a2b3b57) into main (cde3a33) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #10   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          184       184
=========================================
  Hits           184       184

Flag
Coverage Δ

unittests
100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

lib/src/roggle.dart
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cde3a33...a2b3b57. Read the comment docs.


Python FASTAPI az functions working locally but not when deployed

I have developed a Python FastAPI Azure Function that includes both HTTP-triggered and timer-scheduled triggers. I followed this Azure sample code to create the FastAPI Python Azure Function: Azure Functions Python Create FastAPI App. Additionally, I implemented the timer-scheduled trigger using the code suggested in this GitHub issue: Azure/azure-functions-python-worker#1284.
Everything works fine when tested locally, but upon deploying to Azure Functions, an error occurs stating 'HTTP trigger not found'.
Please help :)
Here are my application settings:

Thanks for  reporting will  check and update.

import logging
import datetime
import fastapi
from urllib import response

fast_app = fastapi.FastAPI()

@fast_app.get("/return_http_no_body")
async def return_http_no_body():
    return response(content='test', media_type='text/plain', status_code=200)

app = func.AsgiFunctionApp(app=fast_app, http_auth_level=func.AuthLevel.ANONYMOUS)

@app.schedule(schedule="0 */5 * * * *", arg_name="mytimer", run_on_startup=True)
def http_trigger(mytimer: func.TimerRequest) -> None:
    utc_timestamp = datetime.datetime.utcnow().replace(
        tzinfo=datetime.timezone.utc).isoformat()
    if mytimer.past_due:
        logging.info('The timer is past due!')

    logging.info('Python timer trigger function ran at %s', utc_timestamp)

@alexx087 , thanks for reporting! turned out asgiapplication does not have function_name as decorator, can you try this sample?
![image](https://github.com/Azure/azure-functions-python-worker/assets/12449837/a01d7c5d-c36a-423e-991c-a3cf88dce8f9)
working for me both local and prod

@YunchuWang, I can also confirm this behavior. It happens when you add this decorator:
@app.function_name(name="<funcname>")

In #1284 you show an example where you have this decorator running locally, but in your above example this decorator is missing to rename the TimerTrigger function and this is what appears to cause it to break when running in Azure Functions.
Anytime I've attempted to add this decorator and deploy the code to Azure, the Function fails to load any functions and remains in a failed state.


Nested allOf and anyOf: runtime validation fails

Description
I'm trying to create a schema that allows for a set of shared properties plus two mutually exclusive properties. That is, an object can have all properties A,B...P, but only one of Q or R (though both are optional).
It may be that I'm doing it wrong, but I've consulted all the documentation I've found on the subject, and I can't seem to do it right. The type does seem to come out right, but the validation fails. I suspect that this is an error with this library. However, it may well be that it is just my mistake. In that case: please let me know what the right way to do this would be.

What version of Ajv are you using? Does the issue happen if you use the latest version?
8.11 (already on the latest version)
Ajv options object

const ajv = new Ajv({
    schemas: Object.values(schemas).map((schema) =>
        omitKeys(schema, 'components'),
    ),

    // example was superseded by examples in openapi 3.1, but we're still on 3.0, so
    // let's add it back in!
    keywords: ['example'],
});

addFormats(ajv, ['date-time', 'uri', 'uri-reference']);

JSON Schema

       {
        "allOf": [
          {
            "type": "object",
            "required": [
              "username"
            ],
            "properties": {
              "username": {
                "type": "string"
              }
            }
          },
          {
            "oneOf": [
              {
                "properties": {
                  "project": {
                    "type": "string"
                  }
                }
              },
              {
                "properties": {
                  "projects": {
                    "type": "array",
                    "items": {
                      "type": "string"
                    }
                  }
                }
              }
            ]
          }
        ]
      }

Sample data

  {
    "username": "string",
    "project": "default"
  }

Your code

I have tried to make a working code sample on runkit with 8.11, but there seems to be something wrong with it. I get a syntax error. The same syntax error occurs if I just clone the default sample code and upgrade ajv.
Instead, here's sample code with ajv 4.4.0: it showcases the same issue.
I'm not sure what code you're looking for here (sorry!), so here's what's in the runkit instead
var Ajv = require('ajv');

var ajv = new Ajv({
     // example was superseded by examples in openapi 3.1, but we're still on 3.0, so
    // let's add it back in!
    keywords: ['example']
});

var schema =
 {
        "allOf": [
          {
            "type": "object",
            "required": [
              "username"
            ],
            "properties": {
              "username": {
                "type": "string"
              }
            }
          },
          {
            "oneOf": [
              {
                "properties": {
                  "project": {
                    "type": "string"
                  }
                }
              },
              {
                "properties": {
                  "projects": {
                    "type": "array",
                    "items": {
                      "type": "string"
                    }
                  }
                }
              }
            ]
          }
        ]
};

var data = {
        "username": "string",
    "project": "default"
};

var validate = ajv.compile(schema);

console.log(validate(data));
console.log(validate.errors);

Validation result, data AFTER validation, error messages
{"error":"Request validation failed","validation":[{"keyword":"oneOf","dataPath":".body","schemaPath":"#/components/schemas/createApiTokenSchema/allOf/1/oneOf","params":{"passingSchemas":[0,1]},"message":"should match exactly one schema in oneOf"}]}

What results did you expect?
I would expect the above schema to let me submit either username and project or username and projects or just username.
Are you going to resolve the issue?
I'd be happy to help if there's something I can do, but I'm not very familiar with the library just yet, so I'm not sure it would do much good.
Additional context
I've been trying in as many different ways as I can imagine to make this work, but I haven't been able to. For reference, this seems to be about the closest I've gotten in code (using the json-schema-to-ts package and avj)

Actual source code
export const createApiTokenSchema = {
    $id: '#/components/schemas/createApiTokenSchema',
    type: 'object',
    required: ['username', 'type'],
    oneOf: [
        {
            properties: {
                username: {
                    type: 'string',
                },
                type: {
                    type: 'string',
                    enum: Object.values(ApiTokenType),
                },
                environment: {
                    type: 'string',
                },
                expiresAt: {
                    type: 'string',
                    format: 'date-time',
                    nullable: true,
                },
                project: {
                    type: 'string',
                },
            },
        },
        {
            properties: {
                username: {
                    type: 'string',
                },
                type: {
                    type: 'string',
                    enum: Object.values(ApiTokenType),
                },
                environment: {
                    type: 'string',
                },
                expiresAt: {
                    type: 'string',
                    format: 'date-time',
                    nullable: true,
                },
                projects: {
                    type: 'array',
                    items: {
                        type: 'string',
                    },
                },
            },
        },
    ],
    components: {},
} as const;

export type CreateApiTokenSchema = FromSchema<typeof createApiTokenSchema>;

Any help or insight is much appreciated.

The problem seems to be that neither project no projects properties are required, so both branches pass, and oneOf only allows one branch to pass to be valid. You need to use required and a thirds branch prohibiting both properties. Or you can use “not: required”. Or you can probably use anyOf. However you do it you need to make sure that only one branch of oneOf can pass, not both.

Ah! That makes a lot of sense, actually. That's probably the issue here! I'll go have a look. Thank you!

I've had a look at this now, but can't quite make it work. You're more than likely spot on, but I'm not sure how to represent it. Could you give me some pointers?

You need to use required and a third branch prohibiting both properties.

How can I prohibit specific properties? We generally don't want to set additionalProperties: false on incoming data objects, so don't think I could do it here either in the case that it breaks someone's setup.
Would not: required work for that? E.g.
{
  "not": { "required": ["project", "projects"] }
}

From what I can tell, that works for the third branch, but might just be because either property is required on the other two branches.
Side question: What does not: required mean? Is it one of the following two statements?

These properties are not required on the object (same as the default for properties not marked as required)
These properties are not allowed on the object

Or you can use “not: required”. Or you can probably use anyOf. However you do it you need to make sure that only one branch of oneOf can pass, not both.

Got it! I'm not exactly sure how to do that. Would you be able to give me any pointers? I've got something that looks about like this now, but I'm still getting errors when I try and use either project or projects:
Current version
      {
        "type": "object",
        "allOf": [
          {
            "properties": {
              "username": {
                "type": "string"
              },
            }
          },
          {
            "oneOf": [
              {
                "required": [
                  "username",
                  "project"
                ],
                "not": {
                  "required": [
                    "projects"
                  ]
                },
                "properties": {
                  "project": {
                    "type": "string"
                  }
                }
              },
              {
                "required": [
                  "username",
                  "projects"
                ],
                "not": {
                  "required": [
                    "project"
                  ]
                },
                "properties": {
                  "projects": {
                    "type": "array",
                    "items": {
                      "type": "string"
                    }
                  }
                }
              },
              {
                "required": [
                  "username",
                  "type"
                ],
                "not": {
                  "required": [
                    "project",
                    "projects"
                  ]
                }
              }
            ]
          }
        ]
      }

Errors
I get this when I try and use project. When I use projects, I get the opposite error. It seems to think that it's failing validation for one of them, but matching two of them, if I read that correctly?
{
  "error": "Request validation failed",
  "validation": [
    {
      "keyword": "required",
      "dataPath": ".body",
      "schemaPath": "#/components/schemas/createApiTokenSchema/allOf/1/oneOf/1/required",
      "params": {
        "missingProperty": "projects"
      },
      "message": "should have required property 'projects'"
    },
    {
      "keyword": "oneOf",
      "dataPath": ".body",
      "schemaPath": "#/components/schemas/createApiTokenSchema/allOf/1/oneOf",
      "params": {
        "passingSchemas": [
          0,
          2
        ]
      },
      "message": "should match exactly one schema in oneOf"
    }
  ]
}

The issue is not specific to Ajv issue, it's related to using JSON schema spec. In short, you either need to use anyOf, if both subschemas can be valid for the data, or you need to make subschemas mutually exclusive when you use oneOf (and the error says it is not the case).
You can ask general questions on using JSON schema on StackOverflow.

Got it; appreciate the input 🙏🏼


Update README to show hierarchical names

Pallets can be structured in inheritance hierarchies, for grouping
and/or name space separation. Examplify this in the documentation.
Fixes #96.

The file tree in README.md shows the example warehouse, so you can't have dns-resolver/example-net/ without actually adding it. Then again, the current naming convention is crap, because dhcp-server-example-net/ is supposed to refer to "the example network", whereas dns-resolver/example-com/ is supposed to refer to "the domain example.com".
I think it would be best if you just drop the lines with dns-resolver/example-net/ in this pull request, and then I'll change the DHCP service configuration separately. Or, if you want, you can fix the DHCP service configuration here as well.

Repushed with amendment.