qBraid-SDK migrations

Migrate the following functions and classes (+ corresponding tests) from qbraid to pyqasm:

depth()

rebase() (and all associated helpers)

extract_qasm_version() (don't mask "opaque")

QasmStringType, Qasm2StringType, Qasm3StringType

qasm3_drawer() (This function needs a lot of work done. We will need to refactor it to leverage the openqasm3.ast explicitly, and from there perhaps, limit its scope to just OpenQASM 2 strings until it is stable enough to safely begin expanding to OpenQASM 3. This could be a great issue to turn over to the broader open-source community for help.)

qas2_to_qasm3() (maybe)

Possibly more to come, but this should be a good start.
Create a dev branch for qBraid-SDK, add pyqasm as a dependency, and for each of the above functions/classes that are migrated, import/replace with the appropriate pyqasm function/class in the qBraid-SDK. Open draft PRs across the qBraid-SDK and pyqasm repos so that we can review the updates in parallel.
Note: If things begin to get cluttered, we may want to discuss creating pyqasm sub-modules to distinguish different "families" of functions / operations, e.g. core, typing, passes, etc. But we also don't want to do so pre-maturely, before the project has had a chance to gain it's footing. Otherwise we may set ourselves up for re-factors early on, which we don't want.
In qbraid-qir[qasm3] we plan to maintain the dependency open openqasm3[parser] even after we integrate pyqasm. By contrast, the ultimate goal that this issue begins to work towards is to move openqasm3 from a core to an optional dependency within the qBraid-SDK, and to replace any critical functionality implemented using openqasm3 with equivalent out-of-the-box functionality provided via pyqasm.
For example, we hope to eventually refactor bloated logic surrounding calculations of number of qubits / classical bits in OpenQasm2Program and OpenQasm3Program and move streamlined versions of these functions into pyqasm. We hope to eventually remove functions like unfold_qasm2() and replace them with simple calls to pyqasm.unroll(). Similarly, we hope to replace functions like decompose_qasm2() with pyqasm.rebase() from the function linked above (pending migration). Eventually, we would like to dissipate all of qbraid.passes, and sort these functions into appropriate modules, handlers, and/or helpers in pyqasm or within the qBraid-SDK.
Pending candidate functions up for migration may also include:

has_measurements()
remove_measurements()
others? (TBD)

[!IMPORTANT]
Amidst all of these migrations, we want to be careful to only migrate things into pyqasm which are generic enough to also be useful to a "3rd party". Any helpers that provide functionality that is noticeably specific to qbraid, we should instead look to re-locate / reorganize somewhere else within the qBraid-SDK, wherever it is best suited.

The "ethos" of this project, in my mind, is to offer a concise, focused, and well-documented set of highly practical functions and methods to help users analyze and interface with OpenQASM programs. Overall, the package should be lightweight, fast, straightforward, user-friendly, and clear in both its purpose and utility. Anything that detracts from that, we leave out.

Breaking this off into several sub-issues as the PR #49 is getting pretty big.

I'm a little skeptical about the development of an in-house qasm3_drawer as, once unrolled, the program can be easily visualized by the qiskit drawer which has become a lot more robust.
Maybe we can think of visualizing some higher level representation instead of the qubit level that gives a better sense of how the program is evolving. I'm coming from a place where looking at the circuit level drawing I can not understand what the program "is doing".
A functional-level or a basic block level drawer would be much more useful which highlights "what a particular block of quantum instructions are doing" rather than just being present as a circuit, which is hard to interpret.
It could start off as a simple "highlighter" where in we take the quantum circuit representation and demarcate what is the "use" of a block of circuit operations.
Eg. -

@ryanhill1 let me know if this is something which you think would worth exploring. As you mentioned, it'll be nice to see the open-source community pitch in on this.

Turns out qiskit's drawer already supports something like this -
import qiskit

print(qiskit.__version__)
# 1.2.0

program = """
    OPENQASM 3.0;
    include "stdgates.inc";

    input float[64] a;
    qubit[3] q;
    bit[2] mid;
    bit[3] out;

    let aliased = q[0:1];

    gate my_gate(a) c, t {
      gphase(a / 2);
      ry(a) c;
      cx c, t;
    }
    gate my_phase(a) c {
      ctrl @ inv @ gphase(a) c;
    }

    my_gate(a * 2) aliased[0], q[{1, 2}][0];
    measure q[0] -> mid[0];
    measure q[1] -> mid[1];

    while (mid == "00") {
      reset q[0];
      reset q[1];
      my_gate(a) q[0], q[1];
      my_phase(a - pi/2) q[1];
      mid[0] = measure q[0];
      mid[1] = measure q[1];
    }

    if (mid[0]) {
      let inner_alias = q[{0, 1}];
      reset inner_alias;
    }

    out = measure q;
"""
circuit = qiskit.qasm3.loads(program)
circuit.draw("mpl")

Output -


Activity 1: Your First Caption

Using the API, I have just created a file with a random octocat for you to caption. In this activity, we will learn how to make changes to files in our GitHub repository.

[ ] @JackySze388
[ ] @JustinPong
[ ] @WinsonLiGeneration
[ ] @harry33321
[ ] @shunfu1996
[x] #15
[ ] @E11IEss
[ ] @Sing0424
[ ] @YUEN-YU-WING
[ ] @gabriel888chow
[ ] @ianklfong
[ ] @jolam-developer

hi


Sample doesn't seem to build

Steps to reproduce :scroll:

Build ExoPlayer project
then ExoPlayer (develop) sample

Expected behavior :thinking:
Build run/test
Actual behavior :bug:
Compile failures around ExoPlayer.Demo::EventLogger.cs
internal sealed class EventLogger : Object, IPlayerEventListener, IAudioRendererEventListener,
	IVideoRendererEventListener, IAdaptiveMediaSourceEventListener,
	ExtractorMediaSource.IEventListener, DefaultDrmSessionManager.IEventListener,
	MetadataRenderer.IOutput

ExoPlayerXamarin/Samples/Official Demo/EventLogger.cs(68,68): Error CS0246: The type or namespace name 'IAudioRendererEventListener' could not be found (are you missing a using directive or an assembly reference?) (CS0246) (ExoPlayer.Demo)
ExoPlayerXamarin/Samples/Official Demo/EventLogger.cs(3,3): Error CS0246: The type or namespace name 'IVideoRendererEventListener' could not be found (are you missing a using directive or an assembly reference?) (CS0246) (ExoPlayer.Demo)
ExoPlayerXamarin/Samples/Official Demo/PlayerActivity.cs(65,65): Error CS0535: 'PlayerActivity' does not implement interface member 'IPlayerEventListener.OnTimelineChanged(Timeline, Object, int)' (CS0535) (ExoPlayer.Demo)
ExoPlayerXamarin/Samples/Official Demo/EventLogger.cs(46,46): Error CS0535: 'EventLogger' does not implement interface member 'IPlayerEventListener.OnTimelineChanged(Timeline, Object, int)' (CS0535) (ExoPlayer.Demo)
Configuration :wrench:
Version: 2.x
Platform:

[ ] :robot: Android

The sample use Xam.Plugins.Android.Exoplyer 2.5.2, so you could download sample from here: https://github.com/martijn00/ExoPlayerXamarin/releases
Then, download the 2.5.2 Source code,  I test on my side, it works fine.

Smashing! thanks


APP packet name length

Hello,
there is a problem with the names of the APP packets. API guide states the following:

When in fact, any name that is longer than 3 characters results in name corruption. For example, a packet named "123" produces:

whereas packet named "1234" produces:

In the rtcp_app_packet declaration the name is represented as

So it is converted to an array with a length of [4] and is probably null-terminated, because the function takes char pointer
 rtp_error_t send_app_packet(char *name, uint8_t subtype, size_t payload_len, uint8_t *payload);

So I guess this is the intended behaviour with a misleading API guide. But I think that 3 characters long names are a bit short.
Either the API should be fixed, or the names allowed to be longer, API fix is easier tho :)
p.s also when converting the name from the app packet that we receive back to char*, it becomes non null-terminated.

Hello,
there is a problem with the names of the APP packets. API guide states the following:

When in fact, any name that is longer than 3 characters results in name corruption. For example, a packet named "123" produces:

whereas packet named "1234" produces:

In the rtcp_app_packet declaration the name is represented as

So it is converted to an array with a length of [4] and is probably null-terminated, because the function takes char pointer

I'm actually not convinced there is a problem. When looking at the spec (RFC 3550), 4 is the correct length for the name

Then, when looking at the name

I get the impression that you are supposed to use all 4 bytes for your name and not less. How uvgRTP handles this is just assume there are 4 characters there and copies them (this could probably be handled better, but it works in context of the specification.) This means that 123 will have the null-termination even though it is not supposed to have it. In case of 1234, it is copied without the null-termination, but this is actually correct, since the termination is not supposed to be there. In other words, when printing the name, you should not assume it is null-terminated, because it is not supposed to be.

 rtp_error_t send_app_packet(char *name, uint8_t subtype, size_t payload_len, uint8_t *payload);

You are right, that the char* in the API is a misleading. (I vote for handling this with the C++ API at some point).

So I guess this is the intended behaviour with a misleading API guide. But I think that 3 characters long names are a bit short.
Either the API should be fixed, or the names allowed to be longer, API fix is easier tho :)

The length is specified by the RFC, so it cannot be increased. The API should probably be improved in some way.

p.s also when converting the name from the app packet that we receive back to char*, it becomes non null-terminated.

I'm not super familiar with C, but maybe you should use a conversion function that adds the null-termination.


Add Tron address interface

Fix #221

could you please also remove swift/Sources/Addresses/TronAddress.swift? Let's use wallet core's implementation

Done


Automatically update our dependencies using dependabot

Description of problem and opportunity to address it

Context to understand the problem
We maintain a lot of tools in this repository that have dependencies. Remembering to update them for security or bugfix reasons is often not at the top of our to-do lists and only gets there as a result of a wider problem.
Proposed solution
Dependabot is a tool (supported by GitHub) that can watch select package ecosystems for upgrades to listed dependencies and generate PRs to bump them over a given frequency. The generated PRs come with changelogs and can be managed using a range of @dependabot commands (that are also explained in the PR) and we can choose to ignore a given dependency bump if needed.
What's the value and who would benefit
We would no longer need to "remember" to make PRs like this https://github.com/2i2c-org/infrastructure/pull/1005 while still retaining flexibility on when we upgrade.
Dependabot also tracks more than just Python dependencies! It can also bump GitHub Action versions, terraform modules, and Docker base images https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#package-ecosystem
Implementation guide and constraints

[ ] We should decide if we want to implement this kind of auto-bumping of dependencies and for which package ecosystems
[ ] If the above is agreed, add a .github/dependabot.yaml file with the appropriate config to enable the updates

Updates and ongoing work
No response

I'm +1 on this in theory, but have one concern to figure out: my experience with dependabot in other repositories is that it tends to generate a decent amount of noise. Maybe this is less of a problem for us because we don't have a ton of dependencies, but I've seen a lot of repositories with large numbers of un-merged dependabot PRs for patch versions and such. To that extent, what if we also adopt a practice like:
Any dependabot PR that bumps a minor or patch version should be merged quickly by any team member, so long as the tests are passing. For major version bumps, we should notify the @2i2c-org/tech-team and give a day or two for others to respond before merging.

This will require to believe in our testing infrastructure, but I think that this is a target we should be shooting for anyway).
This also reminds me I need to figure out that "PR is open, somebody merge it" alert bot again :-)

You can set the frequency for when it checks. In my projects I set it to check weekly to reduce noise. But you could set it to run on a specific day of the week if you wanted. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#scheduleinterval
There is also an ignore.update-types key that can be used to ignore patch or minor bumps if that's what we would prefer. https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#specifying-dependencies-and-versions-to-ignore

I am +1 on trying this out and seeing how it goes. If it feels noisy we can revisit it later on.

Another thing we can do is phase in dependabot for different ecosystems, since it will always be noisy when you first add it. So an example strategy could look like:

Add dependabot config that just looks at Python deps
Wait for Python deps to settle
Add dependabot config that just looks at GitHub Actions deps
Wait for GHA deps to settle
etc...

Let's experiment in the iterative fashion you proposed above...
I have also experienced really noisy behavior in the past and I am usually reluctant to use it since then 😛

For what it's worth, the places where I've seen dependabot be the most annoying are in JavaScript worlds where there are seemingly 10,000 dependencies for every project, and they all make patch releases every 15 minutes. 😅 hopefully we wouldn't have as much of an issue with that here

Ok, I will make a PR to enable dependabot just for the Python dependencies in our docs folder later today. Why the docs folder? Our docs get tested/built regularly by readthedocs so we should quickly know if we run into issues.

Sorry, I ended up not having time to make the PR yesterday, but it's here now! https://github.com/2i2c-org/infrastructure/pull/1022
After we merge it, I recommend we monitor for 4 weeks (so 4 runs of the bot) and then reassess.

Adding a note here to remind myself that this should be documented here too https://team-compass.2i2c.org/en/latest/practices/styleguide.html (And should maybe be renamed when that change happens)

yeah I realized that in another project as well - so we should probably use a different requirements file to test this out with, I don't think dependabot will ever open a PR against a requirements file with no pins right?

I think that is true, yeah

either works for me - thus far, for Python packages I haven't found dependabot to be annoying, especially if you don't ask it to make PRs for patch versions.

I opened a new PR to swap to GitHub Actions https://github.com/2i2c-org/infrastructure/pull/1037

Wondering if we should pin those dependencies 🤔.

I'd be plus one on that. Better to know when your deps are changing than letting them define themselves. Even if it's "only" docs.

I realised I had let this go a little bit stale, so here's another PR to start tracking our pip dependencies https://github.com/2i2c-org/infrastructure/pull/1332

Topics to discuss to follow-up this issue:

Dependabot for Python is quiet because we don't pin a lot - should we?
We can also bump terraform modules, but that often comes with issues around deprecated attributes, etc. We could do one of the following:

Implement terraform module bumps with dependabot and define a process where an engineer is assigned to review the PR making sure nothing like deprecated attributes would break it on merge. Either open an issue or implement a fix if it would.
Do nothing.

With terraform, if we bump we'd also have to terraform apply across all our workspaces. So my inclination is to not.

Agreed, but we can also run into unforeseen toil if we have to do this the next time we touch the terraform config. So one thing we could do is, from a project management POV, always allocate extra time to a task that touches terraform in case such an issue crops up. (People are always mad you're overdue but happy that you're early!)

@damianavila Here's a scenario I'm imagining:

There's a task on our backlog that involves adding some "feature" to our terraform config
In the process of adding said feature, some terraform module needs bumping and that causes issues, like attributes being deprecated/changed
This results in a new PR that is not addressing the original task and also has to be applied across all clusters
This is extra toil that we cannot reliably forecast when we scoped/assigned the original task - you don't know it's coming until you bump the module
So when assigning a terraform-related task to someone we give them, say, one-week extra than we scoped the task for just in case the above scenario arises

I think we can close this issue once we reach consensus on the above.

I am usually in favor/biased towards pinning requirements.

I've not read through this issue, but here are three strategies for three situations that I've come to appreciate:

dependabot for bumping referenced github actions' versions in a repo's .github/workflows
pre-commit.ci for bumping .pre-commit-config.yaml referenced pre-commit hooks
using a github workflow/job to re-freezing pip installable dependencies for docker images in a requirements.txt file, based on a requirements.in file, using the tool pip-compile

requirements.txt pinning?
Based on a comment in chat I think it could be relevant to also to provide input if we should pin requirements.txt in this repo - it is used as a declaration of the python dependencies needed for the deployer script.
I think this is reasonable at least if we have experienced or expect to see the CI/CD pipeline crash due to bugs in the dependencies over time. If so, then I think a good approach is to use requirements.in + requirements.txt and refreeze requirements.txt in a way that z2jh's does: using pip-compile run from within a docker container. See this logic and the README.md in this folder.

We already have dependabot setup to watch requirements.txt files, it just wasn't generating any PRs since none of the packages listed in our requirements files are pinned:
https://github.com/2i2c-org/infrastructure/blob/04b6501f700b99d2c70d2d62ab21241afed7e039/.github/dependabot.yaml#L33-L44
Given https://github.com/2i2c-org/infrastructure/issues/1559, I just went ahead and pinned stuff: https://github.com/2i2c-org/infrastructure/pull/1561

Given @damianavila's comment in https://github.com/2i2c-org/infrastructure/pull/1583#issuecomment-1203305618, and the fact that there are other pkgs in the hub image apart from oauthenticator for which we install an unreleased version, I was wondering if we could setup depandabot for that Dockerfile too?
@sgibson91, I believe you mentioned some time ago automating these upgrades, but I don't remember the context exactly and I'm trying to figure out if I should open a new issue to track this?

I don't think dependabot will be able to bump OAuthenticator in the Dockerfile. dependabot only really bumps the base image, i.e., FROM image:tag-to-bump. I also don't think my actions can bump things in Dockerfiles either, only YAML configs, so I was probably referring to bumping the image referenced here in basehub's values: https://github.com/2i2c-org/infrastructure/blob/f35d06d5d61dcc58b1f4d5bd32a03ed48b64c0e5/helm-charts/basehub/values.yaml#L353-L355

@GeorgianaElena I'm going to recommend a new issue for further discussion around your topic and close this one given that #1561 was merged. We can iterate in a new issue on dependabot/pinning generally if folk think it is needed.


Optimize object allocation when using readObjectOrNull and readClassA…

…ndObject
Motivation:
yourkit shows there is a high object allocation when using readObjectOrNull and readClassAndObject, we can replace it with int / kv of strings for headers which shows much better performance.
Modifications:
Replace readObjectOrNull and readClassAndObject with simple type checks and serialization methods if possible.
Result:
Higher throughput.

Benchmark                                                     Mode  Cnt       Score      Error  Units
CustomKryoSerializerTest.testSerializeDeserializeHeadersNew  thrpt  100  620239.983 ± 6840.181  ops/s
CustomKryoSerializerTest.testSerializeDeserializeHeadersOld  thrpt  100  302015.556 ± 4107.025  ops/s

!!! This changes the wire format of messaging (not compatible with previous versions of Orbit).


FileUpdater failed in many repositories

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
.NET
Package manager version
No response
Language version
.NET 8
Manifest location and content before the Dependabot update
Projects in the pattern src/{ProjectName}/{ProjectName}.csproj
dependabot.yml content
version: 2
updates:
- package-ecosystem: nuget
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 1000
  groups:
    AWSSDK:
      patterns:
        - "AWSSDK.*"
    NServiceBusCore:
      patterns:
        - "NServiceBus"
        - "NServiceBus.AcceptanceTesting"
        - "NServiceBus.AcceptanceTests.Sources"
        - "NServiceBus.PersistenceTests.Sources"
        - "NServiceBus.TransportTests.Sources"
  ignore:
    # Particular.Analyzers updates are distributed via RepoStandards
    - dependency-name: "Particular.Analyzers"
    # Changing these 3 dependencies affects the .NET SDK and Visual Studio versions we support
    # These types of updates should be more intentional than an automated update
    - dependency-name: "Microsoft.Build.Utilities.Core"
    - dependency-name: "Microsoft.CodeAnalysis.CSharp"
    - dependency-name: "Microsoft.CodeAnalysis.CSharp.Workspaces"
- package-ecosystem: "github-actions"
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 1000

Updated dependency
No response
What you expected to see, versus what you actually saw
Expect Dependabot to run without errors, but here are some examples of error blocks where the FileUpdater failed. I don't know if all are the same error, but I know that these are different from https://github.com/dependabot/dependabot-core/issues/8537 which is also an issue for us in repos that have central package management.
From https://github.com/Particular/NServiceBus.Transport.AzureServiceBus/network/updates/777192726:
updater | 2024/01/22 15:38:24 ERROR <job_777192726> Error processing Azure.Messaging.ServiceBus (Dependabot::DependabotError)
updater | 2024/01/22 15:38:24 ERROR <job_777192726> FileUpdater failed
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:38:in `run'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/dependency_change_builder.rb:26:in `create_from'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:128:in `check_and_create_pull_request'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:60:in `check_and_create_pr_with_error_handling'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `block in perform'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `each'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `perform'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:128:in `run_ungrouped_dependency_updates'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:63:in `perform'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:45:in `run'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:43:in `perform_job'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:37:in `run'
updater | 2024/01/22 15:38:24 ERROR <job_777192726> bin/update_files.rb:24:in `<main>'

This stack trace seems to be repeated in other repos:

https://github.com/Particular/NServiceBus/network/updates/777209595
https://github.com/Particular/NServiceBus.RavenDB/network/updates/776827269
https://github.com/Particular/NServiceBus.RabbitMQ/network/updates/777294982
https://github.com/Particular/NServiceBus.AzureFunctions.Worker.ServiceBus/network/updates/777297634
https://github.com/Particular/NServiceBus.AmazonSQS/network/updates/777300461
A few internal repos, but I assume the public ones are easier for troubleshooting?

In any case, it's not every repository in our organization, for example NServiceBus.SqlServer seems unaffected, but it seems to be hitting quite a lot of them.
We've also sporadically seen this stack trace, here from https://github.com/Particular/NServiceBus.AzureFunctions.InProcess.ServiceBus/network/updates/777297591:
updater | 2024/01/22 18:47:25 INFO <job_777297591> Sending event 0dcc0447e8d84e50b6b04b64b7c5f4e1 to Sentry
  proxy | 2024/01/22 18:47:25 [968] POST https://sentry.io:443/api/1451818/store/
  proxy | 2024/01/22 18:47:25 [968] 200 https://sentry.io:443/api/1451818/store/
updater | 2024/01/22 18:47:25 ERROR <job_777297591> Error processing NUnit (NoMethodError)
updater | 2024/01/22 18:47:25 ERROR <job_777297591> undefined method `fetch' for nil:NilClass
updater |
updater |           latest_version: preferred_resolvable_version_details.fetch(:version)&.to_s,
updater |                                                               ^^^^^^
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/nuget/lib/dependabot/nuget/update_checker.rb:47:in `updated_requirements'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/nuget/lib/dependabot/nuget/update_checker.rb:101:in `updated_dependencies_after_full_unlock'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/common/lib/dependabot/update_checkers/base.rb:61:in `updated_dependencies'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:99:in `check_and_create_pull_request'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:60:in `check_and_create_pr_with_error_handling'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `block in perform'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `each'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/update_all_versions.rb:35:in `perform'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:128:in `run_ungrouped_dependency_updates'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater/operations/group_update_all_versions.rb:63:in `perform'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/updater.rb:45:in `run'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/update_files_command.rb:43:in `perform_job'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> /home/dependabot/dependabot-updater/lib/dependabot/base_command.rb:37:in `run'
updater | 2024/01/22 18:47:25 ERROR <job_777297591> bin/update_files.rb:24:in `<main>'
updater | 2024/01/22 18:47:25 INFO <job_777297591> Checking if Microsoft.NET.Test.Sdk 17.8.0 needs updating

That one can also be found in:

https://github.com/Particular/NServiceBus.AwsLambda.Sqs/network/updates/777302060

Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

@DavidBoike ; is Dependabot working now for you?

A few repos seem to be fixed but most are still having problems.
Here are updated URLs with failed runs from the last few minutes:

https://github.com/Particular/NServiceBus.Transport.AzureServiceBus/network/updates/779002907
https://github.com/Particular/NServiceBus.RavenDB/network/updates/779003876
https://github.com/Particular/NServiceBus.RabbitMQ/network/updates/779003898
https://github.com/Particular/NServiceBus.AzureFunctions.Worker.ServiceBus/network/updates/779003912
https://github.com/Particular/NServiceBus.AmazonSQS/network/updates/779003924

We've done some more analysis and the problem in our case is that the updater cannot currently handle MSBuild property conditions that have a property mapped in single quotes, in a way that's pretty idiomatic for MSBuild files.
This PR from my colleague @bording fixes it though, please take a look: https://github.com/dependabot/dependabot-core/pull/8913

Thank you so much for digging into this and submitting a fix; I should have it merged soon!

This is now merged and deployed; I hope it fixes the issue; thanks so much.


Material tabs

Replaced TabWidget with customized sliding tabs (#662), removed holo-style headers
Screenshots - http://imgur.com/TWDqTQO,QsE21M9

Looks good.
I'm not sure about the tab indicator style/color though. It just doesn't have good contrast to the view below it IMHO.

@fadils I see what you are saying. I've increase the elevation to have a bigger shadow.

Is this better or you think we should change the selected indicator color?

Here's another option

Increased elevation looks better than blue indicator color IMHO.
Indicator color has good contrast with tab backgroung (white vs dark) while elevation shadow adds additional diversity between tabs and content

@atermenji I agree. Since elevation is not supported on older versions, I've implemented a generic solution that looks the same. Curious to know what @fadils thinks.

@mustafa01ali, same with @atermenji, I don't really like the blue indicator either.
But, I was thinking about creating a clear separation with a good contrast about this.
Then, I came up with this.

Well, I guess now we have options.

@fadils personally, I think that elevation and shadow is mostly used in cases like this.
Let me explain my thoughts:
Since the tab background has deep dark color, tab text and indicator need to have contrast and white color fits the best. On the other side main content has also white background.
From what I've seen so far in other apps, they use 2 options in this case:

Fill indicator with a different, third color, like red or blue or something else which finds place in other places of an app. Like 1 of 3 main app colors
Place shadow/elevation below, like @mustafa01ali  did

Anyway, I'm not a regular UX/UI designer, so I can not provide the best option and this is a thing of discussion.
Do you have some examples from other apps with bottom padding for indicators?

as an example here is a screenshot from my Contacts app:

As you can see, it has almost the same case as ours, and it has a shadow elevation.
Indicator height is also smaller there but I'm not certain if it is a must in latest guidelines.

@atermenji Thanks for your elaboration. I was just voicing another option, which in my personal opinion is better than shadow.
Looking at how other apps do it, I guess shadow is the way to go. =)
I'm not a regular UX designer too, so this is up for discussion.
My inspiration to get to that option:

However, when it's scrolled up, then it uses shadow, which is closer to what @mustafa01ali did and what you suggested earlier:

@atermenji @fadils Good discussion, this was my inspiration while implementing the tabs -

So if you guys agree on the white indicator with shadow, we can merge this PR as it has that implementation.


update: remove russian version of feature-parity table

If you don't figure out what problem with CI, then approve this pr

It appeared that our current docs infrastructure just doesn't have this feature of cross-language includes.


BustAim incompatible with Weapon-Config (or the other way around)

BustAim can't be included after Weapon-Config is included, or else it'll give the following error while compiling.
../pawno/include\BustAim-AntiAimbot\BustAim.inc(467) : error 021: symbol already defined: "OnPlayerGiveDamage"

Including it ABOVE weapon-config does allow the gamemode to compile, but I am not sure if it breaks anything.

I think weapon-config does not allow the usage of OnPlayerGiveDamage. IIRC, it provides its own equivalent callbacks.

You're right, there is an equivalent callback.
On Tue, Oct 31, 2017 at 3:34 PM, Yashas<EMAIL_ADDRESS>wrote:

I think weapon-config does not allow the usage of OnPlayerGiveDamage.
IIRC, it provides its own equivalent callbacks.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/YashasSamaga/BustAim-AntiAimbot/issues/7#issuecomment-340781171,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACx8xmLsCGSjZVwqvgRA-5SLHkZLFRduks5sxy_agaJpZM4QKXbG
.

This might work (I replaced the ALS redefinition from OnPlayerGiveDamage -> OnPlayerDamage)
public OnPlayerDamage(playerid, Float:amount, issuerid, weapon, bodypart)
{
    BustAim_g_IntrnlPlayerSettings{issuerid} |= PREVIOUS_SHOT_DID_DAMAGE;
	#if defined BustAim_OnPlayerDamage
		return BustAim_OnPlayerDamage(playerid, Float:amount, issuerid, weapon, bodypart);
	#else
		return 1;
	#endif
}

#if defined _ALS_OnPlayerDamage
#undef OnPlayerDamage
#else
#define _ALS_OnPlayerDamage
#endif

#define OnPlayerDamage BustAim_OnPlayerDamage

#if defined BustAim_OnPlayerDamage
	forward BustAim_OnPlayerDamage(playerid, Float:amount, issuerid, weapon, bodypart);
#endif


Error creating content when "revalidate" is enabled

I was following this to enable revalidation for a content type: https://next-drupal.org/guides/on-demand-revalidation
But after enabling, when I tried to create a new content, the Drupal site shows me this:
The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: Plugin ID 'Invalid preview url generator.' was not found. in Drupal\next\Entity\NextSite->getPreviewUrlForEntity() (line 173 of modules/contrib/next/src/Entity/NextSite.php).
Drupal\next\Plugin\Next\SitePreviewer\Iframe->render(Object, Array) (Line: 129)
Drupal\next\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 164)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 49)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Do you know how to resolve this?

Can you confirm if you've configured a plugin for the preview url generator at /admin/config/services/next/settings?

@shadcn Thank you! I did not. And I configured one and now it works.


How can I get the angle of the text created by model.Text()?

export function getTextModel(font, caption, font_size) {
  const model = new makerjs.models.Text(font, caption, font_size);

  model.layer = DrawLayerNames.Caption;

  const model_extents = makerjs.measure.modelExtents(model);

  return [model, model_extents];
}

const [caption, caption_extents] = getTextModel(font, `H: ${H}`, render_options.font_size);

  caption.origin = [
  // some origin
  ];

  makerjs.model.rotate(caption, /* some angle*/, caption.origin);

How can I find out how rotated the text is in another part of the program?

Hello, one thing to note is that your drawing is a plain object to which you can add your own properties:
caption.rememberMyRotation = 55;

Properties not used by Maker.js will remain untouched. Hope that helps.

Hello, one thing to note is that your drawing is a plain object to which you can add your own properties:
caption.rememberMyRotation = 55;

Properties not used by Maker.js will remain untouched. Hope that helps.

Ohhhh(
This decision was one of the first in my head) But I thought that maybe someone solved the problem in a different way.
My attempt to solve the problem without adding my own properties:
export function getCircumscribedRectangleAngle(model) {
  const { center, width, height, high } = makerjs.measure.modelExtents(model);

  if (width >= height) {
    const rightMiddle = [high[0], center[1]];

    return makerjs.angle.ofPointInDegrees(center, rightMiddle);
  } else {
    const topMiddle = [center[0], high[1]];

    return makerjs.angle.ofPointInDegrees(center, topMiddle);
  }
}

Has the development of the library stopped? A similar method would be very useful)

I figured out why it doesn't work with slanted lines) Since the makers.measure.model Extends method returns the described rectangle, there are only 4 possible angles.


AD Dashboards hook up with OSD 2.0 see 400 bad request issue

Describe the bug
Hook up AD Dashboards with OSD 2.0 see the following error:
{"statusCode":400,"error":"Bad Request","message":"[request body]: expected value of type [any] but got [undefined]"}

To Reproduce
Run OpenSearch 2.0 with AD engine 2.0
Clone AD Dashboards current main (v1.3) to OpenSearch Dashboards plugins folder
Modify packages.json (delete the packages that have the compatibility issue):
"@testing-library/jest-dom": "^5.11.4",
"@testing-library/react": "^11.0.4"

Change opensearchDashboardsVersion to 2.0.0 in opensearch_dashboards.json
Run yarn osd bootstrap and yarn start in OpenSearch Dashboards
Expected behavior
No issue
Plugins
AD

Issue is due to this line here
After typescript upgrade, Dashboards use a more restrict type check.  For the get API from AD, we could see body is null.

Body null is transformed to undefined in the type check in the dashboards. Then, type undefined is no longer acceptable from type any by restricter type check.
There are two ways to change:

Seems request body is always null in get API. Could delete L64.
Change to body: schema.nullable(schema.any()),

Both would solve the issue.


raise self.error

[ERROR] Exception encountered in worker thread:
  File "/usr/local/lib/python2.7/site-packages/pykafka-2.3.1-py2.7.egg/pykafka/producer.py", line 526, in queue_reader
    self.producer._send_request(batch, self)
  File "/usr/local/lib/python2.7/site-packages/pykafka-2.3.1-py2.7.egg/pykafka/producer.py", line 406, in _send_request
    response = owned_broker.broker.produce_messages(req)
  File "/usr/local/lib/python2.7/site-packages/pykafka-2.3.1-py2.7.egg/pykafka/broker.py", line 286, in produce_messages
    return future.get(ProduceResponse)
  File "/usr/local/lib/python2.7/site-packages/pykafka-2.3.1-py2.7.egg/pykafka/handlers.py", line 65, in get
    raise self.error

kafka version is kafka_2.11-<IP_ADDRESS>

Hi @ToniYang, thanks for filing this. Mind supplying any additional information about this error, including code samples, kafka broker configurations, and/or a more thorough explanation of when and where you're seeing this traceback? Without that information this will be pretty tough to debug. Thanks!


Added Cloudflare to the list of sites.

This patch is intended to add Cloudflare to the list of sites.
Here are the references used to create this patch:

https://support.cloudflare.com/hc/en-us/articles/200167776-How-do-I-cancel-or-downgrade-my-CloudFlare-account-
Experience from deleting my own Cloudflare account a while ago.

I'm assuming https://support.cloudflare.com/requests/new is just a general support request form? Does it have a specific option to request account deletion, or does that need to be mentioned in that form?

The category of the request should probably be set to Account as there is no specific option for account deletion. Because of that, requesting account deletion needs to be mentioned in the message body.
Shall I add a commit to add this information to the notes?

Yes please! Besides that detail, this looks good.


BUG: number of PRs in Code-Review is 5

For Prow and GitHub, we're only looking at the last 5 commits. We used to look at 30 commits.
I don't think this is intentional.
Reproduce via:
go run . --repo=https://github.com/bhuvi11/ecom-service --checks Code-Review --show-details --format json | jq
{
  "date": "2021-09-08",
  "repo": {
    "name": "github.com/bhuvi11/ecom-service",
    "commit": "bb5488c6b99bcbb0954bf5cb7b569068c1cf89fb"
  },
  "scorecard": {
    "version": "",
    "commit": ""
  },
  "checks": [
    {
      "details": [
        "Info: Gerrit code reviews found for 0 commits out of the last 30",
        "Info: Prow code reviews found for 0 commits out of the last 5"
      ],
      "score": 10,
      "reason": "GitHub code reviews found for 5 commits out of the last 5 -- score normalized to 10",
      "name": "Code-Review",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/main/docs/checks.md#code-review",
        "short": "Determines if the project requires code review before pull requests are merged."
      }
    }
  ],
  "metadata": null
}

@azeemsgoogle I suspect this was introduced thru the CodeQl change, so assigning to you for now.

This is because there aren't enough merged PR commits for Scorecard to analyze in this repo. When you try it on a different repository, you can see that 30 commits are being analyzed:
./scorecard --repo=https://github.com/ossf/scorecard --checks Code-Review --show-details --format json | jq
{
  "date": "2021-09-21",
  "repo": {
    "name": "github.com/ossf/scorecard",
    "commit": "bc5d7a8d4b6e8ae268ff94e75dda3082566d30e8"
  },
  "scorecard": {
    "version": "2.2.3-45-gbc5d7a8",
    "commit": "bc5d7a8d4b6e8ae268ff94e75dda3082566d30e8"
  },
  "checks": [
    {
      "details": [
        "Info: Gerrit code reviews found for 0 commits out of the last 30",
        "Info: Prow code reviews found for 0 commits out of the last 30"
      ],
      "score": 10,
      "reason": "GitHub code reviews found for 30 commits out of the last 30 -- score normalized to 10",
      "name": "Code-Review",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/bc5d7a8d4b6e8ae268ff94e75dda3082566d30e8/docs/checks.md#code-review",
        "short": "Determines if the project requires code review before pull requests (aka merge requests) are merged."
      }
    }
  ],
  "metadata": null
}


Add syntax highlighting for code blocks

Uses the rehype-prism plugin which uses the Prism syntax highlighter.
I added a stylesheet link to the default Prism color theme. There are other Prism color themes that we can choose from.

This still needs work and I'm considering switching to rehype-highlight instead.


Plex Connection On Demand + Now Screening no images.

Greetings!
Attempting to configure Plex to show On Demand items from my library. While I do see both features working as far as pulling both On Demand shows/Showing items that are currently being played I can't seem to get any art work to load.
I have tested my configuration for Plex in a number of different fashions including https on https off, 443, 32400, hostname, ip address etc but none seem to allow the poster/art to load properly. There are no immediate errors in my logs after restarting however using the Debug feature On Demand test do see the following error:
PM *On-demand - title retrieval: Error: Plex Server didnt respond with a valid 2xx status code, response code: 404
I am running this on an unRAID system in a Docker container. PMS is on the latest version and running the latest version 1.16.2 of posterr.
Thanks!

D'oh well patience or lack there of (even though did see the change slide mentioned in FAQ) seems to be the trick.
I've left posterr up in an open tab and slowly but surely I am starting to see art work populate.
Apologizes for the unneeded pings/notifications! I am curious though is this something that will have a cache be created once I have setup and over time or is this based on the individual client browser. Thanks again for the awesome app!

What exactly did you do to get this to work?

Couple hours later and mine started working on its own.


North American Phone number format

A clear and concise description of what you want to happen.
Please add support for North American Phone number format.
North American phone numbers are usually written in one of the following formats:
(123) 234-5678
123-234-5678
Other less commonly used formats are:
123 234 5678
123.234.5678
The format being mandated right now is +1-123-456-7890, which nobody would write in North America.
In general too, the country code would be less likely to be written on a resume since one would usually have a local number in the geography they're applying for.

Thank you.
I have added a new option to the data model: locale_catalog.phone_number_format
It's set to national by default, which formats the phone number exactly how you would like. It looks at the country code and formats accordingly, using the Python port of Google's libphonenumber, phonenumbers.

Thank you. I tested it out and it looks great!

The new functionality is released with v1.13.


About visualization

当我使用您的代码进行可视化时，输出这样的结果，并没有可视化的界面出现，请问您知道是什么原因吗？期待您的解答！
When I use your code for visualization, the output is like this, and no visual interface appears. Do you know the reason? Looking forward to your answer!
(polarnet) miao@dongtintech-rtx2080ti:~/Music/CENet-main$ python visualize.py -w kitti -d /home/miao/Music/PolarSeg-master/data/ -s 08
********************************************************************************
INTERFACE:
Dataset Type kitti
Dataset /home/miao/Music/PolarSeg-master/data/
Sequence 08
Predictions None
ignore_semantics False
ignore_safety False
offset 0
********************************************************************************
Opening config file of KITTI
Sequence folder exists! Using sequence from /home/miao/Music/PolarSeg-master/data/sequences/08/velodyne
Labels folder exists! Using labels from /home/miao/Music/PolarSeg-master/data/sequences/08/labels
WARNING: Although tkinter is already imported, the tkinter backend could not
be used ("Could not import Tkinter or pyopengltk, module(s) not found.").
Note that running multiple GUI toolkits simultaneously can cause side effects.
Using semantics in visualizer
/home/miao/anaconda3/envs/polarnet/lib/python3.7/site-packages/vispy/gloo/texture.py:28: UserWarning: GPUs can't support floating point data with more than 32-bits, precision will be lost due to downcasting to 32-bit float.
  warnings.warn(F64_PRECISION_WARNING)
To navigate:
        b: back (previous scan)
        n: next (next scan)
        q: quit (exit program)

Hi. I recheck this part in my case. Look like it's no problem in Windows.
Some key environments: python: 3.6.12 vispy: 0.9.4 matplotlib: 3.3.3
Maybe you should check this part of warning:
WARNING: Although tkinter is already imported, the tkinter backend could not
be used ("Could not import Tkinter or pyopengltk, module(s) not found.").
Note that running multiple GUI toolkits simultaneously can cause side effects.

感谢你的回复！这对我很有帮助！我在安装pyopengltk后解决了问题！
Thank you for your reply! This is very helpful for me! I solved the problem after installing pyopengltk!

Great to hear that！

请问为什么，用自己的算法生成验证集上的预测标签时，在可视化时，调色方案会是下图这样呢？
请问如何设置才能让产生的预测标签颜色与下图（直接查看ground truth）配色方案一样？ 期待您的回复~

You can check this part of color map(color_dict) which from semantic-kitti.yaml.
https://github.com/huixiancheng/CENet/blob/d9f2339c689d695d3ab304c601423c845a5dc543/visualize.py#L149-L153
By the way, I think it's unlikely that the color table is wrong, it's very likely that you have a problem with the label or label mapping(See this part). https://github.com/huixiancheng/CENet/blob/d9f2339c689d695d3ab304c601423c845a5dc543/modules/user.py#L214-L215

I am also running the code on the linux system but there is no pop-up window. After installing the pyopengltk library, the problem has not been addressed. Can I refer to your library directory?

您好，请问如何可以获得图中右侧两个图片中的预测mistake标记图呢？期待您的回答，感谢！

Please refer to issue #18.


FR: Migrate to shared Keychain without clearing signed in user

Feature proposal

Firebase Component: Auth

Currently migrating to a shared Keychain means clearing the current user. For an app in production with thousands of MAU, signing out all of those users to migrate their keychain.
Would it be possible to move the login tokens from a non-shared keychain to a shared keychain, as it seems possible to move in the other direction.

Any update on this? Is this even theoretically possible or not?

Hey Will, sorry for the slow response. As far as I know this should be possible, but we haven't gotten around to evaluating/scheduling this work.

Ah ok no worries. I only ask because I have 1000s of active users, and forcing them all to log in again is not ideal.

I am also interested in this since we have around 100k+ active users, and the worst part is they are mostly anonymous.

Hey @morganchen12 is there any update on this? My app has grown to over 20k users and I can't make them all log in again, but switching the keychain would be awesome

I have made a quick fix. It seems to work, but I think it will cause some problems when users try to logout, since the logout will happen on the shared keychain, and a user will still be logged in in the private keychain.
Right after initializing the library, add this code.
let tmpUser = Auth.auth().currentUser

Auth.auth().shareAuthStateAcrossDevices = true

do {

    try Auth.auth().useUserAccessGroup("XXX.my.app.id")
} catch let error as NSError {
  print("Error changing user access group: %@", error)
}

if let oldUser = tmpUser {
    if Auth.auth().currentUser?.uid ?? "" != oldUser.uid {
        // this happens when we migrate from unshared keychain to a shared keychain
        Auth.auth().updateCurrentUser(oldUser)
    }
}

I believe I've tried very similar code and it didn't survive after an app reboot

The 'fix' for #10582 forces our users to log out because a new key is created. I'm hoping that we can find a fix/mitigation similar to this request that will let us upgrade to Firebase 10.5.0+ without logging our users out.

cc: @ncooke3

Any update on this?


Feature/flow reorder strategies

Problem:
Static elements cannot be dragged on the canvas.
Fix:
Allow dragging static elements, it triggers reorder between sibling static elements. Based on https://github.com/concrete-utopia/utopia/pull/2494
Reordering from block to inline-block is possible with converting the element's display prop. If the display prop would be set to the default it is removed instead.
There are 3 strategies offered to the user on drag as the intention can be quite different:

automatically convert when inserting to rows
no conversion, keeps the original display prop
restrict reorder to only the display type the element has

Improvements for the future: insert into the end of row is not working currently, workaround is to use the same-type restricted strategy, and later support for style 'flow: right', dragging relative elements should allow setting the offset.
Commit Details:

new strategy type
strategy helper functions to find the new position and new display type
new command to convert to block and inline-block
2 new canvas controls:

dragged outline differently colored for block and inline elements
for reorder restricted to rows(inline) or columns(blocks) shows target area with striped background on sibling elements

new metadatautil: isPositionedByFlow
3 basic tests

Test it on this project: https://utopia.pizza/project/03ed1611/?branch_name=feature-flow-reorder-strategies

minor thing - but this looks off


Can this sdk support to use my own server to host  my data instead of using firebase?

I want to connect my app to my own server , in order to save data on my own host, instead of firebase.
Because in my country, it is a big problem to connect to firebase service.
Thanks for your replay in advanced.

Unfortunately, this isn't possible with the Firebase version of the app. If you want to do that, you should use the XMPP version of the project. With this version you can run the messenger using the open source eJabberd server. This project is scheduled to be released in several weeks.


chore(release): v1.3.0 🎉

:robot: I have created a release beep boop
1.3.0 (2024-03-15)
Features

extract: simplify extracting tasks from sqs events (75a6891)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ehmpathy/simple-async-tasks/releases/tag/v1.3.0 :sunflower:


Single jar

Need to get rid of several jar in release.
A single jar which detects an operating system and dispatches to an appropriate launcher would be good.

Fixed.
Revs. a1e069164610f675fc5896a29b175ca9269ae118, 5deafe3ffcd3b815617cad1105e6b740a3b73861


Expose tls_root_certs in Client constructor

TODOs:

[x]  update integration test documentation

@zen-dog Thanks for the review! We changed the config param, but left the tls_root_certs behavior for now. Maybe setting the existing env variable for grpc is sufficient for Aura.

 [PF] Find out flaky python client


Propose a new, externally accessible faucet endpoint

This PR proposes a new /drip endpoint, which could be externally accessible for the users, as requested by https://github.com/paritytech/opstooling/issues/172
It introduces a new configuration option EXTERNAL_ACCESS. If it's disabled, there should be no changes to the behaviour of the backend. It is disabled by default.
If it's enabled, it creates a new endpoint which is rate-limited by IP address of the requester.
The PR also introduces a new docker-compose file which can be used to spin up a new, seperate faucet with separate funds. That way, we require no changes to existing faucets - they can continue to not expose any ports and any risks would be limited to this new deployment of the faucet.
What would be next
If we decide to continue going this way, I would be adding changes such us request sanitization or limiting daily total limit of faucet payouts.
In this PR I tried to make minimum viable changes.
Also I would think about resetting the IP limit more frequently, e.g. once per hour. Because if two developers would be trying to drip on the same wifi they wouldn't be able to for the whole day.

Closed in favor of https://github.com/paritytech/substrate-matrix-faucet/pull/192


Incorrect overall status when failing to save a tracked reference

See original issue on GitLab
In GitLab by [Gitlab user @tristanvb] on Jan 11, 2018, 11:03
If there is an error in the child tracking task, it is handled properly.
If on the other hand tracking completes successfully, and we fail to rewrite the file on disk (can be reproduced by removing write permission from the .bst file and it's parent directory), then we just print a message telling the user that we failed.
What we fail to do (and this applies to any failure in a Queue implementation in the main process):

Report overall failure state message (last log line still says SUCCESS)
Report the appropriate -1 exit code (automated scripts cannot check for this kind of failure)

In GitLab by [Gitlab user @tristanvb] on Jan 11, 2018, 13:41
mentioned in commit b07ca524ec2c24575425b58ff96416bd92e38ba0

In GitLab by [Gitlab user @tristanvb] on Jan 12, 2018, 07:21
mentioned in commit b97c526bfaaf6beedfa8b5b550926a009be33c03

In GitLab by [Gitlab user @tlater] on Jan 25, 2018, 14:11
mentioned in commit 600b75bf30e9a34d15ed2af035ea09b803bc0648

This should be re-verified and tested before BuildStream 2.0

This is verified and tested in tests/frontend/track.py::test_track_error_cannot_write_file()


can i get millisecond in time() format?

time(char *fmt) - Print formatted time
when I use time function,can I get millisecond information?

Seems like strftime doesn't support this. Seems quite difficult to implement b/c we'd have to work around strftime.

I do think having ms/us is useful for the new strftime() call, it should be accurate enough to support atleast ms resolution

cc @ember526

Related PR: #1387

I'll think about it. Though not sure how accurate we can make it.

I Wrote simple code for my time format，It's enough for me.
char *mi="%f";

if (strstr(timestr,mi)) {
  std::string my_string(timestr);
  struct timeb tp;
  ftime(&tp);
  bpftrace->str_replace(my_string,mi,std::to_string(tp.millitm));

  bpftrace->out_->message(MessageType::time, my_string.c_str(), false);
  return;
}

I suppose the issue here could be that: time() can only get its timestimp from userspace when the runtime gets the chance to print it  instread of from BPF the exact moment the event occurs. It's not very clear to me if we can rely on it to offer the precision of millisecond. It might be misleading if we let it give an ouput that is not reliable.


Add proxy settings to octokit for main branch

Related Issue: https://github.com/open-cluster-management/backlog/issues/14015
Description of Changes
This fix was already delivered to the 2.4 branch. Just delivering the same fix to main so the branches are in sync.

Add proxy options to octokit

Originally I tried to do what console did in https://github.com/open-cluster-management/console/pull/943 which is to use proxy-agent but kept getting ProxyAgent is not a constructor so I switched over to https-proxy-agent. It looks like proxy-agent actually uses https-proxy-agent internally so perhaps this way it will have a smaller footprint.
Verification on ocp-bm-e20-h31-0

@fxiang1 Closing this. console-api FF has not been turned off yet, so I FF-merged release-2.4 to main instead so that FF continues to work from main. Only console, grc-ui, and grc-ui-api are currently in dual-stream PR mode.

Yep sounds good. Thanks @KevinFCormier


feat(ftux): refactored status page

Updated ftux git routes:

before: /create/git/:appId/status
after: /apps/:appId/git/status

Changed the logic for how we present operations on the status page.  Now we fetch all the resources within an account and then grab the latest operation that we are care about.
Did a design pass on the status page to match figma spec.

We use date-fns inside the src/date package.  All date utilities should be exported from there and then consumed by other packages.  This makes it easier for us to swap-out the date library if needed.

misread the date file diff (it obscured import on cli) : https://github.com/aptible/cloud-ui/blob/main/src/date/index.ts
LGTM


Fixes #20 licenses => license

Reminder to @cfpb/front-end-team-admin: CC0-1.0 should be used for all our stuff going forward instead of CC0. See https://spdx.org/licenses/.

So we can remove LICENSE from, e.g., cfgov-refresh?

Nah, that file should stay but whenever we programmatically reference our CC0 license (e.g. when it's in a package.json or bower.json manifest) we should use use the text "CC0-1.0" to be SPDX-compliant.


Make awesomplete instance awailable on input element

Having Awesomplete instance available in events as this.awesompelete will handy.
Discussed here https://github.com/LeaVerou/awesomplete/issues/16821#issuecomment-185706841
// in all event handlers:
var me = this.awesomplete;

me.ul.children[me.index]; // selected <li> DOM node
me.suggestions[me.index]; // selected suggestion item

// and so on...

How about a WeakMap on Awesomplete? Then to get the instance you'd do something like Awesomplete.inputs.get(element).
Also, if we do end up making Bliss a dependency, we can add it to element._.

We've discussed WeakMap before. I thought it wasn't an option for the nearest future with current support in browsers. https://github.com/LeaVerou/awesomplete/issues/16821#issuecomment-186079588

As long as it's not used internally, people can always choose whether they want to use it or not and take the reduced browser support (or include a polyfill).
I’m not against having features with different browser support if it's clearly indicated in the docs.
We would, however, need to check for it before using it, to avoid breakage in environments where it's not supported.


Add roles to authors

Add the option to add author roles that will be printed left of their name and affiliation. This is useful when writing a thesis and needing to add the supervisor(s) to the title page.

Look into adapting the author-info-blocks and scholarly-metadata lua filters for this.
Another option is a _authors.tex partial.
I am currently not sure which of these would be easier to implement.


February newsletter

Summary
It's time to draft the next AutSPACEs newsletter!
Deadline
February 28th
What needs to be done?

select topics
draft newsletter
review
send out

Who can help?
Add updates in comments below or in the #autspaces Slack!

topic to include: the SSI blog post about our first round of user testing! https://www.software.ac.uk/blog/user-testing-citizen-science-platform

I've added it in the draft: https://hackmd.io/8NujwtJsRDm6yZlmklG9EA

I'll send DM a reminder prompt Monday or Friday for the spotlight interview too

Newsletter has been send out without the interview feat. DM, will be put in the next newsletter instead.
The newsletter is also archived on GH & on the new wordpress newsletter


Randomly failing test detected

Failed tests:   doesNotTimeOutBeforeTimeoutReached(competitive.programming.timemanagement.TimerTest)
Tests run: 17, Failures: 1, Errors: 0, Skipped: 0
In the first build, I got this error and second build passes.

Should be OK now. It's not easy to deal with timing tests...If you have suggestions to enhance, don't hesitate!

No solutions but get some ideas. In short, with a 1000$ server, it still takes 30 nanos to call System.nanoTime(), so don't try to measure anything which could last less than 30 nanos.
http://shipilev.net/blog/2014/nanotrusting-nanotime/
https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks


Output binding for blob storage needs documentation for path substitution

On this page, we see "path": "samples-workitems/{queueTrigger}" but there is no indication as to where the queueTrigger value is coming from.  Or how to change it.
For example, can I somehow set aribitrary values in my function to be injected into the path?  "path": "{containerName}/{queueTrigger}".  How would I set the containerName value?
Perhaps a new guid?  "path": "samples-workitems/{guid}". How would I set the guid value?

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

ID: 910d4732-bb08-d16a-a932-19c6bd1628c2
Version Independent ID: af4358c7-cb5c-bdc7-6433-289f47dc186b
Content: Azure Blob storage output binding for Azure Functions
Content Source: articles/azure-functions/functions-bindings-storage-blob-output.md
Service: azure-functions
GitHub Login: @craigshoemaker
Microsoft Alias: cshoe

@tehyatt All triggers and bindings support binding expressions, which is what you see in the examples here.

Excellent, thanks. I had been reading lots of documentation pages about binding parameters to the function inputs and outputs but couldn't find this. Thanks again!


request:  Upgrade http dependency to match ^1.0.0

Is there an existing feature request for this?

[X] I have searched the existing issues.

Command
My project use http: ^1.0.0
flutter install

Description
flutterfire_cli ^0.3.0-dev.19 requires http ^0.13.5
Reasoning
Would like to add this package as project dev dependency.
Additional context and comments
No response

If you want to make a PR, I will take a look @EArminjon 🙏

Super, ty :)


Handle invalid BJData optimized type, fix #3461

This patch should fix #3461. Tested both with the fuzzer unit and the unit-test.

Please update to the latest develop branch (we renamed some folders in #3462).

Coverage remained the same at 100.0% when pulling 96bf1433f0eaa799ddc8098e799e1dcb95733282 on NeuroJSON:fix3461 into 0c698b75ccb81c2218e0b0b3ae8e9e60ba97c6bb on nlohmann:develop.

Thanks!


MRG, BUG: Fix M/EEG topomap plotting

Closes #3987
Closes #4880
Closes #5190
Closes #5471
Closes #5472
Closes #6304
Todo:

[x] ensure our montages actually use the same head sizes (done by dig refactoring)
[x] Make the plot_sensors be in physical coordinates
[x] make all code assume a 0.095 m head radius
[x] check that all examples in gist are fixed
[x] deprecate params: transform in montage, outlines, ...
[x] get tests to pass again
[x] change to sphere rather than head_radius for consistency and flexibility
[x] change units in setup_volume_source_space for consistency
[x] move head relative to MEG sensors based on info['dev_head_t']
[x] check plot_topomap, plot_sensors, montage.plot examples via circle full
[x] add setup_volume_source_space param and layout deprecation to API section of latest.inc

cc @jona-sassenhagen @sappelhoff @cbrnr you might be interested in this plan.
After this, due to using physical units for the head, #5471 should be simpler.

That is indeed a lot of refactoring! Great work, I will test it during the weekend!

Also I realized the most consistent API is to have a "sphere" argument allowing you to specify the origin and reading of the sphere. We have this elsewhere and I think in auto mode for digitized EEG locations it will look better.
But feel free to test that things are fixed. The sphere functionality would be a superset of this functionality, and I don't think the defaults will change from what's there now (essentially 0, 0, 0 origin and 9.5cm radius).

Here are the [circle full] outputs:
https://16870-1301584-gh.circle-artifacts.com/0/dev/index.html
One setup_volume_source_space example was broken on that run but fixed in 9c0525c (probably not interesting from an evaluate-whether-or-not-this-works perspective)
There are several examples that are broken, though, so I'll fix those. I think it has to do with loading a layout when it should use the _auto_topomap_coords function instead.

Okay, docs built
https://16891-1301584-gh.circle-artifacts.com/0/dev/index.html
CIs happy other than a small problem with Travis that I just pushed a commit to fix

this example looks a bit weird:

head outlies are not where they should be.

BTW is extrapolate 'local' by default now? (it looks so in the example)

BTW is extrapolate 'local' by default now? (it looks so in the example)

Even worse, I had some debugging cruft in there that made it always use local. Pushing a fix for projs topomap plotting now. But hopefully the rest of the examples look okay.

Many many thanks for tackling this.  A few comments:

in this image it seems like the EEG electrodes don't get as close to the edge of the head as they should.  I thought the idea was that if a sensor were in the plane of the fiducials, it should fall on the edge of the head outline, yet even what looks like electrode Iz (which ought to fall below the fiducial plane right?) is still well away from the edge

here in a few calls to Layout.plot() the outline is missing.

A question: what is the new deciding factor for whether to do a scalp topography with or without skirt?  For example in the ICA tutorial, the corrmap plots do not have skirts, but ICA.plot_components(), ICA.plot_properties(), and evoked.plot_joint() all do have skirts on this PR (whereas on current master only evoked.plot_joint() has skirts).

note that I didn't come close to looking at all the tutorials or examples so don't consider this a thorough review.  I can make time to do that if it's needed.

also strangely this ERP plot is now flat, whereas it's not on master

yet even what looks like electrode Iz (which ought to fall below the fiducial plane right?) is still well away from the edge

No electrodes have z<0:

aud_epochs.average().pick_types(meg=False, eeg=True).plot_sensors(kind='3d')

I don't aesthetically like this contraction, but it seems to be a more true depiction of the channel positions.
Using sphere='auto' (which changes the flattening origin and radius) you see something probably closer to what you'd expect:

here in a few calls to Layout.plot() the outline is missing.

This is intentional. The idea is that:

head outlines are only shown only if info['chs'] positions are used, typically in topomap plots
layouts are schematics to be used only in interactive sensor selection and also topo-style plots for better separation of sensors, and should never be plotted with a head outline because it's potentially misleading about the geometry / head-to-sensor relationship.

A question: what is the new deciding factor for whether to do a scalp topography with or without skirt?

Whatever old defaults there were should remain unchanged in this PR (that's the goal anyway!). What I did was that, regardless of which skirt you choose, it will always plot at least out to all the electrode positions. So for things like MEG sensors, even if you do skirt='head' this will be effectively ignored because the sensors are way outside the head boundary.

strangely this ERP plot is now flat

Fixed by commit I just pushed. It was actually unrelated to this PR, and had non-deterministic behavior. It seemed to have to do with doing get_ylim before the limits had actually been calculated properly (probably some deep mpl bug), adding a figure.draw_idle() seems to fix it locally. We'll see if CircleCI agrees.

I didn't come close to looking at all the tutorials or examples so don't consider this a thorough review. I can make time to do that if it's needed.

It would be helpful, even if you just opened each one and quickly flipped through to look to see if anything is obviously wrong.

Updated full build:
https://16912-1301584-gh.circle-artifacts.com/0/dev/index.html

often the topos are clipped the bottom. See
https://16912-1301584-gh.circle-artifacts.com/0/dev/auto_examples/io/plot_read_proj.html#sphx-glr-auto-examples-io-plot-read-proj-py
https://16912-1301584-gh.circle-artifacts.com/0/dev/_images/sphx_glr_plot_50_artifact_correction_ssp_016.png
any idea why?

It looks as if the center of the head outline was not where the center of the of the circular aperture is.  Because of this we see where the extrapolation box ends - it is not ocvered by the aperture.

oops sorry I didn't mean to push directly to your branch @larsoner (though the changes are relevant to this PR)

No problem, I was tweaking those a little bit so further adjustment is fine by me. In the meantime I'll look into the box-cutting-off-circle issue (I think @mmagnuski is right about the issue), hopefully that's the last one :)

Okay, clipping should be fixed. Made code more DRY and modified a min/max check in the last commit I pushed to fix it. The Circle full build will currently fail because we need #7099 or some similar variant for it to succeed. Hopefully we can get one merged today and I'll rebase and force-push.
@agramfort I trust you'll have free time over the weekend that you want to dedicate to looking through every example :)

maybe this one is still broken https://16984-1301584-gh.circle-artifacts.com/0/dev/auto_examples/visualization/plot_evoked_arrowmap.html#sphx-glr-auto-examples-visualization-plot-evoked-arrowmap-py
also the EEG topos now look weird on sample. I would like to know if it's still comparable topos to fieldtrip on the same data. @dengemann had spent a lot of time years ago to have the topomaps looking at fieldtrip results.

See comment above, I think it's a more accurate representation of the 3D coordinates for sample. They are actually all 2cm or more above z=0 line. sphere='auto' is a better choice for actually digitized data (and it's better for sample), but it's not a good default because it behaves not so nicely for montages because it's affected by channel subsection in that case.

Specifically here
https://github.com/mne-tools/mne-python/pull/7066#issuecomment-556044554

Actually one option would be to use sphere=None to mean 'auto' if there are enough extra did points to do a fit, and the default (0,0,0,0.95) otherwise. This would look better for sample and real data, but also not change with channel picking

maybe this one is still broken

Fixed.

also the EEG topos now look weird on sample.

These plots should now look closer to how they did before -- making None the default makes things look better for real digitized locations, while not messing up montages. See the Circle full build for examples:
https://16998-1301584-gh.circle-artifacts.com/0/dev/index.html

I would like to know if it's still comparable topos to fieldtrip on the same data. @dengemann had spent a lot of time years ago to have the topomaps looking at fieldtrip results.

They still probably won't be totally comparable to Fieldtrip, as we are no longer trying to replicate Fieldtrip (as was done years ago). Instead this PR aims to systematically process / control the head-to-sensor relationship in topomap plotting as we have discussed in the linked issues going back a while. I think things looking similar to FieldTrip would be nice, but should not be the primary goal.

Looking at this ERP image with sensor inset, and this scalp field map from the same tutorial, they're not the same.  In fact, in this joint plot the channel location inset and the scalp topographies on the same figure aren't matching.  I thought they matched before, maybe the None = "auto" trick isn't working the same in insets vs scalp field maps?

Yep, forgot to pass info in one call, should be fixed now.

this looks really nice. I am just a bit worried about the now automatic
extrapolation way beyond helmet boundaries.
See for example
https://17004-1301584-gh.circle-artifacts.com/0/dev/auto_examples/io/plot_read_proj.html
https://17004-1301584-gh.circle-artifacts.com/0/dev/auto_examples/io/plot_read_proj.html#sphx-glr-auto-examples-io-plot-read-proj-py
where you clearly get the extreme values at the boundaries loosing the
dynamical range of values
inside the helmet convex hull.
See how brainstorm does this
https://www.frontiersin.org/files/Articles/435877/fnins-13-00076-HTML-r1/image_m/fnins-13-00076-g005.jpg
by
clipping outside of the helmet convex hull. Also now it's not so clear
anymore how head and skirt differ.
sorry for being a pain @larsoner ...

I am just a bit worried about the now automatic extrapolation way beyond helmet boundaries.

To me it's not very different from how it is on master (just a tiny bit larger), other than that the head is smaller inside the interpolation area:

https://17004-1301584-gh.circle-artifacts.com/0/dev/auto_examples/io/plot_read_proj.html
https://mne.tools/dev/auto_examples/io/plot_read_proj.html

Hence I'd rather change the behavior in a separate PR. We have an extrapolation mode that does a convex hull operation. But if you want me to change the default interpolation mode in this PR I can do it.

Also now it's not so clear anymore how head and skirt differ.

Head and skirt will differ more obviously for EEG when all sensors fit roughly inside the head.
For MEG not much will change because the sensors are generally outside the head circle, so the 1.25x factor for the circle gets ignored because the smallest circle that encompasses sensors is used:
https://github.com/mne-tools/mne-python/pull/7066/files#diff-2f146eb9390ce209fa40cf8fb1c7153dR378
I could instead make it that for MEG "head" does the smallest circle that encompasses sensors, and "skirt" does 1.25x this size, but it will make the problem above worse.

The topos look all very good to me, great work!

Hence I'd rather change the behavior in a separate PR. We have an extrapolation mode that does a convex hull operation. But if you want me to change the default interpolation mode in this PR I can do it.

I think it would be a good idea to keep this separate from changes to interpolation, the PR is already very big.

@cbrnr do you have an opinion here?

Just one (two actually) more thing extrapolation 'head' does not work very well now:

this seems to be because the extrapolation points are placed on the head circle in this extrapolation method, while now channels are often plotted outside the head circle. The readius of the extrapolation circle could be increased.
The other thing is how animate_topomap renders:

this seems to be because the extrapolation points are placed on the head circle in this extrapolation method, while now channels are often plotted outside the head circle. The readius of the extrapolation circle could be increased.

Ahh, I did not look at the head extrapolation mode. I'll see if I can do this tomorrow, and update the docstring for extrapolate to say it will go to the head circle or the sensor bounding circle, whichever is larger.

The other thing is how animate_topomap renders:

Whoops! It is indeed broken in the example that uses it so I'll fix that tomorrow, too.

Actually thinking about it more, I think extrapolate='head' is doing what it says it will do, so I think it's okay to leave it as is. We could in principle expand the radius in cases where sensors are outside the head circle, but I would say that in those cases people should really just use extrapolate='local' instead. It's less magical in terms of what it's doing.

Hm, it just made a lot more sense before when all the channels were within the head circle by default. But I understand the logic of your reasoning. In that case maybe only the tutorial should be changed to not show extrapolate=head
The only problem with 'local' now is that it creates pixelated edges - but thats a separate issue. I can work on this some time soon.

I like the changes to the docs, thanks @larsoner!

Bugs fixed:
https://17104-1301584-gh.circle-artifacts.com/0/dev/auto_examples/visualization/plot_evoked_topomap.html

Docstrings fixed after rebase on #7129, force pushed

thx @larsoner

:confetti_ball: :rocket: !


Interfaces

PR for interfaces support in development.
Approach
Modifies interface declarations to emit a real ES value even after interfaces are removed by Typescript. This ES value is exported if the interface is exported, and set as an unexported constant within the source file otherwise. The value for an interface named Foo has the name IΦFoo and conforms to the Interface interface:
export interface InterfaceToken {
    name : string;
    prototype : any;
    identity : symbol;
}

This value can be obtained by using the reify<T>(): Interface function export provided by the runtime layer.
interface Foo { }
expect(reify<Foo>().name).to.equal('Foo');
expect(typeof reify<Foo>().identity).to.equal('symbol');
expect(typeof reify<Foo>().prototype).to.equal('object');

Interface Tokens
Obtaining a token for an interface can be done using reify<T>(). This token describes the name of the interface as defined at the declaration site, an empty prototype object for hanging property metadata onto, and an identity symbol that can be used to represent the interface should it be required. "Class" level metadata is hung onto the Interface token object itself.
The token adheres to the following interface:
export interface Foo {
    method(foo : number): boolean;
    field : string;
    blah : string | number;
}

You can use reify<T>() to obtain an interface token:
import { ReflectedClass, reify } from 'typescript-rtti';

interface Foo {
    foo : string;
}

let reflectedClass = new ReflectedClass(reify<Foo>());
expect(reflectedClass.getProperty('foo').type.isClass(String)).to.be.true;

The interface token object can be used with the ReflectedClass API:
let reflectedInterface = ReflectedClass.from(reify<Something>());

This PR also introduces reflect() which is a quick uniform way to use the ReflectedClass API to reflect upon classes, interfaces and class instances:
let reflectedInterface = reflect<MyInterface>();
let reflectedClass = reflect(MyClass);

It also works with constructors and values
let reflectedClass = reflect(MyClass);
expect(reflectedClass).to.equal(reflect(new MyClass()));

Simple Validation
A simple API is provided for validating values against a reflected class or interface:
interface MyInterface {
    foo : string;
}
expect(reflect<MyInterface>().matchesValue({ foo: 123 })).to.be.false;

Output
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.IΦFoo = void 0;
const __RtΦ = (k, v) => Reflect.metadata(k, v);
const IΦFoo = { name: "Foo", prototype: {}, identity: Symbol("Foo (interface)") };
exports.IΦFoo = IΦFoo;
__RtΦ("rt:P", ["field", "blah"])(IΦFoo)
__RtΦ("rt:m", ["method"])(IΦFoo)
__RtΦ("rt:f", "C$e")(IΦFoo)
__RtΦ("rt:p", [{ n: "foo", t: () => Number }])(IΦFoo.prototype, "method")
__RtΦ("rt:f", "M$")(IΦFoo.prototype, "method")
__RtΦ("rt:t", () => Boolean)(IΦFoo.prototype, "method")
__RtΦ("rt:t", () => String)(IΦFoo.prototype, "field")
__RtΦ("rt:f", "P$")(IΦFoo.prototype, "field")
__RtΦ("rt:t", () => ({ TΦ: "|", t: [String, Number] }))(IΦFoo.prototype, "blah")
__RtΦ("rt:f", "P$")(IΦFoo.prototype, "blah")

Punch List

[x] Use Iphi not Iphi.prototype for rt:m and rt:P
[x] Support for checking if a specific ReflectedClass implements an interface reference acquired using reify<T>()
[x] Support for checking if a value matches the shape of a ReflectedClass
[x] Convenient way to check if a value's constructor implements an interface, perhaps an implements() export (ie if (implements(aValue, reify<MyInterface>())) { ... })
[x] Convenient way to check if a value matches the shape of a constructor or Interface value (as provided by reify<T>()). Perhaps if (matchesShape(aValue, reify<MyInterface>())) { ... }
[x] Calling reify on anything we don't yet support is an error
[ ] Framework for representing complex types on the fly, like reify<Some | Other>()
https://github.com/rezonant/typescript-rtti/issues/8

🚀


SAMZA-1773: Side inputs for local stores

@prateekm @vjagadish
Please take a look.
I will update the PR with the unit tests for SideInputStorageManager and the util functions.

@bharathkk Also, build is failing because of checkstyle issues.

+1 to Cameron's comments on StorageManagerUtil and SideInputStorageManager. I think I already fixed some of them in my PR earlier. Let's check if they got merged correctly.


some problem about the datasets

Hi, @picekl
I am interest with FungiDataset and the competition held on Kaggle. I have some doubts with them.

What is the difference between [Dev Images][~110Gb] and [Dev Images (max side size 300px)][~6.5Gb], which is the one you used to achieve your results?  I would like to choose smaller data to save my storage.
It seems there is only "scientificName" column which indicates the 1604 classes, so how can we submit "ClassId" for Kaggle competition?

Hi@Xrazy, Very good questions!

Dev [110Gb] contains original images in the original resolution (mostly 12MP). Dev [6.5] includes resized images, where max dimension is just 300px. There is no resized test set so be aware that resize might introduce some bias.
Fixed now. You can find the updated CSVs on Kaggle and the dataset web. The class_id that corresponds to scientificName was added.

Please do not hesitate to contact me if anything else occurs :)
Lukas


Invalid render options

Getting this error, any help would be greatly appreciated.
Exception in thread Thread-3:
ValueError: Invalid render options
Exception in thread Thread-4:
ValueError: Invalid render options

I've been getting that too. I realized after a while that this started happening after I switched to macOS Ventura. Are you on that too?

I've been getting that too. I realized after a while that this started happening after I switched to macOS Ventura. Are you on that too?

I've been getting that too. I realized after a while that this started happening after I switched to macOS Ventura. Are you on that too?

No I'm on windows 11 22H2

I am currently working on rewriting this project in rust for better performance, logging and error handling, so this problem might not be fixed in the python version, but I will try my best to fix it in the new rust version. Can you tell me the command you entered?

That's amazing! Here is the command I used:
unsilence "L23.mov" "L23.mkv" -ss 99 -sl -25 -stt 0.125 -y
I played around with the -t parameter but that doesn't resolve anything.

@lagmoellertim Thank you for all your hard work. This error seems to come up whenever I change the -stt (SILENCE_TIME_THRESHOLD) value.


Dwarf for structs, functions, vectors

Example of the debug info produced for this module/function/vector: (see line !5 with DISubrange, typical for vectors)
module 0x101::vector {
    struct Foo has copy, drop { x: u64, y: bool }

    public fun singleton<Element>(e: Element): vector<Element> {
        let v = empty();
        push_back(&mut v, e);
        v
    }

; ModuleID = '0x101__vector.dbg_info'
source_filename = "/home/sol/tmp/vector.1.move"

!llvm.dbg.cu = !{!0}
!unspecified\20type = !{!2, !2, !2, !2, !2, !2, !2}
!struct.vector__Foo = !{!6}
!test_singleton_contains = !{!14}
!singleton = !{!19}

!0 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !1, producer: "move-mv-llvm-compiler", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, splitDebugInlining: false, sysroot: "/")
!1 = !DIFile(filename: "vector.1.move", directory: "/home/sol/tmp")
!2 = !DICompositeType(tag: DW_TAG_array_type, baseType: !3, size: 192, align: 8, flags: DIFlagVector, elements: !4)
!3 = !DIBasicType(tag: DW_TAG_unspecified_type, name: "unspecified type")
!4 = !{!5}
!5 = !DISubrange(count: 1, lowerBound: 0)
!6 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "struct.vector__Foo__ptr", baseType: !7, size: 64, align: 64, dwarfAddressSpace: 0)
!7 = !DICompositeType(tag: DW_TAG_structure_type, name: "struct.vector__Foo", scope: !8, file: !1, line: 17, size: 128, align: 8, flags: DIFlagObjcClassComplete, elements: !9)
!8 = !DINamespace(name: "struct.vector__Foo", scope: !1)
!9 = !{!10, !12}
!10 = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: !8, file: !1, line: 17, baseType: !11, size: 64, align: 64)
!11 = !DIBasicType(name: "u64", size: 64)
!12 = !DIDerivedType(tag: DW_TAG_member, name: "y", scope: !8, file: !1, line: 18, baseType: !13, size: 1, align: 8, offset: 64)
!13 = !DIBasicType(name: "bool", size: 8)
!14 = distinct !DISubprogram(name: "test_singleton_contains", linkageName: "test_singleton_contains", scope: !15, file: !1, line: 70, type: !16, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, retainedNodes: !18)
!15 = !DINamespace(name: "test_singleton_contains", scope: !1)
!16 = !DISubroutineType(types: !17)
!17 = !{}
!18 = <temporary!> !{}
!19 = distinct !DISubprogram(name: "singleton", linkageName: "singleton", scope: !20, file: !1, line: 64, type: !21, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, retainedNodes: !24)
!20 = !DINamespace(name: "singleton", scope: !1)
!21 = !DISubroutineType(types: !22)
!22 = !{!23}
!23 = !DILocalVariable(name: "e", scope: !20, file: !1, type: !7)
!24 = <temporary!> !{}

Missing:

Functions will be enriched with Basic Block chains.
Vectors may be updated with better base type info.

This PR is a part of #403 work.


Add entry on create file action menu.

Adds support for creating a new Capnp file from the new file menu. This saves the need to type the .capnp file extension.

Thanks! looks good to me!
Please tell me if you're interested in being a collaborator?

I doubt I'll have much spare time to help out. I just happened to have been in a long edit-build-test cycle which gave me some extra free time for some architecture evaluation work. I haven't even decided if I'm using capnproto yet.


[General workload issue]: AMBA-ALZ Monitor Alert Approach how to change in code to Centralized?

Check for previous/existing GitHub issues

[x] I have checked for previous/existing GitHub issues

Issue Type?
Question
Description
Hi,
I see that as default is is decentralized.
AMBA-ALZ Monitor Alert Approach how to change in code to Centralized?
Best regards,
Michal

Hello @kosickimi ,
thanks for you feedback. Could you please expand a bit on what do you mean by change in code to Centralized?
Thanks,
Bruno.

Hi @Brunoga-MS
In documentation I found:
"AMBA-ALZ Monitor Alert Approach
The strategy for enabling alerts in the AMBA-ALZ pattern involves using Azure Policy to deploy alerts as resources are created, configuring action groups, and using Alert Processing Rules to activate alerts and link them to the action group.
There are two main approaches to enabling alerting in the AMBA-ALZ pattern:
Centralized
In a centralized alerting approach, a single Action Group is used for all alerts, resulting in a unified alerting email (distribution group) address or other configured actions.
Metric alerts are deployed with resources in the same resource group, while platform alerts like Service Health and Activity are created in a dedicated resource group within a subscription, typically located in the Management platform management group. A single Alert Action Group in this subscription is configured with a central alerting email address and Alert Processing Rules to enable filters and connect alerts to the Alert Action Group.
For example, in the AMBA-ALZ pattern, a single centralized action group is deployed in the “rg-amba-monitoring-001” resource group within a subscription in the Management platform management group.
Decentralized
In a decentralized approach, each subscription has a dedicated Action Group, providing more granular control over how alert notifications are directed. For instance, connectivity/networking alerts for the platform connectivity subscription can be directed to the network operations team.
Metric alerts are deployed with resources in the same resource group, while platform alerts such as Service Health and Activity are created in a dedicated resource group for each subscription. Alert Action Groups are established in each landing zone subscription, allowing different operational areas and landing zone subscriptions to have distinct alerting email addresses (e.g., networking, identity, operations, workloads) or other supported actions. Alert Processing Rules are created to enable filters and connect alerts to the Action Groups.
For example, in the AMBA-ALZ pattern, a graphic representation of the flow is provided below."

As you found in the documentation, we only provide decentralized approach configuration. Changing to centralized would require many changes at the code level including new parameters, change in the policy that creates the notification assets.
Very difficult to describe. As an alternative you could just exempt the subscriptions you do not want to have the policy applied. However, bear in mind that Alert Processing Rules (APR) can only work on the alerts created for resources in the same subscription as  the APR.

Thank you very much @Brunoga-MS  all clear


Add odo support?

Hello,
maybe you should consider to add support to odo
http://odo.readthedocs.org/
so it will become possible have several outputs / inputs :

get a Pandas DataFrame (see also https://github.com/frictionlessdata/datapackage-py/issues/73 )
store to a database supported by SQLAlchemy
...

Kind regards
see https://github.com/trickvi/datapackage/issues/45

@femtotrader
Thanks!
To export to SQL you could use https://github.com/frictionlessdata/datapackage-py#pushpull-data-package-to-storage

@femtotrader
Now jsontableschema-pandas ia also available - https://github.com/frictionlessdata/jsontableschema-pandas-py
Is this issue still actual?

Hi @roll
@vitorbaptista @sirex and you did great work on this datapackage-py package.
I'm quite busy these days... so I won't be able to work on this but it will be great if you could have a look at such feature because it will became easy to output a DataPackage to several kind of destination (not only SQL databases).
Kind regards

MOVED
https://github.com/frictionlessdata/implementations/issues/16
This issue seems should be resolved on higher-level than the data package library.


Cloud firestore crashes app in APK release mode

Flutter Cloud Firestore is creating an error on my Flutter App, when i execute it on a APK in release mode it just crashes the app and close it. I have AndroidX and everything works fine when i try the app from flutter run --release and i have my device connected. I have this issue for a week and I haven't found a way to solve it. First I thought it was an issue with the Google Maps Plugin but later I realize that it also happened in other parts of the app where i don't use it but where I used the cloud_firestore library too. So I think there is an issue with this
This is my flutter build apk log:
Gabriels-MacBook-Pro:Safer jumpbotron$ flutter build apk --release
You are building a fat APK that includes binaries for android-arm, android-arm64.
If you are deploying the app to the Play Store, it's recommended to use app bundles or split the APK to reduce the APK size.
    To generate an app bundle, run:
        flutter build appbundle --target-platform android-arm,android-arm64
        Learn more on: https://developer.android.com/guide/app-bundle
    To split the APKs per ABI, run:
        flutter build apk --target-platform android-arm,android-arm64 --split-per-abi
        Learn more on:  https://developer.android.com/studio/build/configure-apk-splits#configure-abi-split
Initializing gradle...                                              1.3s
Resolving dependencies...                                           4.0s
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedResFolders(FileCollection)
Note: /Users/jumpbotron/Documents/programming/installations/flutter/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-0.12.9+2/android/src/main/java/io/flutter/plugins/firebase/cloudfirestore/CloudFirestorePlugin.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/jumpbotron/Documents/programming/installations/flutter/.pub-cache/hosted/pub.dartlang.org/cloud_firestore-0.12.9+2/android/src/main/java/io/flutter/plugins/firebase/cloudfirestore/CloudFirestorePlugin.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: /Users/jumpbotron/Documents/programming/installations/flutter/.pub-cache/hosted/pub.dartlang.org/connectivity-0.4.3+6/android/src/main/java/io/flutter/plugins/connectivity/ConnectivityPlugin.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: /Users/jumpbotron/Documents/programming/installations/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_core-0.4.0+6/android/src/main/java/io/flutter/plugins/firebase/core/FirebaseCorePlugin.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
RRemoved unused resources: Binary resource data reduced from 256KB to 233KB: Removed 8%
Running Gradle task 'assembleRelease'...
Running Gradle task 'assembleRelease'... Done                     117.5s
Built build/app/outputs/apk/release/app-release.apk (7.2MB).

With flutter run

With APK file

@Jumpbotron did you migrate to AndroidX? What version of cloud_firestore do you use?
Also, may be related to #38934.

@Jumpbotron did you migrate to AndroidX? What version of cloud_firestore do you use?
Also, may be related to #38934.

Yes i dit the migration to AndroidX I'm using cloud_firestore: ^0.12.9+2
As i said everything works fine with the flutter run command but the problem is when i make the  apk and i try to run the app from it

Have you added proper proguard rules ?

@Jumpbotron and in build.gradle you use classpath 'com.android.tools.build:gradle:3.4.2', not 3.5.0, right?

@Jumpbotron and in build.gradle you use classpath 'com.android.tools.build:gradle:3.4.2', not 3.5.0, right?

That was the solution I needed, thank you very much. Why is it necessary to work with this version of Gradle?
Thank U very much

@Jumpbotron Cool, then I think it's safe to close this one. You can try using dev or master channel, if it will repeat there, please comment and I will re-open the issue right away.
The app bundle is built successfully. The issue is that in Android Gradle plugin 3.5.0, the app bundle is named app-.aab instead of app.aab, which is what the Flutter tool expects. This will be fixed, but in the meanwhile the app bundle will be contained in build/app/outputs/bundle// where  is release, debug or profile.
It was fixed here https://github.com/flutter/flutter/pull/39126 and went to the version 1.9.6, so not on stable/beta yet. I didn't see your flutter doctor, just assumed that if you encounter it, you may use stable.

@Jumpbotron
This issue has been moved to https://github.com/FirebaseExtended/flutterfire/issues/325. Any further collaboration will be done there.

I have this issue