help with zoomToPoint

https://jsfiddle.net/wom7xfnL/3/
Hi Timmy, thanks for your help with this. (see fiddle above)
basically i wish to figure out how to zoom to a coord on the SVG, (in the case of the fiddle x50 y150 from (top left i think))
the view seems to zoom to different places depending on how wide the view port is to start with. if i make the screen wider and refresh i end up with a different part of the svg in the center of the view.
im using
setTimeout(function(){
panzoom.zoomToPoint(3, {clientX:50, clientY:150});
},0);
i did see there is a zoomoption 'focal', but i couldnt figure out if i need it or how to use it.
i hope you don't mind me creating a new issue as im not sure if you get alerts when i added to a already closed issue.
thanks
Clint.

No problem creating an issue.
zoomToPoint allows the user to zoom in on any point in the parent element. In your case, the body. This is so things won't bug out when the Panzoom element is smaller than the parent, as is often the case. zoomToPoint uses the focal option internally, but is a convenience method to handle some of the complex conversions that often accompany zooming. In this case, converting a mouseover's clientX and clientY to a point inside the parent on which to zoom.
That is, you're not zooming to a point on the SVG, but a point somewhere in the parent, that then gets converted to a point on the SVG. Does that make sense?
Here's your example adjusted to zoom in on the center of the viewport. https://jsfiddle.net/timmywil/y7s92fbx/
You can use the focal option directly, but keep in mind that the focal option x/y values should have scale removed from them.
Let me know if you need more help.

Hi Timmy thank you
i still dont get how i can zoom to a specific place on the SVG.
if i knew that i needed to zoom to coord 100 from left 150 from top how would i do that?
it might be a good idea to see the use case. and see how your good work is being put to use
https://dev.fabcomms.co.uk/dynamic_routemap/dist_gtr/#/mapview
so i need to provide a search to zoom to a specific place, i can work out where the place is in the SVG by it is coord but i cant figure out how to use those x and y values within the svg to make the thing zoom with that point in the center.


Search page continuation token takes extra apiVersion and nextLink

Continuation token json is as follows:
{
    "apiVersion": "2019-05-06-Preview",
    "nextLink": "https://...",
    "nextPageParameters": {
        ...
    }
}

String continuationToken = Base64.getEncoder().encodeToString("$json");

@tg-msft @xirzec @xiangyan99 mind taking a quick look to ensure that all languages are using the same data structure to cover scenarios, which Ted mentioned, such as a processing queue.

https://github.com/Azure/azure-sdk-for-net/issues/10590

/azp run java - search - tests

/azp run java - search - tests

/azp run java - search - tests


Fix more edge cases in TextureAtlas

Changes:

Added new test cases, covering a couple of missed edge cases
Refactored Add() to have a whitePixel boolean argument. This means that findPosition() will never be called for the white pixel, and therefore can assume that the white pixel exists when calculating whether a texture will fit.
Added comments

Assumptions:
I changed a couple checks from width - PADDING to width - PADDING * 2 since edge cases were failing due to this. In making this change, I assumed that the intention was for images to have padding on all 4 sides, even at the edges of the texture atlas. If images are allowed go all the way to the bottom/right edges of the texture atlas, then I'd need to make some changes.

Still think there's much improvement to be had here in terms of readability.

findPosition should probably be renamed to allocatePosition (and moved down below public/internal methods). It should also have xmldoc explaining what it does and what a null return means.
not a huge fan of the whitePixel argument to Add. If you want to ensure it's added then make the implementation local to Reset (probably make Reset call an addWhitePixel private method)
The pre-checks in findPosition make the logic a bit hard to follow. I think the check for dual-direction overflow should probably be nested inside the part where the atlas is about to be reset, since that's the only place it will be executed.

Part of the reason I found the code hard to follow was because it was nested where it was about to be reset.
Highly disagree with nesting it - it's interpreted as iterating through the atlas causing whoever knows what other processes to occur such as position offsetting, only to then figure out, after doing so, that the texture couldn't be fit in the atlas at all.
Can you explain to me why prechecks are hard to parse? The point of prechecks is so that they're easy to parse and exclude from your mind - it's the reason why I invert conditions and reduce nesting, and we've had that discussion many times before.

The specific one I have issue with is the one I mentioned above – it's prechecking for something that can only happen in one code path, which makes me read over the code many more times to try and understand why it's done that way. For me it causes more confusion than otherwise.

For reference, I was hoping for something more like this:

Does that read OK to you?

I don't understand why you have to "read over the code many more times". This is the point of a pre-check - so you dont have to do that. It's saying that this condition must hold true for the further code to execute.
You should be reading the pre-check, understanding what it means (i.e. that the texture is able to fit in an empty atlas), and read the rest of the code while knowing that condition always holds true.
The condition you've pointed out is the exact one I had problems with.

Specifically,

By moving the sub condition out it becomes harder for me to read because I need to understand why that's been done (and because the logic isn't easy to parse it takes a while to confirm it's correct).

The reasoning behind "this can't happen without this" is incorrect. Because the first is checking if it can fit from the current position (which it can), and the second is checking if it can fit at all, which it can't. The two aren't related.

Maybe splitting out the "can fit at all" check into a private method would work better? bool checkWouldOverflowEmptyAtlasTexture(int width, int height) or something?


Move solutions from solutions branch to /solutions directory in root

Because

Changing to this structure allows for a smoother contribution flow when it comes to changing exercises or adding new ones. The solutions can be adjusted within the same PR to the main branch rather than needing to submit two separate PRs to main and solutions.
This PR

Moves the solutions to all of the ruby_basics exercises from the solutions branch to a new directory in the root of main branch called solutions/.

Issue

Closes #XXXXX
Additional Information

Upon merging this, the PR template should change to either eliminate or reword the item about potentially requiring PRs to the solutions branch

[ ] If this PR includes changes that needs to be updated on the solutions branch, I have created another PR (and linked it to this PR).

Pull Request Requirements

[x] I have thoroughly read and understand The Odin Project Contributing Guide
[x] The title of this PR follows the location of change: brief description of change format, e.g. Data types exercise: Update spec files
[x] The Because section summarizes the reason for this PR
[x] The This PR section has a bullet point list describing the changes in this PR
[ ] If this PR addresses an open issue, it is linked in the Issue section
[ ] If this PR includes changes that needs to be updated on the solutions branch, I have created another PR (and linked it to this PR).

Also definitely open to discussing where exactly to place the solutions if any reviewer(s) don't like it being in root.


feat(react-await): remove react-await package

Overview
close #1104

remove react-await package

PR Checklist

[x] I did below actions if need

I read the Contributing Guide
I added documents and tests.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.45%. Comparing base (86a4640) to head (d0cb44b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1114      +/-   ##
==========================================
- Coverage   82.08%   79.45%   -2.63%
==========================================
  Files          66       59       -7
  Lines         720      628      -92
  Branches      149      127      -22
==========================================
- Hits          591      499      -92
  Misses        120      120
  Partials        9        9

Components
Coverage Δ

@suspensive/utils
47.16% <ø> (ø)

@suspensive/react
96.88% <ø> (ø)

@suspensive/react-query
71.96% <ø> (ø)

@suspensive/react-query-4
0.00% <ø> (ø)

@suspensive/react-query-5
0.00% <ø> (ø)

@suspensive/jotai
0.00% <ø> (ø)

@suspensive/cache
98.16% <ø> (ø)

@suspensive/react-image
80.39% <ø> (ø)


[docs] update to show correct configuration directory

In DBZ-8206 moved the configuration directory from conf to config, but the docs are still mentioning the old conf directory.

Also did not see anything about it in the 3.0 release notes, so I was scratching my head for a bit trying to figure out why it wouldn't start properly.

@omBratteng Great catch, applied, thanks!


Improve piiscan

Type of Change

[X] Bug fix (non-breaking change, fixes #)
[X] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Adding code coverage to existing functionality
[ ] Pester test is included
[ ] If new file reference added for test, has is been added to github.com/sqlcollaborative/appveyor-lab ?
[ ] Nunit test is included
[ ] Documentation
[ ] Build system

Purpose
The known names and patterns had to be fixed or new ones had to be added.
Implemented several prechecks in the scan command to make the command faster.
Approach
Added the needed patterns and known names
Commands to test
Invoke-DbaDbPiiScan
Screenshots

Learning

one pass!


Add .signature class to the <cite> element

While the signature class works on <cite> elements as far as applying basic text styles, it doesn't render on the right like it does with <div>s. Using <cite> for quotes seems to fall more in-line with how many in the Obsidian community appear to use them, and at the moment, their positioning is a bit intrusive for the writing it's associated with.
Expected behavior:

Actual behavior:

I haven't tried anything yet due to a lack of time, though I think setting display: block; should allow for it to be positioned more easily.

I didn't even know about the  option. I'll play around with it.

Oh, the "incorrect" font isn't because of issues with the theme; the screenshots were just to show the positioning. I changed the font using a second class with .signature; if I take it off, it defaults back to Edwardian.

Will be coming in v6, already have it "" working on my working build


kvssink with a different stream-name not working

I have an IoT Greengrass device (with name smartdvr-1423019132001 )
on the device I stream video to kinesis using the kvssink gstreamer plugin like:
gst-launch-1.0 .... video source ... ! kvssink name=bob storage-size=512 iot-certificate="iot-certificate,endpoint=xxxxxxxxx.credentials.iot.ap-southeast-2.amazonaws.com,cert-path=/greengrass/v2/thingCert.crt,key-path=/greengrass/v2/privKey.key,ca-path=/greengrass/v2/rootCA.pem,role-aliases=KvsCameraIoTRoleAlias" aws-region="ap-southeast-2" log-config="/etc/mtdata/kvssink-log.config" stream-name=smartdvr-1423019132001
and with the instructions on how to setup impersonation via the certificate it uses the following alias: KvsCameraIoTRoleAlias which points to
KVSCameraCertificateBasedIAMRole :
{
"Version": "2012-10-17",
"Statement": [
  {
    "Sid": "VisualEditor0",
    "Effect": "Allow",
    "Action": [
      "kinesisvideo:PutMedia",
      "kinesisvideo:GetDataEndpoint",
      "kinesisvideo:DescribeStream",
      "kinesisvideo:TagStream",
      "kinesisvideo:CreateStream"
    ],
    "Resource": "arn:aws:kinesisvideo:::stream/${credentials-iot:ThingName}/*"
  }
]
}

..this works.. and it creates a smartdvr-1423019132001 kinesis video stream and is streaming the video.
now i want to change to have multiple streams (may have more than 1 camera that i want to stream)
so i've changed the stream-name to smartdvr-1423019132001-video1
and changed the impersonation policy to
"Resource": "arn:aws:kinesisvideo:::stream/${credentials-iot:ThingName}-*/*"
but i'm getting errors in the kvs.log file like:
[DEBUG] [03-11-2021 09:28:24:182.950 GMT] Creating IoT auth callbacks.
[ERROR] [03-11-2021 09:28:24:413.866 GMT] blockingCurlCall(): Curl call response failed with http status 403
[ERROR] [03-11-2021 09:28:24:418.225 GMT] Unable to create Iot Credential provider. Error status: 0x15000011

if i switch it back it starts working again.
also tried
"Resource": "*"
still the same
any suggestions where i can look ?
note: this is a repost of https://forums.aws.amazon.com/thread.jspa?threadID=347747&tstart=0 as i noticed that most support for this is being given here instead of on the aws forum.

diving into the code a bit, it looks like the stream-name is being passed into
createCurlIotCredentialProviderWithTime as the thingName
https://github.com/awslabs/amazon-kinesis-video-streams-producer-c/blob/a8091d1a140fbdcb260ba3c8302aa2e4712d2d91/src/source/IotAuthCallback.c#L39
is there a reason for this ?
would this whole 1 stream per thingname be solved by adding an extra 'thingname' to the paramters and using that to get the authentication token, then using stream-name for..you know.. the name of the stream ?
then letting the policy on the backend limit access to whatever you like.. but don't enforce the stream-name at this stage ?

Closing since PR is merged.

@Coldplayer1995 i added a new parameter called iot-thing-name
If you specify it with your exact thing-name then you can use anything else as your stream-name. I think there is an example in the description of the pull request.


Add GraphVectorStore component doc

Preview:

Should we use CassandraGraphVectorStore, or is My* more idiomatic for the docs?

We can try CassandraVectorStore. Let's see!


aokvqa upload test errpr

Hey, I see that your previous edit mentioned issues with uploading to the AI2 leaderboard. Your message is now blank: so is this resolved?
In any case, that is not an issue I am able to help with. Please contact<EMAIL_ADDRESS>as the error message says.
Closing this issue for now, but feel free to re-open if there is something I’m able to help with.


Feature: Make deleting highlights more intuitive

Type of feature
🍕 Feature
Current behavior
After struggling to find a delete button and deleting the highlights I created for testing through the API 😓, while working on the edit highlight modal, I realised that's the place you delete a highlight from.
https://ux.stackexchange.com/a/104755
Suggested solution
Add a delete option to the context menu directly?
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Contributing Docs

[X] I agree to follow this project's Contribution Docs

I thought it was intentional to prevent deleting highlights, if that's not the case I can .take it.

Yeah, it's intentional. I'm just reporting what I felt, if the team thinks there's no need to work on it, it's fine. So let's wait😁

I think its fine for now. On initial design, the delete is meant to be inside the edit.


Fix missing Trim in Roles and Schemes split

PR for issue #627

Hi @phenixdotnet, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla2.dotnetfoundation.org.

TTYL, DNFBOT;

@phenixdotnet, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, DNFBOT;

I added 2 tests with the roles or authentication scheme empty or with white space.
I have to keep the if(string.IsNullOrWhiteSpace())and use the StringSplitOptions.RemoveEmptyEntries to remove the empty or white space entries.

Okay so if we still need the NullOrWhiteSpace check, there's no real value in the RemoveEmptyEntries option, sorry about that, can you revert that back to the simple Split and other than that this looks good, I'll merge this in next week...  Thanks!

Ok no prob :).
I will do that ASAP and let you known.

Rework done.
One last things, I used linq to filter roles (roles.Where(r => !string.IsNullOrWhiteSpace(r)).Select(r => r => r.Trim());)
Not sure if it's the best way to do this.

Looks good, I'll get this in next week, thanks again!

You're welcome :)


Ingest EYB triage and user data

Description of change

This PR adds functionality to ingest EYB triage and user records from Data Hub's S3 bucket.
Summary of changes:

Removal of the EYBLead create view/endpoint (no longer needed)
Various schema changes to the EYBLead model
Created individual serialisers for the triage and user data
Defined tasks to search for new EYB files and ingest their contents
Scheduled the ingestion of user records after triage records to avoid duplicate EYBLead instances being created

Most of the changes in this feature branch have been approved in two sub-PRs:

#5684
#5710

[!WARNING]
Please note, a few small tweaks have been added since #5710 and are not pre-approved. These are the three most recent commits:

ba9cbdfda
5e5455d3f
9347643c2

Checklist

[x] Has this branch been rebased on top of the current main branch?

Explanation
The branch should not be stale or have conflicts at the time reviews are requested.

[ ] Is the CircleCI build passing?

General points

Other things to check

Make sure fixtures/test_data.yaml is maintained when updating models
Consider the admin site when making changes to models
Use select-/prefetch-related field lists in views and search apps, and update them when fields are added
Make sure the README is updated e.g. when adding new environment variables

See docs/CONTRIBUTING.md for more guidelines.

In investment_lead/serializers.py, CodeCov is flagging a few lines, but I think it's okay to leave them because:

Lines 115 and 126 return an empty dict for the base class methods, which are intended to be overridden, but left in so if it's not overridden (by future code that inherits these classes), it doesn't fail. The classes that override these methods are tested completely.
Lines 217 and 218 refer to the above regarding one edge case location value. On the EYB side, all new records are using a drop down with a fixed value. As a result, I'm still unsure if it's worth handling this edge case, rather than let it be skipped/not ingested.

@oliverjwroberts I think it's still reasonable to:
a) Test what the base class does if used directly (how else do I know that removing that {} and returning None breaks things?
b) Test what inheriting code that doesn't override it would/should do - should it raise an error? Fail gracefully etc?


Barrier delete fix

Fixed rebalance bug: first consumer that succeeds ack barrier should not delete it, because other consumers might not see it.

Also added a couple of optimizations/fixes:

Avoid allocating unnecessary log strings when minimum level is higher than the message's level (especially when strings are lengthy)
Added routine pool for claiming partition ownership. This allows to speed up rebalance when the consumer has to claim a lot of partitions. In our case the consumer had to claim ~3200 partitions and this improvement speeds things up from ~1.5 minutes to 2-4 seconds.

<<  In our case the consumer had to claim ~3200 partitions and this improvement speeds things up from ~1.5 minutes to 2-4 seconds.
HUZZAH!!!


Implement  as shown in BasicElements.pdf

Hi,
Is there a way to implement an <IconButton /> as shown here: https://github.com/OfficeDev/msteams-ui-components/blob/master/docs/design/MicrosoftTeams-BasicElements.pdf ? I'm referring to the primary/secondary/tertiary flavors.
As far as I can tell, there are only two variations to each Icon, default and disabled, with the disabled variant being greyed-out.
Thanks.

We only support the tertiary icon button at the moment.
The relevant styles are here: https://github.com/OfficeDev/msteams-ui-components/blob/master/msteams-ui-styles-core/src/components/icon-button.ts
And the React binding is here: https://github.com/OfficeDev/msteams-ui-components/blob/master/msteams-ui-components-react/src/buttons/icon.tsx
It shouldn't be too hard to add the other flavors but we are a bit swamped with other work at the moment.

All good - appreciate the quick response. Just waned to make sure I wasn't missing anything.


Blog post for E2E progress updates

Describe the solution you'd like
Starting with k8s 1.17+ we will be able to get progress updates from runs in flight. We need to have a blog post showing off this feature as it has been one of the longest-standing, most requested features. Depends on #992

Post is in review; going to bump to next cycle since I dont want it closed before it gets published.

https://sonobuoy.io/conformance-testing-with-progress-updates/


Updated fa maintainers

Hi hope you are doing well,
I'm "Abolfazl Chaman" & am 20 years old, I have been coding since i was 13, started web development in 2018 and got to know React, js, node.js, express & several other related technologies pretty well, since then worked on mostly large-scale closed source projects. I translated the official very well-known Airbnb-javascript-style-guide, as well as their official React/JSX-style-guide style guide as well as their CSS/Sass-style-guide .
For translation and maintaining capability proof: I'm a holder of an Academic IELTS(International English Language Testing System) Band 7.5 test results and Farsi(Persian) is my mother tongue.
I have the time & skills necessary to be an active & consistent member of the maintaining fa translation team and certainly would be honored nonetheless. -Best wishes!🤝

Hi! We're no longer tracking the maintainer lists in this repo, so please raise an issue in the translation repository instead if you'd like to collaborate. If the existing maintainers express interest, they should be able to add you. If there are any issues with contacting them, or you have other concerns, please raise an issue here. Thanks.

Hello. Is there a separate procedure required to add someone as an organization member? cc. @lumirlumir


fix body template 6

for body template 6 we need to setBackgroundImage instead setImage.
Testing this with echo Spot, and echo Show - it works!

Thanks @vitaliidanchul !


Typescript example in docs generates warnings in Viz

Bug or feature request?
Bug
Description:
The state machine documented here has the following line toward the bottom:
            '': { target: 'green' }
If you take that machine configuration and paste it into the xstate-viz, the console spews lots of the following warnings:
Target 'green' not found on 'light.red.stop'
(anonymous) @ graph.js:118
...
n.render | @ | StateChartNode.js:133

(Bug) Expected result:
To be able to explore the documentation example with Viz
(Bug) Actual result:
It sorta works, but the red state can't hit the stop nested state and every transition gives that warning in the console
(Bug) Potential fix:
I didn't see anything in the docs about what an empty property name would indicate, so maybe that is a typo in the example and it should actually be PED_COUNTDOWN?
Changing that doesn't fix the error though.  It seems the target should be something other than 'green'.
Link to reproduction or proof-of-concept:

Visit VIZ
Open the browser's console
Paste in the StateMachine configuration from the typescript page

Ah, that's a mistake in the documentation. It should be '#light.green'.

Cool.  Maybe while in there, you could see if the example could be made a little more consistent/functional? Currently, it can't get from the wait to the stop state, and a power outage event sets the pedestrian state to walk which could be a bit dangerous if this was anything other than a hypothetical example. ;)

Oh, regarding the can't get to stop state, I understand a little better what is happening there.  The condition prevents Viz from letting the user click on the event.
I tried manually sending the event {type: "PED_COUNTDOWN", duration: 0}, but that still doesn't work because elapsed is still 0 and I don't see a way to change that within the simulation.  I did try changing it in the definition of the machine and then manually sending the event did transition.


Export requirements.txt for non Poetry users

It would be nice to have requirements.txt to allow for other install methods outside of Poetry.
Maybe add as a GitHub action?

Implemented in #168 and #170


Parent-child relationships

This commit introduces the parent-child relationships via labels as specified in https://github.com/crossplaneio/crossplane/blob/master/design/one-pager-stack-relationship-labels.md
Fixes https://github.com/crossplaneio/crossplane/issues/1202

@suskin Thanks! I've tested it with minimal gcp stack and it's working:
  labels:
    core.crossplane.io/parent-group: gcp.resourcepacks.crossplane.io
    core.crossplane.io/parent-kind: MinimalGCP
    core.crossplane.io/parent-name: test
    core.crossplane.io/parent-uid: d3f8fa83-e142-4fac-b207-85aa345d1031
    core.crossplane.io/parent-version: v1alpha1


Scala 2.12.0-RC2

Released 0.4.2 based on 49dfa98.

Missing dependency chain:

[ ] ScalaCheck (rickynils/scalacheck#291)
[ ] ScalaTest (scalatest/scalatest#989)
[ ] scodec-bits (scodec/scodec-bits#65)

Released 0.4.2 for Scala 2.12.

Thanks lars!


[MRG] Fix handling of mixed spaces in gp_minimize

Also fixes https://github.com/scikit-optimize/scikit-optimize/issues/292


add downgrade CI

resolves #162

Test fail because of a bug in transform_solutions (fixed in #167)


Choose CSS/New Technology

Tailwind CSS
https://tastedive.com/read/api

Tailwind CSS
https://tastedive.com/read/api

user registration using passport and bcrypt (new technologies)

user registration using passport and bcrypt (new technologies)


Add adafruit board toolkit

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
It is actually only a library so I tested basic functionality of the library instead as below

>>> from adafruit_board_toolkit import circuitpython_serial as cpserial
>>> cpserial.data_comports()
()
#### After connecting a circuitpyhon device
>>> cpserial.data_comports()
(<serial.tools.list_ports_linux.SysFS object at 0x7267322f3500>,)

24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@FliegendeWurst thank you very much for nice suggestions, I applied your suggestion rebuild the package and check if it is still working fine. And everything seems fine!

just updated the commit message, thank you for the comment @misuzu


How to resolve incorrect lock?

I locked an ERC-20 on Eth which was minted on SDK as Coin. Then I locked that Coin on SDK in order to return it to Eth. Of course when doing this you should not lock but instead burn the Coin. I did the incorrect lock instead of burn. After adding error logging to the Eth side it throws an error that says:
> yarn peggy:process 1
yarn run v1.16.0
$ yarn workspace testnet-contracts peggy:process 1
$ truffle exec scripts/sendProcessProphecy.js 1
You can improve web3's peformance when running Node.js versions older than 10.5.0 by installing the (deprecated) scrypt package in your project
You can improve web3's peformance when running Node.js versions older than 10.5.0 by installing the (deprecated) scrypt package in your project
Using network 'ganache'.

Fetching Oracle contract...
Attempting to send processBridgeProphecy() tx...
Returned error: VM Exception while processing transaction: revert Token must be a whitelisted bridge token -- Reason given: Token must be a whitelisted bridge token.
Done in 9.56s.

What are the methods available for undoing an incorrectly made relay?
In a similar vein: what are the methods for relaying a transactions which was originally missed?

This initial version of peggy is designed with the assumption that a transaction, if valid, will always succeed. This assumption should hold if a high enough threshold of  validators/relayers are all operating correctly at all times. (ie, a lock will always result in a minted coin on the opposite chain, a burn will always result in an unlock on the opposite chain)
The whitelist was added as a temporary fix, until more information/features could be gathered around having Cosmos's Coin and Bank systems support multiple tokens with the same denomination. (https://github.com/cosmos/peggy/issues/69)
So for example: in your scenario, it seems like COIN has been whitelisted, then COIN was locked on eth to create CosmosCOIN. You're trying to lock CosmosCOIN, which is not whitelisted, so it fails, preventing you from mistakenly succeeding at the incorrect lock. The way to resolve the above would to get CosmosCOIN whitelisted so that the transfer succeeds onto the Ethereum side and creates ETHCosmosCOIN, then to burn the ETHCosmosCOIN and get your CosmosCOIN back on the Cosmos side.
Another of the reasons for the whitelisting feature was done to avoid the scenario like yours above, ie, prevent a user from mistakenly locking a token when they ought to burn it, though this is still not fully prevented, as the Cosmos transaction still goes through. It may be good to implement the same whitelist on the Cosmos side so that the incorrect transfer couldn't happen in the first place. This would result in challenges with having to synchronise the whitelist on both ETH/Cosmos though. Another option would be to have the whitelist checked at the UX layer, as the user is making the incorrect transfer and prevents it on the frontend (ie, the CLI checks the Ethereum whitelists, or if it was a webapp, the webapp queries ethereum for the whitelist)
Again, ideally default support for all tokens including tokens with the same denomination seems most natural, and so aiming to get that feature supported on Cosmos may be the cleanest, in which case no whitelist should be needed. We considered implementing our own Coin/Bank that supported such, but it seemed like overkill and seemed like a feature that perhaps should be supported by core SDK stuff?

I like the prefix solution better as it is able to prevent a mishap at the level of the state machine. Plus there might be other situations where it's good to be able to tell what category of asset a denom is within the SDK. Being able to check if it was an wrapped asset or not could be useful. There's also been some talk about using something like a metadata module to store information about a coin, like vesting.
https://github.com/cosmos/cosmos-sdk/issues/1980
https://github.com/cosmos/cosmos-sdk/issues/4911

I'm not sure if the prefix method is perfect.
With the prefix method, i suppose we would use something like a naming convention of:
{chainid}{bridgecontractaddress}{tokencontractaddress}_{tokensymbol} that would apply to tokens coming from ethereum. Tokens coming from cosmos would not be restricted to any naming convention.
This could still result in a weird conflict, say, for example, someone named their coin on cosmos, originating on cosmos as: single_collateral_stable_coin
When they tried to relay this, they would get weird unexpected issues, as we wouldn't be able to disambiguate a coin that originated on cosmos or on ethereum. I mean we could implement logic that checks the types of the first 3 prefixes and decides to assume the coin is ethereum-sourced if they match the above types and cosmos-sourced if not, but again it seems like a hacky fix based on assumptions as opposed to being super foolproof with real metadata.
Ideally there was this real token metadata system included either as part of our bridge modules or built into cosmos itself - that would then allow us to unambiguously check where a token is from, whether it's wrapped or not, and more as described in those linked issues.
Some of the above thinking, including waiting on a stable/defacto metadata system to emerge from the cosmos sdk team themself too is why we opted for a whitelisting based solution.
The current system does still have a process for resolving an incorrect lock:
1 - you make the incorrect lock, and it succeeds through the state machine
2 - relayer detects event from cosmos state machine but fails to transfer it, as it is not whitelisted
3 - you get your incorrectly-locked-token whitelisted through an ethereum transaction
4 - relayer tries again and/or you manually relay the lock again, now succeeds through ethereum state machine
5 - you get minted your incorrectly-locked-token on ethereum
6 - you burn your incorrectly-locked-token on ethereum
7 - relayer relays the burn back to cosmos
8 - your incorrectly-locked-token gets unlocked and you have it back
The above process is cumbersome, but should work. Another addition that may be helpful is if, before step 1, in ebcli, we query ethereum (through infura or own eth node) to check the whitelist and block your transaction at the cli-level, before it even gets to the state machine. This means that the above 8 steps would still be possible by someone not using the cli or using a modified cli, but would not be possible for someone using the normal tooling. The only concern here is we'd be adding an external dependency of Infura/Eth Node on the CLI for the lock command, though that may be fine.
Any thoughts?

It's true having the fully featured metadata would be a more complete solution. I don't think there's that much wrong with just settling on a naming convention and enforcing it at the bridge level though. For example if underscore was the decided demarcation, the bridge could restrict usage to only denoms that did not contain any underscores. Probably it would be good to do something a little less common, maybe :: but the idea stays the same.
Checking the whitelist from the CLI is another option but I agree it would be good not to bog down the CLI with that kind of action. Maybe adding the relayer as an endpoint that the CLI could query for that information is an option.
Your outlined solution makes sense beyond the fact that the relayer isn't capable of trying a failed transaction again. There's also the general problem of whitelisting a new token which can only be done by the operator. It seems like maybe any token coming from an SDK chain should be automatically whitelisted upon generation?
For the sake of concrete actions that can be made on the current codebase that would prevent an invalid lock, I'd suggest using a single namespace to denote a token coming from on chain or off chain. The complexities of tracking chain id and bridge address are to allow multiple chains and multiple instance of a bridge on the same chain from interacting with a single sdk chain. I think that is out of scope for this version of peggy and realistically we're talking about only one sdk chain talking to one eth chain via one bridge contract. adding a prefix like peg:: to denoms on the sdk side or on the eth side would be enough to distinguish the origin of the asset and automate the decision to burn or lock.
Alternatively an improvement to the UX of the relayer that is able to check the status of relayed events and detect when one failed and try again would be a method of supporting the userflow you outlined as well.

I'm in favor of removing the whitelist and updating namespacing. In my opinion the value of peg::dai is directly correlated with the associated contract address and should be included in the namespace solution - a user could deploy a new ERC20 contract with denom dai, lock the worthless assets, and still receive peg::dai on the other side. I noticed that in the IBC relayer demo, chain ibc0's n0token has denom transfer/ibczeroxfer/n0token after its been transferred to chain ibc1. The relayer codebase has comments that indicate it's a placeholder solution and I like the :: convention, but should we be adhering to a similar namespacing strategy until a metadata solution is ready?
Also, we'll still need some sort of listed assets mapping on the contracts as we'd want to deploy a new token contract for the first lock of a cosmos-based asset but utilize the same contract for subsequent locks of the same asset.

@okwme Cool, single namespace with a more uncommon prefix sounds fine.
Agree about tracking chain id and bridge address not that important - in fact, chain id and bridge address needs to be implicitly tracked by the relayers, and all relayers need to follow them the same, otherwise this will result in clashing oracle claims and so we effectively have implicit tracking of chain id and bridge address anyway.
@denalimarsh Agree, we do need to track contract addresses for tokens on both sides of the bridge though - are there any major implications for doing this on the Solidity side after removing whitelisting?
I think the suggested namespacing conventions and idea to check/sync with IBC are nice, but shouldn't block us from moving forward and are easy to change as long as we aren't running with real users/$$ and don't need to maintain backwards compatibility with changes. I'm sure we'll want to implement full IBC integration in a future phase of the peggy project, still before we have real users/$$, so conventions/changes can also be made then.

If we remove the whitelist we’ll need to add a map of (cosmos-based asset denom => token contract address). Function completeProphecyClaim() will need to check this new map and conditionally deploy a new bridge token contract or use an existing bridge token contract. Currently newProphecyClaim() assumes a contract is already available (eth-based assets have an existing contract, cosmos-based assets have one created when they're added to the whitelist) and therefore requires a contract address.
Some thoughts on removing param _tokenAddress from newProphecyClaim():

Could add separate entry points for burn/locks where the first burn of a cosmos-based asset deploys a new contract and passes the address along to newProphecyClaim().
Drop the _tokenAddress for eth-based assets as well. Could add another map of (eth-based asset denom => token contract address) and then check it against the lockedFunds mapping that currently holds (eth-based asset token contract address => amount of locked tokens) to validate that funds are available to be unlocked before adding the new claim.

I agree about namespacing conventions. For now, let's just use the proposed peg::atom for cosmos-based assets on Ethereum and peg::dai for eth-based assets on Cosmos.

@denalimarsh
1 - This would work, but if we have separate entry points/separate solidity functions for first vs later burn/locks, are you suggesting that the relayer would then need to distinguish between the two and pick one, or that the relayer would always hit the same entrypoint and it would distinguish in solidity? Latter would be easier for relayer but would mean extra gas being paid by it for that first deployment. Also, in terms of gas limits, would the latter have any risks/issues or should be fine?

Update: Cosmos SDK only supports denoms with [a-z][0-9] characters and max 16. I'm using "pegsymbol" instead of "peg::" as the prefix.
This also means there is no easy way to distinguish between two different Ethereum Tokens with the same symbol/name. Ideally we would include the Ethereum Token Contract address in the denom (eg: like, "peg::0x1203403450345::dai", or in denom metadata, but Cosmos SDK supports neither.
The bridge will be vulnerable to an attacker that duplicates an ERC20 with the same name, mints duplicate coins for themselves, then transfers them across the bridge to the Cosmos side. This vulnerability will need to be fixed in a future version. I'll add this to the README to make it clear.

Another solution would be to keep a registry of Eth based token denoms stored with their contract address and to create cosmos based assets with an incrementing name for collisions. So for instance the first time a contract with "Dai" is as a denom is moved over the contract address is stored and the second time a claim is relayed as "Dai" but with a different address the SDK can distinguish and will mint as "Dai-2" or something?

@okwme Yep, this would basically effectively mean implementing a custom bridge-specific token metadata module. Ideally Cosmos SDK provides that and I think there is already talk of that?
Anyway, could either build a custom metadata module into the bridge or into Cosmos itself as part of the next version, depending on feedback from the SDK team.

rightiright i remember that discussion now. Sounds good, I think this solution works til then


Dependcy issues

Hi, I'm trying to learn Phinx, as on my job we use Cake (erm, Cake 2 … no migration strategy at all, but we are finally willing to upgrade.)
I'm used to work with Symfony and Doctrine, so phinx-migration-generator seems to be the missing part to make my live happy in the Cake world.
For a private project I wanted to test the migration-generator, but it was moaning about my composer.json requiring Phinx 0.16.0 and symfony/console 7.06, no big deal, as my project is not Symfony based, I can downgrade both packages, but maybe an upgrade makes sense? Symfony 7 is out for  a while now and has no breaking changes against 6.4.

Thanks for reporting. This should be fixed now in the latest version.
https://github.com/odan/phinx-migrations-generator/releases/tag/6.2.0


Update aws-java-sdk-kinesis, ... to 1.11.783

Updates

com.amazonaws:aws-java-sdk-kinesis
com.amazonaws:aws-java-sdk-s3
com.amazonaws:aws-java-sdk-sqs

from 1.11.772 to 1.11.783.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.amazonaws" } ]

labels: library-update, semver-patch

Codecov Report

Merging #318 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #318   +/-   ##
=======================================
  Coverage   46.76%   46.76%
=======================================
  Files          24       24
  Lines         278      278
=======================================
  Hits          130      130
  Misses        148      148

Continue to review full report at Codecov.

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


GUVNOR-2933: Guvnor ALA integration

Hello @manstis @porcelli this is just a minor PR derived from the one in kie-wb-commons.
Would you mind review?
Depends on https://github.com/droolsjbpm/kie-wb-common/pull/714
Thanks.

@wmedvede Looks like something in Form Builder needs a change too ( @pefernan uses DMO for Type meta-data for dynamic forms).

Jenkins please retest this.

@manstis I'll double check tomorow early, but I don't think so, since the Form Modeler is doing let's say a very low level access to the DMO apis,  by creating PDMO builder manually for processing already given .class files.

Jenkins please retest this.

@manstis I confirm that not changes are required in the Form Modeler side.

@wmedvede OK. weird; why "jBPM Form Modeler - Data Modeller" is failing compilation then due to:
09:19:35 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile (default-compile) on project jbpm-form-modeler-data-modeler: Compilation failure: Compilation failure:
09:19:35 [ERROR] /home/jenkins/workspace/drools-wb-pullrequests/upstream-repos/jbpm-form-modeler/jbpm-form-modeler-integrations/jbpm-form-modeler-data-modeler/src/main/java/org/jbpm/formModeler/dataModeler/integration/DataModelerService.java:[36,57] cannot find symbol
09:19:35 [ERROR] symbol:   class LRUBuilderCache
09:19:35 [ERROR] location: package org.kie.workbench.common.services.backend.builder
09:19:35 [ERROR] /home/jenkins/workspace/drools-wb-pullrequests/upstream-repos/jbpm-form-modeler/jbpm-form-modeler-integrations/jbpm-form-modeler-data-modeler/src/main/java/org/jbpm/formModeler/dataModeler/integration/DataModelerService.java:[58,13] cannot find symbol
09:19:35 [ERROR] symbol:   class LRUBuilderCache
09:19:35 [ERROR] location: class org.jbpm.formModeler.dataModeler.integration.DataModelerService

@manstis I'll look, but in my local yesterday I've built and runned both kie-wb and kie-drools-wb.

Hello @manstis  you are right, I hadn't realized that you were talking about the old form modeller :( .
A PR has been sent with the fix

Jenkins please retest this.


Update formatting and wording in README.MD

Coverage remained the same at 27.218% when pulling 0c21e33f30577aa64d1458f4073a0170ff142aba on rozniak:dev into 875f092d93599f72d11384b949a9f9b5c477cc4f on paulsapps:dev.


stereo module infrared stream

Could I get the stereo module infrared #1 #2 (the left and right) stream?

Hi @yddcode   Yes, you can access the left and right infrared streams by assigning index numbers to the streams.
C++
https://github.com/IntelRealSense/librealsense/wiki/API-How-To#start-streaming-left-and-right-infrared-imagers
Python
https://github.com/IntelRealSense/librealsense/issues/3878#issuecomment-569550710
C#
https://github.com/IntelRealSense/librealsense/issues/3633#issuecomment-478460259

Hi @yddcode  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Build fails with TS2339 but property exists on interface

Current Behavior
Build fails with semantic error TS2339: Property 'name' does not exist on type 'Erc20', but it does exist.
It's only failing with name  property because it's the first prop of Erc20 prop that's called, if I try any other prop, fails as well
The interface Erc20 lives inside the src folder, under types/contracts/

Erc20 has name prop

Build failing
Expected behavior
Build the project without errors

Additional context
Erc20 interface is generated by typechain
Your environment

  System:
    OS: Linux 5.15 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (12) x64 AMD Ryzen 5 3600X 6-Core Processor
    Memory: 10.51 GB / 15.57 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Brave Browser: <IP_ADDRESS>
    Chrome: 97.0.4692.99
    Firefox: 110.0.1
  npmPackages:
    tsdx: ^0.14.1 => 0.14.1
    typescript: ^4.3.0 => 4.9.5

Did u ever figure this out? All of my typechain interfaces are erroring with tsdx

Same issue


EmrEtlRunner: replace m1.small with m1.medium in config.yml template

When using the instance size stated in the "example" config files and wiki - m1.small, I get an argument error:
ArgumentError (m1.small instance type is not supported with AMI version 3.6.0)
Upgrading to m1.medium solves the problem.
Iain

Thanks, scheduled


fields2cover: 1.2.1-1 in 'humble/distribution.yaml' [bloom]

Increasing version of package(s) in repository fields2cover to 1.2.1-1:

upstream repository: https://github.com/Fields2Cover/fields2cover.git
release repository: https://github.com/Fields2Cover/fields2cover-release.git
distro file: humble/distribution.yaml
bloom version: 0.10.7
previous version for package: null

@Gonzalo-Mier friendly ping

I don't understand why or how to solve this error. @mjcarroll do you have any insight? Thank you

Typically an entry will have a source, doc and release tag, something like:
  filters:
    doc:
      type: git
      url: https://github.com/ros/filters.git
      version: ros2
    release:
      tags:
        release: release/humble/{package}/{version}
      url: https://github.com/ros2-gbp/filters-release.git
      version: 2.1.0-3
    source:
      test_pull_requests: true
      type: git
      url: https://github.com/ros/filters.git
      version: ros2
    status: maintained

Can you update your pull request to at least include source, but maybe additionally doc?

Done. @mjcarroll Thank you for your support!


Get DEVICE_ARCH from target, remove the hardcoded one

Get device_arch from IPEX.

@quintinwang5 Please check if you are ok with c45c355f4d1cf101934e6a665386d027c2071fa0.

This PR requires changing pin of IPEX too.


Dedupe plugins

Overview
It's great that this plugin is including vite-tsconfig-paths by default. However, I noticed that if my local vite-config.ts uses this plugin, it clashes with Ladle's plugin and ultimately breaks how the modules are resolved.
Reproduction
Create a vite project and use vite-tsconfig-paths:
// vite.config.ts
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
    plugins: [tsconfigPaths(), /** rest plugins **/ ],
});

Without adding my tsconfigPaths, everything works fine.
Workaround
As a temporary workaround, I did the following:

Added a base config without vite-tsconfig-paths in the plugins prop
In my vite.config.ts, merge vite-base.config.ts into a config where I use tsconfigPaths() so my vite serve and vite build will work
Serve Ladle from vite-base.config.ts to avoid the plugin conflicts

Workaround code:
// vite.config.ts
import { mergeConfig } from 'vite';
import tsconfigPaths from 'vite-tsconfig-paths';
import viteBaseConfig from './vite-base.config';

export default mergeConfig(viteBaseConfig, {
    plugins: [tsconfigPaths()],
});

// vite-base.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
    plugins: [/** plugins here **/
    /** rest config **/
});

$ yarn ladle serve --viteConfig vite-base.config.ts

There is already a check for that. If you use add that plugin on your side, you should set root: process.cwd() - that might be your issue?

Adding your suggestion worked flawlessly. Thank you!