Add support for Python 3.11

https://blog.python.org/2022/10/python-3110-is-now-available.html
https://www.python.org/downloads/release/python-3110/
The default Python version remains unchanged (at 3.10.x) for now.
Note: Pipenv emits a RuntimeWarning on Python 3.11 which is coming from its vendored copy of attr. This was fixed in attr v22.1:
https://github.com/python-attrs/attrs/commit/a18b3957d55c669de56799a9a72ea31febe93ce4
However pipenv currently uses an older attr:
https://github.com/pypa/pipenv/blob/v2022.10.12/pipenv/vendor/vendor.txt#L2
Once there is a new pipenv release that includes an updated attr, we can update to it to prevent the warning in the logs.
GUS-W-10333186.

$ make publish
Deploy as version: v222 [y/n]? y

Tagging commit 7dc6bdec681d0a57fa8399ca99f48b127e65053e with v222...
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/heroku/heroku-buildpack-python
 * [new tag]         v222 -> v222

Publishing to the buildpack registry...
Two-factor code: ********************************************
Publishing buildpack heroku/python... done
Publishing buildpack was successful

Version  Released At               Status
───────  ────────────────────────  ─────────
222      2022-10-25T08:25:42.979Z  published

https://devcenter.heroku.com/articles/python-support#supported-runtimes
https://devcenter.heroku.com/changelog-items/2489


fix(markdown): table format

Does any other open PR do the same thing?

No
What issue is this PR fixing?
Props table format
How did you test this PR?

its a simple markdown change, looked good in review tab tho

@wael-fadlallah this pull request can't be merged as is because prettier is complaining about the .md file
you can test it yourself:
yarn format-check
I recommend you apply a prettier ignore rule to all *.md files
see https://prettier.io/docs/en/ignore.html


[ERROR] TypeError: Cannot read properties of undefined (reading 'hass')

Hello,
I've just saw this error in console while inspecting.
Everything is up to date.
Errors counting since last reboot, less than 5 minutes ago.

Versions:

Home Assistant: 2024.1.4
Kiosk-Mode: 5.2.0

Hi @RiderCrazy,
Following the stack trace, it originated from an entity change. Could you share your config and what are those entities that you are watching for changes?
Regards

Hi @elchininet,
I have launch the console again after your message, no more errors ¯_(ツ)_/¯

Hi @RiderCrazy,
That‘s wierd, just open an issue if you detect that is something that happens consistently.
Regards

Hi @RiderCrazy i've the same problem. But I don't known what entity create the problem.

`  domain: system_log
service: write
service_data:
logger: frontend.js.latest.202401040
message: >-
Unhandled promise rejection from Brave <IP_ADDRESS> on Mac OS 10.15.7
  TypeError: Cannot read properties of undefined (reading 'hass')

  t.<anonymous> (/hacsfiles/kiosk-mode/kiosk-mode.js:1:43922)

  /hacsfiles/kiosk-mode/kiosk-mode.js:1:1499

  Object.next (/hacsfiles/kiosk-mode/kiosk-mode.js:1:1604)

  /hacsfiles/kiosk-mode/kiosk-mode.js:1:520

  e (/hacsfiles/kiosk-mode/kiosk-mode.js:1:265)

  t.entityWatchCallback (/hacsfiles/kiosk-mode/kiosk-mode.js:1:43790)

  Object.callback (/hacsfiles/kiosk-mode/kiosk-mode.js:1:43661)

  callback
  (node_modules/home-assistant-js-websocket/dist/connection.js:23:33)
level: debug`

100errors each minute.


Remove ProtoFormatter

I was thinking about extract ProtoFormatter to package, but this is a difficult task.

Since Prometheus 2.0 no longer supports the Protobuf-based format

Released in 2.0.0


Charms not showing up

When I open a save file from before I downloaded the mod, the charms do not show up when I try to find them. (Yes i'm looking in the correct spots) It works just fine for saves made after I got the mod though.

This is the intended behaviour of the mod. Only saves created with Transcendence installed get the new charms; existing ones are not changed in any way.

oh ok
On Wed, Dec 25, 2024 at 7:45 PM Diogo Pinela @.***>
wrote:

Closed #30 https://github.com/dpinela/Transcendence/issues/30 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/dpinela/Transcendence/issues/30#event-15762641588,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BN7HUEKPH4AVCPDKFHIJ52L2HNNU7AVCNFSM6AAAAABUGQTIEWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVG43DENRUGE2TQOA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Fix caption integration

This may be a little hacky, but it does fix in-band caption integration on versions of video.js > 5.13.0.
Related to https://github.com/Peer5/videojs-contrib-hls.js/issues/17

There are several drawing/display issues with live streams.   It's very hard to visually follow.
Here's an example captioned live stream:
https://1-fss-fso35.streamhoster.com/lv_ntv/broadcast1/playlist.m3u8
The hls.js demo displays this perfectly (new lines on bottom and grow as new text arrives, pushing old content up):
http://streambox.fr/mse/hls.js-0.7.6/demo/
Is hls.js leveraging native caption drawing in the browser?  How can similar behavior be ported to videojs?

@ranuser99 Did you try reverting https://github.com/videojs/video.js/pull/3798, as it seems the problems started after that commit

The issue is apparently solved using older videojs  5.13.2 (from another user's suggestion).

superseded by #25
thanks for the PR


[BUG] Proxy auth works for HTTP but NOT for socks5!

^title.

Hi, @Nou4r. This issue should be resolved on v0.5.2.
Now you can use authorization for SOCKSv5 (e.g. socks5://USER[:PASS]@IP:PORT).

Hi, @Nou4r. This issue should be resolved on v0.5.2.
Now you can use authorization for SOCKSv5 (e.g. socks5://USER[:PASS]@IP:PORT).

doesn't work, no response


Merge outbox subscriber

This PR merges the outbox subscriber from the V3 branch to the main branch, also setting the version to 3.0.0.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

151 of 159 (94.97%)  changed or added relevant lines in 13 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 91.451%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/hexkit/protocols/daosub.py
13
15
86.67%

src/hexkit/providers/akafka/provider/daosub.py
43
45
95.56%

src/hexkit/providers/akafka/provider/eventpub.py
41
45
91.11%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
1658

Relevant Lines:
1813

💛  - Coveralls


update: maintainers list and evolution resources

Updating maintainers list and the evolution resource files. Made using the update-maintainers periodic ProwJob. Do not edit this PR.
In case you wanna change your name or your company change this file.
/kind documentation

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leogr, poiana
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: f2e5693cb20b1640d429dad48a4e64319f13614f


Fix bug in website badge (regexp was too greedy)

@espadrine Thanks for merging PR #639. I tested it a bit, and it seems it doesn't work when a path is given (instead of just a domain name).
I think I found the cause of the bug, it seems I got caught by a greedy regexp when separating the domain name from the rest of the URL in the syntax, and part of the domain + URL is gobbled up in the group matching the protocol. Hopefully this patch fixes that.

Thanks for this, @jsmaniac! Sorry for the delay.


Team Skill assessment is needed.

No, not a test on your C++ skills, but what we all can collectively do, and where to put each member, and if we have enough people, split them into teams.
It'll help us immensely figure out who to have work on what.
I personally don't know a Line of C++ to save my life (I'm lucky I can read and write bash) but I guess I'll be trusted with maintain the repo itself and handling matters like reporting and helping with bugs, and what not.
I don't want to leave anyone out here. If you have a skill we can use, don't be afraid to show it here.

I think so far We're good with lead devs being Skipper and Jobbin. Other areas we can lean on the community for contribs which me and skipper can probably vet through. I'll continue to maintain the repo with the lead devs, Hawkbit and Decaff and if changes are needed, we'll go from there.


Fixes and improvements for the new CI

Issue
https://gravitee.atlassian.net/browse/APIM-2635
Description
Main changes:

Fix job-snyk-apim-charts
Add license headers in typescript files
Rename db-repositories-test-container to repositories-tests

📚  View the storybook of this branch here

Oops 130 file changes 💦


Rebase https://github.com/P2Enjoy/kohya_ss ?

Your fork of kohya_ss is behind, could you rebase it? Issues are disabled on that repo.
For those of us who know what they're doing, it'd be preferable to use without Docker.
Also, I'm not sure why the original code used tkinter, as web browsers provide a file dialog.
I think removing that and diverging from upstream would be best.

yes. having normal code instead of docker would help a bit

Hi @dsully and @runner22k,
the fork might be "outdated" sometimes but it is "a feature" XD
Seriously, the fork WILL ONLY BE UPDATED if the linux build is fully stable.
I've added a description in the homepage of the fork

@dsully the image was updated with the latest changes :)

Thank you!

Probably shouldn't commit the .idea/ files to your fork BTW.


error handling/ notification when shell integration fails

we should discuss what should happen when process start results in an error when there are shellIntegrationArgs provided

restart the process without those args?
inform the user and suggest they disable shell integration?
disable shell integration?
https://github.com/microsoft/vscode/blob/63e4626c5a9c87972a7fd098c047faf5a3d49457/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L1279-L1289

We want to make sure that failures that happen shortly after the process is created are handled, where the process state is ProcessState.Launching, which would be a special case for this case:
https://github.com/microsoft/vscode/blob/28497c879865b47de63690a19b372ad8f78dd898/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts#L2300-L2305

Let's start with just a message similar to above but that points to the shell integration setting as well. Note that the failure still might not be caused by shell integration.


Intro Text for Click Actions

As you have implemented the "Intro Text" for Click Refresh, I'd like also to have the same one in Click Actions.

No, this will increase complexity in code so I'd like to skip implementing this in the first version.


Failed to set values with characters like '%&' into OVA properties.

Setting password with special characters like '%&', failed to apply in OVA deployment.

Verified and passed with latest ova build. Password tried is "#$VMware.c0m%&@"


a nodeclaim not being registered results in other node claims not being created from other node pools

Description
Observed Behavior:
When a nodeclaim is failing for a specific nodepool, other nodeclaims are not scheduled unless that nodeclaim comes up or is deleted.
Expected Behavior:
nodeclaims from different nodepools should be independent from being scheduled.
Reproduction Steps (Please include YAML):
build your own binary that creates a fake tag that is starts with a -. schedule multiple pods on different nodepools. watch nodeclaim being created for first nodepool, do not see how other nodeclaim for different nodepool gets scheduled until nodeclaim is deleted.
Versions:

Chart Version:
Kubernetes Version (kubectl version):

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

interested in working on the issue

@tvonhacht-apple Why is the NodeClaim fail launch the underlaying node? Also, did any pending pods that were created after the NodeClaim that were able to be scheduled to the node Karpenter expected be register?

The behavior we found, that it was not related NodePools or EC2NodeClasses. It would just overall not bring up any new nodes, until node correctly register with Karpenter

When a nodeclaim is failing for a specific nodepool, other nodeclaims are not scheduled unless that nodeclaim comes up or is deleted

This is interesting. So...the reason that we currently don't allow ourselves to launch when we get a failure is because we don't know what that capacity is going to look like. Scheduling without knowing what that capacity could look like means that we could make the wrong decision when trying to reschedule without this capacity resolving and the prospect of unblocking here is somewhat tricky.
One interesting idea here is still considering that NodeClaim capacity as capacity that can be scheduled against and continue to model pods against that capacity in a new scheduling round rather than completely stopping simulating. There's a few considerations that we'd have to make here:

NodeClaims could launch while we are simulating -- the sizing of the node that actually gets launched is going to affect the scheduling decision that we just went with, so we probably have to throw it out, so we waste a bit more work
NodeClaims that were already created should continue to be able to be constrained if they haven't launched. This allows the scheduling simulation to update the existing NodeClaims with additional constraints after they have already been created -- so it can make an initial decision, but then edit this decision. This also has the potential to have race conditions because it's possible for the NodeClaim to launch while we are editing it -- in this case potentially getting a smaller instance type than what we assumed from the previous scheduling simulation.

Overall, I think our position is basically: NodeClaims failing in this way should generally be cause by misconfigurations in EC2NodeClass so over-indexing for trying to solve this case may not be worth the effort AND the effort of trying to solve for this and avoid all of pitfalls and potential race conditions is going to take a good bit of thought, is going to make the code more complicated, and is going to be more difficult to test.

@tvonhacht-apple Are you seeing pending pods in the cluster that will not fit on NodeClaims created by Karpenter? Are seeing that pods that should be scheduled on NodePool #A are pending until NodeClaims owned by NodePool #B are registered? Also are you able to share any logs during this event?


Bug: OADP 1.3.0 restore shows "The secret is not getting created" on openshift 4.15 cluster.

Only developers will use GitHub issues for development purposes
Description:
When using OADP 1.3.0 to run restore a namespace on openshift 4.15 cluster, the metadata inside the namespace restore works. But even though there is no secret yaml inside the namespace, the velero log shows "The secret is not getting created". But OADP 1.3.0 works on openshift 4.14 cluster.
Velero log part:
https://gist.github.com/Frank51/0bfbe166fec2eff8be2e94cc423c0cbb
Workaround:
After upgrading OADP from 1.3.0 to 1.3.3. The restore works then. And this error message no longer shows up.

My guess is https://github.com/openshift/openshift-velero-plugin/pull/228 fixes it.

cherrypick to OADP 1.3 in https://github.com/openshift/openshift-velero-plugin/pull/235 which goes into 1.3.1
as part of https://issues.redhat.com/browse/OADP-3598


Timer control event change_tick_interval truncates float values to int.

Given the following config:
timers:
   meteorTimer:
     start_value: 30
     end_value: 0
     tick_interval: 1s
     direction: down
     start_running: yes
     control_events:
      - event: some_event
        action: change_tick_interval
        value: 0.1

When 'some_event' fires, the tick interval is set to 0 and the timer immediately runs out. I found that this is because the handler created for this is initialized with a zero. If I changed the value to 2, the handler was initialized to 2 and the tick_interval was doubled as expected.  I checked into the config_spec.py and found the issue:
timer_control_events:  # subconfig for mode timers
    __valid_in__: None
    action: single|enum(add,subtract,jump,start,stop,reset,restart,pause,set_tick_interval,change_tick_interval,\
reset_tick_interval)|
    event: single|str|
    value: single|int|None

The value is being validated as an int, which causes the value to be cast to int, loosing the decimals. When I changed this to 'num' the functionality worked as expected, so I believe that's all the fix requires.
Also, the documentation for both the timer.py change_tick_interval method and the 'timers:' page in the online docs do not explain this functionality correctly. The're both wrong, but in different ways.

So far we expect int values for ticks. Usually you want a timer number for time on your slides. In the future we will get format strings to ensure that with floats but currently it might cause issues for other people. I guess we can change it for a future release but probably not for 0.50.

To be clear, I wasn't talking about setting the tick value, but rather changing the tick interval. It's designed as a multiplier, so if your current interval is 1000ms and you do a change of 2, it's now 2x1000ms = 2000ms.  Likewise, if you do a change of 0.5 from the original interval, it's 0.5x1000ms = 500ms. So if this won't take a decimal, there's no way to ever decrement the interval.
However, I can see that, if you make value allow decimals, a user could also use it to set decimals for other things like the number of ticks, which would be bad.
So maybe instead of making 'value' take decimals, you add a new field called 'change' that will take decimals, and modify the change_tick_interval control event to use the 'change' field.
Another option would be to make people provide percentages for change as a whole number. In other words, if you want to double the tick interval, you provide a value of 200. If you want to halve the interval, you provide a value of 50. Then you would just do a value /= 100 in the change_tick_interval method. But then that's a breaking change, so...
Finally, just to explain the use case, I'm using a timer to decide which of several light shows to call. The lower the timer gets, it starts a progressively faster speed light show. If the player successfully completes the objective, the timer resets, but it runs down faster, so on and so forth until they fail the objective. Thus the reason I need to be able to decrement.
I hope that helps to explain what this is about. :)
Thanks!
Kaydee

That makes sense. We can probably make it num or float and then manually cast it to int where we need an int. If you want you can do a PR for that or I can do that tonight or tomorrow.


Fix data structure in "Joins in EQL"

In the last example of "Joins in EQL" subsection, :list/items field in returned data structure should be [{:todo/label ...} {:todo/label ...} {:todo/label...}] instead of [{:todo/label ... :todo/label ... :todo/label ...}]

Many thanks!


home.html-to-index.html

Issue
(#32)
Description
To resolve the "Cannot GET /Home.html" error, the Home button's link should be updated to direct users to index.html. This can be achieved by modifying the HTML code for the Home button. Ensure that the link is set correctly:
Related Issues
None
Type of PR

[Bug] ()

Screenshots / videos (if applicable)

Checklist

[X] I have gone through the contributing guide
[X] I have updated my branch and synced it with project main branch before making this PR
[X] I have performed a self-review of my code
[X] I have tested the changes thoroughly before submitting this pull request.
[X] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[X] I have commented my code, particularly in hard-to-understand areas.

@Anjaliavv51 try now


Design "flaw" on loading screen

Hey @crwntec ,
i know that this repo is currently WIP, but i found a minor design flaw and I think it should be a quick fix.
 I don't know if you used a fixed position for it.
Here the Screenshot:

As I said, small thing but it kinda set me off. If it is not fixable, I am sorry if I wasted your time.
Keep it up and good luck.
EDIT: I hope it helps to mention, that I used the link in the readme to go to the page...

Hey Teconia
I've noticed it myself and it's definitely an easy one to fix. I've updated the roadmap and will fix it as soon as I get back to the project.
Btw I've never thought that anybody would see this repo so thanks for your interest in the project 😃


Improve ballerina-lang gradle scripts

Description:
The ballerina-lang is a Gradle project with multiple sub projects. We need to review existing Gradle script and do improvements like remove hard coded paths, reduce config processing, make scripts declarative, Check on build times

[ ] Remove hard coded paths
[ ] Reduce config prodeccing
[ ] Make scripts declarative
[x] Cleanup .gitignore file
[x] Implement Gradle plugin
[x] Publish Gradle plugin
[x] Migrate stdlibs to Gradle plugin

Above effort has been done as a separate gradle plugin by
https://github.com/ballerina-platform/plugin-gradle/


Deliver's submit_for_review is for app review, not for beta review

I noticed the "Submit for TestFlight External Testing" in main.go adds the flag --submit_for_review.
AFAIK, Deliver's --submit_for_review flag will submit the app for appstore review (i.e. not for beta review or external testing).
Some ideas to fix this:

I think we can simply change copy from "Submit for TestFlight External Testing" to "Submit for Review" (and also the description text).
"Submit for TestFlight External Testing"  is still achievable via Pilot. I don't think Deliver supports beta review, CMIIW.

what do you think?

Thanks for reporting.

Sure, @doomsayer13. Anyways, what do you think on this problem? I might have some time this weekend to work on this issue. Any comments on my proposed ideas, before I start hacking?


Alter filesystem remount task

Hi,
This is an updated version of the existing code which allows multiple filesystems to be remounted - and should work 'well' just by adding another template. Also fixes a bug where filesystems are remounted exec instead of no exec.
I've checked the syntax is correct by installing in containers but haven't had a chance to test it on something with demountable filesystems - I will do so when possible, hopefully in the next few days.

Thx, for backward compatibility I added a apt_remount_filesystems var to make the difference more clear.

Thanks


Add user signup functions to user store

stores/user.store currently has a couple functions for logging in users, and there is a separate set of functions to handle user migration in utils/user-migration. Need extra functionality in user store to:

register a user with the input username and password via firebase auth
create a new database entry at Users/${user.email} which contains the signup info fields (if registration successful)

Could add consideration as to how to handle situation where one step success and other step fail
child of #8

@chrismclarke I will be happy to continue on this issue ; )

closed with #357


LiveReload breaks production with react 18

What version of Remix are you using?
1.3.4
Steps to Reproduce

Have an app
Develop app in development mode
Switch to production (cross-env NODE_ENV=production remix-serve build)
LiveReload breaks the render resulting in a blank screen

Expected Behavior
LiveReload should not break production
Actual Behavior
The screen flashes the correct content (I think probably the server rendering) but then disappears. When looking at the dev tools, all children of body have disappeared. The console then logs several errors most notably:
Warning: Expected server HTML to contain a matching <script> in <body>.
    at script
    at LiveReload2 (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:2232:3)
    at body
    at html
    at App (http://localhost:3000/build/_shared/chunk-SFXPWZ4C.js:6143:18)
    at ThemeProvider2 (http://localhost:3000/build/_shared/chunk-SFXPWZ4C.js:93:31)
    at AppWithProviders (http://localhost:3000/build/_shared/chunk-SFXPWZ4C.js:6136:16)
    at RemixRoute (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:1639:3)
    at Routes (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:1622:7)
    at Router (http://localhost:3000/build/_shared/chunk-6E4C6WK5.js:686:15)
    at RemixCatchBoundary (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:132:10)
    at RemixErrorBoundary (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:57:5)
    at RemixEntry (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:1519:12)
    at RemixBrowser (http://localhost:3000/build/_shared/chunk-FMOYLMYS.js:2280:27)
Uncaught Error: Hydration failed because the initial UI does not match what was rendered on the server.
    at throwOnHydrationMismatch (react-dom.development.js:14344:9)
    at tryToClaimNextHydratableInstance (react-dom.development.js:14357:7)
    at updateHostComponent$1 (react-dom.development.js:20636:5)
    at beginWork (react-dom.development.js:22373:14)
    at HTMLUnknownElement.callCallback2 (react-dom.development.js:4157:14)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:4206:16)
    at invokeGuardedCallback (react-dom.development.js:4270:31)
    at beginWork$1 (react-dom.development.js:27243:7)
    at performUnitOfWork (react-dom.development.js:26392:12)
    at workLoopSync (react-dom.development.js:26303:5)

Gating it with {process.env.NODE_ENV === "development" ? <LiveReload /> : null} works but the docs say that it is fine to leave in since it will only do anything in development. If that is no longer true, the docs should probably be updated to reflect that.

You mean hydration right? LiveReload shouldn't be involved at all in production

You mean hydration right? LiveReload shouldn't be involved at all in production

When hydrating in a production build the problem is present. When hydrating in a development build, there is no issue.

Building and running a Remix app should be done using the same NODE_ENV.
@DAlperin feel free to reopen if you have a use-case for needing to build in development but run in production.


Update cleanmymac to version 3

Will submit a separate PR to cask-versions for the "legacy" version 2

See #10465 - that's probably more complete as it solves the OSX version dependencies too?

Yes - it is more complete.


Explore Entities in Search

It is currently not possible to just scroll through all entities. The user needs a way to just "flow" through the data.
We want to have an "Explore" button that just loads search results without filter query. Maybe then we also need a "normal" search button.

@DaTebe
i would start here with just showing what ever Elasticsearch want by default

@setaman can you upload a screenshot? Tank you

@DaTebe
The main difference is that now its possible just to scroll down through the results returned from Elasticsearch by default.

For the case there is no data:


Meta DEx trading interface

What do you think should be added, removed, or changed?
To continue the discussion from the other thread:

... we shouldn't round the price in the order book, but we should show the effective unit price after a match is made.

I agree that showing the effective unit price is the way to go, and in general, I have no objections against a "very accurate" view of the available offers, but I'm wondering, if it's necessary, given that unit prices are shown "per MSC", and the input fields for the price are also "per MSC".
My first instinct was to show only up to 8 decimal places, as this aligns well with the minimal tradable amount of MSC, and then adjust the numbers such that a trade is executed, if the user creates an order with that price. For example: say there is an offer with an effective unit price of 0.10002555555555.., then I'd assume, the user would enter either 0.10002555 or 0.10002556 to match that offer, and if this is the case, I was wondering, if we might just show the price rounded up or down to one willet right from the beginning?

Just as a heads up, I need to redo some of the UI data sources - the pricing is actually obtained from the price level in the metadex maps - but it turns out that was bad data because of the bug in persistence inverting the price.  We now have a .inversePrice() in the CMPMetaDEx class so I think I should just need to switch over to using that.
I'd like to get some kind of consolidation going at some point (especially Class C stuff)

I was wondering, if we might just show the price rounded up or down to one willet right from the beginning?

I actually favour this methodology especially at the UI layer - there comes a point where ease of use trumps - look at DEx v1 - there is no volume because it's a PITA to use.  Thus I vote where things are 'safe' to do and improve the experience for the user (such as DexX's suggestion) then we go for it.

@dexX7 I'm just trying to improve the trading interface and noticed on another thread you mentioned:

Swap buy and sell offers area (is there any exchange where this is the other way around?)

That's an interesting point - I did actually poke around a few exchanges before designing it the way I did - it seemed logical that someone would be buying into a sell order, or selling into a buy order hence listing sell offers on the buy side and listing buy offers on the sell side.
Examples - BTC-e and Poloniex are like the way I originally designed it, Bitstamp is like your modified screenie above.

Long story short I'd like to pick a direction - any further thoughts on this at all mate?

someone would be buying into a sell order, or selling into a buy order

Hmm.. this appears to be different from exchange to exchange. I think buy orders should be listed on the left, while sell orders should be listed on the right. This seems more natural (left to right, top to bottom). I'm unsure about the input masks.

Quick Q guys.  Do you think the UI needs to accommodate all potential scenarios on the MetaDEx?
Long story short I'm running into numerous complications due to the fact the "unit price" can be less that the minimum decimal fraction of an MSC.  So for example it is possible to create a trade with a unit price of:
0.000000000000000000000000001084 (0.00000001 tokens desired / 9,223,372,036,854,775,807 tokens for sale)

However since we have agreed to price everything in MSC, it is not valid to say allow the user to interact on a level that permits purchasing 1 unit per 0.000000000000000000000000001084 MSC, simply because the user cannot transact 0.000000000000000000000000001084 MSC.
What I guess I'm proposing is that (purely from a UI perspective) trades with a unit price under 0.00000001 MSC will not be tradeable via the UI.  They would not be shown, nor could they be acted upon or created (again UI only, you could still create such a trade at the RPC layer should you so desire).
This would permit the continuation of the model where all prices are shown in MSC, and not provide complexities for the user resulting from prices that are under that of the minimum transact-able amount of MSC (0.00000001 MSC).
I'm leaning in this direction because whilst the protocol does support these types of miniscule priced trades (eg 0.00000001 tokens desired / 9,223,372,036,854,775,807 tokens for sale) it is highly unlikely that an 'end user' at the UI layer is going to have a need to create or interact with them.
So, TL:DR; I'm considering making the UI limited to a preicision of 0.00000001 MSC, with prices rounded to the nearest willet and trades with prices under 1 willet considered 'advanced trades' and left out of the UI entirely.
What do you think?

The above doesn't seem to work particularly well either based on my local experiments :(

Note, I really don't want to abandon the "buy/sell" model we have for the UI at the moment because it's something users will be easily able to pick up - at the moment it's looking more and more like we need to ditch that completely and move to forcing the user to supply raw amountForSale and amountDesired values but I'm uber worried if we do this then MetaDEx will go the way of DEx v1 - ie no-one will use it because it's just so unfriendly and unintuitive :(

FYI, the problem with using rounding in the UI - we click a sell offer (which automatically sets up the buy):

The price is actually 0.10999999997051402461909080516077581355283271004378 but comes to 0.11 when display precision is set to 8 decimals.  The UI must inherently setup trades based on the "price per SPT" and I fear issues like this will only cause user confusion.

The price is actually ...

Not all rational numbers are finite, so even this may not be precise enough.
I see the dilemma.

I'm uber worried if we do this then MetaDEx will go the way of DEx v1.

It's hard to tell, how the core client is used, and my guess is that most users use Omni Wallet or other thin clients, and it's probably clear we can't solve all UI issues in the tiny QT interface.
I'd say: let's try to make the user experience as good as possible, even if this comes at the cost of limiting the user's actions (i.e. no trading of 0.0000001 for 2^63-1 or so), instead of trying to fit everything together, or falling back to "amount desired" and "amount for sale".

Re: the very small numbers - I appreciate that this is a real math constraint but let's be realistic, how much of a use case is it for someone to buy a quantity valued at a millionth of a penny? (or less...)
Just clip it, disable it in the UI, solved. Omnicore logic-wise, you shouldn't be able to buy anything less than 1 willet worth of a smart property.

the user needs to spend a touch over half a Mastercoin more than necessary

My apologies, this is not accurate - my experiments were based on the existing (XDOUBLE) MetaDEx logic, and we can see from the following that problematic math was responsible for such a big difference (I thought half a Mastercoin was far, far too big a skew just from enforcing 8 decimal pricing):
If we look at the trade (the one I circled in the screenie) directly in the map:
0.10999999997051402461909080516077581355283271004378:trade #12<PHONE_NUMBER>6 for #1 35.81363635
And then look at our getter functions (also used by the UI):
displayUnitPrice() 0.11000000
displayInversePrice() 9.09090909
getAmountForSale()<PHONE_NUMBER>6
getAmountDesired()<PHONE_NUMBER>

We can see that getAmountDesired() is ~0.5 MSC off what is in the map<PHONE_NUMBER> vs<PHONE_NUMBER>).
TL:DR; looks like 8 decimal pricing might be workable after all in the UI without crazy skew (which I was worried would turn off users).  I'm about to start rewriting UI to use rationals as per @dexX7's excellent recent work and I'm hopeful this will be resolved.  Will update here when I have more :)

Displaying only a certain number of decimal places, and restricting the number of decimal places to enter, goes hand in hand, as it seems.
Let's assume for a moment all users are UI users, and let's say all UI users can only enter prices with 8 decimal places, then all prices have 8 decimal places, right?
In practise it's unfortunally not that easy, because there are prices with more than 8 decimal places, which may create a disadvantage for UI users, and likely a rather odd impression, if total MSC doesn't equal displayed price * total SPx.

Let's assume for a moment all users are UI users, and let's say all UI users can only enter prices with 8 decimal places, then all prices have 8 decimal places, right?

That's indeed correct :)

In practise it's unfortunally not that easy, because there are prices with more than 8 decimal places

I'm looking into what kind of skew we're looking at here, and from my early experiments it should be a willet or less, but I need to do more to confirm this.
I'm currently looking at how to work with these new rational prices - specifically a couple of things:

converting them reliably to a string format with 8 decimal places (which I see you go over to dec_float first in xToString but only if the range is suitable for int64 so doesn't cover all cases)
the best approach to divide a rational by COIN - I see in the boost rational docs that the arithmetic operator / is valid so I may be able to do it directly

Early days for me while I poke around and learn a bit (I haven't worked with rationals like this before) but if you have any suggestions on 1 and 2 feel free to shout mate :)

and likely a rather odd impression, if total MSC doesn't equal displayed price * total SPx.

This is exactly the behaviour I'm trying to avoid - again should know more soon :)

The rangeInt64() checks were only relevant for intermediate results, in particular for the amount that one could buy, based on the seller's price and buyer's available amount, which can be larger than int64_t, but in the end all prices should be within rangeInt64().

how to work with these new rational prices

In general, it's possible to do:
rational_t x(1, 2);   // 1 / 2
rational_t y = x / 3; // 1 / 2 / 3
rational_t z = price / COIN;

converting them reliably to a string format with 8 decimal places

There are probably three options:

xToString(), which should return the price as string with 50 decimal places

convert the price to dec_float, as done in xToString(), and then work with the floating number

or use xToInt64() to convert to int64_t , which also rounds correctly in either way, and then format and convert to string via FormatDivisibleMP(), FormatIndivisibleMP() or FormatMP()

The last route is probably the easiest and most reliable.

Thanks for the advice mate :)
I think I was getting myself confused (I'm a bit slow today!!!) eg trade #12<PHONE_NUMBER>6 for #1 35.81363635 is a price of ~0.10999999997051402461909080516078 and the fractional part of that number does not fit into int64_t - but I realize now that's irrelevant (it's the denominator and numerator for the rational that need to fit into int64_t).
Thanks for walking me through it mate :)

The last route is probably the easiest and most reliable.

No joy for now, passing the price into xToInt64 makes every price = 1 willet - it's probably something straight forward but having a hard time focusing (bit distracted) - will tackle it again tomorrow with a set of fresh eyes :)
Unit Price: xToString=1.00000000000000000000000000000000000000000000000000 xToInt64=1 DividedByCoin=false
Unit Price: xToString=0.00000000333333333333333333333333333333333333333333 xToInt64=1 DividedByCoin=true
Unit Price: xToString=0.00000100000000000000000000000000000000000000000000 xToInt64=1 DividedByCoin=true
Unit Price: xToString=0.00000010000000000000000000000000000000000000000000 xToInt64=1 DividedByCoin=true
Unit Price: xToString=0.00000001000000000000000000000000000000000000000000 xToInt64=1 DividedByCoin=true

EDIT: scratch that, where the integer part of the prices is >1 ...

Ahh, wait. In this case FormatDivisibleMP(xToInt64(price * COIN)) could work.

Ahh, wait

It's not just about dividing by COIN mate, even those that we don't modify aren't coming out right - for example:
Display Unit Price Requested:
               Amount For Sale: 50000000 of 1
                Amount Desired:<PHONE_NUMBER> of 12
Unmodified Rational Unit Price: xToString=100.000000000000000000... xToInt64=100
    Divided by COIN Unit Price: xToString=100.000000000000000000... xToInt64=100 DividedByCoin=false
Unmodified Rational Invs Price: xToString=0.01000000000000000000... xToInt64=1
    Divided by COIN Invs Price: xToString=0.01000000000000000000... xToInt64=1 DividedByCoin=false

Looking into it a bit further now - haven't spent the day having tests today so hopefully I'll be in a clearer state of mind hehe!!! :)

OK, think I have it licked with https://github.com/zathras-crypto/mastercore/commit/cb57e5a1a3af96eb48de3be70fa3512c6f0fc244
The good news is after @dexX7's fixes if we now revisit that same trade we can see that unit price rounding to 8 decimal places doesn't seem to pose an issue for the calculated total.  There may be some potential cases where we may see up to a 1 willet skew but I don't think that'll scare off users.

I'm very happy that it works. :)

There may be some potential cases where we may see up to a 1 willet skew but I don't think that'll scare off users.

Could you document one of such cases, if you stumble upon one? I agree, one willet isn't a big deal, if the displayed amount is rounded such that an order fills nevertheless. What I'd like to avoid is a situation where an user buys/sells tokens at the displayed price, but then misses by one willet.

I currently see no specifics to discuss, and once there is, we can open a new issue. /close


Allow advanced search

Allow advance search using the Fuse library,
Allow search on :

[x] Description

[ ] Build-Depends

[ ] Features

[ ] Versions

This requires changing the layout of the JSON created by the parser

Description is now used in search (cd058d2)
The JSON layout was changed with the manifest support (e881f2b)


Typescript to Python JSII CDK Construct Interface issue

:question: Guidance

Affected Languages

[x] TypeScript or Javascript
[x] Python
[ ] Java
[ ] .NET (C#, F#, ...)
[ ] Go

General Information

JSII Version: 1.24.0
Platform: Mac OS

The Question
I converted an existing AWS CDK Construct Library to use Projen & JSII, at the moment I want to target NPM and PyPi for releases of the Construct Library. When using JSII I got a compilation error for an interface I was using to hold properties during the initialization of my Construct so I set it to a behavioral interface by prefacing it with an 'I'. The Javascript version of the Construct takes in a scope, id, and props which are configurations the user can setup and they will be used later in the Construct code. I was able to get JSII to produce the Python artifacts and published it to TestPyPi. I began trying to test my Python CDK Construct produced by JSII but am running into issues with instantiating my Construct. When I attempt to pass in the props my cdk synth fails saying I got an unexpected keyword argument. The constructor went from this in Typescript:
  constructor(scope: cdk.Construct, id: string, props: DatadogProps) {
    super(scope, id);
    this.scope = scope;
    this.props = props;
    validateProps(this.props);
    this.transport = new Transport(
      this.props.flushMetricsToLogs,
      this.props.site,
      this.props.apiKey,
      this.props.apiKMSKey,
      this.props.extensionLayerVersion,
    );
  }

To this in Python:
def __init__(
        self,
        scope: aws_cdk.core.Construct,
        id: builtins.str,
        props: "IDatadogProps",
    ) -> None:
        '''
        :param scope: -
        :param id: -
        :param props: -
        '''
        jsii.create(Datadog, self, [scope, id, props])

It seems like props is being assigned to a string (IDatadogProps) in the constructor and is not really letting someone provide properties through the constructor. I am fairly new to JSII so I am not sure how JSII handles a situation like this.
To sum it up I created a Python artifact via JSII based on a Typescript CDK Construct and published it to TestPyPi, I pulled that package down to test it in a CDK stack but the constructor is not working like it does in the NPM package. Im not sure if I am just interacting with my Python CDK Construct incorrectly or if I need to change something in the Typescript project that the Python Package originated from. If anyone needs more details feel free to ask! Thank you in advance.

Im bumping this to see if anyone can help, let me know if you need more details.

This was the setter generated by JSII for the interface, i'm not sure why the "..." were included:
    @node_layer_version.setter
    def node_layer_version(self, value: typing.Optional[jsii.Number]) -> None:
        ...

I am trying to set the properties using this setter that JSII provided:
Setter I am trying to invoke (in python)
@props.setter
    def props(self, value: "IDatadogProps") -> None:
        jsii.set(self, "props", value)

Code I am invoking the setter with
        props = {
            'node_layer_version': 49
        }
        datadog = Datadog(self, "Datadog", Datadog.props.setter(jsii.create("Object", props)))

Error I am receiving:
fqn=klass.__jsii_type__ or "Object",
AttributeError: 'str' object has no attribute '__jsii_type__'
Subprocess exited with error 1

Can anyone explain what I am doing wrong?

Changing from a behavioral interface to a struct fixed my issue https://aws.github.io/jsii/user-guides/lib-author/typescript-restrictions/#interfaces


interactive bots: Create myanimelist bot

This plugin responds on the same stream and topic with the link of to the anime's
myanimelist page and some details along with it.
It looks for messages starting with '@mal'.
Example Response
https://myanimelist.net/anime/11757/Sword_Art_Online
TV (25 eps) | Scored 7.83 | 895,815 members

Example usage

This doesn't use the myanimelist API, instead it just uses requests to retrieve, beautiful soup and regex to filter.

Automated message from Dropbox CLA bot
@jQwotos, it looks like you've already signed the Dropbox CLA. Thanks!

@femnad How would you recommend retrieving login credentials?
I was thinking of

A PM to the bot, but that would require that every time the bot is started it will require the user to send a PM
Credentials in mal.py

USERNAME = '[Please change]'
PASSWORD = '[Please change]'

(I don't believe I can pass a config file to the script yet on zulip because of the way the parser is handled)

Having in on a predefined config file sounds good to me.

@femnad I made some changes to the contrib_bot.
It's now using the API but requires a username and password. (Returns with error msg and exits if not changed).
Also cleaned up all of the pep8 violations. (I believe so atleast)

The linter complains about Python 3 compatibility though. Do you need that future print import? It seems that you are not doing anything Python 2 or Python 3 specific with print.

Yea, not sure why it wants me to do a future import since I don't have a multi string print.
I imported it anyways and local test pass again. So let's see what travis says this time.

@jQwotos, looks good overall. Please take a look at the inline comments.

@jQwotos, looks pretty good. Left some feedback.

@jQwotos are you still working on this?

@trueskawka currently working on exam preps, I will continue working on this later on after exams. (that would be after code in has ended as well)

Closing.  This can be reopened if there is follow-up.


Add Mainframe Token (MFT)

Added token information for Mainframe Token (MFT) https://mainframe.com

Please refer to the following:
"address": "0xDF2C7238198Ad8B389666574f2d8bc411A4b7428",


Button can be pressed on android  #58

Button can be pressed on android  #58

This works, please merge it!

+1

+1

+1


Error when trying to upload image

@jagguli , if you are on brave, disable shields for the website..
deso identity has been having this issue since ages..


Hi, I have opened week 0 and wanted to follow the instructions by clicking the line and nothing happen, the boxes are not executables

Have you followed the instructions in the README?


Add a date argument to report()

This will be helpful in generating the post-season report that contains summaries of multiple openers. The bootstrapped output from each opener can be compiled into one big data frame, then report() can be looped over to produce the relevant summaries.

Closed in #145.


Study rebase

Summary Change Description
This is simply a rebase and fix that merges the infusates/animals/samples loader work with the peak annotation PR series, to serve as a branch point off which to do the submission refactor work.
Affected Issues/Pull Requests
This PR cannot be reviewed until all extant PRs below it are merged into main.

Partially addresses #829
Depends on:

#999
#1005

Next PR: #1007

Review Notes
This PR cannot be reviewed until all extant PRs below it are merged into main.
Checklist

This pull request will be merged once the following requirements are met.  The
author and/or reviewers should uncheck any unmet requirements:

Review requirements

Minimum approvals: 1
No changes requested
All blocking issues resolved by reviewers
Specific reviewers: @add_username_here

Review period: 2 days

Associated issue/pull request requirements:

[x] All requirements in affected issues marked "resolved" are satisfied
[x] All required pull requests are merged (or none)

Basic requirements

[x] All linters pass
[x] All tests pass
[x] All conflicts resolved

Overhead requirements

[x] New/changed method tests implemented/updated (or no change)
[ ] Updated Unreleased section of changelog.md (or no change)
[x] Migrations created & committed (or no change)

Merged via #1076


CFE-1063: remove kubebuilder validation for placementGroupPartition

As per https://github.com/openshift/api/pull/1897#discussion_r1658841416
Kubebuilder validations won't work on this particular API,  we will need to add them in webhook validation.

Even though the validations do not actually work here, I'd prefer we have them in the API to indicate the validations that we are making via the webhooks. This is a strange edge case but it's better to have that indication IMO, for consistency with other APIs
/close


does it support charset 'gbk'?

i try to crawl this page
http://list.jd.com/737-794-870-0-0-0-0-0-0-0-1-1-1-1-1-72-33.html
it seems no friendly to 'gbk'

forceUTF8:true,
incomingEncoding:'gb2312',


get_bore_desc, Lamination with list of slot and notches

Hello all,
I'm currently working on a publication for ICEM 2020 (and on how to upload Jupyter notebook to pyleecan.org for the documentation). In this publication, I will present the geometrical modeller of pyleecan (build_geometry) and how it can be used to create complex and exotic topologies.
In particular I'm investigating a new class "LamSlotMulti" a "LamSlot" with a list of Slot (and an array of angular positions) to draw uneven slot machine like (image generated with my current version of pyleecan as a proof of concept):

Then I wanted to add notches and it became quite complicated to mix both.
That's why I want to introduce a new method for Lamination objects:
def get_bore_desc(self):
"""This method returns an ordered description of the elements
that defines the bore radius of the lamination

Parameters
----------
self : LamSlot
    A LamSlot object

Returns
-------
bore_desc : list
    list of dictionary with key: "begin_angle", "end_angle", "obj"

For a "normal" Lamination with Zs=12 SlotW10, it would returns (T_op = tooth opening angle, S_op=slot opening angle) :
bore_desc [0] = {"begin_angle" = -T_op/2; "end_angle" = +T_op/2; "obj": Arc1}
bore_desc [1] = {"begin_angle" = T_op/2; "end_angle" = T_op/2+S_op; "obj": SlotW10}
bore_desc [2] = {"begin_angle" = T_op/2+S_op; "end_angle" = 3/2*T_op+S_op; "obj": Arc1}
...

This bore description would then take into account the notches and the uneven bore shape.
The "obj" are either pointer to the corresponding Slot either the Arc to use.
The bore_desc can either describe the complete lamination or a symmetry part. In case of symmetry, the first angle is 0.
We keep the convention: The first tooth is centered on X+ axis (with or without symmetry)

The build_geometry of the "Lamination" object can then call this function to draw the bore (what ever the lamination type or the sym). The polymorphism would be on the get_bore_desc method.
I would like to take the opportunity to update the Notch definition.
In Lamination we currently have a list of Notch and then the Notch class itself contains a list of Slot object. I would like to keep the list of Notch in the Lamination and remove the list of Slot in Notch.
The Notch class would be abstract and empty. NotchEvenDist would have a single Slot object as property and alpha as a float (with alpha=0, first notch centered on X+axis). The number of notches would be set with Zs in the Slot.
Then we can either create a "NotchSingle" with a Slot and alpha as a property that draws only one notch centered on alpha. Either we use a NotchEvenDist with Zs=1 (which can have an impact on the geometry of some slot).
What do you think of these modifications ?
Best regards,
Pierre

Hello Pierre,
your update to the Notch definition seem to keep its functionality, so from my side it's okay.
For the LamSlotMulti class, I'm not quite sure, what the benifit will be compared to a LamSlot with multiple Notches? Do you plan to have windings within the slots?
Best regards,
Sebastian

Hello Sebastian,
Indeed the point of LamSlotMulti is to have winding within the slots and to have the possibility to have uneven distributed slot. For instance we can design such machine:

Best regards,
Pierre


Usage: stale connections / Android?

Thanks for your work on this.
I'm trying to use it to implement a basic Android remote control, however i get some odd behaviour.
When i create an app, i open up a connection. If i use it immediately to change scene, it is fine. If i make the change scene request later in a button click handler, it never seems to go through. However, it does work if i create a fresh connection object in the click handler.
In addition, i can add a switch scene callback when creating the app, and this seems to stay active throughout. It receives scene changes triggered directly in OBS, even though the setCurrentScene in the click handler, using the same connection object, never reaches OBS.
Is there a subtlety to using the library that i haven't understood, or should i put it down to Android screwiness?
Code attached for reference:
MainActivity.kt

Sorry, closing this, on reflection it's probably to do with not using the same connection in multiple threads.

Yes, exactly! You should create a single thread that interacts with our library. Maybe it would make sense for our library to implement a scheduler and a pipe so that you could send requests from whatever thread you want, and the wrapper would take care to schedule it to the correct thread. But that's something for the future.

Thanks for the response. I should have replied earlier -- i read somewhere that in recent versions of Android, HTTP connections are blocked on the UI thread (rather than this just being bad practice). When using this library only in Dispatchers.IO coroutines in Kotlin, things works fine.


Implement tests for gdb-pt-dump

The project has a bunch of features which are not well-tested and protected against regressions. Tests are necessary to continue development.

Tests are in development :)

Tests repo: https://github.com/martinradev/gdb-pt-dump-tests
There's still quite a bit of work remaining, but adding tests has had some progress.


fixing the depth of the DESTRUCTURE effect

Hi,
This is a fix for the DESTRUCTURE effect.
The screenshots below show the problem :
Before the fix

After the fix :

Nice!
You are right, I don't know why I stoped using these variables (density on each channel).


Pressing S saves file

Typing the character s seems to trigger save, no modifier key required...

See recording
I have a save participant that adds semicolons on save
check the log showing menubar#runActionInRenderer {"type":"commandId","commandId":"workbench.action.files.save"}
notice the highlight flash in the macOS toolbar

https://user-images.githubusercontent.com/1794099/105840178-dff3cd80-5fd2-11eb-86de-94aae2f00c04.mov

@jrieken I cannot reproduce. does it repro when you use a fresh user data dir with default settings? Does it repro in stable?

@jrieken I cannot reproduce. does it repro when you use a fresh user data dir with default settings? Does it repro in stable?

Sorry, false alarm. I thought that I had checked that...

Sorry, false alarm. I thought that I had checked that...

This is caused by an extension but I'd say the extension is doing everything right, it uses this when-clause and it seems we aren't evaluating it: config.jupyter.enableKeyboardShortcuts && notebookEditorFocused && !inputFocus && notebookViewType == 'jupyter-notebook'

This is caused by an extension but I'd say the extension is doing everything right, it uses this when-clause and it seems we aren't evaluating it: config.jupyter.enableKeyboardShortcuts && notebookEditorFocused && !inputFocus && notebookViewType == 'jupyter-notebook'

This is a mix of things.
1. Why is s rendered next to Save ?
The reverse keybinding lookup is not context specific. Take for example the Toggle Line Comment built-in keybinding:
{ "key": "ctrl+/", "command": "editor.action.commentLine", "when": "editorTextFocus && !editorReadonly" }

We want to render ctrl+/ in the menu even when there is no file opened and even when a read only file is opened.
In this case, there are multiple keybindings for "Save": cmd+s and s. Both cmd+s and S are valid keybindings that might end up saving the document. From this list, we give precedence to the last one, simply because it is contributed by an extension (each keybinding has a precedence ordinal and keybindings from extensions > builtin keybindings). That is how keymap extensions can work, their keybindings are rendered first before the built-in ones. So long story short, we render S as the keybinding for "Save".
1. Why is s dispatched to "Save" ?
Well, macOS does this thing where rendering a keybinding next to a menu item will also lead to macOS dispatching that key by itself. On our side, we register a menu item and we define a callback via a property called click that we pass in to Electron to create a MenuItem.
But we don't get to know if the menu item is executed because it was clicked or because the keybinding label rendered next to it was dispatched by macOS dispatching. We have a heuristic to try to find out if this was a mouse click on the MenuItem or it was a keybinding dispatched by macOS. We do this here by looking at the modifiers. The heuristic consists of the following observation: when clicking a menu item, it is very rarely that people would press a modifier key, so most of the times using the mouse will make it that the modifiers are all unset (ctrl, alt, shift, meta are not set). We then look at the modifiers that the keybinding label has and the modifiers that are set and try to determine if it was possible that this was triggered via a keybinding.
The problem with keybindings missing modifiers is that they cannot safely be distinguished from a click, so in this case this heuristic cannot say that this was likely triggered via a keybinding, but rather leaves it to be handled as if it were a mouse click.
If we think this was triggered via a keybinding, we will re-dispatch on the renderer process a synthetic keyboard event with the keybinding printed next to the menu item in order to go through the when clauses. But if we think was triggered via the mouse, we simply dispatch a command invocation to the renderer process.
So that is what is going on here: s is dispatched by macOS, because it lacks modifiers we cannot use our heuristic and distinguish between keybinding/mouse and then we go with the safest option, mouse click, which ends up executing "Save" on the renderer.

This is a mix of things.
1. Why is s rendered next to Save ?
The reverse keybinding lookup is not context specific. Take for example the Toggle Line Comment built-in keybinding:
{ "key": "ctrl+/", "command": "editor.action.commentLine", "when": "editorTextFocus && !editorReadonly" }

We want to render ctrl+/ in the menu even when there is no file opened and even when a read only file is opened.
In this case, there are multiple keybindings for "Save": cmd+s and s. Both cmd+s and S are valid keybindings that might end up saving the document. From this list, we give precedence to the last one, simply because it is contributed by an extension (each keybinding has a precedence ordinal and keybindings from extensions > builtin keybindings). That is how keymap extensions can work, their keybindings are rendered first before the built-in ones. So long story short, we render S as the keybinding for "Save".
1. Why is s dispatched to "Save" ?
Well, macOS does this thing where rendering a keybinding next to a menu item will also lead to macOS dispatching that key by itself. On our side, we register a menu item and we define a callback via a property called click that we pass in to Electron to create a MenuItem.
But we don't get to know if the menu item is executed because it was clicked or because the keybinding label rendered next to it was dispatched by macOS dispatching. We have a heuristic to try to find out if this was a mouse click on the MenuItem or it was a keybinding dispatched by macOS. We do this here by looking at the modifiers. The heuristic consists of the following observation: when clicking a menu item, it is very rarely that people would press a modifier key, so most of the times using the mouse will make it that the modifiers are all unset (ctrl, alt, shift, meta are not set). We then look at the modifiers that the keybinding label has and the modifiers that are set and try to determine if it was possible that this was triggered via a keybinding.
The problem with keybindings missing modifiers is that they cannot safely be distinguished from a click, so in this case this heuristic cannot say that this was likely triggered via a keybinding, but rather leaves it to be handled as if it were a mouse click.
If we think this was triggered via a keybinding, we will re-dispatch on the renderer process a synthetic keyboard event with the keybinding printed next to the menu item in order to go through the when clauses. But if we think was triggered via the mouse, we simply dispatch a command invocation to the renderer process.
So that is what is going on here: s is dispatched by macOS, because it lacks modifiers we cannot use our heuristic and distinguish between keybinding/mouse and then we go with the safest option, mouse click, which ends up executing "Save" on the renderer.

Actually, this now looks fixable with a new property that was added by Electron:
https://www.electronjs.org/docs/api/structures/keyboard-event

Actually, this now looks fixable with a new property that was added by Electron:
https://www.electronjs.org/docs/api/structures/keyboard-event

Thanks for the detailed explanation.
I would assume that macOS has more information but that Electron isn't passing them along. So, maybe @deepak1556 can help us here.
These keybinding are currently coming with the preview Jupyter extension. Today, there aren't too many users but we do expect many in the future. These single letter keybindings are very popular for notebooks which means that we should be prepared.

Thanks for the detailed explanation.
I would assume that macOS has more information but that Electron isn't passing them along. So, maybe @deepak1556 can help us here.
These keybinding are currently coming with the preview Jupyter extension. Today, there aren't too many users but we do expect many in the future. These single letter keybindings are very popular for notebooks which means that we should be prepared.

Actually, this now looks fixable with a new property that was added by Electron:

Oh, that's brilliant. Another thing that we can do (unsure we already do) is to always evaluate the command precondition - when triggered by keybinding or mouse. That would help with some impossible commands, but not for commands that come with a precondition, like save

Actually, this now looks fixable with a new property that was added by Electron:

Oh, that's brilliant. Another thing that we can do (unsure we already do) is to always evaluate the command precondition - when triggered by keybinding or mouse. That would help with some impossible commands, but not for commands that come with a precondition, like save

🥳

🥳

The key binding display issue is related to https://github.com/microsoft/vscode/issues/40389

The key binding display issue is related to https://github.com/microsoft/vscode/issues/40389

A new case:
{ "key": "z", "command": "undo", "when": "never" }

A new case:
{ "key": "z", "command": "undo", "when": "never" }

🥳

🥳


fix: table column order and isVisible

Description

Please include a summary of the changes and which issue has been fixed. Please also include relevant motivation
and context. List any dependencies that are required for this change.

Fixes #6480
Fixes #6454
Type of change

Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: fix/Table-visible-column-not-saving

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
53.36 (0)
34.81 (0)
31.49 (-0.01)
53.91 (0)

:red_circle:
app/client/src/sagas/WidgetOperationSagas.tsx
44.22 (-0.07)
30.89 (0)
48.86 (-0.57)
44.52 (-0.07)

@vivekverma2312 can we test this on Release?


JGRP-2231 Intermittent NPE in JGroups GMS#up on shutdown

Jira
https://issues.jboss.org/browse/JGRP-2231

No, that's fine, I already backported this fix to the 3.6 branch.
Thanks,

Cool, thanks!


Update readme

@MarkoBarisic, we can merge this on release day. What are the rules on this repo? Do you merge or PR creator (me)?

@katarinasupe PR creater merges :+1:


ReferenceError: _global is not defined in zone.js 0.8.13

After upgrading to zone.js 0.8.13 in my angular 4.3 app I can no longer load the page; when pouchdb calls addEventListener it winds up on line 209 of lib/common/events.ts complaining that ReferenceError: _global is not defined.
This issue does not happen if I downgrade to zone.js 0.8.12; it's 100% reproducible in my codebase.

thank you for posting the issue, duplicate with #835, have been fixed and please wait for the next release.

close for already been fixed


[#3136] fix(spark-connector): support replace column with same column name for spark connector

What changes were proposed in this pull request?
To support replace column:

support delete and add same column name in valid column change logic in hive catalog
remove get column position logic if not specifying column position in Iceberg catalog

Why are the changes needed?
Fix: #3136
Does this PR introduce any user-facing change?
no
How was this patch tested?
add IT

@jerryshao @mchades @qqqttt123 please help to review this PR when you are free, thanks

@mchades @jerryshao please help to review when you are free, thanks.

@mchades all comments are addressed, please review again


curl-48-an-unknown-option-was-passed-in-to-libcurl

Bug description
Problem with curl if using ubuntu-latest
How to reproduce

Go to https://github.com/tschm/cs and inspect the failing workflow

I hit this bug as well on my repo, I set continue-on-fail so it looks green for now, but the action did indeed fail with the same bug.

This is discussed here https://github.com/jupyterhub/repo2docker-action/issues/99


Spin off validation logic to separate repository

As was mentioned in https://github.com/belgif/rest-guide/issues/169, there are some concerns of combining the validation logic of (business) values with the problem library.
I'd suggest to spin this off to a separate project because:

the lifecycle of validation library depends on evolution of business types, not only on technical REST API concerns
it allows to work towards consolidation with smalsutils-validation

we can work on resolving differences while keeping rest-problem-java stable
it's very hard to document that a (documented) module of rest-problem-java shouldn't be used in Smals

Some differences with the smalsutils-validation library:

Smals library uses Bean Validation, also usable outside of a REST context
Java implementation is kept in sync with validation logic in another Angular validation library
there are some other validations (like VatNumber country-specific formats), probably some divergent ones as well
translations of validation errors (useful when library is used in UIs)

Ideally, we could have a single validation logic for Java and integrate with different ways of using it (programmatic validation, bean validation, inside or outside a REST API context, ...)

Where do you see InputValidationIssues.java fit in? In the problem library or in the validation library?

Good point, I'd put at least the standardized business-agnostic issue types in rest-problem-java (like referencedResourceNotFound).
Not sure about the business-specific ones (like replacedSsin and canceledSsin). It's a bit the same discussion about whether they should be included in the REST guide. Maybe best in the validation library where they can evolve with the validations themselves. Then again, they might be reusable by other validation libraries as well, but that's probably a rather theoretical advantage.

There was some earlier discussion about overlap between belgif-rest-problem-validator and SmalsValidation library in #16.
I also wonder, in your current REST APIs using the SmalsValidation library: how do you map the Bean Validation exception to a BadRequestProblem? Are they mapped to urn:problem-type:belgif:input-validation:schemaViolation?

Seems to differ across APIs, I haven't found a common implementation for our Spring projects.
For JAX-RS, there is a lib in use that:

maps bean validation exceptions from annotations in javax package to schemaViolation. These javax annations are usually generated from the OpenAPI document
the issue type is not set for custom bean validation annotations (other package names)


[DO NOT MERGE] testing existing apk sizes of main

Don't need this, I actually figured it out before the build completed...


'effective genome size' , how precisse does it have to be?

Rat genome is one of the genomes that are not mentioned very much among macs2 users. So I had to look around and do some work for myself. I want to share the output and also ask a related question.
I used rat genome rn6 downloaded from UCSC bigzip file and kept all contigs that do not have standard chromosome names.  The calculation involved using gem-indexer for base-space data and  gem-mappability with kmer size of 45, 50, 75, 100, and 150 bases. The effective genome size values are the number of '!' characters in the .mappability files.
rn6.softmask.all_45:<PHONE_NUMBER>
rn6.softmask.all_50:<PHONE_NUMBER>
rn6.softmask.all_75:<PHONE_NUMBER>
rn6.softmask.all_100:<PHONE_NUMBER>
rn6.softmask.all_150:<PHONE_NUMBER>

I also did some test with color-space index of only chromosome 1. The numbers looks greater than that from base-space index of chromosome 1. So here comes some questions.

Which number should I use? The one from color-space index or base-space index. My BAM files were aligned with colorspace aligner and reads are colorspace reads.
What is the consequence of under or over estimate the effective genome size in macs2 output?
Macs2 documentation does not seem to draw much attention about kmer size. What kmer size was used to calculate those values for 'supported' genomes by macs2?

Thanks.

Decided to post the questions to biostars for broader audience.

So what did you end up using in the end? and how come no one knows the MACS2 kmer size used to compute effective genome size in the supported genomes? :(

@hreypar The fact is that the "effective genome size" is used to compute genome-wide background. And in the actual peak calling, this background is usually the smallest among the three "local background" ( including 10k, 100k, and peak size surrounding region) estimated from control data. Moreover, a slight difference in the estimated number, such as 10% difference, wouldn't cause a big impact on peak calling -- assuming that the data is in good quality and you are mainly studying top tens of thousands of peaks. As a general suggestion, the effective genome size number for MACS2 can be calculated as "the genome size - simple repeats - Ns". Although you can always use a k-mer method to accurately estimate or fine-tuning the number for you specific dataset.


[BUG]

/C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/agora_uikit-0.0.2/lib/controllers/session_controller.dart:41:43: Error: The argument type 'AreaCode' can't be assigned to the parameter type 'List?'.

'AreaCode' is from 'package:agora_rtc_engine/src/enums.dart' ('/C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/agora_rtc_engine-4.0.6/lib/src/enums.dart').
'List' is from 'dart:core'.
areaCode: agoraConnectionData.areaCode),
^

FAILURE: Build failed with an exception.

Where:
Script 'C:\src\flutter\packages\flutter_tools\gradle\flutter.gradle' line: 1035

@Basemshawwa Please try using the dev branch.

ok thank you


support stats compression for merged metrics

(This is used to request new product features, please visit https://github.com/istio/istio/discussions for questions on using Istio)
Describe the feature request
With https://github.com/istio/istio/pull/47997 we have support for compressed envoy stats. For those using agent merged metrics for application metrics or getting envoy metrics from the agent stats endpoint it would be useful to support compression as well in order to cut down on cross-zone/cross-region/cross-cloud costs.
This of course comes at a tradeoff of CPU utilization and would likely start as an opt-in rather than a default. This is just a request to extend the ability to enable stats compression on the agent.
Describe alternatives you've considered
Current workaround is to setup an envoy listener on an alternative port say 14020 which has a route to 15020 and a GZIP http filter enabled. EnvoyFilter to 15020 alone is not an option as 15020 is an Istio excluded port by default.
Affected product area (please put an X in all that apply)
[ ] Ambient
[ ] Docs
[ ] Dual Stack
[ ] Installation
[x] Networking
[ ] Performance and Scalability
[x] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Multi Control Plane
Additional context

While I'd prefer having this issue solved I'd like to get the work around working for at least some pods right away. I have managed to set up a listener on port 14090 in pods for a deployment using the method described here: https://github.com/istio/istio/issues/30987#issuecomment-822517456
But I don't understand how to route the traffic for port 150020 to this listener. Can anybody give me a hint?

While I'd prefer having this issue solved I'd like to get the work around working for at least some pods right away. I have managed to set up a listener on port 14090 in pods for a deployment using the method described here: #30987 (comment)
But I don't understand how to route the traffic for port 150020 to this listener. Can anybody give me a hint?

I think this depends on the scraping application, for prometheus operator I think you can alter the scrape annotations on the pod:
    prometheus.io/path: /stats/prometheus
    prometheus.io/port: "15020"
    prometheus.io/scrape: "true"

Ultimately I'd love to see this integrated, currently merged metrics in our environments are over 1-2 megabytes of highly compressible per request.
We can reduce these requests by over 80% with gzip, with marginal CPU usage. In my opinion there's no reason not to do this out of the box.


Reference blog post on finishing support of Aiven for Elasticsearch

The aiven-string-replacer-for-grafana is referenced in an Aiven blog post,
https://aiven.io/blog/finish-move-away-from-elasticsearch
More precisely, the blog post refers to this page.
It seems sensible to add a link back to the blog post.

We don't do it for other blog posts and for this case I'm not sure how much value it provides for the reader. The blog post doesn't go into more details about replacing a string in Grafana dashboards, so this external link doesn't add a lot of extra info on the topic of the article.

@anelook I think that's a good point, and I think I'm convinced this is not worth doing. I shall close this for now.


Allow users to rebind expect!

Currently, expect-test checks for the string expect![[ when updating test cases. As a result, setting UPDATE_EXPECT=1 will cause a panic if expect is imported under a different name.
We have the column of the macro invocation for each Expect. Use that as a starting point instead.

This doesn't test that UPDATE_EXPECT actually works, yet (I've been testing it locally with chalk). It seems like an integration test would be best for this, as opposed to the unit tests I've been writing, but I'm waiting to see what you think of this change in general.

:+1: to general idea of allowing renaming
Yeah, I like this approach more! I am a bit surprised that we look for first [ and not the second one, but it probably is fine. I'd also maybe try to write this in a simpler way, like line[column..].find("[[") but I guess that doesn't work, as column is in unicode charactres.
Actually, what unit the column is in? This seems to not be documented.

Actually, what unit the column is in? This seems to not be documented.

I filed rust-lang/rust#92301 while implementing this. I believe it's code points.

I'd also maybe try to write this in a simpler way,

Part of the complexity is because I split this out from #27. You could do find("[[") on top of char_indices if there's no plan to support the usual set of macro delimiters, but I'd like to make it work.

bors r+


videoMaximumDuration is not working in IOS

Describe the BUG
videoMaxDuration property is not working as intended in IOS
Steps to reproduce
Implement the plugin with this property. and try to select video which has more seconds than mentioned.
Current behaviour
if we mention    videoMaximumDuration: 10, , if we select video which has more than 10 seconds is also able to select.
Expected Behaviour
Videos having lessthan or equal to 10 seconds must only be able to be picked.

@Mubashir-Mohamed no, that option isn't for selecting video that has 10 seconds. It's for recording limit using this plugin.

@jibon57  So we cant limit the size of the video taken from the gallery?

With this plugin at present not possible. But you can check the file size as soon as user will pickup then can give warning that the size of the file has been exceeded the limit. That's the only work around is possible now.


Just pulled v1.0.0 and get an error

I'm getting this error:
Assertion failed: (handle->flags & UV_CLOSING), function uv__finish_close, file ../deps/uv/src/unix/core.c, line 171.

I'm going to try reverting to the prior version to see if that fixes the issue.
After going to this version: "^0.4.0-beta.1", the error goes away.
I'm seeing other issues after updating all modules. I'll post an update shortly.
Just ran
npm i --save-dev node-sass

and went back to 1.0.0
and the prior error went away. Still some other issues, but might be unrelated.

No issues if you do the explicit install of the node-sass.

What's the temp workaround for this? npm install node-sass?

With sass-loader 1.0.0 node-sass should now be a dependency of your project.

I'm getting the same error, with node-sass 3.0.0-alpha.0 in my project's dependencies. Any suggestions?

<EMAIL_ADDRESS>is – as the name suggests – not stable :wink:. Probably the same issues as #65


super minor issue: -wx only works when you specifiy -n also

super minor issue only, but the discord bot doesnt give a warning when you load a mission by using !mission load -wx ICAO instead of !mission load -n x -wx ICAO.

That's not expected.
Without specifying a mission, it should reload the current one with new weather.
I'm shelving this one for the next iteration.

If you load without -wx ICAO then you wont see the bug and !dcs status works, apparently

now the error messages are gone but I get this report when using !dcs status from a mission that was hosted with -wx ICAO:

> Dcs application: running
> Dcs cpu usage: 21%
> Dcs version: <IP_ADDRESS>54
> Metar: Weather(source='UGKO', source_type='ICAO', _station_icao='UGKO', station_name='Kopitnari Airport', raw_metar_str='UGKO 141430Z 25006KT 9999 BKN048 10/09 Q1017 NOSIG', metar_data=MetarData(raw='UGKO 141430Z 25006KT 9999 BKN048 10/09 Q1017 NOSIG', remarks='NOSIG', station='UGKO', time=Timestamp(repr='141430Z', dt=datetime.datetime(2018, 11, 14, 14, 30)), altimeter=Number(repr='1017', value=1017, spoken='one zero one seven'), clouds=[Cloud(repr='BKN048', type='BKN', altitude=48, modifier=None)], flight_rules='VFR', other=[], sanitized='UGKO 141430Z 25006KT 9999 BKN048 10/09 Q1017 NOSIG', visibility=Number(repr='9999', value=9999, spoken='nine nine nine nine'), wind_direction=Number(repr='250', value=250, spoken='two five zero'), wind_gust=None, wind_speed=Number(repr='06', value=6, spoken='six'), dewpoint=Number(repr='09', value=9, spoken='nine'), remarks_info=RemarksData(dewpoint_decimal=None, temperature_decimal=None), runway_visibility=[], temperature=Number(repr='10', value=10, spoken='one zero'), wind_variable_direction=[]), metar_units=Units(altimeter='hPa', altitude='ft', temperature='C', visibility='m', wind_speed='kt'), altimeter=Pressure(762.8126226350325, "mmhg"), cloud_layers=[Cloud(repr='BKN048', type='BKN', altitude=48, modifier=None)], visibility=Visibility(9999.0, "m"), temperature=Temperature(10, "c"), dew_point=Temperature(9, "c"), wind_speed=WindSpeed(3.0866666666666744, "m/s"), wind_direction=WindDirection(250.0, "degrees"), wind_direction_range=[], wind_gust=WindSpeed(0.0, "m/s"), date_time=Timestamp(repr='141430Z', dt=datetime.datetime(2018, 11, 14, 14, 30)), other=[], remarks='NOSIG', wind_direction_is_variable=False, original_dcs_weather=None)
> Mission file: C:/Users/132nd/Saved Games/DCS.openbeta/Missions/ESST/AUTO/TRM_2.1.1.miz
> Mission name: TRM_2.1.1
> Mission time: 2 hours ago
> Paused: False
> Players: []
> Server age: 2 hours ago
> Server status: loaded mission

If the issue is the METAR format, then it is a placeholder for the time being (resulting from the transition to my own weather parsing library). I will not fix this before the next iteration of ESST, as it is mainly eye-candy and does not hamper main functionality.
If, however, there is something else wrong, please let me know!

@132nd-Entropy Can this be closed ?


Remove requestSubmit polyfill

A polyfill for HTMLFormElement.requestSubmit was introduced and inlined as part of the 7.1.0 release.
As of April 2023, that method has total support and 100% Compatibility with evergreen browsers.
This commit removes that polyfill.

I believe it is too early to remove it. Many people are still on devices that can't upgrade to Safari 16+. See https://caniuse.com/mdn-api_htmlformelement_requestsubmit with "Usage relative" selected.
As a side note, is there a browser support policy for the project?

Would it be an appropriate stance to consider inlined, built-in polyfills outside the bounds of<EMAIL_ADDRESS>while encouraging those that need them to depend on third-party packages like event-submitter-polyfill and form-request-submit-polyfill?

As a data point, we still support Safari 14.1+ at Basecamp. Safari is particularly sticky because versions are tied to the OS and the OS is tied to the hardware so when we deprecate one Safari version we may be forcing customers to updated their hardware.


clarify the "credentials" notion in CIBA workflow authentication

Problem description
the value "credentials" in the CIBA workflow authentication isn't clear
Expected action
Define clearly what is expected in the notion "credentials" (basic auth, client_id, token etc.)
Additional context
in the openid standard documentation, credentials are defined with the notion of client_notification_token.
In the Orange implementation, only client_id is used.

Hi @sebdewet,
If it is not clear, we can agree to add further clarification in the documentation, no problem. I understand you are referring to the part of the flow highlighted in red below:

"Credentials" refers to the client_id and secret of the final application requesting access to the data. These credentials are those created on the Operator side when the corresponding application was onboarded.
And the application credentials are provided in the CIBA /bc-authorize request in HTTP Basic Authentication.
As stated in https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.1 -> "The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id, such as the authentication methods from Section 9 of [OpenID.Core] or authentication methods defined by extension in other specifications."
And HTTP Basic Authentication is one of the options documented for Client Authentication in OpenID Core specification: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication
client_secret_basic
    Clients that have received a client_secret value from the Authorization Server authenticate with the Authorization Server in accordance with Section 2.3.1 of [OAuth 2.0](https://openid.net/specs/openid-connect-core-1_0.html#RFC6749) [RFC6749] using the HTTP Basic authentication scheme.

The CIBA flow explanation in the CAMARA documentation also explains the following, but if it is not clear enough, we can improve the documentation:

Please note the "final application" remark, because in the case of Open Gateway for example, if there is an aggregator in between, the aggregator will use the application credentials to obtain the access_token.

@sebdewet Just to clarify, in the end the flow is OpenId standard and for example private_key_jwt (see https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) is also discussed in the Operate APIs technical discussions (TM Forum APIs) for client authentication. In this case a signed client assertion is used to authenticate the client.

Hi,
I agree with the fact that "The Client MUST authenticate to the Backchannel Authentication Endpoint using the authentication method registered for its client_id"
I just want to know if we allow several methods, like client_id/client_secret or for example use a mutual TLS with only the client_id, or a jwt containing the client_id ? That's what I want to clarify.
another point I wanted to talk about, is if we allow only the usage of login_hint, or if it's possible to use login_hint_token or
id_token_hint.
sorry for the delay.
regards.

CIBA is requesting that the client is authenticated and that the authentication is the one that is defined for it.
If we/Camara think this is too open, then I see no problem in specifying a binding in Camara e.g. that client_secret_basic and client_secret_jwt MUST be implemented by all, and that client_secret_jwt is recommended, and that "none" MUST not be used.
There SHOULD be only one authentication method for one client. If e.g. client_secret_basic is configured for that client, then if a client_secret_jwt is received it MUST be rejected and the receiver MUST not even try to validate HMAC SHA-256.

We could also look at the OIDF FAPI CIBA certification program and recommend Camara OPs be certified
https://openid.net/certification/#FAPI-CIBA_OPs

As per last WG call (29/11) discussion, CAMARA participants tend to agree that there should be an OIDC profile where these developer-oriented implementation details are written down in black and white. But it is still not resolved where to put it. This is also related to issue #82.

As discussed in 17/01/2024 WG meeting call, as the way forward agreed, Telefónica will contribute to CAMARA with a first draft of the OIDC profile.

Added PR with a first draft of OIDC profile.


[BUG] TypeScript hello world component fails to call HTTP

Affected project(s)

[ ] documentation
[X] examples
[ ] wasmCloud host
[ ] wasmCloud CLI (wash)
[ ] wasmCloud dashboard UI (washboard)
[ ] capability providers
[ ] provider bindgen
[ ] control interface client
[ ] other / not sure

Describe the bug
~/tmp/ts-hello ➜ curl localhost:8080
failed to invoke `wrpc:http/incoming-handler.handle`: failed to call `wasi:http/incoming-handler.handle`: error while executing at wasm backtrace:
    0: 0x853340 -<EMAIL_ADDRESS>    1: 0x576756 - <unknown>!<wasm function 5939>
    2: 0x2ab0c9 - <unknown>!<wasm function 418>
    3: 0xc5edb - <unknown>!<wasm function 97>
    4: 0x2aa9f9 - <unknown>!<wasm function 417>
    5: 0x2aaf24 - <unknown>!<wasm function 418>
    6: 0x501a5f - <unknown>!<wasm function 3388>
    7: 0x3dca4e - <unknown>!<wasm function 1226>
    8: 0x3339af - <unknown>!<wasm function 678>
    9: 0x5832dd -<EMAIL_ADDRESS>unknown handle index 1

Steps to reproduce

Run wash new component to generate the typescript hello world example
cd example
npm install
wash build
wash up -d
wash app deploy ./wadm.yaml
curl localhost:8080
see error

Expected behavior
The example should return a successful response.
Environment

OS: [e.g. Linux, MacOS] MacOS
Shell [e.g. bash, zsh, powershell] zsh
wasmcloud Version [e.g. 0.81.0] 1.0.4

Screenshots / Logs / Additional context
Note that this fails within wasmtime 18, 20 and 22 as well, so it is likely not a host bug.
ERROR wasmtime_cli::commands::serve: [0] :: Error {
    context: "error while executing at wasm backtrace:\n    0: 0x853340 -<EMAIL_ADDRESS>  1: 0x576756 - <unknown>!<wasm function 5939>\n    2: 0x2ab0c9 - <unknown>!<wasm function 418>\n    3: 0xc5edb - <unknown>!<wasm function 97>\n    4: 0x2aa9f9 - <unknown>!<wasm function 417>\n    5: 0x2aaf24 - <unknown>!<wasm function 418>\n    6: 0x501a5f - <unknown>!<wasm function 3388>\n    7: 0x3dca4e - <unknown>!<wasm function 1226>\n    8: 0x3339af - <unknown>!<wasm function 678>\n    9: 0x5832dd -<EMAIL_ADDRESS>    source: "unknown handle index 0",
}

Just an extra note, I find this puzzling as I can't see anything in particular that changed about this example or ComponentizeJS to make this fail.

This might be relevant to this old bug report from wasmtime upstream -- are the somehow using the same resource twice? Surprised a test didn't catch this

Using the typescript code from this docs page works: https://wasmcloud.com/docs/developer/components/generate


Add get_events_remaining function

Suggesting a useful helper function get_events_remaining which returns the remaining events for the season. I was doing some experimentation and thought this could be a useful for me and maybe for others.

I'm force pushing updates to ensure you have a single commit as is required by other open source projects I'm involved in. If you prefer to have multiple commits and squash yourself when you merge please let me know :smile:

I'm fine with you force pushing, although I don't consider it necessary. The projects I have contributed so far did not require it. I see that all PRs to Kubernetes seem to be force pushed for each update. What's the rationale behind it? I failed to find it in their contribution guidelines when taking a quick look.

I've noticed that commits are often cherry-picked to multiple release branches. I suspect this just keeps it simpler for them when doing so.

Ok, sorry for the slight delay. There are two minor things remaining, documentation related.

the versionadded number in the docstring should be bumped to 2.3
within fastf1/init.py the function needs to be explicitly added to the docstring at the beginning so that it is picked up by sphinx when generating the docs.

I can also push these changes myself, if you like. Then you don't need to figure the docs stuff out in case you are not familiar with it.

@theOehrly No problem! I can do it. However using the feedback you provided in the code review I realize that this function maybe isn't needed. All I needed was result = fastf1.get_event_schedule(2022) and then filtering using the method you showed me: result.loc[result["EventFormat"] == "sprint"] or result.loc[result["EventDate"] >= now]. I really like this.
I would therefore like to suggest closing this pr to avoid cluttering the api, and instead I can open a pr to expand the documentation adding an example that does this kind of filtering. What do you think?

@oscr I had thought about this when you initially opened the PR. You are right, this function is not strictly necessary, as it is fairly simple to get the desired result without it. FastF1 does provide very similar wrapper functions in other places, too, though. Also, there seem to be plenty of users who have little programming experience.
IMO, it is ok to add wrapper functions like this as shortcuts if they solve a reasonably common problem (which is a very subjective decision, I know). Also, this functionality is very self-contained and does not require much if any maintenance. Therefore, I'd say it is a justifiable addition.

Looks good now. Thank you for contributing to FastF1!

Thank you @theOehrly for your help and support.


Fix delete notifications, use Template.render()

instead of Template.format(), which doesn't exist.

Sorry my bad, I must have had that confused with the string format function (which is what I was using prior to templates).


Firebase instructions not complete.

Following the instructions for connecting your own database, after step 5; updating the Firebase SDK snippet in the /src/Firebase.js file and running the app it builds and loads successfully.
I even see very briefly the main prompt for the session, then it fails giving the error in the console:
The project empathy2 does not exist or it does not contain an active Cloud Datastore or Cloud Firestore database.
I will work through a full flow for setting up Firebase on our end and send you a pull request.

This points out something I overlooked - the readme includes instructions for setting up a Firestore database (which the error message is complaining about) but this is in the section for accessing the admin panel, when it should clearly be in connecting your own database.


Does not support dynamic custom properties

Following expression is not supported by @haftahave/serverless-ses-template in serverless.yml
custom: ${file(../${opt:stage, self:provider.stage}.yml)}

Config file sesTemplatesConfigFile is always default one (defaultSesTemplatesConfigFilePath), because expression is not solved (remains ${file(../${opt:stage, self:provider.stage}.yml)}):
this.sesTemplatesConfigFile = this.serverless.service.custom.sesTemplatesConfigFile
            || defaultSesTemplatesConfigFilePath;

Example of an external file (dev.yml):
...
sesTemplatesConfigFile: './email/config.js'
...

Thank for reporting! I will fix it soon. Issue relates to https://github.com/serverless/serverless/pull/3911

Fixed, feel free to use new version 1.2.5.


Automator: update<EMAIL_ADDRESS>dependency in<EMAIL_ADDRESS>

Generated by Automator - 2023-02-05T18:30:38+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio_release-1.17
64aced24b58d780d37d0f9301cef05e6bcf1b205
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test gencheck

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

gencheck_istio_release-1.17
64aced24b58d780d37d0f9301cef05e6bcf1b205
link
true
/test gencheck

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

There is a later commit for pkg and that commit is in the update_deps.sh PR so this PR can be closed.


[Relay][Pass]Implementation of a custom pass to extend 8bit Conv2D with Checksum Calculation in Relay

Hello Everyone,
I assume that this automated Checksum calculation might be helpful for somebody to detect Soft Faults during the calculation of a Conv2D operation.
So I combined the knowledge from Hari. et. Al's Making Convolutions Resilient Via Algorithm-Based Error Detection Techniques and Uzair's  Efficient Software-Implemented HW Fault Tolerance for TinyML Inference in Safety-critical Applications to support both depthwise and standard Conv2D.
This pass adds multiple relay nodes and generates one output Tuple with the original result and additional boolean output for each "secured" Conv2D to recognize how many soft faults happened during the whole NN.
I  am grateful for any tips/improvements in the code,
Johannes

@tqchen @mbrookhart   @zhiics
Could you give some feedback?


feat: add Keptn 0.11.2

Signed-off-by: Giovanni Liva<EMAIL_ADDRESS>Preview: https://deploy-preview-973--keptn.netlify.app/

Links have been updated and examples released! Could you please have another look at the PR?


TypeScript declaration is wrong in CommonJS

The .d.ts file exports a default class, which makes TypeScript look for a .default property on the exports object in CommonJS. However, in CommonJS environments, the exports object is set to the class itself. This makes it unusable in Node.js/TypeScript projects.

You can fix by telling rollup to force default export but this will make people need require("x").default but if you don't do this it will happen as soon as someone adds a named export

I think if we want interop it is best to avoid module.exports assignment altogether

@krisselden I agree. Personally, I don't mind having to do .default in Node, but that may be a minority opinion.

Is there a change this being merged in for a new version?

I was really hoping to use this lib in one of my project, because I was sure I could share code between frontend and backend, but I guess I was wrong :(

FWIW this is now solved by typescript with the allowSyntheticDefaultImports option, otherwise the typedef matches the module build