F-Droid version

Hi! Is possible load the last version of your app on F-Droid repo (is stop to 5.3.0)??

I am not involved in or maintain the F-Droid builds.
Please ask F-Droid (I guess their forums?) to trigger new builds (or to re-enable the automatic builds).

To clarify: The original setup I agreed with the person adding it to F-Droid was that pushing tags would trigger new builds.
However that soon failed, because someone had modified the build rules while neither informing him or me.
This issue then seems to have been "resolved" by completely disabling that automatic update mechanism, yet again without informing neither me nor the original author of the F-Droid build rules.
As much as I like F-Droid in principle, I've dealt with enough distributions (Linux/BSD side) that I now for my own sanity simply refuse to work with those that don't make an effort to talk to upstream and get issues fixed PROPERLY.
If someone from F-Droid wants to talk to me and make all this work smoothly, I am here to discuss though.

I am very sorry to hear things a working out so badly. Looking at our git tree, the original submitter's last activity was on December 2015... the same month the app got included. Unfortunately, we have a lot of one-shot-submitters, only a couple stay to maintain the builds. Most of the work is done by 1-2 "global" maintainer, like myself, and sometimes work just stays undone and might be forgotten.
I updated the app from time to time, since automatic updates have been disabled -- looking at the git history because the build broke down as a newer utils version was required, so it was not an actual upstream issue.
There currently is a merge request open at https://gitlab.com/fdroid/fdroiddata/merge_requests/1971 to update the app and re-enable automatic updates. How would you like to proceed:

Go ahead, and risk it breaking when newer util versions is needed.
Stay on manual updates, and hope for the current submitter to take maintainership.
Get more closely involved into maintaing this yourself.
... other options?

Hi!
I appreciate that you probably are about as short on time as I am, so thanks for responding.
Maintaining this myself or other solutions that require a continuous effort from me are not really a good option. For the rest, I feel it is more a question for you, how would you like to handle it?

Just enabling automatic updates is better than nothing as Utils will be rarely updated - but it is risky as it might subtly break
Originally the idea was to always build against HEAD of Utils - I assume that this was considered undesirable (which I can understand), but it should work fine and not break with auto-updates.
And alternative to building against HEAD that we discussed was to ALSO tag Utils with the same release tags
While I still think git submodules create as many problems as they solve, it sometimes is better supported. If it would solve the problem in the most convenient way to you, I'm fine with switching over to making Utils a git submodule.

I want a solution that means minimal effort for both of us long-term (and it is the reason why it bothers me a lot when distributions don't complain to me when my code creates problems for them).

Personally I would go with submodules or building against head. Submodules are easy to setup for us while using head makes our linter scream. I will check with some guys resposnible for the fdroid server tools and report back here. For now I just enabled the automatic updates.

I switched it to a submodule. I don't have a new release tag since, but maybe it's enough for you to update the build config already now? Might be a bit before I make the next release, I have a couple of things to do for that.
One reason among many I do not like submodules is due to such user-hostile defaults as not making --recursive the default for git clone, which makes it a pain if you have to work with people who are not that familiar with git (their motto is obviously "make trivial things as difficult as possible").

Thanks for going through the extra hassles, I am quite aware of the.. shortcommings.. of submodules... sigh. I talked to our devs and  they are not really fond of using head, but at least our linter wouldnt complain when using a specific branch (while still being strongly discouraged). Anyway, now submodules it is.
One last thing: Could I ask you to not use versioncode 81 for the next release, but anything above? I'd like to use 81 internally for setting up the template used for the automatic update.

Sure, I changed it to 82 locally, so hopefully I'll remember to skip 81 for the next release.

Thanks, that helps a lot :).
If anything is broken or updates dont work, feel free to ping me directly.


[Bug] Camel Route Debug - breakpoint doesn't hold a route

Hello @tadayosi
I have found unusual behaviour of Camel Route Debug when a breakpoint is added.
My understanding is the following - when the breakpoint is added, the exchange is on hold on the node where the breakpoint was set and you have two options - either click on Step (next) or click on Resume to continue the exchange.
However, when I tried to add the breakpoint, I see that the numbers (see the attached screenshot) are still counting and as I understand the exchange is not on hold and continues anyway.

Is it expected behaviour or it's a bug?
Thank you

I have seen this a few times and assumed it was exchanges 'catching up'. I did do some 'debugging' (ha!) on it a while back and found it goes all the way down to the camel route in that the JMX flags are all properly set but things seem to keep going.

@mmelko Could you take a look at it along with your PF 5 upgrade work?

@tadayosi don't think this is related to PF5 at all. I've tested also on old hawtio 2.18 and the behaviour is practically the same. Although we do have some regression happening here.

@mmelko I see it's not related to PF5. I was asking it because you're the author of the Debug feature 🙂
If you can explain to Juri why it's the expected behaviour then we can close it.

@tadayosi no it was done by @phantomjinx .
@jsolovjo if I understand correctly the excange actually is on hold, but the number of exchanges looks suspicious. When I click on step I can see the numbers sort of correctly:
this is your state:

however on the next steps:

I will double check the stats.


surface: linux 6.6.6 -> 6.6.8

Description of changes

surface: linux 6.6.6 -> 6.6.8

linux-surface: arch-6.6.4-1 -> arch-6.6.6-1

Tested on Surface Laptop 4 AMD

Things done

[X] Tested the changes in your own NixOS Configuration
[X] Tested the changes end-to-end by using your fork of nixos-hardware and
importing it via <nixos-hardware> or Flake input

@mergify queue


Changed the How to Play section in the readme

Updated the how to play section. Now there is two separate how to play instructions for both developers and end users.
fixed #8

Can you please remove the 'How to Play(For Developers)' section?
And only keep the section name as 'How to Play' without any extra information.

ok

@saurabh190802
Looks good now!

Looks good! 🔥
Thank you for contributing. Don't forget to leave a star if you liked the project! ⭐
If you have any queries related to this project or want to connect with me, feel free to DM me on Twitter. My Twitter username is @pushkaraj2007 🤝

ya sure


[HW]

Name:
Email<EMAIL_ADDRESS>Linkedin Profile: https://www.linkedin.com/in/vikas-anand-93380620b/
Attach the homework step I screenshots below:

Attach the homework step II screenshots below:

duplicate submission


[RELEASE] Preparation for release of v0.1.4

This PR makes updates in preparation for release of 0.1.4

[x] once merged we can setup a new tag release for PyPI and conda-forge

thanks @choldgraf bumped the header levels.


Fix for issue #1942 'cargo run fails if called from executable folder'

It maybe a tacky way, but I think that changing util::without_prefix is a bad approach. Maybe modify process.build_command could be another possible approach.
It could be worth to take more time to be sure to find the root of the problem. I am quite new to rust, if anybody can point out the right way of dealing with it, I will be happy to submit a new PR.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Whoa, fascinating! This does kinda make sense as an error case though, as I believe when running the program foo it looks for the binary in PATH, not the current directory. Could you update this to perhaps change the path to ./foo instead? You can do something like:
Some(path) if path.components().len() == 1 => Path::new(".").join(path),
Some(path) => path,
// ...

Also, can you add a test for this as well? Thanks!

Great. Thanks for the suggestion. I will do it as soon as possible and update the PR.

I've fixed the function using pattern matching in a spirit similar to what you suggested.
At the moment it looks like this (in text_caro_run.rs)
use std::fs;
use std::process::Command;

test!(run_from_target_folder {
    let p = project("foo")
        .file("Cargo.toml", r#"
            [project]
            name = "foo"
            version = "0.0.1"
            authors = []
        "#)
        .file("src/main.rs", r#"
            fn main() { println!("hello"); }
        "#);

    let cwd = p.root().join("target").join("debug");
    println!("\nDir: {:?}\n", cwd);
    match p.cargo_process("build").exec_with_output() {
        Ok(output) => println!("{:?}", String::from_utf8(output.stdout)),
        Err(e) => println!("Err: {:?}", e)
    };

    println!("");
    match p.cargo_process("run").exec_with_output() {
        Ok(output) => println!("{:?}", String::from_utf8(output.stdout)),
        Err(e) => println!("Err: {:?}", e)
    };

    println!("");
    match fs::metadata(&cwd) {
        Ok(metadata) => println!("Ok: is {} a dir? {:?}", &cwd, metadata.is_dir()),
        Err(e) => println!("Err: {:?}", e)
    }

    println!("");
    match Command::new("ls").current_dir(&cwd).output() {
        Ok(output) => println!("LS: {}", String::from_utf8(output.stdout).unwrap()),
        Err(e) => println!("Err: {:?}", e)
    };

    let mut pr = p.cargo_process("run").build_command();
    pr.current_dir(&cwd);
    match pr.output() {
        Ok(output) => println!("{:?}", String::from_utf8(output.stdout)),
        Err(e) => println!("Err: {:?}", e)
    };

    assert_that(p.cargo_process("run").cwd(cwd),
                execs().with_status(0).with_stdout(&format!("\
{compiling} foo v0.0.1 ({dir})
{running} `./foo`
hello
",
        compiling = COMPILING,
        running = RUNNING,
        dir = path2url(p.root())
        )));
});

Including all other attempts I've done and the statements I am using for debugging.
Output:
failures:

---- test_cargo_run::run_from_target_folder stdout ----

Dir: "/Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/cit/t0/foo/target/debug"

Ok("   Compiling foo v0.0.1 (file:///Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/cit/t0/foo)\n")

Ok("   Compiling foo v0.0.1 (file:///Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/cit/t0/foo)\n     Running `target/debug/foo`\nhello\n")

Ok: is "/Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/cit/t0/foo/target/debug" a dir? true

LS: build
deps
examples
foo
foo.dSYM
native

Err: Error { repr: Os { code: 2, message: "No such file or directory" } }
thread 'test_cargo_run::run_from_target_folder' panicked at '
Expected: execs
    but: could not exec process `/Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/debug/cargo run`: Could not execute process `/Users/marcelloseri/Desktop/works_in_progress/code/rust/cargo/target/debug/cargo run` (never executed)
caused by: os error', /Users/marcelloseri/.multirust/toolchains/stable/cargo/registry/src/github.com-0a35038f75765ae4/hamcrest-0.1.0/src/core.rs:22

I've tried to solve it in different ways but cannot understand what I am doing wrong. Can you give me any hint?

Oh you'll probably want to switch from cargo_process to cargo in some of those calls, the former blows away the preexisting tree while the latter just builds up the Command as usual.

Great, thanks! I've cleaned it and pushed.

@bors: r+ 33530797a4496c64912b5ae1e58d8baf07020098
Thanks!

:hourglass: Testing commit 3353079 with merge 1d0823b...

:sunny: Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64


Error Expecting value: line 1 column 1 (char 0) occur when start taining

Error Expecting value: line 1 column 1 (char 0) occur when start taining

please supply a screenshot of log and which system you are using.

please supply a screenshot of log and which system you are using.

base window10 use conda virtual environment
sys.platform: win32
Python: 3.8.17 (default, Jul  5 2023, 20:44:21) [MSC v.1916 64 bit (AMD64)]
CUDA available: True
GPU 0: NVIDIA GeForce RTX 4090
CUDA_HOME: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.7
NVCC: Cuda compilation tools, release 11.7, V11.7.64
MSVC: 用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.37.32822 版
GCC: n/a
PyTorch: 2.0.1+cu117
PyTorch compiling details: PyTorch built with:

C++ Version: 199711
MSVC 193431937
Intel(R) Math Kernel Library Version 2020.0.2 Product Build 20200624 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v2.7.3 (Git Hash 6dbeffbae1f23cbbeae17adb7b5b13f1f37c080e)
OpenMP 2019
LAPACK is enabled (usually provided by MKL)
CPU capability usage: AVX2
CUDA Runtime 11.7
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86;-gencode;arch=compute_37,code=compute_37
CuDNN 8.5
Magma 2.5.4
Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.7, CUDNN_VERSION=8.5.0, CXX_COMPILER=C:/actions-runner/_work/pytorch/pytorch/builder/windows/tmp_bin/sccache-cl.exe, CXX_FLAGS=/DWIN32 /D_WINDOWS /GR /EHsc /w /bigobj /FS -DUSE_PTHREADPOOL -DNDEBUG -DUSE_KINETO -DLIBKINETO_NOCUPTI -DLIBKINETO_NOROCTRACER -DUSE_FBGEMM -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_DISABLE_GPU_ASSERTS=OFF, TORCH_VERSION=2.0.1, USE_CUDA=ON, USE_CUDNN=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=OFF, USE_NNPACK=OFF, USE_OPENMP=ON, USE_ROCM=OFF,

TorchVision: 0.15.2+cpu
OpenCV: 4.8.0
MMCV: 1.7.0
MMCV Compiler: MSVC 193732822
MMCV CUDA Compiler: 11.7
MMDetection: 2.26.0+e224989

Please provide more detail message on the command terminal.

Please provide more detail message on the command terminal.

nothting print on the Anaconda Prompt window

try following steps：

pip upgrade gradio
close VPN or Firewall

try following steps：

pip upgrade gradio
close VPN or Firewall

both are checked ;
the error occur after i pull new code from repo

碰到了同样的问题

Same problem

issue closed by lastest code updated


Scripting a quarter circle movement into a macro

Does anyone know how to properly add a quarter circle forward into the script for a macro? Thanks in advance for any help you can offer.

Is this for the dpad? I'm guessing you're building a macro where you're writing out the dualshock states in an order? Assuming both of those are true you'd do something like:
Press(new DualShockState() { DPad_Down = true }, 900);
Press(new DualShockState() { DPad_Down = true, Dpad_Right = true }, 900);
Press(new DualShockState() { DPad_Right = true }, 900);
You may need some sleeps in between and may need to adjust the button press durations.

Is this for the dpad? I'm guessing you're building a macro where you're writing out the dualshock states in an order? Assuming both of those are true you'd do something like:
Press(new DualShockState() { DPad_Down = true }, 900);
Press(new DualShockState() { DPad_Down = true, Dpad_Right = true }, 900);
Press(new DualShockState() { DPad_Right = true }, 900);
You may need some sleeps in between and may need to adjust the button press durations.


[Feature]: Flag to cap/exclude Audit Logs from instance backups using appsmithctl

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
There should be a flag to cap or disable audit logs when taking an instance backup using appsmithctl.
Why should this be worked on?
We are trying to restore a prod backup into a lesser environment and can’t due to the audit log being so huge from prod.  6GB

Libre also has a need for this feature


Create Helm Charts

Request
Create Helm Charts to run a cluster of vertex services easily in Kubernetes with Terraform/Tofu
Why is this needed?

To start Vertex easily

Repository: https://github.com/vertex-center/helm-charts

Done with https://github.com/vertex-center/charts and https://github.com/vertex-center/tf


refactor(deps): for go 1.13

Golanglint-ci and goreleaser are currently broken due to dependencies not being compatible with go1.13.


[Decompile] vector.gc (finally)

I think we now have everything to decompile vector.gc.
Current this is about half of it + tests.  Everything out of the decompiler seems to be correct.  Most of the work is figuring out their crazy naming conventions (what does vector-v*float++! mean??) and writing reasonable doc strings.

Pull Request Test Coverage Report for Build 791084048

32 of 32 (100.0%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 69.247%

Totals

Change from base Build 790847500:
0.02%

Covered Lines:
34118

Relevant Lines:
49270

💛  - Coveralls

vector-cross! will return junk in w - need to update the tests to not print this.


fix(spanddl): support dropping interleaved table

test(spanddl): possibility to specify expected error for ddl statement
feat: throw error if dropping table with interleaved tables
fix(spanddl): support dropping interleaved table

Codecov Report
Attention: 309 lines in your changes are missing coverage. Please review.

Comparison is base (762bfd8) 44.66% compared to head (27e15aa) 43.45%.
Report is 196 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files

@@            Coverage Diff             @@
##           master     #501      +/-   ##
==========================================
- Coverage   44.66%   43.45%   -1.22%
==========================================
  Files          21       20       -1
  Lines        4267     4582     +315
==========================================
+ Hits         1906     1991      +85
- Misses       2249     2483     +234
+ Partials      112      108       -4

Files
Coverage Δ

internal/codegen/databasecodegen/common.go
100.00% <100.00%> (ø)

...nternal/codegen/databasecodegen/readtransaction.go
100.00% <100.00%> (ø)

spanddl/database.go
72.41% <100.00%> (+21.62%)
:arrow_up:

spanddl/table.go
29.46% <0.00%> (ø)

internal/examples/freightdb/descriptor_gen.go
0.00% <0.00%> (ø)

internal/examples/musicdb/descriptor_gen.go
5.55% <0.00%> (-1.47%)
:arrow_down:

internal/examples/freightdb/database_gen.go
23.28% <41.37%> (+0.07%)
:arrow_up:

internal/examples/musicdb/database_gen.go
17.20% <6.29%> (-3.57%)
:arrow_down:


Implemented new auth method access token of GCE(Google Compute Engine)

This pull-request contains new implementation that enable to use GCE pre-defined access token authentication.
If we add devstorage.read_write scope when creating GCE VM instances,
we don't have to set both service_account_email and p12_keyfile_path options.
Because we can get OAuth access-token in GCE VM instances like below.
$ curl "http://metadata/computeMetadata/v1/instance/service-accounts/default/token" -H "X-Google-Metadata-Request: True"
{"access_token":"XXXXXXXXXX","expires_in":3599,"token_type":"Bearer"}

Super! Thanks.

@sakama I release v0.2.0 include #2 #3 #4. Thanks for contributions!

Thanks. I'll try it!!


FPGA: switch from dpcpp to icpx on Linux and icx-cl on Windows

This PR removes the use of the dpcpp compiler to make use of:

icpx on Linux
icx-cl on Windows

A previous change (https://github.com/oneapi-src/oneAPI-samples/commit/5e7bbf6b260063210809b71961844b7c164e8c52) unified the compile commands of all the samples to be using the Linux style on both platforms as dpcpp allowed for it.
This PR reverts this changes as the icpx compiler cannot be used on Windows with cmake at the moment, but we need to move away from dpcpp. Therefore we are using icx-cl on Windows with the Windows style command flags.

Hey @jimmytwei, could you review/approve this change for us to merge it?
This is fairly urgent as this is preventing us from correctly test our samples
Many thanks!

Added @ishaghosh27 for READMEs. @xmnboy: Paul F, is having toolchain": ["icpx -fsycl"] in sample.json valid? I want to double check with you to make sure it doesn't break the sample browsers

@yuguen-intel -- yes that will cause a failure in the aggregator when checking the sample.json files. Just use icx to identify the toolchain -- there is no need to include any options. It is used as a filter by the sample browsers.
I do see, however, that we may have to update the aggregator's sample.json schema checker that it needs to include icx-cl and icpx-cl as valid "toolchain" attribute. Or, we just use only icx and icpx to indicate the toolchain. Again, the "toolchain" attribute is used as a filter, it does not impact any build files (cmake, make, proj, etc.) that are part of the sample.

@xmnboy Thanks Paul. @yuguen-intel Can you update all of the sample.json files to use icx?

I'm not sure which of the binaries are present in the currently released compiler.
However, this change is relevant for the upcoming 2023.0 release - but we don't expect any user to use the master branch of the code samples: they should used the tagged version of the code samples


[KAFKA-10722] doc: Improve JavaDoc for KGroupedStream.aggregate and other similar methods

Tell that the store used internally is always a timestamped one.
This is related to KAFKA-10722.
No tests are necessary because only JavaDoc was changed.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

???

I've made the changes (rather mechanically) as requested.

Thanks for updating the PR. Merged to trunk.


Fix broken build and tests with --no-default-features

I sincerely apologise for the late response. Many things are going on right now. I will have time to review either this week or the next week, unfortunately.

Hi again! First of all, thank you for taking time to contribute! I have a little proposal for this pull request. As it already touches what I have wanted to change for quite some time now, perhaps, now it is a good time to do that, of course, if you don't mind. The thing is, the HeaderMap used in request.rs isn't really needed there in the structure called Request. What we need there is just something what may hold unique associations of strings. A good candidate, for example, would be the std::collections::HashMap. Can you please remove the http crate dependency for good and replace the code using it so that it uses just a hash map, and in case of the client feature being enabled, it would be creating a http::HeaderMap object on-the-fly? If you don't have time for this, I can just merge the code right now and do this myself, no problem at all.


noproxy support in mqtt, Proxy & noproxy support in websocket

[x] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Proposed changes

Bugfix: Fixes comparison of proxy and noproxy against null, now just looks for non-falsy.
1/ The existing comparison encourages people to set the env variable to null, which ends up with it equalling the string 'null'.
2/ if (process.env.no_proxy === undefined), then process.env.no_proxy.split will fail.
Extends proxy use in mqtt by adding noproxy support.
Adds proxy/noproxy support to websocket.
ToDo:
really, proxy configuration node selection should also be added to mqtt and websocket?
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage decreased (-0.002%) to 77.547% when pulling aa86cfc55f534ef6950786799ab521f541e4bc6a on btsimonh:proxy-support into 9bd9c6a40018f5523f3ce3be53b756373f2ecfd0 on node-red:master.


[SMOKES] Dynamic VS Vector decision + Vector Infowindows / Tooltips

WARNING: Default number of features for the map has to be set to Infinity so that things continue working as before if Maps API returns no stats. Change this before merging this!
This PR implements 3 things:

VisView (and MapView) is now rendered after the map is first reloaded.
CARTO.js now decides whether to use vector or raster. DEPENDS ON https://github.com/CartoDB/Windshaft-cartodb/issues/664.
Infowindows & Tooltips for vector rendering. DEPENDS ON https://github.com/CartoDB/tangram.cartodb/pull/9.

We'll be running some SMOKE tests for these changes.
Fixes: https://github.com/CartoDB/cartodb/issues/11783

I did the acceptance steps and it works perfectly.
One thing, vector will not work because it needs some changes that are under dynamic-raster-vs-vector-decision-2 and a new release of tangram.cartodb

True fact @donflopez! Should we cherry-pick those changes so that we can release this?

Yes, sure!

I already did this! We should try it in staging.

It is working on ded02, if you want to try @alonsogarciapablo, I think we're ready to merge :)

Well, I just tried with a torque map and it fails with the next error:
vis-view.js:104 Uncaught TypeError: Cannot read property 'invalidateSize' of undefined

Torque is now working, it need this changes on deep-insights.js

I've noticed that the time series widget is not being animated like the map content.

retest this please

After this retest please I've found that the time series widget moves the time slider but it doesn't move correctly. It moves like 2-3px each step and it should move much more.

Another issue that I found is when clicking to set a range, if you simply click without drag it throw an exception:
Uncaught Error: start must be smaller than end
    at AnimatorStepsRange (animator-steps-range.js:6)
    at Animator.steps (animator.js:101)
    at Object.options.ready (torque.js:92)
    at windshaft._setReady (windshaft.js:270)
    at LeafletTorqueLayer.<anonymous> (torque-layer-view-base.js:174)

But this could not be related with this changes.

After debugging the tiny steps bug, it looks like it takes 256 steps instead of data_steps, If I create a new map it works.

It works randomly... after try in staging it works always, but I think it is because of the timing of the requests.
If I set a throttle in local it works more often than without.
It looks like a race condition, as we can see here we don't control the loading flow.

I've found another error when hiding a torque layer:
Uncaught TypeError: this.hide is not a function
    at h._onModelChanged (torque-layer-view-base.js:157)
    at s (backbone.js:370)
    at r (backbone.js:356)
    at m (backbone.js:155)
    at N.d.k.trigger (backbone.js:346)
    at N.d.set (backbone.js:526)
    at N.d.update (layer-model-base.js:30)
    at t._onLayerDefinitionChanged (deep-insights-integrations.js:707)
    at s (backbone.js:370)
    at r (backbone.js:356)

Adding a new layer after a Torque layer launchs an exception:
Uncaught TypeError: Cannot read property 'replace' of undefined
    at wax.cartodb.js:2231
    at Object.e.getGrid (wax.cartodb.js:2309)
    at Object.o.screen_feature (wax.cartodb.js:2642)
    at HTMLDivElement.c (wax.cartodb.js:2494)
    at HTMLDivElement.<anonymous> (wax.cartodb.js:304)

I've created this other branch to make the smokes deploy

Fixes https://github.com/CartoDB/support/issues/692.

Important reminder!
Some properties set by default are not supported by Tangram and the decision always goes for raster.
We have to think which solution is the best for this cases:
1.- Support those properties.
This can be a pain where most hurt. It is gonna take time and collaboration with Mapzen.
2.- Remove those properties from default ccss.
This has some inconveniences that @makella can explain better than me, some of them are that raster needs some of them to make the visualisations smoother and we have raster in Builder.
3.- Ignore those properties in Tangram.
IMO, this is the best option because we don't affect to the Builder visualisation and we can get rid of those properties that doesn't affect pretty much in visualisations terms in vector.
cc/ @javisantana, @jorgesancha, @rochoa, @makella

The one property that we have by default that isn't supported by Tangram is the polygon-gamma as @donflopez mentioned, this smooths out polygonal data and makes a big difference with things like choropleth maps.
On the other hand, the only place that we have this default is when polygons are first added. As soon as the user modifies any styling property, polygon-gamma and any other custom styling properties are lost so in reality, it isn't a big deal.
Paco and I did some testing and it seemed that the Tangram rendering did an ok job with the rendering so I'd agree with him that if we can ignore these properties and still get the map to vector rendering that would be preferable instead of something like polygon-gamma being something that stops people from getting vector maps.

I'd like to add some other properties that aren't fully supported like line-comp-op: soft-light we only support multiply, add and overlay at this moment.

@donflopez oh yes, that's another default cartocss property for polygons :)

@makella thanks for your input! ❤
So the idea is to ignore all of the default properties that are not supported by tangram? Should we make a list of these properties are they are just the ones you guys already mentioned (polygon-gamma and line-comp-op: soft-light)? Not sure if other types of geometries have some unsupported props. Here's the default CartoCSS:
#layer['mapnik::geometry_type'=1] {
  marker-width: 7;
  marker-fill: #FFB927;
  marker-fill-opacity: 0.9;
  marker-line-color: #FFF;
  marker-line-width: 1;
  marker-line-opacity: 1;
  marker-placement: point;
  marker-type: ellipse;
  marker-allow-overlap: true;
}
#layer['mapnik::geometry_type'=2] {
  line-color: #3EBCAE;
  line-width: 1.5;
  line-opacity: 1;
}
#layer['mapnik::geometry_type'=3] {
  polygon-fill: #374C70;
  polygon-opacity: 0.9;
  polygon-gamma: 0.5;
  line-color: #FFF;
  line-width: 1;
  line-opacity: 0.5;
  line-comp-op: soft-light;
}

Also, not sure if auto-styling might set some props that won't work with Tangram.
@makella you're the boss here! Thanks!
cc: @jorgesancha

If outostyle set a not suported property we should remove it if it's not that important or add support for it.
For example, in case of line-comp-op: soft-light we should remove it from autostyle or default style.
I understand the visual quality is not the same but we should take into account we can't do everything and we need to cut scope at some point

We are going to release this internally as is and we can then continue with this discussion and tune things a bit more.

Retest this please!


Make it easier to work with different priority queues

I'm wondering what's the best design to do something like:
func doFoo() -> Promise<Void> {
  // in thread A
  return somePromise.then(on: DispatchQueue.global(qos: .background)) { x in
    // some processing in the background
  }.then { y in
    // some more processing
  }.thenGoBackToOriginalQueue()
}

So that, while I want some parts to happen in the background in anyway, I'm sure the returned promise is returning in the thread it was called from, and that delegate methods are also called in that thread.
I know I can replace some processing in the background by
return Promise { resolve, reject in
  DispatchQueue.global(qos: .background).async{
    // some processing in the background
    resolve()
  }
}

so that the returned promise stays in the thread it was called from, but that's quite verbose.

Promises don’t exist on any thread, but handlers can be directed to any queue/thread. then, etc. default to the main thread however.
The queue on which a handler executes is entirely up to that handler.

I see. So unless specified then execute in the main thread? Like
somePromise.then(on: DispatchQueue.global(qos: .background)) { x in
    ...
  }.then { y in
    // this is is executed in the main thread, correct?
  }

Yes

ok great thanks

Is this convenient enough?

It gets verbose when using promises in a background queue since at every step I've to specify to stay in the background, but I don't see a better solution since we can't remove the default being going back to the main thread as it would break a few apps for sure. So that's ok.
I've also had a few times where I'd like the promise to be executed in the thread it's called in. Like usually when you do
...
someFunction()
...

you'd expect someFunction to run in the current thread, ie the caller is responsible for choosing the thread, while promises have the opposite behavior where by default the block is dispatched in the main thread and the caller cannot specify which thread to run the promise in, and can only do so for what happens next.

Also I've been surprised that, even when called in the main thread, the block doesn't run synchronously as is the case in javascript. But that just a surprise that comes with platform switch :)

Also I've been surprised that, even when called in the main thread, the block doesn't run synchronously as is the case in javascript.

If so, this is in violation of Promise/A+ which was formulated by the JS community. https://promisesaplus.com
All the major promises implementation in JSland conform to this, and it is explicit that what you described does not happen.

Sorry about the confusion. I was thinking about the first block, and I didn't write my test correctly. This indeed executes the first block synchronously:
print(1)
let p: Promise<Void> = Promise { resolve, reject in
  print(2)
  resolve()
}
p.then {
  print(3)
}
print(4)
// prints:
// 1
// 2
// 4
// 3

and not the second one as excepted.


feat: Deploy containers as non root

Ensure UID/GID is fixed and root use is prevented

:tada: This PR is included in version 0.11.0-next.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add cuda 12.0 to minimum driver version list

@pmeier this adds the cuda 12.0 minimum driver version list. Support for cuda 12 is available in latest source builds of torch and will ultimately be available in nightly binaries.

Thanks @jamesobutler! Will cut a release later today.


BUG - preview middleware served launchpad not able to navigate to (fiori elements) application in UI5 122.x

Hey hey 👋🏻
In UI5 >=1.122.x the launchpad served by the preview middleware is no longer able to open a Fiori Elements app.
Details see internal incident DINC0116030
Seems like NavTargetResolution is now required 🤷🏻
Expected results
App opens on click of tile
Actual results
Error message:
App could not be opened because the SAP UI5 component of the application could not be loaded.
Failed to load UI5 component for navigation intent "#Samples-display"

Root Cause Analysis
Problem
{describe the problem}
Fix
{describe the fix}
Why was it missed
{Some explanation why this issue might have been missed during normal development/testing cycle}
How can we avoid this
{if we don’t want to see this type of issues anymore what we should do to prevent}

@heimwege I am still able to successfully run a Fiori elements application locally without having the NavTargetResolution. Are you able to reproduce the issue locally?

@zdravko-georgiev my CAP Java FE playground repo worked in 1.120.11 and didn't work once I upgraded to 1.122.2. So basically as described in the internal incident. The solution as also taken from there.

@heimwege I can reproduce it with your CAP Java FE playground repo. This is a very interesting issue, because if I switch the loading of UI5, hence use the ui5-proxy-middleware and load UI5 from ui5.sap.com and NOT from npmjs, then the issue does not occur.

I tried the same and yes, the navigation as such works when using the proxy which is strange enough, but the application seems to be broken too. I get the following FE error that I don't get with the implemented fix and the sources are served directly without the proxy:

This is indeed really strange as it seems the served UI5 sources are not identical 🤔

I tried the same and yes, the navigation as such works when using the proxy which is strange enough, but the application seems to be broken too. I get the following FE error that I don't get with the implemented fix and the sources are served directly without the proxy:

This is indeed really strange as it seems the served UI5 sources are not identical 🤔

Please try Empty Cache and Hard Reload in the browser tab. Sometimes there are cache issue when switching between npmjs and ui5.sap.com versions

That solved it, thanks. I thought I'm on the safe side if I just use sap-ui-xx-viewCache=false. Seems not to be the case 🙈

This one only disables the cache for the XML Views 😉

@heimwege, the issue can be closed correct? If not, and I misunderstood, please reopen.

@tobiasqueck fine for me, but as there will be no downport closing this issue means preview middleware is broken for >= 1.122.x < 1.124.x. So at least the readme should be adjusted accordingly.
@zdravko-georgiev please correct me if I'm wrong.

Maybe I misread the discussion, however, I thought to understand that it is an issue in UI5 independent of the middleware i.e. if you create a local flp.html file and do the same, you run into the same issue.

Depends on how your local flp configuration looks like 😄
Assuming you use the very same config for the flp sandbox the preview middleware uses in its flp template, my understanding is that you will run into exactly the same issue (in case you use the ui5 sources from npmjs! Using the proxy to load the ui5 sources works 🙈). So even if this issue is not a preview middleware issue, there's a broken flp sandbox config in 1.122.x and 1.123.x that leads to a broken flp in the preview middleware. So either the UI5 colleagues do a downport of the fix (which they declined) or we should at least add this information to the readme of the preview middleware. That's why I re-opened the issue that adjusting the readme is not forgotten.

Ok, now I am getting it. We usually recommend to use the ui5-proxy-middleware (standalone or included in the `@sap/ux-ui5-tooling), and as far as I understand, then you won't have the issue. So, we are talking about a corner case here.
I am a little reluctant to add this to the README because it could create the impression that all known issue with the other packages are listed, which we don't. Since these are no long term release versions of UI5, I'd still prefer not doing anything here.
What do you think?


About apt install etc., the progress is not clear because the display is cut.

About apt install etc., the progress is not clear because the display is cut.
We have a slow internet environment and a slow repository loading source.
The apt display is verbose.
But when we cut it all output off, we don't know if it's loading from the net or an error.
Curl and Snap are displayed because they are not redundant.
Is'nt there a less verbose way to output apt too?

I rewrite get -y install verbosity to deliting ">/dev/null 2>/dev/null"
Because slow internet env.


Security Monkey TravisCI test for installation

Do not commit yet.

Currently testing the pinned version.

Forgot to merge.

Made a mistake -- re-opening...


File Upload

I'm successfully using the com.vaadin.flow.component.upload.Upload component in
vaadin.version>11.0.1</vaadin.version>
I set	upload.setAutoUpload(true) and upload.addSucceededListener() is correctly invoked at the end of the upload.
If I move to <vaadin.version>11.0.2</vaadin.version> the upload stop to work.
After the version update, the addSucceededListener method is never called anymore.
If I downgrade to 11.0.1 the upload component works well.
Example code:
Upload upload = new Upload(new MemoryBuffer());
upload.setAutoUpload(true);
upload.addSucceededListener(event -> {
			System.out.println("SUCCEEDED Uploading --> " + event.getMIMEType() + " [" + event.getFileName() + "]");
			this.fileName = event.getFileName();
			headerUploadWrapperDiv.add(new Label("file: " + fileName  + " uploaded."));
		});
headerUploadWrapperDiv.add(upload);

This issue was moved to vaadin/vaadin-upload-flow#95


Can't install with NPM, unable to resolve dependency tree

Environment
System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 AMD Ryzen 5 3600 6-Core Processor
    Memory: 3.65 GB / 15.93 GB
  Binaries:
    Node: 16.7.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 7.20.3 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 29, 30, 31
      Build Tools: 29.0.2, 30.0.2, 31.0.0
      System Images: android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom
      Android NDK: Not Found
    Windows SDK: Not Found
  IDEs:
    Android Studio: Version     2<IP_ADDRESS> AI-203.7717.56.2031.7621141
    Visual Studio: 16.10.31515.178 (Visual Studio Community 2019)
  Languages:
    Java: 1.8.0_302
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: 0.64.1 => 0.64.1
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Description
I've tried to install this module with npm install @react-native-community/slider but got an ERESOLVE message below.
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!   peer react@"*" from<EMAIL_ADDRESS>npm ERR!   node_modules/@react-native-community/slider
npm ERR!     @react-native-community/slider@"*" from the root project
npm ERR!   1 more (react-native)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/react-native-windows
npm ERR!   peer react-native-windows@"*" from<EMAIL_ADDRESS>npm ERR!   node_modules/@react-native-community/slider
npm ERR!     @react-native-community/slider@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

I've also tried to install it with --force option but it crashes the app whenever I try to render a slider.

I've never actually thought about updating npm. It worked when I passed --legacy-peer-deps. I'll try to create a new project to check if a newer npm version fixes the issue.

Nope. Just updated to npm 8.1.0 and still got the same issue. I really don't know if it is npm's problem or a package-related issue.

Nope. Just updated to npm 8.1.0 and still got the same issue. I really don't know if it is npm's problem or a package-related issue.

@coneforapine Why won't you try with the version I used - 7.21.1?

@ekremay I've tried to reproduce this issue using your setup:

update npm to the latest - 8.1.0
react-native to the 0.65.1
install the Slider using npm

Everything went fine, so I'm attaching the logs from the terminal (please take a look at the environment info):
PS C:\Dev\ReproProjects\SliderReproAppProject> npm install npm@latest -g
removed 224 packages, changed 10 packages, and audited 39 packages in 26s

1 moderate severity vulnerability

To address all issues, run:
  npm audit fix

Run `npm audit` for details.
PS C:\Dev\ReproProjects\SliderReproAppProject> npm install @react-native-community/slider

added 2 packages, changed 73 packages, and audited 1083 packages in 47s
76 packages are looking for funding
  run `npm fund` for details

48 vulnerabilities (14 moderate, 34 high)

To address issues that do not require attention, run:
  npm audit fix

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.
PS C:\Dev\ReproProjects\SliderReproAppProject> npx react-native info
info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.19042
    CPU: (8) x64 Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
    Memory: 11.58 GB / 23.76 GB
  Binaries:
    Node: 14.17.3 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.1.0 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 28, 29, 30
      Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.2, 30.0.3
      System Images: android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom
      Android NDK: Not Found
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.15063.0, 10.0.18362.0, 10.0.19041.0
  IDEs:
    Android Studio: Version  <IP_ADDRESS> AI-202.76<IP_ADDRESS>86908
    Visual Studio: 16.11.31624.102 (Visual Studio Community 2019), 16.9.30914.41 (Visual Studio Community 2019)
  Languages:
    Java: 1.8.0_292 - C:\Program Files\OpenJDK\openjdk-8u292-b10\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: ^5.0.1 => 5.0.1
    react: 17.0.2 => 17.0.2
    react-native: 0.65.1 => 0.65.1
    react-native-windows: 0.65.4 => 0.65.4
  npmGlobalPackages:
    *react-native*: Not Found

@BartoszKlonowski Thanks a lot. As I mentioned before, now I can use the slider in my project with npm update and --legacy-peer-deps trick, but I couldn't load it normally, I was able to install it when I added --legacy-peer-deps. Could this part I added --legacy-peer-deps cause a problem in the long or short term? I don't know.

same problem here

@abury @BigZ Thank you for letting me know, I totally appreciate!
What surprises me the most is that I'm completely unable to reproduce it, even using various npm versions...
As for the proposal of removing the react-native-windows from peer dependencies: This library uses the Windows implementation, so it should require the react-native-windows to be installed, no matter what version, so I don't think that removing this from peer dependencies would anyhow improve the situation.
Let me check with RNW team and come back once I'll gather some opinions about it.


110 build stability & compatibility

should fix #110

makes post-build steps more robust
adding output messages in VS for post-build
deletes previously copied packages during post-build
respects Debug or DebugRevit solution build config now
SpacePlanning project now copies needed Core & Graphs dlls to bin folder
switches Massing projects to use net47 NuGet packages instead of net472

Example build output (per package) :
+++++++++++++++++++++++++++ SpacePlanning
Config : DebugRevit
Deleted [94] .NET system .dlls and [1] Microsoft .dlls
Built SpacePlanning to C:\Users\Radu\Documents\GitHub\GenerativeToolkit\src\SpacePlanning\bin\DebugRevit\SpacePlanning
Deployed SpacePlanning package to C:\Users\Radu\AppData\Roaming\Dynamo\Dynamo Revit\2.0\packages\SpacePlanning
++++++++++++++++++++++++++++++++++++++

Tested with Dynamo 2.0.2/2.0.3 in both Sandbox & Revit 2019


Update to operator CRD for triggers

Note: This is run-at for 19.21.
Update operator collection CRD to track webhook and secrets.

Create a new default webhook secret on Kabanero instance creation
apiVersion: v1
kind: Secret
metadata:
name: default-webhook-secret
type: Opaque
data:
secret: MWYyZDFlMmU2N2Rm

Update CRD to track webhook URLs and secrets. For example:
webhooks:

type: github
url: https://github.com/owner/repo
type: github
url: https://github.com/org
secret: my-other-secret
type: docker
url: ...

@kaczyns - Is the work for this issue continue to be targeted for v0.3.0 release?

@marikaj123 Michael indicated this was a "run-at" and so I have not prioritized the work for 0.3.0.  If he comes back and says he needs it, we can try our best to make the updates that he needs.

Recommend we target secret management for 0.4.  It's too late for Kabanero webhook to leverage the secret in 0.3.

I spoke briefly with @mchenggit.  I am going to remove this from the 0.4.0 release for now.

@mchenggit I was unsure if this issue was still valid.  Could you please close it if you no longer require these updates?

We don't need this any longer due to recent re-design.


Taproot keys implementation strategy

After https://github.com/rust-bitcoin/rust-bitcoin/pull/561#issuecomment-774485519 and https://github.com/rust-bitcoin/rust-bitcoin/pull/561#issuecomment-798802542

Leave bitcoin::PublicKey as is, probably adding bitcoin::util::ecdsa::PublicKey alias to it (the same for private keys).
Re-export Taproot keys under bitcoin::util::schnorr
Change ExtendedP(ub/priv)Key to hold secp256k1::Key rather than bitcoin equivalents. It is a necessary change anyway, since BIP32 does not support uncompressed keys and using type with compression flag is a mistake
Introduce to Extended*key* functions to_ecdsa (returning always compressed ECDSA key) and to_shchnorr.
... and that's all for the first non-API breaking release.

Next, more invasive change will be:

Remove bitcoin::PublicKey type
Create UncompressedKey types (for legacy purposes) and
Introduce PublicKey enum with just Compressed and Taproot variants (such that it can be used in SegWit miniscript/descriptor context without the need for errors/panics).

The first phase is implemented with the following PRs:

[x] Non-API breaking changes for 0.26.1 #589
[x] API-breaking changes to Extended keys internal key representation: #590
[x] API-breaking changes to PSBT internal BIP32 key representation: #591
[ ] #757

What type would Script::push_key take?

I also don't think ecdsa::PublicKey is the right name for 33-byte pubkeys, because 33-byte pubkeys are not only used for ECDSA. You also need full keys when doing Taproot derivtaions or when working wtih bip32, even if you are ultimately deriving x-only keys.

What type would Script::push_key take?

It looks like the script must become witness-version aware (move context from miniscript?)...

Then what would the type of TxOut::script_pubkey be?

personally, i don't think it makes sense to have a separate type of key for taproot since the keys are technically compatible, right? if there is such a need, the keys could be e.g. backed by some underlying type?
this might become an issue when it comes to BIP-118 though...

I am a bit late for the party. But I don't like mixing Public Keys with signature algorithms. Keys are always full, and should not be associated with any signature algorithm.
My vote is for having separate modules for keys and signature checking. For most users, keys are just for signature checking, so it does make some sense. But the cryptographer inside me just wants to highlight this difference.
I would propose changing

ecdsa to ec for the keys.
changing schnorr::Keypair to ec::XonlyKeyPair
moving all the signature-related stuff to ecdsa and schnorr modules.

This also matches how it is implemented in secp256k1 and IMO makes more conceptual sense if you consider applications for keys beyond signature checking.

While I agree with @sanket1729 maybe it'd be sensible to define newtypes around PublicKey similar to newtypes around hashes?
Also nit: I think XOnlyKeyPair is more appropriate casing.

My vote is for having separate modules for keys and signature checking.
moving all the signature-related stuff to ecdsa and schnorr modules.

Agree. Just for consistency, the same should be applied to secp256k1 lib
Regarding the rest, I will try to re-cap what key type restrictions are we having in post-SegWitV1 world?

ScriptPubkey can take any key type, however this is context-dependent. Currently, script context can't be addressed in rust-bitcoin (and is addressed in rust-miniscript), which creates a lot of exceptions and error handling there (and pain). Ideally, we can have a refactored script::Builder in rust-bitcoin, which will be context-aware and will fail on improper key type usage, and remove Script::push_key completely (in favor of the builder). Then, Script type should continue to be backed just by a byte sequence, thus no propagation of the problem to the level of TxOut/Transaction. I think this addresses @apoelstra concern above.

If removing Script::push_key and re-doing Builder considered too invasive, (while I think this is a good API practice preventing from pushing random data into random script), we may have more key-specific functions on Script, one for each of pubkey types we will agree upon.

Witness is anyway just a vec of bytestrings, so keys story does not affect it - they are all get there via length-independent slice representation anyway.

BIP32/PSBTs should rely on secp256k1-provided types, like currently proposed in #590 and #591

Thus, all use-cases inside rust-bitcoin itself are independent from the selected key type system. For external use (miniscript, wallets, block explorers), I propose to have dedicated key type per each format, since they will like to differentiate between their usage in different contexts. Thus, we will end up with having:

introduce a newtype UncompressedPubkey over secp256k1::PublicKey
do a newtype ec::CompressedPubkey over secp256k1::PublicKey for SegWit v0 contexts (like in miniscript)
PublicKey remains as is (may be we can rename it into FullPubkey), representing either compressed or uncompressed key (for pre-SegWit world)
re-export secp256k1::schnorrsig::PublicKey as ec::XOnlyPubkey to disambiguate the naming

Closed with #757 merged


Bug: Litestar changing root logger by default

Description
Litestar changes the root logger configuration by default.
My current workaround is to set Litestar root logger to an empty dict:
app = Litestar(logging_config=LoggingConfig(root={}))
URL to code causing the issue
No response
MCVE
import logging

from litestar import Litestar

logging.basicConfig(level=logging.INFO, format="CRAZY LOG %(message)s")
logger = logging.getLogger(__name__)

logger.info("Logging from lite_app before creating the litestar app")
app = Litestar()
logger.info("Logging from lite_app after creating the litestar app")

Steps to reproduce
Execute above code, expected output:
CRAZY LOG Logging from lite_app before creating the litestar app
CRAZY LOG Logging from lite_app after creating the litestar app

Current output:
CRAZY LOG Logging from lite_app before creating the litestar app
INFO - 2023-12-08 20:40:08,708 - __main__ - example - Logging from lite_app after creating the litestar app

Screenshots
No response
Logs
No response
Litestar Version
2.3.2
Platform

[X] Linux
[ ] Mac
[X] Windows
[ ] Other (Please specify in the description above)

[!NOTE]
While we are open for sponsoring on GitHub Sponsors and
OpenCollective, we also utilize Polar.sh to engage in pledge-based sponsorship.
Check out all issues funded or available for funding on our Polar.sh dashboard

If you would like to see an issue prioritized, make a pledge towards it!
We receive the pledge once the issue is completed & verified
This, along with engagement in the community, helps us know which features are a priority to our users.

I have the exact same problem.

I have the exact same problem.

While we wait for the fix, my workaround is app = Litestar(logging_config=LoggingConfig(root={}))

Closed by #2969.


Value for DebugMode in the Metadata section needs to be specified

There is a DebugMode key specified in the Metadata section, but no indication as to what value(s) could/should be set to enable the DebugMode. There is a reference to the "Returning error message" section that follows later in the article, but it makes no mention of the value for the setting.
Perhaps it would be best to include a Metadata section snippet in the "Returning error message" section that includes the DebugMode key.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6dff7a38-a459-4eb9-22fe-d225eeac5e34
Version Independent ID: c3e92211-d07e-edec-3a08-eb68a26859bb
Content: Define a RESTful technical profile in a custom policy - Azure AD B2C
Content Source: articles/active-directory-b2c/restful-technical-profile.md
Service: active-directory
Sub-service: b2c
GitHub Login: @mmacy
Microsoft Alias: marsma

Thanks for the feedback and bringing this to our notice . At this time we are reviewing the feedback and will update the document as appropriate .

Thank you - for the record, I tried a random word for the value, and I received the following error message:
"A required Metadata item with key "DebugMode" was found in the TechnicalProfile "CheckAccessCodeViaRESTCallChecker" in policy "B2C_1A_HelloCheckAccessCodeWithFunctions" of tenant "b2cexploration.onmicrosoft.com", but it was not of type boolean."
This pretty much suggests the value is expected to be Boolean. In further testing, using the words "true" and "false" properly toggles the DebugMode behavior.


Add Ford EVs

Checklist

[ ] added entry to CarInfo in selfdrive/car/*/values.py and ran selfdrive/car/docs.py to generate new docs
[ ] test route added to routes.py
[ ] route with openpilot:
[ ] route with stock system:

Ford F150 Lightning and Mach E have not been added yet. This will separate the vehicles, despite using the same controls as the ICE Ford F150 with BlueCruise.
The kicker currently is there's no way to differentiate the Mach E from the Lightning due to the return on the ECUs from the fingerprint.
I suspect this might be fixed when this issue gets resolved but until then this will PR will have to stay as a draft.
This also defaults the Lightning and the Mach E into dashcam mode until injection tests are completed and validated by comma team.

Why is this closed?

Trying new forks and such. Have better changes. Will reopen soon.


OIDC active state form

This PR follows from #13980.  It adds form management portion of the ActiveState Publisher in PyPI Account settings.
Without #13980 merged, this PR have about 1400 more changed lines than it should.  It'll look more like this when 13980 is merged: https://github.com/ActiveState/warehouse/pull/3

I'll review this once #13980 is merged and conflicts are resolved here!

@di, @woodruffw.  Before you give this PR a super thorough review, I'll point out that I've included quite a bit of duplication tests/unit/accounts/test_views.py.  I think I would be able to avoid this if I changed all of the validation tests in that file to call _add_pending_oidc_publisher and perhaps parameterize passing in the respective services values so I can check stuff like this has the right service name in the string?
That could result in quite large or complex parameterize lists though.
Any thoughts?

@th3coop We already have parametrized tests for these which were added recently, e.g. for that specific example: https://github.com/pypi/warehouse/blob/e62049b47483464239fc35df01854274da16c091/tests/unit/accounts/test_views.py#L3442-L3526
I think if you get this branch up to date, you should just be able to add a new ActiveState parameter to these existing tests, rather than duplicating them.

@di, i was expecting these merge conflicts to go away when https://github.com/pypi/warehouse/pull/13980 was merged since I did a fresh rebase yesterday but I still see them now that that code is in main.  I'll rebase again.  I am now realizing that those are the params you already told me about a couple days ago.

@th3coop Is it possible you're rebasing on the out-of-date main from the Activestate fork rather than from PyPI's remote?

@di, that is possible.  I often pull in the upstream main to my local environment though.  And I was certain I had done that before doing my last series of rebases but I could easily forgotten.  Sorry for the delay on this one.  I really thought it was ready for review already.  I'm fixing these merge conflicts right now.

OK.  @di,I got things fixed up.  Again, sorry about that mixup.  Also, I'm working on getting Allowing changes to a pull request branch created from a fork enabled on this PR.  I don't appear to have permissions to do that.

Hey @di.  It appears that we can't turn on **Allowing changes to a pull request branch created from a fork
**.  The option to enable that doesn't show up for myself or any admins of our GitHub account and I can't find anything on the internet as to why that might be.  I'm like 75% sure that it's because our fork is in the ActiveState org and not my personal GitHub account.  That's my best guess based on step 4 from the docs where it says On user-owned forks.
If not having this turned on is a huge pain for y'all, let me know and I can move the remaining PRs to my personal account.

Yeah, that's an unfortunate known long-standing bug with GitHub orgs and forks. The hacky workaround is to manually give the person commit rights on your fork, but that's not always desirable :upside_down_face:

I'm fine with that! Thanks for the workaround @woodruffw.  Invites sent to yourself and DI.  I'll remove you both when we get the PRs merged.

@woodruffw.  All set.

Okie dokie.  All changes pushed, @woodruffw.

Thanks! I'm taking another look today.
(You'll need to update against main for the merge as well.)

Thanks so much for all your time @woodruffw !

@miketheman will you have time to review this PR this week?

Thanks for the review, @miketheman!  Great notes in there.  I'll work through them either later today or tomorrow.  The GQL API is available again if you wanted to, or have time to take it for a manual test drive.  Again, sorry for that terrible timing.

I'm leaning towards removing them though.

@th3coop go ahead and remove them - less is more 😁

go ahead and remove them - less is more 😁

Agreed and done.  Fixed the tests and took it for a spin and it works as I'd expect it to

Yay! I'll approve now, and merge in the AM.

Hurray!  Thanks so much Mike, Will and Dustin!

@th3coop I've gone ahead and enabled the OIDC provider on TestPYI so you can test run it over there.


feat: nicer error messages during development

fixes #408.

Without this change
   Compiling numbat v1.11.0 (/home/hamir/numbat/numbat)
    Finished test [unoptimized + debuginfo] target(s) in 2.23s
     Running tests/interpreter.rs (target/debug/deps/interpreter-86e93d4b0103f0db)

running 1 test
thread 'test_algebra' panicked at numbat/tests/common.rs:27:21:
called `Result::unwrap()` on an `Err` value: ResolverError(ParseErrors([ParseError { kind: ExpectedThen, span: Span { start: SourceCodePositition { byte: 1029, line: 45, position: 22 }, end: SourceCodePositition { byte: 1054, line: 45, position: 47 }, code_source_id: 10 } }, ParseError { kind: ExpectedPrimary, span: Span { start: SourceCodePositition { byte: 1079, line: 46, position: 3 }, end: SourceCodePositition { byte: 1083, line: 46, position: 7 }, code_source_id: 10 } }]))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test test_algebra ... FAILED

failures:

failures:
    test_algebra

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 31 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p numbat --test interpreter`

 *  The terminal process "cargo 'test', '--package', 'numbat', '--test', 'interpreter', '--', 'test_algebra', '--exact', '--nocapture'" terminated with exit code: 101.
 *  Terminal will be reused by tasks, press any key to close it.

With this change
   Compiling numbat v1.11.0 (/home/hamir/numbat/numbat)
    Finished test [unoptimized + debuginfo] target(s) in 2.14s
     Running tests/interpreter.rs (target/debug/deps/interpreter-86e93d4b0103f0db)

running 1 test
thread 'test_algebra' panicked at numbat/tests/common.rs:29:21:

--------------------------------------------------------------------------------
Error
Expected 'then' in if-then-else condition
Expected one of: number, identifier, parenthesized expression
--------------------------------------------------------------------------------

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test test_algebra ... FAILED

failures:

failures:
    test_algebra

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 31 filtered out; finished in 0.00s

error: test failed, to rerun pass `-p numbat --test interpreter`

 *  The terminal process "cargo 'test', '--package', 'numbat', '--test', 'interpreter', '--', 'test_algebra', '--exact', '--nocapture'" terminated with exit code: 101.
 *  Terminal will be reused by tasks, press any key to close it.

Thank you!


ation hide header

Current Behavior

Expected Behavior

Your Environment

software
version

react-navigation

react-native

node

npm or yarn

@Catpants Please close issue as it is empty.


New with ngtable - i do all steps but pagination don't work with my table ?

Hi
i try to use ngtable to do pagination for data i got i just need to display 2 tbody in each page - i got it as:

but nothing happend when i click on page no like (1,2,3 ... )
i have add sample project on: http://plnkr.co/edit/hr9zj6WMW0G6oRWOxC63?p=preview
so please can i know how can i make it works ?

hope to get help soon ....
Thanks

Don't ask question because this repo is dead!

Nope it's not dead. Just like any other os projects, everyone also have day
jobs
On Tuesday, July 7, 2015, TeodorKolev<EMAIL_ADDRESS>wrote:

Don't ask question because this repo is dead!
—
Reply to this email directly or view it on GitHub
https://github.com/esvit/ng-table/issues/641#issuecomment-119169699.


Add ES Lint rules for DynamicColorIOS()and ColorAndroid()

Summary
The PlatformColor PR added support for iOS and Android to express platform specific color values.   The primary method for an app to specify such colors is via the PlatformColor() method that takes string arguments.   The PlatformColor method returns an opaque Flow type enforcing that apps use the PlatformColor method instead of creating Objects from scratch -- doing so would make it harder to write static analysis tools around Color values in the future.   But in addition to PlatformColor(), iOS has a DynamicColorIOS() method that takes an Object.   The Flow type for this Object cannot be opaque, but we still want to enforce that app code doesn't pass variables instead of Object literals or that values in the Objects are variables.   To ensure DynamicColorIOS() can be statically analyzed this change adds an ESLint rule to enforce that DynamicColorIOS() takes an Object literal of a specific shape.   A ColorAndroid() was also introduced not for practical use but just to test having platform specific methods for more than one platform in the same app.   A second ESLint rule is created for ColorAndroid as well.
Changelog

[General] [Changed] - Add ES Lint rules for DynamicColorIOS()and ColorAndroid()
Test Plan
yarn lint passes.

Thanks for this! Can you look into writing tests for these lint rules? Check out https://github.com/facebook/react-native/blob/master/packages/eslint-plugin-react-native-community/tests/error-subclass-name-test.js for an example.
Lint rules are one of the things we push for really good tests for since the infra is so good for it.

Thanks for this! Can you look into writing tests for these lint rules? Check out https://github.com/facebook/react-native/blob/master/packages/eslint-plugin-react-native-community/tests/error-subclass-name-test.js for an example.
Lint rules are one of the things we push for really good tests for since the infra is so good for it.
Also, do you think it makes sense for this to all be one rule vs a different rule for each function? I can't imagine people would want to turn them on or off separately.
I also think we need a similar rule for PlatformColor itself, making sure people pass in a string and not a variable. PlatformColor('secondaryLabelColor ') not PlatformColor(myColor).

Done: added tests, merged into a single rule file, added PlatformColor rules.


"Enabling rules one-by-one" docs are wrong

There is no rules.neon file. I don't know when I broke this, but worth splitting into this other file.

If we moved things to a rules file we would need to provide it to extension installer. But that wouldn't be great as https://github.com/phpstan/extension-installer would still register everything.

Modeling after https://github.com/phpstan/phpstan-symfony


Protonym sort failing

I think we're just missing a human label for OriginalSection?  Or maybe there is some bad data here?
An ActionView::Template::Error occurred in taxon_names#original_combination:

  comparison of TaxonNameRelationship::OriginalCombination::OriginalGenus with TaxonNameRelationship::OriginalCombination::OriginalSection failed
  app/models/protonym.rb:337:in `sort'

Ok. There is a bug in the system. Not sure if this is related though. OriginalSection applies to the botanical names only (original intention). Then we realized, that botanical names do not use original combination. We removed OriginalSection, etc. from the codes, but files were not deleted. I deleted them and running spec tests now.

Problem with NewTaxonName task now. Original combination section is hidden for the botanical name in the species rank. But if I create a new genus in botany, I still have an access to the Original combination (I did not check subspecies or subgenus). And this is a real bug.

Second thought, we cannot create a plant basionym without original combination. In fact may be we need original combination for all plant names... But this is an open question. No Original combination for all plant names, or present Original combination, again for all plant names?

Display original combination option for all plant names

@proceps What about the other codes?

Yes, open original combination for all codes.

Original combination is open for all codes. In the case of botany this could be related with the kind of group. Original Combination its set to work with 'SpeciesGroup and GenusGroup
So, to clear this thing. We need to hide original combination for genus and species group in botany code?

No- open for all nomenclature codes.  @proceps Does this mean we're not populating SpeciesGroup and GenusGroup correctly likely?

THis is (likely) because some constant is incorrect- can you check?
On Wed, Oct 31, 2018 at 3:27 PM Dmitry Dmitriev<EMAIL_ADDRESS>wrote:

It is not open for species group names in botany now. It should be.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SpeciesFileGroup/taxonworks/issues/506#issuecomment-434835775,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABYSDQjDrGUEuUDT65VEJVx80TE33bIks5uqgexgaJpZM4WkLuM
.

@proceps I added SpeciesAndInfraspeciesGroup to the filter. Now original combination should be present there.


Create a Business Service with Node.js Using Visual Studio Code: cds not installing properly

Tutorial URL: https://developers.sap.com/tutorials/cp-apm-nodejs-create-service.html
In step 1, the tutorial says to install cds using the command npm i -g @sap/cds-dk in shell or bash. It does not say in what folder or what application. I tried to do the command in VS Code's powershell, and it seemed to work, but when I ran the comand cds as instructed, I received the following error:

Please open a command line window/terminal and run npm i -g @sap/cds-dk. As mentioned in the tutorial this process takes some minutes installing the cds command. Are you using MacOS or Windows?

I am using Windows. When I run the command in the command prompt, it installs quickly. When i run cds I am met with an error.

Hi,
please check if your environment variables are properly set on Windows for npm and Node, as described in the troubleshooting guide.
Best regards,
Iwona


Update gemspec to point to LICENSE.txt

Reflecting changes made in https://github.com/thekompanee/fuubar/commit/5f111b945f4ecbf7a7bd19281eba79ce5e7111ea

Argh!  That change shouldn't have made it onto master.  Thank you @andrewblim!

Merged in 6ef3d994e77e28e05ca0a11f5b9e07078d78889b


Imx9 usb fixes

Summary
This corrects some USB cache operations on imx9 platform, as well as with some generic buffer overflow issues in cdcacm and pl2303
Impact
Fixes random crashes / instability
Testing
Tested on i.MX93 platform

[Experimental Bot, please feedback here]
No, the PR does not meet the NuttX requirements.
Here's why and how to improve:
Missing Information

Summary:

Be more specific. What cache operations were incorrect? How were they corrected? What buffer overflows were present? How were they fixed?

Impact:

While "Fixes random crashes / instability" is helpful, be more specific about the situations where these issues occurred. Which drivers/configurations were affected?

Testing:

Insufficient Detail: "Tested on i.MX93 platform" is too vague.

Specify the exact board and configuration used.
Mention the NuttX version or branch.
Provide specific test cases that were run to verify the fix (e.g., "Performed bulk transfers with large payloads," "Tested enumeration with multiple devices").

No Logs: The "Testing logs" sections are empty. Include relevant log snippets demonstrating the issue before the change and the fix afterward.

How to Improve the PR Description

Expand on the Summary: Provide a technical explanation of the issues and solutions.
Detailed Impact:  Be specific about affected drivers, configurations, and the nature of the crashes/instability.
Thorough Testing:

List the exact board, configuration, and NuttX version used for testing.
Describe the specific test cases executed (and ideally, how to reproduce them).
Include relevant log snippets showing the problem before and the solution after the PR.

By providing this additional information, your PR will be much easier for reviewers to understand and approve.

@jlaitine there are many similar code snippets like https://github.com/apache/nuttx/pull/13790/commits/93cd30185b11a735b99c29a2e6711484238d31db#r1784472933, have you check all places?

@jlaitine there are many similar code snippets like 93cd301#r1784472933, have you check all places?

I went through the cdcacm driver, and tested it. Before the changes it was corrupting memory and causing system crashes, when _REQLEN was smaller than ep->maxpacket.
I also tried to grep through the drivers/usbdev, but didn't immediately find the same issue elsewhere. I am not 100% certain that the issue is not there in some other driver though, there has been massive changes in usb drivers (and everywhere else as well) since I previously updated our own branches. I haven't been able to follow all of them.


View.Plane node

The View.Plane node doesn't regenerate when I hit run after I've moved a section in the Revit document. Is this intentional?

Hi @josols - definitely not intentional. Will have to investigate...

@josols @andydandy74 this is standard Dynamo problem. Everyone has that same issue. I have been going by this by adding a Boolean Toggle to my nodes and you would have to toggle it on/off. The whole problem is that the input to python nodes need to be different for it to be re-executed and moving something in Revit doesn't really set off re-generation.

I've hacked around achieving something like this:

And just adding an input which does nothing to the pythonscript in your node, Andreas.
I tried to include the three nodes into a the view.plane node itself, and Dynamo gives the possibility to run periodic, but it doesn't work..
So I guess Konrads solution is more viable for now.

I think I'll turn this into a feature request for the Dynamo team. We need to be able to set Python-based custom nodes to force-execute each time a graph runs. Both your solutions are viable but it feels like jumping through hoops.

Created a feature request here:
https://github.com/DynamoDS/Dynamo/issues/4603
Let's see what happens...

I am closing this for now as I don't plan on coding around a built-in limitation of Dynamo.


groonga: 9.1.2 -> 10.0.0

Semi-automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/groonga/versions.
meta.description for groonga is: "An open-source fulltext search engine and column store"
meta.homepage for groonga is: "https://groonga.org/"
Updates performed:

Version update

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 10.0.0 with grep in /nix/store/fwzzcqs7p86r32n1vl32l1k2hl1hv2y0-groonga-10.0.0

directory tree listing: https://gist.github.com/d6676ece43c751e5faac29b31e28c1f6

du listing: https://gist.github.com/ec61b0f237b6565d92cc6abb5eab3576

Rebuild report (if merged into master) (click to expand)

12 total rebuild path(s)
3 package rebuild(s)
3 x86_64-linux rebuild(s)
3 i686-linux rebuild(s)
3 x86_64-darwin rebuild(s)
3 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
groonga
postgresql11Packages.pgroonga
postgresqlPackages.pgroonga

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fwzzcqs7p86r32n1vl32l1k2hl1hv2y0-groonga-10.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A groonga https://github.com/r-ryantm/nixpkgs/archive/2d6afe6ba581ac6b4bff66d352ffd4c7507ed33c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fwzzcqs7p86r32n1vl32l1k2hl1hv2y0-groonga-10.0.0
ls -la /nix/store/fwzzcqs7p86r32n1vl32l1k2hl1hv2y0-groonga-10.0.0/bin

cc @ericsagnes for testing.

@GrahamcOfBorg build postgresqlPackages.pgroonga


Support for Kaniko and ECR

It looks like the config.json for logging into the registry is built into the devspace client and updated every time the build pod is started, using whatever credentials are stored in the local docker client.
Kaniko support a login helper that will use AWS IAM roles to log into ECR.
https://github.com/GoogleContainerTools/kaniko#pushing-to-amazon-ecr
The contents of config.json are just:

{ "credsStore": "ecr-login" }

Is it possible to add the ability to use that config.json, instead of a registry access key?
Thank you!

@pfiled thanks for opening this issue! Yes we can do that to make the kaniko build more flexibel

@pfiled are you aware of the images.build.kaniko.pullSecret option? This allows you to specify a custom pull secret that is bound to the kaniko pod, which could store your custom docker config. I'm not sure if we should implement or add something else since this would pretty much solve your problem.

In case anyone else is looking for this: I added a small example on how to do this to the docs: https://devspace.sh/cli/docs/configuration/images/kaniko#pullsecret
Closing this for now. Feel free to reopen if there are still issues on how to solve this.


Archive project

Hey, given that nova now comes with multiple dashboards ( v2.1.0 ) , I believe this project should be marked as archived/depreciated.
Thanks for all your hard work. I appreciate you. Look forward to your next package.

Thanks for reminding me. I'll archive now.
I actually did the work for this to be put into core, but it took a while so completely forgot I had this.


Pbm try-it function can't display

hello  (openAPI 3.0.0)
I'm not expert in swagger but i can't understand why try-it button is not displayed in my case.
please find the Yaml file here: [https://pastebin.com/raw/gXetGj1Z]
in swagger 2.0 it worked so???
thanks for help.
best regards.

This is still a TODO item, and I believe is expected to arrive during September. See https://github.com/swagger-api/swagger-ui/issues/3338

Thanks a lot !!!

Dupe of (closed) #1340

@rocchisanijl, Swagger UI 3.2.0 now has "try it out" for OpenAPI 3.0.
For future reference, Swagger UI questions should be directed to the Swagger UI repository or the Google group. This repository is for the OpenAPI Specification itself and does not cover the Swagger tools.

Thanks everyone. Closing as really not the right repo.


Swarm test error on CI

The swarm test seems to have errored with the current code in CI  - https://ci.vmware.run/vmware/docker-volume-vsphere/494
FAIL: swarm_test.go:91: SwarmTestSuite.TestDockerSwarm
swarm_test.go:141:
c.Assert(status, Equals, true, Commentf("Volume %s is still attached", s.volumeName))
... obtained bool = false
... expected bool = true
... Volume swarm_test_volume_tr8b5apa57f5 is still attached

From the CI logs,
2017/06/13 07:26:48 Containers running on docker host [<IP_ADDRESS>]: swarm_test_service_1c4n7y6zh4t08.1.3gq04c7lxui5zvsa748ocddm7
swarm_test_service_1c4n7y6zh4t08.2.58z2cu3b7q2m93ifntmdp9jwo
2017/06/13 07:26:48 Confirming attached status for volume [swarm_test_volume_tr8b5apa57f5]
2017/06/13 07:26:50 Destroying volume [swarm_test_volume_tr8b5apa57f5]
2017/06/13 07:26:56 Failed to invoke command [docker volume rm swarm_test_volume_tr8b5apa57f5]: exit status 1
2017/06/13 07:26:56 Removing docker service [swarm_test_service_1c4n7y6zh4t08] on VM [<IP_ADDRESS>]
2017/06/13 07:26:56 Listing docker service [swarm_test_service_1c4n7y6zh4t08] running on VM [<IP_ADDRESS>]
2017/06/13 07:26:56 Failed to invoke command [docker service ps swarm_test_service_1c4n7y6zh4t08]: exit status 1
2017/06/13 07:26:56 Confirming detached status for volume [swarm_test_volume_tr8b5apa57f5]
2017/06/13 07:26:56 Sleep for 2 seconds
2017/06/13 07:26:59 Failed to invoke command [docker volume inspect  --format '{{index .Status.status}}' swarm_test_volume_tr8b5apa57f5]: exit status 1
2017/06/13 07:26:59 Sleep for 2 seconds
2017/06/13 07:27:01 Failed to invoke command [docker volume inspect  --format '{{index .Status.status}}' swarm_test_volume_tr8b5apa57f5]: exit status 1

ESX logs show that the volume was attached and subsequent requests to attach to the same VM all fail with "already" attached. But a detach fails to find the volume (???)

The test logic is trying to verify the volume status is changed from attached to detached after removing the swarm service. However, from above error logs, it looks like the volume is gone:
Failed to invoke command [docker volume inspect --format '{{index .Status.status}}' swarm_test_volume_tr8b5apa57f5]: exit status 1
If the volume exists, the command "docker volume inspect..." shouldn't fail. However, it's really weird why the volume is gone. Have no clue so far...

I've got some clues now. It looks like we are running into issue #1191.
First let's take a look the test case logic - just look at step 12-16:
// Test vDVS usage in swarm mode
//
// Test steps:
// 1. Create a docker service with replicas setting to 1
// 2. Verify the service is up and running with one node
// 3. Verify one container is spawned
// 5. Verify the volume is in attached status
// 6. Scale the service to set replica numbers to 2
// 7. Verify the service is up and running with two nodes
// 8. Verify 2 containers are spawned
// 9. Stop one node of the service
// 10. Verify the service is still running with two nodes
// 11. Verify there are still 2 containers up and running
// 12. Verify the volume is in attached status
// 13. Delete the volume - expect fail
// 14. Remove the service
// 15. Verify the service is gone
// 16. Verify the volume is in detached status
As you can see: step 13 is similar to the scenario in issue #1191 - we are trying to delete a volume which is in attached status - see ESX logs below:
2017-06-13 07:26:50.661402554 +0000 UTC [INFO] Removing volume name="swarm_test_volume_tr8b5apa57f5"
2017-06-13 07:26:56.637418449 +0000 UTC [ERROR] Failed to remove volume name="swarm_test_volume_tr8b5apa57f5" error="Failed to remove volume: Error caused by file /vmfs/volumes/58884956-881be6e0-1941-000c294680dc/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5.vmdk"
2017-06-13 07:29:18.254302006 +0000 UTC [INFO] Removing volume name="swarm_test_volume_tr8b5apa57f5"
After step 13, we removed the swarm service, and again tried to check volume status in step 16. This step is a simple command "docker volume inspect...". It failed because the vmfd file is missing - see logs below:
06/13/17 07:26:59 71629 [MainThread] [INFO   ] Started new thread :<PHONE_NUMBER>68 with target <function execRequestThread at 0x360ae12488> and args (9, 72093, b'{"cmd":"get","details":{"Name":"swarm_test_volume_tr8b5apa57f5"},"version":"2"}')
06/13/17 07:26:59 71629 [Thread-278] [INFO   ] Auth DB /etc/vmware/vmdkops/auth-db is missing, allowing all access
06/13/17 07:26:59 71629 [photon.vmfs-datastore1._DEFAULT.swarm_test_volume_tr8b5apa57f5] [ERROR  ] Failed to access b'/vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5-22129b9236316450.vmfd'
Traceback (most recent call last):
File "/usr/lib/vmware/vmdkops/Python/kvESX.py", line 265, in load
with open(meta_file, "r") as fh:
FileNotFoundError: [Errno 2] No such file or directory: b'/vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5-22129b9236316450.vmfd'
06/13/17 07:26:59 71629 [photon.vmfs-datastore1._DEFAULT.swarm_test_volume_tr8b5apa57f5] [ERROR  ] Failed to get disk details for /vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5.vmdk ('NoneType' object is not subscriptable)
@govint Since you have investigated similar issue before, can you help to take a look?

If this is the same issue as Govindan pointed out (https://github.com/vmware/docker-volume-vsphere/issues/1191#issuecomment-297196000), one workaround is to comment out test step 13 to bypass this issue.

Can someone elaborate what specifically is the root cause ? This is a serious glitch.

@msterin I don't know if Govindan has figured out the root cause during his previous investigation (https://github.com/vmware/docker-volume-vsphere/issues/1191#issuecomment-297196000). As of now, I'm still not clear of the root cause. We don't have any logs to keep track of the metadata file. From ESX logs, the first occurrence of the vmfd file is this FileNotFoundError:
06/13/17 07:26:59 71629 [photon.vmfs-datastore1._DEFAULT.swarm_test_volume_tr8b5apa57f5] [ERROR  ] Failed to access b'/vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5-22129b9236316450.vmfd'
Traceback (most recent call last):
File "/usr/lib/vmware/vmdkops/Python/kvESX.py", line 265, in load
with open(meta_file, "r") as fh:
FileNotFoundError: [Errno 2] No such file or directory: b'/vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5-22129b9236316450.vmfd'
06/13/17 07:26:59 71629 [photon.vmfs-datastore1._DEFAULT.swarm_test_volume_tr8b5apa57f5] [ERROR  ] Failed to get disk details for /vmfs/volumes/datastore1/dockvols/11111111-1111-1111-1111-111111111111/swarm_test_volume_tr8b5apa57f5.vmdk ('NoneType' object is not subscriptable)

I think @govint was referring to disklib behavior when a sidecar was deleted and the disk was not. Or maybe to something else? Let's find out this first, before doing workaround or changing CI

Thankfully, this was a false alarm. The log messages are all valid though. The issue was with the change being tested in the CI. The change (that was being tested in CI #1260) was to remove the calls to handle stale attach in the service.
That was removed in the change and converted into logs instead. Works fine for attach/clone use cases.
The change works fine for volume remove use case also as long as the volume has been detached first. Otherwise, removeVMDK() in the ESX service finds the volume is already attached and logs the message and then proceeds to clean the VMDK (delete the vmdk).
In this case, the test has a container that is using the volume but attempts to remove the volume which is expected to fail. SInce the volume was already attached the delete failed but removed the KV (sidecar). And hence the issue.
Upated the change ( #1260) to restore returning from removeVMDK() if the volume is attached.
The E2E test did catch the bug in the change being tested, although this change does need a new test in the basic tests category whcih i'll add up as part of the existing PR.


rule: rna_report; failure when running test data

Using the test input provided with the pipeline, I got an error with the rule rna_report
error:
rule rna_report:
    input: /gpfs/gsfs12/users/sevillas2/DEG_ALL/RSEM.genes.expected_counts.all_samples.reformatted.tsv, /gpfs/gsfs12/users/sevillas2/DEG_ALL/combined_TIN.tsv, /gpfs/gsfs12/users/sevillas2/Reports/multiqc_matrix.tsv
    output: /gpfs/gsfs12/users/sevillas2/Reports/RNA_Report.html
    jobid: 0
    reason: Missing output files: /gpfs/gsfs12/users/sevillas2/Reports/RNA_Report.html
    resources: mem_mb=1000, mem_mib=954, disk_mb=1000, disk_mib=954, tmpdir=/tmp

    # Avoids inheriting $R_LIBS_SITE
    # from local env variables
    R_LIBS_SITE=/usr/local/lib/R/site-library
    # Generate RNA QC Dashboard
    workflow/scripts/rNA.R         -m workflow/scripts/rNA_flowcells.Rmd         -r /gpfs/gsfs12/users/sevillas2/DEG_ALL/RSEM.genes.expected_counts.all_samples.reformatted.tsv         -t /gpfs/gsfs12/users/sevillas2/DEG_ALL/combined_TIN.tsv         -q /gpfs/gsfs12/users/sevillas2/Reports/multiqc_matrix.tsv         -o /gpfs/gsfs12/users/sevillas2/Reports         -f RNA_Report.html

Activating singularity image /data/CCBR_Pipeliner/SIFS/ccbr_rna_v0.0.1.sif

processing file: rNA_flowcells.Rmd

Quitting from lines 595-647 (rNA_flowcells.Rmd)
Error in `[.data.frame`(numericQC, , apply(numericQC, 2, var) != 0) :
  undefined columns selected
Calls: <Anonymous> ... withCallingHandlers -> withVisible -> eval -> eval -> [ -> [.data.frame
In addition: There were 31 warnings (use warnings() to see them)
Execution halted
[Wed Dec 20 11:51:12 2023]
Error in rule rna_report:
    jobid: 0
    input: /gpfs/gsfs12/users/sevillas2/DEG_ALL/RSEM.genes.expected_counts.all_samples.reformatted.tsv, /gpfs/gsfs12/users/sevillas2/DEG_ALL/combined_TIN.tsv, /gpfs/gsfs12/users/sevillas2/Reports/multiqc_matrix.tsv
    output: /gpfs/gsfs12/users/sevillas2/Reports/RNA_Report.html
    shell:

    # Avoids inheriting $R_LIBS_SITE
    # from local env variables
    R_LIBS_SITE=/usr/local/lib/R/site-library
    # Generate RNA QC Dashboard
    workflow/scripts/rNA.R         -m workflow/scripts/rNA_flowcells.Rmd         -r /gpfs/gsfs12/users/sevillas2/DEG_ALL/RSEM.genes.expected_counts.all_samples.reformatted.tsv         -t /gpfs/gsfs12/users/sevillas2/DEG_ALL/combined_TIN.tsv         -q /gpfs/gsfs12/users/sevillas2/Reports/multiqc_matrix.tsv         -o /gpfs/gsfs12/users/sevillas2/Reports         -f RNA_Report.html

        (one of the commands exited with non-zero exit code; note that snakemake uses bash strict mode!)

Going to check this part of the script - assume the col headers are wrong
https://github.com/CCBR/RENEE/blob/7c58ad68ca5407b4738b4688b901ce3b40fdf431/workflow/scripts/rNA_flowcells.Rmd#L608

Not a real error. my output dir had some other fastqc data - this was getting picked up and added to the report, causing the error.

@kopardev - i forgot I ran into this error at one point. It was actually caused by where it was searching for data. I had other FQ files in the dir that weren't related and the expand character search happened to pick those up. Not sure if this is related to the error you received in your rrna report.


Installation erroneously marked complete

Clocker marks Docker host installation as complete (by touching installDir/BROOKLYN) even when Docker couldn't be installed because the user cannot sudo. This means that Clocker will never reattempt installation until the directory is deleted and means that Clocker will not work even if the sudo permissions error is fixed.

This is a Brooklyn issue, surely?

I think the culprit is the chainGroup call in installDockerOnUbuntu (and presumably in useYum too, I haven't tested). The non-zero exit code from the sudo commands is not propagated.
Here's a complete log on Ubuntu:
+ export INSTALL_DIR=/home/bob/brooklyn-managed-processes/installs/DockerHost_1.2
+ INSTALL_DIR=/home/bob/brooklyn-managed-processes/installs/DockerHost_1.2
+ mkdir -p /home/bob/brooklyn-managed-processes/installs/DockerHost_1.2
+ cd /home/bob/brooklyn-managed-processes/installs/DockerHost_1.2
+ test -f BROOKLYN
+ which curl
+ which zypper
+ which apt-get
+ echo apt-get exists, doing update
+ export DEBIAN_FRONTEND=noninteractive
+ DEBIAN_FRONTEND=noninteractive
+ test 1002 -eq 0
+ sudo -E -n -S -- apt-get update
sudo: a password is required
+ true
+ test 1002 -eq 0
+ sudo -E -n -S -- apt-get install -y --allow-unauthenticated apt-transport-https
sudo: a password is required
+ which yum
+ which brew
+ which port
+ tee /dev/stderr
+ echo 'WARNING: no known/successful package manager to install apt-transport-https, may fail subsequently'
WARNING: no known/successful package manager to install apt-transport-https, may fail subsequently
+ sudo -E -n -u root -s -- tee -a /etc/apt/sources.list.d/docker.list
sudo: a password is required
/usr/bin/curl
+ echo deb https://get.docker.com/ubuntu docker main
/usr/bin/apt-get
+ date
apt-get exists, doing update
WARNING: no known/successful package manager to install apt-transport-https, may fail subsequently
Executed /tmp/brooklyn-20150202-144058411-Fg5X-installing_DockerHostImpl_id_D.sh, result 0


Error possibly related to react functional components

I'm getting the following error with the latest release (2.1.2):
react.development.js:315 Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of `Map`.
    in Map (created by Transition)
    in Transition (created by ForwardRef(Slide))
    in ForwardRef(Slide) (created by HomePage)
    in div (created by HomePage)
    in div (created by ForwardRef(Paper))
    in ForwardRef(Paper) (created by WithStyles(ForwardRef(Paper)))
    in WithStyles(ForwardRef(Paper)) (created by HomePage)
    in HomePage (created by WithWidth(HomePage))
    in WithWidth(HomePage) (created by Context.Consumer)
    in withRouter(WithWidth(HomePage)) (created by Query)
    in Query (created by Context.Consumer)
    in DocumentTitle (created by SideEffect(DocumentTitle))
    in SideEffect(DocumentTitle) (created by HomeRoute)
    in HomeRoute (created by Context.Consumer)
    in SecureRoute
    in Switch
    in div (created by Navigation)
    in Navigation (created by Context.Consumer)
    in withRouter(Navigation) (created by WithWidth(withRouter(Navigation)))
    in WithWidth(withRouter(Navigation)) (created by Mutation)
    in Mutation (created by App)
    in MuiPickersUtilsProvider (created by App)
    in ThemeProvider (created by App)
    in App (created by Context.Consumer)
    in withRouter(App)
    in Router (created by BrowserRouter)
    in BrowserRouter
    in ApolloProvider
printWarning @ react.development.js:315
error @ react.development.js:287
createElementWithValidation @ react.development.js:1788
render @ Map.js:249
finishClassComponent @ react-dom.development.js:17160
updateClassComponent @ react-dom.development.js:17110
beginWork @ react-dom.development.js:18620
beginWork$1 @ react-dom.development.js:23179
performUnitOfWork @ react-dom.development.js:22157
workLoopSync @ react-dom.development.js:22130
performSyncWorkOnRoot @ react-dom.development.js:21756
(anonymous) @ react-dom.development.js:11089
unstable_runWithPriority @ scheduler.development.js:653
runWithPriority$1 @ react-dom.development.js:11039
flushSyncCallbackQueueImpl @ react-dom.development.js:11084
flushSyncCallbackQueue @ react-dom.development.js:11072
unbatchedUpdates @ react-dom.development.js:21909
legacyRenderSubtreeIntoContainer @ react-dom.development.js:24757
render @ react-dom.development.js:24840
./src/client/index.js @ index.js:31
__webpack_require__ @ bootstrap:18
(anonymous) @ bootstrap:93
(anonymous) @ bootstrap:94
index.umd.js:1 Uncaught TypeError: p[r] is not a function
    at projectionConfig.center (index.umd.js:1)
    at index.umd.js:1
    at mountMemo (react-dom.development.js:15442)
    at Object.useMemo (react-dom.development.js:15738)
    at Object.useMemo (react.development.js:1521)
    at m (index.umd.js:1)
    at renderWithHooks (react-dom.development.js:14803)
    at mountIndeterminateComponent (react-dom.development.js:17482)
    at beginWork (react-dom.development.js:18596)
    at HTMLUnknownElement.callCallback (react-dom.development.js:188)

I suspect this may be due to the switch of this project from React Class Components to React Functional Components. Seems like functional components don't play nicely with methods from class components? If so, that kind of sucks, as its going to take a considerable effort to re-write my Class components to be Functional components to be compatible with your latest releases. Is there any way it can be written to work with both?

This is occurring for me as well as I attempt to upgrade my class components to functional components. I think I've got it all setup in a complimentary way to how it was, but I'm getting this error and having a hard time reasoning about it.