Cloud Storage: Signed URL determine generation from BlobInfo

For V2: URL returned by signURL() method doesn't include parameter part: &generation=<number>, one should add it manually.
For V4: there is no way to obtain URL pointing to not the latest version of an object, adding &generation=<number> doesn't help.
As part of cloud java-storage project only V2 problem could be fixed.
V4 problem also exists in nodejs-storage:  Issue googleapis/google-cloud-java#953
And very similar issue is Issue googleapis/google-cloud-java#7044
It should be fixed on the server side.
Steps to reproduce:
Create a blob with two generation:
#> gsutil versioning set on gs://bucket_generation_signed
Enabling versioning for gs://bucket_generation_signed/...
#> echo The very first version > some.txt
#> gsutil cp some.txt gs://bucket_generation_signed
Copying file://some.txt [Content-Type=text/plain]...
/ [1 files][   23.0 B/   23.0 B]
Operation completed over 1 objects/23.0 B.
#> echo Updated version of the file > some.txt
#> gsutil cp some.txt gs://bucket_generation_signed
Copying file://some.txt [Content-Type=text/plain]...
/ [1 files][   28.0 B/   28.0 B]
Operation completed over 1 objects/28.0 B.
#> gsutil ls -a gs://bucket_generation_signed/some.txt
gs://bucket_generation_signed/some.txt#1576656755290328
gs://bucket_generation_signed/some.txt#1576656816500788

Run the following code:
    public static void main(String... args) throws Exception {
        List<String> al = Arrays.asList("https://www.googleapis.com/auth/cloud-platform");
        String googleCredentialsJson = new String(Files.readAllBytes(Paths.get("bucket_generation_signed.json")));
        GoogleCredentials credentials = GoogleCredentials
                .fromStream(new ByteArrayInputStream(googleCredentialsJson.getBytes())).createScoped(al);
        Storage storage = StorageOptions.newBuilder().setCredentials(credentials).build().getService();

        String bucketName = "bucket_generation_signed";
        String blobName = "some.txt";
        long generation =<PHONE_NUMBER>290328L;

        BlobId blobId = BlobId.of(bucketName, blobName, generation);
        Blob blob = storage.get(blobId, Storage.BlobGetOption.generationMatch());
        System.out.println("blob: " + blob);
        System.out.println("v2 " + blob.signUrl(20, TimeUnit.MINUTES, Storage.SignUrlOption.withV2Signature()));
        System.out.println("v4 " + blob.signUrl(20, TimeUnit.MINUTES, Storage.SignUrlOption.withV4Signature()));
    }

The output will look like:
blob: Blob{bucket=bucket_generation_signed, name=some.txt, generation=1576656755290328, size=23, content-type=text/plain, metadata=null}

v2 https://storage.googleapis.com/bucket_generation_signed/some.txt?GoogleAccessId=my-service-account...uJWWFsyd9cfa4FrOSmw%3D%3D

v4 https://storage.googleapis.com/bucket_generation_signed/some.txt?X-Goog-Algorithm=GOOG4-RSA-SHA256&...076f845e952a7

Both returned URLs will point to the latest version:
Updated version of the file
Despite the blob generation is explicitly specified: generation=1576656755290328

Hi @dmitry-fa,
Thanks for filing this issue.
Right now a user of the signUrl() method is required to provide Query Parameters here's the working example.
package com.example.storage;

import com.google.auth.oauth2.GoogleCredentials;
import com.google.cloud.storage.Blob;
import com.google.cloud.storage.BlobId;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;
import com.google.common.collect.ImmutableMap;

import java.io.ByteArrayInputStream;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Arrays;
import java.util.List;
import java.util.concurrent.TimeUnit;

public class ExampleOther {
    public static void main(String... args) throws Exception {
        Storage storage = StorageOptions.getDefaultInstance().getService();

        String bucketName = "anima-frank";
        String blobName = "test";
        long generation =<PHONE_NUMBER>998095L;

        BlobId blobId = BlobId.of(bucketName, blobName, generation);
        Blob blob = storage.get(blobId, Storage.BlobGetOption.generationMatch());
        System.out.println("blob: " + blob);
        System.out.println("v2 " + blob.signUrl(20, TimeUnit.MINUTES, Storage.SignUrlOption.withV2Signature()));
        System.out.println("v4 " + blob.signUrl(20, TimeUnit.MINUTES, Storage.SignUrlOption.withV4Signature(),
                Storage.SignUrlOption.withQueryParams(ImmutableMap.of("generation", "1579134868998095"))));
    }
}

At the moment signUrl doesn't get information from the generation value set in the Blob, but is a good feature request to follow-up on.
HTH for now.

Hi @frankyn,
Thanks for your response. The example works for me.

At the moment signUrl doesn't get information from the generation value set in the Blob, but is a good feature request to follow-up on.

Do you believe it is a backend duty to take care of generations (issue#146802530) or this should be implemented on the client side?

No this is primarily client side only. Could you close that bug.
For right now, this is WAI. V2 doesn't require all query parameters to be signed, therefore a user can add additional query parameters without failing the signature check.
I'd leave this open as a feature request rather than a bug because we have an intended path for folks to use.

It seems that Storage.signUrl(BlobInfo) can distinguish cases when generation is explicitly specified, from cases when generation is not needed:
storage.signUrl(BlobInfo.newBuilder(bucketName, blobName, generation).build(), ...)
storage.signUrl(BlobInfo.newBuilder(bucketName, blobName).build(), ...)

But this is not always easy:
BlobInfo blobInfo = BlobInfo.newBuilder(bucketName, blobName).build();
      // blobInfo.getGeneration() !== null
Blob blob = storage.createBlob(blobInfo);
     // blob.getGeneration() !== null
storage.signUrl(blob);

Including generation in signed URL by default is not a good idea. People will be confused if their URL starts point to an outdated resource. I hope, giving examples on how to sign URL for a blob generation should be enough.


cannot import name '_ElementStringResult' from 'lxml.etree

If you just run:
pip install extruct
And then:
import extruct
You should get the error:
cannot import name '_ElementStringResult' from 'lxml.etree
Reverting to a previous version of lxml solves this:
pip install lxml==5.1.0

see #215

Sorry about that, a quick search didn't pull that issue up for whatever reason


Fix for CI

Rel: https://github.com/pfnet-research/chainer-compiler/pull/803

/test

Moved to: https://github.com/momohatt/chainer-compiler/pull/1

Thanks!


Sample Code validations, edits, and additions

Thank you for your contribution to the IC Developer Portal.
Before submitting your Pull Request, please make sure that:

[x] You have updated the .github/CODEOWNERS file according to your changes.
[x] You have registered new documents to /sidebars.js if any.

This PR validates the accuracy of the following Sample Code tutorials/pages:

Hello, world!
Basic decentralized autonomous organization (DAO)
Deploying your first Bitcoin dapp
Decentralized exchange (DEX) sample
Encrypted note-taking dapp
Hosting a web game on the Internet Computer

Some of these pages have had the tutorials clarified through the use of additional steps or language changes, and other pages that previously lacked tutorial content had that content added. Each page was validated that the commands and workflows used are working as expected and can be reproduced.
The README doc for the portal repo also received minor edits to include mention of the new Style Guide document.

Closed because the changes got merged in a later PR, so this PR is no longer needed


Memory leaks in WASM

Currently there are memory leaks in WASM and it looks like a limitation of WASM, but we need further investigation.
Useful information:

Firefox has a about:memory which shows some extra information about the worker
Firefox Nightly has a DMD mode, which can be used for memory profiling. Run DTD=1 ./firefox in nightly's directory.
Stack Overflow: How can I free memory allocated by Rust code exposed in WebAssembly?
https://github.com/WebAssembly/design/issues/1397
Check wasm-pack's --weak-refs and --reference-types

I just ruled out that this could be a memory fragmentation on the Rust side.
Rust allocates a single continuous memory region my using memory_grow instruction. That memory region is then used by dlmalloc to provide Rust's global allocation. When dlmalloc uses all the memory of that region, it calls memory_grow again to allocate more space. Whatever is allocated by memory_grow can not be freed. I used memory_size to check how much memory was purely allocated for Rust.
After an hour or so, browser's task manager was showing 3GB of memory consumption by Lumina tab. However the memory region that was used by Rust was at 103mb, almost from the beginning of the syncing. This concludes that memory leaks are tightly related to JavaScript's types.

After reading JS Objects in Rust from wasm-bindgen's internal design documentation I ruled out the posibility that memory leak is happening because of Rust not freeing JS objects.
I was printing wasm_bindgen::externref_heap_live_count every 1 minute. In case of memory leak, that value should have constantly increasing to a huge number over time, which didn't happen.

After ruling out the above, I couldn't understand why memory consumption of Lumina's tab was increasing and even becoming more than 3GB.
Throughout all my investigation I was using Allocation instrumentation on timeline of Chrome, trying to pin point the leak. While doing that I was ignoring Performance, PerformanceMark, and PerformanceMeasure from the allocations, thinking that they existed because of the instrumentation.
I started checking random things to find any other clues about the leak, including of reading code of wasm-bindgen generated file lumina_node_wasm.js. Then I notice this:
    imports.wbg.__wbg_mark_6045ef1772587264 = function() { return handleError(function (arg0, arg1, arg2) {
        getObject(arg0).mark(getStringFromWasm0(arg1, arg2));
    }, arguments) };
    imports.wbg.__wbg_mark_bad820680b8580c2 = function() { return handleError(function (arg0, arg1, arg2, arg3) {
        getObject(arg0).mark(getStringFromWasm0(arg1, arg2), getObject(arg3));
    }, arguments) };
    imports.wbg.__wbg_measure_1d846b814d43d7e1 = function() { return handleError(function (arg0, arg1, arg2, arg3, arg4, arg5, arg6) {
        getObject(arg0).measure(getStringFromWasm0(arg1, arg2), getStringFromWasm0(arg3, arg4), getStringFromWasm0(arg5, arg6));
    }, arguments) };
    imports.wbg.__wbg_measure_7ca0e5cfef892340 = function() { return handleError(function (arg0, arg1, arg2, arg3) {
        getObject(arg0).measure(getStringFromWasm0(arg1, arg2), getObject(arg3));
    }, arguments) };
    imports.wbg.__wbg_performance_72f95fe5952939b5 = function() {
        const ret = globalThis.performance;
        return addHeapObject(ret);
    };

Which indicates that our Rust code at some point is using Performance.mark() and Performance.measure(). I started looking on our dependencies and found that tracing-web is using it in its performance layer. After checking our initialization of tracing-web, I realized that we are actually enabling the performance layer, so I commented it out.
After doing that, memory consumption stopped increasing to that huge numbers! That was the leak! 🥳


Redefine internal Kingdom proto messages to support v2alpha public API.

This is for #52.

This change is

Added MeasurementLogEntry, intended to replace ReportLogEntry. PTAL.


Add phosphor-react-sc to community projects

As you're by now aware we have experimental RSC support working and live, I hope you don't feel hurt if we don't want to drive people over to your repo. Thanks for putting in the work though, truly <3


chore: Add fallback user agent

What
For: #3534
Honestly, I couldn't find a problem, here I added a fallback userAgent in cases where native calls to get device information may fail.
+ Added some logging for these cases

Codecov Report

Merging #3546 (f9bcd17) into develop (a5949dc) will increase coverage by 0.00%.
The diff coverage is 0.00%.

@@           Coverage Diff            @@
##           develop    #3546   +/-   ##
========================================
  Coverage    11.08%   11.08%
========================================
  Files          262      262
  Lines        12945    12941    -4
========================================
  Hits          1435     1435
+ Misses       11510    11506    -4

Impacted Files
Coverage Δ

...ackages/smooth_app/lib/helpers/network_config.dart
0.00% <0.00%> (ø)

packages/smooth_app/lib/query/product_query.dart
7.89% <0.00%> (-0.22%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@raphael0202 In your log we can see correct values in the URL parameters, that are related to the user agent:
app_name=Smoothie+-+OpenFoodFacts
app_version=4.2.1%2B897
app_uuid=5839af8f522d4029
app_platform=android%2BPPR1.180610.011.G950FXXUCDVG5
comment

I think that the problem may come from

when we switched from api v2 in POST to api v3 in GET - about one month ago
the fact that we spell "UserAgent" and it looks like the correct spelling is "User-Agent" (the spelling hasn't changed in years in off-dart)
why would "UserAgent" be understood in POST but not in GET? That wouldn't be the first unwanted fix that cause confusion (side-note: in JPEG files there's some kind of rotation parameter - some browsers take that into consideration, but some don't, and by the time you understood that you spent a lot of energy with "Am I crazy or what?"s) (but that's another story)

I'm going to fix the spelling. Hopefully that will work.

Honestly, I couldn't find a problem, here I added a fallback userAgent in cases where native calls to get device information may fail.

@M123-dev It looks like I fixed it on the off-dart level. I think we don't need this PR after all.


wix3

Summary of the Pull Request

PR Checklist

[ ] Closes: #xxx
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

This looks like a change for a personal setup? What is the reason to create a pull request? /needinfo

Yes, this appears to be a local setup PR. Feel free to let us know if we should reconsider!


Not supported file mask

I want to specify mask of files, which can be available to add.  'fileType' doesn't filter files (it's only alert, when I add file, which doesn't contain in fileType array.

The code currently skips files that does not have the expected file extension, as seen here: https://github.com/23/resumable.js/blob/master/resumable.js#L364-L367
As such, it does work as a file extension mask. Make sure you pass an array of file extensions (without the dot), such as ["pdf","gif","jpg", "jpeg"].
The default implementation of fileTypeErrorCallback simply outputs a warning that the file is not valid, which you can overwrite with your own implementation (to give visual feedback, cancel the upload, etc.)


MINOR: tighten condition for logging StreamThread summary to avoid spam under low traffic

Noticed these messages flooding the logs on several integration tests. Since it doesn't really provide any useful information, we may as well skip the logging when there are no new records to be processed.
Should be cherrypicked back to the 2.7 branch

call for a quick review from any of @cadonna @lct45 @wcarlson5

call for a quick review from any of @cadonna @lct45 @wcarlson5

Merged to trunk and cherrypicked to 2.7

Merged to trunk and cherrypicked to 2.7


04_arrays.zig - missing ":" for type of example array

Small fix, the first example declares the array with a type but does not include the colon which I believe is invalid syntax.

Yup, you're right. Thanks for catching this!


[FLINK-35654][docs] Add CDC release verification & Installation guide

This closes FLINK-35654.
Currently, ASF voting process requires vast quality verification before releasing any new versions, including:

Tarball checksum verification
Compile from source code
Run pipeline E2e tests
Run migration tests
Check if jar was packaged with correct JDK version
...

Adding verification SOP in "Contribution guide" of Flink CDC docs should help developers verify future releases more easily.

Thanks for @morazow's comments! Addressed most of them, and left several requires further discussion.


Fix: Changing settings screen pallets colors

Description:

I changed the color of settings screen along with all the buttons styles and color
Linked issues:

Screenshots:

How to test:

Tienes que hacer  yarn test -- -u
para actualizar los snapshots


Revert "Update version: KRTirtho.Spotube version 3.6.0+30 (#149329)"

Fixes #149800 with removing duplicated 3.6.0 manifest
This reverts commit 84c96cc23e38e9ae4c1c60b2d77f9dd5ec2803a0.
This PR does not revert 14d5819740e3d6238b824e7ebe191fc33936d8a2 and c245ebdf5074467398acf8cb6b2d6c0e828387dc
Because the versions aren't duplicated and reverting 14d5819740e3d6238b824e7ebe191fc33936d8a2 makes downgrading schema version from 1.6.0
Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[x] Is there a linked Issue?

Manifests

[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

cc: @KRTirtho @hlqviet
Microsoft Reviewers: Open in CodeFlow

Thank you!


Add support for Beaglebone Blue to resinOS

Get resinOS booting and wireless working on the Beaglebone Blue board.

@willnewton can you link the PR and close this issue? I think it is done. BTW, the current implementation just uses the same image as bbb, right?

Added here: https://github.com/resin-os/resin-beaglebone/pull/79
The current implementation is to use machine "beaglebone" for BeagleBone Blue (as well as Black and in theory other types).

CC @shaunmulligan

This is cool! so eventually over time we could look at removing the other Beaglebone device types right?

That's the plan - as soon as we can handle the old device types.


Solved bug #94: wrong password generation and bug #95: inactive users can login

Solved bug #95 by adding additional check for is_active status of user.
Inactive users now can't login.

if you remove the line you commented, all tests will pass, can you do that? Then I'll approve the pull request.

the whole line needs to be removed:
./arctic/users/forms.py:39:1: W293 blank line contains whitespace

Sorry. Removed the whole line.


publicPath in nuxt.config.js build causes 404 errors for .js files

I have publicPath like following in my nuxt.config:
build: {
  publicPath: '/se/_nuxt/',
  //...
}

which causes 404 errors for the .js files on now v2. It works great in other node environments like now v1 or others I have.
Is there a way to achieve that with now v2?

@silvio-e Would you mind testing the PR I've just submitted? I think it should fix your problem but my repro may differ from yours - and in any case would welcome your feedback. You can do it by adding nuxt/now-builder#support-nuxt-config-default-export as your builder in now.json.

@silvio-e Note this has now been merged so you can test with @nuxtjs/now-builder as usual.


Slow graph traversal query

My Environment

ArangoDB Version:        3.6.1
Storage Engine:             RocksDB
Deployment Mode:       Cluster
Deployment Strategy:  Manual Start in Docker
Infrastructure:               Local
Operating System:        Ubuntu 18.04

Component, Query & Data
Affected feature: Graph traversal using AQL
AQL query (if applicable):
 FOR vertex, edge, path IN 1..1 INBOUND @id GRAPH 'my_graph'
     LIMIT 0, 20
     RETURN {related_object: vertex, relationship: edge}

AQL explain (if applicable):
Execution plan:
 Id   NodeType          Site  Calls   Items   Runtime [s]   Comment
  1   SingletonNode     COOR      1       1       0.00000   * ROOT
  2   TraversalNode     COOR      1      20       6.46067     - FOR vertex  /* vertex */, edge  /* edge */ IN 1..1  /* min..maxPathDepth */ INBOUND @id /* startnode */  GRAPH 'stix_graph'
  4   CalculationNode   COOR      1      20       0.00009       - LET #5 = { "related_object" : vertex, "relationship" : edge }   /* simple expression */
  3   LimitNode         COOR      1      20       0.00001       - LIMIT 0, 20
  5   ReturnNode        COOR      1      20       0.00000       - RETURN #5

Indexes used:
 By   Name   Type   Collection           Unique   Sparse   Selectivity   Fields      Ranges
  2   edge   edge   relationships   false    false         2.33 %   [ `_to` ]   base INBOUND

Traversals on graphs:
 Id  Depth  Vertex collections  Edge collections    Options                                  Filter / Prune Conditions
 2   1..1   objects        relationships  uniqueVertices: none, uniqueEdges: path

Optimization rules applied:
 Id   RuleName
  1   move-calculations-up
  2   optimize-traversals

Query Statistics:
 Writes Exec   Writes Ign   Scan Full   Scan Index   Filtered   Exec Time [s]
           0            0           0           20          0         6.59054

Query Profile:
 Query Stage           Duration [s]
 initializing               0.00000
 parsing                    0.00067
 optimizing ast             0.00001
 loading collections        0.00000
 instantiating plan         0.00003
 optimizing plan            0.00124
 executing                  6.46079
 finalizing                 0.12779

Steps to reproduce
Dataset: The dataset has 1,566,615 vertices and 2,151,773 edges. Both of the collection have one shard only.
The starting vertex of our query is in the _to field of 709,698 edges.
Problem: The query is taking way too much time. A limit was applied on it. In a single server setup with the same dataset the query is taking 0.00173 seconds
Expected result: The query doesn' t take that much time even if it makes sense it is slower than in a single server setup.
Note: the same query in a non traversal way is a lot faster:
FOR edge IN relationships
    FILTER edge._to == @id
    LIMIT 0, 20
    FOR vertex IN objects
        FILTER vertex._id == edge._from
        RETURN {related_object: vertex, relationship: edge}

is taking 0.44302 seconds

Hi @Darkheir,
would it be possible for you to share your dataset with us? You may mask sensitive information. What we need to know is the data distribution of your dataset (like how many edges are connected to the vertex to start the traversal at), and also which start vertices you tried the query with.

Hi, as stated in the initial post there are 709,698 edges connected to the initial vertex and I think this the the cause of the performance issue.
It doesn't explain why the traversal query takes way more time than the nested FOR loop I described in the issue.
My guess was that the coordinators had to retrieve all the edges before being able to get the 20 vertex I needed, but since I don't know anything about the internals I may be totally wrong.

1 vertex -> 700k outbound edges seems like the likely cause, but I need to pass this on to one of our graph developers for technical details. If it's not a performance problem in single server, then it seems unlikely that running through the linked list of edges connected to the vertex itself is the problem. It might be communication overhead between cluster nodes. How is your graph distributed (number of shards, replication factor etc.)?

In our cluster we have:

3 primary servers
3 coordinators
3 agents

Both of the collections (edges and vertices) have:

Shards: 1
Replication factor: 2

There is a known issue with LIMIT in graph operations not being forwarded forcefully enough. Our lead graph engineer also mentioned the OneShard optimizations (Enterprise Edition), which could help in a setup like yours with a single shard (placing the vertex and edge collection shards on the same server and enabling local operations).

Thank you for the answer.
Is there any plan to fix this issue in the upcoming 3.6.2 release ?
We are aware that OneShard might improve the performances, but the use case of a graph traversal with a limit seems common enough to run with acceptable performances.

There are some graph related optimizations in the works for 3.7, but not 3.6 as far as I am aware. The team is currently busy with part 2 of the AQL execution refactor, so can't promise anything at the moment.

Hi!
This graph traversal query
FOR v,e,p IN 0..5 ANY 'companies/81140000436' GRAPH 'counterparty' OPTIONS {bfs: true, uniqueVertices: 'path'} RETURN {v, e}
executes in ~400 ms, but when I set maxDepth to 8 like 0..8 it executes in ~90 seconds. How can I optimize it?
ArangoDB version: 3.7.3
Profile of the query
Query String (126 chars, cacheable: false):
 FOR v, e, p IN 0..5 ANY 'companies/81140000436' GRAPH 'counterparty' OPTIONS {bfs: true,
 uniqueVertices: 'path'} RETURN {v, e}

Execution plan:
 Id   NodeType          Calls   Items   Runtime [s]   Comment
  1   SingletonNode         1       1       0.00001   * ROOT
  2   TraversalNode        21   20708       0.39763     - FOR v  /* vertex */, e  /* edge */ IN 0..5  /* min..maxPathDepth */ ANY 'companies/81140000436' /* startnode */  GRAPH 'counterparty'
  3   CalculationNode      21   20708       0.02028       - LET #5 = { "v" : v, "e" : e }   /* simple expression */
  4   ReturnNode           21   20708       0.00219       - RETURN #5

Indexes used:
 By   Name   Type   Collection   Unique   Sparse   Selectivity   Fields        Ranges
  2   edge   edge   relations    false    false        53.53 %   [ `_to` ]     base INBOUND
  2   edge   edge   relations    false    false        89.28 %   [ `_from` ]   base OUTBOUND

Traversals on graphs:
 Id  Depth  Vertex collections      Edge collections  Options                                               Filter / Prune Conditions
 2   0..5   companies, individuals  relations         bfs: true, , uniqueVertices: path, uniqueEdges: path

Optimization rules applied:
 Id   RuleName
  1   optimize-traversals

Warnings:
 Code   Message
 1202   vertex 'companies/90440011005' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/71040010120' not found
 1202   vertex 'companies/61140005601' not found

Query Statistics:
 Writes Exec   Writes Ign   Scan Full   Scan Index   Filtered   Exec Time [s]
           0            0           0        20708          0         0.42094

Query Profile:
 Query Stage           Duration [s]
 initializing               0.00000
 parsing                    0.00024
 optimizing ast             0.00001
 loading collections        0.00001
 instantiating plan         0.00006
 optimizing plan            0.00017
 executing                  0.42023
 finalizing                 0.00021

Hi!
This graph traversal query
FOR v,e,p IN 0..5 ANY 'companies/81140000436' GRAPH 'counterparty' OPTIONS {bfs: true, uniqueVertices: 'path'} RETURN {v, e}
executes in ~400 ms, but when I set maxDepth to 8 like 0..8 it executes in ~90 seconds. How can I optimize it?
ArangoDB version: 3.7.3
Profile of the query
Query String (126 chars, cacheable: false):
 FOR v, e, p IN 0..5 ANY 'companies/81140000436' GRAPH 'counterparty' OPTIONS {bfs: true,
 uniqueVertices: 'path'} RETURN {v, e}

Execution plan:
 Id   NodeType          Calls   Items   Runtime [s]   Comment
  1   SingletonNode         1       1       0.00001   * ROOT
  2   TraversalNode        21   20708       0.39763     - FOR v  /* vertex */, e  /* edge */ IN 0..5  /* min..maxPathDepth */ ANY 'companies/81140000436' /* startnode */  GRAPH 'counterparty'
  3   CalculationNode      21   20708       0.02028       - LET #5 = { "v" : v, "e" : e }   /* simple expression */
  4   ReturnNode           21   20708       0.00219       - RETURN #5

Indexes used:
 By   Name   Type   Collection   Unique   Sparse   Selectivity   Fields        Ranges
  2   edge   edge   relations    false    false        53.53 %   [ `_to` ]     base INBOUND
  2   edge   edge   relations    false    false        89.28 %   [ `_from` ]   base OUTBOUND

Traversals on graphs:
 Id  Depth  Vertex collections      Edge collections  Options                                               Filter / Prune Conditions
 2   0..5   companies, individuals  relations         bfs: true, , uniqueVertices: path, uniqueEdges: path

Optimization rules applied:
 Id   RuleName
  1   optimize-traversals

Warnings:
 Code   Message
 1202   vertex 'companies/90440011005' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/960140003620' not found
 1202   vertex 'companies/980640001418' not found
 1202   vertex 'companies/71040010120' not found
 1202   vertex 'companies/61140005601' not found

Query Statistics:
 Writes Exec   Writes Ign   Scan Full   Scan Index   Filtered   Exec Time [s]
           0            0           0        20708          0         0.42094

Query Profile:
 Query Stage           Duration [s]
 initializing               0.00000
 parsing                    0.00024
 optimizing ast             0.00001
 loading collections        0.00001
 instantiating plan         0.00006
 optimizing plan            0.00017
 executing                  0.42023
 finalizing                 0.00021

There is a known issue with LIMIT in graph operations not being forwarded forcefully enough.

Do you know if this issue has been addressed in new releases ?
We still have the issue in 3.8.5-1 but maybe it was solved in earlier releases ?

Also seeing a really slow query. Running a cluster with 3 nodes, replication factor of 3, 3 agents, 3 coords and 3 databases. so baiscally each node has their own agent, coord and database.
cluster:

failover:

This is 0.8 seconds slower on cluster and I cant find any way this should be a reality? Any on what to look for?
Tested all these
3.7.12 - 0.8s
3.8.7 - 0.8s
3.9.3 - 0.8s
3.10.0 - 0.8s


Revert "west.yml: Update TFM module SHA to..."

This patch is breaking CI.
This reverts commit 8f18b86ee884838ea10cfff9166288f796859796.
Signed-off-by: Andrew Boie<EMAIL_ADDRESS>

cc @oyvindronningstad

What's going on?

What's going on?

The build is broken, CI is failing
mkdir -p doc/_build && cmake -GNinja -DDOC_TAG=development -DSPHINXOPTS=-q -Bdoc/_build -Hdoc/ && ninja -C doc/_build htmldocs
-- Zephyr base: /home/runner/work/zephyr/zephyr
-- West: /home/runner/.local/bin/west (west --version: "West version: v0.8.0")
-- Found Python3: /usr/bin/python3.6 (found suitable exact version "3.6.9") found components: Interpreter
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") found components: doxygen
-- Could NOT find LATEX (missing: LATEX_COMPILER)
-- Zephyr version: 2.4.99 (/home/runner/work/zephyr/zephyr)
CMake Error at /home/runner/work/zephyr/zephyr/cmake/zephyr_module.cmake:48 (message):
-- Configuring incomplete, errors occurred!
  Traceback (most recent call last):
    File "/home/runner/work/zephyr/zephyr/scripts/zephyr_module.py", line 326, in <module>
      main()
    File "/home/runner/work/zephyr/zephyr/scripts/zephyr_module.py", line 235, in main
      manifest = Manifest.from_file()
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 977, in from_file
      return Manifest(**kwargs)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1158, in __init__
      ctx or _import_ctx({}, None, Path('.')))
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1367, in _load
      self._load_projects(manifest, url_bases, defaults, ctx)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1580, in _load_projects
      self._import_from_project(project, imp, ctx)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1692, in _import_from_project
      self._import_path_from_project(project, _WEST_YML, ctx)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1714, in _import_path_from_project
      imported = self._import_content_from_project(project, path)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 1777, in _import_content_from_project
      content = self._importer(project, path)
    File "/home/runner/.local/lib/python3.6/site-packages/west/manifest.py", line 165, in _default_importer
      raise ManifestImportFailed(project, file)
  west.manifest.ManifestImportFailed: ManifestImportFailed: project <Project
  trusted-firmware-m ('/home/runner/work/zephyr/modules/tee/tfm') at
  867d714099168481d8ca4ff9de9bfa7c27a0ec63> file west.yml
Call Stack (most recent call first):
  CMakeLists.txt:47 (include)
See also "/home/runner/work/zephyr/zephyr/doc/_build/CMakeFiles/CMakeOutput.log".
Makefile:15: recipe for target 'htmldocs' failed
make: *** [htmldocs] Error 1

When stuff like this happens the offending patch is immediately reverted so people's pull requests stop failing, and whoever contributed it can resubmit. @mbolivar told me it was your patch, so here we are.

@oyvindronningstad here's a snippet from #west on slack:
jhe  10:46 AM
@mbolivar-nordic curiously, I can see documentation check
failures due to the same manifest error in all latest
upstream PRs (edited)

mbolivar-nordic  10:47 AM
ugh

jhe  10:47 AM
e.g. here: https://github.com/zephyrproject-rtos/zephyr/pull/30608

mbolivar-nordic  10:47 AM
@galak this is due to the PR which added import: true to tfm repo entry
in zephyr/west.yml ^^ (edited)
10:47
cc @carlesc
10:48
looks like the "west setup" part is just running west init but not
west update
10:48
https://github.com/zephyrproject-rtos/zephyr/pull/30608/checks?check_run_id=1532651878

If this revert gets merged, your options will be:

fixing whatever github action is responsible for the the "west setup" part that's not doing "west update" in the docs build (if using import: true)

just adding the TFM copy of mcuboot to zephyr/west.yml instead of using imports (which is what @carlescufi and I were advocating for on slack; I was surprised to see the import got merged without time for @carlescufi to weigh in)


Problem with firing up samples

After executing mvn eclipse:eclipse in gwtupload/samples i get the following unresolved dependencies error

[ERROR] Failed to execute goal on project gwtupload-samples: Could not resolve dependencies for project com.googlecode.gwtupload:gwtupload-samples:war:1.0.4-SNAPSHOT: The following artifacts could not be resolved: gwtchismes:gwtchismes:jar:0.9.7, com.google.gwt:gwt-incubator:jar:20101117-r1766: Could not find artifact gwtchismes:gwtchismes:jar:0.9.7 in repo1 (http://repo1.maven.org/maven2/) -> [Help 1]

Is it worth to still use this library?

This seems to have disappeared from maven for some reason... not sure why that would happen. I have a copy here. Just copy it into your .m2/repository folder and it should work. @manolo Do you know what is happening here?

Same for me, please fix

Also Failure to find com.google.gwt:gwt-incubator:jar:20101117-r1766

Also
Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project jsupload: An Ant BuildException has occured: The directory /home/ishadrin/workspace/gwtupload/jsupload/target/gwtupload.wiki does not exist
[ERROR] around Ant part ...<exec dir="target/gwtupload.wiki" executable="true">... @ 13:55 in /home/ishadrin/workspace/gwtupload/jsupload/target/antrun/build-main.xml

Whoever finds this, I made a small fix to build the library. It's not perfectly secure (I replaced a repo with a 3rd party one) but everything seems to work so... you've been warned.
diff --git a/pom.xml b/pom.xml
index 41cb7e3..12a58f4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -29,9 +29,9 @@
     <gwtMaven>2.7.0</gwtMaven>
     <commonsFileuploadVersion>1.3.1</commonsFileuploadVersion>
     <commonsIoVersion>2.3</commonsIoVersion>
-    <gwtChismesVersion>0.9.7</gwtChismesVersion>
+    <gwtChismesVersion>0.9.8</gwtChismesVersion>
     <gwtExporterVersion>2.4.0-M1</gwtExporterVersion>
-    <gwtIncubatorVersion>20101117-r1766</gwtIncubatorVersion>
+    <gwtIncubatorVersion>2.0.1</gwtIncubatorVersion>
     <junitVersion>3.8.2</junitVersion>
     <log4jVersion>1.2.16</log4jVersion>
     <commonsLang3Version>3.1</commonsLang3Version>
@@ -183,7 +183,7 @@
   <repositories>
     <repository>
       <id>repo1</id>
-      <url>http://repo1.maven.org/maven2/</url>
+      <url>https://repo1.maven.org/maven2/</url>
     </repository>
     <repository>
       <id>gwtupload</id>
@@ -191,7 +191,7 @@
     </repository>
     <repository>
       <id>gwtchismes</id>
-      <url>http://gwtchismes.googlecode.com/svn/mavenrepo/</url>
+      <url>http://logicaldoc.sourceforge.net/maven/</url>
     </repository>
     <repository>
       <id>timepedia</id>


Build bamoe-9.0.0-maven-repository.zip product artifact

We need to build IBM Business Automation Manager Open Editions 9.0.0 - Maven Repository product artifact.
It is needed to check the 8.x Maven repository to see if we need to include also dependencies or not.
Acceptance criteria:

Zip created that contains all Maven product artifacts - from Drools repository, kogito-runtimes repository, kogito-apps repository.
The zip file is uploaded to a specified folder.

It should be only our dependencies. PR merged. Closing.


Italics no longer works across multiple lines

In multimarkdown 4.7.1, italics/emphasis would work even if the inner text spanned a newline character. For example:
printf "_Multiline\nitalics_" | multimarkdown

produced

Multiline
italics

Now, in version 5.0.1 this is broken, so that
printf "_Multiline\nitalics_" | multimarkdown

produces

_Multiline
italics_

Now I'm a little confused. On Mac OS X with MultiMarkdown 4.7.1 installed via homebrew, italics works across newline. But installing MultiMarkdown 4.7.1 on Linux Ubuntu, I get the same behavior as MultiMarkdown 5.0.1 (italics does not work across newline). Could this really be OS dependent?

Not sure what you're doing in regards to 4.7.1, but I pushed a fix for 5 to the develop branch (will be included in next official release, or you can build now).
Thanks!


modify the resourceGroupId of TCCResource

Ⅰ. Describe what this PR did
modify the group resource id of TCCResource from 'DEFAULT' to 'TCC', this can avoid the conflict between resource ids of TCCResource and DataSourceProxy
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

@tswstarplanet Can you describe the problem that occurred?

@tswstarplanet Can you describe the problem that occurred?

the default resourceGroupId is duplicated with that of DataSourceProxy. In some cases, it may cause problems. Such as use the resourceGroupId as key to cash the Resource in a map.

Codecov Report

Merging #1442 into develop will decrease coverage by 0.35%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##             develop    #1442      +/-   ##
=============================================
- Coverage      45.76%   45.41%   -0.36%
+ Complexity      1666     1664       -2
=============================================
  Files            347      345       -2
  Lines          12711    12708       -3
  Branches        1589     1611      +22
=============================================
- Hits            5817     5771      -46
- Misses          6252     6289      +37
- Partials         642      648       +6

Impacted Files
Coverage Δ
Complexity Δ

tcc/src/main/java/io/seata/rm/tcc/TCCResource.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...va/io/seata/rm/datasource/exec/InsertExecutor.java
67.85% <0%> (-17.22%)
20% <0%> (ø)

...m/datasource/undo/parser/JacksonUndoLogParser.java
55.55% <0%> (-9.57%)
4% <0%> (ø)

.../java/io/seata/rm/datasource/DataCompareUtils.java
70.73% <0%> (-4.62%)
27% <0%> (+2%)

...server/store/file/FileTransactionStoreManager.java
45.99% <0%> (-1.4%)
19% <0%> (ø)

...seata/rm/datasource/undo/AbstractUndoExecutor.java
83.15% <0%> (-0.02%)
20% <0%> (-1%)

...va/io/seata/rm/datasource/exec/UpdateExecutor.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...ta/rm/datasource/exec/SelectForUpdateExecutor.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

...o/seata/server/coordinator/DefaultCoordinator.java
50% <0%> (ø)
25% <0%> (ø)
:arrow_down:

...va/io/seata/rm/datasource/exec/DeleteExecutor.java
0% <0%> (ø)
0% <0%> (ø)
:arrow_down:

... and 9 more

Continue to review full report at Codecov.

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

Codecov Report

Merging #1442 into develop will increase coverage by 0.32%.
The diff coverage is 0.00%.

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

@tswstarplanet Can you describe the problem that occurred?

the default resourceGroupId is duplicated with that of DataSourceProxy. In some cases, it may cause problems. Such as use the resourceGroupId as key to cache the Resource in a map.

Key will only be resourceId, not resourceGroupId.


Adding extra option to allow clean on validation error

Allowing to have the clean on validation error option for quicker develpment

@crossroad0201 Can this be merged? having an option to clean on validation error would be helpful.


Unable to use some of the docker API due to vendoring issues

Description
I am trying to use version 1.13.0-rc3 of the docker api for golang. My imports are:
"github.com/docker/docker/api/types"
"github.com/docker/docker/api/types/container"
"github.com/docker/docker/api/types/network"
"github.com/docker/go-connections/nat"
"github.com/docker/go-units"

I am unable to create a HostConfig like:
portBindings := make(nat.PortMap)
var ulimits []*units.Ulimit
hostConfig := &container.HostConfig{
		PortBindings: portBindings,
		Resources: container.Resources{
			Ulimits: ulimits,
		},
	}

Due to the errors:
cannot use portBindings (type "github.com/docker/go-connections/nat".PortMap) as type "github.com/docker/docker/vendor/github.com/docker/go-connections/nat".PortMap in field value

cannot use ulimits (type []*"github.com/docker/go-units".Ulimit) as type []*"github.com/docker/docker/vendor/github.com/docker/go-units".Ulimit in field value

I cannot use the vendored versions, so how can I get around this?
Steps to reproduce the issue:

Try to create a container.HostConfig using github.com/docker/go-connections/nat.PortMap or github.com/docker/go-units.Ulimit

Describe the results you received:
Failed to compile
Describe the results you expected:
Compile

This was introduced in https://github.com/docker/docker/pull/27912#issuecomment-258334492 and a fix was previously attempted in https://github.com/docker/docker/pull/28080, which was closed without explanation.
cc @LK4D4

Quoting @dnephin on this as I do agree with him.

If you're using docker/docker as a dependency to your project you should manage your dependencies using a tool like vndr or glide. You shouldn't rely on the vendor/ directory in this project.

The workaround is to remove the vendor/ folder of the docker/docker after getting it. It's a little bit tricky depending on what you are using to manage your dependencies though.
And as @tiborvass said

Hopefully we'll find a solution as part of the ongoing works in the Go world.

This rationale is beyond absurd. The API client was previously in a
separate repository (https://github.com/docker/engine-api) but it was
deprecated and folded into docker/docker, leaving us (your users) with no
choice but to depend on docker/dcoker.
On Tue, Dec 13, 2016 at 11:05 AM, Vincent Demeester <
<EMAIL_ADDRESS>wrote:

Quoting @dnephin https://github.com/dnephin on this as I do agree with
him.
If you're using docker/docker as a dependency to your project you should
manage your dependencies using a tool like vndr or glide. You shouldn't
rely on the vendor/ directory in this project.
The workaround is to remove the vendor/ folder of the docker/docker after
getting it. It's a little bit tricky depending on what you are using to
manage your dependencies though.
And as @tiborvass https://github.com/tiborvass said
Hopefully we'll find a solution as part of the ongoing works in the Go
world.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/29362#issuecomment-266779362,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdsPAR2IsaDo-LqVMPQsQUoINvSqySIks5rHsJLgaJpZM4LLttn
.

@tamird I do agree it's not the best. It's just the current workaround, and I really wish we could somehow make it work. Having a vendor folder is a huge enhancement on the development on docker/docker itself as we don't rely on some autopath hack anymore but it broke users of the client side.
Still looking at some possible ideas like extracting the client client.APIClient to a repository for each tagged version of docker (i.e. any RC and GA releases) or something else.

Agreeing with @tamird here that it would be really great if the API client could be returned to it's own repository and be vendored into docker/docker along with all of the other dependencies.
A couple of other alternatives:

the API client does not expose any of the vendored types directly.
the docker/docker project uses a tool like glide and does not actually store the vendor directory in the git repository, but installs them at build time.

For what its worth, I am using glide for dependencies, but that doesn't resolve the issue by itself, just makes for more interesting error messages. I've now added:
glide install --strip-vendor

As part of my 'dependencies' make target. But it just feels a little dirty. Works for now though.

Also, see https://groups.google.com/forum/#!msg/golang-nuts/AnMr9NL6dtc/UnyUUKcMCAAJ

Well then... time to wrap everything in exec commands?

Well then... wow.

Any movement on this? It's still in a pretty nasty state :(
I went to use a project I wrote back a year or two ago, to find something was busted between the N docker repos + the various vendor dirs in each of them.
Example:
cannot use index (type *"github.com/docker/docker/api/types/registry".IndexInfo) as type *"github.com/docker/cli/vendor/github.com/docker/docker/api/types/registry".IndexInfo in argument to command.ResolveAuthConfig

I think I worked around my issues for now, by going:
cd GOPATH/src/github.com/docker
rm -rf docker/vendor
rm -rf cli/vendor
rm -rf distribution/vendor

And then ensured my version of cobra/spf13 + cobra/pflag were up to date. Not elegant, but technically works around my issues.

This totally breaks depending on docker/docker from Bazel build files (need to fork each and every docker repository and remove the vendor directories, and rebase to keep in sync), since https://github.com/bazelbuild/bazel-gazelle cannot ignore vendor directories for dependencies. Are there any plans to remove the vendor directory (especially in the light of Go modules)?

I am currently also stuck with this. It's very frustrating trying to get it to work with vendoring in a Pipeline

Any update on this ?

@SweeXordious You can take a look at this comment from @thaJeztah, he explains what procedure should be followed to get it work with go mod :wink:

This issue was related to the original change to switch to use vendor/ as the path for vendoring, which is the standard path for vendored dependencies. The solution for that is to use a vendoring tool that strips nested dependencies (or to configure the tool you're using to do so).
Unfortunately, using go modules with this repository is still difficult (and complicated to resolve). There are some newer issues that discuss this, and which are more current. Let me close this one in favour of those, and link to some comments on those that may be helpful https://github.com/moby/moby/issues/39056 (https://github.com/moby/moby/issues/39056#issuecomment-633575517) and  https://github.com/moby/moby/issues/39302 (https://github.com/moby/moby/issues/39302#issuecomment-635253855)


Cannot integrate ui5 service with wdio

Hi,
I've been trying to use the ui5 service as :
services: ['chromedriver', 'ui5']
But while running the tests I am running into the following error :
Error: Failed to initilialise launcher service unknown: Error: Couldn't initialise "wdio-ui5-service".
Error: Cannot find module '/Users/I584814/Diya/bp-validation/cloud-extension-s4hana-business-process/app/BusinessPartners/node_modules/webdriverio/build/multiremote/index.js'
Please do advice on how this could be resolved.

Hi @diya-dhan, can you please provide more information about your environment and used versions.

Hey @dominikfeininger ,
So these are dependencies I am using.
"@sap/ui5-builder-webide-extension": "1.0.x",
"@ui5/cli": "1.13.0",
"@wdio/cli": "8.8.2",
"@wdio/local-runner": "8.8.2",
"@wdio/mocha-framework": "8.8.0",
"@wdio/spec-reporter": "8.8.0",
"chromedriver": "112.0.0",
"ui5-task-zipper": "^0.3.1",
"wdio-chromedriver-service": "8.1.1",
"wdio-ui5-service": "1.3.2"
Additionally the node version is v18.14.0 and npm version is 9.6.2.

the culprit is wdio^8 - as of now, wdi5 is compatible with wdio^7 only. so please downgrade webdriverio to v7 and you should be good to go!
ps: we're currently working on the wdio^8 enablement!

Hey @vobu ,
So I did downgrade the version like suggested. Here are the current package versions.
"devDependencies": {
"@sap/ui5-builder-webide-extension": "1.0.x",
"@ui5/cli": "1.13.0",
"@wdio/cli": "7.31.1",
"@wdio/local-runner": "7.31.1",
"@wdio/mocha-framework": "7.30.2",
"@wdio/spec-reporter": "7.31.1",
"chromedriver": "112.0.0",
"ui5-task-zipper": "^0.3.1",
"wdio-chromedriver-service": "8.1.1",
"wdio-ui5-service": "1.3.2",
"wdio-wait-for": "3.0.3"
}
But I am still running into a similar error.
ERROR @wdio/utils:initialiseServices: Error: Couldn't initialise "wdio-ui5-service".
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './build/multiremote' is not defined by "exports" in /Users/I584814/Diya/bp-validation/cloud-extension-s4hana-business-process/app/BusinessPartners/node_modules/webdriverio/package.json

wdio-chromedriver-service is still at 8.x
you might also try removing node_modules entirely and doing npm i again

ah yess. changed it now and all is fine. Thank you very much for your help!

excellent 👍👍👍


chore: Drop unused files from aws/karpenter-provider-aws repo

Fixes #N/A
Description
This drops the following sets of files from the repo:

Publish Test Tools Workflow - This workflow was used for pushing an updated docker image when we were using Tekton for our E2E testing. We have since dropped support for Tekton; so, we can remove these files from the repo
Provisioner Examples - These examples should have been dropped at the v1alpha5 migration on v0.33.x. These examples still exist on older tagged versions of the repo but shouldn't exist on the latest version
Sync Cluster - These scripts were artifacts of the old SQS-based Tekton workflows. These have since been replaced
Dockerfile and push-docker.sh - This script was used in the Publish Test Tools workflow that was mentioned earlier for pushing newer versions of the testing image up to our test ECR for Tekton.

How was this change tested?
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 82.489%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4918

Relevant Lines:
5962

💛  - Coveralls


Update windows-defender-advanced-threat-protection.md

Jody Cedola from Intune engineering confirms WD ATP can also be onboarded using Microsoft Intune. I revised references that say only SCCM can do it.

Looks good @Justinha, thanks for your contribution! :)


Summer student from Pinello Lab at Harvard seeking help from Theis Lab

Hi, my name is Rebecca Combs. I am a student at Winsor High School in Boston. I'm fascinated by scRNA-seq data analysis. I have run into a glitch. I'm unable to complete the Nestrorowa et al. 2016 paga tutorial. On ln[3] I keep getting this:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-4-bfa4168a87e6> in <module>
      1 adata.raw = adata
----> 2 sc.pp.recipe_weinreb17(adata, log=False)
      3 sc.tl.pca(adata)

/opt/anaconda3/lib/python3.7/site-packages/scanpy/preprocessing/_recipes.py in recipe_weinreb17(adata, log, mean_threshold, cv_threshold, n_pcs, svd_solver, random_state, copy)
     48     )
     49     adata._inplace_subset_var(gene_subset)  # this modifies the object itself
---> 50     X_pca = pp.pca(
     51         pp.zscore_deprecated(adata.X),
     52         n_comps=n_pcs,

AttributeError: module 'scanpy.preprocessing._simple' has no attribute 'pca'

I assume that this has been solved after more than a year. Feel free to reopen if required.


Fix bugs with highlighting and searcher

Fixed some bugs from very rare errors

Just curious, what were the errors?
Also, should we change the try/except to catch only this tokenization error? I'm afraid it might silently fail for other errors

Just curious, what were the errors?
Also, should we change the try/except to catch only this tokenization error? I'm afraid it might silently fail for other errors

The error with the searcher is if the query has a not in the latin encoding like any letters with accents, caused Pyserini to throw an error occasionally

For highlighting, because we cut off the max number of paragraphs to highlight, for the very last article, the first paragraph may have been highlighted but not the second one. Then we end up with the length of highlights == 1 which does not match the length of paragraphs

And yeah I agree I will add a specific exception

We had similar/related issues in Pyserini - check out: https://github.com/castorini/pyserini/issues?q=encode
tl;dr - is to use text.encode('utf-8') explicitly.

We had similar/related issues in Pyserini - check out: https://github.com/castorini/pyserini/issues?q=encode
tl;dr - is to use text.encode('utf-8') explicitly.

Should I make a PR in Pyserini? The searcher doesn't encode the query
https://github.com/castorini/pyserini/blob/master/pyserini/search/pysearch.py#L78

Ah, yes, that's an oversight on our part. Yes please. Can you also include a test case that makes sure this is fixed?


[Progress] indicating jeopardy colors change

I want to use the indicating property of the progress component, the problem that it didn't pass review cause it starts with RED and red indicates errors...
I just wanted to ask if it's possible (by css or other hack) to have the colors gradient with one color only? I mean to start with light green and as it progress on it will become darker?

Any update please...


Help and configuring YOLO correctly ?

Hi,
I have some questions about YOLO configuration for my AI problem.
To resume :

2 classes to detect in my dataset, A with 4500 features and B with 1900 features.
A shapes are generaly big and B shapes smaller (depends of the picture).
Original pictures are 6000x4000px.

Configuration:

2 GPU.
batch_size=16.
epochs=1000
size: 416x416

After multiple training trials :

losses are stuck :  loss ~29 ; val_loss ~31

Evaluation :

mAP is really bad ~ < 1

Some questions :

Do i need to calculate my own dataset anchors ? If yes, is it compatible with my original size 6000px*4000px ?
Is there a relation between anchors and 416x416 size ?
Do i need to increase 416x416 size ?
Why my loss / val_loss not decreasing more ?
What do you suggest more ?

Thank you in advance !

Are your classes very different from the COCO classes? When you say original size do you mean you cut the parts of interest out of the large image, or did you rescale the image, or you are passing that whole image to the system? I am assuming you are not passing the whole image since that would take a long time to train. Also are the images very similar meaning the same object in the same place at maybe a slight change in direction, distance, etc? Otherwise, everything looks like your doing it right.


Pyarrow dev

This PR tries to follow minimal implementation to ingest a parquet file using PyArrow.
This is achieved by reading a Parquet file using PyArrow, batching it into RecordBatches before ingesting it with the existing code.
my_file.parquet → PyArrow Table → RecordBatches → Dataframe → FeatureRows (existing code) → Stream
Other modifications:

Standardised docstring format to use reStructuredText with typing.

Added generator function to encode chunks of DataFrame into a chunked list FeatureRow objects.

Generator function to encode chunks of PyArrow table of type RecordBatch into a chunked list of FeatureRow objects.

Thanks @voonhous
I have two comments

Can you please submit all of the formatting and other changes separately? It makes it incredibly difficult to review your code if you submit 700+ lines of code difference.
I cant think of a good reason to wrap ingest with ingest_file. It seems like ingest has steps that both it and ingest_file should share, like validating the dataframe, getting the feature set, and inferring/applying the schema from the dataframe. These should not be rerun for every batch.

I think it would make more sense if you extended the existing ingest so that it took either a dataframe, path, or file-like object. You would then handle it just like in ingest_file. At the infer_schema step, a single batch can be materialized into a DF for creating the schema. Then the rest of the table is passed into ingest_kafka where all iteration can happen.
What do you think?

Also, would you mind updating the title of the PR to something more descriptive? We use the PRs as items in our change logs.

/retest

/test test-core-and-ingestion
Trying to figure out if the integration test in feast-ingestion is flaky i.e. the test can fail with the same test configuration, specifically this test feast.ingestion.ImportJobTest

I have created this code snippet which creates a testing dataframe. It has all the types besides lists of boolean. I think we should ensure that we can ingest this as both a parquet and a pandas dataframe.
https://gist.github.com/woop/d074ded542bc2b6ec5a0b5a96c72e9ab

/retest

/retest

/retest

/lgtm
/approve


Add toml themes

I used babelfish yaml2toml to convert it. https://github.com/pickfire/babelfish

The latest Alacritty version has a built-in command to convert configurations. So it should work with just Alacritty itself.


Azure functions core tools

Motivation for this change
Add Azure functions core tools to set up local Azure functions development environment using Nix.
Things done

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

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

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

Please change the branch to master.

Should I also rebase on it?

Yes.

yes please!

Is there still something that needs to be done?

sorry it needs a rebase again. please ping me when it's done so I can review and merge right after

@zimbatm I rebased it on master. Hope it's all right now.

thanks!


Crop RSTP stream possible?

I have successfully replaced the camera´s lens for a FishEye.
I'm sending the stream to Frigate, but effective image size covers a smaller portion of the sensor.
I was wondering if I could improve quality and performance of both the camera and Frigate by processing a smaller image.
Example image (In yellow the area I'd like to crop):

Sorry but it's not possible.
I can't change stream processing, it's handled by Yi processes.

Thank you for your reply! closing issue.


Integration with google/oss-fuzz

Hey David, first of all, thanks for all your hard work on this project ❤I'd like to help with ensuring that this package reliable and secure. Some of your other projects have already been integrated with oss-fuzz. Do you have plans to integrate this project with oss-fuzz? If not I'd happily champion the integration effort :)

See https://github.com/google/oss-fuzz/pull/5328.


DCOS-55890 fix lingui templates

Replaced usages of i18nMark(``)  with i18nMark(""), i18nMark does not support string templates and these strings we're not being extracted.
Translated strings for ToastNotification manually in the ServicesContainer, the ToastNotification extension for the notification service does not handle any translation, so any text strings sent to it must be translated beforehand. I updated the ServicesContainer to get the lingui i18n object from the container and translate the strings manually.
Testing

Verify strings are extracted now.
Test toast notications for delayed start?

Trade-offs
I add the i18nTranslate helper function to the ServicesContainer so that tests wouldn't need i18n to exist in the container.
Dependencies

Screenshots

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


fs.readdir withFileTypes:true returns useless fs.Dirent objects

while llrt recognizes the withFileTypes:true option of fs.readdir calls,
the returned objects are quite useless.
in node and bun, you receive some objects that let you determine the type (directory or file).
llrt just provides the name of the entry.
it would be nice if at least the type of the node would be provided.

This is already implemented, see:
https://github.com/awslabs/llrt/blob/7b6252bace1026bbbe4e5e1385cd1399d225ff95/tests/fs.test.ts#L16
what issues are you facing?

hello Richard,
thanks for your fast reply.
you are right, the returned objects provide an isFile method.
i was testing it with isDirectory instead of isFile, probably because it is listed higher in the documentation of node's fs.Dirent.
maybe providing isDirectory as well would be nice?
anyways, the issue is not really an issue, so i am closing it.


Extract cell_selector method in scaffold index view spec generator

Basically same change as described in https://github.com/rspec/rspec-rails/pull/2619 - re-attempting only because of last comment - https://github.com/rspec/rspec-rails/pull/2619#issuecomment-1250240003 - which seemed to indicate a desire to get the logic into the generator and out of the generated spec file.
I read the linked discussion and it wasn't totally clear to me which portions involved people talking slightly past each other (about CI vs developer env) and which were genuine issues (that I may have not resolved here, if they exist?) so apologies if that's the case, and I can close and/or attempt to resolve. From my current understanding this does seem safe -- in CI environments or dev environments for working on rspec-rails itself, you'd presumably either have a fresh/clean run and/or clobber first and it should be ok; and for local rails-app development, if you had a prior-version generated spec+view they'd work in conjunction with each other, and this would continue to be true if you switched versions and started generating new ones, I think?
I agree with one of the comments in the linked discussion about how you would likely change this value pretty early on, but also that having the rails version conditional in the generated spec is slightly confusing when you first see it.

Thank you, @mjankowski !

Released in 6.1.4


update dependencies, implement mark-feed-as-read in javascript

I took care of the picofeed commit "Use DateTime object instead of timestamps for feed/item dates". As far as I can see, it is used only one time.

Thanks, it's merged.


Remove the Following Sources

Source name
MangaNelo
Source language
English
Source link
https://manganelo.biz/
Other details
There are 3 ext with same name but all 3 are down!
Manganelo.biz
Manganelo.website
Manganelos.com

Acknowledgements

[X] I have updated all installed extensions.
[X] I have opened WebView and checked that the source website is down.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] I will fill out all of the requested information in this form.

actually just a url change
new url is https://m.manganelo.com

actually just a url change
new url is https://m.manganelo.com

ERM... Manganelo is not related with mentioned sources, just for you to know...


event can't be added to the app

Describe the bug

To Reproduce
<Steps to reproduce the behavior:

Go to 'app'

Click on the app and enter the email id<EMAIL_ADDRESS>and password "fossasia"'

See error  error 401 unauthorized>

Expected behavior
< It should log in
into the app>
Logs

Screenshots
<whatsapp image 2019-02-19 at 1 30 49 pm >
Smartphone Info:

Device
Redmi 5A

Android Version
Oreo

Would you like to work on the issue?

[ ] Yes

@sushmita0810 Probably the credentials are changed. Are you able to signup to create a new account ?

yes!! I am able to signup.
I would like to work more on this project.
I was not able to add any event to the app, i.e it is not going to step 2.

@sushmita0810 To work on an issue, comment on existing issues or open a new issue (bug or feature).

I was not able to add any event to the app, i.e it is not going to step 2.

What're the logs?

While adding the event , nothing happens when I click o nCREATE button  and a toast pops up saying Event Name cannot be empty but I had already written the name in first step1.
here is the screenshot:
step1:

step2:

step 3:

@sushmita0810 This seems like a valid bug. You can start working on it to fix it. Also, while creating the issue paste the logs that are shown in Android Studio.

@sushmita0810 Please change the bug title and description accordingly

ok

@sushmita0810 Are you working on this?

Has this issue been fixed or still under some discussion ?


Should icon reflect current state or action?

Testing #131196
The locked icon is shown unlocked currently when the current group is locked. I am always confused by whether an icon shows the current status or the status after clicking the button (i.e. the action to take). This is because we are not consistent. It seems we tend to favor action over the status but there are exceptions.
SCM: Show as Tree/List
Shows the action, not the current state

Search: Collapse/Expand All
Shows the action, not the current state
Explorer: Filter
Shows the current state, not the action

Timeline: Pinned
Shows the current state, not the action

GitLens Remotes: Show as Tree/List
Shows the current state, not the action

GitLens Search Commits: Keep Results
Shows the current state, not the action

Can we establish some guideline here? Maybe cool for the editor lock would be showing as locked until hover indicating that click would unlock the group.

Good catch, I tend to just flip the icon to show the lock because we do the same for pinned tabs:

//cc @misolori for the general UX guidance


Perfetto can load gz files but not zip.

The standard compress on macOS generates a zip file.   Would be nice to be able to drop these onto Perfetto.

I think we're @carlscabgro is working on adding zip file support for an unrelated reason so this might be solved as a result of that

This should now be fixed.

Doesn't seem to work yet, but maybe this isn't in the current release.  I dropped a zip that I compressed on macOS, and ui.perfetto.dev didn't open any tracks.  Can still open with my kram-profile app.

Currently only rolled out to autopush.


[nx-pulumi] - nx-pulumi:restore-config command now restores file contents as an object

Hello,
Thanks once again for maintaining this plugin! Using the latest version trying to restore my config, i get only [object Object] in my newly created yaml file.
I believe it is related to the below when the s3 dependency was swapped over:
https://github.com/aws/aws-sdk-js-v3/issues/1877
Not sure if this affects anything else in the repo.
Cheers!

Hey @Hemesh-Unka thanks for the link to that thread. How annoying.
I'm releasing https://github.com/sevenwestmedia-labs/nx-plugins/pull/85 now which should fix the issue. Let me know.


chore: update features.json

Updates the features.json file with the latest AC codes added for the features required for October.

Looks OK from my perspective - I'll leave the AC checking to more qualified people


Snippet suggestions

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.75.0

While typing 'log' it used to suggest this:

But after the update it is no longer suggesting 'log' snippet:

It's same with various other snippets.

seems the same with many (all?) languages - no default snippets

same here with php tag, if i type "p" its show usersnipped butif i type "php" it dont show

same here, typescript user snippers doesn't work anymore with VSCode 1.75.0

Same here, if I trigger suggestions (ctrl+space) before typing a snippet works fine

+1

Same here, snippets don't work anymore in JS

In my case, snippets works correctly in JS, but don't work in JSX files.

It's someway inconsistent to me:

I'm getting the exact same issue when my emmet settings are set for javascript: javascriptreact and/or typescript: typescriptreact

When I remove the emmet mapping, it works fine, BUT of course I lose emmet support.
I've just had to go back to the previous version for now.

I have the same problem  I feel uncomfortable and it's a bit frustrating not being able to use custom snippets and extensions. Does anyone have a temporary solution until the error is fixed :/?

/duplicate of #173244

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!

I have the same problem I feel uncomfortable and it's a bit frustrating not being able to use custom snippets and extensions. Does anyone have a temporary solution until the error is fixed :/?

You can do what I did and downgrade to the previous version until a fix is available.


Avoid the SemVer v0.x.x anti-pattern

[x] This only affects the JavaScript OpenTelemetry library
[ ] This may affect other libraries, but I would like to get opinions here first

It's an anti pattern to publish any package, for any reason, with a SemVer 0.x.x version. This is because according to SemVer v0.x.x releases are considered major breaking change releases until v1.x.x, so tooling like npm loses the ability to accept semver minor changes in dependencies with a version range specified with ^.
There are only 2 "upsides" to v0.x.x:

The package author doesn't have to think about or declare if changes are major and breaking or minor and non-breaking. They can just throw a soup of changes out into the wild. This is really truly awful for anyone depending on your package to deal with though, so I don't consider this an "upside" for the ecosystem. Any time something is published, the package author should be carefully considering and what changes are breaking, and should reflect if there are breaking changes or not in a SemVer major increment, and should document those changes in the changelog and release notes so consumers can decide when and how to adopt the new version.
Users can look at the major version number, see it's 0, and have an expectation that the package is experimental. This is a completely worthless "upside" because while this is an extra signal in the version, the user has lost a far more important signal about if there are minor or major changes. Also, users can't trust the stability signal because there have been packages that reached stability a decade ago and are still on v0.x.x, and there are packages with a high major version number that are unstable nightmares riddled with hundreds of bugs. The package readme is the correct place to alert users if a package is experimental or stable.

In my work Node.js project right now, here is the result of running npm ls @opentelemetry/instrumentation:
@[redacted]@ /[redacted]
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
└──<EMAIL_ADDRESS>
Note that there are 2 versions of @opentelemetry/instrumentation installed; v0.41.2 and v0.49.1. This is through no fault of my own, or even really @azure/opentelemetry-instrumentation-azure-sdk installing the very old one. The fault is the v0.x.x of @opentelemetry/instrumentation preventing the declared dependency rage of ^0.49.1 from being able to pull in any releases with only minor changes:
https://github.com/Azure/azure-sdk-for-js/blob/c6b79e3f1bfd106825ba1e99bbab192eaeea146f/sdk/instrumentation/opentelemetry-instrumentation-azure-sdk/package.json#L75
It's unreasonable to expect the @azure/opentelemetry-instrumentation-azure-sdk package maintainers to subscribe to alerts every time a @opentelemetry/instrumentation v0.x is published (how can they even really do that? It's a mono repo so subscribing in GitHub to releases would spam them with releases of other packages) and manually cut a new release adjusting their @opentelemetry/instrumentation dependency up a 0.x increment.
Now as a consumer, I'm in the awkward position of having to remind (beg) third party packages to bump their v0.x dependency versions, or try to set some sort of package.json resolution overrides to force deduplication to one particular v0.x version. But because there is no signal in v0.x version numbers if there are breaking changes or only minor changes, you have to try to sift through mono repo release notes interspersed with other package release notes and if you can't find them or they aren't detailed enough to tell if updating is safe; reverse engineer the commits or code in each release to try to figure it out manually yourself if there are breaking change. But, let's say you realize there were breaking changes in the release. Is it safe to update? Maybe you have knowledge enough about your own project code to know that, but now you have to have expert knowledge of all the third party dependencies using it also to be able to know it's safe to force the package resolutions to the newer version for all node_modules.
Please, just never use v0.x.x. Just go straight to v1 and go from there. Can you please move all @opentelemetry packages to at least v1? Thanks.

We're fully aware of all the problems releasing 0.x versions of our packages brings, especially in situations as outlined in your issue above. However, all packages that we publish at 0.x are published as such for a reason: there is no guarantee for API stability.
This is often due to a multitude of reasons. Sometimes the underlying specification is not yet stable. Sometimes the semantic conventions are not yet stable. Most of time, the package is simply still under development.
There is also a specified expectation that old major versions of the SDK components will be maintained for a minimum of 1 year after the following major version is released. So quickly releasing new major versions will, within just a few times of doing so, render us absolutely unable to make any changes as the burden of maintaining bugfix backports will be so large that we will not be able to act on anything else anymore.
Our current plan is to resolve this is to

drive the @opentelemetry/exporter* packages to a 1.x stable release
follow with integrating the @opentelemetry/api-logs package into @opentelemetry/api, effectively stabilizing it

release the @opentelemetry/sdk-logs package as 1.x
release the @opentelemetry/instrumentation package as 1.x

At this point then we'll be able to release all instrumentation packages in the @opentelemetry namespace as stable that have stable semantic conventions. Until then we need to maintain the ability to break the public API as we see fit, which, considering the constraints I mentioned above is handled by releasing packages as semver 0.x.

Can you please move all @opentelemetry packages to at least v1? Thanks.

We will, in time.

It's an anti pattern to publish any package, for any reason, with a SemVer 0.x.x version.

No, SemVer says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

The experimental packages are 0.y.z, the experimental ones are not.

@pichlermarc

There is also a specified expectation that old major versions of the SDK components will be maintained for a minimum of 1 year after the following major version is released. So quickly releasing new major versions will, within just a few times of doing so, render us absolutely unable to make any changes as the burden of maintaining bugfix backports will be so large that we will not be able to act on anything else anymore.

Supporting npm package major versions for a minimum of 1 year is a truly terrible policy that is divorced from the technical realities of maintaining JavaScript software. How JavaScript and npm packages work is immutable, it's the policy that needs to change. Sometimes a critical bug or security flaw can only be fixed in a semver major release. It will lead to having to support Node.js version that are EOL. It's a bad idea to set expectations to users that they don't need to update their JavaScript dependencies for a long time; as a subject matter expert who authors and maintains packages that get hundreds of millions of installs, building up a huge list of breaking changes in infrequent major releases is a way worse strategy than releasing breaking changes as they come up and allowing users to make smaller migrations over time. You make breaking changes because it makes the software better; by creating a culture of "saving them up" for the delayed next major version, you end up denying the user base the benefits of those changes for a long time. It stunts progress. It becomes much harder to coordinate PRs and maintain vision and velocity when you are juggling a bunch of unreleased changes sitting around in PR branches that can conflict as time goes on.
If you absolutely must have a concept of long term supported major versions, a better approach would be to have a list of particular major versions that you designate as LTS. Don't make every major version LTS. Even Node.js doesn't do that.
@pauldraper You can conform to specs and still commit anti-patterns. Just because you have the ability to publish 0.x releases doesn't mean you should. Nothing in the spec prevents you from publishing v1.0.0 as your first public release:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

— https://semver.org/#spec-item-4
If you have a public API, as in you are expecting anyone to be using the package at all (otherwise why publish to the public npm package registry?), then you should be publishing at least v1.0.0. There is no spec wording to the effect of "Version 1.0.0 means that everything is mature and stable and there will not be any more breaking API changes". The whole point of SemVer is to deal with breaking changes over time. It's expected for there to be a v2, v3, v4 etc. over time.
Saying "these packages are experimental, so we won't use semver major versions deal with it" is ignoring the reality that you have an ecosystem using these packages. Pretending there is no public API or consumers isn't helping the ecosystem. React was v0.x for years and years before they realised how stupid it was given half the world was using it and they admitted they were wrong and published their first major version at v15.0.0.

@jaydenseric I don't necessarily disagree.
For instance: @opentelemetry/instrumentation not being stable is a problem that we're affected by ourselves as well as we also deal with that in https://github.com/open-telemetry/opentelemetry-js-contrib. However, there are some other parts of the project that we'll need to stabilize first to be able to mark that package as stable.
We've not been very transparent with our plans to stabilize packages in the past and we'll try to do better in the future. We're committed to eventually releasing our packages as 1.x. To start, I've started to document parts of the process towards releasing more packages of this repository as 1.x and actions that we need to take to get there (some of them are still incomplete, but I'll continue to refine them in the next few days: #4586, #4582, #4585, Logs API stabilization issue currently pending).
We've also already started considering a 2.0 release, and we are also considering increasing the frequency of major releases in the future. As you've seen in the spec document I linked earlier, this will likely also require us to drive changes in the specification.
We understand that these issues affect people right now, but all these changes are not something that we'll be able to make immediately, it will rather be a gradual process.

as in you are expecting anyone to be using the package at all

This package is experimental. As in, you can experiment with it, provide feedback, etc.
I'm having trouble deciphering your complaint.

0.x.y is the inappropriate version. No, this is a non-stable package, and per SemVer any non-stable package should be 0.x.y.
It should be stable. Brilliant suggestion.

@pauldraper

I'm having trouble deciphering what the complaint is

I have extremely well explained the issue, and reasoned a better approach, to the point that it's hard to interpret your mischaracterizations of it as being in good faith.

0.x.y is the inappropriate version. No, this is a non-stable package, and per SemVer any non-stable package should be 0.x.y.

As I have explained, SemVer allows people to publish 0.x versions, but it doesn't require you to. Due to the many problems I have already explained that 0.x releases cause, they should never be used for any reason.

It should be stable. Brilliant suggestion.

I'm not asking for any sort of code stability or changes, only to change the version numbers. Publish a v1, v2, v3 as fast as you like! The faster the iteration the better. I don't expect v1 to be "stable". I do however expect breaking changes to be documented in the SemVer major version numbers and in the changelog / GitHub release notes. Early in a project when frequently lots of breaking changes are happening, that's the most critical time to make it easy for consumers to understand the differences and manage their dependency updates. Right now, with 0.x releases, you are making it the hardest for people to understand at the time in the project it matters the most.

0.x.y packages should not be published to npm. This convenient for trial uses. You're welcome to ignore them.

This has nothing to do with anything I have said. Publish something experimental, but as v1 and not v0.1.
If you publish something to npm, it means you intend for other packages to install it. At this point, an ecosystem has already adopted OpenTelemetry JS so telling users like me that are required to use it for work to just go away, stop using this software (or the rest of the ecosystem that uses it), and to disregard my contributions of expert advice, is unwarranted hostility. I'm not some random novice spewing uninformed advice; I'm an npm package author and ecosystem expert with over a billion installs under my belt. I specialize in optimal module design and optimizing npm package dependency graphs.
@pichlermarc thanks for your comment :) It's good to have some insight into the challenges and where things are headed. That policy about major versions being supported for a year is a nightmare; I would just change the policy ASAP (assuming it's not legally binding, it's published under the Apache license which explicitly waivers liability or warranty) before too many people adopt this dependency under that expectation, and cop the flak from anyone that complains. Chances are no-one will care at this early stage. If the policy for some reason can't be amended, then I would suggest archiving this package and republishing under a new name with a fresh (no) policy. Only a commitment to adhere to SemVer, which is implied anyway when publishing to npm.

What is the benefit in releasing new major versions frequently instead of new 0.x versions?
People usually use something like ^13.0.0 so new majors are not picked up similar as new minors are not picked up in the 0.x range. As a result the main pain remains.
What would be lost is to move into what is named stable here which comes along with a stability guarantees for some time.
Well, we could decide that every 10th major version is an LTS version or so.

@Flarna imagine hypothetically you are publishing an update to a package foo that is currently v0.1.0, that only includes 3 minor new features and no breaking changes. You publish that as v0.2.0. Now all projects that have a dependency foo: "^0.1.0" won't automatically install the v0.2.0 newer version, because tooling considers a 0.x release a major change.
So now, as a user, you see when you run npm outdated in your project that there is a foo update available from 0.1.0 -> 0.2.0, you wonder, are there any breaking changes in that? Is it safe to update? You have to google the repo for that dependency, and click around in GitHub releases, see it's a mono-repo with all sorts of mingled releases, so you try clicking through the mono-repo directories to look for the changelog for just that specific package, to try to see if the last 0.2.0 release of foo has anything breaking in it. Finally you find out that it only contains new features and no breaking changes, so you bump in your project package.json the dependency foo to ^0.2.0.
But, unbeknownst to you, several other dependencies in your project's dependency graph also depend on the package foo, and they are depending on ^0.1.0 still. So now you get in your node_modules both the 0.1.0 installed by dependencies, and 0.2.0 installed directly by your project. Having multiple versions of the same thing installed in the same project can cause all sorts of problems beyond a bloated hard drive. It can bloat bundles in browsers with multiple versions of the same thing, it can cause instanceof checks to fail because a class instance is being constructed from one version and is being compared against the class from another. Module singletons can stop working properly.

Now, consider an alternative reality where foo was v1.0.0, and you published a new v1.1.0 containing only minor changes. Literally no-one had to do anything at all, next time npm install happens your project and it's dependencies that have a "foo": "^1.0.0" dependency will pull in the updated version.
When it comes time to publish a breaking change, people will see foo is now v2.0.0 and can tell just by looking at it that it's not safe to install without looking up the breaking changes are.

ok so your assumption is that no breaking changes happen usually.
The 0.x range supports this by incrementing patch and patterns like ^0.x would work.
As we are on 0.50.x now either the judgment of breaking/non breaking was incorrect in the past or we would be on major version 50 now.
I assume the combined release/versioning of all modules here has also quite an impact. A breaking change in one experimental module results in minor (or in your proposal major) of all modules.
Independent version numbering would likely require some sort of compatibility table.

The 0.x range supports this by incrementing patch and patterns like ^0.x would work.

No, the semver spec makes 0.x versions special, in that breaking changes are allowed to be published in 0.x versions. So tools like npm etc. will not install v0.2.0 if your dependency range is declared as ^0.1.0. Neither humans or tools can tell if there are breaking changes or not just by looking at a SemVer of 0.x.
If you really published 50 versions that had breaking changes, then it's perfectly reasonable to be at v50.0.0 at this time.

I assume the combined release/versioning of all modules here has also quite an impact. A breaking change in one experimental module results in minor (or in your proposal major) of all modules.
Independent version numbering would likely require some sort of compatibility table.

You are not independently publishing versions for each package? That's a big anti pattern. A package's SemVer should reflect what changes have happened in that specific package, not what has happened elsewhere in other packages. Mono-repo tooling allows independently versioning packages. Popular projects have switched in the past from a shared version to individual versioning because it's simply better for the ecosystem. Publishing new versions for things where nothing has changed in them is hugely disruptive. It creates large diffs in package dependencies and lock files, it causes duplication and bloat in node_modules, it creates more work for tools that audit or analyse package versions, it spams people's attention when they run npm outdated and they see 5 things have a new version available (but actually none have even changed, because a package in the same mono-repo you aren't even installing has a change). It causes dependabot noise in peoples repos, It makes it hard to tell if it's safe to update your dependency that has a new major version available, because maybe that major version increment might only be because of a major change that happened in a different package not installed in your project that happens to be maintained in the same monorepo.

No, the semver spec makes 0.x versions special, in that breaking changes are allowed to be published in 0.x versions. So tools like npm etc. will not install v0.2.0 if your dependency range is declared as ^0.1.0. Neither humans or tools can tell if there are breaking changes or not just by looking at a SemVer of 0.x.

Seems you misunderstood me. Non breaking changes in the 0.x range should not result in minor updates, only patch. So your pattern ^0.1.0 would pick up the 0.1.1, 0.1.2, 0.1.3,... releases.
My feeling is OTel JS at a whole is in a too early stage for you. You expect a sort of stability which is simply not yet reached - at least not in all parts you would like to use. Just changing the numbering doesn't change the reality.
Work is ongoing in the right direction. There is a lot work to do but the number of people actually picking up the work is limited.


Add additional Embrava vendor ID

Hey,
I'm trying to use my (probably older) light with this project.  It works in the previous, depreciated blynclight repo and looking at embrava/blynclight.py the vendor id for my light doesn't show up in the list.  Output from my pi below:
pi@nightlight:~ $ busylight on
Light '0' not in the range of 0..-1
pi@nightlight:~ $ dmesg | tail
[ 7218.521658] Voltage normalised (0x00000000)
[ 9518.695285] usb 1-1.2: USB disconnect, device number 4
[17252.456676] usb 1-1.3: USB disconnect, device number 6
[17254.285218] usb 1-1.3: new low-speed USB device number 7 using dwc_otg
[17254.429614] usb 1-1.3: New USB device found, idVendor=0e53, idProduct=2516, bcdDevice= 1.00
[17254.429637] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[17254.429652] usb 1-1.3: Product: Blynclight
[17254.436605] hid-generic 0003:0E53:2516.000A: hiddev96,hidraw0: USB HID v1.10 Device [Blynclight] on usb-3f980000.usb-1.3/input0

TIL: you can transfer issues between repos!
Transferred this issue from the blynclight repo to this repo, just because I've never had to do that before.

Fixed with commit a468d6a84f19261fc4d656d0082d852fc3ab090b and should be available on pypi with version 0.12.10:
$ python3 -m pip install -U busylight-for-humans

Awesome!  Looks like this change fixed it, I haven't rebooted yet but it was able to control the light as sudo.

You shouldn't need to reboot to use the light, look at the udev-rules sub-command of the busylight CLI. There is more info in the README.md that talks about how to enable USB devices for non-root users when using Linux.  I'm going to close this issue since the light is now recognized.

Sounds good.  I've gone through the udev-rules post install steps, I had to append the new device id to the *.rules file but no dice after reloading and/or rebooting.  Running as a regular user gives the "Light 0 not in range..." message.  Running as sudo works to control the light.
I haven't looked into it more, it could be some weirdness with running raspbian and once I have some more time I was going to test it with ubuntu server and see if it had the same behavior.


Dashboard Pane: label crashes when the subject is not  a NamedNode

Console log
Uncaught (in promise) TypeError: subject.site is not a function
    at Object.label (mashlib.js:62753)
    at mashlib.js:65309
    at Array.filter (<anonymous>)
    at _callee6$ (mashlib.js:65308)
    at tryCatch (mashlib.js:120589)
    at Generator.invoke [as _invoke] (mashlib.js:120815)
    at Generator.prototype.<computed> [as next] (mashlib.js:120641)
    at asyncGeneratorStep (mashlib.js:64629)
    at _next (mashlib.js:64651)
    at mashlib.js:64658

eg when subject is https://webschemas.org/SpecialAnnouncement
in the code:
  name: 'dashboard',
  label: function label(subject) {
    if (subject.uri === subject.site().uri) {
      return 'Dashboard';
    }

eg you expand the URI field in internals pan, then the subject is a literal?  In principle could be blane node I guess too.


Azure FineUploader Issue :: 405 The resource doesn't support specified Http Verb.

Type of issue

[ ] Bug report

Uploader type

[ ] Azure

Note: Support requests cannot be accepted due to lack of time.

Bug Report
Fine Uploader version
{5.15.0}
Browsers where the bug is reproducible
{"Firefox" and "Chrome"}
Operating systems where the bug is reproducible
{ "Windows 10"}
Exact steps required to reproduce the issue

Select 1 file to upload it to Azure Container.
Attempt to upload the selected file.

All relevant Fine Uploader-related code that you have written
We have used azure.fine-uploader.min.js
This is how we tried to instantiate Azure uploader:
var uploader;
uploader = new qq.azure.FineUploader({
element: this.rugbyFineUploaderSettings.uploaderElement,
debug: true,
autoUpload: false,
request: {
endpoint: 'https://MyAccountName.blob.core.windows.net/MyContainerName/',
},
cors: {
expected: true,
sendCredentials: true
},
signature: {
endpoint: "https://MyAccountName.blob.core.windows.net/MyContainerName/rugby-image.jpg?restype=service&comp=properties&sv=2017-04-17&ss=b&srt=sco&sp=rwdlac&se=2017-12-01T00:00:00Z&st=2017-11-01T00:00:00Z&spr=https,http&sig=6xQPKuBohCCm9CJm1cm2uX8kSFM%2BV3CNBTtkxIiadf0%3D"
},
uploadSuccess: {
endpoint: '/nrlflex/success'
},
retry: {
enableAuto: false
},
deleteFile: {
enabled: true
}
});
My CORS configuration is as follows:
Allowed Origins : *
Allowed methods: Get, Put
Allowed headers: *
Exposed headers: *
Max age: 200
Detailed explanation of the problem
This is what I am getting as response:
GET https://bradsol.blob.core.windows.net/nrl-imagery/nrl-image.jpg?restype=service&comp=properties&sv=2017-04-17&ss=b&srt=sco&sp=rwdlac&se=2017-12-01T00:00:00Z&st=2017-11-01T00:00:00Z&spr=https,http&sig=6xQPKuBohCCm9CJm1cm2uX8kSFM%2BV3CNBTtkxIiadf0%3D&bloburi=https%3A%2F%2Fbradsol.blob.core.windows.net%2Fnrl-imagery%2F%2F35f5387d-fa0a-4f53-a8de-95b2d2bd5d30.jpg&_method=PUT&qqtimestamp=1510725973786 405 (The resource doesn't support specified Http Verb.)
Failed to load https://bradsol.blob.core.windows.net/nrl-imagery/nrl-image.jpg?restype=service&comp=properties&sv=2017-04-17&ss=b&srt=sco&sp=rwdlac&se=2017-12-01T00:00:00Z&st=2017-11-01T00:00:00Z&spr=https,http&sig=6xQPKuBohCCm9CJm1cm2uX8kSFM%2BV3CNBTtkxIiadf0%3D&bloburi=https%3A%2F%2Fbradsol.blob.core.windows.net%2Fnrl-imagery%2F%2F35f5387d-fa0a-4f53-a8de-95b2d2bd5d30.jpg&_method=PUT&qqtimestamp=1510725973786: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. Origin 'http://localhost' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

Note: Support requests cannot be accepted due to lack of time.