Contribute to Open Source. Search issue labels to find the right project for you!

Write a usable ANTLR grammar for CSP


With a new parser being written it is a good time to develop a formal grammar for the language in tandem with that. Previously the docs/ dir shipped a EBNF file containing a description of the CSP grammar, however, that isn’t immediately consumable.

An ANTLR4 grammar can be used to generate parsers or write external tooling that interacts with the language. In addition, it gives us an easy way to sanity check the grammar while adding language extensions (see:

Updated 22/03/2018 23:35

Double counting in users?


I tried making a platform-wide social network of ER. To my surprise, I have two connected components:


Winnie, Nadia and I appear in both components: the skinny one on the left is clearly biofabforum. This should not happen, unless we are identified by different ids in the two different forums. @damingo, is that the case?

Updated 22/03/2018 23:22 1 Comments

cmd/link: document default flags passed to extld


What version of Go are you using (go version)?


What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build748215444=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go build -ldflags=“-extld=/path/to/ld.hugetlbfs -linkmode=external” foo.go I was trying to map code section to huge pages.

What did you expect to see?

Everything works.

What did you see instead?

Linker didn’t recognize -m64 option.

Looks like we pass a bunch of gcc/clang specific flags to any external linker. I worked around this by passing -extld=gcc -extldflags=“-B /path/to/ld.hugetlbfs”, to use gcc as a linker that recognizes -m64 and calls ld.hugetlbfs without passing -m64, but this behavior was surprising to me and should be documented somewhere (in extld documentation?)

Updated 22/03/2018 21:35

100 continue documentation is wrong


I’m pretty certain that ATS support the Expect header and 100 continue. I’ve tested this in the past, and I just looked through the code and there is support in there.

Someone internally claimed it wasn’t supported because of a FAQ note in the 5.3 documentation. In fact it is in the current documentation

It seems like we should update the docs or remove some code.

Updated 22/03/2018 20:18

[docs] Add error that appears when using proxies for Deployer Troubleshoot doc

craftercms/craftercms Add a section that explains that if the Deployer is not able to clone the remote repository and an error like this one appears in the logs

org.eclipse.jgit.errors.TransportException: ssh:// Connection timed out (Connection timed out)
    at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(
    at org.eclipse.jgit.transport.SshTransport.getSession(
    at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(
    at org.eclipse.jgit.transport.TransportGitSsh.openFetch(
    at org.eclipse.jgit.transport.FetchProcess.executeImp(
    at org.eclipse.jgit.transport.FetchProcess.execute(
    at org.eclipse.jgit.transport.Transport.fetch(
    ... 15 common frames omitted

and doing a manual git clone ssh:// from the command line works, it’s very probable that there’s a proxy between the servers. Right now the deployer doesn’t support connections through proxies, but it might in a future update.

Updated 22/03/2018 20:17

make an asyncio aiohttp example


As per discussion on #twisted with @markrwilliams it should be possible to make twisted and asyncio play nicely together. There should be an example of this now that txtorcon supports Python3.

The “most interesting” would probably be “make a client-type request via Tor” using the aiohttp requests APIs. A “really cool” example would be running an aiohttp web server behind a v3 Onion service…

Updated 22/03/2018 20:12

ApiUser does not know hashed_password Attribute


A test API user is defined as follows, according to

/* Managed by ansible. Any manual edits will be overwritten! */

object ApiUser "defaultuser" {
  password = "eebo5eeRahyaciev4ung7hahg4ahf9heph9ooB1WeD6LahV3pidai4shoomuiphi"
  permissions = []

Expected Behavior

Icinga2 loads normally.

Current Behavior

The configuration check fails:

root@mon01:/etc/icinga2# icinga2 daemon -C
information/cli: Icinga application loader (version: r2.8.2-1)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: ******
critical/config: Error: Attribute 'hashed_password' does not exist.
Location: in /etc/icinga2/conf.d/api-users.conf: 4:3-4:44
/etc/icinga2/conf.d/api-users.conf(3): object ApiUser "defaultuser" {
/etc/icinga2/conf.d/api-users.conf(4):   hashed_password = "$5$thisisaninvalidhash"
/etc/icinga2/conf.d/api-users.conf(5):   // client_cn = ""
/etc/icinga2/conf.d/api-users.conf(6):   // permissions = [ "*" ]

critical/config: 1 error

When testing with password instead of hashed_password, the configuration check suceeds and icinga2 starts as expected.

Steps to Reproduce (for bugs)

  1. install icinga2
  2. icinga2 node setup --master
  3. icinga2 feature enable api
  4. Set the config in /etc/icinga2/conf.d/api-users.conf to the configuration described above


I’d like to use salted + hashed passwords instead of clear text ones.

Your Environment

  • Version used: ``` root@mon01:/etc/icinga2# icinga2 –version icinga2 - The Icinga 2 network monitoring daemon (version: r2.8.2-1)

Copyright © 2012-2017 Icinga Development Team ( License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Application information: Installation root: /usr Sysconf directory: /etc Run directory: /run Local state directory: /var Package data directory: /usr/share/icinga2 State path: /var/lib/icinga2/icinga2.state Modified attributes path: /var/lib/icinga2/modified-attributes.conf Objects path: /var/cache/icinga2/icinga2.debug Vars path: /var/cache/icinga2/icinga2.vars PID path: /run/icinga2/

System information: Platform: Ubuntu Platform version: 16.04.4 LTS (Xenial Xerus) Kernel: Linux Kernel version: 4.4.0-112-generic Architecture: x86_64

Build information: Compiler: GNU 5.3.1 Build host: 86927c12b6d8 ```

  • Operating System and version: Ubuntu 16.04.4 LTS
  • Enabled features: root@mon01:/etc/icinga2# icinga2 feature list Disabled features: compatlog debuglog elasticsearch gelf graphite influxdb livestatus opentsdb perfdata statusdata syslog Enabled features: api checker command ido-mysql mainlog notification

  • Config validation: As seen in Current Behavior

Updated 22/03/2018 19:49 2 Comments

I179 contribuing section in readme


Sorry to bother you Dave, but I thought I’ll kill two birds with one stone (how bellistic brrr).

I feel that we could release 1.2.5 there seems to be enough stuff here, seems some folks are kindly using workarounds for #168 in ex_doc

Thank you in advance

P.S. Now the README is really long, would you like a clickable TOC at the beginning?

Updated 22/03/2018 18:01

Add documentation about contribution and finding issues


Add documentation on how to contribute by finding issues

The first step should be to check core tags, and high-priority ones

Then unimplemented issues should be checked which got closed due to lack of attention but still need to be implemented.

Then deferred issues may be valid now to take up

If no such criteria meets, only then move on to create new issues during an issue hunt. Of course issues about serious bugs and new ideas about features are always welcome.

Above paragraph is a gist of what is to be communicated

Updated 22/03/2018 16:57 2 Comments

Add separate issue templates


Current issue template has checkboxes which overshadow github’s checklist feature

Github now supports separate issue templates for various occasions. Split the current issue template into 3 parts - bug, feature, and chore

Add 3 corresponding buttons to README in create an issue section where a user can be redirected to new issue template respectively

Updated 22/03/2018 15:51

Document RUN SCRIPT command


We have no documentation of RUN SCRIPT (I checked syntax guide, examples), even though we use it in e.g. the clickstream demo.

RUN SCRIPT allows you to run a list of predefined queries/commands from in a file.

Note: This is related to but different from starting KSQL servers with a --queries-file configuration. In the latter scenario, KSQL servers will run in non-interactive, “headless” configuration and will disable interactive access from the KSQL CLI aka ksql>.

Example usage:

$ cat /path/to/local/application.sql
CREATE STREAM pageviews_copy AS SELECT * FROM pageviews;

$ ksql
ksql> RUN SCRIPT '/path/to/local/application.sql';

Note that, today, RUN SCRIPT will only execute a subset of possible KSQL commands:

1) CS/CT/CTAS/CSAS (= persistent queries) 2) DROP STREAM, DROP TABLE 3) SET

RUN SCRIPT does NOT execute command such as:

4) SHOW TOPICS, SHOW STREAMS, etc. 5) TERMINATE 6) SELECT … (= non-persistent queries)

Updated 22/03/2018 15:35 1 Comments

Document > `SkyAppTestModule`


The SkyAppTestModule is included in the template’s unit test specs by default, but it’s not really explained what it does. It can cause a lot of problems if developers don’t know how it benefits them.

Updated 22/03/2018 15:12

Reorganize the contributors information



<!— Describe your changes in detail –>

Following up on the recent changes for the documentation and the in particular and after a conversation with @jaygambetta, this PR reorganizes a bit the “Authors” section on the main by moving the list of contributors to its own separate file. The goal is to make that list able to scale better, being able to both preserve attribution to the contributors and keep the mainlist readable.

Motivation and Context

<!— Why is this change required? What problem does it solve? –> <!— If it fixes an open issue, please link to the issue here. –>

How Has This Been Tested?

<!— Please describe in detail how you tested your changes. –> <!— Include details of your testing environment, and the tests you ran to –> <!— see how your change affects other areas of the code, etc. –>

Screenshots (if appropriate):

Types of changes

<!— What types of changes does your code introduce? Put an x in all the boxes that apply: –> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change)


<!— Go over all the following points, and put an x in all the boxes that apply. –> <!— If you’re unsure about any of these, don’t hesitate to ask. We’re here to help! –> - [ ] My code follows the code style of this project. - [ ] My change requires a change to the documentation. - [x] I have updated the documentation accordingly. - [ ] I have read the CONTRIBUTING document. - [ ] I have added tests to cover my changes. - [ ] All new and existing tests passed.

Updated 22/03/2018 14:50



I’m going through and updating some in-house mbuild tutorials. I know that mBuild is pre 1.0 so the API changes quite a bit, which is great since it will take several iterations to get right, but it would be useful to have a a changelog file so there is one place to check to see what’s changed, and API breaking changes can be highlighted.

Related to #261, to help keep the changelog manageable, you could require PRs to include a suggested changelog entry.

Updated 22/03/2018 20:25 4 Comments

Review documentation and add BaseStationary to supplementary signs


This PR addresses issue #97.

Regularize doxygen comments. Add links to OSI message fields and enums. Add “plural” form to repeated field names (add list/multiple, add _s etc.). Remove typos and replace special chars.


Split CanditateSupplementarySign in two messages (every supplementary sign has its own list of candidates and a base_rmse). Add BaseStationary to SupplementarySign and remove its position_supplementary field.

Updated 22/03/2018 17:12

2.x: Expand the Getting Started


This PR expands the with further examples and details, plus adds headers so that (former and new) sections can be easily linked in answers on issue lists or StackOverflow.

(Note that it was written offline without proper markdown rendering so I may update the PR a couple of times to get the render mistakes fixed).

Updated 22/03/2018 15:52 2 Comments

Various fixes and cleanups


I have been working on-and-off on implementing ‘blacklisting’ as described here, and in anticipation of that, but also just from having to re-familiarize after a while away from the code, I found various improvements/fixes/clarifications which I am bundling in a PR rather than driving you nuts with a string of PRs. If any commit-messages are not self-explanatory enough let me know.

Updated 22/03/2018 13:22

Better Contribution Instructions


We currently have a [] ( file, however it needs some improvement and more prominence in the readme.

Topics that should be included: - [ ] this project is open to all contributions and people with all levels of skill - [ ] how to setup the project environment - [ ] how to do a git pull & git rebase master to get a PR up to the current master branch - [ ] how to do interactive rebases - [ ] how to name things - [ ] how to test things - [ ] how to comment things

Updated 22/03/2018 12:00

Update changelog


<!– Thanks for sending a pull request!
If this is your first time, read our contributing guidelines. –> What this PR does / why we need it: Update changelog to reflect the latest additions and fixes.

Special notes for your reviewer: Added a few things that are coming. So needs to wait for these to go in.

Updated 22/03/2018 19:14

Decide on general front-matter convention for nested vs flat


<!– This form is for bug reports and feature requests ONLY!
If you’re looking for help check out our support guidelines and the troubleshooting guide. –> Is this a BUG REPORT or FEATURE REQUEST?: feature

What happened: Currently we haven’t defined the front-matter convention to use.

What you expected to happen: Either use nested or use flat variables in front-matter.

Anything else we need to know?: For almost all fragments we use nesting. So that seems to be the one we should go with.

Examples Flat: sidebar_heading = "" sidebar_content = ""

Nested: [sidebar] heading = "" content = ""

Updated 22/03/2018 11:32

LocalDate + Period addition is not documented as adding period components individually

new LocalDate(2016, 2, 29).Plus(Period.FromYears(1) + Period.FromMonths(1))

My initial expectation was that this would produce Mar 29, 2017. Instead, it produces Mar 28, 2017, because it adds a year first, and only then adds a month. I’d have to normalise this to a period of 13 months (with the understanding that this doesn’t work in other calendar systems) to get the result I was expecting.

For LocalDateTime, this is sort of documented:

Addition(LocalDateTime, Period)
Adds a period to a local date/time. Fields are added in the order provided by the period. This is a convenience operator over the Plus(Period) method.


Adds a period to this local date/time. Fields are added in the order provided by the period.

I don’t see what “the order provided by the period” is, but at least it tells that there’s a gotcha.

For LocalDate, this documentation is missing:

Addition(LocalDate, Period)
Adds the specified period to the date.


Adds the specified period to this date. Fluent alternative to operator+().

Updated 22/03/2018 11:43 2 Comments

`auto-approve` flag not documented for `apply` in `-help` section on the command line


Terraform Version

$ terraform -v
Terraform v0.11.5

Terraform Configuration Files

Not applicable

Debug Output

Not applicable

Crash Output

Not applicable

Expected Behavior

auto-approve flag is mentioned when running terraform apply -help

Actual Behavior

auto-approve flag is not mentioned when running terraform apply -help

Steps to Reproduce

  1. terraform apply -help
Updated 22/03/2018 13:33

How stuff works


This documents the way in which agentmon translates statsd / prometheus into data submittable to the Heroku reporter.

Would appreciate feedback from reviewers on wording and necessary clarifications.

Updated 22/03/2018 22:18

add/remove recipients to store without via script


Hi, I want to use gopass for our team. One requirement for us is automation. So my approach to this is a bash script running once a day via cron. Within this script I catch all public keys from the team, sign them locally and then add or remove them to gopass if there are changes.

Everything works fine so far besides adding or removing recipients to gopass.

gopass recipients add --store XYZ
Do you want to add 'user' as an recipient to the store 'XYZ'? [y/N]: 

Is there a parameter like --yes in gpg2 to bypass this question? If not, this would be very helpful!

Best regards, Jens

Updated 22/03/2018 11:03 1 Comments

More documentation


The diff is not helpful because I changed the line ending (was on Windows and did not notice). I added three sections:

  • Your dependencies could not be resolved (additional content on how to find and manually delete cache)
  • ValueError: unknown locale: UTF-8
  • /bin/pip: No such file or directory
Updated 22/03/2018 20:55 2 Comments

Add new way to initialize particles


In the current dev branch, the only way to initialize a new species is by using the Particles object directly. However, there are many pitfalls when using this object directly (esp. when doing boosted-frame simulation, or multi-CPU/multi-GPU simulations).

This PR solves this issue by creating a helper function add_new_species, which takes automatically takes care of these issues.

Note that this helper function is a temporary, backward-compatible patch: in the future (fbpic 1.0) we hope to have a better (but non-backward-compatible) API.

Updated 22/03/2018 22:20

Ensure Proxy Support


Ensure that existing packages support the HTTP_PROXY environment variable, and document that this is requirement for all packages.

Golang’s net/http and Python’s requests support this by default, I am unsure about Node/JS.

Updated 22/03/2018 10:00 3 Comments

Fork me on GitHub