adding domain argument to solid/thermal load setters

This PR adds a domain argument to the load setters in the solid mechanics and thermal physics modules. It is a breaking change, although I suspect most of the time users will not want to apply loads to the entire domain (perhaps this isn't true for body loads). It doesn't seem too bad to provide the entire mesh using the EntireDomain or EntireBoundary helper functions, although it does add another required argument. Curious to hear everyone's thoughts on this suggested interface change

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (655f116) 88.78% compared to head (bfe3693) 88.76%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1075      +/-   ##
===========================================
- Coverage    88.78%   88.76%   -0.02%
===========================================
  Files          154      154
  Lines        12480    12479       -1
===========================================
- Hits         11080    11077       -3
- Misses        1400     1402       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

One way to avoid the interface breaking change is to have the Domain arguments be std::optional with a default null value. If the argument is not supplied, a domain from the entire mesh can be constructed. Any thoughts @samuelpmishLLNL ?

It could also default construct an empty domain to avoid the use of std::optional.

Right now, the Domain class doesn't have a default constructor, since it has a const mfem::Mesh & member that must be initialized. But any of the following seem like reasonable approaches to me:

std::optional argument
defaulted "empty" Domain argument
required non-default Domain argument

Actually, it's probably a good idea to add this to the material calls as well so we can have multiple functional forms in a single simulation.

We could do that now and it would work for elastic material models. For inelastic models, we need extra logic to allocate the correct number of internal variables per material and to stride through those correctly during assembly. Can we get there in an incremental fashion without holding up this PR?

Actually, it's probably a good idea to add this to the material calls as well so we can have multiple functional forms in a single simulation.

We could do that now and it would work for elastic material models. For inelastic models, we need extra logic to allocate the correct number of internal variables per material and to stride through those correctly during assembly. Can we get there in an incremental fashion without holding up this PR?

Good point. I missed the part about materials with state needing some extra work. I'll go ahead an approve this.


pull request for e2e test at 01/18/2017 18:26:15

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Rail fixes for GFX mode

Added proper argument checks in RAILS channel
Fixed screen update in GFX mode
Fixed some missing NULL pointer checks

@freerdp-bot tes

@freerdp-bot test

@hardening @akallabeth
Would be nice to get this merged - can the two of you come to an agreement concerning the checks.
I have no problem merging the PR as is ...

My position is still that this PR is really fine with e23af1d removed from the history. Unneeded checks:

take time at runtime;
makes the code harder to read;
give no protection at all;
give the impression to the reader that the checks that are done indicate legitimate values. Or at least a feeling of self-protecting code, which is an indication of a lack of control of the callers;

The best image I have for that, is "do you take snow chains when going in summer in the Sahara ?"

@hardening Removed the checks you referenced as the function is returning void and can not propagate the misuse.

@hardening Is this one good to go now from your side?


boards: arm: Add support for nRF51 Dongle (PCA10031)

This commit adds support for the nrf51_pca10031 board.
Signed-off-by: Stig Bjørlykke<EMAIL_ADDRESS>

Codecov Report

Merging #11782 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #11782   +/-   ##
=======================================
  Coverage   48.27%   48.27%
=======================================
  Files         280      280
  Lines       43321    43321
  Branches    10371    10371
=======================================
  Hits        20913    20913
  Misses      18258    18258
  Partials     4150     4150

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 10c4841...92a6c24. Read the comment docs.

I've so far used the nRF51 DK board definition (nrf51_pca10028) when building for the nRF51 USB dongle, and haven't had any issues with that. What kind of improvements are to be expected with a dedicated board definition for the dongle?

@ioannisg

I am wondering, since this is so similar to nrf51_pca10028, if these two boards could be merged into the same directory. (Still separate boards, but located under same dir)

Why? Each board has its own directory under /boards after all and those two are surely different boards.

Why is the tests failing for QUARK_D2000 when I didn't touch any related files?

Why is the tests failing for QUARK_D2000 when I didn't touch any related files?

Since you touched tests/drivers/adc/adc_api/src/test_adc.c that might be causing a build on QUARK_D2000.  We try and be smart about what we build, but sometimes we miss things and some times we build a bit too much.

Since you touched tests/drivers/adc/adc_api/src/test_adc.c that might be causing a build on QUARK_D2000.

Ok. It does not give any added value testing for this board so I'll update the changes.

What do we want to do with the patxh, @carlescufi? Should I merge it? @anangl could you add your review?

Files has been updated with requested changes and changes in Zephyr since the PR was last updated.


Disable JS for Every Page/Template on Every Page

Summary
The JS file for every page and template is included on EVERY page as you can see in the attached image of your own site.
A config setting to output only the page relevant JS on the specific page it is generated for. Is there some kind of workaround for the moment?
Basic example

Motivation
For a light site this may be beneficial but for a large site with many very large complex pages this ends up overloading every page.

@edstronaut hi!
Application starts to prefetch all links in a viewport, that's a reason.
Here is original questions + some workarounds inside https://github.com/gridsome/gridsome/issues/786


[Side-nav] Expand/collapse behaviour

Lately, we changed the side-nav expand/collapse behavior to a FAB in the bottom left of the page. I am not satisfied with this solution as the position of the button gives it a low hierarchy in the layout of the page, It overlaps the last item of the navigation list and it's not a common behavior or best practice for this type of action.

A FAB should perform a constructive action such as create, share, or explore and shouldn't be used for minor, layout, overflow, unclear, or destructive actions, such as: Trash, Alerts, or controls better suited to a toolbar.
Examples of FABs can be chat, help, share, favorite, and new usually placed in the bottom right of the UI.
You can find here examples of all side-nav in Vonage's products and their behavior
And new recommended behaviors we should support in our component.
We should also change the behavior here in our docs to the new behavior supporting the following use-cases:

Primary header + secondary drawer
Primary drawer + secondary header
Drawer as modal (shown as the responsive use case)
Collapse drawer to navigation rail (support in the future?)

@jshenkman can you p[lease varify:
https://vivid-5k76ffz5m4m0.deno.dev/

@jshenkman can you p[lease verify: https://vivid-5k76ffz5m4m0.deno.dev/

LOVE IT! Looks amazing! also on mobile! 😍
thanks 🙏🏻


envoy: 1.26.3 -> 1.26.4

Description of changes
https://nvd.nist.gov/vuln/detail/CVE-2023-35941
https://nvd.nist.gov/vuln/detail/CVE-2023-35942
https://nvd.nist.gov/vuln/detail/CVE-2023-35943
https://nvd.nist.gov/vuln/detail/CVE-2023-35944
1.27.0 is indeed out, but bumping to that is significantly more complicated. Be my guest if you would like to figure that out instead - I made a start in a branch https://github.com/NixOS/nixpkgs/compare/master...risicle:ris-envoy-1.27.0 but didn't get very far.
This at least can have a straight backport to 23.05.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

I'm unable to reproduce this build and have received at least two other hashes for the deps when attempting to do so.
error: hash mismatch in fixed-output derivation '/nix/store/rw1jj11dwlfpmqir7bmaj4c8f619ccbv-envoy-1.26.4-deps.tar.gz.drv':
         specified: sha256-KcTh6Fd1EUXcXByPSwMVy5J/6VSVGWBmHr8asS1/ffU=
            got:    sha256-d8uj/uZP2bl5BqqzUwTigW61aYDUxeUh4XdWgKp0dcs=

error: hash mismatch in fixed-output derivation '/nix/store/rw1jj11dwlfpmqir7bmaj4c8f619ccbv-envoy-1.26.4-deps.tar.gz.drv':
         specified: sha256-KcTh6Fd1EUXcXByPSwMVy5J/6VSVGWBmHr8asS1/ffU=
            got:    sha256-RtXd/MfH57lbVHqvofv05rt8qqrJ6y3Eruqwm9E78wc=

You're not the only one. We can revert this, but we need some other solution for the CVEs,

I've opened #254750, please test those hashes.


Update ArchnemesisRecipeTracker.cs

Adding recipe output counts to the recipe window, allowing you to see if it is worth doing a certain recipe.

Used in https://github.com/instantsc/RecipeTracker/commit/dfa0105c89c474f93581991b4ec2147ac2a23019, thanks!


[UB-1339] Adding support for ultra boot sequence

PLEASE DO NOT MERGE !!!

Won't use this for our bootup sequence


XCode 13 Archiving Failed

We can build and run on development; but always failed when archiving on production.

Unfortunately, this is an Xcode 13 issue, from release note:
Known Issues
Swift libraries may fail to build for iOS targets that use armv7. (74120874)
Workaround: Increase the platform dependency of the package to v12 or later.

Swift libraries depending on Combine may fail to build for targets including armv7 and i386 architectures. (82183186, 82189214)
Workaround: Use an updated version of the library that isn’t impacted (if available) or remove armv7 and i386 support (for
example, increase the deployment target of the library to iOS 11 or higher).

The same thing is happening to other libraries https://github.com/onevcat/Kingfisher/issues/1802#issuecomment-919815919
What we can do is opening a branch and remove Combine and SwiftUI for supporting old iOS versions
I'll do that

Use this xcode13-no-swiftui branch

I'm far from an expert but I noticed this in the release notes of Xcode 13.2 Beta:

"Fixed an issue that prevented Swift libraries depending on Combine from building for targets including armv7 and i386 architectures. (82183186, 82189214)"

Could that be a solution?

I can't find the xcode13-no-swiftui branch. How can I fix it? (I support iOS 10 with Xcode 13)

@dinhletrieuduong I restored the branch

Thanks, it's worked


broken regex

Fix broken IPv4 regex

completed in: https://github.com/hirusha-adi/Near/commit/436fe32dc162dd80a08a5683b355972d670d0701


add git requirement to the environment.yml

This adds the git requirement to the environment.yml, as it is necessary during the pip install step
Background:
I tried to install fibsem on a machine where the only version of git was installed through conda, which means that the pip install inside the fibsem environment would error out by not having git available. Adding this line to the environment.yml solved the issue.
Feel free to close this PR if it is not wanted/needed

Merged, thank you @sroet


Handle checksums on copy

S3.Object.copy() fails with multipart and ChecksumAlgorithm as mentioned in #241
This fixes the issue by adding the checksum information to CompleteMultipartUpload

I am also blocked on this PR. If possible, do we have an ETA for this to be merged?

@nateprewitt I've made the requested changes,

Hi everyone, any chance we can help get this done? The possibility of using aws' checksums is very welcome for all those doing checksums for data integrity purposes.

This not being merged is currently blocking me. What are we waiting on @nateprewitt ?


A0-1903: update to 0.9.34

Description
Update to substrate 0.9.34
Type of change

Needed to remove fee calculation test, as fill_block method is no longer in frame system. It is instead in a pallet_root_testing (https://github.com/paritytech/substrate/commit/3e71d606b7d1e91d9c1701c0a443530eefca1a39), which should not be used in production code. Will create a task for bringing this test back

Will create a task for bringing this test back

Did that happen?

Will create a task for bringing this test back

Did that happen?

didn't find it. Here newl created issue


implement run-pass tests as xtasks

resolves https://github.com/rtic-rs/cortex-m-rtic/issues/499 .
With this PR, you should be able to run cargo xtask --target <desired target> or cargo xtask --target all locally. Of course, it also reconfigures the CI workflow to do the same.
Note that I've translated the old Run-pass tests verbatim for now, which means the code includes checks for a "types"example which doesn't exist anymore.
The examples could be collected much more nicely to prevent leftovers like this in the future, but imo that could also be achieved in a separate PR.

Converting to draft until I've debugged the Actions failure (of course, it works on my machine..)

problem resolved; un-draft-ing. I've left my fixup PRs for transparency, happy to squash after review.

bors merge


builtins: implement swathe of I/O functions for Geometry/Geography

PR: https://github.com/cockroachdb/cockroach/pull/48015
From release notes:

Added the following geospatial functions: ST_GeomFromText, ST_GeometryFromText, ST_GeogFromText, ST_GeographyFromText, ST_GeomFromWKB, ST_GeomFromEWKB, ST_GeomFromEWKT, ST_GeomFromGeoJSON, ST_GeogFromWKB, ST_GeogFromEWKB, ST_GeogFromEWKT, ST_GeogFromGeoJSON, ST_AsText, ST_AsBinary, ST_AsEWKB, ST_AsEWKT, ST_AsKML, ST_AsGeoJSON. [#48015][#48015] {% comment %}doc{% endcomment %}

Some of these are partially addressed (or at least mentioned or show an example):

st_geomfromtext (#8747)
st_astext (#7736)
st_asgeojson (#8617, #8782)


error when run python demo/demo_skeleton.py demo/ntu_sample.avi demo/demo.mp4

Thanks for sharing the implementation. When running the demo, the following error message. Please advice.
(pyskl) PS D:\CODE\master\pyskl> python demo/demo_skeleton.py demo/ntu_sample.avi demo/demo.mp4 load checkpoint from local path: .cache\joint_f6bed715.pth load checkpoint from http path: http://download.openmmlab.com/mmdetection/v2.0/faster_rcnn/faster_rcnn_r50_fpn_2x_coco/faster_rcnn_r50_fpn_2x_coco_bbox_mAP-0.384_20200504_210434-a5d8aa15.pth Performing Human Detection for each frame [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 72/72, 4.9 task/s, elapsed: 15s, ETA:     0sPerforming Human Pose Estimation for each frame [                                                  ] 0/72, elapsed: 0s, ETA:Traceback (most recent call last):   File "D:\CODE\master\pyskl\demo\demo_skeleton.py", line 311, in <module>     main()   File "D:\CODE\master\pyskl\demo\demo_skeleton.py", line 255, in main     pose_results = pose_inference(args, frame_paths, det_results)   File "D:\CODE\master\pyskl\demo\demo_skeleton.py", line 181, in pose_inference     pose = inference_top_down_pose_model(model, f, d, format='xyxy')[0] TypeError: 'NoneType' object is not subscriptable
Computer:
GTX 1660TI
Windows 10
Chip AMD Ryzen 3700
Installation:
python3.10 or python3.9 (I tried both)
conda install pytorch==1.10.1 torchvision==0.11.2 torchaudio==0.10.1 cudatoolkit=11.3 -c pytorch -c conda-forge
pip install -r requirements.txt
pip install -e .
pip install openmim
mim install mmcv-full
mim install mmdet
Please, help me. Indeed, can you share exactly version packages you install. Thanks

Hi, seems that the problem is the function call inference_top_down_pose_model(model, f, d, format='xyxy') returned None, which is not the expected behavior. I suggest you delve deep into this problem and try to fix.

thanks

thanks

Hello, how did you solve it, I also encountered this problem


[Bug] Sidebar is not stretching to the full height

Is there an existing issue for this?

[X] Yes, I have searched the existing issues and none of them match my problem.

Product Variant
Cloud (http://rxresu.me)
Current Behavior

The sidebar does not stretch
Expected Behavior
The sidebar should stretch from top to bottom
Steps To Reproduce

Select Chikorita
Enter some text, but not enough to fill the page
The sidebar is not the full length

What browsers are you seeing the problem on?
Firefox
What template are you using?
Chikorita
Anything else?
No response

Can you please assign this issue to me as it seems it needs a small change in styling. Can give min width of 100% and this would work probably.

@prithvi5481 I mean, feel free to fork and pr a solution

I have raised fix PR (here)[https://github.com/AmruthPillai/Reactive-Resume/pull/1891]


ENH: Add APCG for logreg

closes #4

codecov thinks that njitted functions are not tested, hence the negative diff. There does not seem to be an easy fix...

@qb3 looks good to you ?

3 features ?

I had to do it because apcg is so slow to converge :/

Codecov Report

Merging #8 (fae4bfc) into master (2920240) will decrease coverage by 0.81%.
The diff coverage is 57.14%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
- Coverage   61.93%   61.11%   -0.82%
==========================================
  Files           9        9
  Lines         662      751      +89
  Branches      138      153      +15
==========================================
+ Hits          410      459      +49
- Misses        214      248      +34
- Partials       38       44       +6

Impacted Files
Coverage Δ

andersoncd/logreg.py
56.68% <46.83%> (-4.75%)
:arrow_down:

andersoncd/lasso.py
58.90% <100.00%> (ø)

andersoncd/tests/test_logreg.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Failed to Deploy Contract in Playground

Describe the bug
When I'm trying to deploy contracts in a playground project, an error pops up saying "Oops! Something went wrong. If you'd like, please report the Bug. Thank you!". I checked the console and the GraphQL request, there's no additional useful information. I suppose the problem originates from the backend of the playground.
To Reproduce

Open this project
Navigate to Contract 1 and deploy it to account 0x05
Navigate to Contract 2 and try to deploy it to account 0x06, the error should then appear

Screenshot

Environment:

OS: Windows 11 Enterprise 23H2
Browser: Microsoft Edge 121.0.2277.128 (Also tested on Mozilla Firefox 122.0.1)

Additional context
Here's the HTTP response from the server regarding the deployment request:
{
    "errors": [
        {
            "message": "something went wrong, we are looking into the issue",
            "path": [
                "createContractDeployment"
            ],
            "extensions": {
                "code": "INTERNAL_SERVER_ERROR"
            }
        }
    ],
    "data": null,
    "extensions": {
        "code": "INTERNAL_SERVER_ERROR"
    }
}

I’ve pinpointed the root cause of the problem by testing the project in a local emulator. The FlowToken.cdc contract, being a core component, is already deployed to all users. Attempting to re-deploy it results in a conflict because the path /storage/flowTokenVault already contains an object.
However, there remains an issue with the playground: it fails to effectively communicate error messages to users. When contract deployment or transaction execution encounters failure, providing clear error messages is crucial. This helps users better understand the problem and facilitates troubleshooting.

Thanks for reporting the issue. We'll be updating the backend to support Cadence 1.0 development. We'll have a newer version of the emulator that has core contracts already deployed. We plan on exposing these to the user so dev is more straight forward. We'll make sure to pass the errors to the UI so they are more clear.

the backend is officially supports cadence 1.0, and it should handle new syntax without any issues
feel free to reopen the issue if it still doesn't work


One more German file, first time with a sign-off (not configured well, I guess...) ^^

Is This still relevant?

Since the ElkArte team decided to move everything to Transifex where someone else already had a different, worse translation: no :(

I thought both versions were on Transifex ... formal and ... don't know conversational?

I've looked at a little bit. My impression is that this is no longer current. So my request.

I haven't updated this PR in ages, emanuele convinced me to go to Transifex where I, at least, have got some review capabilities by him.
So yes, this is old.
@spuds Which of the two translations is mine, actually?

German (Germany) is Yours..

Ook, so this PR that was kept open for reference can be closed I guess.


The engine "node" is incompatible with this module

Following this issue https://stackoverflow.com/questions/72052616/google-app-engine-the-engine-node-is-incompatible-with-this-module and this one too https://github.com/GoogleCloudPlatform/nodejs-docker/issues/214, we still have an issue with the Node version.
This questions has been asked many times already, and I checked all the answers but none of them helped me.
I'm trying to deploy a NodeJs app to GAE using a app.yml file. It was working perfectly until my last Github PR on it where I upgraded some nodes modules.
Now I'm getting the Error The engine "node" is incompatible with this module. Expected version "16.x.x". Got "12.19.0".
As you can see I'm up to date on my computer. I also removed and install Node, Npm and Yarn tonight just to be sure.
node -v
v16.15.0
npm -v
8.5.5
yarn -v
1.22.18

I tried deploying the app with a specific node version on my packages.json but with or without it's not working.
  "engines": {
    "node": "16.x.x"
  },

I also tried to remove the cache on GAE using this, without no effect.
default_expiration: '0d 0h'

On my app.yml I'm using nodejs en Env: flex:
runtime: nodejs
env: flex

I can't use node16 as I need env: flex.
Of course I tried to delete the Node_modules and yarn.lock for at least 100 times but still nothing, always the same error.
Nothing change on the app.yml file since the last deployment. The only thing is that I upgraded some Node Modules.
On the Yarn side I've tried:
yarn install --force
yarn install --ignore-engines
yarn cache clean --all

But still not working.

# [START app_yaml]
runtime: custom
env: flex

# default_expiration: '0d 0h'

# Define environment variable
env_variables:
  # NodeJS
  NODE_ENV: 'prod'
  APP_PORT: 8080

beta_settings:
  # The connection name of your instance, available by using
  # 'gcloud beta sql instances describe [INSTANCE_NAME]' or from
  # the Instance details page in the Google Cloud Platform Console.
  cloud_sql_instances: '********'
# Resources configuration (for each server)
resources:
  cpu: 1
  memory_gb: 2
  disk_size_gb: 10
# Configuration of automatic scaling
automatic_scaling:
  min_num_instances: 1
  max_num_instances: 3
  cool_down_period_sec: 180
  cpu_utilization:
    target_utilization: 0.6
# [END app_yaml]

Any help will be really grateful.

same issue here
I believe the issue is here in the base dockerfile
RUN /opt/gcp/runtime/bootstrap_node \
    --direct \
    v12.19.0

Sorry, I lost track of this issue. Yes, v12.19.0 is configured in that base dockerfile. However, I couldn't reproduce this issue.
I was able to install node 16, with the following logs from cloud build:
Step #2: INFO[0023] COPY . /app/
Step #2: INFO[0023] Taking snapshot of files...
Step #2: INFO[0023] RUN /usr/local/bin/install_node '16.17.1'
Step #2: INFO[0023] cmd: /bin/sh
Step #2: INFO[0023] args: [-c /usr/local/bin/install_node '16.17.1']

This is different from builds failures reported here:
Step #2: INFO[0024] COPY . /app/
Step #2: INFO[0024] RUN NODE_ENV=*********** yarn install ||   ((if [ -f yarn-error.log ]; then       cat yarn-error.log;     fi) && false)
Step #2: INFO[0024] cmd: /bin/sh
Step #2: INFO[0024] args: [-c NODE_ENV=*********** yarn install ||   ((if [ -f yarn-error.log ]; then       cat yarn-error.log;     fi) && false)]
Step #2: yarn install v1.22.19
Step #2: [1/5] Validating package.json...
Step #2: error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "16.17.1". Got "12.19.0"
Step #2: error Found incompatible module

I spent some time today, and realized that https://github.com/GoogleCloudPlatform/nodejs-docker/blob/9bf092153574f62b650f982d5505b8b9f3d83469/builder/steps/gen-dockerfile/contents/data/Dockerfile.txt#L5-L6 might be part of the puzzle. NODE_ENV=*********** in the log seems to be NODE_ENV= development. Because the other option "production" actually has one less "*". We will continue the investigation tomorrow.

Taking a closer look
if (packageJson.scripts) {
      hasBuildCommand = BUILD_SCRIPT_NAME in packageJson.scripts;
}

Do not include gcp-build in scripts should work...

Good point. I missed that first if statement in that template and thought it's always true. (Blaming the two COPY . /app/ statements in the template file https://github.com/GoogleCloudPlatform/nodejs-docker/blob/9bf092153574f62b650f982d5505b8b9f3d83469/builder/steps/gen-dockerfile/contents/data/Dockerfile.txt#L3 😏 .)
Yes, https://github.com/GoogleCloudPlatform/nodejs-docker/blob/93ded4fc7a62c4b491cad302b5d8fa8d489a8b49/builder/steps/gen-dockerfile/contents/src/detect_setup.ts#L213 is checking if string "gcp-build" is in the "scripts" property (https://classic.yarnpkg.com/lang/en/docs/package-json/#toc-scripts) of the package.json file.
I will try to reproduce this.

Okay, I triggered an error (not exactly the same yet), by changing my package.json file. This newly added "gcp-build" triggered the bug.
"scripts": {
"start": "node app.js",
"test": "mocha --exit test/*.test.js",
"gcp-build": "hello"
},
Kenneth's fix https://github.com/GoogleCloudPlatform/nodejs-docker/pull/258 looks promising to me.

Status update: we are releasing Kenneth's fix #258 .

Unfortunately #260 caused #261


Can't disconnect BLE devices when killing the app with background plugin on

I'm developing an app that interfaces with BLE devices.
Inside the app I can pair the devices and monitor their status.
If I close the app I want to disconnect the devices from the smartphone, and when I open it again, I want the app to reconnect automatically to known devices.
Everything works fine without using the background plugin, but I need to use it since the app needs to monitor the BLE devices even when it's in background.
The problem happens ONLY if I use the background plugin: if I open again the app, the known devices are not reconnected INSIDE the app, but it appears they are already/still connected to the smartphone from the previous time (even if not shown in the bluetooth devices in the phone settings).
It seems that the bluetooth connection to known devices isn't really being closed when I kill the app.
It appears like the device is still connected as therefore it doesn't show up when I scan in the app.
I can't reconnect until I close the app, switch off and then on again bluetooth, and reopen the app.
The steps are very simples:

I open and connect the first time from the phone to the BLE product
Communication is OK, data is sent and received
I close (kill) the application from the smartphone (Without turning off Bluetooth/BLE from smartphone)
I relaunch the application ---> Known device is not reconnected, but appears to be somehow still paired with the phone (if I press the pairing button it does not go into pairing mode, that happens if it is already bonded to a phone).

Why this behaviour? Looks like something in the plugin prevents the bluetooth connection to be closed on app closing. I specify that:

it only occurs using the background plugin, without it activated everything works ok
this behaviour occurs only with Android (don't use the background plugin for iOS)
It does happen only on some Android smartphones: tried three different phones, with Adroid version v4.4, v5.1.1 and v6.0.1, and only two of them show this issue (android version 4.4 on S3 and 6.0.1 on S5 Neo).

Thanks

After some testings, it appears that it is an issue caused by the Foregroundservice which doesn't close when I close the app.
I found out that forcing the closure of the app in the settings solve the problem, and when I open again the app everything works. I believe then that it is a problem of the service created by the background plugin, which is somehow not stopped when I swipe away the app.
I tried to add the stopWithTask = "true" in the Android Manifest in the service field, but this doesn't force the service to stop when I swipe away the app! How can this happen? Do you have any suggestion about that, or things I must be aware of when trying to close a service together with the app?
I also tried to add "onTaksRemoved" and call "stopService" inside, so that the service should be stopped when the activity is closed, but this does not work too.
Any idea why it behaves like this? How can I force the service created by this plugin to stop?
Can it be that the service is not "binded" to the app, and therefore it doesn't see the stopWithTask when I close the app?

This is maybe related to issue #246 and #262 try to change. The problem is this plugin set the launchMode singleInstance to the cordova activity.

@Albertazzi88 Thanks for your investigation. As I've only Samsung - did you manage to reproduce the issue with Samsung? I've hear about quite often that the service is still running however I am not able to reproduce that. Can you see in the logs that the service is still running or is the notification still present in the notification center?

@katzer yes, I've noticed it also on a Samsung S3 Neo and S5 Neo, they both have this problem.
From what I see, the notification is not present any longer in the notification center, but the problem persist.
The only way now is to make the app "crach" when I swipe it out using stopWithTask = "true" (don't know why it crashes anyway!), in this way everything is closed but an error message appear after the app is swiped out.
This is certainly not the best way to act.

I'm also seeing this in a similar fashion on a ZTE phone with Android 6.0: I'm writing an app that plays audio and should continue playing in the background. I enable background mode when the user starts playing audio and disable it when the audio stops playing.
If I kill the app from within the task list while my audio plays (hence: while the background mode is enabled), its GUI completely disappears, nothing indicates that the app is still running, but its audio keeps playing. The only way I found to get it to stop is to restart the app and kill it while background mode is disabled (it somehow seems to collect up the running player that went rogue...).

I am facing exactly the same issue here. Oneplus 3T Android 7.1.1
I am connecting to a BLE device and when I swipe the app away, the connection is still on for some reason. Next time I start the app, I am not able to connect to the BLE device because it's in a 'stuck' state.
A solution to this would be greatly appreciated.

I should also note that DavidWiesner's pull request did not help. The problem persists. I even tried installing from his fork.
There has to be a way to kill the service once the app is swiped away!

Hi all, since you are experts about BLE, ionic and Background, I have the following issue:
https://github.com/don/cordova-plugin-ble-central/issues/850
Any advise or pointer would be greatly appreciated, thanks a lot!


how to deploy latest version of parse server

I want to use new version of parse server. Could you please guide me regarding this?

I've just updated this to the latest version of the parse-server module, also updated more optional configs

I tried to deployed the new version. i am getting an error .Could you please guide me.
Error Details (Log)
Done uploading
OK
Starting app parse-on-bluemix-March in org 2Mee / space test as<EMAIL_ADDRESS>-----> Downloaded app package (4.0K)
-----> IBM SDK for Node.js Buildpack v3.2-20160315-1257
Based on Cloud Foundry Node.js Buildpack v1.5.4
-----> Creating runtime environment
NPM_CONFIG_LOGLEVEL=error
NPM_CONFIG_PRODUCTION=true
NODE_ENV=production
NODE_MODULES_CACHE=true
-----> Installing binaries
engines.node (package.json):  4.2.5
engines.npm (package.json):   unspecified (use default)
Downloading and installing node 4.2.5...
Using default npm version: 2.14.12
-----> Restoring cache
Skipping cache restore (new runtime signature)
-----> Building dependencies
Pruning any extraneous modules
Installing node modules (package.json)
WARN engine<EMAIL_ADDRESS>wanted: {"node":">=4.3"} (current: {"node":"4.2.5","npm":"2.14.12"})
><EMAIL_ADDRESS>install /tmp/staged/app/node_modules/parse-server/node_modules/gcloud/node_modules/hash-stream-validation/node_modules/fast-crc32c/node_modules/sse4_crc32
> node-gyp rebuild
make: Entering directory /tmp/staged/app/node_modules/parse-server/node_modules/gcloud/node_modules/hash-stream-validation/node_modules/fast-crc32c/node_modules/sse4_crc32/build'        CXX(target) Release/obj.target/crc32c_sse42/src/crc32c_sse42.o        AR(target) Release/obj.target/crc32c_sse42.a        COPY Release/crc32c_sse42.a        CXX(target) Release/obj.target/sse4_crc32/src/crc32c.o        SOLINK_MODULE(target) Release/obj.target/sse4_crc32.node        COPY Release/sse4_crc32.node        make: Leaving directory /tmp/staged/app/node_modules/parse-server/node_modules/gcloud/node_modules/hash-stream-validation/node_modules/fast-crc32c/node_modules/sse4_crc32/build'
<EMAIL_ADDRESS>node_modules/express
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>node_modules/cf-deployment-tracker-client
└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>node_modules/parse-server
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>└──<EMAIL_ADDRESS><EMAIL_ADDRESS>-----> Installing App Management
-----> Caching build
Clearing previous node cache
Saving 2 cacheDirectories (default):
- node_modules
- bower_components (nothing to cache)
-----> Build succeeded!
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>-----> Uploading droplet (29M)
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 down
0 of 1 instances running, 1 failing
FAILED
Start unsuccessful
TIP: use 'cf logs parse-on-bluemix-March --recent' for more information
Finished: FAILED
Stage has no runtime information
Stack information
2016-03-23T17:43:58.36+0530 [STG/0]      ERR
2016-03-23T17:44:05.94+0530 [STG/113]    OUT -----> Uploading droplet (29M)
2016-03-23T17:44:17.33+0530 [DEA/113]    OUT Starting app instance (index 0) with guid 6716d703-e3f6-4838-8dc5-94fcd2717e5e
2016-03-23T17:44:29.05+0530 [App/0]      OUT
2016-03-23T17:44:29.05+0530 [App/0]      OUT ><EMAIL_ADDRESS>start /home/vcap/app
2016-03-23T17:44:29.05+0530 [App/0]      OUT > node index.js
2016-03-23T17:44:31.78+0530 [App/0]      ERR
2016-03-23T17:44:31.78+0530 [App/0]      ERR /home/vcap/app/index.js:25
2016-03-23T17:44:31.78+0530 [App/0]      ERR   throw 'Please apply the Application ID from Parse.com';
2016-03-23T17:44:31.78+0530 [App/0]      ERR   ^
2016-03-23T17:44:31.78+0530 [App/0]      ERR Please apply the Application ID from Parse.com
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! Linux 3.19.0-25-generic
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! argv "/home/vcap/app/vendor/node/bin/node" "/home/vcap/app/vendor/node/bin/npm" "start"
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! node v4.2.5
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! npm  v2.14.12
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! code ELIFECYCLE
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR<EMAIL_ADDRESS>start: node index.js
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! Exit status 1
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR!
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node index.js'.
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! This is most likely a problem with the parse-on-bluemix package,
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! not with npm itself.
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! Tell the author that this fails on your system:
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR!     node index.js
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! You can get their info via:
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR!     npm owner ls parse-on-bluemix
2016-03-23T17:44:31.81+0530 [App/0]      ERR npm ERR! There is likely additional logging output above.
2016-03-23T17:44:31.82+0530 [App/0]      ERR npm ERR! Please include the following file with any support request:
2016-03-23T17:44:31.82+0530 [App/0]      ERR npm ERR!     /home/vcap/app/npm-debug.log
2016-03-23T17:44:31.89+0530 [DEA/113]    ERR Instance (index 0) failed to start accepting connections
2016-03-23T17:44:31.91+0530 [API/9]      OUT App instance exited with guid 6716d703-e3f6-4838-8dc5-94fcd2717e5e payload: {"cc_partition"=>"default", "droplet"=>"6716d703-e3f6-4838-8dc5-94fcd2717e5e", "version"=>"c491b53d-a407-45e2-9326-7c6733be64c1", "instance"=>"b6a8399c096144db90690abb9c1e19c4", "index"=>0, "reason"=>"CRASHED", "exit_status"=>1, "exit_description"=>"failed to accept connections within health check timeout", "crash_timestamp"=>1458735271}

I am resolve it .Thanks


Issue with "Visual Studio Code Extension" in @site/docs/concepts/vscode-extension.md

Describe the problem

Page: Visual Studio Code Extension
Source: https://github.com/demisto/content-docs/tree/master/docs/concepts/vscode-extension.md

The link in page (under Debugging section) " Read the Debugging using your IDE section" is broken.. Page not found.
Screenshots
Environment

OS: [e.g. Windows]
Browser: [e.g. chrome, safari, firefox..]
Browser Version:

Suggested fix

Closing as this was fixed by https://github.com/demisto/content-docs/pull/850


Create a signature SPI for Ed25519 and Ed448

This signature SPI should expose low level functionality and use the standard functionality from RFC 8032. This should have at least two core implementations: one based on BouncyCastle, and the other based on Java 15.

Generally implemented now in main.

Generally implemented now in main.


Use the new SDK within the api server

Fixes https://github.com/run-llama/llama_deploy/issues/337 https://github.com/run-llama/llama_deploy/issues/334

Use the new Client
Remove generic JSONResponses in favor of specific types
Consolidated the apiserver portion of the SDK: go lazy and stop pre-filling items when creating collections. Will remove the field in a subsequent PR.

coverage: 72.055% (-0.02%) from 72.076%
when pulling 6cc06d6e4d745de7f262d89193edbc3f93a1efa4 on massi/apiserver-sdk
into d7066e7457f782d26e9c1f74450d062310c97fe0 on main.


Add a type for complex input generation that performs exploratory testing

Description
In order to support testing patterns where randomized input generation is used to explore a program's state space (such as fuzz, differential, property-based, or mutation testing) we need to add some affordance to developers to specify the following:

The next value to pass into a @Test
A way to receive the prior value and test result as a result of executing @Test
A way to receive additional information, such as changes in code coverage, from the last @Test
A way to stop input generation based on some heuristic or predicate.

Having these 4 items would be the essential set of primitives to really streamline the creation of tools like QuickCheck, libFuzzer, etc. with Swift Testing.
Perhaps this could take the form of a protocol, potentially named TestCaseInputGenerator, that has the following shape:
protocol TestCaseInputGenerator {
    associatedtype AdditionalContext
    func shouldStop<InputType>(given priorRun: (InputType, TestResult)?, additionalContext: AdditionalContext?) -> Bool
    func nextValue<InputType>(given priorRun: (InputType, TestResult)?, additionalContext: AdditionalContext?) -> InputType
}

AdditionalContext can encapsulate data of interest to the test; previously tried values, their results, and other data like code coverage, crashes, etc.
I'm filing this issue rather quickly, in between tasks, so apologizes in advance for oversights on the type signatures and compilability of the proposed API. :)

There doesn’t seem to be an awful lot of interest in this feature - let me know what I can do to help? I’ve been working (very slowly) on a hedgehog port. The types of things I’d be looking for are:

Top requirement is suppressing expectation failures - generally for property based tests you may have hundreds of failures but you only want the minimal failing case reported; the rest is noise
It’s not clear how/if test runs can be parallel. Ideally the root level tests would run in parallel, but shrinks should be tested sequentially
Unsure whether variadic inputs would be supported? Vanilla parameterised tests appear to only support up to two arguments, but this restriction may not be as applicable to property tests which don’t attempt all combinations
Reporting output: I assume the relevant info would need to be shoehorned into the existing issue reporting process - it looks like it should work, but for reference, the typical output is:

Passed: number of (root) tests
Failed: number of tests, number of shrinks, input value(s), failure description (ie expectation failure narrative), seed/path info to reproduce the test. Inputs & failures should be catered for, the rest may need to go to stdout?

Most libraries also have a verbose option that logs out inputs for all tests run, this could potentially be recorded the same way as the current parameterised test runs, although the number of sub-tests is potentially large.
An alternative approach may be some sort of test interceptor or embedded runner that can receive, filter, modify & generate test events/issues within its test context - this is the workaround I ended up using for XCTest support. I don’t think this would be as well-integrated into swift-testing overall but would be more flexible and may be simpler to implement.

Just want to put myself forward - would be interested in helping out with adding property (randomized) tests to swift-testing in case there's a demand for it.
Some credentials: I've previously implemented such test runner for SerenityOS in C++ and am the maintainer of the official property testing library for the Elm language (reimplemented it from the hedgehog-like RoseTree approach to the Hypothesis-like approach).

We're starting to plan out what we want to do for the next major Swift release. This is on our spreadsheet, although I don't know if we've assigned any particular priority to it. It would help to get some more information about your use cases @samritchie @Janiczek. 😄

Thanks @grynspan, the very high level use case is that there’s nothing equivalent currently available for Swift except for SwiftCheck, which still works but is largely unmaintained since Robert moved to Apple.
Would the plan be to integrate a standard random testing feature, or provide extension points to support third party frameworks like Sean suggested in the original issue? There’s value in terms of simplicity/adoption/availability/acceptance to have a builtin feature, but this would end up blocking alternatives and needs to be well designed & targeted.
If the goal is extension points & third party frameworks, my comments above still stand - however it’s probably worth finishing the hedgehog port and using it in a couple of projects, and then looking at how swift-testing integration could make it better. I have struggled a bit with time & motivation - @Janiczek I’d be happy to team up on this if you’re interested? I’ve used Elm Fuzzer before and I like that approach as well.

Nice to see this is somewhere on the docket for a future Swift Testing. Getting harness support in the framework would certainly go a long way towards getting this functionality out the door. I want to also enumerate some yet-to-be-done work in other components outside of this library to really make this feature great:
libFuzzer's Library Support is Severely Lacking
libFuzzer is very much a batteries-included library. It was designed with the idea that you link your (ostensibly C[++]) program with their fuzzing runtime and they'll give you a main that initializes their framework and calls into a very narrow set of callbacks - to my knowledge this is LLVMFuzzerInitialize, LLVMFuzzerTestOneInput, and recently LLVMFuzzerCustomMutator. At time of writing, the first and last of these are not even documented by libFuzzer yet!
Another spot of trouble is the fuzzer runtime very much assumes that you are trying to crash the program under scrutiny. And while, at this time, Swift Testing does have experimental support for death tests, it's still a deficiency in the fuzzing model that you cannot e.g. reject a particular buffer as being incorrectly shaped for the task at hand. Coupled with the fact that libFuzzer can also be used in a coverage-guided manner, this means we may not actually wind up using the framework to its fullest extent! Which is to say, libFuzzer's approach is much smarter than just generating random blobs of data. It actually wants to try to explore its way through the state space of your programs. And if all we wind up doing is just asking libFuzzer to generate a buffer so we can store it off in a collection, or return some data as part of a protocol requirement that mutates and generates the next test case, all of the actual code that libFuzzer actually cares about in the test case is completely invisible to it!
Finally, while it does have a "bring your own driver mode" that forgoes the fuzzing runtime defining main for you, in practice what that means is literally just that.
Property Testing
How about property testing then? SwiftCheck certainly isn't trying to read code coverage data, and it would appear that it makes a better candidate for the mutation-at-a-time model Sean sketched above since you can just pump its Generators into a Collection. However, I still think the sketch above is missing support for a primitive at the heart of this class of frameworks: shrink. The *Check frameworks don't just want to mutate data, they want to try to isolate a minimal reproducing test case from the results of failing property tests. I'm sure there's a way to add a shrink-style requirement to Swift Testing, I just don't know if that then implies that you have to go import basically the entire QuickCheck execution model into the framework as well.


Slack link updated

Fixes https://github.com/containerd/containerd.io/issues/34
Signed-off-by: Ihor Dvoretskyi<EMAIL_ADDRESS>

cc @lucperkins @estesp

LGTM

Keeping the current one for now as we have over 700 ppl in the channel


Braket nb

This notebook is a bit untidy at the moment, hence I've made it a draft for now. I'm not sure what is/is not helpful to include in a notebook like this.
If this isn't the right place for a notebook example then I'm happy to remove it.

Currently I think the right place for this would be https://github.com/CQCL/pytket/tree/main/examples .
This will require adding pytket-braket to the requirements there, checking in a corresponding python file, and updating check-examples.
Alternatively it could live in an examples repo here, but should have some kind of test, preferably on the CI,

Braket moved over to https://github.com/CQCL/pytket-braket, please reopen the PR at the new repo. If you need help, please let me know.


Kebab-case instead of snake_case

The functions in this package have snake_case names:
compact_diff, LCS_length, traverse_balanced, traverse_sequences.
I think it is better if those functions are with kebab-case.
Alternatively, we can have kebab-case synonyms.
I do not feel very strongly about this, but since this package is re-adopted, I think this is the right time to change those names.

I think this functionality needs a more thorough reconsidering using Raku features, rather than being a port from Perl.  Such a new approach could use kebab-case.  So closing this now.


Flickering when I have a window(CDialog) that constantly updates

i've a game that couldn't draw the backgrounds properly, so I put ddrawcompat.dll and now draw the background perfectly. The problem is that in the menu I have a map (it is a dialog window) it's there to catch mouse events because you can move around the map, well the problem is that the map flickers all the time. Flick between the map and a black color, and it doesn't follow any pattern (it doesn't change every x frame or anything like that)

And what game is it? It's hard  to say anything with this little info.
If the window is constantly making itself topmost, then that might interfere with the borderless fullscreen handling of DDrawCompat. Check if FullscreenMode=exclusive helps in the Configuration.


Postgres DB backend

Currently we use just an SQLite backend. However it might be a good idea to add Postgres support so that we can integrate into a larger deployment easily.

The rough steps for this are

Create Postgres specific migrations
Add a feature flag to specify to use Postgres
Alter code to be either generic or gated with the feature flag
Update configuration systems


⚠ Mobitopup has degraded performance

In dd1a62c, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 9809 ms

Resolved: Mobitopup performance has improved in f03394a after 8 minutes.


Run pyHYDRA without covariate_tsv

Hi. While running pyHYDRA without covariate_tsv, an error appears at the base.py line which normally reads the covariates file. From the error message 'ValueError: Invalid file path or buffer object type: <class 'int'>', I think it tries to read the covariates file but there is no such file. I attach a screenshot. Thank you.

Hi, n_threads is an optional argument (so does covariate_tsv). You gave it as mandatory. That's why pyHYDRA take n_threads as covariate_tsv, leading to your ValueError.
Thanks

Great, thank you!


update colosrchemes

pablo: fix 8c invisible comments
quiet: fix EndOfBuffer and Directory background colors (set to NONE)
lunaperche: add syntax overrides for cs, java, rst; make comments a stronger blue, make light close to dark wrt using colors (strings are yellowish for both now).

I'll include this, thanks.


Update sbt-github-actions to 0.13.0

Updates com.codecommit:sbt-github-actions from 0.12.0 to 0.13.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (0.12.0).
You might want to review and update them manually.
generic-extras/src/main/scala/io/circe/generic/extras/encoding/package.scala
generic-extras/src/main/scala/io/circe/generic/extras/semiauto.scala

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.codecommit", artifactId = "sbt-github-actions" } ]

labels: sbt-plugin-update, semver-minor, old-version-remains

Codecov Report

Merging #171 (6987dab) into master (91b086d) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #171   +/-   ##
=======================================
  Coverage   84.04%   84.04%
=======================================
  Files          19       19
  Lines         282      282
  Branches        6        6
=======================================
  Hits          237      237
  Misses         45       45

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 91b086d...6987dab. Read the comment docs.


Problem: test_matchparen not run in CI

Problem:  test_matchparen not run in CI
Solution: add test_matchparen.res to NEW_TESTS_RES in Makefile,
update changed highlighting dump from v9.1.61

OK so we now have different cursor position based on compiled features. That doesn't seem right for this test, I'll try to look into it.

yes, let's just update the test with the changed cursor positions.


Add pytest based nodetest

This brings install and upgrade testing up to parity with the bash based
version. Reorganize the testnode code into a module instead of
one large file. Finally fixed linting as well.

A few points for 2021 us:

These don't run on EC2 probably due to a weird bug with LXD.
Timeouts seem a bit low, e.g. my laptop can't bring up DNS in time.
Docker is not running inside the LXD container so tests fail on docker pull.

I've added a global test coefficient. I have no idea what was going on with that EC2 instance, but I suspect the current bash scripts fail in the same way since spin up LXD containers with this same profile and install the same snaps.
I don't follow the docker issue though, I don't experience that. I think you might be hitting a snap in lxd on zfs issue. If you can reproduce but I don't hit that particular issue.
I do wonder if some of the timeouts should be increased for individual things that are being cut a little to close. I was setting these based on passing on my laptop but it was just a starting point. We should play with global vs individual tests to land them wherever seems the most appropriate.

I've added a global test coefficient. I have no idea what was going on with that EC2 instance, but I suspect the current bash scripts fail in the same way since spin up LXD containers with this same profile and install the same snaps.
I don't follow the docker issue though, I don't experience that. I think you might be hitting a snap in lxd on zfs issue. If you can reproduce but I don't hit that particular issue.
I do wonder if some of the timeouts should be increased for individual things that are being cut a little to close. I was setting these based on passing on my laptop but it was just a starting point. We should play with global vs individual tests to land them wherever seems the most appropriate.

With the last push all tests are passing again for me, try the environment variable to adjust timeouts and see if this runs for you now @joedborg

With the last push all tests are passing again for me, try the environment variable to adjust timeouts and see if this runs for you now @joedborg

@chris-sanders https://github.com/ubuntu/microk8s/commit/466df0a2f7d9ab345f8818009632d395197842f0 needs merging into this PR

@chris-sanders https://github.com/ubuntu/microk8s/commit/466df0a2f7d9ab345f8818009632d395197842f0 needs merging into this PR

@joedborg added

@joedborg added


Volume OSD not hidden, but it dissapears quicker with keyboard control. Not at all with slider.

I'm on the LG 5k2k monitor, and the "hide OSD" checkbox doesn't function as intended for the native volume OSD. Enabling it forces the window to close more quickly, which is better, but it still flashes up. Meanwhile, the volume slider in the taskbar activates the OSD as normal - that is, it comes up and persists for several seconds after the volume is adjusted. It would be better if that were hidden, too.
P.S. MonitorControl is amazing and I really appreciate all the work put into it.

I have the same issue on my monitor. It's not perfect yet hence why it's in Advanced Prefs. Figured it would still be better to put it in there since it does help. But thanks for opening the issue.
Might look into it in the future or if anyone else wants to open a PR and fix it, feel free ;)

@JoniVR: FWIW, this is quite easy to implement, but I'm wary about the method by which the OSD is being hidden (that is, writing 0x01 twenty times consecutively to the 0xca DDC command).
On my monitor that doesn't automatically show the display OSD when writing DDC commands, setting this value once seems to be indefinite until you set it back to 0x02 (OSD enabled).
I do have access to a monitor that exhibits the auto-showing OSD behavior but it's not at my house, so I won't be able to get to this for testing until at least Friday.
The command set for 0xca can be found on page 64 of the VESA MCCS Standard (https://milek7.pl/ddcbacklight/mccs.pdf).

I tested the required change to make the display OSD hide upon changing slider values both independently and as part of my changes in #134, and they both seem to work fine.
Hitting the display 20 times with the hide OSD command causes the movement of the slider to become pretty rough. I removed the 20x repeat and it was a lot smoother, plus it still worked as intended.
If there wasn't a specific reason for repeating the command 20 times, I'd advocate for removing the repetition.
I've put up PR #147 to handle both changes.

Any updates to post here? I checked into #134 and #147 but nothing was ever built into a release.

Will this be included in the next release?

I think both of the pull requests still contain some issues that need to be fixed but there hasn't been any activity on either one of them lately.

I think both of the pull requests still contain some issues that need to be fixed but there hasn't been any activity on either one of them lately.

PR #147 was supposed to be superseded by @reitermarkus's PR (#152), but there were still unresolved issues I was waiting on changes for so I could re-test it.
#147 can probably be declined at this point.

Chiming in on this one. I have an LG Ultrawide that I can do some testing on if it would help.

Do we know if there is any way to just suppress ALL native OSDs? The LG also has a 'HDR' popup whenever it turns on that is also annoying and unnecessary.

Do we know if there is any way to just suppress ALL native OSDs? The LG also has a 'HDR' popup whenever it turns on that is also annoying and unnecessary.

Any ideas on this? I'd be happy to work on this but I'm not sure where to start.

There is a way provided in DDC.swift, it only works properly by sending it multiple times in short succession though. It worked previously for the shortcuts but I don't think it's feasible to implement for the slider as it would just spam the monitor too much and cause lag.

The flickering of the OSD is still persistent in 2.1.0.

Hi, the Hide OSD function was removed form the app due to numerous complaints. There is an option instead to disable tha macOS volume OSD so you don't have two overlaying OSDs. I know this is not a perfect solution but it come to this due to technical limitations. I'll close this issue for now. Thank you for your understanding!

Is there an option to have the volune buttons increase/decreases volume by
1/100 units instead of 6.5 units per click? Even 3 units per button press
would be nice.
On Sat, Aug 21, 2021 at 12:17 PM waydabber @.***> wrote:

Hi, the Hide OSD function was removed form the app due to numerous
complaints. There is an option instead to disable tha macOS volume OSD so
you don't have two overlaying OSDs. I know this is not a perfect solution
but it come to this due to technical limitations. I'll close this issue for
now. Thank you for your understanding!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MonitorControl/MonitorControl/issues/136#issuecomment-903139514,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMSQ5BK6YJDIDXKFWJQTTT57GPVANCNFSM4I4QV36A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.


Using Mongolab, saving regular parse objects produces : MongoError: exception: Btree::insert: key too large to index, failing

Parse hosted server runs fine.
I'm in the process of migrating my server and now I receive this error when saving an object:
(XXXXX are keys I've obfuscated for this post...)
 MongoError: exception: Btree::insert: key too large to index, failing test_parse_server.RefFollowerUser.$_p_follower_1__p_user_1 1622 { : "_User$ilnDsp7JHh", : { lastActive: new Date(1456266521816), searchable: { __type: "Pointer", className: "Searchable", objectId: "szd8JUJG89" }, googleLogin: false, facebookLogin: true, nickname: "XXXXX", searchPhrase: "XXXXX", username: "3379hGpzOxdwSClGdXun8O8Z2", updatedAt: new Date(1456266527688), email<EMAIL_ADDRESS>authData: { facebook: { access_token: "XXXXX", expiration_date: "2016-04-21T14:04:11.000Z", id: "XXXXX" } }, privateProfile: false, createdAt: new Date(1421380522173), profilePicture: { __type: "File", name: "tfss-c34ad0d3-51fd-49c6-94d5-799c5ffd9a7d-file", url: "XXXXX" }, followersCount: 175, emailVerified: false, twitterLogin: false, shoutsCount: 73, gender: "male", coverUrl: "XXXXX", state: 1, enc: { __type: "Pointer", className: "UserEnc", objectId: "MJO7pdkj96" }, photoUrl: "XXXXX", countryCode: "il", hideSuggestions: true, socialId: "XXXXX", shouldSentJoinNotification: false, rank: 100, objectId: "yEVzdLRHgu", __type: "Object", className: "_User" } }
    at Function.MongoError.create (c:\PROJECTS\shout-server\shout-server\node_modules\mongodb\node_modules\mongodb-core\lib\error.js:31:11)
    at commandCallback (c:\PROJECTS\shout-server\shout-server\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:929:66)
    at Callbacks.emit (c:\PROJECTS\shout-server\shout-server\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:116:3)
    at messageHandler (c:\PROJECTS\shout-server\shout-server\node_modules\mongodb\node_modules\mongodb-core\lib\topologies\server.js:282:23)
    at Socket.dataHandler (c:\PROJECTS\shout-server\shout-server\node_modules\mongodb\node_modules\mongodb-core\lib\connection\connection.js:273:22)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

This is due to large indexed documents. On Parse.com we use the failIndexKeyTooLong=false option in Mongo however that will cause documents to not get indexed, so if you can, we recommend you change your db structure to reduce the size of your documents.

Yes, I've read about this just now.
So I can't set this on mongoLab I guess..
How can I reduce?
My DB isn't big at all. What am I supposed to reduce?
count of objects per table?
column count?
Please be as specific as possible. this migration is a pain in the ***.

Its not the size of the db, it's the size of the parse object. Your parse object looks like it has a lot of columns, so I'd suggest splitting it into two objects in separate classes that are connected via a pointer. You may also be able to just delete the indexes you aren't using.
MongoLab does allow you to change this parameter on some database types, I believe, although that may not include any of the free ones.

Oh.
I'll try splitting this table.
Is the data itself an issue?
Meaning if I had only one column but one value was big amount of text, was this also a problem?

Yes, that is also a problem. It would be same problem if you have one column that contained a very large array.

Ok I think I figured out the problem.
for some reasons, in cloud code:
if I get an object by it's ObjectId and then set it to the reference field of other object it duplicates the object put it in the reference field instead of just setting it's reference (the android API works ok).
here's my code  (user is from request.object, shoutUser is the one i'm getting with query and "get"):
`var userQuery = new Parse.Query('_User');
userQuery.get("4GJ9QWcecT", {useMasterKey: true})
.then(function (shoutUser) {
                    var RefFollowerUser = Parse.Object.extend("RefFollowerUser");
                    var refFollowerUser = new RefFollowerUser();

                    setACLIfNull(refFollowerUser);

                    refFollowerUser.set("user", shoutUser);

                    refFollowerUser.set("follower", user);

                    return refFollowerUser.save(null, {useMasterKey: true});

                });

`

That sounds like a different problem. Could you open a separate issue for that?


Is there a way to dockerize this?

Is there a way to use this as a docker container, so its an easy install?

there isn't. the plan long term is to offer an image of the lxc container for easier install. for additional information including why docker was a bad choice for this project, please watch this video: https://youtu.be/SD4KgwdjmdI

there isn't. the plan long term is to offer an image of the lxc container for easier install. for additional information including why docker was a bad choice for this project, please watch this video: https://youtu.be/SD4KgwdjmdI


CI: SITL test run: select ROS version based on ROS_DISTRO

As we introduce SITL testing on Melodic this is important as we'll have Kinetic at the same time.

Working on updating images to support this --> https://github.com/PX4/Firmware/pull/11606

rebased

Why not set the distro based on the OS distro?

This is a good idea, but I see issues with it. It would be fairly trivial if we assume this will only be used with Ubuntu. We could run something like lsb_release -sc and set it based on that. The problem is the assumption. To actually test for the users OS and set this appropriately, we need to consider Debian, Arch, and so on. I don't want to claim we're checking the distro and don't actually check for all the flavors compatible with Kinetic and Melodic respectively. So, I'd rather just fall back to the default ROS version supported in our CI system.

Check this example: https://github.com/PX4/px4_ros_com/blob/master/scripts/setup_system.bash

Check this example: https://github.com/PX4/px4_ros_com/blob/master/scripts/setup_system.bash

That's exactly what I said we could do. I don't want to assume that everyone only uses Ubuntu.

Check this example: https://github.com/PX4/px4_ros_com/blob/master/scripts/setup_system.bash

That's exactly what I said we could do. I don't want to assume that everyone only uses Ubuntu.

ROS officially support Ubuntu and Debian. Both Ubuntu and Debian support the lsb-release commands. The support for Arch, Gentoo, etc. for ROS is experimental, though it's also possible to verify the release version of them. In the end, I think what matters is what platforms we want to support based on where ROS can run (officially). Am I wrong to assume that?

There's nothing wrong with your statement. It's just beyond the scope of what I was going for here. I was only trying to dynamically source the correct ROS setup for CI purposes as stated in the title and the original post. I still think the default matching what is officially used for testing is fine as it is only used for that purpose. If users want to run this on their own machine, they should have already sourced the correct setup script for their environment as defined in the installation instructions for ROS. If users run this inside the px4 docker container the environment variable will be set. I don't see any issues with this as is.

Good enough for now. We can continue to generalize further.


Setting font size big breaks layout.

When setting font and display size to maximum not all text is readable. Tested on pixel 6

Which app version? I've tested with 6.0.0 and it seemed fine, can you provide more details?

I am also using 6.0.0, i just now realise that you can scroll sidways on the main screen


Docker container actions and service containers only work on 'ubuntu-latest'

replaced "ubuntu-latest image" with "ubuntu images" in the phrase
Note: If your workflows use Docker container actions or service containers, then you must use a Linux runner:

If you are using GitHub-hosted runners, you must use the ubuntu-latest runner.

See https://docs.github.com/en/free-pro-team@latest/actions/guides/about-service-containers#about-service-containers
Pay attention the is a reused data and blue block is to be changed across the whole documentation set.
The related issue: https://github.com/actions/virtual-environments/issues/1624
Check off the following:

[ ] All of the tests are passing.
[ ] I have reviewed my changes in staging.
[x] For content changes, I have reviewed the localization checklist
[x] For content changes, I have reviewed the Content style guide for GitHub Docs.

LGTM
some context: Docker-Moby recently added support of Ubuntu-20.04 so now it is correct to say that Docker container actions or service containers can be used on all Ubuntu images.

Thanks for opening a PR @dsame! I'll get this triaged for review ✨

__


Phone: Skip the "Place Earth" step if not on a holographic platform

Hi @timGerken, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Tim Gerken). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Skip the "Place Earth" step if not on a holographic platform


Is it possible to change the styles of a NavLinkButton on individual instances or global default?

Hello again!
AppBar.scala has NavLinkButtons for authenticated and unauthenticated states, and you pass in the path, link text, and onClick.
But I don't see a way to override the default styles in package net.wiringbits.webapp.utils.slinkyUtils.components.core.widgets NavLinkButton.
E.g., let's say I wanted to change the color of the links to #0074bf with .setColor("#0074bf")

.setColor("inherit")

I found this at the NavLinkButton component, hence, the component will inherit the color from its parent, I'd try setting the color on AppBar.scala, you could try creating a div with your desired color, hopefully, this will work.


Cargo Arbitrage Episode Morbillion - Sec techfab

Description

The .35 ammo is worth more than the metal it's made with.
Reproduction

Get the HoS/warden to give you their secfab.
Put steel in it
Print money

Security is gonna regret doing this when antags are in cargo

Warop nukies when sec moves their fab to cargo, sells ammo, and station is armed with laser raptors and thronglers:

Isnt there like, an ammofab, that salvages can earn in expeditions or smth?

yes but the issue is the bullet pricing

Resolved by #23698.


feat: initial setup for ts

https://github.com/lightbend/akkaserverless-framework/issues/689

@pvlugter @jroper based on the discussion here, I was trying to add a basic TS support to the SDK.
My idea was the following:

make the whole package TS based with the minimal amount of effort
try to generate the .d.ts files with the help of the TS compiler based on the existing JSDocs
gradually extend the JSDocs where the types are missing or not correct

I've faced with the following issues:
I got a couple of TS errors, but I could fix those by removing/adding some parts of the JSDoc (just to make things work).
After that I could create a package locally with npm pack and use this package in a simple TS project, where I got intelli sense for the EventSourcedEntity:

As you can see here:

unfortunately almost all the types had been inferred to any and the namespace declarations are also pretty weird.
I think the reason for this is that TS can't handle the module declarations and references (like @memberOf module:akkaserverless or module:akkaserverless.EventSourcedEntity~options=), that's why the whole type inference stops at first JSDoc comment (~commandHandler) and almost everything becomes any.
I was also trying to use the tsd-jsdoc tool instead of the built in TS compiler to generate the types, but it was failing with these kind of errors:
╰─$ node_modules/.bin/jsdoc -t node_modules/tsd-jsdoc/dist -r src/. -d gen_types                                                                                127 ↵
[TSD-JSDoc] action.js:73:0 Failed to find parent of doclet 'module:akkaserverless.Action' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] action-support.js:119:2 Failed to find parent of doclet 'ActionHandler#invokeCallback' using memberof 'ActionHandler', this is likely due to invalid JSDoc.
[TSD-JSDoc] action-support.js:135:2 Failed to find parent of doclet 'ActionHandler#passReplyThroughContext' using memberof 'ActionHandler', this is likely due to invalid JSDoc.
[TSD-JSDoc] action.js:73:0 Failed to find parent of doclet 'module:akkaserverless.Action' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] akkaserverless.js:56:0 Failed to find parent of doclet 'module:akkaserverless.Server' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] akkaserverless.js:56:0 Failed to find parent of doclet 'module:akkaserverless.Server' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] akkaserverless.js:84:0 Failed to find parent of doclet 'module:akkaserverless.Entity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] akkaserverless.js:98:0 Failed to find parent of doclet 'module:akkaserverless.AkkaServerless' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] akkaserverless.js:98:0 Failed to find parent of doclet 'module:akkaserverless.AkkaServerless' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] cloudevents.js:17:0 Failed to find parent of doclet 'module:akkaserverless.CloudEvent' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] command-helper.js:249:4 Failed to find parent of doclet 'module:akkaserverless.EntityContext' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] command-helper.js:258:4 Failed to find parent of doclet 'module:akkaserverless.EffectContext' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] command-helper.js:266:4 Failed to find parent of doclet 'module:akkaserverless.CommandContext' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] event-sourced-entity.js:100:0 Failed to find parent of doclet 'module:akkaserverless.EventSourcedEntity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] event-sourced-entity.js:100:0 Failed to find parent of doclet 'module:akkaserverless.EventSourcedEntity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] integration-testkit.js:44:2 Failed to find parent of doclet 'IntegrationTestkit#addComponent' using memberof 'IntegrationTestkit', this is likely due to invalid JSDoc.
[TSD-JSDoc] metadata.js:27:0 Failed to find parent of doclet 'module:akkaserverless.MetadataValue' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] metadata.js:34:0 Failed to find parent of doclet 'module:akkaserverless.Metadata' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] protobuf-any.js:39:0 Failed to find parent of doclet 'module:akkaserverless.SerializableProtobufMessage' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] protobuf-any.js:48:0 Failed to find parent of doclet 'module:akkaserverless.TypedJson' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] protobuf-any.js:57:0 Failed to find parent of doclet 'module:akkaserverless.Serializable' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] index.js:31:0 Failed to find parent of doclet 'module:akkaserverless.replicatedentity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] ormap.js:182:2 Failed to find parent of doclet '{module:akkaserverless.replicatedentity.ORMap#get}' using memberof '{module:akkaserverless.replicatedentity.ORMap', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:34:2 Failed to find parent of doclet 'Reply#addEffect' using memberof 'Reply', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:45:2 Failed to find parent of doclet 'Reply#addEffects' using memberof 'Reply', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:56:2 Failed to find parent of doclet 'Reply#isEmpty' using memberof 'Reply', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:81:0 Failed to find parent of doclet 'module:akkaserverless.replies' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:93:2 Failed to find parent of doclet 'ReplyFactory#message' using memberof 'ReplyFactory', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:106:2 Failed to find parent of doclet 'ReplyFactory#forward' using memberof 'ReplyFactory', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:120:2 Failed to find parent of doclet 'ReplyFactory#failure' using memberof 'ReplyFactory', this is likely due to invalid JSDoc.
[TSD-JSDoc] reply.js:133:2 Failed to find parent of doclet 'ReplyFactory#noReply' using memberof 'ReplyFactory', this is likely due to invalid JSDoc.
[TSD-JSDoc] value-entity.js:74:0 Failed to find parent of doclet 'module:akkaserverless.ValueEntity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] value-entity.js:74:0 Failed to find parent of doclet 'module:akkaserverless.ValueEntity' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] view.js:59:0 Failed to find parent of doclet 'module:akkaserverless.View' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.
[TSD-JSDoc] view.js:59:0 Failed to find parent of doclet 'module:akkaserverless.View' using memberof 'module:akkaserverless', this is likely due to invalid JSDoc.

For me it looks like that similar to the TS compiler, it has some problems with the module definitions.
At this point I am pretty stuck, because I am not sure how could we reuse the JSDoc comments to generate the TS types, on the other hand as @jroper mentioned starting from scratch would be a lot of work.
It would be nice, if we could find some time to discuss this issue in person or maybe even do some pair programming.
What do you think?

I don't know about TypeScript or JSDoc. It looks like there are a few open issues for TypeScript around namespaces and @memberOf, so it may not be possible. I think it's worthwhile seeing if there is an alternative or better way to structure comments so the types can be derived. Maybe discuss with @johanandren (for same time zone in person chat) to figure out approach going forward?

@RoryStokes Do you have any thoughts about this? https://github.com/lightbend/akkaserverless-javascript-sdk/pull/16#issuecomment-853099397

adding @katsutoxin to the loop as well

@janory , have you tried this solution?  https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html

@janory , have you tried this solution? https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html

If the above solution does not work, you can also try this https://github.com/Microsoft/dts-gen

@janory , have you tried this solution? https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html

Yes, this is the solution what we have in this PR, I think the other solution is just same like what the TS compiler does, it's just extracted to a tool from the compiler.

@janory , have you tried this solution? https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html

Yes, this is the solution what we have in this PR, I think the other solution is just same like what the TS compiler does, it's just extracted to a tool from the compiler.

Hi @janory ,  dts-gen is a totally different solution, usually people use it when compile solution not working.  It simply examines the objects as they appear at runtime, rather than needing the source code that creates the object.
Here is a demo video for how to use dts-gen https://www.youtube.com/watch?v=ShargpxE1Xs

Closing this PR and moving on with issue here.

Closing this PR and moving on with the issue here.

@janory , have you tried this solution? https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html

Yes, this is the solution what we have in this PR, I think the other solution is just same like what the TS compiler does, it's just extracted to a tool from the compiler.

Hi @janory , dts-gen is a totally different solution, usually people use it when compile solution not working. It simply examines the objects as they appear at runtime, rather than needing the source code that creates the object.
Here is a demo video for how to use dts-gen https://www.youtube.com/watch?v=ShargpxE1Xs

fyi @katsutoxin I could eventually move on with the JSDoc -> .d.ts generator, but thanks for the tips and support! 👍 :)


Fix derived with byte ids

Invalid after removing derived fields from entities and implementing loadRelated. Will cherry-pick the last commit in a separate PR


[RFC]: production-setup: add net.core.bpf_jit_limit and kernel.keys.m…

…axbytes
/* kernel.keys.maxbytes */
When all containers share the same id mapping they will share a keyring. But
since each container will get their own session key it will be appended to the
keyring which will thus grow quite large. Thus the limit needs to be bumped.
/* net.core.bpf_jit_limit */
When running a kernel on which has /proc/sys/net/core/bpf_jit_enable set to a
value other than 0 then seccomp will make use of the eBPF JIT compiler so each
container's seccomp filter will be charged against the eBPF JIT limit. Thus the
limit needs to be bumped significantly. Note that a lot of kernels have
CONFIG_BPF_JIT_ALWAYS_ON=y set as a hardening feature which means the
bpf_jit_enable value can't be changed to anything else and will be fixed at 1.
Cc: Tobias Schüring<EMAIL_ADDRESS>Signed-off-by: Christian Brauner<EMAIL_ADDRESS>

@stgraber we need to decide on reasonable limits for these two new keys. That's why it's RFC.

So we usually try to have a clean Ubuntu system be able to run 100 LXD containers.
I suspect that for production-setup, our aim should be 1000 containers.
Quite a few of the limits are effectively 8x or 10x the default for that reason. A few are bumped even further due to things like routing table entries growing quite a bit faster than linearly in production environments.


nav-justified not working within navbar

Hello,
It seems like nav-justified and nav-fill are not working together with navbar.
Example: https://jsfiddle.net/wq16antm/
Tested with Chrome 56.0.2924.76 on Ubuntu 16.04
The Bootstrap justified-nav example (http://v4-alpha.getbootstrap.com/examples/justified-nav/) seems to be pretty broken as it is permanently collapsed (shouldn't the whole toggle-stuff disappear when the screen is big enough?).
I just want justified pills within a fixed-top navbar collapsing at medium level...

@bardiharborow - I have been able to reproduce this, as well.
if you change from the ul/li schema for navs, and instead just use anchor tags like IMPORTANT STUFF, the justification and fill classes work within navbar.  BUT if you do make this switch, then ScrollSpy doesn't work.
I'm looking for related bugs for both of these issues, now, before I open one.

Fix for the justified navbar example is coming in #22230. It'll make use of the .nav-justified modifier, but also require .w-100 because of the flex sizing.

The need for .w-100 to get this to work should be in the docs, no? I just ran into this.

Agreed with zfrenchee.  Also noticing when using the w-100, once page is collapsed, the ul/li in the navbar still list horizontally instead of adjusting to vertical list


feat: Apply latest 1.2 working draft

Original: https://github.com/A11yance/aria-query/pull/46

Closing in favor of  #4


Translate LayoutFooter and LayoutHeader

You're welcome, It was a pleasure , if you need anything else just let me know.


Mobile + WebGL exhibits some shader issues.

Low roughness values causes strange rendering on my Pixel 2, it looks similar to the screenshot reported by Eric:
https://twitter.com/RaptorDeVitesse/status/1040050253548777473

Hm, the term computed by D_GGX_Anisotropic is what's blowing up here.
Anisotropy is zero but the code path is enabled because it uses the existing sandboxLit material.

Small values of at and ab (e.g. when they hover between MIN_LINEAR_ROUGHNESS and 0.1) cause the aforementioned term to blow up on WebGL Mobile.

I'll try on Android see what happens. It's surprising this computation wouldn't work, I've implemented it in WebGL directly before and successfully.