Output quanitty JSON to hot phase module

return a json object to the campagin in hot module phases with the quantity total for each day
select quanity
from dosomething_quanity_log
where nid = X
group timestamp by dates
and n.timestamp is max where timestamps

@angaither this is so we can (more) easily populate the graph yeah?

@mikefantini yup

@angaither All I need for the graph is 4 data points. One for each day we are showing on the x-axis. Is it possible to have a JSON object that holds just the four dates we want to show on the graph, and the goal progress on each of those dates (set as null if the date is in the future). So something like:
{
  dates: ["JAN 1", "JAN 10", "JAN 21", "JAN 31"],
  value: [3000, 4500, 9000, null],
}

@sbsmith86 hmm, originally when we talked about this we were going to send the latest timestamp from each date, because how do we pick which four dates we are going to use?
What happens when we run a campaign for a week?

@angaither yea, we still need that data to aggregate it into these 4 data points because the graph only shows 4 points. Could we determine the dates by getting using the hot phase start and end dates, divide by 4, and then calculate dates based on that interval? If the hot phase is only for a week, then we could still determine 4 dates in between start and end.

oh boy

@sbsmith86 can we sync on this? I thought we were going to be adding to the graph regularly, but only having markers at those 4 points in the date range (i.e. 4 markers within the one month).
I think the clean lines were just for ease on @lkpttn's part

@mikefantini Ah yea, lets sync. You are right and I think I confused things talking about aggregating stuff. But regardless, I definitely need data about those four dates, so there will be some logic around figuring out those dates programmatically, either on the backend or the frontend.

I think we can keep this on the front end. If you've got the and date and start date, you can divide by four and round up to get the two interim dates.

Just wrapping up this convo. I made a custom graph type that will allow us to go ahead and pull in all of the data for each day of the month like originally planned!

:+1: awesome @sbsmith86 I'm working on outputting this data now!

Fixed by #4664


Trashing on external drive does not work on Linux

What system are you running Yazi on?
Linux Wayland
What terminal are you running Yazi in?
Kitty v0.31.0
Yazi version
yazi 0.1.5 (e41266d 2024-01-13)
Did you try the latest main branch to see if the problem has already been fixed?
Tried, but the problem is still present
Describe the bug
On Linux, when trashing a file on a different drive it fails because it tries to trash. This is because it tries to trash the file at /run/.Trash-1000 instead of <MOUNTPOINT>/.Trash-<UID>. (i.e. if you have a drive mountained at /run/darkkronicle/cooldrive, it should trash in /run/darkkronicle/cooldrive/.Trash-1000
Error within yazi task:
Failed to work on this task: Error during a `trash` operation: FileSystem { path: "/run/.Trash-1000", kind: PermissionDenied }

Related: #246 and https://github.com/Byron/trash-rs/issues/57
Expected Behavior
When moving file to trash on a different drive, it should go to the correct trash folder, and not error out.
To Reproduce

Have a mounted drive on linux that is not the $HOME directory.
In yazi, go to any file in there and press d to delete it.
See that the task never gets completed, and has an error.

Configuration
No response
Anything else?
No response

Looking at trash-rs, the issue was it was selecting my /run directory as the top level mount. I have created a pull request to hopefully fix this https://github.com/Byron/trash-rs/pull/97

It's been fixed in upstream. Tested after running cargo update, and it's all good now!


[4.3beta3] Sprite pivot changed since 4.3beta2

Tested versions

Reproducible in 4.3.beta3
Not reproducible in 4.2.1-stable
Not reproducible in 4.3.beta2
Not reproducible in 4.3.beta1

System information
Godot v4.3.beta3 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3070 (NVIDIA; <IP_ADDRESS>19) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)
Issue description
Since upgrading to 4.3.beta3 a lot of the sprites in the game I've been working on have been visually offset. The data for the sprite has not changed or corrupted, you can freely switch between 4.3.beta2 and 4.3.beta3 to see the sprite offset.
Below is what this looks like in 4.3.beta2 (and in 4.2.1-stable):

And below is how it looks in 4.3.beta3, note that it is no longer centred on the xy axis.

Steps to reproduce

Open the MRP below in 4.2.beta2. In the test_scene.tscn is a sprite which is centred on the xy axis.
Open the MRP in 4.3.beta3. The sprite is no longer centred.

Minimal reproduction project (MRP)
Sprite Pivot Bug.zip

Looks like a centered property no longer affects a sprite position.

Bisected to 6b17d51425f9215aec42b3e5ea97630ea5c22543

The issue is with rounding of the sprite offset for both Sprite2D and AnimatedSprite2D. Since the sprite is 1px in size, the calculated offset when centred is -0.5, which in theory means the sprite's anchor should be at the centre of the sprite. But because of pixel snapping, the code decides it needs to snap the offset to an integer value, so it either snaps left or right (considering the x-axis). Mind that this snapping is local to the Sprite2D, which means it does not consider the sprite transform's scale.
In 4.2 and earlier, this snapping used floor(x), which means even a -0.1 offset would snap the sprite to the left. In #87297 it was changed to round(x) which makes more sense. Crucially, the halfway value -0.5 is still being snapped to the left.
#93740 aimed to address the inconsistent behaviour of snapping the halfway values of canvas items, but at the same time it also changed the snapping of the sprite offset. This changed the snapping of -0.5, which is what caused this issue. (Side note, #93712 is another issue caused by inconsistent snapping of halfway values.)
Consider the simpler case with no scaling: Say we have a 3x3 sprite at the origin, with the default centre offset by -1.5,-1.5, how do we want the sprite to be snapped?

Left is if we fix this bug, right is the current (bugged) behaviour.
Now there may not be an obvious answer at first. It'll be clearer if we move the sprite to 0.5,0.5:

Again, left is if we fix this bug, right is the current (bugged) behaviour.
I think the left is indeed more desirable.

@alvinhochun I'm off work today so I'll look at this a little too. I'd first like to get a good grasp of how this is reproduced. The MRP is very specific and has a lot of odd project settings for this, with the specific scene scaled 20x and offset. I'm going to make a cleaner MRP because I suspect all of this isn't necessary to reproduce. I'll then test it against 4.2 and 4.3 and your fix against 4.2 and 4.3 for the pixel snap tests to make sure there's no regressions.

Okay, the MRP is actually very simple to make. I just made a 1x1 sprite from a PlaceholderTexture2D and turned on pixel snap.
sprite-snap-mrp.zip
If you run this in 4.2, you'll see that half values round down (actually all values round down in 4.2, but for the sake of the issue...), and in 4.3 half values round up. This is more apparent when you take a 1x1 pixel sprite and scale it 20x and then offset it, but that's a specific case. You can see this also just as clear by changing the placeholder texture from 1x1 to 2x2 or 3x3 etc and turning the centering on and off.
It's hard for me to say that this is a regression any more than the fact that 0.6 rounds up instead of down now, because it's an arbitrary tie-breaking rule for exact half values. In most cases in the wild you'll see it round up. Another common one is "banker's rounding" which rounds to the nearest even number which also may be a good choice for centering, but I'm not sure. Either way, it sounds like godot's internal rounding oddly rounds down for half values?
We could change all floors to ceils but the intent of #87297 was to change how snapping works to be more consistent and just personally I thing rounding up is the more common tie-breaker for 0.5. It doesn't seem like any of this is critical, but if Godot's internal round() and GDScript's round() both round down for half values, I guess we should make it consistent with that. I'll have to check though.

After some discussions and considerations I do incline to consider this not a bug, because the previous changes intentionally fixed some inconsistent behaviour. This can be worked around by disabling "centered" and manually setting an offset with integer values.

Hmm, for cases where numbers cause offsets in reverse (like pivots), should we replace floor(x + 0.5) with ceil(x - 0.5)?

Hmm, for cases where numbers cause offsets in reverse (like pivots), should we replace floor(x + 0.5) with ceil(x - 0.5)? This would allow -0.5 to round to -1 specifically for those scenarios. It would also maintain the consistent behavior across both positive and negative signs that the "floor and offset by half" fix was designed to address.

This is what #94305 tried to do. The problem is that the offset is not setting the pivot point with respect to the top-left corner of the sprite, but actually moving the top-left corner of the sprite with respect to the node origin. Changing how it is rounded makes the offset rounding inconsistent with the canvas item position rounding.

After noticing that all the 2D team agree on this issue, I'm closing this issue as "as intended". We deeply refactored (and fixed) "Snap 2D Transforms to Pixel", so these kind of issues are expected.
To me, the new behavior is behaving correctly. The old behavior was a bug.


Support OpenSearch Dashboards 2.3.0

Signed-off-by: Eva Millán<EMAIL_ADDRESS>

Thanks a lot @evamillan !


Lists array error

Hey, probably easier to have a distinct topic for each :p
An error regarding UUIs array :
[ERROR]: [string "SubclassCompatibilityFramework/CompatibilityS..."]:15: attempt to index a nil value (local 'list')
stack traceback:
	SubclassCompatibilityFramework/CompatibilitySupport/ListsSupport/_ListCompatibility.lua:15: in global 'AddList'
	SubclassCompatibilityFramework/CompatibilitySupport/ListsSupport/_ListCompatibility.lua:31: in global 'HandleList'
	SubclassCompatibilityFramework/API/ListApi.lua:11: in field 'List'
	SubclassCompatibilityFramework/JsonLayer/ListHandler.lua:6: in global 'ParseAndSubmitLists'
	SubclassCompatibilityFramework/JsonLayer/ListHandler.lua:17: in global 'ListJsonHandler'
	SubclassCompatibilityFramework/JsonLayer/_JsonLoader.lua:18: in upvalue 'SubmitData'
	SubclassCompatibilityFramework/JsonLayer/_JsonLoader.lua:36: in function <SubclassCompatibilityFramework/JsonLayer/_JsonLoader.lua:32>
	[C++ Code]: in function 'xpcall'
	SubclassCompatibilityFramework/JsonLayer/_JsonLoader.lua:47: in global 'LoadConfigFiles'
	SubclassCompatibilityFramework/Init/_InitDefaults.lua:2: in function <SubclassCompatibilityFramework/Init/_InitDefaults.lua:1>
	[C++ Code]: in function 'xpcall'
	builtin://Libs/Event.lua:129: in method 'Throw'
	builtin://Libs/Event.lua:184: in function <builtin://Libs/Event.lua:183>

UUIDs does work for cantrip lists but not leveled spell lists.
Edit : Actually seems there is a issus since the insertion does not work for the Magus modded class/list, even cantrips, which is odd since it's loaded and I have no prob inserting spells in (new) modded lists such as Cleric subclasses mod...
Attached config (lists with issues are at line 1517+) and logs
CompatibilityFrameworkConfig.json
Extender Runtime 2023-10-27 13-14-31.log

The error is happening because it isn't able to find the List from the game using the supplied UUID, which it should if the mod is activated, that's really weird. Your JSON config appears valid, too.
Going to try to mimic your mod set-up and see if I can dig deeper. In the meantime, I'm uploading a Debug Build that might provide more information on where things are failing There will be a lot of console messages, as a heads up. Does it seem to affect mainly lists where multiple UUIDs are being being provided?

Debug build here

Here are the logs
Extender Runtime 2023-10-27 19-23-54.log

Huh, I might have uploaded the wrong build, log should have a lot more in there. So far, I've been able to find two of the lists that aren't found:
    {
      "Action": "Insert",
      "UUID": "c9c328b8-f066-48d9-9a2d-b6cfb62e13d8",
      "Type": "SpellList",
      "Items": [
        "Target_Command_Container",
        "Target_Sleep2e",
        "Shout_FalseLife",
        "Projectile_RayOfSickness",
        "Target_Harm2e",
        "Target_NathairsMischief",
        "Target_HoldPerson",
        "Target_WitherAndBloom",
        "Projectile_RayOfEnfeeblement",
        "Target_FeastOfAshes",
        "Target_BoneShaker",
        "Target_Slow",
        "Target_AnimateDead",
        "Target_VampiricTouch",
        "Target_VampiricTouch2e",
        "Target_Confusion",
        "Target_ResilientSphere",
        "Target_Blight",
        "Target_DeathWard",
        "Shout_ShadowOfMoil",
        "Target_DominatePerson",
        "Shout_DevouringDarkness",
        "Target_Cloudkill",
        "Projectile_NegativeEnergyFlood",
        "Target_Blister"
      ]

and
    {
      "Action": "Insert",
      "UUID": "349c99a9-bb7b-4e3f-860b-c182a06661e7",
      "Type": "SpellList",
      "Items": [
        "Target_Command_Container",
        "Target_Sleep2e",
        "Shout_FalseLife",
        "Projectile_RayOfSickness",
        "Target_Harm2e"
      ]
    },

I'll upload another debug build that might help narrow the cause down in your logs

Debug Build here: https://github.com/BG3-Community-Library-Team/BG3-Compatibility-Framework/releases/tag/2.4.15-DBG-B

New logs, will investigate the 2 lists!
Extender Runtime 2023-10-27 20-45-38.log

Ok those two are spell lists implemented by Cleric Subclasses mod, which sure is loaded since I can choose one of the subclasses :p
Same thing for Magus class mod I guess.
That would not explain why spells are not added to, IE, sorcerer cantrip list (I checked the UUID).

Just to make sure, is your mod loading after the others you're adding to? It could be that at that step in the process the other mod's lists don't exist yet.
The entry that prints just before the error will be the one that it can't find the list of, looks like this most recent one is:
{
	"ListItems" :
	{
		"0" : "Target_Agitate",
		"1" : "Target_DrawIre",
		"2" : "Target_Endure",
		"3" : "Projectile_FriendFetch",
		"4" : "Shout_MageArmor2e",
		"5" : "Projectile_MagicMissile2e",
		"6" : "Target_Sleep2e",
		"7" : "Target_BitingWords",
		"8" : "Zone_ColorSpray2e",
		"9" : "Target_CondordantChoir"
	},
	"ListType" : "SpellList",
	"TargetList" : "073c09e5-ccb9-4153-a210-001225a30cbb",
	"modGuid" : "143ed971-72c8-4d11-a749-2d01a9badaff"
}

Oh and something else, you pointed :
    {
      "Action": "Insert",
      "UUID": "349c99a9-bb7b-4e3f-860b-c182a06661e7",
      "Type": "SpellList",
      "Items": [
        "Target_Command_Container",
        "Target_Sleep2e",
        "Shout_FalseLife",
        "Projectile_RayOfSickness",
        "Target_Harm2e"
      ]
    },

actually shows in game for the right subclass x)

Huh, so it errors out but then still works? That's bizarre

Just to make sure, is your mod loading after the others you're adding to? It could be that at that step in the process the other mod's lists don't exist yet.

Yes my mod loads after all those that add classes/spells etc...

Sooo I'm dumb, looks like I deleted the wrong file earlier, the one that implemented some referenced spell lists.
Now that it's back all lists seem good, so sorry for your time -_-
(but the "error that works" was a funny one)

Happy to help 😄

Well, with me you can view and review all your code that's for sure...


Missing references to logic in annotations

In the following excerpt, the annotations included in the ELM output do not contain references to all the components. In particular, the else portion of the conditional expressions in the final two terms of the union:
define "Age Dependent Combination Risk Factors":
	"Combination Risk Factors Applicable Any Time"
		union "Combination Risk Factors From Patient History"
		union "Osteopenia Before Measurement Period"
		union "Current Tobacco User"
		union "Average of Two Drinks Per Drinking Day"
		union ( if "Glucocorticoid Medication Duration Greater Than or Equal to 90 Days" then { true } else { } )
		union ( if "First BMI in Measurement Period" is not null then { "First BMI in Measurement Period" } else { } )

Note that this issue is related to at least BONNIE-452. Re-expressing criteria using a different approach that does not require the if/then works around the issue, so this issue is being addressed as part of 1.3 Ballot Support.

Adressed in 1.3.14


I want to use moment(moment(xxx).format('lll')).format('ll'), what should I do?

moment.locale((navigator.language || navigator.browserLanguage).toLowerCase());
aTime = moment(xxx).format('lll')
moment(aTime).format('ll')

but not work...What should I do?

You need to provide a format to Moment so it knows how to parse your "lll" string:
moment(moment().format("lll"), "lll").format("ll"); //=> "Dec 31, 2016"

Thank you very much :heart:  :smile:

Thank you very much :heart:  :smile:


add initial Sphinx documentation

Added Sphinx documentation for uniflow.
Process documented here: https://www.notion.so/goldpiggy/Sphinx-fed327996d8c4304bfba2fa5d90ef2ee?pvs=4

@jojortz Could you please add a bit more description regarding what you follow to generate these Sphinx document?
Also, please re-run your script because we recently merged in a HTML extractor, so our doc will be update to date.
One more thing that is there a automated GitHub action to regenerated doc, so we do not have to re-do this for every code change?

@jojortz approved. In the notion, could you add another section regarding where to copy these compiled docs to build the website.


feature: expose STS endpoint type

AWS STS deprecates the use of the global endpoint and all usage needs to be switched over to the regional endpoints.
As described in this issue: https://github.com/awslabs/aws-delivlib/issues/358, shellable's assumeRole Uses STS Global Endpoint.
This change resolves the issue using the environment variable AWS_STS_REGIONAL_ENDPOINTS.
The default behavior will remain the same as AWS_STS_REGIONAL_ENDPOINTS will be set to value legacy and the calls will still go to the global endpoint. Although now we expose the boolean flag useRegionalSTSEndpoints and if it's set to true, then AWS_STS_REGIONAL_ENDPOINTS=regional will be used and the calls will go to the regional endpoints.

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

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID: 7e3e2a523a5290fd6b1a5c6871901ccedee51bad
Result: SUCCEEDED
Build Logs (available for 30 days)

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

Is there a downside to flipping the defaults around, and make regional endpoints the default?
Are there regions in which it doesn't work yet?
I get the desire for safety but this seems innocent.

A few quotes from the STS documentation https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html:

Most AWS Regions are enabled for operations in all AWS services by default. Those Regions are automatically activated for use with AWS STS. Some Regions, such as Asia Pacific (Hong Kong), must be manually enabled.

Tokens that are valid in all AWS Regions are longer than tokens that are valid in Regions that are enabled by default. Changing this setting might affect existing systems where you temporarily store tokens.

I'm still not sure about all the implications of switching the default to Regional endpoints (this would be a much simpler one line change). So I decided to provide an option for clients, who want to use regional endpoints, but for all the existing code to work as before.

Hello! Could someone please take a look at this PR again? Should I simplify it just to
AWS_STS_REGIONAL_ENDPOINTS=regional aws sts assume-role ... ?

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID:<PHONE_NUMBER>0da1c0f857cea371e08e20f1d1cb28
Result: SUCCEEDED
Build Logs (available for 30 days)

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

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID: 32293392c43cfc3c797939e7ddd1a65c92f319d0
Result: FAILED
Build Logs (available for 30 days)

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

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID: c82b7e92dfdd464a3e634cdcd89ac569a04647b8
Result: SUCCEEDED
Build Logs (available for 30 days)

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

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID: d23f432dd3a45a0071736283ef238ac13a97ee20
Result: SUCCEEDED
Build Logs (available for 30 days)

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

AWS CodeBuild CI Report

CodeBuild project: GitHubPipelineAutoBuildProj-eNGjrh4O6eRH
Commit ID: fbd326f93ab4f14fecae28851b47358068e546be
Result: SUCCEEDED
Build Logs (available for 30 days)

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

Updated the branch. I will be grateful if someone merges it. Thanks!


COD312 Cust-Check Cr. Limit - SalesHeaderCheck

SalesHeader should be passed as VAR parameter in COD312 Cust-Check Cr. Limit in SalesHeaderCheck !
If not (current situation): any changes to SalesHeader (via OnCustomerCreditLimitExceeded) are lost !

NAV2018CU3

According to the owning team this will be fixed for the Fall release versions

Better late than never ...
TY! :)


fix: ensure that property is writable and configurable

A property thats writable but not configurable cannot be overwitten.
Attempting to overwrite a non-configurable property will result in
error equivalent to:
TypeError: Cannot redefine property: stack

I have changed the formatting of the condition too, because as it is, the current condition is neither correct (it returns on the first positive condition, either writable or configurable), neither readable.

To clarify:

17:35	not-an-aardvark	What issue are were you having that is fixed by the change?
17:39	gajus	I have described that in the github issue
17:39	gajus	an error thrown with 'stack' property configured to {writable: true, configurable: false}
17:39	gajus	will cause Bluebird to swallow the error and fail silently with the original promise never being resolved

This is the stack trace:
  unhandled-rejection Got unhandledRejection +50ms
  unhandled-rejection Emitting unhandledRejection... +0ms
unhandledRejection TypeError: Cannot redefine property: stack
    at Object.defineProperty (native)
    at Object.notEnumerableProp (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/bookshelf/node_modules/bluebird/js/release/util.js:102:11)
    at CapturedTrace.attachExtraTrace (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/bookshelf/node_modules/bluebird/js/release/debuggability.js:785:10)
    at Promise.longStackTracesAttachExtraTrace [as _attachExtraTrace] (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/bookshelf/node_modules/bluebird/js/release/debuggability.js:406:19)
    at Promise._rejectCallback (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/bookshelf/node_modules/bluebird/js/release/promise.js:472:10)
    at reject (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/bookshelf/node_modules/bluebird/js/release/thenables.js:79:17)
    at run (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/core-js/modules/es6.promise.js:87:22)
    at /Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/core-js/modules/es6.promise.js:100:28
    at flush (/Users/gajuskuizinas/Documents/dev/mailonline/mol-fe-live-blog-api/node_modules/core-js/modules/_microtask.js:18:9)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickDomainCallback (internal/process/next_tick.js:122:9)

Something is off.
I am trying to build a test case, but I am not able to.
This is the line of code that throws the error:
es5.defineProperty(obj, name, descriptor);

I have changed it to:
try {
  es5.defineProperty(obj, name, descriptor);
} catch (error) {
  console.log('error', {obj, name}, Object.getOwnPropertyDescriptor(obj, name));
}

Which produces:
error { obj:
   { Error: test 1
       at on (/src/factories/bookshelf/createSchemaValidatorPlugin.js:33:17)
       at /node_modules/bookshelf/lib/base/events.js:175:25
   From previous event:
       at triggerThen (/node_modules/bookshelf/lib/base/events.js:174:32)
       at .<anonymous> (/node_modules/bookshelf/lib/model.js:1007:19)
   From previous event:
       at .<anonymous> (/node_modules/bookshelf/lib/model.js:932:8)
   From previous event:
       at runCallback (timers.js:574:20)
       at tryOnImmediate (timers.js:554:5)
       at processImmediate [as _immediateCallback] (timers.js:533:5)
   From previous event:
       at exports.default (/src/mutators/updateBadge.js:36:6)
       at resolveOrError (/node_modules/graphql/execution/execute.js:447:12)
       at resolveField (/node_modules/graphql/execution/execute.js:438:16)
       at /node_modules/graphql/execution/execute.js:219:20
       at process._tickDomainCallback (internal/process/next_tick.js:129:7)
     message: 'test 1',
     locations: [ [Object] ],
     path: [ 'updateBadge' ] },
  name: 'stack' } { value: 'Error: test 1\n    at on (/src/factories/bookshelf/createSchemaValidatorPlugin.js:33:17)\n    at /node_modules/bookshelf/lib/base/events.js:175:25\nFrom previous event:\n    at triggerThen (/node_modules/bookshelf/lib/base/events.js:174:32)\n    at .<anonymous> (/node_modules/bookshelf/lib/model.js:1007:19)\nFrom previous event:\n    at .<anonymous> (/node_modules/bookshelf/lib/model.js:932:8)\nFrom previous event:\n    at runCallback (timers.js:574:20)\n    at tryOnImmediate (timers.js:554:5)\n    at processImmediate [as _immediateCallback] (timers.js:533:5)\nFrom previous event:\n    at exports.default (/src/mutators/updateBadge.js:36:6)\n    at resolveOrError (/node_modules/graphql/execution/execute.js:447:12)\n    at resolveField (/node_modules/graphql/execution/execute.js:438:16)\n    at /node_modules/graphql/execution/execute.js:219:20\n    at process._tickDomainCallback (internal/process/next_tick.js:129:7)',
  writable: true,
  enumerable: false,
  configurable: false }

To replicate the issue:
import Promise from 'bluebird';

const error = new Error('test');

Object.defineProperty(error, 'stack', {
  value: 'test',
  writable: true,
  enumerable: false,
  configurable: false
});

new Promise(() => {
  throw error;
});

which will produce:
/node_modules/bluebird/js/release/util.js:97
    es5.defineProperty(obj, name, descriptor);
        ^

TypeError: Cannot redefine property: stack
    at Object.defineProperty (native)
    at Object.notEnumerableProp (/node_modules/bluebird/js/release/util.js:97:9)
    at Promise.longStackTracesAttachExtraTrace [as _attachExtraTrace] (/node_modules/bluebird/js/release/debuggability.js:409:18)
    at Promise._rejectCallback (/node_modules/bluebird/js/release/promise.js:472:10)
    at Promise._resolveFromExecutor (/node_modules/bluebird/js/release/promise.js:490:17)
    at new Promise (/node_modules/bluebird/js/release/promise.js:77:14)
    at Object.<anonymous> (/src/bin/server.js:12:1)
    at Module._compile (module.js:556:32)
    at loader (/node_modules/babel-register/lib/node.js:146:5)
    at Object.require.extensions.(anonymous function) [as .js] (/node_modules/babel-register/lib/node.js:156:7)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Function.Module.runMain (module.js:590:10)
    at /node_modules/babel-cli/lib/_babel-node.js:151:24
    at Object.<anonymous> (/node_modules/babel-cli/lib/_babel-node.js:152:7)

🙏

@petkaantonov Is there a reason for not merging this?

perhaps it's better to use propertyIsConfigurable separately?

perhaps it's better to use propertyIsConfigurable separately?

I am not certain whats that in reference to.

Using Object.defineProperty only needs configurable true or undefined descriptor, so for this code propertyIsConfigurable would be more appropriate check


Make read only vaadin-date-picker focusable

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Only allow two attacking and two defending bans

Not necessary - current functionality allows players to permaban operators they don't like


iOS uncaught exception crash on internet loss

Issues exists in 3.0.2 iOS module with Titanium 3.5.0.GA. If the internet goes down the module gives Network connection failed and makes 5 attempts to retry, after the 5th it crashes with a NSInternalInconsistencyException.
Steps to replicate, build on iOS with no internet and watch for when Analytics decides starts its call.

Are you sure this is Google Analytics. This might in fact be Appcelerators analytics stuff. To make sure, please set analytics to false in your tiapp.xml file.
<analytics>false</analytics>

Correct. Appcelerator too has its own analytics. Do disable it and then
test it.
On Monday, February 23, 2015, Adam St. John<EMAIL_ADDRESS>wrote:

Are you sure this is Google Analytics. This might in fact be Appcelerators
analytics stuff. To make sure, please set analytics to false in your
tiapp.xml file.
false
—
Reply to this email directly or view it on GitHub
https://github.com/Sitata/titanium-google-analytics/issues/20#issuecomment-75657926
.

Update on this, I set   tag to false, it still tries to connect and times out 5 times before crashing.
I reverted tiapp to use the older version of the module (1.0 which was 32 bit) it still runs but crashes with in the same way.
So this might not be a Google Analytics issue,  thanks for helping troubleshoot that as a possible factor though.


Image is broken after reducing font size

Contour Terminal version
0.3.1-unreleased-master-0cf97cb9
Installer source
Github: source code cloned
Operating System
Ubuntu Linux 20.04
Architecture
x86-64
Other Software
No response
Steps to reproduce

display sixel
reduce font size (e.g. Ctrl + mouse wheel down)

Expected Behavior
Image is not broken.
Actual Behavior
Image is broken.

Additional notes
I cannot test the latest version <IP_ADDRESS>
because the fix of #642 has not been applied yet in the version.

Thanks for the three reports. With these 3 fixed (hopefully ASAP), i'll certainly do a 0.3.1 rather soon. (There's also a display-bug that I actually planned to hunt tonight.) I'll keep you posted.

For the record, it's only broken on shrink, not on grow. @kumattau I noticed that you're active in that alacritty PR about sixel. So here's my thinking: Once the sixel image has been once rasterized into the grid, it should not change the associated cells after a font resize.
Applications may request terminal pixel size and send Sixel images out respectively, so this scheme would break if after a grow/shrink of font size, the image would paint into cells it would not have done initially. (I hope my words are clear :) )

So here's my thinking: Once the sixel image has been once rasterized into the grid, it should not change the associated cells after a font resize.

I agree your thinking.
And I think that introducing a coordinate system between application and terminal apart from a coordinate system between terminal and display is one idea.
This idea may be solve inconsistency between pixel-based and cell-based.
https://github.com/alacritty/alacritty/issues/910#issuecomment-1107552838

So, I think that this more of a feature request than a bug, since for example chafa and img2sixel (if i am not mistaken) will resize image to fit inside the window.
I will remove this from our bug fix milestone


[Feature Request] Ui enhancement

🚀 Feature Request
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Example: "I'm frustrated when..."
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Would you like to work on this feature?

[ ] Yes
[ ] No

Please don't create spam. We need only four issues open, not a large number. If you want to work on more issues, you can try other open source projects. A large number of issues in a single project can create problems for you and for us.


HOTT-3622: Add CI config to deploy Terraform

Jira link
HOTT-3622
What?
I have added/removed/altered:

Added CI jobs to write out the docker tag and run Terraform

Why?
I am doing this because:

This is the remaining bit required to deploy this app on ECS :)

Will require https://github.com/trade-tariff/trade-tariff-platform-terraform-modules/pull/29 and then a module version bump.


Introduce Protocol Concept to Merlin Deployment

This merge request introduce protocol concept to model deployment in Merlin as part of adding UPI (Universal Prediction Interface) support.
There are 2 possible protocols values currently:

(Default) HTTP_JSON --> deploy model as http service.
UPI_V1 --> deploy model as grpc service. Even though the name is already UPI_V1, the protocol enforcement is not yet implemented.
protocol value affects both version endpoint and model endpoint.

Impact to Version Endpoint

New protocol field in the VersionEndpoint object
When protocol is protocol.UpiV1 the corresponding InferenceService expect model to expose grpc service at defaultGRPCPort = 9000

      ports:
        - containerPort: 9000
          name: h2c
          protocol: TCP

Version endpoint's URL will be the hostname of the inference service, without any scheme or path. e.g. my-model-1.my-project.domain.com

Impact to Model Endpoint

New protocol field in the ModelEndpoint object
When protocol is protocol.UpiV1, the corresponding VirtualService doesn't have path rewrite, and simply map the model endpoint to version endpoint host.

Other Modifications

I refactored model endpoint implementation to make the structure more align with other "services" implementation.
Introduction of CARAML_ environment variable to replace MERLIN_ for custom transformer and custom model.

Environment Variable
Description
To Replace

CARAML_HTTP_PORT
Custom Model and custom transformer must open http server listening at this port when protocol = HTTP_JSON
MERLIN_TRANSFORMER_PORT, MERLIN_PREDICTOR_PORT

CARAML_GRPC_PORT
Custom Model and custom transformer must open grpc server listening at this port when protocol = UPI_V1
N.A.

CARAML_MODEL_NAME
Model name, shall be used when the custom model or custom transformer requires information about model name
N.A.

CARAML_MODEL_VERSION
Model version, shall be used when the custom model or custom transformer requires information about model version
N.A.

CARAML_MODEL_FULL_NAME
Model full name in the format of ${CARAML_MODEL_NAME}-${CARAML_MODEL_FULL_NAME}
MERLIN_TRANSFORMER_MODEL_NAME, MERLIN_MODEL_NAME

CARAML_MODEL_PREDICTOR_HOST
Predictor host to be used from custom transformer
MERLIN_TRANSFORMER_MODEL_PREDICT_URL

CARAML_ARTIFACT_LOCATION
User's artifact will be located at this path for custom model
MERLIN_ARTIFACT_LOCATION

CARAML_DISABLE_LIVENESS_PROBE
Flag to disable liveness probe when set to true
MERLIN_DISABLE_LIVENESS_PROBE

Does this PR introduce a user-facing change?:

Add `protocol` to version endpoint and model endpoint

Checklist

[x] Added unit test, integration, and/or e2e tests
[x] Tested locally
[x] Update Swagger spec if the PR introduce API changes
[N.A.] Regenerated Golang and Python client if the PR introduce API changes.
[N.A. ] Updated documentation

Client and documentation update will be done in separate PR.

@tiopramayudi @ariefrahmansyah Is it good to merge?

LGTM


Dead link in README to a blog post

Description
The link "Zalando Tech blog post API First" in README.rst is dead (404). There is an archive.org snapshot, for reference.
I'd open a PR to just remove it, but I'm not sure what the authors' intentions are.
Expected behaviour
All links in README.rst lead to a functional page
Actual behaviour
The link "Zalando Tech blog post API First" leads to a 404 page.
Steps to reproduce
Click the "API First" link in the README (https://tech.zalando.com/blog/on-apis-and-the-zalando-api-guild/)

Thanks for pointing this out!

@dtilchin I changed it to link to RESTful API guidelines instead: https://github.com/zalando/connexion/pull/1216


Cant type two polish characters when powertoys is running

Microsoft PowerToys version
0.70.1
Installation method
Microsoft Store
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
I use the Polish programmers keyboard. rightAlt-L and rightAlt-E generate Polish characters normally.
However, when powertoys is running, the latter does nothing at all.
The former does nothing the first time, but locks the windows screen the second time.
If I terminate powertoys, normal keyboard behaviour returns.
✔ Expected Behavior
Be able to type rightAlt-L and rightAlt-E on Polish programmers keyboard.
❌ Actual Behavior
When I type rightAlt E no character appears.
When typing rightAlt L does nothing the first time, but locks the windows screen the second time.
Other Software
No response

Thanks, I’ll try that. In fact, come to think of it, mouse without Borders was the most recent one I activated, so I’ll try deactivating it. See how I go. In fact, I’ll do that now.
Spot on, you are right, that’s the one that was causing it. Okay, I’ve deactivated mouse without Borders and we’ll just use RDP to connect to my laptop since. Practically it probably is more efficient anyway.
Thank you so very much for your help!
Get Outlook for iOShttps://aka.ms/o0ukef

From: Jaime Bernardo @.>
Sent: Monday, June 5, 2023 9:09:53 PM
To: microsoft/PowerToys @.>
Cc: DruhScoff @.>; Author @.>
Subject: Re: [microsoft/PowerToys] Cant type two polish characters when powertoys is running (Issue #26587)
I think this might be because of collisions with Mouse Without Borders shortcuts. Can you please verify if disabling those shortcuts in Settings helps? Reassigning those shortcuts to different keystrokes might help here. /needinfo
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/26587#issuecomment-1576590662, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAINTXII534TBBHIHTFUGFTXJW5ADANCNFSM6AAAAAAYYBUIWU.
You are receiving this because you authored the thread.Message ID: @.***>

/dup #26279


Local cluster tutorial demonstrating fault tolerance and recovery

Added google tags and triggers to track the following key events on page:
Step 4. Add data while the node is offline (using cockroach gen).
Track via event category "docs-fault-tolerance-add-data"
Step 7. Add another node
Track via event category "docs-fault-tolerance-add-node"


Customization of auth providers and  plugging in Kiota authproviders into Graph SDK

Authentication Abstractions in Kiota:
interface AuthenticationProvider {
    authenticateRequest:void;
}

abstract class BaseBearerTokenAuthenticationProvider {
    public authenticateRequest{
        //
    }
    abstract public getAuthorizationToken();
}

class AzureIdentityAuthenticationProvider extends BaseBearerTokenAuthenticationProvider{
    public getAuthorizationToken(){
        // return the access token;
    }
}

Authentication Abstractions in current Graph JS SDK:
class AuthenticationHandler {
    authProvider: AuthProvider
    middleware.execute() or authenticateRequest(){
        if(Graph Specific Condition){
            const token = authProvider.getAccessToken();
            appendToHeader("Authorization", token);
        }
        else {
            deleteAuthHeader();
        }
    }
}

class AuthProvider
{
    getAccessToken();
}

Currently the Graph JS SDK uses a composition pattern. The AuthenticationHandler which is a part of the middleware verifies
if the request url is a Graph URL or a custom host passed by the user and appends the authorization headers.
Goal :
Reuse Kiota AuthProviders such as the AzureIdentityAuthenticationProvider class and authentication abstractions as is in Graph SDKs.
Limitations:
Adding the customizations:
The authenticateRequest in BaseBearerTokenAuthenticationProvidershould append the authorization headers based on the custom conditions. Thereby, the custom logic should also get extended into the child classes such as the AzureIdentityAuthenticationProvider. This limits reusing the existing BaseBearerTokenAuthenticationProvider and the auth providers as is.
Solution:

Apply composition pattern in Kiota. Maintain separate classes, one with the authenticateRequest and one with the getAccesstoken. I suggest this as it promotes reuse of Kiota authorizaton abstractions and classes.

Mantain separate GraphBaseBearerTokenAuthenticationProvider and Graph AuthProviders which extends the former class.

@nikithauc, can you elaborate more on the solution? Where will these implementations live? Could you also share how the graph SDK customers consume these proposed auth providers with an example?

@nikithauc Thanks for reaching out.
To be more specific, the AuthenticationProvider interface doesn't return void, but Promise
https://github.com/microsoft/kiota/blob/75a07e3ee63a0ecdae3b1ebb7778799b9a6e3ab8/abstractions/typescript/src/authentication/authenticationProvider.ts#L10
Similar comment for Base Auth provider
https://github.com/microsoft/kiota/blob/75a07e3ee63a0ecdae3b1ebb7778799b9a6e3ab8/abstractions/typescript/src/authentication/baseBearerTokenAuthenticationProvider.ts#L27
(don't hesitate to get permalinks from the repo, and paste them straight into a comment, GitHub will generate a preview of the code for you)

The authenticateRequest in BaseBearerTokenAuthenticationProvidershould append the authorization headers based on the custom conditions. Thereby, the custom logic should also get extended into the child classes such as the AzureIdentityAuthenticationProvider. This limits reusing the existing BaseBearerTokenAuthenticationProvider and the auth providers as is.

I'm not sure I understand the issue here, Base Auth Provider implement the Auth Provider interface by calling the GetAuthToken from the child type and adding it to the abstract request as authorization bearer header. Which avoids code duplication. Now if I want to implement an SPFx auth provider for Kiota, all I need to do is derive from base auth provider, and implement only the part that gets the token.
In the case of JS core (for the part that allows arbitrary request), all you need to add is a wrapper:

Constructor that accepts a base auth provider from kiota, and keeps it as a private field
Method that implements the interface you've already defined in JS core to get the token, which will call the get access token method from the base auth provider that's passed.

Here are a few reasons why we diverged away from using a middleware to handle authentication:

Forked API surface, you need to pass the auth provider both to the Graph client and the middleware if you're customizing the middleware, Java SDK used to suffer from that.
It mixes concerns: the authentication layer is tied to the http layer, which is an anti-pattern. By separating concerns, we can have a number of different authentication provider implementations work with a number of different http request adapter implementations (typically different native clients).

Hopefully this clears some of the confusion around design decisions that were made a while ago.

@zengin I have tried to explain the solution below. Please let me know if you have more questions.
My suggestion is that we use composition pattern to maintain two interfaces/abstractions separating the:

getAuthorizationToken - This function returns the access token that is received from an authentication library such as MSAL and azure-browser.
authenticateRequest  - This function calls the getAuthorizationToken to get the access token and appends the token in the request headers for Authorization.

The structures would be something as follows:
interface AuthProvider {
    getAccessToken();
}

interface Authenticator {
    authenticateRequest();
}

abstract class BaseTokenAuthenticator() {
    private authProvider : AuthProvider;

    constructor(authProvider){};

    public authenticateRequest(){
       const token = authProvider.getAccessToken();
       appendToHeader("Authorization", "token");
    }
}

Example of the implementations:
import {TokenCredential} from "@azure/identity";

class AzureAuthProvider implements AuthProvider {
    getAccessToken(){
        return TokenCredential.getToken();
    }
}

class GraphAuthenticator extends BaseTokenAuthenticator {
    private authProvider : AuthProvider;

    constructor(authProvider){};

    authenticateRequest(){
        if( //some graph condition ){
            const token = authProvider.getAccessToken();
            appendToHeader("Authorization", "token");
        }
        else
        {
         deleteAuthHeader();
        }
    }
}

A consumer of the Graph JS SDK would provide the AuthProvider instance
import Client from "Graph library";
import AzureAuthProvider from "Kiota AuthProvider";

const graphClient = Client.init({
    authProvider: new AzureAuthProvider();
});

The reason to suggest the separation is that the composition pattern allows to easily customize any function without having to rewrite or reduplicate the child classes.
For example with inheritance if I a user wants to add custom logic in the authenticationRequest for BaseBearerTokenAuthenticationProvider then they would create a MyCustomBaseBearerTokenAuthenticationProvider. But as the AzureTokenAuthenticationProvider is tightly with the coupled the BaseBearerTokenAuthenticationProvider the user would need to rewrite the AzureTokenAuthenticationProvider.
This makes Kiota which aims for a larger set of APIs more customizable.
https://github.com/microsoft/kiota/blob/fcc58327b29dd7a3de2c4aa2f9e79dc679550c98/abstractions/typescript/src/authentication/baseBearerTokenAuthenticationProvider.ts#L5
https://github.com/microsoft/kiota/blob/fcc58327b29dd7a3de2c4aa2f9e79dc679550c98/authentication/typescript/azure/src/azureIdentityAuthenticationProvider.ts#L4
@baywet

In the case of JS core (for the part that allows arbitrary request), all you need to add is a wrapper

I think you are referring to the composition pattern here which I have explained above. Is JS core the Graph JS SDK?

Forked API surface, you need to pass the auth provider both to the Graph client and the middleware if you're customizing the middleware, Java SDK used to suffer from that.

Graph JS SDK has a accepts the authprovider  as a configuration while creating the client and uses a factory to create the client and delegate it to the middleware.

It mixes concerns: the authentication layer is tied to the http layer, which is an anti-pattern. By separating concerns, we can have a number of different authentication provider implementations work with a number of different http request adapter implementations (typically different native clients).

Agree with this. I do not suggest mixing the two.

Encapsulation over inheritance, I like the suggestion :)
So effectively we'd have
interface AuthenticationProvider { //This doesn't change and exists in Kiota today
    authenticateRequest: (request: RequestInformation) => Promise<void>;
}

interface AccesTokenProvider { // We'd add this interface definition in Kiota abstractions
   getAccessToken: (url: URL| string) => Promise<string>;
}

abstract class BaseBearerTokenAuthenticationProvider() {// already exist in Kiota
    constructor(public readonly accessTokenProvider: AccesTokenProvider ){}; // we're adding this constructor and field

    public authenticateRequest = async (request: RequestInformation) : Promise<void> => {} // already exists today, it'd call the authProvider instead of the abstract method

   // we'd remove the abstract method definition
}

// in each authentication package we'd have two things I'm going to take the example of Azure identity

export class AzureIdentityAuthenticationProvider extends BaseBearerTokenAuthenticationProvider {
    /**
     *
     */
    public constructor(credentials: TokenCredential, scopes: string[] = ['https://graph.microsoft.com/.default']) {
        super(new AzureIdentityAccessTokenProvider(credentials, scopes));
    }
}

export class AzureIdentityAccessTokenProvider implement AccessTokenProvider { // this is new
    public constructor(private readonly credentials: TokenCredential, private readonly scopes: string[] = ['https://graph.microsoft.com/.default']) {
        if(!credentials) {
            throw new Error('parameter credentials cannot be null');
        }
        if(!scopes || scopes.length === 0) {
            throw new Error('scopes cannot be null or empty');
        }
    }

    public getAuthorizationToken = async (_: URL|string) : Promise<string> => {
        const result = await this.credentials.getToken(this.scopes);
        return result?.token ?? '';
    }
}

In terms of consumption the user would only have to do:
import Client from "Graph library";
import AzureIdentityAuthenticationProvider from "Kiota AuthProvider";

const graphClient = Client.init({
    authProvider: new AzureIdentityAuthenticationProvider(deviceCodeCredentials, scopes),
});

And the client could use the authentication provider as is for the fluent API or the access token provider for the existing arbitrary API. (by accessing the accessTokenProvider property on the BaseBearerTokenAuthenticationProvider)
Now, this adds a level of complexity but adds the advantage of making the providers reusable for both Kiota and the current JS SDK, (as well as other surfaces like MGT etc...)
@nikithauc did I capture properly what you were expressing?
@andrueastman do you think we should apply that for all languages? I'm tempted to say yes for uniformity even if it means a bit more work.
@sebastienlevert for the experience side of things and the impact on MGT.

@baywet you have captured my suggestions well :) I like the name AccesTokenProvider!
@baywet @sebastienlevert
How about maintaining a separate BaseTokenAuthenticationProvider implementation in the Graph JS SDKs and the other Graph SDKs as follows?
export class GraphAuthenticationProvider extends BaseBearerTokenAuthenticationProvider

and the client initiailization using the Graph JS SDK would look like:
const graphClient = Client.init({
    accessTokenProvider: new AzureIdentityAccessTokenProvider();
});

The Client.init static factory method will take care of passing the instance of AzureIdentityAccessTokenProvider to the GraphAuthenticationProvider. This is close to how we wrap the auth provider in the AuthHandler today.
The Graph user will also have the choice to pass an implementation of the AuthenticationProvider.
The reason I am suggesting a separate GraphAuthenticationProvider is to allow any Graph specific modifications and extensions in the future. We can flexibly make fixes in the GraphAuthenticationProvider in case of any bugs or issues reported by a Graph user.
As for a Kiota user, introducing AzureIdentityAuthenticationProvider and implementations something like MSALAuthenticationProvider is good suggestion.

@andrueastman do you think we should apply that for all languages? I'm tempted to say yes for uniformity even if it means a bit more work.

Yeah. I think we should definitely do it if we can. There are definitely advantages here that would benefit all the SDKs across the board.

@sebastienlevert, I'd suggest that we avoid introducing a SharePointAuthenticationProvider or TeamsFxAuthenticationProvider in Kiota because it tightly couples Kiota with toolchains and leads to a matrix of versions we'd need to maintain in case the logic to get a token in teamsfx or SPFx changes or in case the shape of our provider changes. Also, whenever someone else builds a new toolchain, we'd either need to support it in Kiota or have developers use a different way to get an authenticated Graph client for that toolchain, which would be confusing to them.
Assuming that each toolchain already returns an authenticated Graph client, I'd suggest that we use the Graph client as the input to upgrade to a newer version of the client and not assume any knowledge of toolkits external to Kiota and Graph JS SDK.

@waldekmastykarz I'm curious about those assumptions. Surely the developer knows in why "surface" their code lives (SPA, SPFx, TeamsFx...). So if we tell them "when in SPFx, use that, when in teamsFx, use this" should be straightforward to them. Anyway the rest of the code will change (how to access the context/token etc...).
It feels like we wouldn't be pushing extra burden on them. And the benefit for us would be to have small, dedicated layers instead of a mess of probing logic in a single provider (most likely with any all over the place).
Should SPFx "break something", we can major rev just the package for SPFx, no impact on other audiences.
Lastly I'd argue that having those providers in Kiota is a good thing, since ultimately people could be generating SDKs with kiota for LOBs APIs behind MIP, Dynamics and more. And call those from SPFx, teamsFX etc... Using the same providers for Graph, they'd be able to call those APIs, which sounds like a huge added benefit overall.

Should SPFx "break something", we can major rev just the package for SPFx, no impact on other audiences.

@sebastienlevert This is something keep in mind and discuss about when deciding on the syncing the package version numbers.

Adding @AJIXuMuK from the ODSP team for his opinion on this approach for SPFx. This could help with both providing more flexibility for SPFx developers and reducing the burden on the ODSP team.

My opinion is having access token/auth provider in toolchain seems natural (there are other concerns how SPFx and Graph SDK should communicate, but it's not related to the topic).
The only thing in mind - public interfaces for the provider should not change inside major release.
Otherwise toolchain's dev teams will be forced to update providers prior to the next release of the Graph SDK.


Disable scale animation of thumb while dragging

how can I disable scale animation of leading & trailing thumb? Additionally label also should not move downwards.

try to set selectedHandleDiameterMultiplier=1.0


Does Azure Bot's Tenant (Azure AD) need to be the same Tenant with Teams (O365) to enable Teams Bot Calling?

Discussed in https://github.com/MicrosoftDocs/msteams-docs/discussions/8659

Originally posted by namnam0610 May 18, 2023
Hi all,
After reading the Teams bot calling and meeting document. I am wondering if we can use 2 different tenants (one for hosting the Azure Bot and Azure websites that host the web hook url, and one for the O365 Tenant that MS Teams relies on) or not?

Yes, it is possible to use two different tenants for hosting the Azure Bot and Azure websites that host the webhook URL, and for the O365 Tenant that Microsoft Teams relies on. This setup can be achieved by configuring your bot as a multi-tenant bot.

https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/registering-calling-bot
https://github.com/OfficeDev/Microsoft-Teams-Samples/tree/main/samples/bot-calling-meeting/csharp#register-azure-ad-application


TypeError: unsupported format string passed to NoneType.format

I recently started receiving this error while running the code in random intervals after running.
TypeError: unsupported format string passed to NoneType.__format__
I always had no issues with the module but this started a few days ago, where the code stops working and that error message appears.
This is the code I am using
a=yf.Ticker(QQQ)
b=yf.Ticker(^SPX)
c=yf.Ticker(TSLA)

price1=a.info['regularMarketPrice']
price2=b.info['regularMarketPrice']
price3=c.info['regularMarketPrice']

print(price1)
print(price2)
print(price3)

Is it a Yahoo Finance issue returning a NaN or something else?

Use “if “regularMarketPrice” in a.info to avoid

Thank you for replying, how would your put this into a python code?


Add cause to error.ts

Motivation
Maintain a reference to the original error
Approach
Add the cause attribute

@lc-mm Before I write a test case for this, have you confirmed that this will work for you by linking it into your codebase and attempting to run it?

Yes I am running this code in my production app now.

Yes I am running this code in my production app now.

@lc-mm Fantastic! If I may ask, how long have you been using Effection, and how do you find using it?

Yes I am running this code in my production app now.

@lc-mm Fantastic! If I may ask, how long have you been using Effection, and how do you find using it?

I chose Effection 2-3 months ago to build out a new feature. I wanted to use generators because I had good experiences in the past using redux saga. So far I have enjoyed using it. I did choose to go with v2 until v3 is out of beta.
On a side note I am using it in react native and did have to add this in order to start using it:
window.addEventListener = (x: unknown) => x;
window.removeEventListener = (x: unknown) => x;

Interesting. I'm guessing it's because the main() method? https://github.com/thefrontside/effection/blob/v2/packages/main/src/browser.ts#L33
What would we do to detect the react native app unloading?
Also, please let us know if there's any questions you have, or feedback. We're always looking for ways to improve.

There is no way that I know of to detect the app closing or unloading, You can detect application states such as foreground or background. When the user closes an app the execution stops without any notice


Client container can not be pushed currently

Just for tracking, real ticket here https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1366

Fixed


Deprecate this driver

Hey folks. Here's the good news: Cycle DOM now supports selecting document and body. Awesome! Users can now do things like:
DOM.select('document').events('mouseup');
Since this is now supported, we don't need to use a driver to do this.
What shall we do with Cycle Mouse Driver? Keep it, or deprecate it?
My preference would be to deprecate it, and encourage users to go ahead and use the new DOM feature.
Does anyone see a reason not to deprecate this driver?

+1 for deprecate

Deprecated 😄

It might be good to publish a new version on npm so that the deprecation notice shows up there

@farism I thought that I had, but clearly not! I'll do it tonight when I'm on my home computer. Thanks for letting me know.


Assertion failure when running Kinetic Merge in MoveDestinations.isDegenerate.

Version: 1.2.5
Reproduction

Set up a blank Git repository.
Switch to new branch: git checkout -b master.
Commit file aFile.txt with content of:

This is the first line,
followed by the second.

Can you see where this is going?
Need a hint?
THE END.

Tag the commit with git tag base.
Switch to new branch: git checkout -b renaming
git mv aFile.txt theRenamedFile.txt.
Edit the content of theRenamedFile.txt to be:

This is the first line,
followed by the second.

Can you see where this is going?
Need a hint? No, good - you're a quick study.
THE END.

Update the index: git add theRenamedFile.txt.
Commit the rename and edit.
Switch back to master: git checkout master.
Edit the content of aFile.txt to be:

This is the obligatory zeroth line.
Can you see where this is going?
Need a hint?
This was the first line,
followed by the second.

THE END.

Update the index: git add aFile.txt.
Commit the edit.
Run Kinetic Merge to bring in the renaming + edit: kinetic-merge --no-commit renaming.
This will fault with a stacktrace of:

Exception in thread "main" scala.MatchError: java.lang.IllegalArgumentException: requirement failed (of class java.lang.IllegalArgumentException)
	at com.sageserpent.kineticmerge.Main$.apply$$anonfun$1(Main.scala:240)
	at scala.util.Success.fold(Try.scala:281)
	at com.sageserpent.kineticmerge.Main$.apply(Main.scala:243)
	at com.sageserpent.kineticmerge.Main$.main(Main.scala:78)
	at com.sageserpent.kineticmerge.Main.main(Main.scala)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at coursier.bootstrap.launcher.a.a(Unknown Source)
	at coursier.bootstrap.launcher.ResourcesLauncher.main(Unknown Source)

Discussion
Debugging shows that this is down to a requirement assertion failure in com.sageserpent.kineticmerge.core.MoveDestinations#isDegenerate.

While we're at it, that diagnostic is lousy - what we should see is the original requirement assertion failure with the stacktrace of where it was thrown. What we currently see is some exception handling code that wasn't expecting to see the IllegalArgumentException propagated up.
Need to fix that as a prelude to the bug-fix.

As of cc7477cad70b87d2d095da6a15d0814341be3193, the bug leads to a better diagnostic when running Kinetic Merge.
A bug reproduction test has been added: MainTest.issue48BugReproduction - and it fails!
Looking at the logging from the failing test shows that the base form of aFile.txt has a filler section of THE END., whereas the left form of aFile.txt and the right form of theRenamedFile.txt have left-right matching sections of .\nTHE END.. Now this isn't very pretty, but it is valid, and provokes the bug...
Investigation reveals two problems:

The requirement assertion is part of the invariant for MoveDestinations. It asserts that if the move destination is degenerate, i.e. there is no source for the move, then it must be either a divergent move where matched sections are inserted at different locations (possibly in different files) or is a coincident move where the matched sections align in the same file. The problem here is that a divergent move is picked up in distinct left moves and right moves, possibly across distinct files, so the invariant is temporarily boken while the overall MoveDestinationsReport is being built up. It is straightforward enough to hoist the requirement assertion out of MoveDestinations and into CodeMotionAnalysisExtension.merge to become an assumption, valid once all the per-file merges have been collated together.
Solving the first problem leads to the next - there is an edit-versus-deletion merge conflict when aFile.txt is merged, where the edit replaces the filler section THE END. with .\nTHE END. on the left. That does not lead to a left move being registered, whereas theRenamedFile.txt does register a right move. Thus both the original invariant and the more relaxed assumption break.

Interestingly, the change mentioned above in 4.i. is enough to get a conflicted merge if the minumum match size is set to 3 (the default is 4). This allows an all-sides match of THE END. and shifts the left-right match to the preceding .\n. That left-right match results in a straight divergent insertion move across the two files.

The crux of 4.ii is that we have what would be a divergent insertion, but one side of the insertion is hidden by virtue of being in a edit-versus-delete merge conflict.
What should this look like, bearing in mind that what was the base section was nearly a match for the inserted sections...?

Musing about the previous comment's questions - if a move destination (be it divergent or not, or a migration or an insertion) shows up in a conflict (be it edit-versus-delete or edit-versus-edit), then it really is a move, regardless of whether the user resolving the merge decides to keep it in preference to the other side of the conflict, or allow both in some order, or meld them together, or delete it in favour of the other side, or just completely rewrite the conflict to something new.
The fact is, the conflict records two competing valid bits of content, and one of the them is a move destination.
So we should record it as such.
The other thing is, given the changes made in #43, why didn't the base section act as a gap chunk and thus make a last-minute match in the merge? The answer is, because the left and right actually made a match, and these are held as sacrosanct; matched sections are not considered for breaking up by gap chunks. All of which makes me wonder whether it's worth finding a way of rooting out small matches that are not ambiguous. Here we go again...

Spike work done in 99951ff339415d9a4f02d91d24a30db616d5f7b4 shows that a fix is feasible, but exposes another unrelated bug; spun out a new issue for that: #49.
Now to write more tests and complete the cut over of the conflict handling logic in MatchesContext...

While reviewing MatchesContextTest, it occurs to me that the codebase tracks moves via their destinations - this is reflected in the tests for the merge algebra furnished by MatchesContext - only incoming moves appear in test expectations.
On the other hand, migrations have to picked up at the move sources - which is fine, only they are associated with the move destinations. This feels a bit odd - why not associate them with the move sources and apply the migrations by referring back to the move sources that match a given move destination. One to ponder...

As of 8d47ce7231cc32c7ae066e8e0e5434694bfa16c5, new tests added into MatchesContextTest, these detect failures in the code prior to the spike, and pass subsequent to it.

This went out in Release 1.3.0.


ArangoDB as vault backend

Vault is a secret store from Hashicorp that allows leasing username/password credentials for backends such as databases and ssh.
It would be really awesome if the ArangoDB team can contribute an ArangoDB backend, so that vault users can dynamically lease usernames and passwords for accessing ArangoDB through vault.

if I see that correctly, Their http API is already wrapped by a node module - You could simply convert that to use the ArangoDB HTTP client. You could use the foxx authentication demo as a starting point.

In my understanding the linked node module has no connection to the project by hashicorp and hashicorp states in their documentation, that it's not possible right now to contribute third party auth backens. I would love that, too, but right now there does not seem to be a way to accomplish this.

If anyone is still interested in that, here's my shot at it:
https://github.com/eplightning/vault-plugin-database-arangodb
It's a plugin for HashiCorp Vault that allows dynamic / static ArangoDB credentials management .


Clippy: Fixes and CI

This is the next big step after #3292, inspired by #3271. The remaining RUSTFLAGS exceptions and the examples code are left as future work.

@Liamolucko, can you please review this PR? It contains trivial changes. Is there anything I should change?

@Liamolucko ping. This PR gets a lot of merge conflicts, can you tell when you can review it, so I can rebase it before?

@lukaslihotzki I can review and merge this, so a rebase would be welcome!


add comments for each file,

Pull Request
Description
Add comment to code
no code change

@braddf if you want to have a look at this, I recon either lets

merge if useful
add a few more comments, then merge
close the merge if not useful

out of date


[stable/cluster-autoscaler] Allow individual envs from secrets

Is this a new chart
No
What this PR does / why we need it:
Previously the envFromSecret config accepted a single secret name and all keys from this secret would be exposed as envs, using the same key name as the env name.
This commit changes the envFromSecret config to be a map in the format:
envFromSecret:
  <env var name>:
    name: <secret name>
    key: <secret key>

This adds more flexibility by allowing to expose selected keys from a secret and also allowing for a different name for the env variable. The new behavior is identical to the existing envFromConfigMap config.
Special notes for your reviewer:
This is a breaking change, that's why I bumped the version to 4.0.0. If a breaking change is not wanted it would be possible to add a new config value instead of replacing the behavior of the old one. However, this could be confusing due to similar config values with different behaviors.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

Thanks. What's the use case for this? Why wouldn't you just prepare your secret appropriately? This seems to break the pattern used by other charts, so I'm hesitant to merge.

I'm using this chart to deploy the autoscaler to a different cloud provider from the officially supported ones and each provider decides on which envs are required.
The main idea behind this change was sharing existing secrets instead of creating new ones with possibly the same data. Say I have a secret which contains the data provider-secret: supersecret which is used by some cluster components, but the autoscaler provider implementation requires an env named PROVIDER_SECRET_KEY. Creating duplicated secrets is a possibility but would require some extra work when updating the secret value.
About breaking the pattern found in other charts I found a reference to something similar in the reloader chart:
https://github.com/helm/charts/blob/f918e6f7572e5cea34d14fc5ee67566216de8bea/stable/reloader/templates/deployment.yaml#L49-L57
However, as you said, this is not very common. Another possible approach would be being even more flexible in our configuration and allowing a list of full env blocks (currently this chart only allow extra keys and values in the extraEnv field). Some examples of this other approach:
https://github.com/helm/charts/blob/f918e6f7572e5cea34d14fc5ee67566216de8bea/stable/airflow/values.yaml#L22-L27
https://github.com/helm/charts/blob/f918e6f7572e5cea34d14fc5ee67566216de8bea/stable/nginx-ingress/values.yaml#L108-L114
This approach is used in a lot of other charts including the locust, selenium, cert-manager and many others.
I'd be happy to change this PR to use this other approach, however a decision would have to be made regarding the existing extraEnv: {}. First option would be to still do a breaking change, altering the existing extraEnv to a be a list. Another option would be creating a new values field as a list called extraEnvs as some charts use it that way.
Would any of these options be okay?

Thanks for the detailed response. I'll have to think on this. Hopefully we can get some other opinions too.

Thining

Sorry for taking so long, I was on vacation last week. I have updated/rebased the PR with your suggestion, I think it's nice. I also changed the README a bit to try making it clearer on the difference between envFromSecret and extraEnvSecrets.

Thanks!
/approve
/ok-to-test
/lgtm


Support pre-exit hooks

Moin!
Currently I can put a environment hook into S3. I would like to have support for the pre-exit hook.
I had a look at the code.
How about introducing another optional environment variable. It can be set to environment or pre-exit and if it is set to pre-exit, it does the same for pre-exit as it normally does for environment.
Would you accept such a contribution?
Cheers
Ruwen

Hi @elruwen. Thanks for your question! We only want to support the use case of retrieving secrets from S3 in with this repo. If you would like to store part of an agent hook in S3, then it may be simpler to create the hooks in your agents hook path as bash scripts that download what then need from S3.
Perhaps if you could explan more about your use case and why you would like to run a pre-exit hook stored in S3 rather than, for example, a plugin stored in a git repo, we may be able to consdier this more throughly.


drivers: modem: gsm: introduce lock

After the introduction of start/stop & rssi query work, these
additional functions can be invoked from different threads.
Things can quickly become hard to analyze when an interrupt
fires during one of these functions and upon return the
scheduler schedules another thread and run another function.
This PR introduces a simple mutex lock that guarantees thread
safety. Similar implementation can be found in hl7800 driver,
which has lots of public APIs that can be invoked from different
threads.

cc @bbilas @endian-benjamin

Of course given this patch set, it is rather tempting to introduce a return value and a timeout param to gsm_ppp_stop() - or a new function possibly. I wouldn't insist on that change being done in this PR, but I'd prefer having gsm_ppp_lock() just take a timeout (you can just have all current calls pass K_FOREVER)
Another thing to note is that gsm_ppp_stop() is now blocking, which is sort of an implicit API breakage. Not sure if that's a big deal or not, just thought I'd point it out.

introduce a return value and a timeout param to gsm_ppp_stop()

That is planned in the FSM implementation later

Another thing to note is that gsm_ppp_stop() is now blocking, which is sort of an implicit API breakage. Not sure if that's a big deal or not, just thought I'd point it out.

The driver upstream is blocking since 19910666e03888e083244fe04246686d7531409f and more recently 60beb291dfbdde1e8aebf98dcb57a3dd8686cc4b


build(app-shell): build app's python env with pandas as dependency to match robot's env

Overview
Include the pandas library in the app's python environment as it is a default package available on
the OT2's python environment.
Closes https://github.com/Opentrons/opentrons/issues/10874
Changelog

add pandas version 0.25.3 via pip in the app-shell's setup of it's bundled python environment

Review requests

please take the app build generated by CI for this branch and upload a protocol that import's and uses the pandas python library. App-side protocol analysis should succeed

Risk assessment
med, pandas is a very heavy dependency to add to the app's build, otherwise there is not much risk

Is Pandas the only package we need to add?
The pip list on the robot is the below, are there other packages we expect to be used in protocols?
# pip list
Package               Version
--------------------- -------
aiodns                1.1.1
aiohttp               3.4.4
aionotify             0.2.0
aiosqlite             0.17.0
anyio                 3.3.0
asgiref               3.4.1
async-timeout         3.0.1
attrs                 18.2.0
bleach                3.1.0
cchardet              2.1.4
click                 8.0.1
decorator             4.0.11
defusedxml            0.5.0
entrypoints           0.3
fastapi               0.68.1
greenlet              1.1.2
h11                   0.12.0
httptools             0.2.0
idna                  3.2
importlib-metadata    4.6.3
ipykernel             5.1.0
ipython               5.8.0
ipython-genutils      0.2.0
Jinja2                2.10
jsonschema            3.0.2
jupyter-client        5.2.4
jupyter-core          4.4.0
MarkupSafe            1.0
mistune               0.8.4
multidict             4.4.2
nbconvert             5.4.1
nbformat              4.4.0
notebook              5.7.4
notify-server         6.0.0b0
numpy                 1.15.1
opentrons             6.0.0b0
opentrons-shared-data 6.0.0b0
otupdate              6.0.0b0
pandas                0.25.3
pandocfilters         1.4.2
pexpect               4.6.0
pickleshare           0.7.4
pip                   18.1
prometheus-client     0.6.0
prompt-toolkit        1.0.13
ptyprocess            0.5.1
pydantic              1.8.2
Pygments              2.2.0
pyrsistent            0.14.11
pyserial              3.5
python-dateutil       2.7.5
python-dotenv         0.19.0
python-multipart      0.0.5
pytz                  2018.7
pyzmq                 19.0.2
robot-server          6.0.0b0
Send2Trash            1.5.0
setuptools            44.0.0
simplegeneric         0.8.1
six                   1.16.0
smbus                 1.1
sniffio               1.2.0
SQLAlchemy            1.4.32
starlette             0.14.2
syslogng              1.0
systemd-python        234
terminado             0.8.1
testpath              0.4.2
tornado               5.1.1
traitlets             4.3.2
typing-extensions     4.1.1
uvicorn               0.14.0
uvloop                0.14.0
wcwidth               0.1.7
webencodings          0.5.1
websockets            9.1
wsproto               1.0.0
yarl                  1.2.6
zipp                  3.5.0

@y3rsh @b-cooper This seems kind of can-of-wormsy considering that people can install whatever they want (as long as it's not native) on the OT-2 environment. I'm wondering if we should keep this bare minimum, maybe with pandas but nothing after that, and officially note or have error messages for when you import something that the sim doesn't have. Maybe in the longer term we can have the sim environment be controllable or something.

Also @b-cooper do you actually intend to put all 36 of these commits in release_6.0.0?


Is it possible to save a cache on Azure storage account through your action?

Is it possible to save a cache on Azure storage account through your action?

I've not tested but it should be possible since OpenDAL support Azure Blob. Maybe you could have a try.

Should be possible. Please let us know if it doesn't work.


Improper Token Matching Order

The order of token definitions in the TOKENS list affects how patterns are matched against the input code. Generic patterns like NUMBER`` (r"\d+(\.\d+)?) appear before more specific patterns like FLOAT_NUMBER (r"\d*\.\d+|\d+\.\d*"), potentially causing incorrect tokenization. For example, a floating-point number such as 3.14 might be incorrectly matched as NUMBER instead of FLOAT_NUMBER.
Example
("NUMBER", r"\d+(\.\d+)?"),   # Generic number
("FLOAT_NUMBER", r"\d*\.\d+|\d+\.\d*"),  # Specific float number
Potential Impact:
Incorrect token types may be generated during tokenization.
Floating-point numbers might be misclassified as integers.
Logical errors or bugs in subsequent processing stages.
Suggested Fix:
Reorder TOKENS so that specific patterns appear before more generic ones:
("FLOAT_NUMBER", r"\d*\.\d+|\d+\.\d*"),  # Specific float number
("NUMBER", r"\d+(\.\d+)?"),   # Generic number
File to make changes:
crosstl/_crosstl.py
@NripeshN Would you like this fix implemented ?

Solutions for Improper Token Matching

Use the Correct Tokenizer
Ensure the tokenizer matches the pre-trained model.
python
Copy code
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("bert-base-uncased")
text = "What is token matching?"
tokens = tokenizer.tokenize(text)
print(tokens)
2. Include Required Special Tokens
Ensure inputs are properly formatted with special tokens:
[CLS]: For classification tasks.
[SEP]: To separate segments in sentence-pair tasks.
python
Copy code
input = tokenizer.encode("What is token matching?", "Explain tokenization.")
print(tokenizer.convert_ids_to_tokens(input))
3. Validate Token and Label Alignment
When working with token-level tasks:
Match each token to its corresponding label.
Use subword token alignment techniques (e.g., for BERT WordPiece tokens).
python
Copy code
from transformers import BertTokenizerFast
tokenizer = BertTokenizerFast.from_pretrained("bert-base-uncased")
tokens = tokenizer("Token alignment example.", return_offsets_mapping=True)
print(tokens['offset_mapping'])
4. Handle Overlapping Matches
Use strict matching rules or regex to avoid overlapping patterns:
python
Copy code
import re
text = "token matching example"
pattern = r"\b(token|matching)\b"
matches = re.findall(pattern, text)
print(matches)

Please assign this issue to me. I would like to handle this issue.

Hi @jigyanshrathore @haroonbashi2514 @AeleSahithi
To assign issues to yourself please read this documentation: https://github.com/CrossGL/crosstl/blob/main/CONTRIBUTING.md#-assigning-or-creating-issues

@CrossGL-issue-bot assign me

@CrossGL-issue-bot assign me

@CrossGL-issue-bot assign me

@CrossGL-issue-bot assign me

Assigning @AeleSahithi as they are the author of the issue

@NripeshN @vaatsalya123 Could you please review #225 this merge request? Thank you!

I’d like to work on this issue. Could you please assign it to me? @NripeshN


[Select] Does not work properly with keyboard navigation when using NVDA in chrome

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behaviour 😯
When using the keyboard to navigate, the dropdown for choosing rows per page does not behave as expected. When opening the dropdown using enter/space, it opens properly and receives focus. After that, you can't use the arrow keys to move up/down. If you press enter/space again, you can move using the arrows. This is present on the material ui table documentation page. This is only a problem when NVDA is running (version 2020.4).

(When pressing arrow down repeatedly, NVDA repeats rows per page list 5)
Expected Behaviour 🤔
As soon as you open the dropdown, you should be able to navigate the options using arrows while NVDA is running.
Steps to Reproduce 🕹
Steps:

Start NVDA
Go to https://material-ui.com/components/tables/ in chrome
Tab down to an example that has the ability to set rows per page (e.g. https://material-ui.com/components/tables/#sorting-amp-selecting)
Open the dropdown using space or enter
Press up or down arrow -> nothing happens

Context 🔦
We are building an advanced table extension for Qlik Sense, where we would like a consistent keyboard navigation solution. The a11y setup we support is NVDA in chrome on windows, so a different screen reader is not an option unfortunately.
Your Environment 🌎
Windows 10
Chrome Version 90.0.4430.93
NVDA version 2020.4

@haxxmaxx Please test on v5, v4 is not relevant

Thanks for the quick respons! Same problem on v5.

I just noticed that it works on the https://next.material-ui.com/components/tables/#custom-pagination-actions example, because of using the native dropdown.

@haxxmaxx Thanks. It looks like we have quite many issues: https://github.com/mui-org/material-ui/issues?q=is%3Aopen+label%3A"component%3A+Select"+label%3Aaccessibility.

Ah I see. I noticed that space isn't working to confirm as well, mentioned in one of those bugs. We might actually consider using the native one

I noticed that space isn't working to confirm as well, mentioned in one of those bugs.

@haxxmaxx Interesting, @eps1lon worked on this in #18754.

I was just testing the unstyled select, and looks like it works much better. I am able to open, navigate, select items and they are properly announced. @haxxmaxx would you like to check https://mui.com/components/selects/#unstyled-component (it basically reads similar as the native select) cc @michaldudak good job on the unstyled component.

Yupp seems to work fine! We are currently using the native one. We will do some design changes eventually, we'll keep the unstyled one in mind 👍

Perfect, thanks for the confirmation @haxxmaxx


ci: reduce job permissions to minimum

@Fdawgs oh I have no doubt about this, but are we really now going and changing ALL the workflows to do this? There surely must be a better way

Pino could follow Fastify plugins' impending move to shared workflows, so that it only needs to be changed in one place?

I think it can be applied at the organization level.


Add getters for FOV limits

It may be useful to know the current FOV limits so user code can change them sensibly. And, to do this without needing to parse the attributes (duplicating work).

recreating with non-master branch: https://github.com/google/model-viewer/pull/1218


The method name should be changed as getAuthenticatedUser currently it says getAuthenticateUser

https://github.com/DInuwan97/wso2-IS-UAEPass-authenticator/blob/3520e437999c514ef9b2711a6eb14ee306615b0d/uae-pass-federated-authenticator/src/main/java/org/wso2/carbon/identity/uae/pass/federated/authenticator/UAEPassAuthenticator.java#L237

@lakshithakasun check this out #2


feat: introduce composer-extension

This PR sets up the foundation for embedding composer inside github but does minimal work on integration which will be done in followup PRs.
copilot:all

Current dependencies on/for this PR:

main

PR #3168   👈

This comment was auto-generated by Graphite.


WIP : Cico planner

Run build + unit + func tests on cico

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-3 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-4 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-5 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-6 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-7 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-8 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-10 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-11 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: docker pull registry.devshift.net/MISSING_IMAGE_NAME:SNAPSHOT-PR-2473.

@pranavgore09 Your image is available in the registry: docker pull registry.devshift.net/MISSING_IMAGE_NAME:SNAPSHOT-PR-2473.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-12 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: docker pull registry.devshift.net/MISSING_IMAGE_NAME:SNAPSHOT-PR-2473.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-13 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-14 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: docker pull registry.devshift.net/MISSING_IMAGE_NAME:SNAPSHOT-PR-2473.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 $MISSING_REGISTRY/$MISSING_IMAGE_REPO:$MISSING_TAG.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-15 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-16 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_REGISTRY/MISSING_IMAGE_REPO:MISSING_TAG.

Codecov Report

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

@@          Coverage Diff           @@
##           master   #2473   +/-   ##
======================================
  Coverage    9.91%   9.91%
======================================
  Files         195     195
  Lines       12601   12601
  Branches     1776    1776
======================================
  Hits         1250    1250
  Misses      11282   11282
  Partials       69      69

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c93e159...e4fcc2f.

This PR is now working on both platforms cico and f8.jenkins.
The only change I need to make is google chrome getting downloaded from random repo here
I am struggling to find out official chrome releases for each version. Once that is done this PR will be good to merge.

We should separate those out and provide a shell-oriented Makefile that one can execute on a local machine as well.

@kwk agreed, but can that be considered into a followup patch? We (me and pranav) are considering addition of Makefile and define its most appropriate purpose (without taking-away/stepping-onto npm or gulp's tails). But that will need a bit of followup, and better done when this and the standalone Planner patch are through (so to say, the architecture is a bit more stable).

@debloper I'm just here to say that npm and gulp can be as good as they want but they probably will never beat a Makefile when it comes to just executing commands and making the computer do something. So please don't put this build stuff into npm or gulp would you?

The spec-file changes shouldn't need to be part of this PR.
Put stuff back into the Dockerfile instead of running those steps with docker exec
If you need to run multiple commands as entrypoint, then make a script out of them and run that.

thanks @kwk for spending time on review and for creating this https://github.com/fabric8-ui/fabric8-planner/issues/2506 issue for adding makefile.
I just want to keep this PR small and short, already we are having so many abstraction levels to find from. Sometimes I feel the single source of truth is better than jumping all over places. Still, I agree with your concerns and I would like to keep #2506  out of this PR.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-49 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@debloper

The spec-file changes shouldn't need to be part of this PR.

Spec file changes are absolutely necessary and should go in with this PR. Those changes stabilize the tests.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-51 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-52 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-53 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-54 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-55 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-56 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-57 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

[test]

@pranavgore09 The [test] command triggered a new build. The [test] command is not project specific, it is cico specific.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.

@pranavgore09 fabric8/fabric8-ui:SNAPSHOT-PR-2473-60 is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-2473-fabric8-planner.badger.fabric8.io

@pranavgore09 Your image is available in the registry: Run docker run -e PROXY_PASS_URL="https://api.free-stg.openshift.com" -p 8080:8080 MISSING_IMAGE.


GUI: No scrolling while drag and drop

Operating system or device - Godot version:
Mac OS 10.10.5, Godot 2.1
Issue description (what happened, and what was expected):
If you move nodes from up to down or down to up the node list don't scroll. So you can move nodes inside the visible entries of the list only.
If you move s sprite from the ressource browser to the sprite definition with drag and drop, then the sprite slot have to be visible. Also here no automatic scrolling with an object "in the hand".

is this resolved by #6529?

#6529 should fix the issue for the first part - node editor, it was merged to 2.1.1.
@Lebostein can you check it with 2.1.1 rc2?

I can confirm this is fixed on current master head. cdc4664226cdc397d054b7390d0f75028d40412c


<EMAIL_ADDRESS>

<!---


Year needs to update dynamically in footer

Describe the bug
Year needs to be update dynamically in footer
To Reproduce
Steps to reproduce the behavior:

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

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Hello @thestarsahil please assign this issue to me under gssoc 24

Thanks, As we accepting major 3 level of problem , and this is one of them
We request to contribute as much as possible with containing level 3

Hello @thestarsahil here is pr https://github.com/Counselllor/Counsellor-Web/pull/748 for this issue please check


Live Demo is down

The backend for the live demo on the website is down

Thanks! I’ll look into it.

Fixed!

Hello the backend for the live demo on the website is down since at least yesterday Feb 17 2021
Would be great to give it life back ...🤞🏽🙏🤓


Update copyright year logic

See as title
Test
test locally

Reviewers
@mhluongo @henryboldi @Shadowfiend

Hi guys, can i get a stamp ? @mhluongo @henryboldi @Shadowfiend

Drat, I forgot about commit signing requirements. @rootial  if you have signing set up, can you force-push a branch of signed commits? If not I can vouch and sign these myself to get it on main

I have not setup sign, can you help on this ? thx @mhluongo

@rootial Here's a helpful video tutorial on signing commits! https://www.youtube.com/watch?v=4V-7KnhcrbY
The video essentially walks you through the written guide here https://github.com/pstadler/keybase-gpg-github

Signed myself and pushed to master ea30209ac70ff9f0bebdd6d3349726e7ac63ba2e. Thanks @rootial!


Intel BigDL 0.7 and Analytics Zoo 0.4 support for dataproc init script

The current version of BigDL init script has a very old link to old version of BigZL and doesn't support BigDL with Zoo configurations.
This PR fixes this.

I signed it!

Out of curiosity, does the new BigDL version still work on Dataproc 1.2 (Spark 2.2.1?). Just asking for backwards compatibility reasons.

Never tried it myself, but BigDL v0.7 should work even with Spark 1.6. The related packages are available to download from here https://repo1.maven.org/maven2/com/intel/analytics/bigdl/.

Also, consider adding an integration test, if you have time :) E.g. https://github.com/GoogleCloudPlatform/dataproc-initialization-actions/pull/391/files
:) It looks that I need more time (and being Python-minded :P) for this that I have had at the moment.


Support custom loss function for DNNRegressor

DNNRegressor is commonly used, and it does not support customize the loss function, which limits itself.
I wanna know if there are any schedule to support the customize loss function for DNNRegressor or is there any difficulties for supporting that?

What other loss function would you like to have?

You can use tf.contrib.learn.DNNEstimator which takes a head as argument.
You can define any loss fn you want via head.

I will use DNNEstimator, thanks for replying.