[dev] update csi driver and operator versions to 2.14.0

Since we are about to start building master CNSA builds (v<IP_ADDRESS>), I figured we need to bump the CSI driver and operator versions.
Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature Enhancement
[ ] Test Automation
[ ] Code Refactoring (no functional changes, no api changes)
[X] Build related changes
[ ] Community Operator listing
[ ] Other (please describe):

What is the current behavior?

What is the new behavior?

How risky is this change?

[X] Small, isolated change
[ ] Medium, requires regression testing
[ ] Large, requires functional and regression testing

We should  also fix MakeFile (https://github.com/IBM/ibm-spectrum-scale-csi/blob/dev/operator/Makefile#L87) to remove the rhel-yaml file regeneration.


Partition tables

I'm ready to merge this: release notes:

The large tables associated with the TOAD data are all partitioned by month and have default indexes. More indexes can be added as needed - open an issue with a slow query.
Traffic signals are in the database at construction time
The TriMet and Census GIS files are in schemas trimet_gis and census_gis.
TOAD data covers September - November 2017 and 2018 - all days of the week.
Database has been restored to staging server.

Okay so we've reduced the data to just that which we are using for our graphic? I think that's a good move to get started for demo day, but it would probably be good to continue exploring if/how we could host all this data going forward (which it sounds like people are investigated) and not be limited to just a few months worth. It is certainly a lot of data!

@jbeyer16 Yeah, once we get stuff working end-to-end I'm planning to redesign the whole process assuming we get a file every month. That's contingent on some externalities, though - feedback from the "customer" saying it's a good idea and there's a demand for the finished product. ;-)


vmm: support VFIO device

Support VFIO device in vmm.
Run libc::connect() in spawn_blocking to avoid blocking other task.
Return OK() if sandbox is in CREATED state.

It would be better to split three commits, a little confusing to review if mixed together


need to click "Next" twice on the "Metadata" step of the wizard

Say I go through the wizard successfully, using the Continuous Deployment option, and on the last step, "Metadata", I fill all the empty inputs, but won't get out of the form by a Tab key or clicking in the blank to trigger validation -- instead, I click the "Next" button right after filling an empty input, so the click triggers the change event, which triggers validation. Validation succeeds, and then I need to click "Next" again.

Now validation begins after 1.5 seconds of not typing. If you are fast and click on next before validation is started you'll still have to click twice, but no idea how we could "fix" that. Have a look at how it responds now and if you have any other suggestions just add them here.

I think it works much better in this regard.


macos m1 arm64 build error

Alread used pod install
❌  Undefined symbols for architecture arm64
┌─ Symbol: skottie::Animation::seekFrameTime(double, sksg::InvalidationController*)
└─ Referenced from: skottie::Animation::seek(float, sksg::InvalidationController*) in libreact-native-skia-skottie.a[4](react-native-skia-skottie.o)

❌  ld: symbol(s) not found for architecture arm64

❌  clang: error: linker command failed with exit code 1 (use -v to see invocation)

react-native-skottie 2.1.4
@shopify/react-native-skia 1.3.6

Can you provide a repo with a reproduction please?

Had run into the same issue on an Intel MacBook (2020), on Expo, randomly, after not changing or running project locally for a month. Set my Xcode to 15.3, deleted ios and .expo directories, installed latest Skia (1.3.13) and rerun a fresh dev build, and it resolved itself.
Hopefully, this helps.


xcodebuild: error: Scheme libPhoneNumber is not currently configured for the clean action

Today when I run the script carthage update I found that there is an error with the libPhoneNumber. the error's description is  in the issue title.
Then I solved it by deleting the libPhoneNumber by hand then running cathage update again, it works. I wonder if we can add the clean configuration into this library?

Sorry for late, I was very very very busy :(
I recreated project last time, maybe I think it cause carthage error. So, did you meet that error again ?


The number of instructions seem not consistent with the paper

Hi,
I am trying to train my own model on RxR, but after I downloaded the data (guide data only), I found that the number of instructions in the provided file, i.e., rxr_train_guide.jsonl, seem not the same as your paper said. Specifically, the paper said there was 1,1089 paths in the training set, but it seems the unique path_ids in rxr_train_guide.jsonl (only English data I considered) are only 8000+. Besides, in Table 5 of the paper, it said there were totally 42K training pairs in Guide data for each language, but 26k was what I got from the file. I am confused about which numbers are right now. Please help. Thanks in advance.

Hey,
There should be ~11089 paths in the training set including all three languages. But, if you are only looking at English, the number of paths will be only 8824. While most paths are annotated in all three languages, there is a subset of paths that are only annotated in one language to give more variation in paths. See the last paragraph of Section 4, subsection 'Guide Task' in the paper.
The total number of training pairs in the Guide data is ~79467, which is the 'train' split of the 126k instructions detailed in Table 2 (the rest are in the val-seen, val-unseen, test-standard and test-challenge splits). This is about 26k per language, so your numbers sound right.

What about the 42k training pairs in Table 5? Should it be 26k actually?


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v4.7 to before v5.10.70",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5d9e2ab9fea4cdf0a2522f5cbed2e7fbb220d757",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=91e4ad05bf18322b5921d1a6c9b603f6eb1694f0"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "5d9e2ab9fea4cdf0a2522f5cbed2e7fbb220d757",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "91e4ad05bf18322b5921d1a6c9b603f6eb1694f0",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "mcb: fix error handling in mcb_alloc_bus()\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.10.70 by commit 91e4ad05bf18322b5921d1a6c9b603f6eb1694f0, it was introduced in version v4.7 by commit 5d9e2ab9fea4cdf0a2522f5cbed2e7fbb220d757. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001675


Fix 'wasPressed' never returning true

As detailed in #984 , GamePads.wasPressed() will never return true.
This happens because update() sets previous to current before updating current, but they're all pointing to the same object!
A potential fix is to make sure to only copy the values. For the convenience of the reviewer I also added a gamepad test to confirm that it currently does not work, and will work with this fix.
This version is a lot more verbose than the previous, but it works. I welcome suggestions on making it more concise/clear!

@daredevildave, can you review please?

Any updates/feedback @daredevildave ?

Hi Omar,
Can you complete the Contributors License Agreement?
https://docs.google.com/forms/d/e/1FAIpQLSfG9XHIgdapCBkvwxbXow592Y5NFPEKD5TM-TyWOmbaCbLeHA/viewform
Thanks

Just tested and it seems to work. Needs to be fixed to coding standards and CLA completed then I'll merge.
Thanks!

@daredevildave I've completed the CLA and fixed all the style issues, except for making each variable be declared on an individual line, because I noticed other parts in the code use this pattern:
var i, len = padDevices.length;
for (i = 0; i < len; i++) {

I've also made the gamepad example have an example of wasPressed as well as isPressed. That file isn't required for this PR but might be nice to have.

Change == to === and I think we're good.

Ah, yes, sorry about that! I started going through the style guide point by point and forgot about strict equality.
Should be good now.

Thanks! 👍


Corrected update of orientation for other entities

Addresses the issue #94 but still needs to resolve the issue of the camera_pyr affecting inp_state.direction, which really should be pulled from the client separately and should reflect the model's orientation.
Additions/modifications proposed in this pull request:

Modifies SetOrientation() to pull from inp_state.direction
Modifies AngleQuantize() which was eliminating half of the rotation
TODO: figure out how to update without relying on camera_pyr, which rotates the model when using the camera to look.
TODO: remove remnant debug code left in DEBUG_INPUT ifdefs.

This can be tested by logging into a character and typing the command /turnleft 1 into the chat window. This will set your character to rotate left indefinitely. Then log in with another character and confirm correct rotation.

As far as I can tell, the client should be sending an update of the model's orientation along with the position and camera_pyr. If we can capture that value directly, we can update direction correctly, and avoid some of the issue in this pull request. Thoughts @nemerle?

Meant to rebase at 50e9b45 instead of merge. Hope that doesn't mess anything up.

Despite what I expected, pulling this from camera_pyr or subsequently direction doesn't rotate the entity when the camera rotates. Why? I have no idea. haha.
At first I thought camera_pyr was mislabeled, but it definitely changes value when the camera moves, however it also changes when the entity rotates. So I'm not really clear what that is.
You can test with the following slash commands in the chat window (NOTE: /camrotate simply flags whether or not the camera rotates or the entity rotates:
/turnleft 1
/camrotate 1
/camrotate 0
/turnleft 0

In a way, this makes this easy on us. In the future we simply check if the entity IS_FLYING and if so, then update vec.x, vec.y, and vec.z instead of setting x and z to 0 value.


Python Formatter breaks multiline strings

Triple-quotes for multiline strings (usually used as docstrings) get replaced with single quotes --- this obviously breaks the syntax.
Error is:
Unable to format 'myfile.py'
Traceback (most recent call last):
  File "/usr/local/bin/python-formatter", line 9, in <module>
    load_entry_point('formatter2==1.1.0', 'console_scripts', 'python-formatter')()
  File "/usr/local/lib/python2.7/dist-packages/formatter2/main.py", line 32, in main
    formatter.format_path(file_, args.recursive)
  File "/usr/local/lib/python2.7/dist-packages/formatter2/formatter.py", line 47, in format_path
    self.format_file(path)
  File "/usr/local/lib/python2.7/dist-packages/formatter2/formatter.py", line 59, in format_file
    code = self(name)
  File "/usr/local/lib/python2.7/dist-packages/formatter2/formatter.py", line 37, in __call__
    compile(formatted, '', 'exec')
  File "", line 35
    '
    ^
SyntaxError: EOL while scanning string literal

Can you show me the test code? I've tried this and it works just fine:
myfile.py
'''
Testing some 'triple-single' "quoted" stuff with quotes
'''

"""
Testing some 'triple-single' "quoted" stuff with quotes
"""

Running the test:
# python-formatter -vv myfile.py
offset: <TokenOffset[0x10c344910:STRING]'\'\'\'\nTesting some \'triple-single\' "quoted" stuff with quotes\n\'\'\'' (0,0) None>
offset: <TokenOffset[0x10bb26950:NEWLINE]'\n' (0,0) None>
offset: <TokenOffset[0x10c344a90:NL]'\n' (0,0) None>
offset: <TokenOffset[0x10c344ad0:STRING]'"""\nTesting some \'triple-single\' "quoted" stuff with quotes\n"""' (0,0) None>
offset: <TokenOffset[0x10bb26950:NEWLINE]'\n' (0,0) None>
offset: <TokenOffset[0x10c344a90:NL]'\n' (0,0) None>
offset: <TokenOffset[0x10c344a90:NL]'\n' (0,0) None>
offset: <TokenOffset[0x10c344b10:ENDMARKER]'' (0,0) None>

Just try:
$ sudo pip3 install formatter2
$ git clone https://github.com/zalando/connexion.git
$ python-formatter connexion/connexion/app.py
Unable to format 'connexion/connexion/app.py'
Traceback (most recent call last):
  File "/usr/local/bin/python-formatter", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.4/dist-packages/formatter2/main.py", line 32, in main
    formatter.format_path(file_, args.recursive)
  File "/usr/local/lib/python3.4/dist-packages/formatter2/formatter.py", line 47, in format_path
    self.format_file(path)
  File "/usr/local/lib/python3.4/dist-packages/formatter2/formatter.py", line 59, in format_file
    code = self(name)
  File "/usr/local/lib/python3.4/dist-packages/formatter2/formatter.py", line 37, in __call__
    compile(formatted, '', 'exec')
  File "", line 1
    '
    ^
SyntaxError: EOL while scanning string literal

Indeed, apparently it doesn't work with multiline comments. I'll work on a fix :)

:+1: thanks :smile:

Well, that part has been fixed but I've found a new problem. Ternary if statements are still a problem.

Both issues are fixed now :)


Sticky.destroy

Hi there,
I'm trying to work out how to use the functions for Sticky plugin in F6... I have a menu that has data options set to make it sticky, however I need to "destroy" that functionality when a certain breakpoint is reached (because I cannot seem to find a way of setting stickyOn: small-only! Not small up).
I've tried daft things like instantiating a new Foundation.Sticky(jQuery('.element').destroy(), any help would be greatly appreciated (or indeed a way of setting a data option to show ONLY on small and not small up!
Cheers

To call plugin methods, do this:
$('#sticky-thing').foundation('destroy');

If it's a method with parameters, you can add them as extra parameters on the .foundation() function.


Inconsistent performance between Chrome and Node

The following seems more like an issue with the platform than with the library, but before opening an issue somewhere else it might be worth to double-check with you.
Running the following code:
const XXH = require ( 'xxhash-wasm' );
(async () => {
  const {h64, h64ToString} = await XXH ();
  console.time('xxhash.bigint');
  for ( let i = 0, l = 10000000; i < l; i++ ) {
    h64 ( 'something' );
  }
  console.timeEnd('xxhash.bigint');
  console.time('xxhash.string');
  for ( let i = 0, l = 10000000; i < l; i++ ) {
    h64ToString ( 'something' );
  }
  console.timeEnd('xxhash.string');
})()

Produces an output like the following on Node@16 on my machine:
xxhash.bigint: 1.639s
xxhash.string: 2.038s

But on Chrome latest I get something like the following:
xxhash.bigint: 4224.4541015625 ms
xxhash.string: 4640.7080078125 ms

Basically it's 2~3x slower. It's weird because both platforms should be using V8 under the hood, and if anything Chrome should be using a more up-to-date version of that.

FWIW this is the actual code I'm executing in Chrome, it's the same as what I posted but bundled with esbuild:
(() => {
  var __getOwnPropNames = Object.getOwnPropertyNames;
  var __commonJS = (cb, mod) => function __require() {
    return mod || (0, cb[__getOwnPropNames(cb)[0]])((mod = { exports: {} }).exports, mod), mod.exports;
  };

  // node_modules/xxhash-wasm/cjs/xxhash-wasm.cjs
  var require_xxhash_wasm = __commonJS({
    "node_modules/xxhash-wasm/cjs/xxhash-wasm.cjs"(exports, module) {
      "use strict";
      var t = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 48, 8, 96, 3, 127, 127, 127, 0, 96, 3, 127, 127, 127, 1, 127, 96, 2, 127, 127, 0, 96, 2, 127, 126, 0, 96, 1, 127, 1, 127, 96, 1, 127, 1, 126, 96, 3, 127, 127, 126, 1, 126, 96, 3, 126, 127, 127, 1, 126, 3, 11, 10, 1, 1, 2, 0, 4, 6, 7, 3, 0, 5, 5, 3, 1, 0, 1, 7, 85, 9, 3, 109, 101, 109, 2, 0, 5, 120, 120, 104, 51, 50, 0, 0, 6, 105, 110, 105, 116, 51, 50, 0, 2, 8, 117, 112, 100, 97, 116, 101, 51, 50, 0, 3, 8, 100, 105, 103, 101, 115, 116, 51, 50, 0, 4, 5, 120, 120, 104, 54, 52, 0, 5, 6, 105, 110, 105, 116, 54, 52, 0, 7, 8, 117, 112, 100, 97, 116, 101, 54, 52, 0, 8, 8, 100, 105, 103, 101, 115, 116, 54, 52, 0, 9, 10, 211, 23, 10, 242, 1, 1, 4, 127, 32, 0, 32, 1, 106, 33, 3, 32, 1, 65, 16, 79, 4, 127, 32, 3, 65, 16, 107, 33, 6, 32, 2, 65, 168, 136, 141, 161, 2, 106, 33, 3, 32, 2, 65, 247, 148, 175, 175, 120, 106, 33, 4, 32, 2, 65, 177, 243, 221, 241, 121, 107, 33, 5, 3, 64, 32, 0, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 3, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 3, 32, 0, 65, 4, 106, 34, 0, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 4, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 0, 65, 4, 106, 34, 0, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 2, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 2, 32, 0, 65, 4, 106, 34, 0, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 5, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 5, 32, 0, 65, 4, 106, 34, 0, 32, 6, 77, 13, 0, 11, 32, 2, 65, 12, 119, 32, 5, 65, 18, 119, 106, 32, 4, 65, 7, 119, 106, 32, 3, 65, 1, 119, 106, 5, 32, 2, 65, 177, 207, 217, 178, 1, 106, 11, 32, 1, 106, 32, 0, 32, 1, 65, 15, 113, 16, 1, 11, 146, 1, 0, 32, 1, 32, 2, 106, 33, 2, 3, 64, 32, 1, 65, 4, 106, 32, 2, 75, 69, 4, 64, 32, 1, 40, 2, 0, 65, 189, 220, 202, 149, 124, 108, 32, 0, 106, 65, 17, 119, 65, 175, 214, 211, 190, 2, 108, 33, 0, 32, 1, 65, 4, 106, 33, 1, 12, 1, 11, 11, 3, 64, 32, 1, 32, 2, 79, 69, 4, 64, 32, 1, 45, 0, 0, 65, 177, 207, 217, 178, 1, 108, 32, 0, 106, 65, 11, 119, 65, 177, 243, 221, 241, 121, 108, 33, 0, 32, 1, 65, 1, 106, 33, 1, 12, 1, 11, 11, 32, 0, 65, 15, 118, 32, 0, 115, 65, 247, 148, 175, 175, 120, 108, 34, 0, 32, 0, 65, 13, 118, 115, 65, 189, 220, 202, 149, 124, 108, 34, 0, 32, 0, 65, 16, 118, 115, 11, 63, 0, 32, 0, 65, 8, 106, 32, 1, 65, 168, 136, 141, 161, 2, 106, 54, 2, 0, 32, 0, 65, 12, 106, 32, 1, 65, 247, 148, 175, 175, 120, 106, 54, 2, 0, 32, 0, 65, 16, 106, 32, 1, 54, 2, 0, 32, 0, 65, 20, 106, 32, 1, 65, 177, 243, 221, 241, 121, 107, 54, 2, 0, 11, 211, 4, 1, 6, 127, 32, 1, 32, 2, 106, 33, 6, 32, 0, 65, 24, 106, 33, 5, 32, 0, 65, 40, 106, 40, 2, 0, 33, 3, 32, 0, 32, 0, 40, 2, 0, 32, 2, 106, 54, 2, 0, 32, 0, 65, 4, 106, 34, 4, 32, 4, 40, 2, 0, 32, 2, 65, 16, 79, 32, 0, 40, 2, 0, 65, 16, 79, 114, 114, 54, 2, 0, 32, 2, 32, 3, 106, 65, 16, 73, 4, 64, 32, 3, 32, 5, 106, 32, 1, 32, 2, 252, 10, 0, 0, 32, 0, 65, 40, 106, 32, 2, 32, 3, 106, 54, 2, 0, 15, 11, 32, 3, 4, 64, 32, 3, 32, 5, 106, 32, 1, 65, 16, 32, 3, 107, 34, 2, 252, 10, 0, 0, 32, 0, 65, 8, 106, 34, 3, 40, 2, 0, 32, 5, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 3, 32, 4, 54, 2, 0, 32, 0, 65, 12, 106, 34, 3, 40, 2, 0, 32, 5, 65, 4, 106, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 3, 32, 4, 54, 2, 0, 32, 0, 65, 16, 106, 34, 3, 40, 2, 0, 32, 5, 65, 8, 106, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 3, 32, 4, 54, 2, 0, 32, 0, 65, 20, 106, 34, 3, 40, 2, 0, 32, 5, 65, 12, 106, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 3, 32, 4, 54, 2, 0, 32, 0, 65, 40, 106, 65, 0, 54, 2, 0, 32, 1, 32, 2, 106, 33, 1, 11, 32, 1, 32, 6, 65, 16, 107, 77, 4, 64, 32, 6, 65, 16, 107, 33, 8, 32, 0, 65, 8, 106, 40, 2, 0, 33, 2, 32, 0, 65, 12, 106, 40, 2, 0, 33, 3, 32, 0, 65, 16, 106, 40, 2, 0, 33, 4, 32, 0, 65, 20, 106, 40, 2, 0, 33, 7, 3, 64, 32, 1, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 2, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 2, 32, 1, 65, 4, 106, 34, 1, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 3, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 3, 32, 1, 65, 4, 106, 34, 1, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 4, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 4, 32, 1, 65, 4, 106, 34, 1, 40, 2, 0, 65, 247, 148, 175, 175, 120, 108, 32, 7, 106, 65, 13, 119, 65, 177, 243, 221, 241, 121, 108, 33, 7, 32, 1, 65, 4, 106, 34, 1, 32, 8, 77, 13, 0, 11, 32, 0, 65, 8, 106, 32, 2, 54, 2, 0, 32, 0, 65, 12, 106, 32, 3, 54, 2, 0, 32, 0, 65, 16, 106, 32, 4, 54, 2, 0, 32, 0, 65, 20, 106, 32, 7, 54, 2, 0, 11, 32, 1, 32, 6, 73, 4, 64, 32, 5, 32, 1, 32, 6, 32, 1, 107, 34, 1, 252, 10, 0, 0, 32, 0, 65, 40, 106, 32, 1, 54, 2, 0, 11, 11, 97, 1, 1, 127, 32, 0, 65, 16, 106, 40, 2, 0, 33, 1, 32, 0, 65, 4, 106, 40, 2, 0, 4, 127, 32, 1, 65, 12, 119, 32, 0, 65, 20, 106, 40, 2, 0, 65, 18, 119, 106, 32, 0, 65, 12, 106, 40, 2, 0, 65, 7, 119, 106, 32, 0, 65, 8, 106, 40, 2, 0, 65, 1, 119, 106, 5, 32, 1, 65, 177, 207, 217, 178, 1, 106, 11, 32, 0, 40, 2, 0, 106, 32, 0, 65, 24, 106, 32, 0, 65, 40, 106, 40, 2, 0, 16, 1, 11, 157, 4, 2, 1, 127, 3, 126, 32, 0, 32, 1, 106, 33, 3, 32, 1, 65, 32, 79, 4, 126, 32, 3, 65, 32, 107, 33, 3, 32, 2, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 124, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 124, 33, 4, 32, 2, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 124, 33, 5, 32, 2, 66, 0, 124, 33, 6, 32, 2, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 125, 33, 2, 3, 64, 32, 0, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 4, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 4, 32, 0, 65, 8, 106, 34, 0, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 5, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 5, 32, 0, 65, 8, 106, 34, 0, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 6, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 0, 65, 8, 106, 34, 0, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 2, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 2, 32, 0, 65, 8, 106, 34, 0, 32, 3, 77, 13, 0, 11, 32, 6, 66, 12, 137, 32, 2, 66, 18, 137, 124, 32, 5, 66, 7, 137, 124, 32, 4, 66, 1, 137, 124, 32, 4, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 5, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 6, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 2, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 5, 32, 2, 66, 197, 207, 217, 178, 241, 229, 186, 234, 39, 124, 11, 32, 1, 173, 124, 32, 0, 32, 1, 65, 31, 113, 16, 6, 11, 137, 2, 0, 32, 1, 32, 2, 106, 33, 2, 3, 64, 32, 1, 65, 8, 106, 32, 2, 77, 4, 64, 32, 1, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 32, 0, 133, 66, 27, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 33, 0, 32, 1, 65, 8, 106, 33, 1, 12, 1, 11, 11, 32, 1, 65, 4, 106, 32, 2, 77, 4, 64, 32, 1, 53, 2, 0, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 32, 0, 133, 66, 23, 137, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 249, 243, 221, 241, 153, 246, 153, 171, 22, 124, 33, 0, 32, 1, 65, 4, 106, 33, 1, 11, 3, 64, 32, 1, 32, 2, 73, 4, 64, 32, 1, 49, 0, 0, 66, 197, 207, 217, 178, 241, 229, 186, 234, 39, 126, 32, 0, 133, 66, 11, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 0, 32, 1, 65, 1, 106, 33, 1, 12, 1, 11, 11, 32, 0, 66, 33, 136, 32, 0, 133, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 34, 0, 32, 0, 66, 29, 136, 133, 66, 249, 243, 221, 241, 153, 246, 153, 171, 22, 126, 34, 0, 32, 0, 66, 32, 136, 133, 11, 88, 0, 32, 0, 65, 8, 106, 32, 1, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 124, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 124, 55, 3, 0, 32, 0, 65, 16, 106, 32, 1, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 124, 55, 3, 0, 32, 0, 65, 24, 106, 32, 1, 55, 3, 0, 32, 0, 65, 32, 106, 32, 1, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 125, 55, 3, 0, 11, 132, 5, 2, 3, 127, 4, 126, 32, 1, 32, 2, 106, 33, 5, 32, 0, 65, 40, 106, 33, 4, 32, 0, 65, 200, 0, 106, 40, 2, 0, 33, 3, 32, 0, 32, 0, 41, 3, 0, 32, 2, 173, 124, 55, 3, 0, 32, 2, 32, 3, 106, 65, 32, 73, 4, 64, 32, 3, 32, 4, 106, 32, 1, 32, 2, 252, 10, 0, 0, 32, 0, 65, 200, 0, 106, 32, 2, 32, 3, 106, 54, 2, 0, 15, 11, 32, 3, 4, 64, 32, 3, 32, 4, 106, 32, 1, 65, 32, 32, 3, 107, 34, 2, 252, 10, 0, 0, 32, 0, 65, 8, 106, 34, 3, 41, 3, 0, 32, 4, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 3, 32, 6, 55, 3, 0, 32, 0, 65, 16, 106, 34, 3, 41, 3, 0, 32, 4, 65, 8, 106, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 3, 32, 6, 55, 3, 0, 32, 0, 65, 24, 106, 34, 3, 41, 3, 0, 32, 4, 65, 16, 106, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 3, 32, 6, 55, 3, 0, 32, 0, 65, 32, 106, 34, 3, 41, 3, 0, 32, 4, 65, 24, 106, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 3, 32, 6, 55, 3, 0, 32, 0, 65, 200, 0, 106, 65, 0, 54, 2, 0, 32, 1, 32, 2, 106, 33, 1, 11, 32, 1, 65, 32, 106, 32, 5, 77, 4, 64, 32, 5, 65, 32, 107, 33, 2, 32, 0, 65, 8, 106, 41, 3, 0, 33, 6, 32, 0, 65, 16, 106, 41, 3, 0, 33, 7, 32, 0, 65, 24, 106, 41, 3, 0, 33, 8, 32, 0, 65, 32, 106, 41, 3, 0, 33, 9, 3, 64, 32, 1, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 6, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 6, 32, 1, 65, 8, 106, 34, 1, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 7, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 7, 32, 1, 65, 8, 106, 34, 1, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 8, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 8, 32, 1, 65, 8, 106, 34, 1, 41, 3, 0, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 32, 9, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 33, 9, 32, 1, 65, 8, 106, 34, 1, 32, 2, 77, 13, 0, 11, 32, 0, 65, 8, 106, 32, 6, 55, 3, 0, 32, 0, 65, 16, 106, 32, 7, 55, 3, 0, 32, 0, 65, 24, 106, 32, 8, 55, 3, 0, 32, 0, 65, 32, 106, 32, 9, 55, 3, 0, 11, 32, 1, 32, 5, 73, 4, 64, 32, 4, 32, 1, 32, 5, 32, 1, 107, 34, 1, 252, 10, 0, 0, 32, 0, 65, 200, 0, 106, 32, 1, 54, 2, 0, 11, 11, 200, 2, 1, 5, 126, 32, 0, 65, 24, 106, 41, 3, 0, 33, 1, 32, 0, 41, 3, 0, 34, 2, 66, 32, 90, 4, 126, 32, 0, 65, 8, 106, 41, 3, 0, 34, 3, 66, 1, 137, 32, 0, 65, 16, 106, 41, 3, 0, 34, 4, 66, 7, 137, 124, 32, 1, 66, 12, 137, 32, 0, 65, 32, 106, 41, 3, 0, 34, 5, 66, 18, 137, 124, 124, 32, 3, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 4, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 1, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 32, 5, 66, 207, 214, 211, 190, 210, 199, 171, 217, 66, 126, 66, 0, 124, 66, 31, 137, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 133, 66, 135, 149, 175, 175, 152, 182, 222, 155, 158, 127, 126, 66, 227, 220, 202, 149, 252, 206, 242, 245, 133, 127, 124, 5, 32, 1, 66, 197, 207, 217, 178, 241, 229, 186, 234, 39, 124, 11, 32, 2, 124, 32, 0, 65, 40, 106, 32, 2, 66, 31, 131, 167, 16, 6, 11]);
      module.exports = async function() {
        const { instance: { exports: { mem: e, xxh32: n, xxh64: r, init32: i, update32: o, digest32: s, init64: u, update64: h, digest64: g } } } = await WebAssembly.instantiate(t);
        let c = new Uint8Array(e.buffer);
        function a(t2, n2) {
          if (e.buffer.byteLength < t2 + n2) {
            const r2 = Math.ceil((t2 + n2 - e.buffer.byteLength) / 65536);
            e.grow(r2), c = new Uint8Array(e.buffer);
          }
        }
        function l(t2, e2, n2, r2, i2, o2) {
          a(t2);
          const s2 = new Uint8Array(t2);
          return c.set(s2), n2(0, e2), s2.set(c.slice(0, t2)), { update(e3) {
            let n3;
            return c.set(s2), typeof e3 == "string" ? (a(3 * e3.length, t2), n3 = b.encodeInto(e3, c.subarray(t2)).written) : (a(e3.byteLength, t2), c.set(e3, t2), n3 = e3.byteLength), r2(0, t2, n3), s2.set(c.slice(0, t2)), this;
          }, digest: () => (c.set(s2), o2(i2(0))) };
        }
        function d(t2) {
          return t2 >>> 0;
        }
        const f = 2n ** 64n - 1n;
        function y(t2) {
          return t2 & f;
        }
        const b = new TextEncoder(), w = 0n;
        function p(t2) {
          let e2 = arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : 0;
          return a(3 * t2.length, 0), d(n(0, b.encodeInto(t2, c).written, e2));
        }
        function v(t2) {
          let e2 = arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : w;
          return a(3 * t2.length, 0), y(r(0, b.encodeInto(t2, c).written, e2));
        }
        return { h32: p, h32ToString(t2) {
          return p(t2, arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : 0).toString(16).padStart(8, "0");
        }, h32Raw(t2) {
          let e2 = arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : 0;
          return a(t2.byteLength, 0), c.set(t2), d(n(0, t2.byteLength, e2));
        }, create32() {
          return l(48, arguments.length > 0 && arguments[0] !== void 0 ? arguments[0] : 0, i, o, s, d);
        }, h64: v, h64ToString(t2) {
          return v(t2, arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : w).toString(16).padStart(16, "0");
        }, h64Raw(t2) {
          let e2 = arguments.length > 1 && arguments[1] !== void 0 ? arguments[1] : w;
          return a(t2.byteLength, 0), c.set(t2), y(r(0, t2.byteLength, e2));
        }, create64() {
          return l(88, arguments.length > 0 && arguments[0] !== void 0 ? arguments[0] : w, u, h, g, y);
        } };
      };
    }
  });

  // asd.js
  var XXH = require_xxhash_wasm();
  (async () => {
    const { h64, h64ToString } = await XXH();
    console.time("xxhash.bigint");
    for (let i = 0, l = 1e7; i < l; i++) {
      h64("something");
    }
    console.timeEnd("xxhash.bigint");
    console.time("xxhash.string");
    for (let i = 0, l = 1e7; i < l; i++) {
      h64ToString("something");
    }
    console.timeEnd("xxhash.string");
  })();
})();

I just checked what happens when running the bundled code under Node too, and I'm getting the ~same numbers there, so the problem is not the bundler.

I can confirm this, Node seems to be significantly faster than Chrome and Firefox (didn't test Safari, as I'm on Linux).
The timings have been run in incognito mode and have been observed consistently and many times.
Timings in ms.

Hash Function
Node 17.4.0
Chrome 97.0.4692.99 (stable)
Chrome 99.0.4840.0 (unstable)
Firefox

h32
257.802
1781.716
2504.363
1784.000

h32Raw
152.300
833.997
942.290
1243.000

h64
265.812
1553.274
2273.483
1284.000

h64Raw
153.056
532.352
730.155
731.000

Chrome stable (97) is a lot slower, and to make matters worse, the current unstable version of Chrome (99), got even slower (although I wouldn't count it on being representative what will be shipped in the respective stable version).
Also no clue why Firefox is so much worse on the Raw hashing in comparison to the regular ones.
I've used larger strings to really push the WASM execution, but fewer iterations (see below for the code) and the discrepancy is even larger, being up to 10x slower on my machine.
I ran the profilers and just saw that the WASM part is indeed the only part that takes longer, and to verify that I also tried the Raw versions, to eliminated any doubts that TextEncoder.encodeInto could make any difference. Similarly, it is not related to BigInt, as h32 is even slower.
It is really just the WASM runtime and I quite frankly have no idea why that is the case. And I've also checked that it's not the compilation or GC, as each individual run is consistently slower.
Pretty much my only guess would be, that the browsers are limited in the resources that they are allowed to use or maybe some excessive context switching, since browsers need to do more than just run the JavaScript.
I've used the following code for these timings (both directly using the ES Module without any bundlers):

Node snippet
import xxhash from "xxhash-wasm";

const NUM_RUNS = 1e6;

async function main() {
  const hasher = await xxhash();
  const input = "something".repeat(100);
  const encoded = new TextEncoder().encode(input);

  console.time("h32");
  for (let i = 0; i < NUM_RUNS; i++) {
    hasher.h32(input);
  }
  console.timeEnd("h32");

  console.time("h32Raw");
  for (let i = 0; i < NUM_RUNS; i++) {
    hasher.h32Raw(encoded);
  }
  console.timeEnd("h32Raw");

  console.time("h64");
  for (let i = 0; i < NUM_RUNS; i++) {
    hasher.h64(input);
  }
  console.timeEnd("h64");

  console.time("h64Raw");
  for (let i = 0; i < NUM_RUNS; i++) {
    hasher.h64Raw(encoded);
  }
  console.timeEnd("h64Raw");
}

main();

Browser snippet
<html>
  <head>
    <script type="module">
      import xxhash from "https://unpkg.com/xxhash-wasm/esm/xxhash-wasm.js";

      const NUM_RUNS = 1e6;

      async function main() {
        const hasher = await xxhash();
        const input = "something".repeat(100);
        const encoded = new TextEncoder().encode(input);

        console.time("h32");
        for (let i = 0; i < NUM_RUNS; i++) {
          hasher.h32(input);
        }
        console.timeEnd("h32");

        console.time("h32Raw");
        for (let i = 0; i < NUM_RUNS; i++) {
          hasher.h32Raw(encoded);
        }
        console.timeEnd("h32Raw");

        console.time("h64");
        for (let i = 0; i < NUM_RUNS; i++) {
          hasher.h64(input);
        }
        console.timeEnd("h64");

        console.time("h64Raw");
        for (let i = 0; i < NUM_RUNS; i++) {
          hasher.h64Raw(encoded);
        }
        console.timeEnd("h64Raw");
      }

      main();
    </script>
  </head>
</html>


homebridge-hue mqtt

Hi
I am trying to set up my smart home via Raspberry Pi and homebridge.
I already did temperature and humidity sensor.
But now i bought Philips Hue light and I would like to connect to my home.
I change my config.json
{
        "bridge": {
                "name": "Homebridge",
                "username": "CC:22:3D:E3:CE:30",
                "port": 51826,
                "pin": "031-45-154"
        },
        "description": "Nastavenie Homebridge pre domacu siet..",

        "platforms": [{

                "platform": "mqtt",
                "name": "mqtt",
                "url": "mqtt://<IP_ADDRESS>",
                "topic_prefix": "homebridge"
      },
{
      "platform": "Hue",
        "users": {
        "001788FFFExxxxxx": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "001788FFFEyyyyyy": "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
      },      "lights": true
    }
]
}

I am using mqtt for sending data via module. Can you help me how can i add philips hue to the system?
When I turn on homebridge it give me this error
[2018-3-30 14:54:01] Loaded plugin: homebridge-hue
[2018-3-30 14:54:01] Registering platform 'homebridge-hue.Hue
[2018-3-30 14:54:01] ---
[2018-3-30 14:54:02] Loaded plugin: homebridge-mqtt
homebridge API version: 2.2
[2018-3-30 14:54:02] Registering platform 'homebridge-mqtt.mqtt
[2018-3-30 14:54:02] ---
[2018-3-30 14:54:02] Loaded config.json with 0 accessories and 2 platforms.
[2018-3-30 14:54:02] ---
[2018-3-30 14:54:02] Loading 2 platforms...
[2018-3-30 14:54:02] [mqtt] Initializing mqtt platform...
[2018-3-30 14:54:02] [mqtt] homebridge-mqtt v0.4.7
[2018-3-30 14:54:02] [Hue] Initializing Hue platform...
[2018-3-30 14:54:03] [Hue] homebridge-hue v0.8.8, node v8.11.1, homebridge v0.4.38
[2018-3-30 14:54:03] [Hue] warning: not using recommended node version v8.10.0 LTS
[2018-3-30 14:54:03] [mqtt] Number of cached Accessories: 3
[2018-3-30 14:54:03] [mqtt] clientId = homebridge-mqtt_81773c26
[2018-3-30 14:54:03] [mqtt] Connecting..
[2018-3-30 14:54:03] [mqtt] connected (url = mqtt://<IP_ADDRESS>)
[2018-3-30 14:54:05] [Hue] dresden appspot ipv6: communication error ENETUNREACH on https://dresden-light.appspot.com/
[2018-3-30 14:54:11] [Hue] 192.***.***.100: bridge request 1: get /config
[2018-3-30 14:54:11] [Hue] 192.***.***.100: bridge communication error EHOSTUNREACH on 192.***.***.100
[2018-3-30 14:54:13] [Hue] 192.***.***.101: bridge request 1: get /config
[2018-3-30 14:54:13] [Hue] 192.***.***.101: bridge communication error EHOSTUNREACH on 192.***.***.101

Hi, firstly thanks for your answer
Here is information from homebridge.log
`-- Logs begin at Mon 2018-04-02 19:30:48 UTC, end at Mon 2018-04-02 19:35:28 UTC. --
Apr 02 19:30:50 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:30:50 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:30:50 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:30:50 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:00 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:00 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:00 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:00 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:00 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:00 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:11 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:11 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:11 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:11 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:11 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:11 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:29 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:29 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:29 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:29 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:29 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:29 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:39 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:39 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:39 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:39 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:39 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:39 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:49 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:49 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:49 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:49 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:49 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:49 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:31:59 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.
Apr 02 19:31:59 raspberrypi systemd[1]: Stopped Node.js HomeKit Server.
Apr 02 19:31:59 raspberrypi systemd[1]: Started Node.js HomeKit Server.
Apr 02 19:31:59 raspberrypi systemd[1]: homebridge.service: Main process exited, code=exited, status=203/EXEC
Apr 02 19:31:59 raspberrypi systemd[1]: homebridge.service: Unit entered failed state.
Apr 02 19:31:59 raspberrypi systemd[1]: homebridge.service: Failed with result 'exit-code'.
Apr 02 19:32:09 raspberrypi systemd[1]: homebridge.service: Service hold-off time over, scheduling restart.

When I usedhomebridge -D 2>&1 | tee homebridge.log ` it gave me this log
root@raspberrypi:~/.homebridge# homebridge -D 2>&1 | tee homebridge.log
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=node&f=DNSServiceRegister>
[2018-4-2 19:38:02] Loaded plugin: homebridge-hue
[2018-4-2 19:38:02] Registering platform 'homebridge-hue.Hue'
[2018-4-2 19:38:02] ---
[2018-4-2 19:38:03] Loaded plugin: homebridge-mqtt
homebridge API version: 2.2
[2018-4-2 19:38:03] Registering platform 'homebridge-mqtt.mqtt'
[2018-4-2 19:38:03] ---
[2018-4-2 19:38:03] Loaded config.json with 0 accessories and 2 platforms.
[2018-4-2 19:38:03] ---
[2018-4-2 19:38:03] Loading 2 platforms...
[2018-4-2 19:38:03] [mqtt] Initializing mqtt platform...
[2018-4-2 19:38:03] [mqtt] homebridge-mqtt v0.4.7
[2018-4-2 19:38:03] [mqtt] storagePath = /root/.homebridge
[2018-4-2 19:38:03] [mqtt] config = {"platform":"mqtt","name":"mqtt","url":"mqtt://<IP_ADDRESS>","topic_prefix":"homebridge"}
[2018-4-2 19:38:03] [Hue] Initializing Hue platform...
[2018-4-2 19:38:03] [Hue] homebridge-hue v0.8.8, node v8.11.1, homebridge v0.4.38
[2018-4-2 19:38:03] [Hue] warning: not using recommended node version v8.10.0 LTS
[2018-4-2 19:38:03] [Hue] npm registry: get /homebridge-hue
[2018-4-2 19:38:03] [mqtt] Accessory.configureAccessory 'Teplota' 'Teplota'
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics Teplota Teplota Name Teplota
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics Teplota Teplota CurrentTemperature 21
[2018-4-2 19:38:03] [mqtt] Accessory.configureAccessory 'Vlhkost' 'Vlhkost'
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics Vlhkost Vlhkost Name Vlhkost
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics Vlhkost Vlhkost CurrentRelativeHumidity 62
[2018-4-2 19:38:03] [mqtt] Accessory.configureAccessory 'living_lamp' 'light'
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics living_lamp light Name light
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics living_lamp light On false
[2018-4-2 19:38:03] [mqtt] Accessory.configureCharacteristics living_lamp light Brightness 100
[2018-4-2 19:38:03] [mqtt] Number of cached Accessories: 3
[2018-4-2 19:38:03] [mqtt] Controller.start
[2018-4-2 19:38:03] [mqtt] clientId = homebridge-mqtt_7adbcd49
[2018-4-2 19:38:03] [mqtt] Connecting..
[2018-4-2 19:38:04] [mqtt] connected (url = mqtt://<IP_ADDRESS>)
[2018-4-2 19:38:04] [mqtt] on.connect subscribe homebridge/to/#
[2018-4-2 19:38:04] [mqtt] on.connect homebridge-mqtt v0.4.7 started
[2018-4-2 19:38:05] [Hue] npm registry: get /homebridge-hue ok
[2018-4-2 19:38:05] [Hue] warning: lastest version: homebridge-hue v0.8.9
[2018-4-2 19:38:05] [Hue] config.json: {"platform":"Hue","users":{"001788FFFExxxxxx":"***************************************1","001788FFFEyyyyyy":"***************************************2"},"lights":true}
[2018-4-2 19:38:05] [Hue] meethue portal: get /api/nupnp
[2018-4-2 19:38:05] [Hue] dresden appspot ipv4: get /discover
[2018-4-2 19:38:05] [Hue] dresden appspot ipv6: get /discover
[2018-4-2 19:38:05] [Hue] upnp search: searching at <IP_ADDRESS>:1900 for 5 seconds
[2018-4-2 19:38:05] [Hue] dresden appspot ipv6: communication error ENETUNREACH on https://dresden-light.appspot.com/
[2018-4-2 19:38:05] [Hue] meethue portal: get /api/nupnp ok
[2018-4-2 19:38:05] [Hue] meethue portal: found bridge 001788FFFE15D538 at 192.***.***.101
[2018-4-2 19:38:05] [Hue] meethue portal: found bridge 001788FFFE4F79BE at 192.***.***.101
[2018-4-2 19:38:05] [Hue] meethue portal: found bridge 001788FFFE78A377 at 192.***.***.100
[2018-4-2 19:38:05] [Hue] meethue portal: found bridge 001788FFFE4B5345 at 192.***.***.102
[2018-4-2 19:38:05] [Hue] dresden appspot ipv4: get /discover ok
[2018-4-2 19:38:10] [Hue] upnp search: done
[2018-4-2 19:38:10] [Hue] 192.***.***.101: bridge request 1: get /config
[2018-4-2 19:38:10] [Hue] 192.***.***.101: bridge request 1: get /config
[2018-4-2 19:38:10] [Hue] 192.***.***.100: bridge request 1: get /config
[2018-4-2 19:38:10] [Hue] 192.***.***.102: bridge request 1: get /config
[2018-4-2 19:38:13] [Hue] 192.***.***.100: bridge request 1: get /config
[2018-4-2 19:38:13] [Hue] 192.***.***.100: bridge communication error EHOSTUNREACH on 192.***.***.100
[2018-4-2 19:38:13] [Hue] 192.***.***.101: bridge request 1: get /config
[2018-4-2 19:38:13] [Hue] 192.***.***.101: bridge communication error EHOSTUNREACH on 192.***.***.101
[2018-4-2 19:38:13] [Hue] 192.***.***.101: bridge request 1: get /config
[2018-4-2 19:38:13] [Hue] 192.***.***.101: bridge communication error EHOSTUNREACH on 192.***.***.101
[2018-4-2 19:38:15] [Hue] 192.***.***.102: bridge request 1: get /config
[2018-4-2 19:38:15] [Hue] 192.***.***.102: bridge communication error ETIMEDOUT on 192.***.***.102
```
`
If you have any tips how to solve this problem I will be so happy !
Thank you for answer :)

The meethue portal reports that you have four different Hue bridges?!  What kind of Internet connection do you have?  Are you sharing a public IP address?
Best configure the IP address of your bridge in config.json to disable discovery, see https://github.com/ebaauw/homebridge-hue/wiki/Configuration.

The meethue portal reports that you have four different Hue bridges?! What kind of Internet connection do you have? Are you sharing a public IP address?
Best configure the IP address of your bridge in config.json to disable discovery, see https://github.com/ebaauw/homebridge-hue/wiki/Configuration.

Thank you I solve the problem and now it is working perfectly :)
I have another question, is it possible to connect Xiamo door sensor, I bought this one https://www.ebay.com/itm/Xiaomi-Mijia-Smart-Door-and-Windows-Sensor-Multi-Functional-Home-Security-Guard/312032695109?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
Is there any way how to properly connect to my home ?
Thanks

I dont know exactly what IP adress I should use it

The IP address of your Hue bridge.

My another question, users should be the same like in your tutorial ? Or what users should be there ?

No, these are just examples.  When you run homebridge-hue for the first time, it will ask you in the homebridge output/log to press the button on the bridge, so it can create a username.  It will than log what bridgeid and username you need to put in config.json.

I have another question, is it possible to connect Xiamo door sensor

homebridge-hue supports this sensor, but the Hue bridge doesn’t.  You’ll need deCONZ.
Alternatively, you could try the Mi gateway and one of the Mi homebridge plugins, but I have no experience with these.  Also, you’ll need HomeKit automations instead of gateway rules to control your lights automatically.  I find these are slower and less reliable than gateway rules.

this RaspBee

That's the one.  It's also available at amazon.de (for the same price, note the VAT).

Then I can use all of these accessories as you describe

Yes (except the Hue bridge link button).

After I will connect RaspBee, it will be my smart home bridge ?

Yes, it can fully replace the Hue bridge, except for upgrading the firmware of Hue devices and for the Hue entertainment stuff.  Also, there's some subtle differences between the Hue and deCONZ APIs, so Hue apps might not work.

do I need something else for that

Obviously a Raspberry Pi to install it to.  I'm using a 3 B on RaspBian Stretch, running both deCONZ and homebridge on the same Raspberry.

I am using IPv4 connection and my internet is getting IP automatically

I think your ISP provides you with a shared IPv4 address, see #326.


Problem counting the vehicles (Wrong direction is counted up)

Hello together,
I'm running Opendatacam and Yolov4 on Jetson AGX Xavier with this configuration "config.json" (.json renamed to .txt).
I have currently this problem:
In this video I have two counting lines that have different direction. In some scenes the car was also counted additional in the wrong driving direction. I could not figured out, what kind of error can this be.
https://user-images.githubusercontent.com/93678091/143570487-fa314b80-1910-4b52-adf3-b22ed01ddbd3.mp4
https://user-images.githubusercontent.com/93678091/143570896-94e4c51d-d413-4e6e-97bc-474953090e16.mp4

My guess is, that if you evaluate the tracker data you will find that the center of the bounding box will be moving backwards because of inaccuracies in the detection of the object (notice how the bounding box is jumping even when the car is not moving?)
Currently there is no way to define a "minimum travel distance" or "hysteresis" to prevent this.
However have you tried to set up one bidirectional counting line instead of two? As it gives you the direction of the vehicle in the JSON/CSV file you should be able to collect the same data but possibly without the errors.

My guess is, that if you evaluate the tracker data you will find that the center of the bounding box will be moving backwards because of inaccuracies in the detection of the object (notice how the bounding box is jumping even when the car is not moving?)
Currently there is no way to define a "minimum travel distance" or "hysteresis" to prevent this.
However have you tried to set up one bidirectional counting line, at a location where the vehicles are still moving sufficiently fast, instead of two? As it gives you the direction of the vehicle in the JSON/CSV file you should be able to collect the same data but possibly without the errors.

yeah, ill bet my hat that you right. i faced this when i used the previous coordinate against the current coordinate to check tripline intersection. i store around 20 frames of trajectoryhistory, so my solution was to check first recorded coordinate against the current one instead of using only the previous one. yolo bboxes be jumpy...


run daemon on windows

Hello  documentation only describes run daemon on Linux, How can do it on windows? Thank you

You can just open a new terminal, run and keep open:
php artisan websockets:serve
As long as the terminal is open and running this command, it will serve WebSockets.
For supvervisord-like functionality, a quick google search gives you some answers:
https://superuser.com/questions/331675/supervisord-like-tool-for-windows

I found a reliable solution:
https://hazaveh.net/2018/01/run-and-monitor-laravel-queue-using-pm2/


feat(plugin-react): export types

removed an unused import
exports that will make it easier for strict TS users to initialize BugSnag asserting it won't be undefined

related to #868

Many thanks for the PR @dacevedo12, I have passed to our dev team for review and, if approved, merge.

Thanks @dacevedo12, this looks good. I need to re-raise it so it will run on our private ci infrastructure. See #1009.

We have released an update for this in v7.3.3.

Thank you!


ffmpeg-for-homebridge is not being utilized

When debugging why I could not use the proper audio codec provided by ffmpeg-for-homebridge found that it was using the OS installed version.

As this will change everyone to use the ffmpeg for homebridge version of ffmpeg as a default going forward, going to create change log to include with the pull request.  If end users wish to use a different version they can include it in the config.json

@KhaosT anyway we can get this published to npm?


Hovered ListBoxItem show weird behaviour

Describe the bug
When creating DataTemplate ListBox Item with binding, weird things happened with the hover state.
it shows default data binding
To Reproduce
Steps to reproduce the behavior:

Create ListBox, with GeneratedItemTemplate
Bind to some data.
run, when clicked, it shows default binding.

Expected behavior
it supposed to show nothing but the content.

Screenshots

I think the problem is with the ripple effect.

Thank you for reporting this.
A few questions:

What do you mean with 'GeneratedItemTemplate'? There is no such property as far as I know. Do you simply mean 'ItemTemplate' or is there anything special to it?
Did you enable the ripple effect on the list box? It is supported by the template but not visible by default.
Did you set some kind of Content or CotnentTemplate properties in your ItemTemplate?

It might be worth posting your xaml here so I can better see what exactly lead to this result.
In the meantime you can try the following to fix it temporarily:

Take AdonisUI's default ListBoxItem style from AdonisUI.ClassicTheme/DefaultStyles/ListBox.xaml

Copy it into your App.xaml resources right after the lines that include AdonisUI. You can also put it into a separate ResourceDictionary file and include it there. Give it a new key like ListBoxItemWithoutRippleStyle.

Remove the RippleHost control and associated triggers from the style's control template.

Create a new default ListBox style and assign the ListBoxItem style to it, e.g. like:

<Style TargetType="ListBox"
       BasedOn="{StaticResource {x:Type ListBox}">
    <Setter Property="ItemContainerStyle" Value="{StaticResource ListBoxItemWithoutRippleStyle}"/>
</Style>

Put that style in the same location as you chose for your ListBoxItem style.

In case it is really a problem with the ripple effect, it should be gone now. Currently I am not able to test this approach myself, so I apologize in case this does not work.

What do you mean with 'GeneratedItemTemplate'? There is no such property as far as I know. Do you simply mean 'ItemTemplate' or is there anything special to it?

Yes, I mean ItemTemplate, it just generated by adding data template

Did you enable the ripple effect on the list box? It is supported by the template but not visible by default.

I didn't enable it. I don't even know where the switch code.
Did you set some kind of Content or ContentTemplate properties in your ItemTemplate?
No, it just data template with binding.
Anyway, the solution works well for me,  thank you so much.

Juts wanted to chime in that this removal of ripple effect also fixed an issue I was having where I had a listbox that had a stackpanel in it with a checkbox, an image, and some text. The check would appear and then fade out when being checked and would blank almost immediately when being unchecked.

Hey @Mgamerz, thanks for reporting this.
I was able to reproduce the behavior you described. I will see if I can find a reason for this and hope to develop a fix as well.

So, I think i was able to fix it. At least it works perfectly in my test scenario now. As I could not reproduce @rasyidf's setup I cannot be entirely sure if it solves his issues as well. But from looking at the description and image he provided I am very optimistic that it should be fixed now as well.
Additionally, I have removed the ripple host from the default ListBoxItem style as it is not required for most use cases. This should also improve performance a little on ListBoxes with many items. In case someone needs a ListBox where each item feels more like a button that executes some action on click, there is now a separate RippleListBoxItem style which can be used. This felt like a cleaner solution to me.

PS: Explanation
Just in case someone is interested what lead to the CheckBoxes fading out, I will try to explain it here.
First, a little background knowledge: When using the light theme, text is black. This does not look good on the blue accent color though where white text is more appropriate. So, when a ripple starts it has to transition the foreground color from black into white. In order to get the perfect transition here, the color switches exactly at the edge of the ripple ellipse. To make this possible the ripple host duplicates the actual content but with its duplicated version having white foreground. The ripple ellipse is actually an opacity mask which blends the duplicated content and the blue background over the existing content. This works as long as the duplicated content is an exact copy only with different colors. All this is also documented here.
Now about the actual issue: Somehow the DataContext was not inherited down the visual tree inside the ripple host's duplicated content. That's why clicking a CheckBox would set it to IsChecked="True" but the ripple started to blend in the duplicated CheckBox which has its own state still being on IsChecked="False". It looked like fading out because this is the only change the ripple does here. The actual elliptical color animation is not visible here because ListBoxItems switch their background to the same accent color instantly when selected.
The current state: The DataContext is now inherited correctly so when the CheckBox is checked now the duplicated one receives the check as well. The problem still remains though when not using bindings. When a child control like a CheckBox inside a control with ripple like a Button changes parts of its state, the duplicated CheckBox can only know about this if there has been a binding to a shared DataContext defined. So that both CheckBoxes' state is bound to the same property in some view model.
This might be a limitation which needs to be solved in the future but it was sufficient for all previous cases so far. I expect it to be a relatively rare scenario to have an interactive element like a CheckBox inside a control with a ripple host like a Button which is already interactive as well. One would not put a TabControl inside a MenuItem as well, I guess. But we'll see how long it takes until someone comes up with that ;)


Static property

Apparently the latest version failed to handle static fields in class.
Try to minify sample codes from developer.mozilla.org:
class ClassWithStaticMethod {
  static staticProperty = 'someValue';
  static staticMethod() {
    return 'static method has been called.';
  }
  static {
    console.log('Class static initialization block called');
  }
}

and get the error: "Parse error: Unexpected token: operator (=)"

The issue is that we're stuck on an old version. I'll merge a PR updating to the latest version.

This has been fixed in https://github.com/Skalman/UglifyJS-online/pull/18.


YAML comments support

This adds support for YAML comments.
Let me know if you want to see changes.

Thanks for this contribution! I would love to have full support for reading comments back from configuration files, but I think this could be a decent stopgap until that work is complete.

I wasn't aware that comments are also supposed to be read back.
After quite a bit of digging I've added support for that in the latest commit.
I might change the way the comments are read back for map keys a bit, but the general concept is there.

Hi, can this be merged?

Any update on this?

no

Sorry, should've asked differently: "What's stopping this from getting merged?"

time

Does this have any merge conflicts? If not, what needs to be done in order for this to be merged?


Unimplemented: nested pattern-match on integer values

Error:
   Generating project's blueprint (~/Desktop/.../plutus.json)
Error:
  × Main thread panicked.
  ├─▶ at src/gen_uplc.rs:2712:36
  ╰─▶ not yet implemented
  help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.

Minimal example:
  expect (1, _) =
    (1, 2)
  True
}

Reporting as bug as the keyword either should work as expected, or throw a legible error.

Using expect to assert on the value of an Integer (or ByteArray) is not supported and will unlikely be in the near future.
Instead, we ought to provide a better error during code generation or, to forbid this entirely during type-check.

duplicate of #631


add recurrence rule constraints

This PR adds RecurrenceRuleConstraint functionality. RecurrenceRuleSetConstraints, RecurrenceRuleRangeConstrains and RecurrenceRuleStepConstraints constrain the value of a RecurrenceRule.Timeunit (.ie year, month, hour, etc.). Each has a cron equivalent (i.e set: 5 or 5,9,7, Range: 1-6, step: */2). This PR is reduced/simplified from #19.

Hey @rnantes, you just merged a pull request, have a coin!
You now have 1 coins.


docs(saas): reorganize and rewrite content in preparation for saas

@brian-armory a little confused when I see Armory Admin and Administration -- maybe rename Administration to Spinnaker Administration?

@brian-armory a little confused when I see Armory Admin and Administration -- maybe rename Administration to Spinnaker Administration?

Administration is going away.
We'll have Armory Admin for on-prem admin tasks and Armory Cloud Admin for the SaaS equivalents.
- Overview
- Installation
- Armory Admin
- Armory Cloud Admin
- User Guides
- Release Notes
- Plugins

In my head, these are the top lvl items. Armory (or Armory Platform) is the name for on-prem and Armory Cloud is the name for SaaS.

We'll have Armory Admin for on-prem admin tasks and Armory Cloud Admin for the SaaS equivalents.

What do you think of  'Armory Server Admin' and 'Armory Cloud Admin' ?? Thinking of products like Jira that use 'Server' vs 'Cloud'


Monster Raor A web app that roars

Monster app a Web app that roars
It'a simple mini javascript project

Please Update directory name to MosnterRoad/{USERNAME}.
Thank you.


Job links do not work with nested views

If you use the nested views plugin to organize the monitor views, the links of the jobs are not valid.
Example:
http://abt-tooldev.de.xxx.com:8088/jenkins/view/Monitor Views/view/job/xxx.yyy.zzz.domainmodel/
Correct would be:
http://abt-tooldev.de.xxx.com:8088/jenkins/job/xxx.yyy.zzz.domainmodel/

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/36810683-job-links-do-not-work-with-nested-views?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F580790&utm_medium=issues&utm_source=github).

Hey @mfarnung and thanks for reporting that! I haven't used nested views so that's why the Build Monitor doesn't support them I'm afraid. If you'd like to submit a PR I'd be more than happy to help out with review and merging?
Best,
Jan


Access manager has been derived from Telegram APIs

Access manager has been derived from Telegram APIs in new branch accessmanager-dev. Please help me test it. Thx. @flynnoct
In case of granting users different authority between text, voice and file, the <chat_type> field is currently reserved for future use.

I refactor access manager code.
This should be handled in message manager and we should do that later. Close this issue for now.


V0.12.0.x msghand

Revert some changes https://github.com/dashpay/dash/commit/40149c4e41114499c324abc313aea93a59bfa2f7#diff-9a82240fe7dfe86564178691cc57f2f1R1485 and cherry-pick 351593b9c8687b4da2e86769899b8b61ea44b630
Should help with #535

before
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 89.04    0.003298           1      2476      1235 futex
  9.64    0.000357           0     45249           gettimeofday
  1.16    0.000043           0       480           sendto
  0.16    0.000006           0      1235           clock_gettime
  0.00    0.000000           0        32           write
------ ----------- ----------- --------- --------- ----------------
100.00    0.003704                 49472      1235 total

after
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0        36           write
  0.00    0.000000           0       200           sendto
  0.00    0.000000           0      2451           gettimeofday
  0.00    0.000000           0       243         9 futex
  0.00    0.000000           0         1           restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                  2931         9 total

still smth is broken somewhere but looks much better now imo

Compiling and testing on one of my live masternodes..

OK, now it's running live,
changed the clocksource back to tsc = default.
Everything seems to be fine currently, there are no
futex: (Connection timed out), messages in strace as of now, there are some futex resource unavailable from time to time, and futex ..... = 0. but we will see.
looking realtime graph and
CPU usage went from ~20% to ~5%.
Still monitoring memory if it's starts to do the chainsaw or is it stable for now...
Network packets also went down from 3500 to around 2000.

Current graphs, we will see in day or two what happens..

Here's a week graph, you can see the CPU usage is good, even it's sawing a little, memory is all over the place, same as disk usage is increasing and is sawing These has to do something with the masternode count?
going to compile the latest release and try that.

Newest 0.46 release, looking very good. Memory usage back down to normal no sawing and cpu-usage too, going to update the rest of the masternodes.
![5cpu-usage](https://cloud.githubusercontent.com/assets/7759283/9348776/74b8cf5a-4644-11e5-
9bb9-010ffa6582e5.png)

@minersday thank you for extended testing and report! :+1:

@minersday many thanks for your testing from me, too!

NP =)

Here's latest graphs for you please (daily range), you can clearly see at the end when updated to .46.

I can confirm this, i have updated some nodes and the load reduces significantly (at least after startup)


Unzipping Zip64 files while streaming fails with UnexpectedHeaderError

This library is used in the python packing too, uv, for unzipping Python package Wheels (zip files) for dependencies, among other things.
I recently had an issue with one such dependency - fontawesomepro, which provides its Wheel files at a private repository based on subscribers' API key (e.g.: https://dl.fontawesome.com/MYTOKENHERE/fontawesome-pro/python/simple/). At first I thought the issue might be with the repo or the files themselves, but it looks like it's an issue with unzipping.
I opened up an Issue on the uv repo, but it was recommended that I do the same here since you will probably be able to identify if I diagnosed this correctly, and if so, help with resolution.
I provided a lot of detail in that Issue, and will copy over portions of my comments from that Issue with the details that are probably most important:

It looks like uv first started unzipping while streaming the wheels in #1157. At that point, uv started using the async_zip (aka: rs-async-zip) in a repo owned by @charliermarsh, forked from @Majored.
The error message I'm seeing, "Encountered an unexpected header (actual: 0x6064b50, expected: 0x2014b50).", is defined in error.rs in that package's repository with the error UnexpectedHeaderError.
If I am understanding the flow of the code correctly, this is what's happening:
In CentralDirectoryReader (src/base/read/cd.rs), when unzipping a streaming file we iterate through each CentralDirectoryEntry. We expect to either get the CDH_SIGNATURE for a CentralDirectoryEntry, or if we get EOCDR_SIGNATURE we consider that OK and end the loop. Otherwise we return an UnexpectedHeaderError.
The problem is that after the last CentralDirectoryEntry, instead of EOCDR_SIGNATURE, we are seeing ZIP64_EOCDR_SIGNATURE - which is perfectly valid for a zip64 file - but we return an UnexpectedHeaderError even though a perfectly good EOCDR_SIGNATURE is just a few bytes further away.
From the zipfile spec:
4.3.6
Overall .ZIP file format:
  [local file header 1]
  [encryption header 1]
  [file data 1]
  [data descriptor 1]
  .
  .
  .
  [local file header n]
  [encryption header n]
  [file data n]
  [data descriptor n]
  [archive decryption header]
  [archive extra data record]
  [central directory header 1]
  .
  .
  .
  [central directory header n]
  [zip64 end of central directory record]  <-- What cd.rs finds after last CentralDirectoryEntry
  [zip64 end of central directory locator]
  [end of central directory record]  <-- What cd.rs expects after last CentralDirectoryEntry

I can't provide the whole file due to size and because I don't own the rights, but here is the beginning and end of the wheel (aka, zip). You can clearly see the last central directory header signature, the zip64 end of central directory record signature, and the end of central directory record signature.
50 4B 03 04 14 00 00 00 08 00 E5 9B 7C 57 00 00
00 00 02 00 00 00 00 00 00 00 1A 00 00 00 66 6F
6E 74 61 77 65 73 6F 6D 65 70 72 6F 2F 5F 5F 69
6E 69 74 5F 5F 2E 70 79 03 00 50 4B 03 04 14 00
00 00 08 00 E5 9B 7C 57 F2 89 6B 4E 73 01 00 00
DF 02 00 00 30 00 00 00 66 6F 6E 74 61 77 65 73
6F 6D 65 70 72 6F 2F 73 74 61 74 69 63 2F 66 6F
6E 74 61 77 65 73 6F 6D 65 70 72 6F 2F 4C 49 43
45 4E 53 45 2E 74 78 74 8D 51 BD 6E DB 30 10 DE

...

0F 66 6F 6E 74 61 77 65 73 6F 6D 65 70 72 6F 2D
36 2E 35 2E 30 2E 64 69 73 74 2D 69 6E 66 6F 2F
57 48 45 45 4C 50 4B 01 02 14 03 14 00 00 00 08
00 E6 9B 7C 57 AC 1A 5F A9 11 00 00 00 0F 00 00
00 2C 00 00 00 00 00 00 00 00 00 00 00 A4 81 97
6E C3 0F 66 6F 6E 74 61 77 65 73 6F 6D 65 70 72
6F 2D 36 2E 35 2E 30 2E 64 69 73 74 2D 69 6E 66
6F 2F 74 6F 70 5F 6C 65 76 65 6C 2E 74 78 74 50
4B 01 02 14 03 14 00 00 00 08 00 5B 9C 7C 57 AE
75 97 40 7F 93 5A 00 5A 1F 3E 01 25 00 00 00 00
00 00 00 00 00 00 00 B4 81 F2 6E C3 0F 66 6F 6E
74 61 77 65 73 6F 6D 65 70 72 6F 2D 36 2E 35 2E
30 2E 64 69 73 74 2D 69 6E 66 6F 2F 52 45 43 4F
52 44 50 4B 06 06 2C 00 00 00 00 00 00 00 2D 00
2D 00 00 00 00 00 00 00 00 00 CF 1B 02 00 00 00
00 00 CF 1B 02 00 00 00 00 00 DE 76 28 01 00 00
00 00 B4 02 1E 10 00 00 00 00 50 4B 06 07 00 00
00 00 92 79 46 11 00 00 00 00 01 00 00 00 50 4B
05 06 00 00 00 00 FF FF FF FF DE 76 28 01 B4 02
1E 10 00 00

I've verified on two wheels for this package that the files are good, valid zip files.
Running zip -T fontawesomepro-6.5.0-py3-none-any.whl: test of fontawesomepro-6.5.0-py3-none-any.whl OK
Runnning unzip -t fontawesomepro-6.5.0-py3-none-any.whl: No errors detected in compressed data of fontawesomepro-6.5.0-py3-none-any.whl.
Running file fontawesomepro-6.5.0-py3-none-any.whl: Zip archive data, at least v2.0 to extract, compression method=deflate
Running python -m zipfile -t fontawesomepro-6.5.0-py3-none-any.whl: Done testing
Running 7z t fontawesomepro-6.5.0-py3-none-any.whl:
7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
 64-bit locale=en_US.UTF-8 Threads:12 OPEN_MAX:1024

Scanning the drive for archives:
1 file, 289831412 bytes (277 MiB)

Testing archive: fontawesomepro-6.5.0-py3-none-any.whl
--
Path = fontawesomepro-6.5.0-py3-none-any.whl
Type = zip
Physical Size = 289831412
64-bit = +
Characteristics = Zip64

Everything is Ok

Files: 138191
Size:       639195676
Compressed: 289831412

If there are any other details that would be helpful in resolving this or narrowing down the problem, please let me know. Thank you.

Can anyone with more knowledge in rust take a look and confirm whether my understanding of the problem is correct?

@jacklinke -- Are you able to check out https://github.com/astral-sh/uv/pull/9110 and try running uv from source with those changes?

Alternatively, if you can somehow share the wheel, that would be helpful too.

@jacklinke -- Are you able to check out astral-sh/uv#9110 and try running uv from source with those changes?

@charliermarsh Thank you for the quick work ❤! Sorry it took so long to get back to you, but yes!!! It's working and I can now use this in my big project. It was the only big blocker stopping me from moving to uv.
Thank you also, @zanieb


ReaKit

Related to #94

Codecov Report

Merging #111 into master will decrease coverage by 0.66%.
The diff coverage is 96.96%.

@@            Coverage Diff             @@
##           master     #111      +/-   ##
==========================================
- Coverage     100%   99.33%   -0.67%
==========================================
  Files          21       32      +11
  Lines         238      301      +63
  Branches       66       88      +22
==========================================
+ Hits          238      299      +61
- Misses          0        2       +2

Impacted Files
Coverage Δ

website/src/utils/filterSections.js
100% <100%> (ø)

website/src/utils/findNonEmptySiblingSection.js
100% <100%> (ø)

website/src/utils/findSectionByName.js
100% <100%> (ø)

website/src/utils/requireToImport.js
100% <100%> (ø)

website/src/utils/findSectionByLocation.js
100% <100%> (ø)

website/src/utils/getSectionContent.js
100% <100%> (ø)

website/src/utils/getSectionUrl.js
100% <100%> (ø)

website/src/utils/getSections.js
100% <100%> (ø)

src/components/Step/StepContainer.js
100% <100%> (ø)
:arrow_up:

website/src/utils/importToRequire.js
100% <100%> (ø)

... and 13 more

Continue to review full report at Codecov.

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

I just want to say that the new site is superb! Good work! ✨


onNotificationDisplayedMethod - is not called on iOS

onNotificationCreated will be called but onNotificationDisplayedMethod does not work. Neither in background nor in foreground.
Note: Debug set to true or false does not change behavior. Works PERFECTLY on android.
2 - Provide us as much information as possible
Using IOS physical device to receive notifications
Plugin initialization:
AwesomeNotifications().initialize(
null,
[
NotificationChannel(
channelGroupKey: 'basic_channel_group',
importance: NotificationImportance.Max,
channelKey: 'basic_channel',
channelName: 'Basic notifications',
channelDescription: 'Main channel.',
defaultColor: Color(0xFF53E7DF),
ledColor: Color(0xFF53E7DF))
],
channelGroups: [
NotificationChannelGroup(channelGroupKey: 'basic_channel_group', channelGroupName: 'Basic group')
],
debug: false);
e
AwesomeNotifications().setListeners(
onActionReceivedMethod: FcmManager.onActionReceivedMethod,
onNotificationCreatedMethod: FcmManager.onNotificationCreatedMethod,
onNotificationDisplayedMethod: FcmManager.onNotificationDisplayedMethod,
onDismissActionReceivedMethod: FcmManager.onDismissActionReceivedMethod);
3 - How To Reproduce the Error
Steps to reproduce the behavior:
Use IOS physical device:
Schedule a local notification,
onNotificationCreatedMethod will be called but onNotificationDisplayedMethod does not work. Neither in background nor in foreground
4 - Expected behavior
callbacks are called
5 - Screenshots
6 - Additional context
Here are my callback methods:
/// Use this method to detect every time that a new notification is displayed
@pragma("vm:entry-point")
static Future onNotificationDisplayedMethod(ReceivedNotification receivedNotification) async {
print("onNotificationDisplayedMethod");
}
/// Use this method to detect when a new notification or a schedule is created
@pragma("vm:entry-point")
static Future onNotificationCreatedMethod(ReceivedNotification receivedNotification) async {
print('onNotificationCreatedMethod');
}
/// Use this method to detect if the user dismissed a notification
@pragma("vm:entry-point")
static Future onDismissActionReceivedMethod(ReceivedAction receivedAction) async {
print('onDismissActionReceivedMethod');
}
/// Use this method to detect when the user taps on a notification or action button
@pragma("vm:entry-point")
static Future onActionReceivedMethod(ReceivedAction receivedAction) async {
print('onActionReceivedMethod');
}
In AppDelegate.swift
import UIKit
import Flutter
import awesome_notifications
import shared_preferences_foundation
@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
override func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
GeneratedPluginRegistrant.register(with: self)
    SwiftAwesomeNotificationsPlugin.setPluginRegistrantCallback { registry in
      SwiftAwesomeNotificationsPlugin.register(
        with: registry.registrar(forPlugin: "io.flutter.plugins.awesomenotifications.AwesomeNotificationsPlugin")!)
      SharedPreferencesPlugin.register(
        with: registry.registrar(forPlugin: "io.flutter.plugins.sharedpreferences.SharedPreferencesPlugin")!)
    }

    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
}

}

@rafaelsetragni - I check the iOS package, and I see you implement it. But I could not figure out why the onDismissActionReceivedMethod is not called on iOS. Am I missing somethings, please guide me through - thank you!

@rafaelsetragni - thank you so much for your response! Could you let me know when 0.7.5 is available? I am planning to use onNotificationDisplayedMethod to record all displayed notifications in the app.

@rafaelsetragni I am using the code in this notification-interval-fix branch, onNotificationDisplayedMethod is called as expectation on foreground and background, NOT IN TERMINATED
Expected behavior:
All events that happen during TERMINATED state should be saved and notified when the app goes foreground.

Its impossible to do anything on terminated state on iOS, including register events. Im recreating the events at runtimeafter the app goes to foreground and this branch is in development stage.

@rafaelsetragni
"recreating the events" means, all notification events are in the terminated state. will be recreated and fired after the app goes to the foreground, it is right ?. It is important to us because we rely on it to record all visible notifications.
Thank you for your quick response!

Same issue, there is any release date for version 0.7.5?

Same problem, my application relies on the notificationDisplayed to do some stuff, and I just now found out this callback is never called on iOS, which is a major problem, and is not documented anywhere

Also, the dismiss action notification does not fire the onDismissed callback either

Hi @alim971, @Dancas93 and @haily2706, i just uploaded the new release versions of 0.7.5-dev.2+1 versions of awesome_notifications and awesome_notifications_fcm to fix this issue. Please, check it out to see if this issue is solved on these new versions.
Also, don't forget to join in your Discord Beta team to request fixes and new updates.

@rafaelsetragni seeing same issue. Even upgrading to 0.7.5-dev.2+1 doesn't seem to make any change.

Now the last version is 0.7.5-dev.3

@rafaelsetragni unfortunately couldn't try it, because the FCM package apparently isn't compatible yet with 0.7.5-dev.3 (even when also using 0.7.5-dev.3) for that one)
Is there any documentation around needing that notification service extension? I also noticed that other handlers stopped working, like onActionReceivedMethod, is that also due to needing a notification service extension?

You should not use firebase_messaging with awesome_notifications_fcm and the documentation is on readme files.

Not talking about firebase_messaging, I don't use it. talking about awesome_notifications_fcm not being compatible with awesome_notifications.
I see the documentation in the README, but nowhere does it mention under what conditions it is necessary to implement.
So with v0.7.4 onActionReceivedMethod works fine but onNotificationDisplayedMethod is never called.
On 0.7.5-dev.3 neither is called.
Can you confirm that both should work, and that the service extension is needed for this? I don't care about custom notifications or buttons, so normally a service extension shouldn't be necessarily.
Thanks!

Same issue here. Any workarounds are highly appreciated!

In my case, the listener worked well after I create an immediate notification without schedule on 0.7.4+1
static Future<void> initializeListeners() async {
    if (await Permission.notification.isGranted) {
      await _instance.createNotification(
        content: NotificationContent(
          id: -1,
          channelKey: 'channel_key',
          displayOnForeground: false,
          displayOnBackground: false,
        ),
      );
    }
  }


Optimizing Production Deployment

Hi team,
I was searching through the GitHub when I came across this project. As a developer working in Healthcare field, I would like to contribute to the project as well.
These are some suggestions/questions that came to my mind after a quick look through the repository.

The NodeJS part is scattered across the repository. It could be moved to a single folder along with the Dockerfile. This will result is separate folders for each of the components required for docker-compose.
The base image used for the NodeJS part is node:boron and the build is done inside the container. Although this simplifies the build process, it makes the image heavy. node:boron-slim image is less than half the size of the current image and provides the same functionality. curl also comes in-built.
Further optimizations are possible in Dockerfile code, and further more if we put all the NodeJS code in one folder. For example, separate mkdir command is not required.
The only parameter required to be edited before running the application is the DOMAIN_NAME parameter in docker-compose.yml. This also means that we can supply the built Docker images over Docker Hub, and refer them in the docker-compose.yml rather than building them everytime. This will ensure that the software can be deployed with consistent dependencies. This could be added as an option for people who wish to deploy it direclty into production.
The documentation seems to be lacking descriptions for some of the entries (such as the key files).

And out of curiosity, few more question.

Is there any plans of supporting deployment on Kubernetes or Docker Swarm?
Is there already a CI-CD pipeline setup for this repository? I could see a .travis.yml but no build status embedded in the README. Also couldn't find anything on Travis Portal.

Regards
Lallu

@lalluanthoor thanks for your interest in this project.  If you would like to contribute a PR with Docker improvements that would be gladly welcomed!
As far as Kubernetes or Docker Swarm, we currently don't have anyone involved in the project who has experience in those environments, but we would love to eventually support more deployment options.
We do not currently have a a CI-CD pipeline setup.  I think some work may have started on that but it was never finished.

@jkleinsc I have already submitted a PR #59  for the first part of my questions.
For the second part, I was going through how to setup automated Docker image builds out of a Github repository. Docker Hub already provides this feature. But for this to work, we might need to split the repository into multiple repositories, with each one producing a single Docker image.
For the third part, only some minor adjustments in the docker-compose.yml and a separate deployment guide would be required to deploy the server on a Docker Swarm.
What are  your thoughts?

@lalluanthoor I think setting up automated Docker image builds would be great.  If I understand it properly, I think we would need three repos:
1 - HospitalRun -- probably use this repo (hospitalrun-server)
2 - HospitalRun logstash
3 - HospitalRun nginx
It looks like the couchdb and elasticsearch containers are prebuilt containers.

@jkleinsc
Proposal
Assumptions

It is OK to store default credentials in source code.

Decomposition of Current Repository

hospitalrun-server

conf folder
patientimages folder? I don't know why this folder is there.
utils folder
.dockerignore
.eslintignore
Dockerfile
app.js
config-example.js
package.json

hospitalrun-logstash

logstash folder

hospitalrun-nginx

nginx folder

hospitalrun

docker-compose.yml
DEPLOYMENT_GUIDE.md

The CODE_OF_CONDUCT.md, README.md, LICENSE, .gitignore, etc. should be there in all the repos.
The other two containers (elasticsearch and couchdb) are pre-built and we only use them as is. I also checked with the elastic team whether they have a thinner version of these images. They currently do not have any. Their recommendation was to use the open source code base directly and optimize it to our needs. Currently, we can put it as out of scope for this discussion.
Why Four and not Three

all the images get their own repositories, clear separation, easy to manage
releases can be made using only updating the image versions in docker-compose.yml, clean and independent of work in other repos
only require minimal cloning (few files and their history), easy for deployment, no build environment needed in customer side (node, npm)
customisation of images are easy as well; customer can pull any of our shipped images, make necessary changes, and update the docker-compose.yml to use the custom image

@lalluanthoor looks good to me.
As far as patientimages, it is a directory that needs to exist for the server (patient photos are saved here); Also there should be an /attachments directory.  They need to exist in the running container.

@jkleinsc I need some clarifications.

The patientimages and attachments are part of which server? Node or Nginx?
Are they located in the site root or file system root?

@lalluanthoor patientimages and attachments are part of the Node server.  It needs to be able to write to those directories and serve files from those directories.  They are located at site root, dictated by the value set in config.js (defaults to patientimages and attachments under the node app root directory).

@jkleinsc thank you. Could you also create the empty repos? I don't have write access.

@lalluanthoor I created the repos.  For the "hospitalrun" one, use hospitalrun-deploy.

PR Updates

The NodeJS components remain in the current repository.
The Nginx component moved to it's own repository.
The LogStash component moved to it's own repository.
The Docker Compose component moved to it's own repository.
Tagged all 4 repositories with 1.0.0-beta2.

Docker Hub Updates

@jkleinsc and myself have setup automatic build for the containers whenever a new tag is pushed to Github.
The tag should match the regex /^\d+\.\d+\.\d+(-[a-z]+(\d+)?)?$/. It will match regular SemVers (like 1.0.0, 1.1.1, etc) as well as pre-releases (like 1.0.0-beta, 1.0.0-beta2, etc).
The images will be qualified with the same tag.
The NodeJS server image can be found at hospitalrun/hospitalrun-server.
The LogStash server image can be found at hospitalrun/hospitalrun-logstash.
The Nginx server image can be found at hospitalrun/hospitalrun-nginx.

Please refer to the linked PRs for code changes.
Notifying @jkleinsc @tangollama @mofesola @jglovier

@jkleinsc Is there any specific reason why the logstash configuration is loaded during runtime rather than adding it to the image directly? If not, I would like to make it part of the image build process and remove the volume mounting from the docker-compose.yml.

I have also closed three of the PRs for safety.

@lalluanthoor I'm not sure.  I can't think of why it would need to be done one way vs the other.  @mofesola might be able to explain why it was built that way.


Build error: package crypto/ecdh is not in GOROOT

Your environment.

Version: go version go1.15.15 linux/arm

What did you do?

I am currently attempting to build the WebRTC example on Raspberry Pi OS. However, I encountered the following build error: "../../../../go/pkg/mod/golang.org/x/crypto@v0.11.0/curve25519/curve25519_go120.go:9:8: package crypto/ecdh is not in GOROOT (/usr/lib/go-1.15/src/crypto/ecdh)". It appears to be a dependency version mismatch error. Has anyone successfully resolved this issue previously?

Hi @arunmir
Would you mind upgrading to a modern version of Go? I believe you will need at least 1.18+
thanks for using Pion! Please re-open if you have more questions


Autograder: No output for all checks that runs a shebang

Which autograder check is failing?
All checks including and after Play Rock Paper Scissors with an opponent
What is happening?
It seems like my code produces no output when the autograder is checking them.
Failed workflow run URL
https://github.com/comp426-2023-spring/a03-zhangwy324/actions/runs/4219800935/jobs/7325504926
What should be happening?
My code should always produce some output when running node-rps followed by anything.
Screenshots of your local test(s)

Why do you think the autograder is failing?
I am not too sure. It might be the shebang in the beginning and it is not running a valid script, because if it is, my code should always produce some output. I think it is the shebang because all autograder tests that run #!/bin/bash; in the beginning are not producing any output.

@zhangwy324 See #1
Latest fix to autograder should have taken care of the behavior mentioned above, closing this for now.


Implemented an advanced types verification for the TypedStorage in the NativeContracts.

Implemented an advanced types verification for the TypedStorage in the NativeContracts.

Can you elaborate a bit on what the problem was and how it was solved?

@heikoheiko

The initial commit "Fixed length recalculation after elements removal from the List typed… " was addressing your request to fix the length recalculation for IterableDict and List, but later both were removed as you already implemented the recalculation for the ItedableDict on your own and the List's recalculation was removed due to the perfomance concerns;

The commit "Implemented an advanced types verification for the TypedStorage in th…". Since the TypedStorage-derived classes are strongly typed, their misusage was possible without the developer even noticing that since they did not issue any errors on the incorrect initialization attempts. The wrong data was just written to the wrong places in the storage. To address this I added the type checks on assignment and the following unit tests:
a = nc.Dict(nc.List('uint16'))
c = nc.List(nc.Dict('uint16'))
k = nc.List(nc.List('address'))
a.setup(b'a', _get, _set)
c.setup(b'c', _get, _set)
k.setup(b'k', _get, _set)
test invalid types
with pytest.raises(AttributeError):
a.b == 81
with pytest.raises(ValueError):
a['one']['two'] = 63432
with pytest.raises(TypeError):
a['one'][2] = 'somestr'
with pytest.raises(NotImplementedError):
k[1] = 2
with pytest.raises(NotImplementedError):
c[1] = 2

The commit "Removed the tester.disable_logging() calls as obsolete" is pretty obvious, such method was removed from the tester.

The commit "Fixed an error in test_native_contracts.test_nac_tester()" addressed a Failing Travis build by adding the error handling for abi encoding.

The commit "Resolved the HydraChain#70 issue: "Reading Scalar from Struct in native contracts throws EncodingError" fixed calling the Struct getters/setters instead of the nested Scalar ones. So now the nested Scalar accesses the storage itself.

Coverage increased (+0.3%) to 80.836% when pulling 0dada9e983d919f869b58454f5b58e2f2ff9bf28 on RomanZacharia:develop into dda8abb0618fb4ff45341b168b1d5515e7722432 on HydraChain:develop.

py27 build succeeded -- merging


Apply Icons Customization Not Working

When attempting to customize some of the file associations, I ran into the issue that the Apply Icons Customization command does not work. I receive a "command 'extension.regenerateIcons' not found" error from VSCode. In fact none of the Icons commands seem to be working even though they show up in the F1 list.
I am running VSCode 1.8.1 on OS X 10.12.2. I tried uninstalling and re-installing the extension with no luck either.

Can you post your custom settings?

Sure thing.
{
  "tslint.rulesDirectory": "./node_modules/codelyzer",
  "typescript.tsdk": "node_modules/typescript/lib",
  "editor.tabSize": 2,
  "html.suggest.angular1": false,
  "html.suggest.ionic": false,
  "vsicons.associations.files": [
    {
      "icon": "webpack",
      "extensions": [
        "webpack.config.js",
        "webpack.config.common.js",
        "webpack.config.babel.js",
        "webpack.config.common.babel.js",
        "webpack.config.base.babel.js",
        "webpack.config.dev.babel.js",
        "webpack.config.staging.babel.js",
        "webpack.config.production.babel.js",
        "webpack.config.prod.babel.js",
        "webpack.config.dev.js",
        "webpack.config.staging.js",
        "webpack.config.production.js",
        "webpack.config.prod.js",
        "webpack.config.ts",
        "webpack.config.coffee",
        "webpack.config.test.js"
      ],
      "format": "svg"
    }
  ]
}

Thanks! I'll come back to you soon!

FYI, trying to invoke Restore Default Icon Manifest ends in the error "command 'extension.restoreIcons' not found".

Try with this. If you only want to add, there's no need to copy all the already existent icons. Plus, you have to specify that this are filenames not normal extensions.
"vsicons.associations.files": [
    { "icon": "webpack",  "extensions": ["webpack.config.test.js"], "filename": true, "format": "svg" }

Stay tuned as we're going to release 6.0.0 in a moment.

Thanks!  I made that changes but still getting the "command 'extension.regenerateIcons' not found" error...  it occurs even if I take out the settings completely...

It seems to be a bug affecting the installation package (.vsix). I'm looking into it.

Found it! A misplaced dependency. New version will fix this.

@cmccorvey it's been automatically closed once I merged. Let me know if it works with v6.0.0. If not, I'll reopen it.

6.0.0 works great, Thanks!

Cool :+1:

That was a tricky one. Only debuggable on a non-dev machine.


Problem with CDN, expire ssl certificate

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
It's trouble load CSS file from https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css because expire SSL certificate frome Sectigo Limited
Certificate expire Tue, 12 Oct 2021 23:59:59 GMT
Reduced test cases
https://stackpath.bootstrapcdn.com/bootstrap/4.4.1/css/bootstrap.min.css
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Firefox
What version of Bootstrap are you using?
4.4.1

We do not recommend to use StackPath anymore. Please use JSDelivr instead, as we now mention in the docs.


First step to add Only Sexy comments feature.

Hi! I'm proposing the following feature. What do you think about it?
I find this plugin very useful but actually the only feature I use
most of the time is the so called "Sexy Comments", however this feature doesn't
behaves exactly as I want. For example:
Default behavior for toggle comments:
    //while (true) {
        //Socket client = sock.accept();
        //PrintWriter pout = new PrintWriter(client.getOutputStream(), true);
        //pout.println(new java.util.Date().toString());
        //client.close();
    //}

Default behavior for sexy comments:
    /*
     *while (true) {
     *    Socket client = sock.accept();
     *    PrintWriter pout = new PrintWriter(client.getOutputStream(), true);
     *    pout.println(new java.util.Date().toString());
     *    client.close();
     *}
     */

Desired behavior in both cases:
    //while (true) {
    //    Socket client = sock.accept();
    //    PrintWriter pout = new PrintWriter(client.getOutputStream(), true);
    //    pout.println(new java.util.Date().toString());
    //    client.close();
    //}

The feature I'm proposing is to create a mode that, when ON, the Toggle function calls
CommentLinesSexy() by default and this function behaves as shown above.
There is a lot of work to do for this feature to work with all the languages
supported, this is only the first step. The tested languages are:

Python
C/C++
Java
Ruby
Bash
VimML

Personally I have disabled all the mapping of this plugin and only have
c binded to SexyCommentsOnly. Don't worry this isn't part of my
SexyCommentsOnly feature.

Thanks for your contribution @rendon. I've been added as a maintainer to this repo and will be going through all the old pull requests. At first bluff this one seems to accomplish much the same thing as #24 that I merged just a minute ago.
Can you give that change a review and let me know where this is heading that's different than that? And where you are at with this development wise?

Thanks @alerque for responding, I will try #24 from your repo and I'll let your know if that covers my pull request.

Indeed #24  does the same as this PR. You can close this one :).

Thanks for looking into this @rendon. I'm closing this now, but let me know if anything turns up that isn't functioning as well as it could and we'll review the implementation differences.


Specify the low-level model-server HTTP API using OpenAPI or AsyncAPI

Should be a different spec than for the high-level API. Otherwise, this API might become to prominent.

Implementation can be found in https://github.com/modelix/modelix.core/blob/d427dcb0de74263069a468408a316a002b6e832b/model-server/src/main/kotlin/org/modelix/model/server/KtorModelServer.kt