Fixed codec nullptr dereferencing.

Signed-off-by: Cervenka Dusan<EMAIL_ADDRESS>Pull request
Choose Correct

[X] bug
[ ] feature

Describe the pull request

#263
To Reproduce

Expected behavior

Screenshots

Desktop (please complete the following information):

OS:
eRPC Version:

Steps you didn't forgot to do

[X] I checked if other PR isn't solving this issue.
[x] I read Contribution details and did appropriate actions.
[X] PR code is tested.
[X] PR code is formatted.

Additional context

This PR should be ready to merge.

I suggest (maybe in addition?) to call the dispose function just if it not null
    // Get a new request.
    RequestContext request = g_client->createRequest(false);

    // Encode the request.
    Codec * codec = request.getCodec();

    if (codec == NULL)
    {
        err = kErpcStatus_MemoryError;
    }
    else
    {
        ...
    // Dispose of the request.
    g_client->releaseRequest(request);
    }

I suggest (maybe in addition?) to call the dispose function just if it not null
    // Get a new request.
    RequestContext request = g_client->createRequest(false);

    // Encode the request.
    Codec * codec = request.getCodec();

    if (codec == NULL)
    {
        err = kErpcStatus_MemoryError;
    }
    else
    {
        ...
    // Dispose of the request.
    g_client->releaseRequest(request);
    }

I was thinking about this implementation too. It is correct, but it may be tricky if there will be change in RequestContext. Logically i don't like that createRequest is called in different scope than release request. As this are pair functions.

OK, agree.
Another thing that is bothering me her is that we know that g_client->createRequest(false); failed just with looking on the codec, isn't there is some status we can return and check it for failures?

OK, agree. Another thing that is bothering me her is that we know that g_client->createRequest(false); failed just with looking on the codec, isn't there is some status we can return and check it for failures?

I understand what you  want to achieve. I think it is not necessary right now. But it can be usefull in future if another allocation may failed during RequestContext creation...


Feat/Refactor: EventBus and Notifications

This PR adds an EventBus singleton to the codebase and replaces the notificationsStore with this new approach. There are a few places in the app where the existence of this pattern will simplify the code. Additionally, this PR cleans up the various Notification related components.

Adds a type safe global EventBus
Removes the use of the notificationsStore
Consolidates all notification component types into a single Notification component
Brings Notification styling more in line with Figma mocks
Moves the NotificationCenter component higher up in the tree
Fixes an issue where the type property on a notification was not being used

Ah, my intention was to eliminate that and just have notifications with links always be persisted. Will update.


Adding a Route53 private entry

I am pretty newt to TF, and have been using this module to create various instance types for myself. However, as part of the module, I wanted to add a DNS A record in route53. It works, kinda. Except if i create more than one instance, it assigns all the IPs to the first instance name [in the case below fp-1 gets the IPs for fp-1-3]
It would be awesome if the module had the option to create a private DNS entry based on the Name tag.... [or alternatively someone could help me figure out where I am banjaxing this]
module "ec2_fp" {
  source                 = "../../terraform_modules/terraform-aws-ec2-instance"
  name                   = "FP"
  ami                    = "${var.ami}"
  instance_type          = "${var.fp_instance_type}"
  instance_count         = "${var.fp_instances_number}"
  use_num_suffix         = "true"
  subnet_ids             = "${data.terraform_remote_state.vpc.public_subnets}"
  vpc_security_group_ids = ["${data.terraform_remote_state.secgrp.fp_sg}"]

  tags = {
    "NodeType"       = "FP"
    "ManagedBy"      = "TerraForm"
    "Tier_Placement" = "public"
  }
}

resource "aws_route53_record" "r53_fp" {
  zone_id = "${data.aws_route53_zone.selected.zone_id}"
  name    = "${lookup(module.ec2_fep.tags[0], "Name")}.${data.aws_route53_zone.selected.name}"
  type    = "A"
  ttl     = "300"
  records = ["${module.ec2_fp.private_ip}"]
}

Someone on reddit helped me out with this, so the solution was a count issue:
resource "aws_route53_record" "r53_fp" {
  count   = "${var.fp_instances_number}"
  zone_id = "${data.aws_route53_zone.selected.zone_id}"
  name    = "${lookup(module.ec2_fp.tags[count.index], "Name")}.${data.aws_route53_zone.selected.name}"
  type    = "A"
  ttl     = "300"
  records = ["${element(module.ec2_fp.private_ip, count.index)}"]
}


Blazor WASM security: Distinguish Kestrel & IIS ports

Fixes #18389
Thanks again @marshallr12! 🌴

mmm 🤔 I'll probably go with an INCLUDE file in the future to streamline updates like this.


[ci:component:github.com/gardener/vpn2:0.14.0->0.15.0]

How to categorize this PR?

/area TODO
/kind TODO
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note:

/approve
/kind enhancement


some minor lint related changes

some minor lint related changes

This just updates the code to be compliant with the upcoming dart recommended lint rule set (not yet released).
cc @pq

I thought I added the missing lints here, perhaps I missed one. Is this the directives_ordering lint? If so can you add it to the analysis options?

I thought I added the missing lints here, perhaps I missed one. Is this the directives_ordering lint? If so can you add it to the analysis options?

I thought I added the missing lints here, perhaps I missed one. Is this the directives_ordering lint? If so can you add it to the analysis options?

It is the directive ordering line; these are the (small) deltas from the current rule set to a potential proposal for a new recommended rule set for Dart. A preview of that rule set is here https://github.com/devoncarew/simple_lint_rules/blob/main/lib/analysis_options.yaml (note that that package isn't intended to be supported, just a way to preview the lint set).

I thought I added the missing lints here, perhaps I missed one. Is this the directives_ordering lint? If so can you add it to the analysis options?

It is the directive ordering line; these are the (small) deltas from the current rule set to a potential proposal for a new recommended rule set for Dart. A preview of that rule set is here https://github.com/devoncarew/simple_lint_rules/blob/main/lib/analysis_options.yaml (note that that package isn't intended to be supported, just a way to preview the lint set).


Non default ordering of classes

Allow input to _init to allow for custom ordering of classes possibly by ordring from most important class (postive class) to least important (trivial class).   For example, a three class problem where you are trying to classify stocks:
Buy
Hold
Sell
One may want high precision on "buy" class with less focus on recall.   But, conversely, high recall on sell class.  And less concerned with inaccurate predictions on hold class.  So ordering may be:
Buy (pos class)
Sell (neg class)
Hold (neutral class)

Released and tested. Have not run performance tests yet.


Particle system demo does not play well with timeline

http://localhost:8080/Apps/Sandcastle/index.html?src=Particle System Tails.html&label=New in 1.44

The demo animates whether the clock is running or not.
Jumping around in the timeline seems to completely break the effect.

@mramato this is a new demo, should we fix it before the release tomorrow?  @hanbollar @ggetz

The fix for this would be to factor in the delta time that is passed as the second parameter to the update function, but it would take a little bit of fiddling to make it look nice for all time multipliers.
@hanbollar would you be interested in providing a fix?

@ggetz @mramato @hpinkos I can take a look at this and try to fix the visual

THanks @hanbollar!

@ggetz @mramato @hpinkos - added sort of a hacky fix - lmk if this is ok for a sandcastle example - i explain my reasoning in the pull request


Allow first part of a path to be a path param

It seems like type-route doesn't allow the first part of a path definition to be a parameter? Is that intended behaviour or a bug? For example I'd like to define routes that start with a locale, for example /en-us/test or /en-gb/test.
Here's a quick snippet to test with:
const testRouter = createRouter({
    testA: defineRoute({ locale: "path.param.string" }, (p) => `/${p.locale}/test`),
    testB: defineRoute({ locale: "path.param.string" }, (p) => `/first/${p.locale}/test`)
})
console.log("A match", testRouter.routes.testA.match({ pathName: "/en-us/test" })) // false
console.log("B match", testRouter.routes.testB.match({ pathName: "/first/en-us/test" })) // { locale: 'en-us' }

The testA route fails to match, but I expected it to match with { locale: 'en-us' }.

I opened #14 which I think can fix this.

Thanks! Just released your fix in version 0.3.2.


Recommended partition`s size (TZ-813)

Question
In every zigbee sdk`s example there are custom partition table. In those tables always zb_storage partition with length of 16k
Is this general recommendation and 16k is more then enough? Or is it make sense increase partition if I plan to connect 100+ devices to my router? Same question about zb_fct
Thanks!
# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you have increased the bootloader size, make sure to update the offsets to avoid overlap
nvs,        data, nvs,      0x9000,  0x6000,
phy_init,   data, phy,      0xf000,  0x1000,
factory,    app,  factory,  0x10000, 900K,
zb_storage, data, fat,      0xf1000, 16K,
zb_fct,     data, fat,      0xf5000, 1K,

Additional context.
No response

@grebenyuk51 ,
Based on the statistics, the coordinator needs to allocate approximately 496 bytes for a new device. You can optimize this based on your project's requirements.
As for the zc_fct partition, it is reserved for manufacturer configuration. You can find more information in the mfg_tool documentation.

thanks


[BUG] Kubescape 'privilege' test doesn't support excluding containers with the allowlist argument

Describe the bug
Kubescape 'privilege' test doesn't support excluding containers with the allowlist argument
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Device (please complete the following information):

OS [e.g. Linux, iOS, Windows, Android]
Distro [e.g. Ubuntu]
Version [e.g. 18.04]
Architecture [e.g. x86, arm]
Browser [e.g. chrome, safari]

How will this be tested? aka Acceptance Criteria (optional)
(optional: unnecessary for things like spelling errors and such)
Once this issue is address how will the fix be verified?
Additional context
Add any other context about the problem here.

NOTE: you can enable higher logging level output via the command line or env var. to help with debugging
# cmd line
./cnf-testsuite -l debug test

# make sure to use -- if running from source
crystal src/cnf-testsuite.cr -- -l debug test

# env var
LOGLEVEL=DEBUG ./cnf-testsuite test

Also setting the verbose option for many tasks will add extra output to help with debugging
crystal src/cnf-testsuite.cr test_name verbose

Check usage documentation for more info about invoking commands and logging

@HashNuke @agentpoyo @denverwilliams is still issue still relevant for CNTI?

I can take a look at this.

@lixuna I checked that and I think that this issue is still relevant. I see different behavior when I run test for checking privileged containers with kubescape an also without kubescape.
Run without kubescape:
./cnf-testsuite privileged I, [2024-02-22 10:35:01 +01:00 #1298101]  INFO -- cnf-testsuite: task_runner args: #<Sam::Args:0x7f6205c78540 @arr=[], @named_args={}> I, [2024-02-22 10:35:01 +01:00 #1298101]  INFO -- cnf-testsuite: cnf_config_list I, [2024-02-22 10:35:01 +01:00 #1298101]  INFO -- cnf-testsuite: find: find cnfs/* -name "cnf-testsuite.yml" I, [2024-02-22 10:35:01 +01:00 #1298101]  INFO -- cnf-testsuite: find response: ["cnfs/privileged-coredns/cnf-testsuite.yml"] ... ✔  PASSED: No privileged containers 🔓🔑
Run with kubescape:
./cnf-testsuite privileged_containers I, [2024-02-22 10:36:13 +01:00 #1300602]  INFO -- cnf-testsuite: kubescape_framework_download I, [2024-02-22 10:36:13 +01:00 #1300602]  INFO -- cnf-testsuite: install_kubescape I, [2024-02-22 10:36:13 +01:00 #1300602]  INFO -- cnf-testsuite: scan command: /home/horecoli/.cnf-testsuite/tools/kubescape/kubescape scan framework nsa --use-from /home/horecoli/.cnf-testsuite/tools/kubescape/nsa.json --exclude-namespaces kube-system,kube-public,kube-node-lease,local-path-storage,litmus,cnf-testsuite --format json --output kubescape_results.json ... ✖  🏆 FAILED: Found privileged containers 🔓🔑 Failed resource: Deployment privileged-coredns-coredns in default namespace Remediation: Remove privileged capabilities by setting the securityContext.privileged to false. If you must deploy a Pod as privileged, add other restriction to it, such as network policy, Seccomp etc and still remove all unnecessary capabilities. Use the exception mechanism to remove unnecessary notifications.
So with kubescape (task privileged_containers) is ignoring allowlist_helm_chart_container_names: [coredns] in cnf-testsuite.yml.
I will take a look at this issue.

This issue isn't valid anymore. Closing ticket.

When this ticket was created, kubescape wasn't considering resources specific to the CNF. A later ticket/PR included a change to the Kubescape module to consider only the CNF's resources. (There is a 'filter_cnf_resources' helper method in the Kubescape module that does this).

The allowlist option is for certain tests to help ignore certain resources that are not part of the CNF.

The new Kubescape and Kyverno-based tests only consider resources that are part of the CNF instead of all resources on the cluster.
AFAIK, several old tests also been updated to only read & test resources that are part of the helm chart.
In addition, all the testsuite-related tools have been moved to the cnf-testsuite namespace to avoid having to configure allowlist for these tools/resources.

@horecoli Please ignore this ticket.

OK, but then we should remove the ignoring of containers from task privileged where it is checked without kubescape.
As I understand from your answer, that situation should not happen because of placing in different namespaces. So, also checking without kubescape (task privilege) should fail too, shouldn't it?

@horecoli To be able to remove the support for allowlist in the privileged test, we will have to ensure that the test only checks the CNF's resources.
Thanks for bringing this up. I created a ticket here with some details - https://github.com/cnti-testcatalog/testsuite/issues/1906


Plugin doesn't pick up concatenated strings

I'm using the plugin with a function called t().
If I split a token across multiple string concat calls, the plugin does not seem to pick up the translation: t('a' + 'b') doesn't work but t('ab') does.
I looked at the code but I couldn't figure it out, sorry.
Thanks,
Eddie

Hello
It is very strange, we have done a release with this MR that contains your case. Could you double check your version ?
Julien


How to enable the mm-grounding-dino support to detect classes described in Chinese?

Since the in-house images are all labeled in Chinese, I'm curious about how to enable the model to support detecting images like that. I simply translated the label from English to Chinese, but there are some ambiguities and I think it cannot be solved by translation. So I decide to change "bert-base-uncased"  to "bert-base-chinese". I viewed the config file of these two, and the main difference between them is the vocabulary size. I'm not sure whether the simple change will work and curious about whether I need to tune the Chinese Bert or not. If I need to tune the Chinese Bert, do you have any suggestions? Like which dataset I can use? The in-house dataset or the 13 datasets given by official mm-detection? Can I view the OVD task like a downstream task and set small learning rate to tune the Chinese Bert?

Since the in-house images are all labeled in Chinese, I'm curious about how to enable the model to support detecting images like that. I simply translated the label from English to Chinese, but there are some ambiguities and I think it cannot be solved by translation. So I decide to change "bert-base-uncased" to "bert-base-chinese". I viewed the config file of these two, and the main difference between them is the vocabulary size. I'm not sure whether the simple change will work and curious about whether I need to tune the Chinese Bert or not. If I need to tune the Chinese Bert, do you have any suggestions? Like which dataset I can use? The in-house dataset or the 13 datasets given by official mm-detection? Can I view the OVD task like a downstream task and set small learning rate to tune the Chinese Bert?

After simply running through all the code given by official mm-detection, and doing some continue-pretraining as the way to finetune, I notice that the official code just simply download the original bert-base-uncased and never tune that, so I'm not sure what to do next.

same question here, I want to use bert-chinese to train the mmgd. But I think it needs a full dataset re-pretraining process.
the problem is that the dataset mmgd used for pretraining is labeled in English and quite difficult to translate it to Chinese, needs time to align those labels.
And ideas would be welcome.


[Question]: how to start qemu with QEMU machine protocol (QMP) enabled?

Is your question not already answered in the FAQ?

[X] I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

[X] I am sure my question is not about a technical issue.

Question
Hi, in the entry.sh the qemu virtual machine get started with the following command
{ qemu-system-x86_64 ${ARGS:+ $ARGS} >"$QEMU_OUT" 2>"$QEMU_LOG"; rc=$?; } || : (( rc != 0 )) && error "$(<"$QEMU_LOG")" && exit 15
How can I add the argument -qmp TCP:localhost:4444,server,nowait  to the start parameter so that the virtual machine starts with qmp running and I can connect to it? I want to use the system as a testbed for forensic analysis and, therefore, need to create memory dumps of the virtual machine. I already tried libvirt and virsh, but the virtual machine is not listed in the local VM; here is the output:
sudo virsh list --all
 Id   Name   State
--------------------

Can someone please help me with getting access to the qemu environment?

Thank you. I could create the dump, but how do I get the memory dump outside the Qemu and the Docker environments?


Removes Datastore geospatial sample.

In reference to internal bug 32697836.
@lesv PTAL

Because the API is in a closed alpha and they are not accepting whitelist applications. The tech writers removed the documentation today because they were getting too much feedback asking to join the whitelist.
I suppose we could keep the sample around, but it's not referenced anywhere in the docs anymore.


add: QuipLoader in langchain.document_loaders init.py

since this has all been moved to community, going to avoid changing here

@hwchase17 thanks, created PR: https://github.com/langchain-ai/langchain/pull/15098/files


Azure Search Ranking

Hi,
My application is in MVC and I have a search text box based on azure index, its working fine however I have a scenario where in if I enter "chres Harris" instead of "chris Harris" it should return result "chris Harris" but it returns different result like "bob Harris" and then "chris harris", I want the results to be nearabout the same even if there is a spell mistake, please help will any index scoring profile, parameter boost or something useful ?

Hi @harsh288,
This issue is not specific to the .NET SDK, so I'm going to close it. Please start a new thread on the Azure Search MSDN forum and I'll make sure the right person on our team helps you out:
https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=azuresearch
Thanks,
-Bruce

Sure thanks !!


Rename "All facilities" link text

FRONTEND PULL REQUEST
Related Issue
Resolves #4097
Changes Proposed
Renames the "All facilities" link that takes a user back to /facilities to "Back to all facilities" so that it is more descriptive to users accessing the page from a screen reader
Additional Information
In a separate story, we might want to check-in with design about spacing between the link and the facility name if a user is exploring an existing facility.
How it looks now:

Testing

Ensure the back link works as intended
Ensure no new accessibility issues were introduced

Screenshots / Demos

Looks good to me! Do you mind adding a ticket for the design ask on respacing?

Thank you for the reminder!! Here i t is https://app.zenhub.com/workspaces/simplereport-growth--engagement-605b43a6ceb92c000f86279a/issues/cdcgov/prime-simplereport/4323


AnimationTree StateMachine advance conditions to self-disable

AnimationTree state machine transitions can have advance condition. This adds prop which can be set to true/false which enables/disables such transition auto-advancement. This allows for easier enabling transition paths without need to explicitely travel() nodes. However sometimes we need to go into state, wait till it ends and go back. If second transition ("back") is always advances, or enables advcnce condition, the state will be entered again in loop. If both conditions are IMMEDIATE, this will lead to rapid looping. This is not always wanted, but catching condition execution from script by polling to disable it is not possible to do reliably in script. So it would be nice if once triggered, the advance condition could disable itself for second triggering (configurable with parameter). Or some signal to know when transition happens to be able to disable advance condition.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!


jsonwebtoken unrestricted key type could lead to legacy keys usage

Hey, yesterday npm started to yell at me when I was trying to install the package. There is some issue with the older versions of jsonwebtoken (screenshot from npm audit is attached).  I'm very new to web development and programming in general, so I decided to report it as an issue because it just doesn't seem like a safe solution to me to try to update the jsonwebtoken directly in the multer-firebase-storage folder.

You are completely correct, I'll update the package versions that this repository relies on and generate a new safe version! Thanks for commenting!

Thanks! Great package btw, helped me a lot.


Initial integration with ledger application

This draft PR introduces a foundational step towards secure hardware wallet support within zingolib by integrating a custom ledger application.
Changes

Keystore Abstraction: Introduced a new abstraction layer, Keystore, as an enum with two variants: WalletCapability for the existing in-memory wallet functionality, and LedgerWalletCapability for the new ledger integration. This allows for seamless switching between wallet types and makes future extensions possible and easy.

Ledger Wallet Capability: The LedgerWalletCapability encapsulates all interactions with the Ledger device, including transaction signing(not supported yet) and address generation.

Support for Sapling and Transparent Addresses: The ledger application currently supports sapling and transparent addresses, orchard protocol is not supported yet by the ledger-app.

Challenges

Integration with In-memory Key Architecture: Adapting the ledger's secure key management approach to fit within zingolib's architecture, which currently relies on in-memory keys, poses a significant challenge. This required careful design to ensure that cryptographic operations are executed on the Ledger device, with zingolib managing only the operations that do not involve direct access to private keys, usually done through the TryFrom trait.
Partial Address Support: Currently, the integration does not support orchard and unified addresses. The support for Orchard is not part of the scope of implementing this feature in zingolib but in the ledger-app.
Data storage: Currently we are unable to read address data from wallet.dat file which is used to store important metadata like addresses and key parameters. This is due to the way the ledger app operates.
** Understanding zingolib architecture:** The current integration effort can be improved by a better understanding of the zingo architecture to ensure a seamlessly integration that would facilitate further integration of new features.
Types differences: There are some conflicts between our Rust library and zingolib, the differences are more related to versioning and API compatibility.

There are some TODOs in the code and comments explaining the reason.
This initial integration is still not functional, in order to get there more changes have to be done in:

Defining how many metadata file the app supports and if differentiating from in memory or ledger-app ones is desirable.
Proper changes on the UI
Add support for sapling addresses
Transaction signing would possibly require adding another abstraction, which for the ledger app is provided via ledger-zcash-rs
Modifying ledger-zcash-rs library, in order to use raw data, could make easy further integration efforts, decoupling other libraries and relying on simple conversion, for example:  PublicKey::from_slice(), and so on.

This is on my radar.

We've consulted with ZonDax and this work is largely obsolete.  Is there important code to preserve @neithanmo ?

Is this fully outdated or is this just hard to rebase?

@zancas it is outdated, but the general integration idea holds, however this would depend on recent development the structure/design might be now outdated and could not be the best integration approach

I'm giving it a go to see if I can bring this to life in a newer branch

Superseded by #1352


Increase minimal token length

To be consistent with web part

I just though... what would happen to existing 16-character tokens?

Hm, you are right. User object won't be created from DB.

I guess we should keep it as it is. There might be a way to deal with it,  but I don't want to make it too complicated.

Move validation to API resource.
But OK. Leave it as is.


[FEATURE] Add bulk() / prepareBulk() to SDKRestClient

Is your feature request related to a problem?
The Anomaly Detection AnomalyResultBulkIndexHandler and its test classes utilize the node client to invoke prepareBulk() here which returns a BulkRequestBuilder that is used to send multiple index requests to the anomaly results index. The client is then used to invoke bulk() which sends the request configured by the BulkRequestBuilder.
The SDK should have the same capability to support handling of bulk requests.

@dbwiddis I would like to take this issue.

@dbwiddis How to resolve this issue? SDKRestClient is deprecated. SDKClient returns RestClient that have bulk().

Hey @nassipkali we have intentionally marked SDKRestClient as deprecated because we don't want it used for new development. New users should use the java clients.
However we need SDKRestClient to ease migration of existing plugins.  So the SDKRestClient is the correct place to work on this.

Hey @nassipkali we have intentionally marked SDKRestClient as deprecated because we don't want it used for new development. New users should use the java clients.
However we need SDKRestClient to ease migration of existing plugins. So the SDKRestClient is the correct place to work on this.

Is this class located in OpenSearch? I didn't find SDKRestClient in sdk repo.

It's an inner class in SDKClient

@dbwiddis How to implement prepareBulk() if RestHighLevelClient does not have that method? For implementation of that method from scratch I need BulkRequestBuilder but constructor needs OpenSearchClient. Only way to pass OpenSearchClient is getting javaClient from SDKClient. Is it correct way to construct BulkRequestBuilder?

@joshpalis can you provide more insight here?

@joshpalis Looks like we can use bulk() without prepareBulk()
https://stackoverflow.com/questions/51868548/elasticsearch-indexing-100k-documents-with-bulkrequest-api-using-java-resthighle/51868683#51868683

Or just create a prepareBulk() method that wraps and returns that constructor. :)

Or just create a prepareBulk() method that wraps and returns that constructor. :)

Should it return BulkRequest?

Probably. That's what the one on OpenSearch does. We just need a copy of it.  Or delegate to the one on OpenSearch in the RHLC.

@joshpalis Is issue completed?

@nassipkali It looks like @joshpalis implemented bulk().  As you indicated in this comment it's possible to just instantiate a new BulkRequest object which is an acceptable workaround.
However, we also like to enable plugin migration minimizing the diff between projects so it would be nice to have a prepareBulk() method.
In theory we'd want to just copy the OpenSearch version that returns a BulkRequestBuilder but its entire purpose is to wrap a request and include a client argument to be able to call the execute() and get() methods in the ActionRequestBuilder superclass, and it also instantiates itself with the (OpenSearch-side) BulkRequest action, none of which we want.  See here.  So that isn't really a good course of action; we really just need the internal BulkRequest.
As an option we could create an SDKBulkRequestBuilder that can be returned by the prepareRequest() method.  There we could either

extend the OpenSearch one and override the methods.  Given the OpenSearch class is marked as internal and we'd be removing most of the functionality, I don't like this idea.
create our own class which internally instantiates a BulkRequest and then implements the add() methods that proxy the add() requests to the internal request object, that's returned by request().   This would work but it's really just a layer over instantiating the BulkRequest and calling add() to it directly, and there are a lot of add() methods to implement.  It reminds me of all the incremental work I did to create an ExtensionRestRequest only to finally realize I just wanted the original RestRequest object.

So I'm in favor of just instantiating the BulkRequest object instead of calling prepareRequest().  Which requires no code PR, but should be documented in our PLUGIN_MIGRATION document, probably as another bullet point under the paragraph starting "TransportActions on OpenSearch are not accessible to extensions ....".
@joshpalis WDYT?


Update help system URL once element gallery is ready

In core.pprint:
    @classmethod
    def object_info(cls, obj, name, ansi=False):
        element = not getattr(obj, '_deep_indexable', False)
        url = ('http://holoviews.org/Tutorials/Elements.html#{obj}'
               if element else 'http://holoviews.org/Tutorials/Containers.html#{obj}')
        link = url.format(obj=name)

        link = None if element and (name not in cls.elements) else link
        msg = ("\nOnline example: {link}" if link else ''
               + "\nHelp for the data object: holoviews.help({obj})"
               + " or holoviews.help(<{lower}_instance>)")

        return '\n'.join([msg.format(obj=name,
                                     lower=name.lower(),
                                     link=link)])

The URLs will need to be updated once the element gallery is in place.

Addressed in the PR referenced above (#1624).


Componentisation has gone too far.

While I agree that making clearly delineated separation between components is good, the approach that has gone on in the past few months is severely hindering ongoing development and bug-fixing of the docker engine.
I concur that certain components make perfect sense to be in independent, such as libcontainer or libnetwork. But for other components, engine-api for example being the latest I hit today, IMO it simply makes it harder to develop changes/bug fixes to the engine for reasonably little gain. As it stands as I type, it is not even possible to build the docker engine with the latest engine api - it's not in a state that can be vendored in and compiled. That makes issues such as https://github.com/docker/docker/issues/18077#issuecomment-178641687 almost impossible to fix in the current code base.
My suggestion is to keep separation at the pkg/ level, rather than fracturing out into so many distinct repos. The current design philosophy makes submitting changes incrementally hard and onerous, and I'm far from convinced that this level of componentisation is worth the advantages. It sets the the learning curve bar for new contributors at 'extreme'. And 'complicated++' for relatively seasoned ones.
It also (in the current CI world where Windows CI is only enabled on docker/docker) is prone to increased error possibilities. We should try to make this easy for everyone, not overly complicate things.
Componentisation to separate repos makes sense if the overall code base were stable. However, this remains far from the case with the level of changes going through daily and weekly.
Please discuss :smile:
@shykes @docker-maintainers @thaJeztah @friizm @icecrime

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@jhowardmsft agreed - and mentioned it here: https://github.com/docker/engine-api/pull/65#issuecomment-176186569
In addition to what you mentioned, the spit at the repo level forces a duplication of testing too - and a lot of work to "mock" things. This extra "mocking" effort ends up 1) being a lot of wasted effort when the real data is available to us if we just used docker itself, and 2) gives us a false sense of security because we only end up verifying the most basic cases and miss the unplanned interactions of a real live daemon. And if the answer there is "we'll catch those when we vendor it into the engine", then we should just move it back to the engine now because then its not really as independent as we claim since it can't be truly tested on its own.
With go's import/pkg system there's really no reason (at this time) not to keep it with the engine and let people import it if they want just that bit.  If at some point the engine-api (and the go-builder repo too) are really stand-alone and can be fully run/tested w/o the engine, then I think we can reconsider this but right now its just pain with no real gain.  I don't see what we get by being in a different repo that we can't do in a pkg (aside from a different set of maintainers, which IMO isn't necessarily a good thing since the apis & builder are so related to the engine anyway).

This is an important discussion to have, I'll share my current feelings.

[...] for other components, engine-api for example being the latest I hit today, IMO it simply makes it harder to develop changes/bug fixes to the engine for reasonably little gain

Yes, that is absolutely true: it makes it harder on the Engine. But the reasoning behind this decision is that Engine is not alone anymore. Tons of projects out there use the Docker API, both outside (Rancher, CI systems, ...), and inside Docker (Swarm, Compose, ...). One of the most recurring criticism against the project is that the API changes too much, sometimes for no good reason.
Having a reference API implementation that is upstream from all products seems like a sane thing to do: we can discuss changes to the API independently of any particular product, and when such changes are approved, all clients stand on equal ground and can manage their own related patches.
What we are experiencing on Engine right now is what every other project out there has been experiencing forever. We made it worse on Engine, to make it better for everybody else.

Componentisation to separate repos makes sense if the overall code base were stable. However, this remains far from the case with the level of changes going through daily and weekly.

I honestly wonder how much more stable would the API be if it hadn't been so trivial to change, including by mistake (!), through the Engine codebase. I think it's worth considering that maybe nothing is stable because there is no technical incentive for it to be.

This extra "mocking" effort ends up 1) being a lot of wasted effort when the real data is available to us if we just used docker itself, and 2) gives us a false sense of security because we only end up verifying the most basic cases and miss the unplanned interactions of a real live daemon.

This statement is Engine centric: what about all the other clients depending on the API today?

If at some point the engine-api (and the go-builder repo too) are really stand-alone and can be fully run/tested w/o the engine, then I think we can reconsider this but right now its just pain with no real gain.

Do you think anybody is happy having those repositories untested? The only reason there are no tests is because nobody had time, and the fact that it's issue docker/engine-api#1 makes it pretty clear how much we think it matters. It's extremely ironic for a maintainer to complain that something is missing.
I'm just going to conclude this way. Am I convinced that a separate repository is a better idea than a sub pkg/? No, but I don't think we tried hard enough to make that call just yet. Maybe the conclusion will be that it indeed doesn't make sense, we'll say "well, we tried", and we'll move on. I know for sure that I'd be happier writing code against docker/engine-api than against docker/docker/pkg/engine-api.

On Feb 3, 2016, at 12:07 PM, Arnaud Porterie<EMAIL_ADDRESS>wrote:

This is an important discussion to have, I'll share my current feelings.
[...] for other components, engine-api for example being the latest I hit today, IMO it simply makes it harder to develop changes/bug fixes to the engine for reasonably little gain
Yes, that is absolutely true: it makes it harder on the Engine. But the reasoning behind this decision is that Engine is not alone anymore. Tons of projects out there use the Docker API, both outside (Rancher, CI systems, ...), and inside Docker (Swarm, Compose, ...). One of the most recurring criticism against the project is that the API changes too much, sometimes for no good reason

The problem with this is that the engine-api’s don’t stand alone either - they have no meaning without an impl behind it - and the only real impl (as of now) that matters is the engine.  No change should go into the engine-api, that will require a change to the engine, without also being reviewed by the engine team. Otherwise the engine-api change will be an orphan and will probably need to be removed.  Wasted time/effort.
See comment below about “API changes too much”.

Having a reference API implementation that is upstream from all products seems like a sane thing to do: we can discuss changes to the API independently of any particular product, and when such changes are approved, all clients stand on equal ground and can manage their own related patches.

An API w/o impl makes no sense. All api changes should be reviewed within the full context of Docker, meaning (mainly) the engine.  Unless you actually see a point in time where the API has a feature that the Docker engine doesn’t support - but even if that’s possible (way way in the future) I don’t see it in the cards right now.

What we are experiencing on Engine right now is what every other project out there has been experiencing forever. We made it worse on Engine, to make it better for everybody else.
Componentisation to separate repos makes sense if the overall code base were stable. However, this remains far from the case with the level of changes going through daily and weekly.
I honestly wonder how much more stable would the API be if it hadn't been so trivial to change, including by mistake (!), through the Engine codebase. I think it's worth considering that maybe nothing is stable because there is no technical incentive for it to be.

I don’t think the stability, or lack of it, can be blamed on which repo the code sits in. That’s strictly on us for allowing changes when we maybe shouldn’t have.  And, in fact, a separate repo will make it worse because there’s not only nothing stopping us from making these types of changes in the future, but now we’re doing it w/o any analysis (testing) of what it means for the engine and the rest of Docker.

This extra "mocking" effort ends up 1) being a lot of wasted effort when the real data is available to us if we just used docker itself, and 2) gives us a false sense of security because we only end up verifying the most basic cases and miss the unplanned interactions of a real live daemon.
This statement is Engine centric: what about all the other clients depending on the API today?

People care about the engine-api's because they want compatibility with Docker - its not some random API out there.  So, yes its very engine centric because the engine-api repo is for the engine  :-)  Trying to give the main interface of a product a different lifecycle/feature-set/etc... from the product itself seems really odd to me - unless its stand-alone, which its not.

If at some point the engine-api (and the go-builder repo too) are really stand-alone and can be fully run/tested w/o the engine, then I think we can reconsider this but right now its just pain with no real gain.
Do you think anybody is happy having those repositories untested? The only reason there are no tests is because nobody had time, and the fact that it's issue docker/engine-api#1 https://github.com/docker/engine-api/issues/1 makes it pretty clear how much we think it matters. It's extremely ironic for a maintainer to complain that something is missing.

But we have tests - its called integration cli  :-)    What you’re suggesting is that we either duplicate it or mock it.  Who has the time to maintain two sets of tests that should look pretty similar? Who really wants to?

I'm just going to conclude this way. Am I convinced that a separate repository is a better idea than a sub pkg/? No, but I don't think we tried hard enough to make that call just yet. Maybe the conclusion will be that it indeed doesn't make sense, we'll say "well, we tried", and we'll move on. I know for sure that I'd be happier writing code against docker/engine-api than against docker/docker/pkg/engine-api.

A better approach would be to move it to the pkg dir and see how that feels first. It provides the isolation 3rd party tooling needs w/o the pain. Once we have proven that’s ok AND we have a solid framework for testing and reviewing PRs for that pkg w/o the rest of Docker then we can consider moving it to a new repo.

Let's ask actual & potential users: ping @vieux @aluzzardi @ibuildthecloud @justincormack @ehazlett @donhcd @dnephin.

I think the split into engine-api is actually working extremely well. It's forcing us to consider API changes in isolation, which leads to more consistent and well thought out API design. It allows other projects which depend on the API to watch for changes and contribute feedback without the torrent of implementation-related changes in the engine.
We've just started this process, so I think it's normal there are some pain points. We should work on addressing them directly instead of abandoning the idea entirely.

What we are experiencing on Engine right now is what every other project out there has been experiencing forever. We made it worse on Engine, to make it better for everybody else.

+100
Most of the issues I see here I think can be fixed with some better tooling.

But we have tests - its called integration cli

integration-cli tests are part of the problem. If you test from the client you completely miss any API regressions. The client can cover up unexpected api changes. The end-to-end tests for engine should really be using the API directly, not the cli.
engine-api is a special case. You don't test an interface by testing its implementation. I think the relevant tests for an interface are:

is it consistent
is it backwards compatible
is it complete

The first two can be verified without any implementation, and the last can't be verified without every implementation, so can't be verified in engine either (each implementation is responsible for testing itself).
Testing of packages like go-builder is easy to do in isolation. All the important unit and functional tests can be done in the go-builder repo. engine only needs a couple high level end-to-end tests for the integration of the package.

I don’t think the stability, or lack of it, can be blamed on which repo the code sits in.

I think it makes a big difference. When you look at API changes as a set of 20+ other file changes it's easy to miss problems. You're focused on too many things at once. If you look at API changes in the context of "the api repo" and there are only 2 or 3 file changes, it's much easier to focus on the API design, and not get lost in the implementation changes.
It also makes it possible for other projects who depend on the API to be involved, because watching the engine-api repo is a much easier than watching every change to docker/docker.

With go's import/pkg system there's really no reason (at this time) not to keep it with the engine and let people import it if they want just that bit.
A better approach would be to move it to the pkg dir and see how that feels first.

If we went with this approach it would never be extracted. In order to make any progress on this we need to pull it out and start severing the ties early. It's painful at first, but it gives us a chance to identify the pain points and create the right tooling to address it.
Keeping it in the engine means the pain points are only felt by those outside the engine team, which aren't in a position to fix them.
I personally think this split out is long overdue, not premature.

Also I saw that @bobrik used engine-api for his project.

Note too that once the server api is moved out things should be less painful since the API change happens in one place, vendor-in and update the implementation only.
I agree it's certainly been more painful, however I think in the long run it's a huge benefit to all projects involved and will help interoperability.
Changes to the API becomes a discussion of how the change affects multiple projects rather than "what cool new thing can we make Docker do"

Swarm maintainer here,
I am very happy about the engine-api split.
Swarm is currently using samalba/dockercient and it's extremely outdated, every time a new command/flag is merged in engine, we have to update samalba/dockercient.
Even worse, we aren't even notified.
When swarm-1.1.0-rc1 was released, it was incompatible with docker update and all the new networking flags like --ip or --alias because there is no way for us to see what's new in engine except by reading the changelog, that was produced with engine 1.10-rc1 (at the same time)
Hopefully we had time to fix during our "code freeze" period, but it's really not ideal.
Thanks to engine-api we are going to share:

the API types so they will always be up to date (--ip or --alias would have worked right away)
the API Client
In the future, the API server, so we now when a new endpoint is added (like docker update)

Well almost everything I wanted to say has been said, either by @icecrime or @dnephin 😻.

I think the split into engine-api is actually working extremely well. It's forcing us to consider API changes in isolation, which leads to more consistent and well thought out API design. It allows other projects which depend on the API to watch for changes and contribute feedback without the torrent of implementation-related changes in the engine.
We've just started this process, so I think it's normal there are some pain points. We should work on addressing them directly instead of abandoning the idea entirely.

+1000

integration-cli tests are part of the problem. If you test from the client you completely miss any API regressions. The client can cover up unexpected api changes. The end-to-end tests for engine should really be using the API directly, not the cli.

I couldn't agree more. That's a thought that is turning and turning in my head (both for docker/docker and docker/libcompose project), that all our integration tests are cli-oriented ; there should be way more API integration tests than cli's.
The docker/engine-api most certainly needs more maintainers (from docker/docker but most importantly from other project that actively depends on it — swarm, etc., soon libcompose and probably many other projects). And @cpuguy83 said it very well ; couldn't agree more.

Changes to the API becomes a discussion of how the change affects multiple projects rather than "what cool new thing can we make Docker do"

In short, I agree it appears a little bit more painful but in the long run, I really think it's gonna pay of !

@vdemeester in fact, we should probably use the engine-api client in our tests too unless necessary to use the binary client. The client itself has to be tested to make sure it does the right api calls.

Coming from using a third party Go client I'm a huge +1 for this.  It's very painful to try and keep up with the change (types and lack of support for X in the third party, etc).  Having a single client that is always in step reduces a tremendous amount of maintenance burden.

API testing and integration-cli testing are two different things. Before integration-cli, we only had API testing and testing done using internal APIs. Tests were passing and we still had lots of regressions between Docker versions. I don't see API based tests deprecating integration-cli.
I think these separate repositories have been useful when some projects had to evolve rapidly (libnetwork and distribution), but it's also a problem for projects which use these. I don't think we should merge these back in to the main repository for now, but we need to make sure we don't cause problems for downstream users of these packages and that we avoid problems for those who use them.

API testing and integration-cli testing are two different things. Before integration-cli, we only had API testing and testing done using internal APIs. Tests were passing and we still had lots of regressions between Docker versions. I don't see API based tests deprecating integration-cli.

Definitely, I didn't mean to suggest that integration-cli was completely unnecessary. It's still important to have some tests that cover the client behaviour, I was just suggesting that engine behaviour should be tested at the API level. There have been major regressions because of a lack of API level testing.
I was trying to suggest that having tests at different boundaries isn't test duplication, it's a necessity for complete test coverage.

There are good use cases for engine-api, as outlined above. But please do file issues for enabling Windows CI where it is not being run, and for "testing X is too difficult", these are definitely issues that need fixing.

Just random two cents.  The engine-api project immensely helps us (Rancher).  If it is a separate project as in github.com/docker/engine-api or in Docker as github.com/docker/pkg/engine-api makes little difference to me.  One possible thing I could think of is that currently docker as a A LOT of pkg/ projects that I use.  I could possibly see an issue in which I want a different version of the client, but not a different version of all the pkg/ projects.   For example, what I could see is that often we are conservative in bumping the client version (for most of our stuff we still use Docker 1.6 API) so we might want an old client but newer code from pkg/ for something else.  From that perspective I'd I lean toward a separate repo.
Another thing about separating repos is that because you have to change in two places and coordinate it makes people think a lot more about the impact.  This may have an advantage in that I feel like the API often changes too rapidly and people to easily break backwards compatibility.

engine-api has been moved back in, so I'll close this issue, but as always, feel free to comment


refactor(transformer): isolate babel options logic

#7034  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite


Add docs for UTO

Please describe the feature you'd like to see
Currently, the docs for the UTO are missing we should add them.

Add docs on reading the docs
Add a CI job to keep it up to date.

Docs structure

GCS -> Snowflake

Non-native
Native
Third-party

S3 -> GCS
Snowflake -> Bigquery
Bigquery -> GCS


Unexpectedly weird errors while compiling a project with opencv-rust

Operating system
Windows 11 Pro 21H2

The way you installed OpenCV: package, official binary distribution, manual compilation, etc.
Via chocolatey

OpenCV version
4.8.1

rustc version (rustc --version)
rustc 1.76.0-nightly (21cce21d8 2023-12-11)

I have attached the full log, but in short: very weird errors. I haven't been able to find anything at all about this. This error occurs with opencv bindgen, failing to run the bindings generator for every opencv module. This line keeps repeating (with some variations): c:/MinGW64/x86_64-w64-mingw32/include\stdlib.h:388:47: error: expected ';' after top level declarator. It seems as if I was using some weird compilator? I don't know. I tried both the msvc and the gnu target triple (for x64 Windows), both give the same error.

I think you haven't in fact attached the full build log unless I'm missing something

I think you haven't in fact attached the full build log unless I'm missing something

You're right - I uploaded the file, but for some reason it wasn't there. Thank you for the fast reply - it's attached now!

Looks like the stdlib headers are not processed correctly. I'm not sure how to help here to be honest and I've never tested build with mingw. There is also this warning that's very suspicious in the logs:
warning: "__STRICT_ANSI__ seems to have been undefined; this is not supported"

I also tried building with MSVC, but got the same errors (with the stdlib headers). It all feels like I made a mistake configuring all of this, but I retraced all of my steps and don't think I found anything wrong.

Sorry for bumping, currently facing the same issue. Any work arounds?

Are you using mingw on Windows too?

Yes, I am. My errors are equivalent to OP.


Fix oAuthPrompt Catch Block

Fixes #1054
Description
Per MDN, in JavaScript, the catch in try/catch blocks must have the exception statement (something like catch (err).
Specific Changes
Changes catch {...} to catch (e) {...}
Testing
All existing tests pass. I can add one for this, but that seems a bit overkill.

@cleemullins 	Per linked issue, looks like lots of OAuthPrompt users are running into this. Can we roll this into the next patch release?

Pull Request Test Coverage Report for Build 72166

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.8%) to 88.289%

Totals

Change from base Build 71693:
-0.8%

Covered Lines:
3535

Relevant Lines:
3846

💛  - Coveralls


[Task]: Fix path for cypress binary for running cypress test suite locally

Is there an existing issue for this?

[X] I have searched the existing issues

SubTasks
yarn install isn't able to symlink cypress binary to node_modules folder inside app/client folder. Thus a developer is unable to run yarn run cytest command to run the cypress test suite.
yarn install should ideally create a binary for cypress inside node_modules as it is added as a dependency in package.json file.
Currently, cypress may have been installed globally on developer system which might be getting invoked when a developer runs yarn run cytest.
A new developer who setups up their project from scratch won't be able to run the test suite locally since cypress binary is unavailable in node_modules folder inside client folder.
To find out if cypress is installed globally, run : npm list -g | grep -i cypress
Check this link for documentation of workspaces setup for npm packages : https://classic.yarnpkg.com/lang/en/docs/workspaces/
Sample project to demonstrate cypress binary working in workspaces setup
workspace-exp.zip

After merging this PR, cypress became available from the client folder. Therefore, I would suggest closing this ticket. But we definitely need to move cypress to packages so that everything works according to the general rules of the workspace. This way we can clear the root package.json from cypress dependencies, optimise the script launch for tests and make our code base a bit cleaner.
Let's get a separate ticket for this.
@rajatagrawal @SatishGandham

As per @KelvinOm 's comments, closing this ticket.


Upgrading to latest laravel

The current app is based on Laravel 5.1 upgrade it to latest 5.6

[ ] 5.1 to 5.2
[ ] 5.2 to 5.3
[ ] 5.3 to 5.4
[ ] 5.4 to 5.5
[ ] 5.5 to 5.6

would try this, if interested

@cracker182 you can work on the upgrade. Our end goal is to upgrade to latest laravel version. Have created the new branch "upgrade/laravel".


Using with shadowed items

Items with shadow in lazyrow causes weird shadow effect

second one is when fading edges is visible

Hi, can you share a piece of example of how are you using it? Also, try to change the FillType of .fadingEdges, because by default it uses Clip - which clips the child content by applying Xfer mask mode, maybe it causes some issues?

Hi, can you share a piece of example of how are you using it? Also, try to change the FillType of .fadingEdges, because by default it uses Clip - which clips the child content by applying Xfer mask mode, maybe it causes some issues?

Maybe it is, i will take a look

This still persists sadly(


Eliminate nullness errors from MongoDbIO

I didn't try to change the design. There are probably ways to redesign the internals a bit to consolidate the checks and get better messages. But as it is they would just be NPEs in random places, so this allows us to turn on the type checking that will protect any refactor from problems.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[x] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Yea I don't really know the IO other than the digging I did because I happened to be touching it. I believe I mostly just added annotations that were clearly necessary and checks that were also clearly necessary. And beyond that I trust the tests.

I did also potentially add some "setting to null" that will allow things to be GC'd, but not in a way that will matter.


fix: LEAP-444: Implement HTML sanitization in LSF monorepo

Hi @juliosgarbi!
This PR was created in a response to PRs in upstream repos:

https://github.com/HumanSignal/label-studio-frontend/pull/1651

closing this as monorepo was merged to develop branch


Install lwc server plugin via oclif hooks, adds the check to setup requirements

Overview
Now the setup for both platforms are set to test for the presence of lwc-dev-server plugin. If this is not found an attempt will be made to install the plugin.
This PR does the following.

Removes explicit dependency callouts for lwc-dev-server plugin.
Adds an oclif hook that installs lwc server plugin (if missing)
Adds a check for lwc server to the setup.
Moves the common requirement for both platforms to BaseSetup.
Moves come common code to CommonUtils.
Refactors tests to mock the oclif hook & the basic pass/fail scenario for the new setup requirement.

Oh one thing I see when I run preview in the adverse case, is an UnhandledPromiseRejectionWarning.  Not sure if it was there before?

$ sfdx force:lightning:lwc:preview -n helloWorld -p Android
This plugin is not digitally signed and its authenticity cannot be verified. Continue installation y/n?: n
›   The user canceled the plugin installation.
└─ Setup
├─ Failed: Error: Install the sfdx LWC server plugin.
├─ Passed: ANDROID_HOME is set to /Users/khawkins/Library/Android/sdk.
├─ Passed: Android SDK prerequisites are met.
├─ Passed: Android SDK tools were detected at /Users/khawkins/Library/Android/sdk/tools/bin.
├─ Passed: Android Platform tools were detected at /Users/khawkins/Library/Android/sdk/platform-tools.
├─ Passed: android-29 API package was detected.
└─ Passed: Android emulator image (system-images;android-29;google_apis;x86_64) was detected.
(node:86346) UnhandledPromiseRejectionWarning: lwc-dev-mobile: Setup for platform Android failed.
at Preview.run (/Users/khawkins/.local/share/sfdx/node_modules/@salesforce/lwc-dev-mobile/lib/cli/commands/force/lightning/local/setup.js:35:35)
(node:86346) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 5)
(node:86346) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Can you take a look?

@khawkins Im gonna merge this PR. It appears like the unhandled promise rejections may have been occurring before as well and it only surfaces up due to a user involved rejection. I am looking into it and will push a PR to address that issue.


docs: Fix outdated hyperlinks in documentation

Detail

Fix outdated hyperlinks in documentation, referring to old versions of the library
Fix broken labels in Jupyter Notebooks

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

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 435e9075156834bb799aa216dc91e50497df61ff
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: f0b2b35b1d413af45cb8a0bb740b9ad9ca824ccf
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 435e9075156834bb799aa216dc91e50497df61ff
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: f0b2b35b1d413af45cb8a0bb740b9ad9ca824ccf
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 411f144b8a0cad8c3a07cd7bab40a11514a8c429
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Create ecosystem proto and implementation changes

dotnet
cli
web (ts)

I will fix the java issues in a PR, hold on a minute. Do we have an SDK change request in for this set of changes?

You mean an issue? I don't think so. I'll make one.

You mean an issue? I don't think so. I'll make one.

https://github.com/trinsic-id/sdk/issues/759 <- thanks! Will do this as a set of PRs into this one, and we can merge all at once.


feat(expr): add array_sum

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
add array_sum & resolve #11996

Checklist

[ ] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[x] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

The current implementation only support Int16, Int32, Int64.
Though have tried many times, I could only come up with the current workaround, it's dirty and could definitely be refactored.
Also, seems that we should only support int, float, decimal for sum operation?
Any advice is welcomed!

The current implementation only support Int16, Int32, Int64.
Though have tried many times, I could only come up with the current workaround, it's dirty and could definitely be refactored.
Also, seems that we should only support int, float, decimal for sum operation?
Any advice is welcomed!

I have refactored the function with some type exercise tricks. 🤪

Is this supposed to be consistent with the agg version of sum? Note the return type is wider than input type for smallint, int, and bigint. See PostgreSQL and RisingWave.

Is this supposed to be consistent with the agg version of sum? Note the return type is wider than input type for smallint, int, and bigint. See PostgreSQL and RisingWave (the sum(int64) -> int64 variant is for 2-phase agg and should not be user visible).

Yes I think it's better to be consistent with agg.

I don't quite get the point how to be consistent with the sum in aggregation 🥺, should we also change to the two-phase building for array_sum just like agg?

I don't quite get the point how to be consistent with the sum in aggregation 🥺, should we also change to the two-phase building for array_sum just like agg?

I meant the user-visible behavior. We would like select ..., array_sum(arr), ... from ... where ... to be equivalent to select ..., (select sum(elem) from unnest(arr) as foo(elem)), ... from ... where ...
More specifically, array_sum(array[32767::smallint, 2::smallint]) shall return 32769 of bigint type rather than reporting smallint out of range error.

New version updated. Now it should be conform with the agg except Int256, seems that the return type of Int256 in the trait bound can not be satisfied 🤔?


Error message  when running cargo limit without neovim

I'm switching over to _cargo-limit-open-in-nvim, and I'm getting errors when I run cargo lcheck without having an nvim instance open.

These errors don't occur if I have an nvim instance open, which makes me suspect that cargo-limit is trying to open the neovim server socket when it doesn't exist.

Fixed, please run cargo install nvim-send


Improve UI & Add Responsiveness

Description
Improve UI & Add Responsiveness
Checklist

[x] I am making a proper pull request, not spam.
[x] I've checked the issue list before deciding what to submit.

Add relevant screenshot or video (if any)
After:
https://user-images.githubusercontent.com/80192140/193984486-eb6c4814-05db-473b-adf5-f963e4236db8.mp4

Hii @wasimreja , why did you close this pull request? Please Let me know if you want any changes.

current ui is better. leave it as is


Fix latest news in the news article template

There are some issues (with the query?) for the latest news list.
It doesn't seem to list 3 news articles and it should not list draft news

Are we not filtering out drafts in the querues?

Probably a couple of things since this was made ages ago and way before we added the read token :)

Also this one, do we not filter correctly on languages

news/20211201-stepping-up-fusion-investment

Should we also filter out articles that don't have all the content (like image and ingress)?

Hint for reviewing this, use this url slug locally: news/news-testing, dataset production.
Without the heroImage query:

without the languages' query:

after the fix:

Using the preview inside Sanity, lists the English latest news in the Norwegian page

Hi @wenche, I fixed the news in norwegian but it doesn't work when previewing inside the studio. I couldn't figure out why but seems to be working fine otherwise. If this is a "must" requirement I can do some more investigation. I will also add this as a point for the next sanity discussion


pagination: tab index

is it possible to tab to each item in the control and click enter to select, currently keyboard navigation is not working for me in chrome

not sure what I was doing, tab works


Updating the components

Change Type
Addition
Proposed Changes
Apologies if I missed it in the docs, but is there a section on what to do if components are updated? Since it's a CLI orientated system that essentially just imports components into your project -

What would you do if a bug is fixed or features are added to a particular component? Especially if you have made any custom modifications.

Is there some way to diff it?

At the moment, you have to diff it yourself manually. Since they are your components and there's no predicting what you might do with them, not sure if it's practical.
You could always re-add them and check the git diff locally to update anything that may have changed, or simply look at the updated components code.
Open to ideas if anyone has anything better. Just remember, this isn't 'supposed' to operate like a normal component library, more as a reference.

In the meantime, I will work on adding something to do the docs to explain that as I assume it'll be a common question.

Open to ideas if anyone has anything better. Just remember, this isn't 'supposed' to operate like a normal component library, more as a reference.

I guess for me, I am more concerned with bugs that may be fixed in the individual components, which I would like to push into my components, rather than custom attributes.
Maybe some way to keep track of the individual version of each component so you can at least tell if there are substantial updates or fixes to them?

Thinking out loud for a second:
Say that we provide an npx shadcn-svelte update command that will read the contents the components/ui (or whatever the user has specified in shadcn.componentPath) and check if the user's components need to be updated.
How do we differentiate between the currently up-to-date components and the user's current components?
We can't diff on the content of the files because of user defined formatting differences, as well as the possibility that the user may have already modified the files, so string diffing won't work.
What if we provide some kind of versioning to each component?
My first thought would be to add the versioning to the shadcn object in svelte.config.js, but I think that would quickly devolve into a mess the more components the user installs...
How about versioning on a per component basis where the index.ts of each component dir has an export for the version?
That might actually work, but I feel like we may be getting too deep into the weeds here. I'm not a particular fan of this either.
Perhaps the best solution may be the simplest? Have update read the child dirs of the specified componentPath, figure out which ones are shadcn components (I'm oversimplifying a little bit here), and overwrite them with the latest.
We'd have to provide a warning, as well as a [y/n] prompt, before continuing to overwrite the contents of those files, but I think this method would be easiest to implement and maintain.

We can't diff on the content of the files because of user defined formatting differences, as well as the possibility that the user may have already modified the files, so string diffing won't work.

Are you able to basically flatten or remove all tabs/spaces/formatting of both files so they are equivalent? (if the user hasn't actually added any content to the file)
Perhaps the best solution may be the simplest? Have update read the child dirs of the specified componentPath, figure out which ones are shadcn components (I'm oversimplifying a little bit here), and overwrite them with the latest.

We'd have to provide a warning, as well as a [y/n] prompt, before continuing to overwrite the contents of those files, but I think this method would be easiest to implement and maintain.

Honestly I'm fine with this


getting error ------  File "./tmdb", line 202, in main     for item in resultList['results']: KeyError: 'results'

Same as issue #1


Added unicode double slash in jsx props

Describe the bug
When non-English text is inserted in jsx props, it is changed to a Unicode string with two slashes added.
There are two slashes, so it is recognized as plain text.
Input code
const Test = () => (
  <div
    id="test"
    title="한글 테스트"
    data-test="丂"
    data-test2="тест"
    data-test3="😭"
  >
    한글 테스트
  </div>
)

export default Test;

Output code
import { jsx as _jsx } from "react/jsx-runtime";
const Test = ()=>/*#__PURE__*/ _jsx("div", {
        id: "test",
        title: "\\ud55c\\uae00 \\ud14c\\uc2a4\\ud2b8",
        "data-test": "\\u4e02",
        "data-test2": "\\u{442}\\u{435}\\u{441}\\u{442}",
        "data-test3": "\\u{1f62d}",
        children: "\ud55c\uae00 \ud14c\uc2a4\ud2b8"
    })
;
export default Test;

Config
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": true
    },
    "transform": {
      "react": {
        "runtime": "automatic"
      }
    },
    "target": "es2016"
  }
}

Version
The version of @swc/core: 1.2.59

duplicate issue #1782


cannot install hydrogen on linux mint

Description:
Cannot install hydrogen on linux mint 18.3
I wonder if anyone else experienced a same problem on linux.
It would be grateful if anyone could help me.  :(
Steps to Reproduce:
sudo apm install hydrogen
produces the following error at the bottom
Versions:
Which OS and which version of Hydrogen and Atom are you running?
You can get this information from copy and pasting the output of atom --version  from the command line.
Linux Mint 18.3
~ $ atom --version
Atom    : 1.22.1
Electron: 1.6.15
Chrome  : 56.0.2924.87
Node    : 7.4.0
Logs:
Please post any error logs and the output of the developer tools as described in our Debugging Guide.

<EMAIL_ADDRESS>install /tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/canvas
node-gyp rebuild

<EMAIL_ADDRESS>install /tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/zeromq
node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)

/tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor
└── (empty)
gyp ERR! configure error
gyp ERR! stack Error: EACCES: permission denied, mkdir '/tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/canvas/build'
gyp ERR! stack     at Error (native)
gyp ERR! System Linux 4.13.0-26-generic
gyp ERR! command "/usr/share/atom/resources/app/apm/bin/node" "/usr/share/atom/resources/app/apm/node_modules/.bin/node-gyp" "rebuild"
gyp ERR! cwd /tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/canvas
gyp ERR! node -v v6.9.5
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
module.js:471
throw err;
^
Error: Cannot find module '/tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/zeromq/scripts/prebuild-install.js'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3
module.js:471
throw err;
^
Error: Cannot find module '/tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/node_modules/Hydrogen/node_modules/zeromq/scripts/preinstall.js'
at Function.Module._resolveFilename (module.js:469:15)
at Function.Module._load (module.js:417:25)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:394:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:509:3
npm WARN enoent ENOENT: no such file or directory, open '/tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/package.json'
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^15.0.0 but none was installed.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^0.26.0 || ^0.24.0 but none was installed.
npm WARN apm-install-dir-118023-7250-jqk22i.3279vvlsor No description
npm WARN apm-install-dir-118023-7250-jqk22i.3279vvlsor No repository field.
npm WARN apm-install-dir-118023-7250-jqk22i.3279vvlsor No README data
npm WARN apm-install-dir-118023-7250-jqk22i.3279vvlsor No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/Hydrogen/node_modules/canvas):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>install: node-gyp rebuild
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1
npm ERR! Linux 4.13.0-26-generic
npm ERR! argv "/usr/share/atom/resources/app/apm/bin/node" "/usr/share/atom/resources/app/apm/node_modules/npm/bin/npm-cli.js" "--globalconfig" "/home/jeong/.atom/.apm/.apmrc" "--userconfig" "/home/jeong/.atom/.apmrc" "install" "/tmp/d-118023-7250-1cdnk7r.d7xi2xd2t9/package.tgz" "--runtime=electron" "--target=1.6.15" "--arch=x64" "--global-style"
npm ERR! node v6.9.5
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the zeromq package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs zeromq
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls zeromq
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /tmp/apm-install-dir-118023-7250-jqk22i.3279vvlsor/npm-debug.log
npm ERR! code 1

I am getting this same error on linux mint but the steps above did not work for me. Were there any permissions that you have to change?
Logs

<EMAIL_ADDRESS>install /tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/canvas
node-gyp rebuild

<EMAIL_ADDRESS>install /tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/canvas-prebuilt
node-pre-gyp install

404 status code downloading tarball https://github.com/chearon/node-canvas-prebuilt/releases/download/v1.6.0/canvas-prebuilt-v1.6.0-electron-v1.6-linux-x64.tar.gz

<EMAIL_ADDRESS>install /tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/zeromq
node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)

/bin/sh: 1: prebuild-install: Permission denied
Building libzmq for linux
/tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor
└── (empty)
gyp ERR! configure error
gyp ERR! stack Error: Python executable "/usr/share/atom/resources/app/apm/bin/python-interceptor.sh" is v3.6.4, which is not supported by gyp.
gyp ERR! stack You can pass the --python switch to point to Python >= v2.5.0 & < 3.0.0.
gyp ERR! stack     at failPythonVersion (/usr/share/atom/resources/app/apm/node_modules/node-gyp/lib/configure.js:454:14)
gyp ERR! stack     at /usr/share/atom/resources/app/apm/node_modules/node-gyp/lib/configure.js:443:9
gyp ERR! stack     at ChildProcess.exithandler (child_process.js:197:7)
gyp ERR! stack     at emitTwo (events.js:106:13)
gyp ERR! stack     at ChildProcess.emit (events.js:191:7)
gyp ERR! stack     at maybeClose (internal/child_process.js:877:16)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
gyp ERR!  System Linux 4.4.0-112-generic
node-pre-gyp ERR! command "/usr/share/atom/resources/app/apm/bin/node" "/usr/local/bin/node-pre-gyp" "install"
node-pre-gyp ERR! cwd /tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/canvas-prebuilt
node-pre-gyp ERR! node -v v6.9.5
node-pre-gyp ERR! node-pre-gyp -v v0.6.39
node-pre-gyp ERR! not ok
internal/child_process.js:313
throw errnoException(err, 'spawn');
^
Error: spawn EACCES
at exports._errnoException (util.js:1022:11)
at ChildProcess.spawn (internal/child_process.js:313:11)
at exports.spawn (child_process.js:380:9)
at buildZMQ (/tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/zeromq/scripts/preinstall.js:17:15)
at IncomingMessage. (/tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/node_modules/Hydrogen/node_modules/zeromq/scripts/preinstall.js:106:5)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)
npm WARN enoent ENOENT: no such file or directory, open '/tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/package.json'
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^15.0.0 but none was installed.
npm WARN<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>|| ^0.26.0 || ^0.24.0 but none was installed.
npm WARN apm-install-dir-11811-23884-q37t7h.7hqa9ssjor No description
npm WARN apm-install-dir-11811-23884-q37t7h.7hqa9ssjor No repository field.
npm WARN apm-install-dir-11811-23884-q37t7h.7hqa9ssjor No README data
npm WARN apm-install-dir-11811-23884-q37t7h.7hqa9ssjor No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/Hydrogen/node_modules/canvas):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>install: node-gyp rebuild
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules/Hydrogen/node_modules/canvas-prebuilt):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>install: node-pre-gyp install
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1
npm ERR! Linux 4.4.0-112-generic
npm ERR! argv "/usr/share/atom/resources/app/apm/bin/node" "/usr/share/atom/resources/app/apm/node_modules/npm/bin/npm-cli.js" "--globalconfig" "/home/joseph/.atom/.apm/.apmrc" "--userconfig" "/home/joseph/.atom/.apmrc" "install" "/tmp/d-11811-23884-z9vpsn.9p8rara4i/package.tgz" "--runtime=electron" "--target=1.6.15" "--arch=x64" "--global-style"
npm ERR! node v6.9.5
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the zeromq package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node scripts/prebuild-install.js || (node scripts/preinstall.js && node-gyp rebuild)
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs zeromq
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls zeromq
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /tmp/apm-install-dir-11811-23884-q37t7h.7hqa9ssjor/npm-debug.log
npm ERR! code 1


Add insertSpaceAfterConstructor Formatting Option

From https://github.com/Microsoft/TypeScript/issues/15960

To verify, try setting typescript.format.insertSpaceAfterConstructor and javascript.format.insertSpaceAfterConstructor" and verifying that spaces are inserted or not after the constructor keyword in js and ts files


--ongoing-- Data Sources Research

Temporary place to hold links and resources for data we need. TODO is move this into long term spot (google doc or wiki or website)

https://dc.gov/page/open-government


Upgrade core dependencies to 0.10.44, remove embulk-api, and upgrade embulk-util-config to 0.3.2

It updates the core dependencies to 0.10.44. Then along with that, it removes embulk-api as embulk-api is merged into embulk-spi in 0.10.44.
It updates embulk-util-config to the latest 0.3.2. No critical updates, though.

Thanks!

Due to removing guava from embulk-core(junit4?) in 0.10.39 and 0.10.40, guava dependency is necessary for the test explicitly. Correct?

Yes, Guava has been removed before v0.10.44, but these tests needed Guava. We can rewrite them not to use Guava, but only the test dependencies are not very serious. I may try removing them someday.


Fuzzing integration by way of OSS-Fuzz

Hi,
Would you be interested in integrating continuous fuzzing of dask by way of OSS-Fuzz? Fuzzing is a form of test-generation technique and has been used to catch many bugs in memory unsafe languages. There is currently efforts to fuzz more memory safe languages, and in this context I was wondering if you would be interested in getting Dask fuzzed?
In this PR I have integrated Dask with OSS-Fuzz: https://github.com/google/oss-fuzz/pull/7688 Specifically, created the necessary logic from an OSS-Fuzz perspective to integrate Dask. The first goal will be to increase the coverage to cover as much of the Dask code as possible. Down the line it is preferable to have the fuzzers upstream but it can be convenient to have on OSS-Fuzz to begin with.
Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid. The fuzzing set up on the OSS-Fuzz side relies on Atheris fuzzer (https://github.com/google/atheris) to perform the fuzzing.
If you would like to integrate, the only thing I need is as list of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. Notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.

@DavidKorczynski Thank you for sharing!
@jrbourbeau @jcrist What do you think?

Thanks for opening this @DavidKorczynski, and apologies for the delayed response.
While I think fuzzing is a useful strategy, dask doesn't have a lot of surface area where fuzzing makes sense IMO (and places where it does we often already do have some form of randomized tests). The functions covered in your initial PR already have excellent test coverage in repo, and the fuzz-tests there don't test correctness, only for lack of errors. I (personally) don't see a large benefit from having dask fuzz tests in an upstream repo, which will increase maintenance costs for both our team and the OSS-fuzz project.

Thanks for being understanding (and for doing all this work). I have no problem with you doing work external to the dask project, please let us know if you find any bugs!  Closing.


window is not defined in mock example [bug]

Describe the bug
When i try to run the mock example i get the error  window is not defined.
Reproduction

Create new Tauri Project react-ts
Add vitest and try to run the Mock example: https://tauri.app/v1/guides/testing/mocking

Expected behavior
Test to run without error
Platform and versions
npm run tauri info

<EMAIL_ADDRESS>tauri
tauri info

Environment
› OS: Linux Mint 21 X64
› Node.js: 18.12.0
› npm: 8.19.2
› pnpm: 7.25.0
› yarn: 1.22.19
› rustup: 1.25.1
› rustc: 1.65.0
› cargo: 1.65.0
› Rust toolchain: stable-x86_64-unknown-linux-gnu
Packages
› @tauri-apps/cli [NPM]: 1.2.2
› @tauri-apps/api [NPM]: 1.2.0
thread '' panicked at 'called Result::unwrap() on an Err value: Error("unexpected end of input while parsing minor version number")', src/info.rs:502:41
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Stack trace
ReferenceError: window is not defined
    at /media/cedu/Main/Projects/TestVitest/src/Test/example.spec.ts:10:5
    at /media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-chain.4e2aa823.js:2336:26
    at /media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:286:59
    at Array.map (<anonymous>)
    at callSuiteHook (/media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:286:47)
    at runSuite (/media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:454:39)
    at runFiles (/media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:613:11)
    at startTestsNode (/media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:631:9)
    at /media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/entry.js:103:11
    at Module.withEnv (/media/cedu/Main/Projects/TestVitest/node_modules/vitest/dist/chunk-runtime-setup.56d71d30.js:168:5)

Additional context
No response

by default vite's test runs in a nodejs environment which doesn't have access to window/navigator. You need to set environment to jsdom (or maybe happy-dom if that works for your frontend) https://vitest.dev/config/#environment - iirc you also need to install the jsdom package for that to work.
afaik the configuration of test frameworks is out of scope for our guide

Ahh thanks a lot. Totally missed that.


changing to cookie cutter templating

Adding new templating for this, in order to change the values in a cookie-cutter project. Test with $ cookiecutter https://github.com/itsbenweeks/template-mit-demo.git --checkout cookie-cutter
Addresses #2.

Looks like there is an issue with j2 and tex commands, see #5.

Looks like my latest commits haven't made their way to this PR. Going to close and resubmit.


Folder background color in database navigator

Would be great, that connection folders will be colored for differenting for example PROD/ACC enviroments or whatever user wants

Thanks for the feature request.
We can change the folder background based on its contents. For example, if all connections inside a folder use the same connection type (e.g., production or development), that folder will use the same background color as its children.

Hello, I do not know, how do you mean it, but by me it is not as you wrote

It's not implemented yet. I'm proposing a possible solution.

Oh, I am sorry, I understood it badly. I mean, it is partialy tha i asked, but will be better to set independently to children

Thanks for mentioning that. We will see what can be done.


TypeError: class must have base classes

any transcompiled simple (empty) python class, raising same error:
TypeError: class must have base classes

to reproduce the issue, create a python file with below code, then transcompile, and run:
class c:
    pass

it is happening because of a sanity check here, anyway it needs more investigation to see why base class is empty there.

@trotterdylan any comment on this?

Classes without a list of bases are old style classes, and Grumpy doesn't current support them. I've debated whether to bother supporting old style classes since Python 3 gets rid of them.
Unfortunately there are subtle behavioral differences between new and old style classes so we can't just pretend to support them by replacing the empty list of bases with (object).
For modules that use old style classes, I've just been modifying the code to add the object base class and hoping that they continue to work correctly.

@trotterdylan thanks! I'll try to do same for the modules.


[Bug Fix]: Improper Access Control in seaport-js via Undici

Component
Other (please describe)
Have you ensured that all of these are up to date?

[X] seaport-js
[X] Node (minimum v16)

What version of seaport-js are you on?
5.28.3
What function is the bug in?
fetch()
Operating System
Linux
Describe the bug
The project ProjectOpenSea/seaport-js was used Undici is an HTTP/1.1 client, written from scratch for Node.js. An attacker can alter the integrity option passed to fetch(), allowing fetch() to accept requests as valid even if they have been tampered. I Requested for Patch on #540
  const list = parsedMetadata.sort((c, d) => d.algo.localeCompare(c.algo))
  // get the strongest algorithm
  const strongest = list[0].algo
  // get all entries that use the strongest algorithm; ignore weaker
  const metadata = list.filter((item) => item.algo === strongest)

    if (actualValue === expectedValue) {
      return true
    }

    let actualBase64URL = crypto.createHash(algorithm).update(bytes).digest('base64url')

    if (actualBase64URL.endsWith('==')) {
      actualBase64URL = actualBase64URL.slice(0, -2)
    }

    if (actualBase64URL === expectedValue) {

Impact
CVE-2024-30261
CWE-284
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N

Hi! @JoshuaSchmidt-OpenSea @ryanio can you please check my reports on 27f52911-be32-48f4-aebb-afbcbd2ec313 on bugcrowd platform, because i still waiting opensea staff to respond
Best regards,
hackerone.com/sufatmawati


proposal: support restful  API to trigger chaos

A friendly HTTP API can be very helpful to use chaos-mesh. We can support APIs such as  triggr request
POST /api/v1/network
{
     "type":"partition",
     "source":"<IP_ADDRESS>",
     "target":"<IP_ADDRESS>",
     ...
}

how to trigger chaos?  How does the HTTP API look like?
Can you provide more information?

I believe this should be part of the new chaos-dashboard backend.

I believe this should be part of the new chaos-dashboard backend.

Yes, it should be 👍

We also need to give a design proposal for the APIs(what really do we need)

@yeya24 I have remove the good first issue. We will design for this. Once the design proposal is over, we will add the label good first issue again