create-react-app is not offering suggestions/guideline for managing environment specific configuration

Is your proposal related to a problem?
The react applications created by "create-react-app" does NOT provide a opinion on how to handle environment specific configuration.
I had joined 3 different react projects in the recent years, and I found the way they handled environment specific configurations in not the best way.
When building application we often have to deploy in multiple environments such as dev, staging and production. Some times instead of one production we might prod-cust1, prod-cust2, etc...
React is NOT offering any suggestions or guidelines how to manage environment specific configuration file.
Angular is offering this suggestion https://angular.io/guide/build
The suggestion offered by Angular is less than optimal.
Many developers are adopting an approach similar to Angular approach for configurations
The problems in Angular approach is

The code and the configuration is not separated (this is against the guideline of 12 factor app)
When we decide to deploy the application in a new environment, we have to create a new environment file.
It also doesn't help Build Once Deploy Anywhere

Describe the solution you'd like
Modify "create-react-app" to the following when called with --with-config

Have the configuration file named environmentConfig.js in the public folder and add it as script in index.html
Have a file named Config.js that exports config by assessing window.config
This will make it easy to externalize config and dockerize the application

Reference:
https://github.com/ZeroWasteTeam/SampleReact
Describe alternatives you've considered
The app could get the environment specific configuration from backend by calling an API.

The advantage of this approach would the configurations need not be duplicated in backend and frontend.
The disadvantage would be the app would always need to make this call for getting the config on load in the browser.

Additional context
With containerization getting popular, it would be nice to have parameters that could provide a Dockerfile and .dockerignore.
This will speed up the initial dev environment set up.

I've always managed to do all I need with this :
https://create-react-app.dev/docs/adding-custom-environment-variables#adding-development-environment-variables-in-env
Coupled with a piece of logic that load a config file depending on the current environment from the server, when necessary.

@julienberubebnc , Thanks for brining this up... It works however there are limitations in it.
Once the build is completed, the the values specified in .env.production or .env.local.production file can  not be changed
So if these values are changed, then the application needs to rebuild.
The problems with this approach

It does not fit in the approach 'build once deploy anywhere'.
It does not fit in the approach separate config from code - https://12factor.net/config
When we dockerize the application, the docker image is specific for an environment. (We can change the configuration and deploy it in another environment)
The deployment process takes longer as it is couple with the build

CRA is usually used to create a SPA (single page application) which is usually pretty static. That definitely fits the:

'build once deploy anywhere'. If you need additional settings then those should be handled by your server and can be something like a config.js file that is put there by the server. Then your code can do a simple <script src='/config.js'></script> before any other code. This would satisfy all your requirements it seems.

Like @julienberubebnc said, .env is the way to go. I've found it covers almost all of the cases I have ever come across and anything missing would be handled by the approach I said above.

Hey @eddiemonge , I agree that CRA is doing it fine for building the whole app and configs as an artifact. However there are many projects out there that are promoting the react app to different quality levels such as dev, staging, prod1, prod2, etc...
When many projects have this need, it would help if CRA guided developers this way.
Could you take a look at below project?
https://github.com/ZeroWasteTeam/SampleReact
This will also make containerization much easy

That is doing what I said so I'm confused. Are you against this approach or this is how you think it should be done?

Iam not against this approach. However I think the approach of CRA could be improved


CHW/ANC - Add Family member to ANC Crashes

Describe the bug
Adding a family member as an ANC Client causes the app to crash
To Reproduce
Steps to reproduce the behaviour:

Go Family profile
Select a family member
Click on menu Item to add as ANC client
Click save

Expected behaviour

Go Family profile
Select a family member
Click on menu Item to add as ANC client
Click save
Patient should appear in the ANC list post save
View also acceptance criteria

Screenshots

[ ] App takes a while to load the Enroll to ANC Questionnaire

[ ] Validate date to be LMP to be in the past while EDD should be in the future

[ ] Prompt user before submission - working ok

[ ] Remove progress bar in the background and leave the one in the alert dialogue

[ ] Screen to match the once being updated here  : #695
[ ] Update ANC card in the patient profile

Smartphone (please complete the following information):

Physical Device or Emulator
Android API Level 25 and above

Additional context
Memory Leak Issues. See screenshots

Acceptance Criteria

[ ] Patient should also appear in ANC List upon search in that register
[ ] Update the number of clients due in ANC Family List view

Related Tickets

#695

@qiarie These are the desired mocks

You can pull the PR from @RaaziaTarique whose working on the ticket #695
For this tasks

[ ] Add family questionnaire loading
[ ] Successfully add family
[ ] Check layout of where to add Family member button
[ ] On successful family member addition go back to family profile with a refreshed patient listing
[ ] Only female clients who meet the ANC criteria can be enlisted to ANC in the menu items , thus hide menu item Mark as ANC if male or already ANC client
[ ] Hide Pregnancy outcome if not an ANC client


just: 0.4.4 -> 0.4.5

Motivation for this change
Update just to the latest release.

https://github.com/casey/just/releases/tag/v0.4.5

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build just

Let's check darwin build
@GrahamcOfBorg build just

Thanks!


handles non GIF image cases

added methods to handle the case that the images are not GIF
For UIImage :
convenience init?(imageData:Data, levelOfIntegrity: GifLevelOfIntegrity = .default) throws
convenience init?(imageName: String, levelOfIntegrity: GifLevelOfIntegrity = .default) throws

For UIImageView:
func setImage(_ image: UIImage, manager: SwiftyGifManager = .defaultManager, loopCount: Int = -1)

Create snapshot tests to verify the functionalities of non-animated GIF and normal images.

Thanks, great work!

You also need to add non-GIF processing in the case of urls


Complete Jupyter notebook integration

Meta issue to keep track of the remaining tasks before shipping Jupyter notebook native integration:

[x] #4727
[ ] #5189
[ ] Add support for viewing Jupyter Notebooks in the playground
[x] #5190

Formatter Support

[ ] ~Add support for IpyEscapeCommand token in SimpleTokenizer (if required)~
[x] Add support for formatting StmtIpyEscapeCommand
[x] Add support for formatting ExprIpyEscapeCommand
[x] https://github.com/astral-sh/ruff/pull/7749

Editor Integrations

[ ] https://github.com/astral-sh/ruff-vscode/issues/256 - I think this will probably involve changes in ruff-lsp so that other editors can benefit as well.

IPython Syntax Handling (%, !, etc.)

[x] #5030

Ruff

[x] #6090
[x] #6087

Proposed new rules

[ ] Empty magic command (%) (Autofix: remove the statement)
[ ] Magic command contains whitespace between the prefix and command value (% matplotlib inline) (Autofix: remove all the whitespaces) (Only valid for % magic prefix)

Existing rule changes

[x] #6116
[ ] #6672

I'll be looking at other related rules and update this issue accordingly
Parser

[x] #6359
[x] #6357
[x] https://github.com/astral-sh/RustPython-Parser/pull/23
[x] https://github.com/astral-sh/RustPython-Parser/pull/30
[x] https://github.com/astral-sh/RustPython-Parser/pull/31

Autofix for Jupyter Notebook

[x] https://github.com/astral-sh/ruff/issues/1218

Implementation

[x] https://github.com/astral-sh/ruff/pull/5114
[x] https://github.com/astral-sh/ruff/pull/5076
[x] https://github.com/astral-sh/ruff/pull/5028
[x] https://github.com/astral-sh/ruff/pull/4665

My main question would be: at what point do you think we can remove the feature flag, and open this up to users? (Maybe we're already past that point!)

I do think we're ready except that without the (1) task above Ruff might give false positives. Without that we would ignore any cell which contains magic commands. Now, we would also ignore if it contains valid Python code. It could be that a variable is defined in that cell and is being referenced in another cell. Here, we might trigger undefined variable. Similar example can be given for imports.
I see this a lot for %matplotlib inline command: https://sourcegraph.com/search?q=context:global+lang:"Jupyter+Notebook"+%25matplotlib+inline&patternType=standard&sm=1&groupBy=repo

What do you think about releasing this under experimental? I'm not sure what would that look like but maybe we don't add the *.ipynb to include and ask users to explicitly opt in to that.

Yeah, I think it would be reasonable to release it now (even without magic handling) and omit *.ipynb in include, so users need to opt-in explicitly. We can market it as experimental to get feedback. We can include it in the next release IMO.
We should also add the magic command support, but doesn't have to block if it's opt-in :)

(To be explicit: we could just remove the flag now.)

I'm not sure if this deserves its own issue, but: Would it be possible to use extend-include = ["*.ipynb"] and ruff format to only re-format the Python code in cells, and not the ipynb file itself?
My users typically edit notebooks in Google Colab. Google Colab uses two-space indentation in the ipynb file, instead of the typical one-space indentation. ruff format currently re-indents with one space. As such, edit history becomes difficult/impossible to track, because effectively every line gets rewritten between the user saving from Google Colab (changing to 2 spaces) and CI running ruff format (changing to 1 space).
Google Colab also puts keys like metadata, nbformat, nbformat_minor at the top of the file, but ruff format moves these to the bottom. ruff format also changes the order of execution_count, outputs, etc.
I would love to be able to opt out of ipynb formatting, so that only the Python code inside cells is reformatted.

(I think it deserves its own issue, we can discuss it there :))

Closing this as completed. The only thing remaining is to support --add-noqa.


Fix Missing Punctuation

This will fix the missing punctuation in the first paragraph.

I signed it.

/lgtm
/approve


Update cargo-binstall to 0.14.0

Update to the latest cargo-binstall, which fixes the installation of sccache.

Here's the full changelog.
It's worth mentioning that cargo-binstall can also install crates like miniserve which set pkg-fmt to bin instead of packing them as a tarball/zip archive, plus some sandboxing for bin-dir.

Published in 1.13.9.


Create databases in the target cluster if they don't already exists

Hit this when using this tool for the ICDS cluster migration. The gist here is:

save the shard_suffix in the plan so that we can use it to create the new db doc later
when loading the plan re-create the ShardAllocationDocs

For this use case we're migrating shards from one cluster to another (as opposed to moving shards around in the same cluster). So even though the files are copied across the database files don't exist yet.


Feature/diktat cli arguments pattern#1854

A test PR to validate before creating a proper one in main repo

Welcome to Codecov :tada:
Once merged to your default branch, Codecov will compare your coverage reports and display the results in this comment.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


feat: create examples on init

Description

This PR adds a mechanism to gather examples at init time.
Types of change

This is a feature.
Checklist

[x] I confirm that I have the right to submit this contribution under the project's MIT license.
[x] I ran all tests in tests and usage_examples/tests, and all new and existing tests passed. This includes

all external tests (i. e. pytest ran with --external)
all tests requiring a GPU

[ ] My changes don't require a change to the documentation, or if they do, I've added all required information.

It's missing example extraction for other tasks, but I wanted to let you have a look before I took a break.

Note: still missing docs (let's go through review first)

Retracted the approval for clarity because docs are still missing. Code is good for me.

I'm not super happy about the name infer_prompt_examples actually, sounds like a flag. n_prompt_examples_to_infer maybe? It's verbose, I know, but more accurate.

More generally I'm a bit unsure about this because we offer two way to do one thing (inject examples into the prompt):

Create an examples file and inject it into a prompt using the spacy.FileReader.v1.
Initialize the component with Example instances, set infer_prompt_examples != 0.

I feel like this may be confusing. I do see the value though.

This will be a hassle because we'll have the legacy versions, or we might just drop support for the older versions as we go to the next minor version...

I'm fine with just dropping all legacy versions and always using .v1 as long as we are <1.0.0 (as long as we version afterwards).

@svlandeg I think this is good to go except for the readme updates. I can wrap this up tomorrow, but feel free to do so today.

Updated the readme. Ready for review.


Some performance bottlenecks for UAV loads

Thanks for useful tool.
I added support for UAV loads in fork https://github.com/ash3D/perftest/tree/UAV_load (branch UAV_load). The results turned out to be somewhat slower than SRV on NVIDIA Kepler (GeForce GTX 760M). Previously I obtained higher performance with UAV compared to SRV under certain conditions in similar benchmark. So I started to experiment with shaders and eventually came up to about 2X speedup. The things I tried:

Loop unrolling.
This improved 1d and 2d raw buffer loads but significantly worsened 3d and 4d loads on Kepler. Unrolling typed UAV buffer and texture loads resulted in crashes during benchmark execution on Kepler (but Intel worked well).
I also tried partial loop unrolling. This eliminated big slowdown for 3d/4d loads on Kepler but in general partial unrolling performance was closer to original one (without unrolling), often slower. Different unroll factors worked best for different conditions (load width, access pattern) in somewhat unpredicted way.

Loop iteration count reduction.
Big 3d/4d loads slowdown on Kepler with unrolled loop suggested to reduce iteration count. This unexpectedly also improved 1d/2d performance (2X scaledown led to >2X performance). Even more unexpectedly it improved performance of original loop without unrolling.
Such behavior was detected on Kepler only. I tested Intel and Fermi a little bit and found mostly linear performance scaling there.

Remove read start address and address mask.
Reading start address from cbuffer (used for unaligned tests) harmed UAV performance even if value is 0. Address mask which is intended to prevent compiler from merging multiple narrow loads also affected wide loads performance. It seems than NVIDIA GPUs perform wide raw buffer loads sequentially anyway so performance gains from removing address mask here apparently comes from something other. There are other places though where address mask apparently actually prevents narrow loads merging on Kepler (e.g. scalar 8/16/32 bit texture SRV loads).
Removing address mask also fixed big slowdown for 3d/4d loads on Kepler with unrolled loop.
I experimented with other address mask application - &= ~mask instead of |= mask. It unexpectedly improved performance. In some specific cases performance oddly became better than even without mask at all.

The modifications I mentioned also affected SRV performance in some extent but UAV performance was much more sensitive.
The results ultimately became close to expected theoretical peak rates of Kepler architecture. NVIDIA GPUs implements SRV loads in read-only TMU pipeline thus performance is different compared to CUDA which uses read/write LSU pipeline. It also differs significantly from AMD GCN. All of the 4 32-bit fetch units used for bilinear texture sampling can be utilized for buffer accesses in GCN (for wide loads/stores or coalesced 1d access). NVIDIA TMU fetch units are 64-bit beginning with Fermi (it able to filter 64-bit RGBA16F textures at full rate) but apparently only 1 of 4 used for buffer reads. I have observed similar behavior before with GT200 except its' fetch units are 32-bit.
UAV accesses are served by LSU pipeline on NVIDIA GPUs. Kepler has 2:1 LD/ST to TMU ratio but UAV cached in L2 only. Initially UAV loads was slower then SRV in the benchmark but after shaders modifications I described above UAV performance became faster then SRV for invariant loads. Ratio is still not 2X but close to it. Linear and random UAV load performance varied in wide range (probably due to increased L2 access rate) and can be much faster or slower then SRV in different cases. SRV performance is very stable (it is the same for invariant/linear/random reads).
I also tested NVIDIA Fermi2 (GeForce GTX 460) a little. Fermi has L1 cache for LSU pipeline (combined with shared memory) thus UAV performance appeared to be better. Invariant UAV reads are 2X faster then SRV ones. Linear and random UAV read performance still not as stable as SRV one but much better then on Kepler. Also Fermi is not subject to big performance drop for 3d/4d UAV raw loads with long unrolled loop.

Thanks for the detailed info.
CUDA has different memory model as DirectX/OpenGL/Vulkan (raw data vs data fetched using resource descriptors). It makes sense that Nvidia has different hardware paths for these. I am just used to AMDs architecture, which is more generic.
The loops should definitely be slightly unrolled, because most GPUs benefit from being able to issue multiple loads at once and then wait for them at once. With loop, you issue each load separately and then wait for them. Because this loop doesn't have any ALU to hide the load latency, it would definitely be better to unroll at least by 2x or 4x. But it obviously increases the register pressure so results are highly GPU and compiler specific.
The start address and the address mask are there to avoid compiler merging multiple 1d loads to wider 4d loads. This is because I want to benchmark 1d load performance and wide (2d and 4d) load performance separately. If the compiler would be allowed to merge them, all linear tests become wide 4d load tests. This is obviously not the intention.
The big perf changes caused by different masking operators are very strange indeed. ALU should be irrelevant here, because the L1$ latency is much higher than any ALU latency. The memory access pattern doesn't change at all either by masking changes, so it must be that the compiler optimizes the loops differently based on different masking. Maybe it partially unrolls some cases, because the loop length (256) is known at compile time. If this test app was DX12 based, we could use the new DX12 PIX to see Nvidia shader compiler output to see what's happening.
The length of the loop should not matter for performance (unless it becomes very short), since the test case is designed to fit fully to the compute unit's L1 cache. Also the group should be wide enough to fulfill all possible coalescing requirements. This is another strange result (for Fermi). Obviously in real workloads, larger loop size would often mean larger working set for each group, potentially trashing the L1$ (depending of course whether there's more data locality in program order vs neighboring groups).
DX11 has loose default guarantees of data visibility. Data written by another thread group is not guaranteed to be visible to other thread groups during the same dispatch, unless "globallycoherent" buffer attribute is used and memory barrier instruction is used. This allows AMD to use L1$ for UAV reads safely (common case = not globallycoherent). This works fine, since a single group always runs fully on the same CU (= single L1 cache). However UAV writes are a bit more complicated matter, especially since there's separate K$ for the scalar units that is not coherent with L1$. I would assume that AMD shader compiler marks UAVs that are written and then driver does some pessimistic assumptions. GCN asm also has tags for individual load/store instructions that allow changing the cache protocol.

GPUs can potentially hide fetch latency even within loops - it cat switch to another warp/wavefront if results for current one are not yet ready (AMD GCN able to keep up to 10 wavefronts in flight per CU). But it is limited by available GPU resources, primarily by GPR count. I am not sure if it is enough to completely hide latency in such synthetic shader, it would be interesting to find it out for different GPUs. Real-world shaders with fetch loops can behave differently because other parts of shader can require many GPRs which can limit occupancy and thus GPU's ability to hide latency in fetch-intensive part.
Aside from fetch latency there is another potential cause to limit performance in looped fetches - loop instructions overhead. Modern GPUs have much higher ALU throughput relative to fetch units so it is less likely to became a bottleneck but it worth to not rule it out beforehand especially considering presence of mask operations. Also loop require counter which increases GPR pressure. AMD GCN though can utilize scalar hardware for loops. It has dedicated scheduler, ALU and GPRs for scalar operations so presumably loops should impact less on GCN.
 At the same time I noticed other cases where the mask is required to prevent scalar loads merging (SRV texture loads). So for now I have not found single solution that work well for all cases.
Start address offset which is used to test unaligned loads is much simpler. Reading it from cbuffer also slows down performance in some cases but it is possible to hardcode it in shader which solves the problem.
I suppose that performance dependency on loop length on Kepler is not related to access pattern. Initially I started experiments with loop length after I had fully unrolled loop and noticed poor performance for 3d/4d raw UAV loads. I suspected that the reason was instruction cache overflow and tried to reduce iteration count. But later I observed that loop length also affects performance for loop without unrolling. Maybe compiler chooses different optimization strategies regarding loop unrolling or register allocation. This behavior is specific for Kepler, other GPUs behaves more predictably. Address mask options also affects how different loop techniques performs relatively to each other.


Best way to use pre-commit

Describe the bug
I'm trying to best understand how to use the pre-commit derivation to set up hooks on projects that I work on. So far I have tried:

Adding pre-commit to the buildInputs of the project, entering a development environment using nix-shell, and running pre-commit install. However, my text editor is not inside any nix-shell.
Installing pre-commit globally using nix-env -iA nixos.gitAndTools.pre-commit.

I've had failures because pre-commit cannot find virtualenv to set up a Python environment, or because the virtualenv it sets up for a hook does not have access to six.
I guess the situation is complicated because pre-commit tries to build its own "repositories" in a somewhat Nix-like way, but outside Nix and relying on a global Python installation.
I am starting to think that instead of using pre-commit install to generate .git/hooks/pre-commit, I should just hand-write a simple one that does nix-shell && pre-commit run. This seems dangerous too, since the repositories that pre-commit creates will be influenced by the shell that they're being run in, and since they're re-used, could break in other projects with other inputs in their shell.nix.  I was wondering if this is the expected behavior or if there's something obvious I'm missing.
To Reproduce

Create a new git repository.
Add a shell.nix that provides pre-commit. Something like this is fine:

{ pkgs ? import <nixpkgs> {} }:
pkgs.stdenv.mkDerivation {
  name = "quartermaster-elm-dev";
  nativeBuildInputs = [
    pkgs.pre-commit
  ];
}

Create a .pre-commit-config.yaml. This one is fine:

- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v2.3.0
  hooks:
    - id: end-of-file-fixer
    - id: trailing-whitespace

Commit these two files.
nix-shell --command "pre-commit install"
Touch another file and try to commit it.

Expected behavior
The git hook will be run successfully.
Additional context
I also found https://github.com/cachix/pre-commit-hooks.nix, maybe that's what I should be using instead?
Notify maintainers
@borisbabic
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.40, NixOS, 20.03.1885.885a6658073 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.4`
 - channels(ethan): `""`
 - channels(root): `"nixos-20.03.1885.885a6658073"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

However, my text editor is not inside any nix-shell.

This perhaps isn't directly related to your issue, but a good way to solve tools having access to your Nix shell environment in general is with direnv, which supports Nix; many shells, editors, and other tools integrate with it. You might then also be interested in lorri or nix-direnv to make the direnv activation faster.

This is great. I had been putting off looking at direnv or lorri but you're right, they're perfect for what I need. I think "run pre-commit from within your nix-shell or similar" is a great answer to the question so I'm closing it.


Add material icons golden test

Reland https://github.com/flutter/flutter/pull/73361 (reverted in https://github.com/flutter/flutter/pull/73521) by using a more robust method for obtaining the flutter root directory.
Adds a golden test for a few enlarged material icons (first, last, and variants). This will help validate upcoming icon font updates

I'm getting this in the logs when I run tests:
No expectations provided by Skia Gold for test: material.test.icons.sample.png. This may be a new test. If this is an unexpected result, check https://flutter-gold.skia.org.
Validate image output found at file:///home/ianh/dev/flutter/bin/cache/pkg/skia_goldens/packages/flutter/test/material/

Did we maybe never actually validate the goldens? It doesn't seem to fail the test, which seems weird.

I'm getting this in the logs when I run tests:
No expectations provided by Skia Gold for test: material.test.icons.sample.png. This may be a new test. If this is an unexpected result, check https://flutter-gold.skia.org.
Validate image output found at file:///home/ianh/dev/flutter/bin/cache/pkg/skia_goldens/packages/flutter/test/material/

Did we maybe never actually validate the goldens? It doesn't seem to fail the test, which seems weird.

Looks like I validated Windows and macOS, missing the golden for Linux (I just validated that one). I checked the LUCI logs and the test did indeed pass. I'm not sure why...

Looks like I validated Windows and macOS, missing the golden for Linux (I just validated that one). I checked the LUCI logs and the test did indeed pass. I'm not sure why...

Cool, thanks for looking into it. Would you mind filing a bug to remind us to make this a fatal error in the future?

Cool, thanks for looking into it. Would you mind filing a bug to remind us to make this a fatal error in the future?

Sure, filed https://github.com/flutter/flutter/issues/74712

Sure, filed https://github.com/flutter/flutter/issues/74712


Allow connexion to InfluxDB with login/pass

I just make this to allow your app works with my influxdb.
I already have grafana and influxdb
Maybe no need to accept PR. I think it doesn't works with influxdb withouh login/pass

I just make this to allow your app works with my influxdb.
I already have grafana and influxdb
Maybe no need to accept PR. I think it doesn't works with influxdb withouh login/pass

Hi,
Thanks for your submission !
I recently added this feature (f21a5b36) in the 2.0 release.
You can now use CLI option --username and --password to specify user and password


go get downloads the v1 (old and broken version) instead of latest (v3)

Hi,
found this repo today, tried doing the go get line to add it to my project, discovered it downloads either some .a file or the pkg code for the v1 release. Not sure what is wrong with the repo, guessing a bad release setup in github or go.mod file?
Would much prefer to import your repo instead of forking the latest version to resolve this.
Thanks

Hey @anz-gordonj7 Thanks for reporting, I'll look into it today

@anz-gordonj7 fixed the problem. I forgot to update the modules file.
You can import it now with go get -v -u github.com/disiqueira/gotree/v3
Closing the issue, but feel free to re-open if any problem occurs.

Please fix import in README.


yarn create slidev works error

Describe the bug
run yarn create slidev in terminal, works error just now
To Reproduce

Desktop (please complete the following information):

OS: Windows Feature Experience Pack 120.2212.3530.0
Browser:
Slidev version:

when select npm in terminal, works ok
but works error if select pnpm
maybe it's a pnpm bug similar error

I managed to get things working by removing the dependency for "@slidev/theme-seriph".
However, it defaulted to installing version 0.0.0-alpha3 of the "@slidev/theme-default" package.
It seems that pnpm does not find the correct version of the themes with the * version selector.

The final solution that installed everything correctly with pnpm:

pnpm create slidev.
Choose No to "Install and start it now ?".
cd FOLDERNAME
Remove both themes from the dependencies in "package.json".
pnpm install
pnpm add @slidev/theme-default @slidev/theme-seriph
pnpm run dev


backward_ros: 1.0.0-1 in 'rolling/distribution.yaml' [bloom]

Increasing version of package(s) in repository backward_ros to 1.0.0-1:

upstream repository: git@github.com:pal-robotics/backward_ros.git
release repository: https://github.com/pal-gbp/backward_ros-release.git
distro file: rolling/distribution.yaml
bloom version: 0.10.7
previous version for package: null

backward_ros
* Update backward.hpp from https://github.com/bombela/backward-cpp
* Update README
* Update package.xml
* Adapt package to ROS2
* Contributors: Victor Lopez

@nuclearsandwich as in #30179 ,  It's missing rhel dependency rosdep rules (libdw-dev), is there any instructions on how to check it? I've never worked with redhat. I downloaded a redhat docker but kept getting message about missing a license.

@nuclearsandwich as in #30179 , It's missing rhel dependency rosdep rules (libdw-dev), is there any instructions on how to check it? I've never worked with redhat. I downloaded a redhat docker but kept getting message about missing a license.

See https://github.com/ros/rosdistro/pull/30179#issuecomment-879214011.


Is there a convenient way to make the AAC 2.0 converted audio the new default in the output?

One of the biggest use cases for sickbeard is for optimising videos for universal client compatibility e.g for Emby or Plex server. However, many video files have 2 or more audio streams. Even after running sickbeard and the output video is now x264 mp4, if the AAC 2.0 track is not the default stream, then it will still require on the fly conversion by servers to work in most browsers (e.g. Chrome) - this is because browsers have no way of directly selecting secondary audio tracks so the media servers have to convert on the fly, all non-default streams as the new default. (the only exception I found is Edge browser, which seems to be able to direct play non-default streams if they are in AAC.)
Any advice appreciated.

Thanks @mdhiggins !


fix(JSONReducers/Containers): delete protocol field on ADD_ITEM

Since we've ditched applyPatch but still want to keep in stuff that we don't know about we started copying values via ADD_ITEM. The problem here was that the internal representation of protocol field was an object wheres the JSON representation is an array.
That array threw a wrench into the parser-reducer logic, because an array is an object in javascript.
To fix the issue I had to delete protocol field for the ADD_ITEM event and process it separately. I also added a missing bit to out integrity test to make sure we won't have it again.
Closes DCOS-18694

LGTM! 🚢


How would I call long-running functions in update() without freezing the ui?

Description

[x] question - For instance I'm going to need to do thousands of calculations, and then display the results to a table. How can I do this without freezing the ui while the calculations are in progress? Threads with a channel would work, except wasm dosen't support threads

I haven't tested this code but something along these lines should work:
use yew::services::timeout::TimeoutService;

struct Context {
    timeout: TimeoutService<Msg>,
}

impl Component<Context> for Model {
    fn update(&mut self, msg: Self::Message, context: &mut Env<Context, Self>) -> ShouldRender {
        match msg {
            Msg::StartLongTask => {
                let send_msg = context.send_back(|_| {
                  long_task();
                  Msg::LongTaskDone
                });
                context.timeout.spawn(Duration::from_secs(0), send_msg);
            }
            Msg::LongTaskDone => {
                // Do something
            }
        }
    }
}

Maybe we could add an example with Fibonacci for demonstrating this?

Hey, I think that this example is outdated, as can be seen by the fact that it uses the Env<Context, Self> parameter in update, which was removed around v0.4.0 or v0.5.0.
It was replaced with an actor system, which uses Agents to coordinate concurrent tasks.
In short, you send a message to an agent over a bridge to that agent, Yew's "runtime" spawns an instance of the agent if one doesn't already exist, the agent gets the message, processes it for an indeterminate amount of time, and then sends a message back to the caller (or technically, anything else that is connected to the agent).
The multi-thread example uses an advanced form of this that uses web-workers to perform actions on a separate "thread".
The router example uses it to handle arbitrary events from the browser and distribute them to interested components.
Although they aren't explicitly about long-running tasks, these examples offer a way to get familiar with the semantics of agents for the purpose of handling long running tasks.


Can't swap back to armor when submerged in lava

If you press space in lava you equip the elytra but can't equip the armor again until you get out, this can be really bad in certain situations.
I assume it is related to this bug

Thanks for such a thorough bug report!
This definitely seems to be caused by MC-106879. I should be able to patch this as part of the mod!
At the moment, your armour is only re-equipped after vanilla behavior causes you to stop flying, usually by landing on the ground. I could force your armour to be equipped when in lava, although this should be behind a configuration option as it may not be preferable in all situations...
I will let you know when this fix has been implemented!

You should now be able to download the fixed version from GitHub Releases or Modrinth!


Script currently not working as apt not called with sudo

In raising this issue, I confirm the following:
{please fill the checkboxes, e.g: [X]}

[X] I have read and understood the contributors guide.
[X] The issue I am reporting can be replicated.
[X] The issue I am reporting can be is directly related to the pivpn installer script.
[X] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

Fix
Manually download the script, make it executable, add $SUDO before apt here in the code (possibly before npm too).
wget https://raw.githubusercontent.com/pivpn/pivpn/master/auto_install/install.sh
chmod +x ./install.sh

make the change, then run with ./install.sh

ooooh crap .. really my bad here with this one! I made my tests with root account which obviously worked flawlessly and didn't spotted that! will make a hotfix for that right away

I am working on making it optional as well ... will make it show a whiptail message asking if user wants to install it.

@orazioedoardo should be fixed, can you test and comeback with feedback pls?
Thanks a lot

As per comments here: https://github.com/pivpn/pivpn/issues/823 I have removed Bitwarden installation from the script. commit: 510979ae90682c4ca11eb59d763c91930ffb5847
Thanks a lot for your help @orazioedoardo
should no longer be an issue.
Closing.


Run lorri daemon as a service on Linux and macOS

Addresses some of #96. lorri.socket, lorri.service and lorri.nix are mostly taken from comments on that issue.
contrib/README.md preview.

Works For Me (TM) on NixOS 19.09.

I'm looking into how we can check these files in CI. There's systemd-analyze verify for the .socket and .service files: http://manpages.ubuntu.com/manpages/bionic/man1/systemd-analyze.1.html#examples for verify

I'm looking into how we can check these files in CI. There's systemd-analyze verify for the .socket and .service files: http://manpages.ubuntu.com/manpages/bionic/man1/systemd-analyze.1.html#examples for verify

Things I've learned:

Currently we don't set the dist in .travis.yml. The default is xenial (Ubuntu 16.04).
Even on bionic (Ubuntu 18.04, the latest dist available on Travis CI), systemd is only at version 237.
Somehow, systemd-analyze still reports its version as 229 on bionic (I set dist: bionic in that CI run).

Since the names of systemd unit settings have changed, running systemd-analyze verify in CI is difficult: lorri.socket and lorri.service do actually work fine on systemd 243 (the version shipped in NixOS 19.09), but older versions of systemd-analyze verify report errors.

PTAL

I'm a big fan of adding these files into contrib/, and refer those in a NixOS module for example.
I don't really like we need to document multiple ways on how to get it set up - can't we please just release Lorri, get it into nixpkgs, and provide a NixOS module using the unit files in contrib/? :laughing:

I think the NixOS module should also install the lorri binary so it's available to all users, or eval "$(lorri direnv)" won't work in .envrc files (as lorri can't be found)

Thank you @ocharles for trying this out! I believe that in order to address the issues you've raised, we'll have to think about the Nix packaging of lorri more generally - that is, actually have a packaged .nix file that makes sure nix is available as a runtime dependency, and then have the .nix file describing the service integration depend on that. (They could be the same file.)
Note to self: check out https://eipi.xyz/blog/packaging-a-rust-project-for-nix/

Quick update - I'm working on getting lorri included in nixpkgs right now: https://github.com/NixOS/nixpkgs/pull/72889, including the service definition. That will eliminate the manual steps on NixOS at least, and it will make it easier to include the service definition in home-manager (i.e. https://github.com/rycee/home-manager/pull/799 could be re-opened).

Thanks for the review @grahamc! Note that now lorri has landed in nixpkgs (https://github.com/NixOS/nixpkgs/pull/72889) :tada: I think this PR can be simplified quite a lot. I'm not exactly sure what the instructions should be now, to be honest, given that lorri is now in nixpkgs/master, but not yet in unstable nor in any stable branch.

With NixOS/nixpkgs#73451 merged aswell, we should direct users to just set services.lorri.enable = true;.

I pinged at rycee/home-manager#799, it would be nice if we could have a home-manager module aswell, which we could refer to.

services.lorri.enable has landed in home-manager: https://github.com/rycee/home-manager/blob/286dd9b3088298e5a4625b517f8e72b1c62e4f74/modules/services/lorri.nix - I'll adjust the home-manager instructions in the README accordingly.

PTAL - I'd like to merge this now (it's better to have this than not to have this) and then revisit it as part of https://github.com/target/lorri/issues/231.

Let’s merge after squashing. Since you’re gonna re-work parts anyway, I don’t see why we should block the merge.

:+1: I've squashed the commits.


Missing font weights in the preset

I found this library very useful with Radix Themes. But I noticed that in the config there are some missing fontWeights which were in the default tailwind config. Are those omitted on purpose or is it a small mistake while implementing the preset? If its a small mistake I can open a PR if you would like. Thanks

Hi, the preset is meant to follow radix design system and so it only includes the font weights used in radix themes.


added two more cases to SSL template and gzip as default in templates.

There were two cases missing from the SSL template:

Ability to redirect from www to https://www
Ability to redirect from naked url to https://

And added gzip as default on both SSL and NOSSL templates.

Should the gzip bits perhaps go in the top-level nginx config? Like here maybe?


Updated the download iso link to 4.12 iso

But the RELEASE_IMAGE is still 11?

:smirk: forgot to push..

closed in favor of https://github.com/eranco74/bootstrap-in-place-poc/pull/37


heap buffer overflow vulnerability

in index.js:36 you allow the user to specify the size of the target buffer:
'compress': (input, length) => {
  // ...
  let output = Buffer.alloc(length || (input.length + (input.length / 16) + 64 + 3));
  result = lzo.compress(input, output);
  // ...
}

later you pass a pointer to this buffer to the lzo1x_1_compress function in lzo.cc:21
int result = compress(  (unsigned char *) node::Buffer::Data(inputBuffer),
                        (unsigned char *) node::Buffer::Data(outputBuffer),
                        input_len,
                        output_len );

int compress(const unsigned char *input, unsigned char *output, lzo_uint in_len, lzo_uint& out_len) {
  if (lzo_init() != LZO_E_OK)
    return ERR_INIT_FAILED;

  return lzo1x_1_compress(input, in_len, output, &out_len, wrkmem);
}

the call makes sure to forward the correct length of the output buffer in the out_len (4th) argument. however, from a very quick reading of the source of the lzo1x_1_compress function it seems that this argument is not checked/used as an input bounds parameter, but merely as an output parameter: https://github.com/schroffl/node-lzo/blob/master/lib/minilzo209/minilzo.c#L4791
I'm not 100% positive that there isn't a check that I have missed (the c code in minilzo is very dense and re-uses identifiers a lot), so I might be mistaken, but it seems like this allows users to write arbitrary data beyond the bounds of the output buffer, potentially creating a security vulnerability.

adding some evidence
    const lzo = require('lzo');

    // works and valgrind reports clean
    {
      const str = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
      const str_ = lzo.decompress(lzo.compress(str), 4096);
      console.log(str_);
    }

    // crashes, valgrind errors below
    {
      const str = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
      const str_ = lzo.decompress(lzo.compress(str), 4);
      console.log(str_);
    }

valgrind errors for 2nd test case:
== Invalid write of size 1
    at 0x98D9BC6: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21874 is 0 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid write of size 1
    at 0x98D9798: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21875 is 1 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid write of size 1
    at 0x98D97AC: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21876 is 2 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid write of size 1
    at 0x98D9F30: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21877 is 3 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid read of size 1
    at 0x98D9F24: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21874 is 0 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid write of size 8
    at 0x98D9B7B: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21881 is 13 bytes after a block of size 4 alloc'd
    at 0x4C2FB45: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x10CED02: v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) (in /usr/bin/nodejs)
    by 0xC3BB36: v8::internal::(anonymous namespace)::ConstructBuffer(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::JSReceiver>, v8::internal::Handle<v8::internal::Object>, bool) (in /usr/bin/nodejs)
    by 0xC3BF66: v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA3C8DC: ???
    by 0x2B2BDCACB81E: ???
    by 0x2B2BDCACE38A: ???
    by 0x2B2BDCAF4F25: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCA09419: ???
    by 0x2B2BDCAF596D: ???
    by 0x2B2BDCA12F11: ???

 Invalid write of size 1
    at 0x98D9BD9: lzo1x_decompress (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB13B: decompress(unsigned char const*, unsigned char*, unsigned long, unsigned long&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0x98DB222: js_decompress(v8::FunctionCallbackInfo<v8::Value> const&) (in /tmp/node_modules/lzo/build/Release/node_lzo.node)
    by 0xBC1962: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) (in /usr/bin/nodejs)
    by 0xC3AC49: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (in /usr/bin/nodejs)
    by 0xC3B9F8: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (in /usr/bin/nodejs)
    by 0x2B2BDCA040DC: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF38A9: ???
    by 0x2B2BDCA12F11: ???
    by 0x2B2BDCAF2CC7: ???
  Address 0x8a21892 is 34 bytes inside a block of size 64 in arena "client"

As I have already mentioned in previous issues, I'm not even remotely fluent in C++ and mainly created this  package for a hobby project.
I will investigate this tomorrow and also add a disclaimer to the Readme (linking to this issue). But please feel free to submit a Pull Request if you have a fix at hand.
Thank you for all the information.
Cheers!


Sysimage creation fails in Windows

I am following the documentation step-by-step to generate a binary from Julia code on a Windows 10 machine using Julia v1.3.1
The first step works fine:

C:\X>julia --startup-file=no --trace-compile=app_precompile.jl MyApp.jl "FL_insurance_sample.csv"
FL_insurance_sample.csv: 90356x4

On the next step when I try to create the sysimage I get this error:

C:\X>julia --startup-file=no -J"C:\julia-1.3.1\lib\julia\sys.dll" --output-o sys.o custom_sysimage.jl
Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x669a4e98 -- uv_write at /workspace/srcdir/libuv\src/win\stream.c:124
in expression starting at none:0
uv_write at /workspace/srcdir/libuv\src/win\stream.c:124
jl_uv_write at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\jl_uv.c:476
uv_write_async at .\stream.jl:967
uv_write at .\stream.jl:924
unsafe_write at .\stream.jl:1007
#with_output_color#707 at .\gcutils.jl:91
unknown function (ip: 000000001E27E839)
#with_output_color at .\tuple.jl:0 [inlined]
#printstyled#708 at .\util.jl:397 [inlined]
#printstyled at .\none:0
_jl_invoke at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2141 [inlined]
jl_apply_generic at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2305
display_error at .\client.jl:101
_jl_invoke at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2141 [inlined]
jl_apply_generic at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2305
display_error at .\client.jl:104
_jl_invoke at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2141 [inlined]
jl_apply_generic at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2305
jl_apply at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\julia.h:1631 [inlined]
jl_f__apply at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\builtins.c:627
jl_f__apply_latest at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\builtins.c:665
#invokelatest#1 at .\essentials.jl:709 [inlined]
invokelatest at .\essentials.jl:708 [inlined]
exec_options at .\client.jl:289
_start at .\client.jl:460
unknown function (ip:<PHONE_NUMBER>1E0BFA)
_jl_invoke at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2141 [inlined]
jl_apply_generic at /cygdrive/d/buildbot/worker/package_win64/build/src/cygdrive/d/buildbot/worker/package_win64/build/src\gf.c:2305
unknown function (ip:<PHONE_NUMBER>4017DD)
unknown function (ip:<PHONE_NUMBER>401BC5)
unknown function (ip:<PHONE_NUMBER>4013DE)
unknown function (ip:<PHONE_NUMBER>40151A)
BaseThreadInitThunk at C:\WINDOWS\System32\KERNEL32.DLL (unknown line)
RtlUserThreadStart at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
Allocations: 863992 (Pool: 863525; Big: 467); GC: 1

Hit me for any additional info. Thank you

What is the content of custom_sysimage.jl at this point?

custom_sysimage.jl never gets created

It is not supposed to be created, you have to create it yourself.
If you are at this place https://juliacomputing.github.io/PackageCompilerX.jl/dev/devdocs/binaries_part_2/#Create-the-sysimage-1 in the tutorial, you need to create custom_sysimage.jl with the content showed there.

oh are you maybe talking about the create_sysimage.jl file? that is exactly the same as the one in the tutorial.

Yes.
Ok, can you put
Base.reinit_stdio()

in the top of the file and try agian.

Ok, that didn't sort any effect, what fixed it was creating an empty custom_sysimage.jl file in the directory. The same instruction that failed initially generated a consistent sys.o file!

Okay but that sysimage will not be good (it will not contain the stuff we want).

ahah ok. I thought I was going somewhere :) not in a good place apparently

Well, if it works with an empty file, something inside the file must cause it to crash.
If you leave out --output-o sys.o and run the same command, does it crash?
What if you only have
Base.init_depot_path()
Base.init_load_path()

@eval Module() begin
    Base.include(@__MODULE__, "MyApp.jl")
end # module

empty!(LOAD_PATH)
empty!(DEPOT_PATH)

in there?

Ok, I start grasping what's going on. First, I got confused by the documentation: at some point talks about custom_sysimage.jl, it actually just refers to the create_sysimage.jl that it just got created.
Following your advice, I edited the create_sysimage.jl to the following:
Base.init_depot_path()
Base.init_load_path()

@eval Module() begin
    Base.include(@__MODULE__, "MyApp.jl")
    for (pkgid, mod) in Base.loaded_modules
        if !(pkgid.name in ("Main", "Core", "Base"))
            eval(@__MODULE__, :(const $(Symbol(mod)) = $mod))
        end
    end
    for statement in readlines("app_precompile.jl")
	println(statement)
	Base.include_string(@__MODULE__, statement)
    end
end # module

empty!(LOAD_PATH)
empty!(DEPOT_PATH)

this prints the list of precompile insturctions. It fails here:

precompile(Tuple{getfield(Dates, Symbol("##s626#37")), Any, Any, Any, Any, Any, Any, Any, Any})
precompile(Tuple{typeof(Dates.character_codes), Type{Dates.DateFormat{Symbol("yyyy-mm-dd"), Tuple{Dates.DatePart{Char(0x79000000)}, Dates.Delim{Char, 1}, Dates.DatePart{Char(0x6d000000)}, Dates.Delim{Char, 1}, Dates.DatePart{Char(0x64000000)}}}}})
ERROR: LoadError: LoadError: Base.CodePointError{UInt32}(0x79000000)
Stacktrace:
[1] code_point_err(::UInt32) at .\char.jl:86
[2] Char(::UInt32) at .\char.jl:160
[3] top-level scope at string:1
[4] include_string(::Module, ::String, ::String) at .\loading.jl:1075
[5] include_string at .\loading.jl:1079 [inlined]
[6] top-level scope at C:\Temp\compile\PackageCompilerX\create_sysimage.jl:15
in expression starting at string:1
in expression starting at C:\Temp\compile\PackageCompilerX\create_sysimage.jl:5

I thought the
        catch
            # See julia issue #28808
            Core.println("failed to compile statement: ", statement)
        end

should take care of that.

Now it works. I think it is just my bad understanding of the documentation - I might eventually send a PR clarifying a few things, if that is ok.


Fix/plotdata

Time Estimate or Size
xsmall
Problem
getPlotData is typed to return Plot[] but when I logged what I got, it returns an object with {version: 1, data: Plot[]}, so I changed the functions to actually return Plot[]
Solution
Adjust the return of getPlotData to unpack the data
Type of change
Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
Breaking change (fix or feature that would cause existing functionality to not work as expected)

What about all the plots in our example trajectories that are displayed in the simularium-website? Do they go through a different code path than this? (would this change break them or are they already broken and this is fixing it?)

this is a breaking change, but the fix is really small: remove a .data when unpacking the data. I could have changed the typing but my thinking here is that the version is really for the internals of the viewer, and anyone consuming the plot data shouldn't be managing/caring about the version number

this is a breaking change, but the fix is really small: remove a .data when unpacking the data. I could have changed the typing but my thinking here is that the version is really for the internals of the viewer, and anyone consuming the plot data shouldn't be managing/caring about the version number

So the fix goes in simularium-website, or where? Is there already another PR that fixes the breakage?

this is a breaking change, but the fix is really small: remove a .data when unpacking the data. I could have changed the typing but my thinking here is that the version is really for the internals of the viewer, and anyone consuming the plot data shouldn't be managing/caring about the version number

So the fix goes in simularium-website, or where? Is there already another PR that fixes the breakage?

it's here https://github.com/simularium/simularium-website/pull/522

(Left an approval since I saw that this was urgent, but will defer to Dan since there was an existing discussion)


IRC to Matrix: cannot create filters for others users

Describe the bug
The bridge is running, I'm getting a lot of these messages though:
msg=Failed to POST JSON to /_matrix/client/r0/user/@myuser:matrix.org/filter code=403 wrapped=M_FORBIDDEN: Cannot create filters for other users
IRC -> Matrix messages are relayed
Matrix -> IRC are not
To Reproduce
No idea, I'm coming from a very old matterbridge version and just updated to latest stable, if this helps.
Expected behavior
I'd expect to not have this error and if related, to relay messages IRC <-> Matrix correctly.
Environment (please complete the following information):

OS: Linux
Matterbridge version: latest stable

Additional context
[matrix]
[matrix.mychanname]
Server="https://matrix.org"
MxID="@myid:matrix.org"
Token=""
Login="mylogin"
Password="mypassword"
NoHomeServerSuffix=true
UseUserName=false
IgnoreMessages="^~~ badword"
ShowJoinPart=false
ShowTopicChange=false
HTMLDisable=true

[general]
RemoteNickFormat="<{NICK}> "

[irc]
[irc.mychanname]
Server="myserverhostname:6697"
Nick="mynick"
UseTLS=true
SkipTLSVerify=true
UseSASL=true
NickServNick="mynick"
NickServPassword="mypassword"
#Flood control
#Delay in milliseconds between each message send to the IRC server
#OPTIONAL (default 1300)
MessageDelay=50
#Maximum amount of messages to hold in queue. If queue is full
#messages will be dropped.
#<message clipped> will be add to the message that fills the queue.
#OPTIONAL (default 30)
MessageQueue=50
#Maximum length of message sent to irc server. If it exceeds
#<message clipped> will be add to the message.
#OPTIONAL (default 400)
MessageLength=256
#Nicks you want to ignore.
#Messages from those users will not be sent to other bridges.
#OPTIONAL
IgnoreNicks="ircspammer1 ircspammer2"
#Messages you want to ignore.
#Messages matching these regexp will be ignored and not sent to other bridges
#See https://regex-golang.appspot.com/assets/html/index.html for more regex info
#OPTIONAL (example below ignores messages starting with ~~ or messages containing badword
IgnoreMessages="^~~ badword"
#RemoteNickFormat defines how remote users appear on this bridge
#The string "{NICK}" (case sensitive) will be replaced by the actual nick / username.
#The string "{BRIDGE}" (case sensitive) will be replaced by the sending bridge
#The string "{PROTOCOL}" (case sensitive) will be replaced by the protocol used by the bridge
#The string "{NOPINGNICK}" (case sensitive) will be replaced by the actual nick / username, but with a ZWSP inside the nick, so the irc user with the same nick won't get pinged. See https://github.com/4$
#Enable to show users joins/parts from other bridges
#Only works hiding/show messages from irc and mattermost bridge for now
#OPTIONAL (default false)
ShowJoinPart=false
#StripNick only allows alphanumerical nicks. See https://github.com/42wim/matterbridge/issues/285
#It will strip other characters from the nick
#OPTIONAL (default false)
StripNick=false
Charset="utf8"
UserName="myusername"
RealName="myrealname"
MessageClipped="<clipped message>"

[[gateway]]
    name = "mygateway"
    enable=true

[[gateway.inout]]
account = "irc.mychanname"
channel = "#mychanname"
[gateway.inout.options]
key = "myircchankey"

[[gateway.inout]]
account ="matrix.mychanname"
channel = "#myotherchanname:matrix.org"

That was due to a wrong mxid.


[Event Hubs] Use AwaitableSender in lieu of Sender

For more context refer to #3375

I think you need to update the version of rhea-promise to make use of the AwaitableSender. Currently seeing builds failures because the type is missing.

I think you need to update the version of rhea-promise to make use of the AwaitableSender. Currently seeing builds failures because the type is missing.

Discussed offline about this - the version update is part of #4228and so changes/merge from master would fix the build errors (after which current PR can be merged).
PR and code cannot be checked in anyway without build passing, hoping any concerns about the main issue, problem can be reviewed and surfaced as part of the review.
Otherwise, please see linked issue thread - https://github.com/azure/azure-sdk-for-js/issues/3375#issuecomment-515302962
The changes were successfully built on local, run and tested.

Hmm.. I see the discussion in https://github.com/Azure/azure-sdk-for-js/issues/3375#issuecomment-515302962 and understand the trouble behind sharing the timeout value between link creation and actual sending of the message.
This would need some changes in rhea-promise.
But for now, for the sake of this PR, lets pass the per try timeout set by the user as part of the options used to create the sender i.e set the sendTimeoutInSeconds option.
For send operations by the user where the sender is already created, this will result in exactly what we want.
For send operations by the user where the sender is not yet created, this will end up in doubling the timeout. We can fix this once https://github.com/amqp/rhea-promise/issues/49 is fixed.


fix(config): Fix Inovelli LZW31-SN Parameter 51

Parameter 51 ("Instant On") on the Inovelli LZW31-SN is currently described backwards: "Enable" disables instant on, and vice-versa.  Changed the description of the parameter to "Physical On/Off Delay", copied from the LZW31, which behaves correctly.  This way the two switches are also described consistently.

This parameter has already been corrected in pending PR #2247.


Update CI for deploy docs, warnings, and simplify

Describe the contribution
Fix #28, Deploy documentation
Fix #60, config warnings except for the new ones
introduced by using the latest deployment version
Fix #47, removes permissive mode hack and updates README.md
Adds enforce of no doxygen warnings for osal and users guide
Testing performed
Steps taken to test the contribution:

CI test

Expected behavior changes
Old CI script warnings resolved (2 remain based on using development version)
Now enforces no doxygen warnings for user guides
Will deploy documentation to gh_pages branch on push to master
System(s) tested on

CI system

Additional context
None
Contributor Info - All information REQUIRED for consideration of pull request
Jacob Hageman - NASA/GSFC

@astrogeco @jphickey could you review and merge this?  All just CI/README changes, and once this is in I can update the README to reference the deployment documentation (adds the cFE and OSAL user's guide auto-generated pdfs).  NOTE - I did only test it in my fork w/ special settings to make it work.  There is a chance it may fail the CI check on merge to master by another user, but I'll work with whoever does it to solve it ASAP.  Likely failure case could be the GITHUB_TOKEN, but documentation says collaborators should have access to mine.


Added Joke Teller project

This is a Joke Teller project which fetches programming jokes using an API and then converts it into an audio using another Text-to-Speech API and can be hosted on GitHub pages with its full functionality. This is also a responsive web app.
PS: Please add the Hacktoberfest label. Thanks

Thank you for contributing, @gauravbhaskar080. Please check your contribution on GitHub Pages.


Secret generation hangs on machines with close to no entropy

This can happen in virtual machines / clouds instances.
This has been observed on Digital Ocean and reported by @jcdominguez.
user@host$ gradle devshell
>> Werval DevShell for werval-gradle starting...
Isolating worlds...
Starting isolated Werval Application...
Application has no 'app.secret', generating a random one for development mode!
> Building 85% > :devshell

and
user@host$ gradle secret
:secret
>> Generate new Werval Application Secret
> Building 0% > :secret

Thats because we require a secure source of entropy when generating new secrets.
And in fact, if one wants good entropy he has to wait for it.
Secret generation occur when

one wants to generate a proper production secret
unit tests with no secret defined in configuration
development mode with no secret defined in configuration

For 1 there's nothing to do except use a system with enough entropy.
For 2 and 3 we could generate the temporary secrets with a loosy entropy. They are temporary after all. The only benefit would be allowing running tests and dev mode in badly setup cloud VMs. Could prove usefull for some CI systems for example.

Workaround for Digital Ocean Ubuntu Droplets:
install haveged
See:
https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Thanks @jcdominguez.
Looks like haveged is packaged for most of the linux distributions, good.


Bug: Fix serial mode.

Serial mode wasn't actually waiting for previous tasks to finish before spawning the next.
/cc @mhink

Codecov Report

Merging #29 (2b82c26) into main (07a1efc) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #29   +/-   ##
=======================================
  Coverage   99.14%   99.14%
=======================================
  Files          13       13
  Lines         351      351
=======================================
  Hits          348      348
  Misses          3        3

Impacted Files
Coverage Δ

lib/actions/package.js
100.00% <100.00%> (ø)

lib/util/promise.js
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 07a1efc...2b82c26. Read the comment docs.

Released in<EMAIL_ADDRESS>


[Bug]: The details of the database permission application ticket are inconsistent with those displayed on the UED

ODC version
4.3.2
OB version
no related
What happened?
The details of the database permission application ticket are inconsistent with those displayed on the UED

What did you expect to happen?
The details of the database permission ticket should be the same as those displayed in the UED
How can we reproduce it (as minimally and precisely as possible)?
Initiate a database permission application ticket to view the ticket details
Anything else we need to know?
No response

Fixed In Commit 9ec5ef705eea3bacdc1619f6bb9cd43dfe261219
------
畅晚
Wed Sep 25 16:02:09 2024 +0800

The problem still exists

Fixed In Commit 65b92a945308b43628795d6f1a651ebdbfda03e1
------
畅晚
Thu Sep 26 15:23:52 2024 +0800

pass


We need more examples about async api

Is your feature request related to a problem? Please describe.
I can find some examples at grpc/examples/cpp.
But the only example about async api is greeter_async_server.cc.
I wonder, what should I do if I need more than one rpc method.
Just like this:
`// Copyright 2015 gRPC authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
syntax = "proto3";
option java_multiple_files = true;
option java_package = "io.grpc.examples.helloworld";
option java_outer_classname = "HelloWorldProto";
option objc_class_prefix = "HLW";
package helloworld;
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply) {}
rpc SayByeBye (ByeByeRequest) returns (ByeByeReply) {}
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings
message HelloReply {
string message = 1;
}
// The request message containing the user's name.
message ByeByeRequest {
string name = 1;
}
// The response message containing the farewells
message ByeByeReply {
string message = 1;
}
`
If my server need to reply ByeByeRequest(), how can I distinguish the different method(HelloRequest and ByeByeRequest), use different completion queue?

I write an example to solve the problem.
https://github.com/DinoStray/grpc_example_async_cpp_api

Did you mean to link to another repo? This has just one rpc function in the service
//  grpc_example_async_cpp_api/protobuf/greeting.proto
syntax = "proto3";
package grpc.example;

service GreetingService {
    rpc SubscribeGreetingBySecond (stream RequestSubscribe) returns (stream ReplyGreeting) {
    }
}

If anyone stumbles upon this.. follow this

add a bool parameter to CallData (hello_ in this example), instantiate two CallData objects, one with hello_ = true, and one with hello_ = false, and have each one request a different RPC.

Also can use enums or create subclasses of CallData to deal with multiple requests.


Add 'IF NOT EXISTS' to prevent duplicate table exception

PR for issue #2060: Avoid exception handling for PostgresTarget.create_marker_table() with "CREATE TABLE IF NOT EXISTS"

Description
adding Postgresq IF NOT EXISTS clause in order to avoid having to rely on a exception handling when the marker_table already exists
Motivation and Context
Fix issue #2060
Have you tested this? If so, how?
Not tested directly, but the SQL query is valid for Postgresql since version 9.1

I have updated the code; it seems that the PR is automatically updated and tests are run also, which means I have nothing more to do... is that right?

Can you find somebody to review this code? Somebody who knows about the technologies (postgres?) this PR touches upon.

Isn't the luigi/test/postgres_with_server_test.py file supposed to do so?
I am more fluent in (postgre)sql than Python, so I know the query is working. I crafted quickly 2 sqlfiddle here and they do not return any error:

http://sqlfiddle.com/#!15/d1587 : CREATE TABLE IF NOT EXISTS with values inserted => OK
http://sqlfiddle.com/#!15/b33421 : (CREATE TABLE IF NOT EXISTS twice and then values inserted => OK

I don't know if it is enough as a code review; maybe some people using Redshift could also confirm that, as Redshift as the same feature (see http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_CREATE_TABLE_NEW.html)

I think it helps to have real humans look at code. Also you'll learn more if you get feedback from peers. :)
If however noone volunteers for a few days or a week. I'm fine with just merging this.

I'll have a look at it today.
-s.
Sent from my iPhone

On Mar 16, 2017, at 6:13 AM, Arash Rouhani<EMAIL_ADDRESS>wrote:
I think it helps to have real humans look at code. Also you'll learn more if you get feedback from peers. :)
If however noone volunteers for a few days or a week. I'm fine with just merging this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

If no one else reviews, I'll merge this soon. Thanks


Vacuum Chest NBT tag check

Issue Description:
This isn't a bug in EnderIO per se, but it does affect it's usage with my mod. I'm making a mod called Demagnetize which applies the PreventRemoteMovement NBT tag to items around the Demagnetizer, which prevents them from being picked up from Item Magnets.
This behaviour works very well with the Electromagnet from this mod, but the Vacuum Chest also checks this NBT tag. As it isn't a magnet, it shouldn't be prevented from picking up these items; however removing this check would break compatability with Immersive Engineering's Conveyors, as it stops items being removed from conveyors. I have posted a similar issue on the CoFH issue tracker for the Vacuumulator, as it is the only other "Vacuum" block that checks this NBT tag.
I therefore propose that a check for an extra NBT tag be added, called AllowMachineRemoteMovement (or similar) that permits machines (but not item magnets) to remotely move items with it. It should only be checked if PreventRemoteMovement already exists on the EntityItem, to enable compatibility with existing mods.
If PreventRemoteMovement exists and AllowMachineRemoteMovement also exists, machines can remotely move items, but magnets cannot. If PreventRemoteMovement exists but AllowMachineRemoteMovement doesn't exist, neither machines nor magnets can remotely move items.
What happens:
The Vacuum Chest doesn't pick up the items.
What you expected to happen:
The Vacuum Chest should pick up items that have been Demagnetized, as it is not a magnet.
Steps to reproduce:

Place a Vacuum Chest
Place a Demagnetizer within 4 blocks
Drop an item
The item is not picked up

Affected Versions (Do not use "latest"):

EnderIO: 5.0.26
EnderCore: 0.5.31
Minecraft: 1.12.2
Forge: <IP_ADDRESS>15
Demagnetize: <IP_ADDRESS>
SpongeForge? no
Optifine? no
Single Player and/or Server? Singleplayer tested (applies to both)

The main code that handles this is in EnderCore.
Your most recent log file where the issue was present:
https://paste.ee/p/DB7Dt (probably not that useful though, there are no relevant errors in it)

It appears that this wasn't implemented correctly for the Vacuum Chest, and instead it runs the method shouldAttract(@Nullable BlockPos pullerPos, @Nullable Entity entity, boolean isMachine) with false on the isMachine argument, causing it to not suck any items "modified" by any demagnetization mod.
Is this intentional?

Darn, I messed up. Sorry and thank you.


Containerize method evaluation

docker inside snakemake
require that we have the Dockerfile
require that all dependencies are pinned (via pip freeze)

[ ] convert evaluate.py into snakemake
[ ] one rule per method
[ ] method name in config

for task in tasks:
    for dataset in task.datasets:
        adata = dataset.load()
        save(adata, "temp.h5ad")
        for method in task.methods:
            docker_method(method, "temp.h5ad")
            for metric in task.metrics:
                result = docker_metric(metric, f"{method}.h5ad")

def docker_method(method, filename):
    adata = load(filename)
    method(adata)
    save(adata, f"{method}.h5ad")

def docker_metric(metric, filename):
    adata = load(filename)
    result = metric(adata)
    return result

@LuckyMD we now have a snakemake pipeline that generates the results files. We need to swap in docker containers for:

methods (https://github.com/singlecellopenproblems/SingleCellOpenProblems/blob/master/scripts/run_method.py)
metrics (https://github.com/singlecellopenproblems/SingleCellOpenProblems/blob/master/scripts/evaluate_metric.py)

and then this should be done.

Corresponding lines of the snakemake file:

method: https://github.com/singlecellopenproblems/SingleCellOpenProblems/blob/master/scripts/Snakefile#L119
metric: https://github.com/singlecellopenproblems/SingleCellOpenProblems/blob/master/scripts/Snakefile#L110

Not sure exactly what this will look like but assuming we can mount access to the file system, we could just run those existing python scripts inside the docker container.

I just wanted to commit the Dockerfile quickly so that we have sth to test: #85
I haven't tested running anything inside yet. But I guess if you have the script that should be easy to test, no?

I can try to find out how to mount volumes in a snakemake rule if you want.

Yes, that would be great!

According to this you specify volumes to mount in the command. So you would run sth like:
snakemake --use-singularity ---singularity-args "-v /path/outside/container:/path/inside/container"
Also, it seems as though you have to have the image built already, and it doesn't build this automatically.
And, I haven't set up a particular folder structure in the docker container yet. What would you like to have? :)

@LuckyMD any reason why you're installing python from source and not just using https://hub.docker.com/r/rackspacedot/python37 ?

I was looking at the python images and wanted one based on debian so I could use apt-get. It was really only a question of convenience. I'm not familiar with alpine and all. Didn't see rackspacedot (and not sure what that is).

Okay cool. The rackspacedot image has 60M downloads and is based on Debian
Stretch so that should be fine - just saves us having to compile python
from source.
On Thu, 8 Oct 2020, 4:23 am MalteDLuecken<EMAIL_ADDRESS>wrote:

I was looking at the python images and wanted one based on debian so I
could use apt-get. It was really only a question of convenience. I'm not
familiar with alpine and all. Didn't see rackspacedot (and not sure what
that is).
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/singlecellopenproblems/SingleCellOpenProblems/issues/74#issuecomment-705413064,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACA3DX77TB4YLKNUUV2JUGLSJVZGZANCNFSM4RUW5J7A
.

yeah, that sounds much faster to build ;).


Show replies in context of their threads

Resubmit of https://github.com/bluesky-social/social-app/pull/4835.
What
This rewrites our feed slicing logic which determines how posts (and in particular replies) appear in the feed.
It aims to fix a few problems:

Replies now appear within the context of their parent threads. This avoids out-of-context replies.
Replies from the same thread don't appear again in your Following feed. In other words, replies from friends "bump" threads but you only see the most recent reply to any given thread. This avoids a single thread dominating the timeline.
Replies no longer get "torn off" from their parent conversations due to a pagination boundary.
Replies from friends no longer get "torn off" from the original "author threads" that they belong to. In fact we're removing special casing of an "author thread". This means https://github.com/bluesky-social/social-app/pull/2914 can be closed.
Lists now use the Following feed settings (and no longer show replies from non-follows).

We probably still want to do this but I'll send a separate PR later — not part of this change.

"Hide replies" no longer hides reposted replies (since someone you follow wanted to treat it as a top-level).

How
This builds on changes from https://github.com/bluesky-social/social-app/pull/4834, https://github.com/bluesky-social/social-app/pull/4864, https://github.com/bluesky-social/social-app/pull/4868, and https://github.com/bluesky-social/social-app/pull/4869. I've made the "feed slice" encapsulate more of the "building up items" logic so that it's able to reuse parent and root from the response despite those not having a reply.
What we show on the screen is now much closer to the data shape returned by the server — essentially, we show [root, ..., parent, reply] for each item. In Following feeds, feedgens, and lists, we deduplicate by the root so that each thread acts as a forum thread — you only see it once (but replies from friends bump it). In author feeds (Posts and Replies), we use a different deduplication strategy: you want to see all relevant posts, so we instead hide contiguous leading sequences of posts that you have already seen. See comments in code for specific scenarios.
Examples
Here's a broken up thread (before):

Here's how this PR fixes it (after):

Here's an out-of-context reply (before):

Here's how this PR adds context to it (after):

Here's a reply from somebody I follow to somebody I don't follow (before):

There is no "after" for this example because we'd no longer show the above replies in Following in this PR.
Here is a "torn" reply to another person's thread (before):

Here is how this PR fixes it:

Test Plan
Here's some things I encourage you to test:

Following feed

Different settings (hide replies, hide reposts, hide quotes)
Mergefeed on and off
Move Following to first position on an account that doesn't follow anyone, verify Discover fallback works
Verify you only see people you follow for each root/parent/reply
Replies from a seen thread should not appear below
Repost of a non-leaf reply should not break the thread, both should remain visible
Reposts of same post by different follow should remain deduped
Replies with deleted and blocked parents or roots should not show up
Replies with blocked grandparents should not show up
When parent and grandparent authors are different in a >=3 post thread, "in reply to" is displayed
"Has new" polling and button works

Feedgens

Replies from a seen thread should not appear below

Pushed a commit that makes it work like Profile instead — see https://github.com/bluesky-social/social-app/pull/4871#issuecomment-2266940374

Replies with deleted and blocked parents or roots should not show up
Replies with blocked grandparents should not show up
When parent and grandparent authors are different in a >=3 post thread, "in reply to" is displayed
"Has new" polling and button works

Starter Packs

Posts tab should work like Following

Profile

Should deduplicate individual posts but should not deduplicate threads
Contiguous leading blocks should get deduplicated top-down (threads like [ABC], [ABD], [AEF] become [ABC], [D], [EF]). You should see "in reply to" for [D] and [EF] since their parent/roots got deduplicated.
Replies with deleted and blocked parents or roots should (!) show up for Replies tab
Replies with blocked grandparents should (!) show up for Replies tab

Lists

Should work like Profile (deduplicate by leading posts, but not by threads)
We'll probably change it to work more like Following later, but out of scope of this PR

Pushed a commit that turns off thread deduping for feedgens. The motivation is that feedgens are already able to do thread deduping if they want to. So if a feedgen is serving a bunch of replies from the same thread, it must have a reason to do so and we shouldn't hide those. Instead we'll rely on contiguous leading post deduping for feedgens, same as for author feeds.

Pushed a revert to the Lists part of the deal. We probably still want to do it but decoupling from this already chunky change.


Dangerous use of pull_request_target

Description
Hi, I am Joyce working on behalf of Google and the OpenSSF.
The project has one workflow with dangerous or risky behavior (identified by using the Scorecard tool), which is the https://github.com/nlohmann/json/blob/develop/.github/workflows/check_amalgamation.yml.
The pull_request_target should not be used with a checkout  as can be seen in the following warning from the Github Documentation Page:

Reproduction steps
None
Expected vs. actual results
Analysing the workflow and looking at the more secure alternatives, I could think in two approaches:
Use pull_request
Instead of using pull_request_target, we could use the pull_request which would change the current behavior in two ways:

The verifications would be done in a "merge commit"
The workflow would not be granted the read-all and write-all permission that make it dangerous.
EDIT: Create a workflow with a workflow_run trigger in another workflow to add the comment

Use label verification
We can use a type: [labeled] and a condition of if: ${{ github.event.label.name == 'is ok to test' }} to check for a label "is ok to test" for example, that you would manually add once you saw that nothing potentially dangerous would be running.
That's the two solutions I though, but let me know if you know another one we can explore. I can open a PR with any solution we agree on this issue.
Minimal code example
No response
Error messages
No response
Compiler and operating system
None
Library version
None
Validation

[ ] The bug also occurs if the latest version from the develop branch is used.
[ ] I can successfully compile and run the unit tests.

Any help is appreciated here!


Add Trino support to Airflow integration

@treysp wasn't this added as part of https://github.com/TobikoData/sqlmesh/pull/2188?

I think so - sorry, didn't catch it when that PR was merged


Unable to print recovery codes

When viewing recovery codes in the frontend MFA app (after registering a first method), selecting the 'Print codes' button does nothing.
Console error: Uncaught TypeError: Cannot read property 'cloneNode' of undefined
Browser: Chrome Version 75.0.3770.100 (Mac OSX)
Notes

There's different issues for the CMS version of this, see #223

Was this in the frontend or admin?

Sorry, this was frontend. I've updated the description.

Reproduced

I'll do this as part of #223

PR at https://github.com/silverstripe/silverstripe-mfa/pull/228

Heads up this is still an issue on the 3 branch
bundle.js?m=1563836177:1 Uncaught TypeError: Cannot read property 'cloneNode' of undefined
    at e.print (bundle.js?m=1563836177:1)
    at t.value (bundle.js?m=1563836177:1)
    at Object.i (bundle.js?m=1563836177:1)
    at a (bundle.js?m=1563836177:1)
    at l (bundle.js?m=1563836177:1)
    at c (bundle.js?m=1563836177:1)
    at p (bundle.js?m=1563836177:1)
    at f (bundle.js?m=1563836177:1)
    at h (bundle.js?m=1563836177:1)
    at Ie (bundle.js?m=1563836177:1)

We haven't backported the latest round of changes from the SS4 version yet - from memory #228 will be one of those changes