Multi Level / Mixed Schema API

A more general use case when working with forms involves a bigger schema from yup / joi.
These are done in the following ways
const CreateAccountSchema = Yup.object().shape({
  firstName: Yup.string()
    .min(2, 'Too Short!')
    .max(70, 'Too Long!')
    .required('Required'),
  lastName: Yup.string()
    .min(2, 'Too Short!')
    .max(70, 'Too Long!')
    .required('Required'),
  email: Yup.string().email('Invalid email').required('Required'),
  password: Yup.string()
    .min(8, 'Password too short')
    .max(70, 'Password too long')
    .matches(
      /^(?![\s])(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[^\w])([^\s]){8,}$/,
    )
    .required('Required'),
});

Which we can't work with when working with atoms but I'd like to add a way into the API to support defining multi atom schema.
Here's what I think would work with the Jotai style of doing things
const schemas = {
  firstName: Yup.string()
    .min(2, "Too Short!")
    .max(70, "Too Long!")
    .required("Required"),
  lastName: Yup.string()
    .min(2, "Too Short!")
    .max(70, "Too Long!")
    .required("Required"),
};

const firstName = atomWithValidate(0, {
  validate: (v) => {
    const result = schemas.firstName.validate(v);
    if (result.error) {
      throw result.error;
    }
    return result.value;
  },
});

const lastName = atomWithValidate(0, {
  validate: (v) => {
    const result = schemas.lastName.validate(v);
    if (result.error) {
      throw result.error;
    }
    return result.value;
  },
});

const formSchemaAtom = mergeAtoms({
  firstName,
  lastName,
});

const inComponent = () => {
  const { formState } = useAtom(formSchemaAtom);
  return (
    <>
      {formState.firstName.value}
      {formState.firstName.error}
      {formState.firstName.isDirty}
      {formState.firstName.error}
    </>
  );
};

Might have to add mergeAtoms logic to the original library, or add it as mergeSchema and limit it to this library.
This is open for discussion

This is basically a mismatch with atomic model, but I understand where it comes from.
I would expect something like this:
const firstName = atomWithValidate('', {
  validate: (v) => pickYupSchema('firstName', CreateAccountSchema).validate(v),
});

It can support nesting:
  pickYupSchema('person.fistName', CreateAccountSchema);
  // or
  pickYupSchema(['person', 'fistName'], CreateAccountSchema);

Alternatively, we could make a big atom and pick/select/focus out of it.
const formAtom = atomWithValidate({}, {
  validate: (v) => CreateAccountSchema.validate(v),
});

const firstNameAtom = pickAtomWithValidate('firstName', formAtom);

Not sure if it's possible to implement.

This is basically a mismatch with atomic model, but I understand where it comes from.
I would expect something like this:
const firstNameAtom = atomWithValidate('', {
  validate: (v) => pickYupSchema('firstName', CreateAccountSchema).validate(v),
});

It can support nesting:
  pickYupSchema('person.fistName', CreateAccountSchema);
  // or
  pickYupSchema(['person', 'fistName'], CreateAccountSchema);

This makes more sense to me, though the pick part could be just a function param in validate to make it even cleaner ?

I prefer validate property to be validation-library agnostic.
So, it can work with any library:
const fooAtom = atomWithValidate({}, {
  validate: validateWithYup(yupSchema),
});

const barAtom = atomWithValidate({}, {
  validate: validateWithJoi(joiSchema),
});

Or, anything. I learned this idea from react-hook-form.
Notice, validateWithYup and validateWithJoi can be implemented pretty easily.

In this case, the following would be more natural:
const firstNameAtom = atomWithValidate('', {
  validate: (v) => validateWithYup(CreateAccountSchema, ['firstName']),
});

okay, the point of the picker would've been to help pick the schema property but this works too.
since validate is just a function, anything should be fine

handled in #14


Using ansi quotes in variables.md

I was reading the doc https://ec.haxx.se/cmdline/variables.html and I was suprised to see unicode quotes in the command line examples:

I've checked it with the latest version of curl and such usage gives an error:
bessarabov@bessarabov-osx:~$ docker run -it --rm docker.io/curlimages/curl --expand-url “https://example.com/{{path:trim}}”
Warning: The argument '“https://example.com/”' starts with a unicode quote
Warning: where maybe an ASCII " was intended?
curl: (3) URL rejected: Port number was not a decimal number between 0 and 65535
bessarabov@bessarabov-osx:~$

So I'm pretty sure that this is a misspell in the docs that should be fixed.
PS I don't think that the exact curl version will give any additional info, but just in case i'm providing it here.
bessarabov@bessarabov-osx:~$ docker run -it --rm docker.io/curlimages/curl --version
curl 8.8.0 (x86_64-pc-linux-musl) libcurl/8.8.0 OpenSSL/3.1.5 zlib/1.3.1 brotli/1.1.0 libidn2/2.3.4 libpsl/0.21.2 libssh2/1.11.0 nghttp2/1.58.0
Release-Date: 2024-05-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets
bessarabov@bessarabov-osx:~$
bessarabov@bessarabov-osx:~$ docker images|grep curl
curlimages/curl              latest    bef568b8a706   3 days ago      23.5MB
bessarabov@bessarabov-osx:~$

After creating the first version of this PR with one commit I saw that there is a CI job bad-quote.
Based on the name I was expecting it to check for incorrect quotation marks, but it does a diffrent check.
So I have also updated the script .github/scripts/check-quotes.pl and I have found one more unicode quatation mark that I've also checked.
I'm not sure how those changes should be put into PR. I did the thing that is the simplies for me — did all the changes in one PR, but if you like I can split it into several PRs.


Use of opentelemetry agent seems to disable shedlock

We had a hard time figuring out what is going on, as this error was not reproducible on a dev machine as we use opentelemetry in AWS only and the debug level for shedlock was not enabled by default.
Describe the bug

Which version do you use

4.25.0

Which Lock Provider

JdbcTemplateLockProvider

ShedLock configuration

on the configuration:
@EnableScheduling
@EnableSchedulerLock(
defaultLockAtMostFor = "PT30m",
interceptMode = InterceptMode.PROXY_SCHEDULER
)
on the method:
@Scheduled(cron = "0 0 0 * * *")
@SchedulerLock(
name = "something",
lockAtMostFor = "120m"
)

ShedLock logs

log.level
DEBUG

log.logger
net.javacrumbs.shedlock.core.DefaultLockManager

message
No lock configuration for io.opentelemetry.javaagent.instrumentation.spring.scheduling.SpringSchedulingRunnableWrapper@7431c1da. Executing without lock.

Expected behavior
if possible, resolve the configuration despite the indirection, or at least log an ERROR level log message if this is unexpected.
Actual behavior
Execution without a lock, breaking randomly in multinode environment.

Thanks for the quick analysis. Apparently, we did not have a compelling reason for PROXY_SCHEDULER :laughing:
METHOD works fine for us. However, maybe i miss some use-cases, but isn't this situation worth a WARN level log line (at least)?

Cool, I am glad it helped. The trouble is thet there can be tasks without a lock executed by the scheduler and you do not want to get WARN for them. It's impossible to recognize whether the missing configuration is due to lack of lock or due to some library messing with the scheduler.


App structure

Added nodemon and script
type in terminal npm run start:dev
fixed app structure

:shipit:


chore(icons): :point_up: update icons

Design system icons are now up to date!
Added icons
2512 and 2513

Preview environments are getting posted here, as soon as they are ready!


Backport Calendar system to BA

Been meaning to do this for months, but it requires building run category codes into the announcement system. This likely requires interacting with the database, since there aren't many more embed fields to cram information into.

I managed to open the same issue twice, two days in a row. Closing this - duplicate of #8.


ci: add pypy 3.9 dev

cc @mattip

As discussed in #2137 this will be blocked until the next PyPy rc.

Added a commit to support the newly released PyPy 3.9

I think there are merge conflicts?

I think there are merge conflicts?

Resolved :) Let's hope this works...

Many CI runs are failing.

Looks like most of them were failing due to a variable that wasn't renamed, but the pypy3.9 runners are failing to a link error.
error LNK2019: unresolved external symbol PyPyCFunction_NewEx referenced in function
and
/usr/bin/ld: cannot find -lpypy3-c
and
= note: ld: library not found for -lpypy3-c

Looks like the lib name has added the version in PyPy 3.9, :
$ python
Python 3.9.10 (8276b505180f70c5784a698a510f0a17317a85c3, Feb 19 2022, 16:51:03)
[PyPy 7.3.8 with GCC Apple LLVM 13.0.0 (clang-13<IP_ADDRESS>)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>> import sysconfig
>>>> sysconfig.get_config_var("LIBDIR")
'/Users/david/tools/pypy3.9-v7.3.8-osx64/bin'
>>>> sysconfig.get_config_var("LDLIBRARY")
'libpypy3-c.dylib'

$ ls /Users/david/tools/pypy3.9-v7.3.8-osx64/bin
libpypy3.9-c.dylib	pypy3			python			python3.9
pypy			pypy3.9			python3

$ ls /Users/david/tools/pypy3.7-v7.3.8-osx64/bin
libpypy3-c.dylib	pypy3			python			python3.7
pypy			pypy3.7			python3

Compare libpypy3.9-c.dylib containing the minor version versus 3.7's libpypy3-c.dylib.
@mattip are you able to comment on whether this is intended / expected? Note also that LDLIBRARY has not been updated to have the minor version.

Seems likely unintended to me; posted at https://foss.heptapod.net/pypy/pypy/-/issues/3689

Actually I found this minor version is mentioned in https://foss.heptapod.net/pypy/pypy/-/blob/branch/py3.9/pypy/doc/release-v7.3.8.rst
I'll push a commit to add minor version to the lib name on PyPy 3.9

libpypy3.9-c.so is intentional, so that it can be put into /usr/local/lib64 together with other (future) versions like libpypy3.10-c.so reducing the burden on distro packagers


fix: LSDV-4988: Fix No Label for Dynamic Labels

Switch off labels removal if they are missing in the config. That's destructive action, because this is the case for predictions for example — labels from model can mismatch labels defined in config, but they can be observed and fixed during labeling. This is hidden by LSDV-4988 FF.
PR fulfills these requirements

[ ] Commit message(s) and PR title follows the format [fix|feat|ci|chore|doc]: TICKET-ID: Short description of change made ex. fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errors
[ ] Tests for the changes have been added/updated (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
[ ] Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)
(check all that apply)

[ ] Product design
[ ] Frontend

Describe the reason for change
(link to issue, supportive screenshots etc.)
What does this fix?
(if this is a bug fix)
What is the new behavior?
(if this is a breaking or feature change)
What is the current behavior?
(if this is a breaking or feature change)
What libraries were added/updated?
(list all with version changes)
Does this change affect performance?
(if so describe the impacts positive or negative)
Does this change affect security?
(if so describe the impacts positive or negative)
What alternative approaches were there?
(briefly list any if applicable)
What feature flags were used to cover this change?
(briefly list any if applicable)
Does this PR introduce a breaking change?
(check only one)

[ ] Yes, and covered entirely by feature flag(s)
[ ] Yes, and covered partially by feature flag(s)
[ ] No
[ ] Not sure (briefly explain the situation below)

What level of testing was included in the change?
(check all that apply)

[ ] e2e
[ ] integration
[ ] unit

Which logical domain(s) does this change affect?
(for bug fixes/features, be as precise as possible. ex. Authentication, Annotation History, Review Stream etc.)

/git merge master

/git merge master


controller/registry/resolver: detect incoherent state

If I'm getting it right, we're introducing a live list call to check whether the lister cache is stale. I'm not getting why
if realSubscription.Status.InstalledCSV == csv.Name

gives us that. What's stale in the lister? Has the subscription gone to the new csv but the cached version (of the sub) still points to an old csv?
Is there any concern around the added load on the API server?

@perdasilva the if check to enter the block is predicated on that equality not being true, based on the values we got in our listers. If we do a live list and find the equality to be true, we know our listers were incoherent.


Missing CONTRIBUTING.md

Discussed in https://github.com/ramedina86/streamsync/discussions/19

Originally posted by Wazarr94 May  5, 2023
Is it possible to have a CONTRIBUTING.md file in the project?
The steps to make the right environment aren't really obvious and I am not sure about the conventions/tools you used.
Thanks.

Available in v0.1.12, which was just released.


Remove excess punctuation from help

We should remove extra punctuation from --help where we expect it to be cut/paste (e.g. vm create --image)

Which part should be removed?
--image                       : OS image (URN alias, URN or URI).  Default: Win2012R2Datacenter.
URN aliases: CentOS, CoreOS, Debian, openSUSE, RHEL, SLES, UbuntuLTS, Win2008SP1,
Win2012Datacenter, Win2012R2Datacenter.
Example URN: MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest.
Example URI: http://.blob.core.windows.net/vhds/osdiskimage.vhd.
Values from: az vm image list, az vm image show.

Generic issue for help, no examples should have excess punctuation

We enforce periods across descriptions.  We can't enforce uniformity in descriptions for descriptions that have multiple sentences if we don't.

let us fix the example in azure-cli-vm at least

I cross checked, urn examples is the only place where we use examples in the summary. All others are in the example section and we do not auto-append punctuation.
I removed the . on windows urn. The storage URI is not a complete example for copy, so we are fine.


Comments: Remove placeholder text when comments input is active

Should disappear once user clicks inside input

Are you sure? That is not the default behavior of placeholders. See the example bellow:
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_placeholder
It goes away only after you type the first character.

We can keep it. I guess I'm used to material design where the placeholder moves out the way once the field is active. I kept thinking the input wasn't active and tapping again
https://kstatic.googleusercontent.com/files/e1b29d8e4b672404d302169b82d43b55a9987c114cd8d47be9dff66fe6436f82a1c3b4a016d0a609e9b78c07fe24f841d5d599bfdc56897e30dfae7814b900fd
Can you do one thing that'll help: move the circular avatar to the left a little so it lines up with the curve of the input. That way it creates more space between the avatar and placeholder text (and I can better see the cursor flashing).
This is how it currently looks:

Should look like:

You have this all correct on desktop but looks off on mobile


Zookeeper link not working

Describe the bug
In the following page https://spring.io/projects/spring-cloud-zookeeper , link to Zookeeper documentation is not working: https://zookeeper.apache.org/doc/trunk/zookeeperStarted.html
Sample
See above

Just link to https://zookeeper.apache.org/


TEI Span Annotations should have value as tooltip not the span text

General WebAnno feature: track changes here: https://github.com/webanno/webanno/issues/587


Add 'change_feed_mode' to 'query_items_change_feed' API

Description
In this PR, we added support for change_feed_mode for query_items_change_feed API. For the change_feed_mode argument, users can use either string values(LatestVersion or AllVersionsAndDeletes) or Enum values(ChangeFeedMode.LATEST_VERSIONor ChangeFeedMode.ALL_VERSIONS_AND_DELETES).  The Enum can be imported from change_feed_state.py like the following:
from azure.cosmos._change_feed.change_feed_state import ChangeFeedMode

...
create or set "created_container"
...

# query change feed with 'ALL_VERSIONS_AND_DELETES' mode
query_iterable = created_container.query_items_change_feed(
    change_feed_mode=ChangeFeedMode.ALL_VERSIONS_AND_DELETES,
)

Currently the default value for the change_feed_mode is LATEST_VERSION mode. If the change_feed_mode argument were not passed, query_items_change_feed will use LATEST_VERSION by default. This mode was the only mode supported before we added the change_feed_mdoe argument. Now users can choose either option by passing change_feed_mode
ChangeFeedMode.LATEST_VERSION
With this mode, we return all items of the latest/current version from a container. Even if some items were updated after creation, it only returns the latest version of all created items from a specified point of time, which could be passed by the following arguments. (By default, the point in time will be Now):

is_start_from_beginning: Query all items created from the beginning of container creation. (is_start_from_beginning and start_time are exclusive, and cannot be used together.)
start_time: Query items created from the start time. The start time can be [datetime, 'Now', or 'Beginning']. (is_start_from_beginning and start_time are exclusive, and cannot be used together.)
continuation: Query all items created from a continuation token, which was stored from previous query run.

example:
# query change feed from beginning
query_iterable = created_container.query_items_change_feed(
    is_start_from_beginning=True,
    change_feed_mode=ChangeFeedMode.LATEST_VERSION,
)

# query change feed from Now
query_iterable = created_container.query_items_change_feed(
    start_time="Now",
    change_feed_mode=ChangeFeedMode.LATEST_VERSION,
)

# query change feed from a continuation token
query_iterable = created_container.query_items_change_feed(
    continuation=continuation_token_1,
    change_feed_mode=ChangeFeedMode.LATEST_VERSION,
)

ChangeFeedMode.ALL_VERSIONS_AND_DELETES
With this option, we return all items of all versions including creates, updates, deletes. If an item was deleted , the deleted items will be included, and the metadata will specify that the item was deleted. Currently, we backend server only supports continuation token to specify the beginning time. If is_start_from_beginning or start_time were used, exceptions will be risen with error message. If continuation token was not passed, the point in time will be set to Now.
example:
# query change feed from a continuation token
query_iterable = created_container.query_items_change_feed(
    continuation=continuation_token_1,
    change_feed_mode=ChangeFeedMode.ALL_VERSIONS_AND_DELETES,
)

All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-cosmos


[Test Suite] Refactor arithmetic

Description
refactor test-suite arithmetic

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

193 of 193 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 97.901%

Totals

Change from base Build<PHONE_NUMBER>:
0.007%

Covered Lines:
30837

Relevant Lines:
31498

💛  - Coveralls


Remove columns migration

This pull-request is for a migration to remove columns from a table.
SQLite does not support removing columns from a table via ALTER TABLE. Instead, you must copy the data to a backup table, create a new table with fewer columns, and copy the data from the backup table to the new table with fewer columns. The RemoveColumnsMigration codifies this pattern. The only requirement for the developer when using RemoveColumnsMigration is define a backup model, which subclasses the original model. The backup model then contains the columns to be removed from the original model.
Here is how one would use RemoveColumnsMigration:
// UserProfile.java
@Model(database = MigrationDatabase.class)
public class UserProfile extends BaseModel {
    @Column
    public String firstName;

    @Column
    public String lastName;
}

// UserProfileBackup.java
@Model(database = MigrationDatabase.class)
public class UserProfileBackup extends UserProfile {
    @Column
    public String dropColumn;
}

Then, define the migration to remove the columns:
@Migration(version = 2, database = MigrationDatabase.class)
public static class RemoveColumnsFromUserProfile extends RemoveColumnsMigration<UserProfile, UserProfileBackup> {
    public RemoveColumnsFromUserProfile () {
      super (UserProfile.class, UserProfileBackup.class);
    }
}

In the end, dropColumn will be removed from the UserProfile table in the
database.
The usage of RemoveColumnsMigration has been documented in Migrations.md.

The problem with this is it assumes that UserProfile doesn't change in the future.
If I add a column in migration three, this migration two breaks it, when running a migration from version 1 -> 3. In this situation the migration code is now trying to run based on the version three adapter creation query. When migration three goes to perform a simple add column it will fail because the column already exists.
The same story will play true with most any other alteration to UserProfile.

Any suggestions on improvements to handle this situation. Also, this is not meant to handle complex cases—just the basics.

Personally I feel like migrations should always be written out rather than calculated at run time, so as to implicitly encode both the "from" and "to" schema thus ensuring that they don't have side effect on later migrations.
It might be possible to write a bit of annotation processing code to generate the migration for you but the issue is that without the version one backup table you are going from an unknown state. That backup table is wasteful in terms of maintenance and method count.
Just seems to me that while a manually written out migration can take some time to write it is just far safer and less expensive in the long run than some dynamic solutions.
Have you tried doing the migration in an SQL file? They tend to be less tedious since they are written directly in SQL. So long as you avoid migrations that have things that would break later migrations you should be fine. And write tests for all migration paths. 1 -> N .... N-1 -> N

I think this approach as @trevjonez has said leaves the backup table there. Also it definitely is safer to write out on your own. A manual approach, while not ideal would keep this very safe and ensure that the backup table class somehow doesnt change. I think theres a way to do this to ensure safely.


Update for FSE's latest "My Flight" page and "Max Cargo Weight" Changes.

As the title states, looks like the URL for the My Flight page changed to remove the "v2" so when you have the Planner Rent the plane or add all the jobs in a plan, when it open the My Fight page it goes to a broken link now. The Plane and Jobs are added correctly still however.
Also I assume the changes for the Max Cargo Weight for the list of planes is going to make finding routes a whole bunch of fun now.
Copied from the announcement page. "https://www.fseconomy.net/welcome"
Below is a list of aircraft that will be changed immediately.
Any of these aircraft that are currently airborne during the code update
will not be impacted for that flight. However, the next attempted
takeoff will be subject to the new maximum cargo restrictions.

 (Obviously you're on top of it.)
Damn you work fast. Great stuff!

Thanks :)


ndt_mapping Method Types and parameters

Is there documentation regarding the method types and other parameters for ndt_mapping? Most of the settings are straightforward, but some are opaque. There is no documentation regarding pcl_anh or pcl_anh_gpu or pcl_openmp as far as I can tell. Does "anh" refer to the adaptive octree region-growing method devised by Anh-Vo? Extracting assumptions with which to justify node settings for map generation is challenging using the source code alone. A simple explanation (or README) would prove very helpful.
Followup question - What are the trade-offs when comparing the use of pcl_generic vs pcl_anh?

Thanks for using Autoware and for your question. However the issue tracker is for posting confirmed bugs and feature requests.
We ask that you please ask questions on the Autoware Discourse category following our support guidelines: https://github.com/CPFL/Autoware/wiki/Support-guidelines. Please pay particular attention to the information we ask you to provide.


Hotfixes and new features for ministry and reports

:tada: This PR is included in version 3.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Unverbose FormattedMessage etc. after Fiber release

Because FormattedMessage etc. will return plain string, so we will not need a child as function workaround.

Este textComponent dependency injection is ok.


Header/Navbar Remains Light/White Regardless of the theme applied?

Hi,
I seemingly successfully added all the Catppuccin themes to my app.ini and restarted my Gitea instance. I also set the default theme to catppuccin-frappe-blue. However no matter what catppuccin theme I set it to, the navbar/header remains white/light for some reason.
Screenshots:

I'm super confused. Any help would be appreciated. Thanks,

@jontstaz you can change the following in the .css files to make it display correctly:
search for:
  --color-nav-bg:
  --color-nav-bg-transparent:

and replace it with
  --color-nav-bg:
  --color-nav-hover-bg:

I am not a profi and have only been using the theme since yesterday, so I don't know if the behaviour is correct.


Update to current ansible/molecule/testinfra and fix CentOS7 init.

Description of PR
See individual commit messages
Type of change
Bugfix Pull Request
Fixes an issue
Fixes CentOS7 including init script in RPM vs role dropping systemd unit.
Fixes molecule tests not working with latest versions of testinfra
Corrects style for Ansible 2.7

Thanks! 👍


Extension Management: Migration

Description
Batch process all extensions
Who's implementing?

[ ] I'm willing to implement this feature myself

The problem
chrome.google.com does not have certain extensions, and chrome.google.com won't let extensions that don't have privacy issues through. Not all of the very best extensions are in chrome.google.com.  for example AdNauseam
Possible solutions

ungoogled-software\User Data\Default\Extensions # Install the extension by copying and pasting the folder, Known Issues Extensions folder won't install by copying and pasting and Extensions folder is emptied after opening the browser.

Packing or loading and unpacking at once All extended features

Alternatives
No response
Additional context
No response

I don't understand this issue, what would you like ungoogled-chromium to do?

I don't understand this issue, what would you like ungoogled-chromium to do?

Drag and drop multiple extension folders at once to install


casperjs 1.0.4 w/ phantom 1.9.2 breaks completely on error

Via homebrew I upgraded to casperjs 1.0.4 from casperjs 1.0.2. (I have phantomjs 1.9.2 installed)
After the update to 1.0.4 I received this message when trying to use/invoke casperjs:
"CasperJS 1.0.x does not support PhantomJS version >= 1.9"
I tried uninstalling and reinstalling casperjs but the message persisted. Finally, I uninstalled capserjs 1.0.4 and installed 1.0.3. Fortunately, this works fine (e.g., no error message anymore).
By the way if anyone is trying to install 1.0.3 (not 1.0.4) via homebrew, first uninstall casperjs and then do:
brew install https://raw.github.com/mxcl/homebrew/8f7a1311af77b13b2bd5cc0d760290a320024525/Library/Formula/casperjs.rb

:+1: Finally!!


Docker args config

Support both create_container and start optional args. Made args configurable, so you do not have to extend DockerSpawner to just change the args.

@jhamrick Would def start(self, image=None, extra_create_kwargs={}, extra_start_kwargs={}) work?

Thanks! I would just say one other change -- could you make it be extra_create_kwargs=None and extra_start_kwargs=None in the function definition, rather than {}? There can be some nasty unpredictable bugs if you make default keyword objects be mutable objects. So if you set them to None, then you can check in the function body whether they're None, and if so, set them to {} there.

Thanks!

This looks great! I actually just realized, though, that this change will also require updating systemuserspawner.py because it still assumes the **kwargs function signature: https://github.com/jupyter/dockerspawner/blob/master/dockerspawner/systemuserspawner.py#L119
Could you update that, too, so that it passes the working directory as part of extra_create_kwargs?

Any other place where this will trickle down that I need to go clean up?

Perfect. I think those are all the places we need to worry about in this repository, at least.


Update all pypi.python.org URLs to pypi.org

For details on the new PyPI, see the blog post:
https://pythoninsider.blogspot.ca/2018/04/new-pypi-launched-legacy-pypi-shutting.html

Thanks. I did this for Flask, but all the other Pallets projects still need to be updated.


500 error returned when trying to manage participants for an engagement

Prerequisites

[X] I've searched for existing issues

Describe the bug
This was reported on the production site. It is only affecting a specific engagement. Originally it was only when navigating to the "Access needs" tab of the manage participants page. After adding an additional user it is now also affecting the Manage Participants page itself.
This issue was not reproduced on the staging site, and also not with on a local dev environment.
What's also curious is that this doesn't trigger a Flare error report.
To Reproduce
Steps to reproduce the behavior:

Login with the IRIS org account
View the survey engagement
Open the manage participants page
See the 500 error page

Expected behavior
The page should load without any errors.
Screenshots

I managed to get something locally that returns an error like preg_match(): Compilation failed: regular expression is too large at offset. Looks like passing in the model to localizedRouteIs() method causes this. The model doesn't seem to need to be passed in here, perhaps this was a copy/past error.


has_and_belongs_to_many( :join_table => 'this must be a string' )

We are getting a code base to run both in ruby and in jruby with ActiveRecord, and in this case it is 2.3.x, so you may want to just ignore this issue.
When using has_and_belongs_to_many, the :join_table option must have a string value.
In spinning up our existing code base, activerecord-jdbc is throwing errors here https://github.com/jruby/activerecord-jdbc-adapter/blob/v1.2.1/lib/arjdbc/postgresql/adapter.rb#L307 when the table is a symbol.
I've looked at the code examples in the ActiveRecord API documentation, and they all use strings for the value of :join_table so this may be just a bonus that the standard rails postgresql adapter takes care of for us.
I'm fixing this on my end, converting these from Symbol's to Strings in my models, I just thought you should be aware of it.

That code doesn't exist any more in the latest releases, so I think we're good. Thanks for reporting!

Cool, glad to help.


Black screen after scrolling down and coming back to video view

Not enough background info

Versions :
"react-native-youtube": "^1.0.0-alpha.4",
"react": "~15.4.0-rc.4",
"react-native": "0.42.3",

I integrated youtube player as given example in readme.md. When I opened it works fine. When I scroll down and come back that video player is becoming black . I am putting that view in ListView

Yes. Am also facing the same issue. anyone knows the solution for this? @Dineshchitta

Nope .  We couldn't figure out why it is happening @moorthysubu

@davidohayon669 When I tried with normal scrollview it worked fine. But when I put it in ListView I am getting that issue

@Dineshchitta To my understanding, the components in a ListView gets mounted and unmounted to save memory. Try removeClippedSubviews={false} on the ListView, but this doesn't sound like a problem with this package


Feature request: Enable a way to hold down a button without locking the mouse click

microbit.org-ticket: 1976
This is a feature request to allow simulation of a button pressed down without having to maintain the mouse clicked on the button. Freeing up the mouse while maintaining the button pressed would allow interaction with other input features of the micro:bit (momentarily pressing the other button, changing tilt, changing orientation, etc).
As an example, the following if statement cannot be triggered in the emulator:

By design, the simulator only supports a subset of functionality available on the hardware.  I don't see a natural way to support simultaneous inputs to the simulator.

Perhaps on long press there could be a small "pop-up" in the DOM (like a tick box?) to maintain the button pressed down? It could then be "unticked" (and the pop-up removed) to deactivate it.

Hi,
When I submitted this feature request, my suggested solution was to allow two "clickable" areas: one would work as a button and the other one would work as a switch.
Thanks.

How about keyboard controls for the simulator?
I have games where you might need to press e.g. A and then B within a very short time, which is a similar problem.

@veler did the accessibility work add keyboard shortcuts for the simulator?

As Microbit doesn't support a long press, but just the state "pressed" (push the button down then back, and only at this moment an event fire), this feature is actually not available in Microbit.
But it is available for Adafruit as the board supports a long press feature. You can already do it with the mouse and it will be soon available with the keyboard.

The micro:bit DAL does support a long press event, which is why the event is fired on release rather than on pressed down.

I would have to check again, but if memory serves me right MakeCode at the moment does not differentiate between short and long press (please somebody correct me here if I'm wrong!). So not sure if that is something that would have be discussed if we want to add it as a new block, or how that difference would affect the accessibility assessment.

MakeCode for the micro:bit does already differentiate between short and long press, it's just not implemented in the simulator #2445

@microbit-carlos the micro:bit does differenciate hold, click, double-click, etc... If we introduce a hold gesture, we would not be able to support these events in the future.

Okay, so MakeCode does currently differentiate between click and long click events? But it is not implemented in the emulator? Why would introducing a "hold gesture" block the ability to support these events in the future?
The original ticket was about enabling a way within for the emulator UI to be able to "physically" press the button without locking the mouse in a click action, so that the user could trigger more than one thing at the same time. How that gets "gesture" is interpreted by the simulated code underneath was not really within the scope of the original request.
Just to have a more concrete example for the sake of argument, let's say if a DOM "on mouse down" event happens on the emulator button, and then "on mouse up" happens outside of the button, this could be interpreted as the user still pressing down the micro:bit button until a new "click" or "mouse up" happens on top of the button. With something like that the emulator can still differentiate between a short click, long click, or other DAL events, no?

What about a "KEEP PRESSED" check button?


Added move types

Added feature:
Three movement mode of panorama
touch
motion
all (touch and motion)
Example "MonoImage" changed for demonstrate new feature.
(I accidentally broke the old pull request while doing the rebase, so I made a new one. D:)

Hi @Allui,
Thanks for your PR!
We are also considering features like movement mode for PanoramaView.
In your code, you defined enum PanoramaMoveType as a single value to toggle rotation methods. However, if specify them all at once, every associated parts are updated every time, which is slightly inconvenient for thread-safe implementation.
How about implementing this feature as separated variables like this? (#34)
// PanoramaView.swift

public var isDeviceMotionEnabled: Bool { get set }

public var isPanGestureEnabled: Bool { get set }

Hi @junpluse,
This (#34) solution is better, but how to reset camera position to zero, when changing movement mode on the fly?
For this i made:
public func fullyResetRotation() {
         userRotationNode.transform = SCNMatrix4Identity
         referenceRotationNode.transform = SCNMatrix4Identity
         deviceOrientationNode.transform = SCNMatrix4Identity
 }


refactor: update blas/ext/base/scusumors

updates blas/ext/base/scusumors to follow current project conventions
Related Issues

Does this pull request have any related issues?
#788
#1152

This pull request:

fixes #1519

Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

Hi @Planeshifter, I have implemented the changes


How to exclude electron imports from renderer process when building for web?

I dont know whether this is basic question or something more.
So heres the things i have now,
*) A custom Title Menu component with minimize, Maximize and Close in my Renderer Process.
For this i had to import electron in my component. Everything is working perfectly when i build Desktop App. But my problem is when i build for web, the build failed with error saying "Can't resolve 'fs' in '/home/emjimadhu/Projects/sample_app/node_modules/electron'"
So what can i do to exclude electron imports when i compile for web?
Thank you.

@emjimadhu
electron-vue provides a global variable to let you know if you are building for electron vs. web. You can reference process.env.IS_WEB to determine how your application logic should be handled.
Example in default src/renderer/main.js
if (!process.env.IS_WEB) Vue.use(require('vue-electron'))

Other than this, there isn't any magical way for the build process to handle this logic for you.

have to comment as I encountered the same and what seems to work is this
/src/renderer/main.js

if (!process.env.IS_WEB) Vue.use(VUE_ELECTRON)

instead of if (!process.env.IS_WEB) Vue.use(require('vue-electron'))
/.electron-vue/webpack.renderer.config.js

  plugins: [
    /* add to plugins */
    new webpack.ProvidePlugin({
      VUE_ELECTRON: 'vue-electron'
    }),
    /* more plugins */
  ]

/.eslintrc.js

/* to suppress eslint no undefined variables error */
globals: {
    __static: true,
    VUE_ELECTRON: true
}

it seems to work so far, maybe this could be default in electron-vue (if others can confirm that it works properly) @SimulatedGREG  ?

@CanRau: using require like @SimulatedGREG stated works for me though.

Either way will work, but I believe using the webpack.ProvidePlugin would be a little too magical for entry-level users. The provided IS_WEB environment variable solves the problem and is more flexiable since it can be used for more than just VUE_ELECTRON.

um, I had the proposed way already in place which produced the above mentioned error, the magic solved it for me ;)
so if it's usually working, of course stick with it..might be some changes I made (don't know exactly right now^^)


Un-deprecate bind_to_port and use_original_dst.

Opening separate issue for visibility.
It's noteworthy that migrating away from non-binding listeners to a single listener with multiple filter chains is going to be painful in highly dynamic systems, because, due to a missing FilterChain Discovery Service (FDS), each update will require draining of the listener. Perhaps it should be a blocker for the removal?
cc @mattklein123 @alyssawilk @htuch

@PiotrSikora I'd like to hear someone state that the drain behavior in a real-world situation is going to make FDS necessary before making it a strict blocker. So far, we're just guessing I think? OTOH I totally agree we should do FDS sooner rather than later, this will be needed for on-demand LDS and solves the high churn story.

@htuch yes, it's not a strict blocker (hence the question mark), but I'm a bit concerned about the reliability of constant draining and it's effect on long-lived connections.
This might be a moot point, though, considering that @ggreenway already started working on F(C)DS.

@rshriram the point of FDS is that the listener blob delivered via LDS is just the top-level configuration; it's relatively stable and never updates. Instead, individual filter chains update, none of which requires a drain.

FWIW, this also covers the use of use_original_dst, another deprecated field that was slated for upcoming  default fatal-on-startup. We need to preserve both until we have Istio migrate to this.
@PiotrSikora @costinm can you provide an updated statement on what time frames we should be intending to drive this deprecation in FTR?

@silentdai is working on this.

Yep, I'm just wondering if we can get an agreement on which release version we're all comfortable with deprecation taking place in?

We would be comfortable with use_original_dst and bind_to_port to be marked as fatal-by-default on July 1st 2019. Would it be possible to keep these fields exempt from deprecation process until that date?

Jul 2019 would match Istio plans - if 1.2 and 1.3 don't get delayed. Given vacations and history - I would be more comfortable with Dec ( or as late as we can get ).

fatal by default "in july" means it'd actually flip when we cut the September Envoy build, and the code would be safe to remove in 2020, when it was slated by removal in 2018.  I think we can do better than that.
I think we should make it fatal-by-default either in this or the next Envoy release (likely the next to allow for tooling), make it super easy for the Istio's Envoy build to override that fatal-by-default (since we're in good communication with you about deprecation/removal timeline but that'd force any lingering users to move over and start the clock for removal) and then when you folks hit 1.2 we can remove the code as quickly as the Envoy policy allows.  Does this sound plausible from your end?

I'm going to just close this. This will live until v2 dies and then it's gone.

@lambdai @costinm now that we have drainless listener updates, are we good to deprecate bind_to_port and remove this on the Envoy minor version cycle? Reopening to track this for v3.

Per the chat today, we're going to un-deprecate bind_to_port and use_original_dst.
cc @tbarrella

@costinm @PiotrSikora can you folks summarize the key issues around why Istio has been unable to move to non-virtual listeners? Since we're making a fairly big exception here, it would be good to record for posterity why this deprecation didn't work as planned.

It looks like bind_to_port is a hidden field that has been part of DeprecatedV1 ever since it was introduced to the proto API (https://github.com/envoyproxy/data-plane-api/pull/143). Just to make sure, it should be exposed and moved to the top level of config.listener.v3.Listener as in #329? Does this need extra API approval?
Undeprecating use_original_dst will cause hidden_envoy_deprecated_use_original_dst to be renamed. I'm assuming this breaking change is fine since anyone using a hidden_envoy_deprecated_ field should expect a breaking change at any point, but want to make sure.

I think there are a few primary issues:

Draining granularity - this is already fixed by what Yuchen did to make draining per filter chain
Time + Risk - we simply haven't had the time to migrate everything over, and when we do it will be a massive change that introduces substantial risk, which also likely means two code+testing paths for quite some time
I suspect, but have not proven either way, that filter_chain_match trie logic (https://github.com/envoyproxy/envoy/issues/12572) may make things more challenging for the reasons mentioned in that issue.
NACK granularity - now the entirety of listener config will be rejected together since we have a single massive listener
Scalability of XDS - this is probably not an issue. Today, we send N listeners with M filter chains. On any change, we send all NM listeners. With this change, we will send one listener with NM filter chains, which is the same. Theoretically if we implemented delta XDS we could optimize this with bind_to_port=false but not with single listener without something like FilterChainDS

I suspect (4) is  a major problem - we really only have 2 listeners, one for iptables inbound and one for outbound.
Even if Envoy can still start the listener and ignore filter chains that are broken ( which I don't think happens now), the
error reporting and metrics will be off, meaning users will need to adjust alerts and debugging.

@howardjohn @PiotrSikora @costinm @htuch could one of you tell @tbarrella how the undeprecation should work?  I take it that the 'hidden_envoy_deprecated_' fields should themselves go through a deprecation process?

I don't think renaming a field breaks protobuf compatibility (just like adding hidden_envoy_deprecated_ didn't break it in the first place), so it should be fine to just rename it I would guess, without being familiar with Envoy api process.

Renaming a field breaks loading the config via yaml. Documentation on envoy processes around this are here: https://github.com/envoyproxy/envoy/blob/master/api/API_VERSIONING.md#backwards-compatibility

Thank you, yeah, maybe it was an easy fix but I noticed the field name showed up in Istio code (https://github.com/istio/istio/pull/25159)
So then according to the policy the hidden field should only be removed in v4alpha. If it's important, maybe the non-hidden field could be added in v3 by removing the reserve field here and replacing it with this? This would be kind of confusing though and the newly-added non-hidden field would have a different ID
Similarly, the DeprecatedV1 shouldn't be removed till v4alpha, but are there any approval extra steps needed to add bind_to_port to v3?

and the newly-added non-hidden field would have a different ID

I think if you do this you break wire compatibility. We don't want a new field, right? We just want the existing one to no longer be deprecated.

Renaming a field breaks loading the config via yaml

Does this still apply for a field that already requires an explicit runtime override to be able to even configure it? It was already broken in this manner, to change it back would just be to "un-break" it from my point of view

@howardjohn @costinm thanks for the explanation, super helpful.
I think we can just rename the hidden_ fields; any use of them outside of Envoy is illegal, and you can update their names in the Envoy source. Istio's current use of this is outside-of-contract. Please do this in the v3 API. For the v2 API, I'm not sure if we need to make any changes, since the fields still exist there, they are just marked deprecated.

Thank you. What about deprecated_v1.bind_to_port? Should that and a new bind_to_port coexist in v3, with both being valid, or with the old option being ignored? deprecated_v1.bind_to_port wasn't marked deprecated in v2 proto, so if I try to remove it in v3, proto_format.sh fix complains

Hm, I don't really have context on this beyond what @PiotrSikora @howardjohn @costinm already said; they'd probably be able to answer better than me. My understanding though is that bind_to_port should be retained in the long term

We use bind_to_port on the outbound chain - and if we are allowed we'll likely keep it. We are exploring other modes
of interception besides iptables REDIRECT - like raw binding to the IP, which will look exactly like the current config but with
real binding to each IP:port. And it's cleaner/simpler.
On the inbound chain - we will make big changes when we move to BTS, i.e. everything will move to vhosts and routes.

@htuch do you think it's fine to proceed with the plan at the end of https://github.com/envoyproxy/envoy/issues/5355#issuecomment-743466041?

Seems like a reasonable plan, but I'd like to be deliberative about this undeprecation if we live with it long term. Tagging folks who have done significant listener work and are effective owners. @lambdai @mattklein123 @PiotrSikora WDYT?

I just learned that another factor is there's an attempt to totally preserve backward compatibility on the wire; it seems the other Istio folks have more context. For example, renaming deprecated_v1 but not changing the message structure or field numbers. I'm not sure how realistic of a goal this is

My two cents:
Pros:

Flexibility: since 2 level listener is theoretically more powerful in terms of splitting responsibility and listener update granular. This functionality is proved useful and it's supporting istio.
Cons:
Simplicity of code flow: Two level listener is error-prone. There is no well defined boundary and test coverage. One 0-day and several bugs were introduced partially because of the complexity of bind_to_port.
Simplicity of traffic matcher: Two level listener has two set of matchers, filter chain match the bind_to_port=true listener; find the best bind_to_port=false listener; and another round of filter chain match in the later listener. It's a spaghetti match flow if all of the 3 are used.
Scalability: Bind_to_port is designed for tens of listeners. Istio need to support more than this scale.

I'm fine with keeping bind to port right now. I agree it adds some complexity, but it's mostly limited to a single place in the code (connection handler) and the code has already been there for a very long time. We can always deprecate it later if we feel that it becomes truly redundant.
In terms of the actual proto, I would have to look at it myself, but I think it's fine to just add a new field in v3 if that is what it takes.

Yep, new v3 field, +1 on going ahead with reintroducing.

Great, thank you all, I'm happy that alignment is clear now!
To summarize and add some context from discussing offline with @howardjohn @costinm,

bind_to_port will be added with the deprecated_v1 option remaining but marked as deprecated in v3. If either bind_to_port or deprecated_v1.bind_to_port is set to false, this will be interpreted as false, since true is the default
Originally there was a hope (among Istio developers) that wire compatibility could be preserved, based on an assumption that previous deprecation of this field could just be reverted. But it turns out that this field was always "deprecated" ever since it was migrated from json to proto (https://github.com/envoyproxy/data-plane-api/pull/143). This is fine for Istio though as long as the old field isn't removed in v3, and it won't be, since that would be against Envoy's breaking change policy

The PRs to undeprecate both parameters have been merged; it sounds like new issues will be created when old code paths need to be cleaned up in the future, so does that mean this issue can be closed now?

The PRs to undeprecate both parameters have been merged; it sounds like new issues will be created when old code paths need to be cleaned up in the future, so does that mean this issue can be closed now?


Parse URI

Mondot is parsing URI using regex and i see two problems with that:

Impossible to tell the user what is wrong with URI
The regex must be correct

The first one is not a big problem and can be ignored. The second one is very serious.

[ ] Fail to parse against IPv6

Mondot is being reworked and some features are being deleted.
This is one of them.


Create Custom Windows VT Sequence

Description of the new feature/enhancement
As found in issue #1868 (and perhaps any other issues that rely on custom, dynamic changes to terminal appearance based on changes, e.g. ssh to other machine) & discussed on #8064 , there is a need to implement a custom Windows Terminal VT sequence to allow for later work (such as for #1868) to be app-driven. This is beyond the scope of #1868 and hence deserves its own issue ticket
If features such as #1868 are still desired, this would seem like the logical route to go down

Wait hold up, I'm not sure how this is different from #1868 at all. That issue is tracking "author a VT sequence to allow apps to set the tab icon". If I'm not mistaken, this issue is also tracking "author a VT sequence to let the application set the window icon", correct?

We might be seeing different things (I wouldn't put this past my personal struggle with finding matching issues in github)
I can't pull up  an issue which matches what you are saying above with regards to "author a VT sequence to allow apps to set the tab icon"

are you referring to just a sub feature noted within #1868 ?
I might be misunderstanding how things are organised here; this ticket was to start a conversation on carrying out the VT work (which seemingly needs to happen before #1868 can be resolved, as that issue has "gone cold")  because a) this is a feature in itself, which I would see as being beyond the scope of #1868 and b) I could not see any other issue which was specifically working on this, but it sounds like perhaps you can

Hey sorry, I didn't mean that those were literally the titles of the issues, more just what the gist of the issue was fundamentally about.
I think at the end of the day, #1868 needs a new VT sequence to be able to set the tab icon, and part of the work for #1868 is coming up with that sequence. I don't think we really need another thread to track how we're gonna author that sequence, since coming up with the sequence is like 90% of the work of #1868. Yea, that issue's fairly cold, but that's just because there's a lot of work that's being tracked and we can't keep every thread moving simultaneously. We'll come back to it at some point, which is why it's still open ☺
Sorry for the miscommunication!
/dup #1868


Some edges are not connected when opening in live mode

Original FBP graph definition:
ingress-table(c-flo/ingress-table) CBASE -> STATE partymods(c-flo/DetectPartyMods)
partymods LIGHTS -> COLORS ampel-nerd(c-flo/ampel-nerd)

However, when opening in Flowhub live mode, these edges are not shown connected:

The only difference between these and other edges seems to be that this particular flow includes a noflo-runtime-msgflo participant

One potential reason is that this participant starts quite a bit later than the others

There is a 10-second timeout for waiting for participants. Could try to increase that to see if it helps? It should probably be made configurable.
The related problem is that the coordinator does not ensure that bindings exists for participants which appear at an arbitrary time, outside of the coordinators control...
The challenge here is that we actually have two graphs/networks. One is the desired configuration, potentially initially from --graph foo.json, then modified onwards via the FBP protocol client. The other is the actual live-situation, which is influenced by participant existance. Mostly the coordinator works to adjust the actual situation to match desired, but there are also cases where actual info informs desired - like when unknown participants pop up, or when one port sends directly to another (effectively already bound).

Maybe the cleanest way to represent this would be to keep a list of "pending" actions (needed to realize desired state), with data about any (missing) dependencies attached. Actions without dependencies can be fired right away, but should the list include them? Their realization could fail (and need retrying), so mostly a question of whether we pop optimistically or upon verification of having reached desired state.
On participant changes we'd check our list of pending actions if any dependencies are now met, and if so, execute the action.

I'm at least not seeing us hit https://github.com/msgflo/msgflo/blob/master/src/coordinator.coffee#L33

Suggestion on how to improve coordinator start-up:

Start using fbp-graph as the internal graph representation for better metadata, events, etc
Load graph from file, mark everything "dead" via node/edge metadata
When discovery message(s) arrive, rectify graph data and mark affected parts as "non-dead"

Those are all nice-to-have, outside of the scope of this bug.

I investigated this a bit. We are monitoring for participant changes at any time, but our checking/ensuring that queues are setup is broken (checkParticipantConnections).
There are several different cases the code needs to handle.

Two (or more) participant in+out ports have the same queue.
That means they are already connected, so we don't need (and should not try) to bind them.
Should ensure that @connections contains this fact.
Graph says that outport of one participant role should be bound to the inport of another participant role (different queues). If the binding does not exist, have to create it. On success, should update @connections with fact that they are now created.

It looks like 2) is broken and this is causing this bug. We actually don't even keep the desired graph or connections around... Need to do that somehow.

Actually the issue was that we were not using the regular codepaths for starting participants / adding connections at all, but using some outdated special-cased-and-generally-broken logic.


Use jbuilder and to update to datakit 0.11

This repo could do with some CI!

should we create linuxkit-ci-ci?


Error: showLintError is not a registered action

I'm trying to implement custom rules. My plugin and rules used to work just fine in Camunda Modeler < 5.3 with the "old" approach.
Now I updated the modeler and adapted to the build-in linter plugin and the way custom rules are now implemented.
I got some errors when trying in out with my own plugin so I went ahead and tried to break the issue down by checking if it is related to my rules or if it is a more general issue.
So I build the camunda-modeler-custom-linter-rules plugin project template (without any changes!) and added it to my modeler. I get the same error and behavior:

This happens when clicking on the error in the Linter Tab. Full console output:
showLintError is not a registered action
    at Ba (webpack://camunda-modeler-client/node_modules/diagram-js/lib/features/editor-actions/EditorActions.js:259:9)
    at error (webpack://camunda-modeler-client/node_modules/diagram-js/lib/features/editor-actions/EditorActions.js:169:10)
    at trigger (webpack://camunda-modeler-client/src/app/tabs/bpmn/BpmnEditor.js:723:40)
    at triggerAction (webpack://camunda-modeler-client/src/app/tabs/MultiSheetTab.js:269:18)
    at triggerAction (webpack://camunda-modeler-client/src/app/tabs/EditorTab.js:36:33)
    at triggerAction (webpack://camunda-modeler-client/src/app/App.js:1831:15)
    at file:///MY_DISK/camunda-modeler-win/resources/app.asar/public/bundle.js:2:2883152
    at file:///MY_DISK/camunda-modeler-win/resources/app.asar/public/72.js:1:3411
    at file:///MY_DISK/camunda-modeler-win/resources/app.asar/public/490.js:1:8466
    at apply (webpack://camunda-modeler-client/node_modules/react-dom/cjs/react-dom.production.min.js:14:427) [ error ]
This error may be the result of a plug-in compatibility issue. [ info ]
[Disable plug-ins (restarts the app)](https://github.com/camunda/camunda-modeler-custom-linter-rules-plugin/issues/new#) [ info ]

Camunda Modeler 5.5.1 and current HEAD of this repo.
Is this supposed to happen? I would have expected this link to jump to the error location...

Same error with the nightly for me:
showLintError is not a registered action
    at us (webpack://camunda-modeler-client/node_modules/bpmn-js/node_modules/diagram-js/lib/features/editor-actions/EditorActions.js:259:9)
    at error (webpack://camunda-modeler-client/node_modules/bpmn-js/node_modules/diagram-js/lib/features/editor-actions/EditorActions.js:169:10)
    at trigger (webpack://camunda-modeler-client/src/app/tabs/bpmn/BpmnEditor.js:723:40)
    at triggerAction (webpack://camunda-modeler-client/src/app/tabs/MultiSheetTab.js:269:18)
    at triggerAction (webpack://camunda-modeler-client/src/app/tabs/EditorTab.js:36:33)
    at triggerAction (webpack://camunda-modeler-client/src/app/App.js:1831:15)
    at file:///MY_DISK/camunda-modeler/resources/app.asar/public/bundle.js:2:2641508
    at file:///MY_DISK/camunda-modeler/resources/app.asar/public/72.js:1:3411
    at file:///MY_DISK/camunda-modeler/resources/app.asar/public/900.js:1:9351
    at apply (webpack://camunda-modeler-client/node_modules/react-dom/cjs/react-dom.production.min.js:14:427) [ error ]
This error may be the result of a plug-in compatibility issue. [ info ]

We'd need to fix this / address this in C7.

Thanks for taking your time to report all these glitches.


Incorporate more Yukon area types

Closes #630.
This PR, along with its corresponding API PR (https://github.com/ua-snap/data-api/pull/407), incorporates the following Yukon areas into NCR:

Yukon Fire Districts
Yukon Game Management Subzones
Yukon Watersheds

To test:

export SNAP_API_URL=http://localhost:5000
Run both the API and NCR from their respective more_yukon_areas branches.
Try clicking a few areas within the Yukon territory on NCR's location search map. Verify that each of the new Yukon area types are represented in the search results. Similar to Alaska's Fire Management Zones, Yukon Fire District polygons are not drawn on the map because they can be quite large. But all three of the new Yukon area types should show up in the bulleted list of search results if they intersect the point to clicked.
Load some reports for the new Yukon area types and verify that they load as expected & have some data.

Setting this PR as draft mode for now since it would be too ambitious to merge it (+ the corresponding API PR) before our upcoming launch. I think the PR is good to go otherwise, so we'll want to set it back to non-draft mode sometime after the upcoming launch.


Quine not accepted even though it is completely valid?

(a=b=>write((a=${a})()))()
should work, perfectly. The expected and output are identical in every way. I can't figure it out.

If the program terminates without emitting a trailing newline, bash will add one. To resolve, add a newline to your source.

Duplicate of #11


Permission denied - /opt/homebrew-cask

brew cask install is not working --> Permission denied - /opt/homebrew-cask
history
osx 10.10
install brew
brew works
upgrade to osx 10.11
install brew cask
--> cask nor working
imac4ado:sync ado$ brew cask doctor
==> We need to make Caskroom for the first time at /opt/homebrew-cask/Caskroom
==> We'll set permissions properly so we won't need sudo in the future
==> OS X Release:
10.11
==> OS X Release with Patchlevel:
10.11
==> Hardware Architecture:
intel-64
==> Ruby Version:
2.0.0-p645
==> Ruby Path:
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
==> Homebrew Version:
0.9.5 (git revision 142f61; last commit 2015-10-17)
==> Homebrew Executable Path:
/usr/local/bin/brew
==> Homebrew Cellar Path:
/usr/local/Cellar
==> Homebrew Repository Path:
/usr/local
==> Homebrew Origin:
https://github.com/Homebrew/homebrew
==> Homebrew-cask Version:
0.58.0
==> Homebrew-cask Install Location:
/usr/local/Cellar/brew-cask/0.58.0
==> Homebrew-cask Staging Location:
/opt/homebrew-cask/Caskroom (error: path does not exist)
==> Homebrew-cask Cached Downloads:
/Library/Caches/Homebrew
/Library/Caches/Homebrew/Casks
2 files (warning: run "brew cask cleanup")
1.12 megs (warning: run "brew cask cleanup")
==> Homebrew-cask Default Tap Path:
/usr/local/Library/Taps/caskroom/homebrew-cask
==> Homebrew-cask Alternate Cask Taps:

==> Homebrew-cask Default Tap Cask Count:
2806
==> Contents of $LOAD_PATH:
/usr/local/Cellar/brew-cask/0.58.0/rubylib
/Library/Ruby/Site/2.0.0
/Library/Ruby/Site/2.0.0/x86_64-darwin15
/Library/Ruby/Site/2.0.0/universal-darwin15
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/universal-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/x86_64-darwin15
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin15
==> Contents of $RUBYLIB Environment Variable:

==> Contents of $RUBYOPT Environment Variable:

==> Contents of $RUBYPATH Environment Variable:

==> Contents of $RBENV_VERSION Environment Variable:

==> Contents of $CHRUBY_VERSION Environment Variable:

==> Contents of $GEM_HOME Environment Variable:

==> Contents of $GEM_PATH Environment Variable:

==> Contents of $BUNDLE_PATH Environment Variable:

==> Contents of $PATH Environment Variable:
PATH="/~/sync:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/local/Library/ENV/scm"
==> Contents of $SHELL Environment Variable:
SHELL="/bin/bash"
==> Contents of Locale Environment Variables:
LANG="de_DE.UTF-8"
==> Running As Privileged User:
No
imac4ado:sync ado$ brew cask instal supaview
==> We need to make Caskroom for the first time at /opt/homebrew-cask/Caskroom
==> We'll set permissions properly so we won't need sudo in the future
==> Downloading http://twinside.free.fr/supaview/SupaView.1.3.2.zip
Already downloaded: /Library/Caches/Homebrew/supaview-1.3.2.zip
Error: Permission denied - /opt/homebrew-cask
Most likely, this means you have an outdated version of homebrew-cask. Please run:
  brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup

If this doesn’t fix the problem, please report this bug:
  https://github.com/caskroom/homebrew-cask/issues

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:245:in mkdir' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:245:in fu_mkdir'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:219:in block (2 levels) in mkdir_p' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:217:in reverse_each'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:217:in block in mkdir_p' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:203:in each'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:203:in mkdir_p' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/installer.rb:100:in extract_primary_container'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/installer.rb:65:in install' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:20:in block in install_casks'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:17:in each' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:17:in install_casks'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:6:in run' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli.rb:79:in run_command'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli.rb:119:in process' /usr/local/Cellar/brew-cask/0.58.0/rubylib/brew-cask-cmd.rb:19:in '
imac4ado:sync ado$ brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup
Updated Homebrew from 142f61a6 to 25f3f43f.
==> Updated Formulae
deis                        deisctl                     gauge                       redis
Error: caskroom/cask/brew-cask 0.58.0 already installed
imac4ado:sync ado$ brew cask instal supaview
==> We need to make Caskroom for the first time at /opt/homebrew-cask/Caskroom
==> We'll set permissions properly so we won't need sudo in the future
==> Downloading http://twinside.free.fr/supaview/SupaView.1.3.2.zip
Already downloaded: /Library/Caches/Homebrew/supaview-1.3.2.zip
Error: Permission denied - /opt/homebrew-cask
Most likely, this means you have an outdated version of homebrew-cask. Please run:
  brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup

If this doesn’t fix the problem, please report this bug:
  https://github.com/caskroom/homebrew-cask/issues

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:245:in mkdir' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:245:in fu_mkdir'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:219:in block (2 levels) in mkdir_p' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:217:in reverse_each'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:217:in block in mkdir_p' /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:203:in each'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/fileutils.rb:203:in mkdir_p' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/installer.rb:100:in extract_primary_container'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/installer.rb:65:in install' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:20:in block in install_casks'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:17:in each' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:17:in install_casks'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli/install.rb:6:in run' /usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli.rb:79:in run_command'
/usr/local/Cellar/brew-cask/0.58.0/rubylib/hbc/cli.rb:119:in process' /usr/local/Cellar/brew-cask/0.58.0/rubylib/brew-cask-cmd.rb:19:in '
imac4ado:sync ado$
brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup
does not solve the problem
imac4ado:sync ado$ sudo ls -arlt /opt/homebrew-cask
total 0
drwxr-xr-x  2 ado       staff   68 17 Okt 19:28 Caskroom
drwx------@ 4 macports  staff  136 17 Okt 19:28 ..
drwxr-xr-x  3 ado       staff  102 17 Okt 19:28 .

Reporting Bugs.
Your report is really hard to read, as it is.

Same problem over here.
➜  ~  brew cask install shady --verbose
==> Downloading http://instinctivecode.com/shady/shady_1.0.3.zip
Already downloaded: /Library/Caches/Homebrew/shady-1.0.3.zip
==> Symlinking App 'Shady.app' to '/Users/user/Applications/Shady.app'
==> ln: /Users/user/Applications/Shady.app: Permission denied
Error: Command failed to execute!

==> Failed command:
["/bin/ln", "-hfs", "--", "#<Pathname:/opt/homebrew-cask/Caskroom/shady/1.0.3/Shady.app>", "#<Pathname:/Users/user/Applications/Shady.app>"]

==> Output of failed command:

==> Exit status of failed command:
#<Process::Status: pid 48341 exit 1>

Here's the output for brew cask doctor:
➜  ~  brew cask doctor
==> OS X Release:
10.10
==> OS X Release with Patchlevel:
10.10.4
==> Hardware Architecture:
intel-64
==> Ruby Version:
2.0.0-p481
==> Ruby Path:
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
==> Homebrew Version:
0.9.5 (git revision 0deb; last commit 2015-10-18)
==> Homebrew Executable Path:
/usr/local/bin/brew
==> Homebrew Cellar Path:
/usr/local/Cellar
==> Homebrew Repository Path:
/usr/local
==> Homebrew Origin:
https://github.com/Homebrew/homebrew
==> Homebrew-cask Version:
0.58.0
==> Homebrew-cask Install Location:
/usr/local/Cellar/brew-cask/0.58.0
==> Homebrew-cask Staging Location:
/opt/homebrew-cask/Caskroom
==> Homebrew-cask Cached Downloads:
/Library/Caches/Homebrew
/Library/Caches/Homebrew/Casks
==> Homebrew-cask Default Tap Path:
/usr/local/Library/Taps/caskroom/homebrew-cask
==> Homebrew-cask Alternate Cask Taps:
/usr/local/Library/Taps/caskroom/homebrew-versions
==> Homebrew-cask Default Tap Cask Count:
2807
==> Contents of $LOAD_PATH:
/usr/local/Cellar/brew-cask/0.58.0/rubylib
/Library/Ruby/Site/2.0.0
/Library/Ruby/Site/2.0.0/x86_64-darwin14
/Library/Ruby/Site/2.0.0/universal-darwin14
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/x86_64-darwin14
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby/2.0.0/universal-darwin14
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/vendor_ruby
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/x86_64-darwin14
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin14
==> Contents of $RUBYLIB Environment Variable:
<NONE>
==> Contents of $RUBYOPT Environment Variable:
<NONE>
==> Contents of $RUBYPATH Environment Variable:
<NONE>
==> Contents of $RBENV_VERSION Environment Variable:
<NONE>
==> Contents of $CHRUBY_VERSION Environment Variable:
<NONE>
==> Contents of $GEM_HOME Environment Variable:
<NONE>
==> Contents of $GEM_PATH Environment Variable:
<NONE>
==> Contents of $BUNDLE_PATH Environment Variable:
<NONE>
==> Contents of $PATH Environment Variable:
PATH="/Users/user/.nvm/versions/node/v0.12.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/Library/ENV/scm"
==> Contents of $SHELL Environment Variable:
SHELL="/bin/zsh"
==> Contents of Locale Environment Variables:
LC_CTYPE="UTF-8"
==> Running As Privileged User:
No

Can you run brew doctor and see if following those directions fixes permissions? (or paste the output here and we can go from there)

Hi I have already done this see top of the terminal excerpt. I do not get over the point
imac4ado:sync ado$ brew cask doctor
==> We need to make Caskroom for the first time at /opt/homebrew-cask/Caskroom
==> We'll set permissions properly so we won't need sudo in the future

means doctor ask for password i enter this. everythink look fine. I run doctor again. It again ask for the pw to fix the problem.
folde permissions see ls at the end of my first post
BTW - Thank you for the quick response

Does
sudo mkdir -p /opt/homebrew-cask/Caskroom
sudo chown -R ${USER}:staff /opt/homebrew-cask

work?

unfortunally not
brew cask doctor

still tells
/opt/homebrew-cask/Caskroom (error: path does not exist)```

and the permissions look fine as well
````imac4ado:sync ado$ sudo ls -arlt /opt/homebrew-cask
total 0
drwxr-xr-x  2 ado       staff   68 17 Okt 19:28 Caskroom
drwx------@ 4 macports  staff  136 17 Okt 19:28 ..
drwxr-xr-x  3 ado       staff  102 17 Okt 19:28 .

@samer Your issue is likely unrelated. Your issue problem is with your ~/Applications directory.
Unfortunately, not really sure what to tell you there, @ado1. Let’s try this:
brew uninstall brew-cask
brew untap caskroom/cask
sudo rm -rf '/opt'
brew install caskroom/cask/brew-cask

@vitorgalvao true, something must have changed the permissions of ~/Applications to root:staff instead of user:staff. It works now. Sorry for hijacking the thread.

@vitorgalvao uninstall and install like as you stated has worked feels a little bit like a MS solutions :-)
But It works now Thank you

Sorry for hijacking the thread.

@samer No worries.

like a MS solutions :-)

@ado1 I agree, it does.

Thank you, @vitorgalvao, your suggestion (re-quoted below) fixed the same problem for me.
brew uninstall brew-cask
brew untap caskroom/cask
sudo rm -rf '/opt'
brew install caskroom/cask/brew-cask

brew install caskroom/cask/brew-cask is no longer valid and should not be used. Homebrew-cask is installed on-demand by homebrew.

Should I uninstall and then let homebrew do it's on-demand thing?

Should work as is.

This worked for me. 'brew search' answered my question.
brew search cuda
caskroom/drivers/cuda                    caskroom/cask/cuda-z
caskroom/versions/cuda-z-beta
If you meant "cuda" specifically:
It was migrated from caskroom/cask to caskroom/drivers.
You can access it again by running:
brew tap caskroom/drivers_
brew tap caskroom/drivers
brew cask install cuda
==> Satisfying dependencies
==> Downloading ...