Disable RequestAuthentication JWT rules for specific paths

Describe the feature request
I am using the RequestAuthentication API at the Istio Ingress Gateway to enforce clients to present a valid JWT token. This is working fine.
However there are some workloads within the cluster which need to be exposed without the need to have a valid JWT token. One such workload is Keycloak which serves as the OAuth provider. Keycloak is responsible for issuing tokens, so clients accessing the Keycloak's path (/auth) can NEVER present a valid JWT token. Similarly there could be other paths that I need to expose without JWT token.
In the RequestAuthentication API, there are no fields to specify excluded paths. See below the API specification in version 1.7:-
https://istio.io/latest/docs/reference/config/security/request_authentication/
In the legacy Authentication API (in Istio version 1.4) it had support for excluded paths. See below link for the API specification in Istio 1.4:-
https://istio.io/v1.4/docs/reference/config/security/istio.authentication.v1alpha1/
See below text from above link:-

A JWT for all requests except request at path /health_check and path with prefix /status/. This is useful to expose some paths for public access but keep others JWT validated.
issuer: https://example.com
jwksUri: https://example.com/.well-known/jwks.json
triggerRules:

excludedPaths:
exact: /health_check
prefix: /status/

However when the API's were re-designed in Istio 1.5, this functionality is missing.
Find below the YAML manifests of RequestAuthentication and AuthorizationPolicy I am using (these manifests enforce JWT authentication for ALL paths and specifically would permit access to path /nginx subject to meeting the rules defined in the authorization policy):-
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: my-request-authentication
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
      istio: ingressgateway
  jwtRules:
  - issuer: "https://www.example.com/auth/realms/mxe"
    jwksUri: "https://www.example.com/auth/realms/mxe/protocol/openid-connect/certs"

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: my-authorization-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
      istio: ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["https://www.example.com/auth/realms/mxe/4374027b-f16e-4da1-8445-b0ebd09f5905"]
    to:
    - operation:
        paths: ["/nginx"]

Describe alternatives you've considered
The moment I install a ReqestAuthentication object and an AuthorizationPolicy object, Ingress Gateway expects EVERY request to fulfill the JWT rules specified in ReqestAuthentication. I don't know if my requirement can be achieved in an alternate manner using the existing APIs.
If there are alternate ways to fulfil my requirement, I would be glad if someone can point me towards that.
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[X] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Additional context

@yangminzhu Hi Yangming, could you take a look? Thanks!

The moment I install a ReqestAuthentication object and an AuthorizationPolicy object, Ingress Gateway expects EVERY request to fulfill the JWT rules specified in ReqestAuthentication. I don't know if my requirement can be achieved in an alternate manner using the existing APIs.

It's also doable in the new API, you can use the following to exclude path (e.g. "/healthz") from JWT:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: my-authorization-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
      istio: ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["https://www.example.com/auth/realms/mxe/4374027b-f16e-4da1-8445-b0ebd09f5905"]
    to:
    - operation:
        paths: ["/nginx"]
  - to:
    # The 2nd rule doesn't have `from` allowing any access (without JWT) to /healthz
    - operation:
        paths: ["/healthz"]

Also see https://istio.io/latest/docs/tasks/security/authentication/authn-policy/#require-valid-tokens-per-path

@yangminzhu : the solution you provided works. thanks.
closing this issue.

@yangminzhu Dose paths: ["/nginx"]  support path prefix?

You might want to exclude the path also from EnvoyFilter https://stackoverflow.com/questions/63448933/istio-exclude-service-from-ext-auth
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: bypass-authn
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
    - applyTo: HTTP_ROUTE
      match:
        routeConfiguration:
          vhost:
            route:
              name: /public/path
      patch:
        operation: MERGE
        value:
          name: envoy.ext_authz_disabled
          typed_per_filter_config:
            envoy.ext_authz:
              "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthzPerRoute
              disabled: true

Let's say I want to allow wrong Tokens for specific paths?
With the above solutions a requests with a bad token would still fail, right?
Cause as soon as there is a token present it will be validated 1st before any other rules might be applied?

Same here, have you find any solution? @JohnniDi

I also need to support non-JWT Authorization Bearer values - has anyone found a workaround?


More hygenic version of styled_components

The current version of styled_components leaks the identifier __stylist_style_manager__. This can't be worked around without ditching the design and switching to a proc macro declaring other proc_macros, since __css_yew_impl has to have that identifier in scope.
In any case, I don't see a reason to not use function_component directly and have a hook-like macro that introduces the scoped versions. That's what use_stylist!(css); does: get the manager with use_context, then introduce macro_rules that are ready to use at the call-site, that refer to that manager (and the unmodifed stylist-macros).
There are a few hacks along the way that can be improved in the future, if the rust compiler follows accordingly.

The hacky ($dol:tt) to expand to a literal dollar sign in a proc macro comes from this issue but when RFC 3086 gets merged, this gets simplified to just using $$.
The whole macro rule is in a separate crate. Unfortunately, to export it from stylist, if it was defined in stylist, it needs a #[macro_export] slapped onto it, which also makes it visible from the crate root. Trying to hide it there in the docs with doc(hidden) also hides the re-export. If it's okay with you, I'd accept the re-export at the crate root, maybe with a textual warning in the docs?

There's also goodies to get

Allow the user to chose the name of the macro. Simple as use_stylist!(css as stylist_css) or similar.
No need to track yew-upstream for changes to the function_component macro to mirror

Macros still need test cases for style! and global_style! and the impl is probably wrong, cause with_manager doesn't yet exist for those.

Thank you for the PR.
However, I don't think use_stylist(css) is a good replacement of styled_component.
Consider the following two designs:
use yew::prelude::*;
use stylist::yew::styled_component;

#[styled_component(Comp)]
pub fn comp() -> Html {
    html! {

}
}

use yew::prelude::*;
use stylist::yew::use_stylist;

#[function_component(Comp)]
pub fn comp() -> Html {
    use_stylist!(css);
    html! {

}
}

In my opinion, use_stylist!(css); is counter intuitive.
Despite I understand what the code above does, when seeing the code above, my mind tells me that it's invoking a function call taking a variable css instead of some kind of assignment.
Even the following does not mass with my mind as much.
use yew::prelude::*;
use stylist::yew::managed;

#[function_component(Comp)]
pub fn comp() -> Html {
    #[managed]
    use stylist::css;
    html! {

}
}

This also applies to other crates use a syntax like this to declare stuff which I wish to avoid to introduce a similar usage.
Why #[styled_component(Comp)] over other designs?
This is an ergonomic design that adds 0 lines of code over standard function_component.
All other ways I can think of introduce at least 1 line of code for each component which is an unnecessary overhead to pay compare to this design.
In addition, styled_component is very iconic and will leave a deep first impression to users which is a deliberate choice I made when making this API.
leaking __stylist_style_manager__ is unhygienic.
This is true. But I am happy to overlook this issue at the moment this because it's very unlikely to collide this variable name unless the user is deliberately doing so.
Additionally, this can be solved with Span::def_site() once that becomes available in stable Rust.
style! and global_style! do not support with_manager.
This is by design.
Users should use APIs in stylist::yew::* over other APIs when using stylist with Yew.
I don't think use of style! and global_style! is justified when css! and <Global /> is available and more ergonomic to use.
Emotion also make a similar distinction on @emotion/react and @emotion/css where one is context aware and the other isn't.

Allow the user to chose the name of the macro. Simple as use_stylist!(css as stylist_css) or similar.

A similar effect can be achieved by #[styled_component(Comp, rename_css = styled)].
(not implemented at the moment, as I think it's not critical to include in the first round.)

No need to track yew-upstream for changes to the function_component macro to mirror

The current procedural macro accepts any valid function and passes it to the upstream function_component attribute.
I think it's unlikely that it's going to be changed to something other than a function.
In addition, a #[styled_component_base] attribute can be added to provide a usage in combination with #[function_component(Comp)] which means they can be made completely API neutral or use in combination with other libraries.

This is an ergonomic design that adds 0 lines of code over standard function_component.

My biggest concern: it starts getting unergonomic once another library adopts a similar design and wants to replace function_component, too. The two results don't compose and the user will have to chose between one or the other. I posit we aren't large enough to argue that our replacement is the one true one.

In my opinion, use_stylist!(css); is counter intuitive.
Despite I understand what the code above does, when seeing the code above, my mind tells me that it's invoking a function call taking a variable css instead of some kind of assignment.

Alternate syntax use_stylist!(use css); should be more intuitive in that regard.

A similar effect can be achieved by #[styled_component(Comp, rename_css = styled)].

Reading code written with the current styled_component introduces an accessible name, at all. I have not seen other macros I use do that, and it's discouraged with macro_rules!. Sorry that I can't find the relevant section from the rust guide that talks about this, but I don't think it's wise to introduce names the user never mentioned, no matter how big a warning is in the docs of styled_component. When you only see the code in a diff of a larger project, it can get confusing.

style! and global_style! do not support with_manager. This is by design.

Why? Both Style and GlobalStyle have a new_with_manager and should insert the style at the closest (shadow) DOM root. I don't see the design choice that they aren't context sensitive. style! and global_style! might as well be supported.

In fact, I think that using the "global" versions of the macros in any component makes that component less usable than it could be and can cause bugs downstream, but that's for another discussion.

My biggest concern: it starts getting unergonomic once another library adopts a similar design and wants to replace function_component, too.

You can combine the usage with the standard attribute (and other #[attrs]) with a similar attribute #[styled_component_base] (not implemented at this moment).
#[styled_component_base]
#[function_component(Comp)]
pub fn comp() -> Html {
    html! {

}
}

Reading code written with the current styled_component introduces an accessible name, at all. I have not seen other macros I use do that, and it's discouraged with macro_rules!. Sorry that I can't find the relevant section from the rust guide that talks about this, but I don't think it's wise to introduce names the user never mentioned, no matter how big a warning is in the docs of styled_component. When you only see the code in a diff of a larger project, it can get confusing.

During the initial design, I have considered to introduce an equivalent stylist::yew::css! macro with the __stylist_style_manager__ named __this_macro_is_only_available_inside_of_a_styled_component__. But ultimately deemed better to just include it for the end user so it's not possible to accidentally import the wrong one.
I don't think there's ultimately a difference of introducing a custom syntax inside of a macro and and adding an variable as the same is achievable with replacing all css! with ::stylist::yew:: __css_yew_impl manually.
However, I think if the variable leaves the macro's control, then it's bad.
fn func() {
    declare_a!();  // bad, and shouldn't be possible?
    println!("{}", a);
}

#[declare_a] // Should be fine as custom syntax is allowed in this context.
fn func() {
    println!("{}", a);
}

Why? Both Style and GlobalStyle have a new_with_manager and should insert the style at the closest (shadow) DOM root.

I see this question as an opportunity cost.
Why would user use style! and global_style! if css! and <Global /> is both more powerful and simpler to use?
I really cannot think of any reason one would prefer style! and global_style! if using stylist with Yew.

I forgot that Span::mixed_site() will achieve the same effect of isolating the variable from call site.
Will file an issue to improve this.

You can combine the usage with the standard function component attribute (and other #[attrs]) with a similar attribute #[styled_component_base] (not implemented at this moment).

I didn't know this could work. I'd actually prefer this way over the current implementation and repurpose this PR towards that. To make sure, #[styled_component_base] fn ... would work for any function, not just function_components, right? I can see the appeal of wanting to write helper functions to call from function components and use it there, too.

repurpose this PR towards that.

Could you please close this PR and open a separate one if use_ is dropped so the history is not as messy?

To make sure, #[styled_component_base] fn ... would work for any function

This is possible with any function but I am not sure about the evaluation order of multiple attributes.
I think it evaluates from top to bottom which is why I wrote
#[styled_component_base]
#[function_component(Comp)]
pub fn comp() -> Html {
    html! {

}
}


AdError 400: There was an error playing the video ad. Caused by: Error

Issue occurs randomly (~50/50) on Philips Android TV (Android 9, Chrome 119) where I'm running my web app in webview.
[INFO:CONSOLE(1)] "Ad error: AdError 400: There was an error playing the video ad. Caused by: Error: Error: There was an error playing the video ad."
[INFO:CONSOLE(1)] "VIDEOJS: adserror (Preroll)"
[INFO:CONSOLE(1)] "VIDEOJS: ADS: resumeAfterNoPreroll: attempting to resume playback (Preroll)"

player.src(source);

player.ready(function () {
    player.ima({
        adTagUrl: "https://pubads.g.doubleclick.net/gampad/ads?iu=/21775744923/external/single_preroll_skippable&sz=640x480&ciu_szs=300x250%2C728x90&gdfp_req=1&output=vast&unviewed_position_start=1&env=vp&impl=s&correlator=",
        disableAdControls: true,
        adLabel: "",
        showControlsForJSAds: false,
        contribAdsSettings: {
            debug: true,
        },
        debug: true
   });

   player.play();
}

"video.js": "^8.6.1",
"videojs-contrib-ads": "^7.3.2",
"videojs-ima": "^2.2.0",

Hello @Roz1c ,
Thank you for raising this issue. This plugin does not explicitly support connected TVs. Some features may work, but others may not. If you are able to reproduce the issue in a web environment, please add steps here, and I can take a look at a fix for the issue.
I would recommend not using this plugin, and following the IMA HTML5 getting started guide for a IMA integration that is more customizable for your specific platforms.
Please let me know if you have any additional questions.
Thank you,
Jackson
IMA SDK team


Issues with extends keyword.

When a template (say article.spf) extends another template (say base.spf), if the base template is alphabetically lower than the extended one, an error is thrown during dependency check.
Triggered by:
Environment('templates').load_dir()

Fixed in the commit 8c0c10. Might open later if further issues pertaining to this are discovered.


Add the option to send an array of data to RHQ.

At the point only single values are sent to RHQ. Delivery of array of values should be supported.

Resolution is contained in the commit https://github.com/panossot/jboss-automated-metrics/commit/512ac10a64abdbe34b172b09866385e5a6bc3bb5 .

Commit is included in the master branch. Closing the issue.


Topic: URL Constants

moves error reporting url into INTERNAL.py as constants, adds host param option to ASFSEssion auth_with_creds() and auth_with_token() methods

Codecov Report

Merging #201 (2b325af) into master (f0df348) will decrease coverage by 0.09%.
The diff coverage is 92.30%.

@@            Coverage Diff             @@
##           master     #201      +/-   ##
==========================================
- Coverage   89.58%   89.50%   -0.09%
==========================================
  Files          51       51
  Lines        1930     1934       +4
==========================================
+ Hits         1729     1731       +2
- Misses        201      203       +2

Flag
Coverage Δ

unittests
89.50% <92.30%> (-0.09%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

asf_search/ASFSearchOptions/validator_map.py
58.82% <ø> (ø)

asf_search/CMR/field_map.py
100.00% <ø> (ø)

asf_search/search/search.py
100.00% <ø> (ø)

asf_search/search/error_reporting.py
75.00% <66.66%> (-1.20%)
:arrow_down:

asf_search/search/search_generator.py
95.90% <91.66%> (-1.58%)
:arrow_down:

asf_search/ASFSession.py
84.00% <100.00%> (ø)

asf_search/CMR/MissionList.py
92.30% <100.00%> (ø)

asf_search/CMR/subquery.py
100.00% <100.00%> (ø)

asf_search/constants/INTERNAL.py
100.00% <100.00%> (ø)

asf_search/download/download.py
65.00% <100.00%> (ø)


Issue with POINTER_UP_OUTSIDE

Version: Phaser Version: 3.55.2
Browser: Windows Chrome 107
I'm running into an interesting problem, and I think I have it narrowed down to the cause, and it's possible that it's expected behavior. I have a game that is running on our website, the game runs inside of an iframe where the contents are on a different domain than the website. We use to have document.domain set, but have recently removed it as it is getting deprecated. I noticed that some of our games weren't working correctly if you were dragging something in the game, dragged your mouse of the game area, and then released. Generally what would happen is the item wouldn't get "dropped" and would continue to follow your mouse.
It seems like the mouseup event is not firing for the game when you release outside of the game. After a bit of diving into Phaser's code, it looks like the mouseup listener for when the mouse is released outside of the game was being down by doing window.top.addEventListener('mouseup') which obviously doesn't work without document domain setting, so it falls back to just using window.addEventListener. The relevant code is found here: https://github.com/photonstorm/phaser/blob/v3.55.2/src/input/mouse/MouseManager.js#L475
I created a simple setup that results in the problem:
const contentWrapper = document.getElementById('contentWrapper');
const canvas = document.createElement('canvas');
canvas.width = 1024;
canvas.height = 768;
contentWrapper.appendChild(canvas);
canvas.addEventListener('mousedown', () => console.log('mouse down on canvas'));
window.addEventListener('mouseup', () => console.info('mouse up on window'));

class Example extends Phaser.Scene {
  create () {
    this.input.on(Phaser.Input.Events.POINTER_UP_OUTSIDE, () => console.info('phaser pointer up outside'));
    this.input.on(Phaser.Input.Events.POINTER_UP, () => console.info('phaser pointer up'));

    this.add.text(this.scale.width / 2,this.scale.height / 2, 'This is a test Phaser game', { align: 'center', color: '#ffffff', fontSize: '32px', fontFamily: 'Arial' }).setOrigin(0.5);
  }
}

/** @type {Phaser.Types.Core.GameConfig} */
const config = {
  type: Phaser.WEBGL,
  width: 1024,
  height: 768,
  parent: 'contentWrapper',
  canvas,
  scale: {
    mode: Phaser.Scale.FIT,
    autoCenter: Phaser.Scale.CENTER_BOTH
  },
  scene: Example
};

const game = new Phaser.Game(config);

I noticed if I didn't create the Phaser game (comment out the last line of code), the canvas/window listeners work - you get the "mouse up on window" if you click inside of the canvas, and then release outside of the canvas. Once the Phaser game is created, that stops working.
After a bit more digging, I found that adding the following to the config fixes the issue: input:{mouse:{preventDefaultDown:false}}. The relevant code that this is used is here: https://github.com/photonstorm/phaser/blob/v3.55.2/src/input/mouse/MouseManager.js#L391. I am assuming that what is happening is the event gets its "prevent default" called, which prevents it from correctly firing on the window. I'm not 100% sure why turning off the down prevent default fixes it for the up event, but turning off the prevent default for up doesn't fix it. I would assume the reason why the window.top version works is because that has its own mouse up event that is fired, so it wouldn't have prevent default set on it.
Again, this might be expected behavior. I'm not sure what ramifications turning off preventDefaultDown would have, so I'm hesitant to do that. In the meantime I'm going to look at other solutions but maybe someone can shed some light on why this happens the way it does, and whether there might be a solution.
An additional note: POINTER_UP_OUTSIDE works correctly on our website on Windows Firefox, but doesn't work correctly on Windows Edge. Not sure about Mac browsers, and the structure of our website on mobile is different so it "works" on mobile but the page setup is different so I don't think the issue is relevant on there.
Final note: I noticed that Phaser 2.11.0 works. After diving through that code, it doesn't seem like they prevent default on any of the events - there's a way for that to be turned on, but it looks like it is off by default.

The solution I ended up going with is
  if (event instanceof MouseEvent) {
    this.input.manager.onMouseUp(event);
  }
});```
The one "gotcha" with this is the event listener for ending drag has to be "drag end" instead of "pointer up", because if the pointer isn't over the game object when the pointer goes outside of the game window, the pointer up event doesn't fire on the gameobject, but the drag end event does (which makes sense).

To fix this issue, you can try using the POINTER_UP event instead of the POINTER_UP_OUTSIDE event. The POINTER_UP event is triggered when a pointer is released, regardless of whether it was released inside or outside of the game canvas.
Here is an example of how you can use the POINTER_UP event in Phaser 3:
gameObject.on('pointerup', () => {
  // Pointer was released (inside or outside of the game canvas)
});

Alternatively, you can try setting the capture property of the InputPlugin to true to ensure that the POINTER_UP_OUTSIDE event is correctly triggered.
this.input.setCapture(true);

Based on the information you provided, it seems like the issue you are experiencing with your game is related to the mouseup event not firing when you release the mouse outside of the game area. It looks like the mouseup listener for when the mouse is released outside of the game was being set by doing window.top.addEventListener('mouseup') which obviously doesn't work without document domain setting, so it falls back to just using window.addEventListener.
To fix this issue, you can try adding the following to the config: input:{mouse:{preventDefaultDown:false}}. This should prevent the event from getting its "prevent default" called, which is likely causing it to not fire correctly on the window.
However, it's important to note that turning off preventDefaultDown might have other ramifications, so be sure to test your game thoroughly after making this change. It's also worth considering other solutions to this problem, such as changing the structure of your website or game to avoid the use of iframes, or using a different approach to handling mouse events.

After extensive testing, this does not seem to be an issue. The current version of Phaser no longer exhibits this problem.
We've made several improvements and fixes since the initial report, and it looks like this issue has been resolved.


RIghts statements are not checked against the list of available rights statements

There are regularly occurrences of digital objects that have rights statements that are not on the list of available rights statements. Right now there are a number of digital objects with the depreciated "out of Copyright - non commercial reuse" statement available on Europeana:

This should not happen, the value in edm:rights should be checked against the list of available rights statements to prevent digital objects with unsupported rights statements showing up in Europeana.

also the "less false" link in the screenshot above should be renamed

@ashmarriotteuropeana can you take a look at the 'less false' thing please.  The main issue in this thread is known and already on EF agenda through Hennings team.

@juliafallon I've raised this and it'll enter development on Tuesday.
Progress can be tracked here:
https://europeana.atlassian.net/browse/EC-2517


Question: running debug builds on xplat without logging?

I couldn't find the answer to this in the wiki or docs if it is there I'm sorry for missing it.
If I run a debug build of ChakraCore on macOS it produces a lot of logging that is rarely of use to me, below is a sample but one run of ch from a debug build with any script at all produces about 5 times this amount :
] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] SetSignalCount /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:563Expression: InternalGetCurrentThread() == m_pthrOwner
] ReleaseController /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:742Expression: InternalGetCurrentThread() == m_pthrOwner
] Release /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:100Expression: InternalGetCurrentThread() == m_pthrOwner
] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] Init /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:59Expression: InternalGetCurrentThread() == pthrCurrent
] CanThreadWaitWithoutBlocking /Users/snip/Documents/ChakraCore/pal/src/synchmgr/synchcontrollers.cpp:153Expression: InternalGetCurrentThread() == m_pthrOwner

Additionally if I run the test suite with a debug build it produces all of this logging - which causes every single test to fail as the logging is not in the baselines.
Please could someone tell me how to disable this so I can:

ensure any new code I've written doesn't hit asserts whilst passing tests in the test suite
use tracing or dump features without this noise
debug CC without this noise

Interestingly, debug builds of ChakraCore done with MSVC IIRC don’t produce all this logging (or any at all, even).  This suggests it is indeed possible to disable it, but unfortunately I don’t know how.

That debug logging is assertion failures. I think there is some bug with tracking current thread in the PAL.

This is related to #6404

@rhuanjl doe you have a stack trace for the assert by any chance?
I've tried pulling the offending file out, and of course it failed to link, but maybe there is a way to rewrite some of this as part of ChakraCore, rather than PAL.

@rhuanjl doe you have a stack trace for the assert by any chance?

These are PAL “asserte”s which check a condition then print that it failed if it did they don’t crash the programme or produce a stack trace. I tried digging into it further with break points but it got rather tricky.
It seems that on many occasions when CC calls into PAL’s thread manager it’s log of what the current thread should be is wrong which is what causes this.

Noted that these "asserte"s only fire in a shared or dynamic build, static builds don't have this issue.


Hope to use internal pkg

Why parser is in internal pkg?

Is there any way to use gql parser directly?

Could I copy internal pkg into my own project?

Is there any plan to change it?

@neelance

The project has a BSD licence, you can do what it allows you to do. I myself have no intention to open up the parser package because it would contradict the project goal "minimal API".

Thanks @neelance


New TeamManager

Currently TeamManager is able to create new students and teams, add contact information, and add safety tests, media consent forms, team dues, and medicals.

:+1: :shipit: :ship:


TouchAction.perform() The operation is ineffective

Code:
Duration duration = Duration.ofMillis(500);
TouchAction action1 = new TouchAction(driver).press(PointOption.point(startx, starty)).waitAction(WaitOptions.waitOptions(duration)).moveTo(PointOption.point(endx, endy)).release();
action1.perform();
The logs returned by the device：

The device's screen can slide, but there is no response after the action1.performang() operation
Why did this situation occur?

I guess your case was for https://github.com/appium/appium-uiautomator2-driver/blob/master/CHANGELOG.md#features-8
The endpoint has been deprecated. Please use w3c actions with latest Appium. If you're interested in how to actions work, https://github.com/appium/appium-uiautomator2-driver/blob/a3f32360bd6c53ffcaed820257d5d9d1f313707f/docs/actions.md will also helps then.


Add manual cluster joining and singleton actor system

Added manual cluster joining instead of cluster bootstrap
Added singleton actor system which is used for kubernetes hostname and shared between multiple engines
Fixed signal bus component registration for multiple engines

Codecov Report

Merging #200 (b672fa0) into main (bd297c3) will decrease coverage by 1.54%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main     #200      +/-   ##
==========================================
- Coverage   60.66%   59.12%   -1.55%
==========================================
  Files         158      158
  Lines        3259     3273      +14
  Branches      101      100       -1
==========================================
- Hits         1977     1935      -42
- Misses       1282     1338      +56

Impacted Files
Coverage Δ

...surge/internal/core/ActorSystemBindingHelper.scala
0.00% <0.00%> (ø)

...a/surge/internal/domain/SurgeMessagePipeline.scala
54.11% <ø> (-19.14%)
:arrow_down:

.../kafka/KafkaClusterShardingRebalanceListener.scala
0.00% <0.00%> (ø)

...ain/scala/surge/javadsl/command/SurgeCommand.scala
0.00% <0.00%> (ø)

...rc/main/scala/surge/javadsl/event/SurgeEvent.scala
0.00% <0.00%> (ø)

...in/scala/surge/scaladsl/command/SurgeCommand.scala
30.76% <0.00%> (+2.19%)
:arrow_up:

...c/main/scala/surge/scaladsl/event/SurgeEvent.scala
0.00% <0.00%> (ø)

.../main/scala/surge/health/domain/HealthSignal.scala
0.00% <0.00%> (-66.67%)
:arrow_down:

...afka/streams/AggregateStateStoreKafkaStreams.scala
61.22% <0.00%> (-4.09%)
:arrow_down:

... and 8 more

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 bd297c3...b672fa0. Read the comment docs.

I've tested the surge-sample with multiple engines. It is working fine with the current akka remoting implementation.
https://github.com/UltimateSoftware/surge-samples/pull/15
However, there are issues when using akka cluster implementation with multiple engines(no issues with single engine). As I've made changes to use the shared actor system as in surge-ukg(seems valid to me), we are facing cluster sharding issues.
I can save the logic of creating an actor system per engine, but won't it be too costly?


[dbus] Use port libsystemd

Fix installation order dependency and linking WRT port libsystemd. Fixes https://github.com/microsoft/vcpkg/pull/35129.
NB: Port libsystemd is linux-only. Port dbus always builds shared libs.

@FrankXie05 Ready. And needed.


Error when load sentinel on Python 3.4

When try to load sentinel in python3.4, I have the error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/site-packages/flask/exthook.py", line 81, in load_module
    reraise(exc_type, exc_value, tb.tb_next)
  File "/usr/local/lib/python3.4/site-packages/flask/_compat.py", line 32, in reraise
    raise value.with_traceback(tb)
  File "/usr/local/lib/python3.4/site-packages/flask_sentinel/__init__.py", line 1, in <module>
    from flask_sentinel import ResourceOwnerPasswordCredentials, oauth  # noqa
ImportError: cannot import name 'ResourceOwnerPasswordCredentials'

Hello, that should be fixed on the development branch (see https://github.com/nicolaiarocci/flask-sentinel/commit/a90b7377242672701b8160ba826f111bba18714b). Could you please try again with v0.4-dev and see if it's solved for you? Thanks!


[Feature Request] Add Validity Period or Schedules for Rules

Request to add a Validity Period or a Scheduling Mechanism for Rules to be enabled or disabled based on that schedule.
May be useful to integrate with Issue #199
Currently, there is no simple way of enabling or disabling a Rule based on Dates/Times/Schedules. Certain functions could be triggered using Timers based on Cron expressions etc., however, you may not necessarily want an operation to trigger, you just want to check a Condition during a certain period.
Examples:

Enable a Rule after Sunset and before Sunrise: Trigger a light to come on only when it is dark outside
Enable a Rule between Hours of 5PM and 7AM Monday through Friday: Ability to arm a door during non-working hours.
Disable/Enable a Rule on specific calendar dates: Send a notification or reminder of Daylight Savings
Set an Expiration Date or Time for a Rule: If you go on vacation set an alarm if doors are tripped but let the rule expire on your anticipated return.
Many More...

This functionality should be in addition to the current Condition evaluation being performed by the Rule.

It will be a nice feature!


JavaScript module support

We currently don't bundle JavaScript, only inline it. We'll need to support bundling script for modules.

[ ] Add support for modules to Analyzer.

Full module support is tracked here: https://github.com/Polymer/polymer-analyzer/issues/731
Import support was added in https://github.com/Polymer/polymer-analyzer/pull/732 and https://github.com/Polymer/polymer-analyzer/pull/733
Dynamic import support is tracked here: https://github.com/Polymer/polymer-analyzer/issues/740

[ ] Track JavaScript files in the bundle manifest
[ ] Generate lists of JS files to bundle.
[ ] Generate bundles - whether we write new code to do this or delegate to Rollup is TBD. We're going to experiment with Rollup first.
[ ] Rewrite references to bundled files.

I believe a lot of the Angular community was using Rollup, but standardized on Webpack as implemented in the Angular CLI.
Examples of bundling polymer 3 with webpack:

https://github.com/chybie/poly-mini-game
https://github.com/pferretti/polymer3-typescript

Is there any documentation available for bundling a Polymer 3 app for Firefox/Edge?

@craftyc0der I work on a project that currently uses Webpack bundle Polymer 3. Not much for documentation but it's an example. Unfortunately it's also not the cleanest example as we are Webpack n00bs.

FYI, we're using Rollup in the Bundler. The PRs are being reviewed now. We'll have documentation soon.

This is in master now.


Add superscript in publisher summary table for 90th percentile difference

Codecov Report

Merging #145 into master will decrease coverage by <.01%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master     #145      +/-   ##
==========================================
- Coverage   68.25%   68.25%   -0.01%
==========================================
  Files          44       44
  Lines        3824     3830       +6
  Branches      662      664       +2
==========================================
+ Hits         2610     2614       +4
- Misses        974      975       +1
- Partials      240      241       +1

Impacted Files
Coverage Δ

...on/plugins/performance/reports/AbstractReport.java
35.29% <ø> (ø)
:arrow_up:

...plugins/performance/reports/PerformanceReport.java
85.85% <100%> (+0.21%)
:arrow_up:

.../hudson/plugins/performance/reports/UriReport.java
69.89% <33.33%> (-0.6%)
:arrow_down:

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 58695ad...006fe84. Read the comment docs.


[Android Pie] Crashed when onReceive fired

Description:

My App crashed when received background notification. It resulted this error message:
java.lang.NoSuchMethodError: No static method zzc(Landroid/content/Context;)Lcom/google/firebase/iid/zzaa; in class Lcom/google/firebase/iid/zzaa; or its super classes (declaration of 'com.google.firebase.iid.zzaa' appears in base.apk)
	at com.google.firebase.messaging.FirebaseMessagingService.zzd(Unknown Source:29)
	at com.google.firebase.iid.zzg.run(Unknown Source:26)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at com.google.android.gms.common.util.concurrent.zza.run(Unknown Source:7)
	at java.lang.Thread.run(Thread.java:764)

You can look my app/build.gradle in this link https://pastebin.com/kq7D6amV
I realized, this error only showed on Android Pie (Google Pixel 1). When I tried on other phone using prior version, it work normally.
Environment

What version of the OneSignal React-Native SDK are you using?
react-native-onesignal": "^3.2.6

How did you add the SDK to your project (eg. npm)
npm install react-native-onesignal@latest

Android Version:
Android Pie 9.0

Steps to Reproduce Issue:

run npm install -- save react-native-onesignal@latest
implement
OneSignal.addEventListener('received', (notification)=>{console.log(notification)}
Send messages without title, but insert some background data
Crashed

On my app logcat, it still be able to print the log (notification), shortly after that, my app crashed. Sometimes, the crash error messages printed before the log, but sometimes, it printed after the log.

@abdullahizzuddiin I cannot reproduce this issue on our own Android 9 devices. Also, I can no longer see your app/build.gradle, have you added our gradle plugin?
If not, please try adding this to the very top of your app/build.gradle and let me know if the issue still occurs:
buildscript {
    repositories {
        maven { url 'https://plugins.gradle.org/m2/'}
    }
    dependencies {
        classpath 'gradle.plugin.com.onesignal:onesignal-gradle-plugin:[0.11.0, 0.99.99]'
    }
}
apply plugin: 'com.onesignal.androidsdk.onesignal-gradle-plugin'

repositories {
    jcenter()
    maven { url 'https://maven.google.com' }
}

@abdullahizzuddiin Would you also please post your package.json?

I also experienced the same issue. I solved it by upgrading com.google.gms:google-services from 4.0.1 to  4.1.0.

@abdullahizzuddiin can you post your app/build.gradle and give @anjar10’s suggestion a shot?

Closing due to no response, if you're still having this problem please post and I'll be happy to reopen and help investigate

I also experienced the same issue. I solved it by upgrading com.google.gms:google-services from 4.0.1 to 4.1.0.

@anjar10 : Can you  please elaborate the fix? Did you change in the build.gradle file? Would you mind pasting your file here?

I just upgrade google service in build.gradle file which located in <PROJECT_ROOT>\build.gradle. Here is my build.gradle file:
...
buildscript {
    repositories {
        jcenter()
        google()
        maven { url "https://jitpack.io" }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.2'
        classpath 'com.google.gms:google-services:4.1.0'
    }
}
...


secrets fix

Current dependencies on/for this PR:

main

PR #23   👈

This comment was auto-generated by Graphite.


Pretty broken on mozilla-central by now

Disabling annotations doesn't work, disabling autoplay doesn't work. At least setting quality still works.

So. You just decided to close it without reason or explanation.

Because it is in a essence duplicate of at least #2293 and #2324 something that would have been trivial to find out and since you are a long time user of this issue tracker you should know how to do so.
This is the last time I explain myself to you since you have failed to do your due diligence several times (checking for duplicates) when opening new issues and your behavior has been problematic even before that.
I don't like wasting my time so that is why I closed your last two opened issues. This one shouldn't even have deserved any kind of reply since it is just a rant in form of an issue report.

Neither of those are about disabling annotations or autoplay. Much less named as such.
How do you imagine one finding such "duplicates"?
Just a hint: Decent people close duplicates with a note of the duped issue.

Decent people also create one issue per you know, issue. Yours is mostly a rant of how the addon is completely broken. We already have one of those open issues with more insight like this one #2324. It's not as old as yours, but it clears up some things and is the first issue on the open issues page.
There is no reason to close an issue with reference to other issues when it is clearly faulty and has no worth since that creates reference clutter.
But since I'm a nice guy I'll humor you this time (won't link directly, but you should figure out how to open them).
Here is at least one for annotation: 2278
And here is one for the auto-play: 1869
And if you had actually searched, you'd find that both issues have several reports.
You're welcome.

Those are too old to be relevant. (especially the older one) Anyway, I give up. It's pointless dealing with you if yeppha's not around.

Incorrect. The oldest one which still applies is always the most relevant one. It's a shame you do not know this considering you seem fit to school me about how issue trackers work.
From now on, expect no replies when you try to call me out in the future since as was proven I'm more suited for this than you are.

(Since it both broke some weeks before, I doubt that you're right.)


getting issue while using accessing google drive listing in ios. working fine in android

Hii firstly, thnx for the plugin.  I tried the setting you recommeded in the docs

but still i am getting the preflight error. can anyone please help.. any setting need to be done any thing.. would be really helpful
thank you in advance

The call for loading the google client

Might be related, not sure what are the supported schemas on google, with file:// used to work just fine, but that is not an option using this plugin

if they don't accept ionic scheme, there is nothing we can do about it, sorry


release: 0.9.0

Prepare 0.9.0 release PRs.
This includes cleaning release news items:

Check CHANGES.rst against git log 0.8.0.. to see whether we did not miss any important change.
Clean the verbiage of news items in CHANGES.rst to make it user-centric and understandable outside of any context.
Use the usual Added/changed/fixed style for new features, improved features, and bug fixes.

Test integration on many examples before merging and pushing images:

[x] Kubernetes (reana-dev run-example -c DEMO -b kubernetes --submit-only)

Test HTCondor compute backends again:

[x] HTCondor (reana-dev run-example -c DEMO -b htcondorcern --submit-only)

Test VOMS proxy and Rucio support:

[ ] VOMS proxy
[ ] Rucio

Test three launch examples:

[x] /launch

Shared components:

[x] pytest-reana https://github.com/reanahub/pytest-reana/pull/105/
[x] reana-db https://github.com/reanahub/reana-db/pull/192
[x] reana-commons https://github.com/reanahub/reana-commons/pull/384

Cluster components:

[x] reana-job-controller reanahub/reana-job-controller#379
[x] reana-message-broker https://github.com/reanahub/reana-message-broker/pull/49
[x] reana-server https://github.com/reanahub/reana-server/pull/570
[x] reana-ui https://github.com/reanahub/reana-ui/pull/307
[x] reana-workflow-controller https://github.com/reanahub/reana-workflow-controller/pull/491
[x] reana-workflow-engine-cwl https://github.com/reanahub/reana-workflow-engine-cwl/pull/236
[x] reana-workflow-engine-serial https://github.com/reanahub/reana-workflow-engine-serial/pull/173
[x] reana-workflow-engine-snakemake https://github.com/reanahub/reana-workflow-engine-snakemake/pull/53
[x] reana-workflow-engine-yadage https://github.com/reanahub/reana-workflow-engine-yadage/pull/237

Client components:

[x] reana-client https://github.com/reanahub/reana-client/pull/648

Helm chart:

[x] reana https://github.com/reanahub/reana/pull/690
[x] test researcher-oriented helm installation method.

Docs:

[x] www.reana.io update (next branch)
[x] docs.reana.io update (next branch)

All done and working


Update html5.rb forwarding params syntax

hackday 🙂
What problem is this PR intended to solve?
#3323
Have you included adequate test coverage?
No test changes
Does this change affect the behavior of either the C or the Java implementations?
No

Thanks for your patience. The last couple of weeks have been really busy, but I'm hoping to review and merge this in the next week or so!


add additional debug logs for mysql charset

I'm thinking issue #603 stems from (source):

If you specify a character set that the client recognizes but the server does not, the server falls back to its default character set and collation.

I'd like to verify that by adding this logging.

actually I don't think this is the issue.


tests: logging: test case log_msg2.logging.log_msg2_64b_timestamp failed on qemu_cortex_a9

Describe the bug
The logging test:  tests/subsys/logging/log_msg2/logging.log_msg2_64b_timestamp failed after this commit:
99b7e9d8603f42f5ed8a8691711ba77416a3238b  boards: arm: qemu_cortex_a9: change board's timing parameters
Please also mention any information which could help others to understand
the problem you're facing:

What target platform are you using?
qemu_cortex_a9
What have you tried to diagnose or workaround this issue?
without CONFIG_LOG_TIMESTAMP_64BIT=y, the test case will pass.

To Reproduce
Steps to reproduce the behavior:

source zephyr-env.sh
twister -T tests/subsys/logging/log_msg2/ -p qemu_cortex_a9
or
west build tests/subsys/logging/log_msg2/ -b qemu_cortex_a9 -p always -t run -DCONFIG_LOG_TIMESTAMP_64BIT=y
See error

Expected behavior
A clear and concise description of what you expected to happen.
Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
Logs and console output
twister output:
mm@mm-NUC8i7BEH:~/zephyrproject/zephyr$ twister -T tests/subsys/logging/log_msg2/ -p qemu_cortex_a9
Renaming output directory to /home/mm/zephyrproject/zephyr/twister-out.13
INFO    - Zephyr version: v2.7.99-1413-g99b7e9d8603f
INFO    - JOBS: 12
INFO    - Using 'zephyr' toolchain.
INFO    - Building initial testcase list...
INFO    - 5 test scenarios (5 configurations) selected, 0 configurations discarded due to filters.
INFO    - Adding tasks to the queue...
INFO    - Added initial list of jobs to queue
INFO    - Total complete:    3/   5  60%  skipped:    0, failed:    0
ERROR   - qemu_cortex_a9            tests/subsys/logging/log_msg2/logging.log_msg2_64b_timestamp FAILED: Failed
ERROR   - see: /home/mm/zephyrproject/zephyr/twister-out/qemu_cortex_a9/tests/subsys/logging/log_msg2/logging.log_msg2_64b_timestamp/handler.log
INFO    - Total complete:    4/   5  80%  skipped:    0, failed:    1
ERROR   - qemu_cortex_a9            tests/subsys/logging/log_msg2/logging.log_msg2_fp_64b_timestamp FAILED: Failed
ERROR   - see: /home/mm/zephyrproject/zephyr/twister-out/qemu_cortex_a9/tests/subsys/logging/log_msg2/logging.log_msg2_fp_64b_timestamp/handler.log
INFO    - Total complete:    5/   5  100%  skipped:    0, failed:    2
INFO    - 3 of 5 test configurations passed (60.00%), 2 failed, 0 skipped with 0 warnings in 7.37 seconds
INFO    - In total 50 test cases were executed, 0 skipped on 1 out of total 406 platforms (0.25%)
INFO    - 5 test configurations executed on platforms, 0 test configurations were only built.
INFO    - Saving reports...
INFO    - Writing xunit report /home/mm/zephyrproject/zephyr/twister-out/twister.xml...
INFO    - Writing xunit report /home/mm/zephyrproject/zephyr/twister-out/twister_report.xml...
INFO    - Run completed

and the content of the handler.log:
Running test suite test_log_msg2
===================================================================
START - test_log_msg2_0_args_msg
.
.
.
===================================================================
START - test_mode_size_plain_str_data
 PASS - test_mode_size_plain_str_data in 0.1 seconds
===================================================================
START - test_mode_size_str_with_2strings

    Assertion failed at WEST_TOPDIR/zephyr/tests/subsys/logging/log_msg2/src/main.c:343: get_msg_validate_length: (len not equal to exp_len)
Unexpected message length 16 (exp:8)
 FAIL - test_mode_size_str_with_2strings in 0.1 seconds
===================================================================
START - test_saturate
 PASS - test_saturate in 0.1 seconds
===================================================================
Test suite test_log_msg2 failed.
===================================================================
PROJECT EXECUTION FAILED

Environment (please complete the following information):

OS: Linux,
Toolchain Zephyr SDK, 0.13.1
Commit SHA or Version used: 99b7e9d8603f42f5ed8a8691711ba77416a3238b

Additional context

It's related (or deplicate) to #39978

@nordic-krch got it, close it, thanks!


Demonstration of a unified Onramp

With this change the user sees a single Onramp button and the wallet code decides whether to process it using the Fast or Slow mechanisms. In this example, any request for less than 1/2 of the present oETH balance on the L2 side will be processed as a Fast swap. Larger requests will be sent through the direct (Slow) path. Other factors could be considered as well, e.g. only using a Fast swap if the L2 liquidity balance was greater than on the L1 side.
Instead of making the decision here, it would also be possible to send all of the L1->L2 requests to a smart contract and have that contract make the decision about which channel to use. This would have a higher L1 gas cost, but there might be advantages e.g. avoiding race conditions where multiple users generate Fast swap requests at the same time and thereby exhaust the L2 oETH balance.
This patch does not do anything regarding fees. In the real world the fee paid by the user should be the same regardless of which path our code chooses. The fee for L1->L2 swaps should probably be 0, with a user only paying for using the pool in the L2->L1 exit direction. However an L1->L2 fee might also be acceptable to users if we can provide a convincing explanation for why it's there.
Changes to be committed:
modified:   packages/omgx/wallet/wallet/src/containers/account/Account.js
modified:   packages/omgx/wallet/wallet/src/containers/modals/deposit/steps/InputStep.js

Codecov Report

Merging #94 (56e649f) into fast-relayer-wallet (90721c0) will increase coverage by 0.12%.
The diff coverage is n/a.

:exclamation: Current head 56e649f differs from pull request most recent head 3e346da. Consider uploading reports for the commit 3e346da to get more accurate results

@@                   Coverage Diff                   @@
##           fast-relayer-wallet      #94      +/-   ##
=======================================================
+ Coverage                82.14%   82.26%   +0.12%
=======================================================
  Files                       49       49
  Lines                     1904     1900       -4
  Branches                   304      303       -1
=======================================================
- Hits                      1564     1563       -1
+ Misses                     340      337       -3

Impacted Files
Coverage Δ

...VM/bridge/messaging/OVM_L1CrossDomainMessenger.sol
98.11% <ø> (+5.13%)
:arrow_up:

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 41a9a3c...3e346da. Read the comment docs.

I'm closing this as it's obsolete and was not intended to be merged, only to provide an example for discussion purposes.


Align functions sometimes don't move things to appropriate quadrant

If I set the layout size to 1000,1000, call autolayout, then align some element (i.e. 'alignTop'), sometimes the position of those elements is not in the appropriate swath of the layout:  when I call 'alignTop', for example, nine times out of 10, the Y value is 30, and often it's in the 30's to 200's.  But sometimes it's close to the middle, like '432'.  I think that's too far off to really say that's at the 'top' of the layout; it's more like the hCenter.
One time, I got 'nan' values, which is also not ideal, but I don't know how to reliably get that to repeat.

'alginTop' function calculates the min of the 'y' values of the selected items and set the 'y' values of all the items to that one. So, I wouldn't be surprised if you occasionally get something near to the center due to the randomness of the autolayout. In my test, I compare all the 'y' values to the min value after calling 'alignTop'

I think this behavior is not what people would expect.  I think think if you're aligning elements to 'the top', people think of 'the top' as 'the top of the page' not 'the top of the cluster of elements that I don't know where they are'.
That said, it's possible that people might want your behavior in some conditions.  Maybe a 'relative=true/false' argument to the functions?
(for version 2; I think the current state of things is probably fine for now.)

Great. We will implement it in the version 0.2.


Redundant "Getting Started" tutorials in several reference files

The same process to Getting Started with the repo has been described in

README.md - a bit short though
Adding examples.md - a bit long
i18n contribution.md - the most verbose, and very beginner friendly.

Moreover, the file structure contained in the i18n file is pretty much a duplicate of the one in README. I would suggest:

moving the "Getting Started" parts in i18n file to its own separate file, and linking to it from all the three other files.
Deleting the section on file structure from i18n, and linking to the one in README in it.

Thoughts? I am happy to work on this if approved.

@GaurangTandon Sure go ahead.

@GaurangTandon since the steps are just a few, I think it might be easier for beginners if we just replicate these across files consistently so they don't have to click through multiple links to get started.

@lmccart I understand, but, it adds redundancy which makes maintainability harder. Also, since these steps are only taken once for the repo, if the person has already forked and cloned the repo for i18n work, they would still have the repo ready adding examples or any other work :) So, they won't need to click multiple links anyway.

@GaurangTandon ok I see your point. 👍 I would say please go ahead and make the change. @limzykenneth do you have thoughts here?

I think it's good to consolidate initial setup stuff in one place but for "initial setup" I'm thinking more just mentioning cloning the repo, npm install then grunt server to build the site and run it (which will be in README.md).
Any additional steps, even if they are required once only, for creating examples or i18n work etc should be isolated into their own file, that includes explaining file structures, as i18n and examples uses different file structures and different build steps (assemble vs just copying) so there's not need to know both to do one of them.
In principle I would like to see that the initial barrier to entry be as minimal as possible so to keep the information in README.md sparse but enough to build the website, then if someone wants to work on a specific task just read the guide for that type of task.


HashedElGamal: Compatibility with the reference implementation

Manually transferred.

Dependent issue: https://github.com/microsoft/electionguard-python/issues/646
Depending on what they do or don't fix, we might need to:

Ensure that we're always serializing integers to 32-bits
Remove the 0x00 from the KDF computation
Encode HMAC keys in hex bytes (hopefully not!)

We should also double-check that they are correctly handling inputs that aren't multiples of 32 bytes long.

Short term: we're not using HashedElGamal and not supporting features that require it (encoding overvotes & write-ins).
In the fall, when ElectionGuard gets past the 1.0x versions in to 2.0, we'll bring this back.

So in the meantime what should we do about the numBytes field? It causes issues with my compatibility tests, particularly in terms of deserializing and re-serializing the sample data. electionguard-python's padding approach has issues like you described earlier. I saw that electionguard-cpp just errors on plaintexts and ciphertexts whose length isn't a multiple of the block size. Should I implement something of that sort and adjust the tests accordingly?

Hmm. It really bugs me when we have a "correct" implementation and we have to introduce bugs.
I suggest we introduce a HashedElGamalCompat structure of some kind, which is just an empty shell of a data structure. We can serialize and deserialize, but it has no actual code attached. Since we're not actually using it, we don't care about it yet.


pir: parsing accuracy

Changes

This change allows each field to be processed by separate extractors.
I've reduced the amount of places where types were sometimes strings, and sometimes
Addresses are now represented everywhere as just city/state pairs

We also exclude addresses where the state is not in a valid format
This makes matching simpler and removes most of the code related to addresses

We now do a better job of handling duplicates

New

We now remove common suffixes/prefixes from strings before passing to extractors

This makes our declarative format less flaky and the list is small/focussed

Extractors
Using Typescript to describe the new extractors is easier that the JSDoc
interface ExtractorParams {
  afterText?: string
  beforeText?: string
}

interface Extractor<JsonValue> {
  extract(strings: string[], params: ExtractorParams): JsonValue
}

/**
 * Example extractor - note how the type param `JsonValue` is filled
 * in by the implementor.
 */
const myNewExtractor: Extractor<string[]> = {
  extract: function (strings: string[], params: ExtractorParams): string[] {
    throw new Error("Function not implemented.")
  }
}

#933  👈
main

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

Join @shakyShane and the rest of your teammates on  Graphite

@brianhall please take a look at these changes - in particular to understand the changes I recommend looking at the new tests and the ones that were altered. Every change made here is represented in those tests one way or another


Policy based routing

Now that swap_vid is supported as an output action, and we have inter VLAN routing, we should have policy based routing now (remains to write a test that has multiple RIBs with same destination and ACL can select which RIB).

https://github.com/anarkiwi/faucet/commit/dda45dfee7a4420413d52a402b2d0d24e813e861


Hover Events not showing in the correct location

When i try to read a hover event it doesn't show up where it should be it instead shows up down further idk if this is because of the chat scale or what not but its be great if it were fixed :)

Can you post some screenshots comparing it to the vanilla behavior?

sure

TabbyChat^

Vanilla^

my mouse doesn't show but in vanilla i can point directly at the name and in the TabbyChat i have to move it down further

Are you using the latest version?

i got it from the liteloader website.

But what version? What's the file name?

2.3.0-beta-296

Update to 2.3.1-mc1.12.1 and report back.

oh im using it for 1.12

So test it on 1.12.1.

ok

yes it still does the same thing

It seems to work for me. Are you able to build the current source and test using that?

yea i can

and if its because of this i am using this with optifine

i will do this tomorrow after school thanks for the help ill let you know if it works or not

Be sure to try without optifine as well.

ok
actally ill do it now.

 You can wait until after you do it so you can post the results at the same time.

ok

Yes it works fine in 1.12.1 after building it from github

I'll be backporting to 1.11 at some point, but not 1.12.

fine, ill just port it up to 1.12 then... or at least try to...


feat: change around the x and y in editor

fixes #587

:tada: This PR is included in version 2.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[feature] add the config of containUppercase

ref:
https://github.com/namics/stylelint-bem-namics/issues/6

Sorry for closing - see #6 for details


Test: All links must have a "title" attribute

I do not think this is correct. The "title" is supposed to provide additional / advisory information (expand on the meaning of the link). Do not add link titles to all links: if it is obvious from the link anchor and its surrounding context where the link will lead, then a link title will reduce usability by being one more thing users have to look at. •don’t duplicate it with link text (this hurts usability: for example some blind users will hear the same text twice);
•don’t put too much weight on the title attributes as not all screen readers may render it (make sure either surrounding text or anchor text explains the link at least the first time you use it).

Yes, I agree. This test needs to be refactored, possibly even removed.


error running the package

hi
i want to use this package to validate my md files..i was trying to run the index.test.js in test folder to get the understanding about this...but i am getting a error
`describe('skeemas-markdown-validation plugin', function() {
^
ReferenceError: describe is not defined
at Object. (.....\tests\index.test.js:7:1)
at Module._compile (internal/modules/cjs/loader.js:956:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
at Module.load (internal/modules/cjs/loader.js:812:32)
at Function.Module._load (internal/modules/cjs/loader.js:724:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1025:10)
at internal/main/run_main_module.js:17:11`
is there any node package i missing to install..or any other error..please help me
thanks

You need to have a test framework that adds a describe method or you need to drop the outer describe call. Have a look at mocha or jest if you are looking for a testing framework.

@Prestaul thank you very much..i found it myself....anyway thanks for update


[build] Configure osx-aarch64  binaries

GitHub just enabled osx arm64 runners.
https://github.com/mthmulders/mcs
cc: @mthmulders

In fact, I use a self-hosted runner that I spin up whenever I need it. Works good enough for me...

Thanks. Sadly this wont't work all the time for out use case 😢

Already done a couple of releases ago.


Adjust memory bounds on ResourceProfiler plot

Now lower bound of memory axis is the minimum value, instead of 0. Fixes #840.

@koverholt, does this satisfy your needs? I'd rather adjust the bounds for the plot, than the actual numbers, as it's very difficult to determine what the memory usage of the process is actually from (python overhead, etc...).

@koverholt  gave this a +1 in offline conversation. Merging.

This is great, thanks for the fix. I'm loving the profiling plots.


Editing Modal

Will this be a modal or a screen that will be navigated to after putting in edited information for curriculum?
This code will probably be reused with create curriculum

Editing/Add curriculum is now a list


Support per component logging configuration

It would be nice to support per component log levels (e.g. like istio) so a user can target debug to specific areas of interest.
Also, a log format that contains the component would be more informative when reading/debugging the logs

@ttschampel Part of this issue is solved but I don't think it has been fully rolled out yet. We are currently create a new child logger with the namespace name of the service. Maybe namespace should be changed to something else because we use that for policy as well.
https://github.com/opentdf/platform/blob/main/service/pkg/server/services.go#L137
cc: @pbacon-blaber


Add pool DB operation removeRetiredPools

Context
As part of the work to perform garbage collection of retired pools from the database, we need to be able to conveniently and safely remove retired pools.
Decision
Create a pool database operation removeRetiredPools:
removeRetiredPools
    :: EpochNo
    -> stm [PoolId]
    -- ^ Remove all pools with an active retirement epoch that is
    -- earlier than or equal to the specified epoch.

This operation reuses the existing listRetiredPools and removePools operations.
Acceptance Criteria

[x] The pool DB must provide a removeRetiredPools operation.
[x] The removeRetiredPools operation must remove each pool atomically.
[x] The removeRetiredPools operation must write an entry to the log before removing a pool.

Development

#2047

QA
Property test:

https://github.com/input-output-hk/cardano-wallet/pull/2078

This operation reuses the existing listRetiredPools and removePools operations. The tests for these operations are described in the following tasks:

#2016
#2017

lgtm


Update pulumi-terraform-bridge to v3.23.0

Also update pulumi sdk to  v3.32.1
Update tf-plugin SDK to latest commit on master

@guineveresaenger Ideally, the replace for terraform-plugin-sdk should be set to upstream-vSOMETHING where SOMETHING is the version referenced upstream. This isn't always needed, but it gives the best chance of the provider functioning correctly. It gets tricky because the bridge references terraform-plugin-sdk, but the upstream provider does as well. (In this case 2.5.0, which is pretty old at this point.)

Removed the test to unblock


MSID: 87135 Version: 2 DOI: 2<IP_ADDRESS>9958

[PLACE MANUSCRIPT AND EDITOR DETAILS HERE WHEN AVAILABLE] See step 3
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v1/by-publisher/elife/get-by-manuscript-id?manuscript_id=87135)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/87135/v2)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>9958)
[ ] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/87135/v2/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/87135)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/87135

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/87135

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/87135/v2/87135-v2.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/87135)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

Numerous references simply broken, where the information is duplicated:

Fix in https://github.com/elifesciences/enhanced-preprints-biorxiv-xslt/pull/77

References generally looking better now.


Unix socket binding

Is your feature request related to a problem? Please describe.
My deployment architecture allows me to map Git branches to deployment environments. Such environments are created automatically, many residing on the same server. Each of those environments needs one instance of each component (web server, database, and in this case tusd).
In order to multiplex the access to those services, most of the time using a different HTTP Host is sufficient. This is done by a nginx reverse proxy on each server that handles the different name-based virtual hosts, the HTTPS and various details.
If all my services used TCP ports, I would have to do a lot of book keeping to know which service uses which port. In this case, if I have to bind tusd to a TCP port, I have to keep track of all the TCP ports it's being bound to in relation to which Git branch and this which vhost.
Describe the solution you'd like
What I do is bind my services to Unix sockets. This way I can bind sockets to predictable locations based on the project and branch name, like /run/{project}/{component}/{branch}.sock.
I'm thinking about a new tusd option which would be -unix-sock and would signify to discard -host and -port while binding to the specified path.
Describe alternatives you've considered
Other options for me would include

A port/project/service book keeper
A wrapper around the binary to redirect a Unix socket to the TCP port (using a different netns or something like that)

But they seem largely overkill in comparison to an implementation that should be a 15-lines diff.
Can you provide help with implementing this feature?
I'm in an exploratory stage for my project (which should conclude within hours, very tight deadline). If I need so (80% chances) then I'll implement it myself and make a PR, unless someone does it before the next 3 hours (which I certainly don't expect). Then I'll happily implement the tests, documentation or any other requirements the project might have. Unless the feature doesn't interest you of course.

Fixed with pull request actually


Support token binding for public client apps

For details, see https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1597946/?triage=true.

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'IoT:0.10892465,App Services:0.06740505,Cosmos:0.060353283'


[maven-publish]: Error when running the generateMetadataFileFor*Publication task

Current Behavior
An error occurs when running the generateMetadataFileFor*Publication task:

* What went wrong:
   Execution failed for task ':publish-problem-spring-boot-autoconfigure:generateMetadataFileForStarterPublication'.
   > Invalid publication 'starter':
   - Publication only contains dependencies and/or constraints without a version. You need to add minimal version information, publish resolved versions (For more on this, please refer to https://docs.gradle.org/8.6/userguide/publishing_maven.html#publishing_maven:resolved_dependencies in the Gradle documentation.) or reference a platform (For more platforms, please refer to https://docs.gradle.org/8.6/userguide/platforms.html in the Gradle documentation.)

full stacktrace: https://gist.github.com/morohon/555b4d093733e088eda0d707d60751bf
Expected Behavior
Executing the generateMetadataFileFor*Publication task does not produce an error.
maven-publish uses the dependency versions provided by the spring dependency management plugin.
Context (optional)
A very similar issue was previously raised in this issue: https://github.com/gradle/gradle/issues/27789 and was closed.
In the comment there is a request to re-open
Steps to Reproduce

Clone the repository:

git clone git@github.com:morohon/publish-problem-spring-boot-starter.git

Go to the main branch:

git checkout main

Run the command:

./gradlew publish-problem-spring-boot-autoconfigure:clean publish-problem-spring-boot-autoconfigure:generateMetadataFileForStarterPublication

See an error in the logs

Important note:
The project builds successfully and does not cause an error. That is, if you execute the command:
./gradlew publish-problem-spring-boot-autoconfigure:clean publish-problem-spring-boot-autoconfigure:build

it will be executed successfully. The only problem is with publishing the artifact.
Workaround:
You must specify dependency versions manually; an example of a fix is provided in the commit.

Clone the repository:

git clone git@github.com:morohon/publish-problem-spring-boot-starter.git

Go to the fix-publish branch:

git checkout fix-publish

Run the command:

./gradlew publish-problem-spring-boot-autoconfigure:clean publish-problem-spring-boot-autoconfigure:generateMetadataFileForStarterPublication

See information about the successful execution of the command in the log

Gradle version
8.6
Build scan URL (optional)
https://scans.gradle.com/s/5deahcckx2wxm
Your Environment (optional)
macbook pro 2021 (m1 max), java 21, spring boot 3.2.2

This issue will be closed as a duplicate of

#23030

This was a strict failure in Gradle 8.6 and before.
With Gradle 8.7, you will be able to skip this validation and publish metadata without versions.
Note that we still do not recommend doing so for any public library as it is unlikely to behave properly in all cases


How to publish page after edit

I am in need of page builder in Vue/Laravel project.
v-craft seems to be fit with my need.
Already looked through documentation and codebase but not sure how to publish page after edit.
Please help!

@yoychen
FYI

Hi,
https://yoychen.github.io/v-craft/docs/api/editor.html#disable
I wish the disable() method would be the solution you want. Make the editor disabled after loading page data so user can view your page.


when in run there are somany errors on the workflow when i try to configure kubeflow on azure KMS service...

when in run there are somany errors on the workflow when i try to configure kubeflow on azure KMS service...WARN[0076] Encountered error applying application application:  (kubeflow.error): Code 500 with message: Apply.Run : [unable to recognize "/tmp/kout425701374": no matches for kind "CustomResourceDefinition" in version "apiextensions.k8s.io/v1beta1", unable to recognize "/tmp/kout425701374": no matches for kind "Application" in version "app.k8s.io/v1beta1"]  filename="kustomize/kustomize.go:284"
WARN[0076] Will retry in 13 seconds.

The Azure docs are being removed from the website in https://github.com/kubeflow/website/pull/3547, please raise an issue on their new repo if you are still having problems.
/close


Figure out a decent first draft API.

I'd like to take some time to play with API ideas, to see if we can come up with something better than we currently have, and also account for supporting the various features of OpenEXR.
I don't expect to figure out a final 1.0 API or anything, but rather a first draft that we can implement and use for a while to get more experience for the next iteration.
Some notes of my own below.
Using the builder pattern, pros and cons
For OutputFile I'm currently using a builder pattern, so creating a file and writing to it looks something like this:
let mut fb = {
    // Create the frame buffer ...
};

OutputFile::new()
    .resolution(256, 256)
    .channel("R", PixelType::FLOAT)
    .channel("G", PixelType::FLOAT)
    .channel("B", PixelType::FLOAT)
    .open(Path::new("/path/to/file.exr"))
    .unwrap();
    .write_pixels(&mut fb).unwrap();

This seems to make sense, because there are a lot of things that can potentially be specified about the file (but which mostly have obvious defaults), and due to OpenEXR's C++ API they all need to be specified before actually opening the file for writing.  It's also convenient for creating an OutputFile inline somewhere.
However, a weakness of this is, for example, that if you have an array of channels already, the builder pattern actually makes it a bit more awkward.  Instead of something like this:
let mut out = OutputFile::new().resolution(256, 256);
for (name, pixel_type) in channel_vec.iter() {
    out.add_channel(name, pixel_type);
}
// ...

You have to do this:
let mut out = OutputFile::new().resolution(256, 256);
for (name, pixel_type) in channel_vec.iter() {
    out = out.channel(name, pixel_type);
}
// ...

OutputFile::new()
.resolution(256, 256)
That isn't awful, but it does IMO read a bit strange with the out = out.whatever() in the loop.
Supporting different InputFile and OutputFile types
OpenEXR supports scanline files, tiled files, multi-part files, and deep files and all the permutations thereof.  For simple input/output this isn't too much of a concern, and I would like to make sure there are simple API's for cases where people just don't care.  But first I want to make sure we wrap all of the lower-level functionality well, and then we can build on top of that later for simpler use-cases.
For output, my current idea is to have multiple different *Writer types that you can get from *_open() calls.  So, for example, if you want a create a tiled file you would do:
let mut out: TiledWriter = OutputFile::new()
    .resolution(256, 256)
    // ...
    .open_tiled(Path::new("/path/to/file.exr"));

And for a tiled and multi-part file:
let mut out: TiledMultiPartWriter = OutputFile::new()
    .resolution(256, 256)
    // ...
    .open_tiled_multipart(Path::new("/path/to/file.exr"));

Etc.
This would correspond closely to the various *OutputFile types in the C++ API, and would allow us to present a tailer-made API for each output type (e.g. writing tiles to a tiled file).
For InputFile I'm thinking we could do something similar by returning an enum of possible *Reader types.
Accessing InputFile's channels
To properly read an input file, it should either be verified that the expected channels exist in it and are of the right type, or the channels that do exist should be used to build the frame buffer.  This requires accessing the channel descriptors.
So far all I've implemented for that is an iterator API:
let input = // Get input file
for (name, channel) in input.channels() {
    println!("{} {:#?}", name, channel);
}

But that is unlikely to cut it on its own.  Some kind of direct access would probably be good:
let channel_descriptor = input.get_channel("R").unwrap();

Custom Attributes
OpenEXR files support custom attributes to be written to and read from exr files.  I haven't investigated the API closely enough to know exactly how they work (e.g. what types are supported, if it's extensible, etc.).  But at first blush, I think using an API similar to what we have for channels would be good:
OutputFile::new()
    .resolution(256, 256)
    .attribute("attribute_name_1", /* some way of specifying an attribute value */)
    .attribute("attribute_name_2", /* some way of specifying an attribute value */)
    // ...

let input = // Get input file
for (name, attribute) in input.attributes() {
    println!("{} {:#?}", name, attribute);
}

let attribute_value = input.get_attribute("attribute_name_1").unwrap();

@Ralith
Would love your thoughts on this, if you have the time!

Using the builder pattern, pros and cons

Using a builder whose methods take and return &mut Self, rather than Self, addresses the cons here. This is the approach taken by the cmake and gcc crates, for example, and we've already taken advantage of that in build.rs.

Supporting different InputFile and OutputFile types

Why diverge from the upstream FooOutputFile naming scheme here? I figure we should stay as close as we can except where that would severely compromise API usability. Naming aside, the output stuff makes sense to me.
I poked around the input end of things in the OpenEXR and it wasn't obvious to me how to dynamically identify the type of a file. Is it clear that the different interfaces aren't more about access patterns than the actual file itself? I'd also be concerned about keeping it convenient for people to decode data from a file without necessarily caring what its internal layout is. Neither of these are insurmountable, just things to bear in mind.

Accessing InputFile's channels
Custom Attributes

These both seem like basically reasonable APIs, but is there a good reason for us to be inlining Header accessors into the input/output objects like that? If we stick more closely to the upstream API of mediating through a header object, there might be substantially less boilerplate, and the interface would be less surprising.

Why diverge from the upstream FooOutputFile naming scheme here? [...]

That's an excellent point.  Yeah, let's try to match naming wherever possible.

I poked around the input end of things in the OpenEXR and it wasn't obvious to me how to dynamically identify the type of a file. Is it clear that the different interfaces aren't more about access patterns than the actual file itself?

If you take a look at e.g. https://github.com/openexr/openexr/blob/develop/OpenEXR/IlmImf/ImfTiledInputFile.h, the doc comments specify that it throws an exception if the file isn't a tiled file.  I haven't checked the others, but I expect the same holds true for the other variants.
The exception to that, I believe, is the vanilla InputFile which treats all files uniformly, but you also can only access the file in the lowest-common-denominator ways.  Unless I'm misreading the code (which is entirely possible).
In any case, we could just try matching those semantics first: have different *InputFile types, and they return Err if the file you're trying to open doesn't match its type.  Then we can layer other things like a function that returns an enum on top of those at some point in the future.

These both seem like basically reasonable APIs, but is there a good reason for us to be inlining Header accessors into the input/output objects like that?

I don't think there is.  So yeah, let's expose the header too.  Then we can have HeaderBuilder instead of OutputFileBuilder or whatnot, since the header is the part that takes all of the numerous parameters.  And then we can return a header reference from InputFile's.
After reading what you wrote, I'm thinking now that the best approach is to try to match the upstream API semantics as closely as we can, with matching naming schemes and everything.

I'd also be concerned about keeping it convenient for people to decode data from a file without necessarily caring what its internal layout is.

Oh yeah, I definitely agree.  But what I'm thinking is that we make low-ish level bindings first, and then we can layer convenience API's on top of that later.  For example, for people who just want to do simple input/output of RGB(A) files, and don't care about tiling, deep pixel data, etc.

In any case, we could just try matching those semantics first: have different *InputFile types, and they return Err if the file you're trying to open doesn't match its type

Reviewing the docs this seems to be the intended use pattern--either you know in advance that your file has a specific layout or you don't care. I have trouble imagining a use case that demands anything other than that.

But what I'm thinking is that we make low-ish level bindings first, and then we can layer convenience API's on top of that later

It sounds like all we really need to do here is retain (something much like) the current InputFile API while exposing the more specialized stuff separately. There's also the Rgba variants for extra simplicity if needed.

Reviewing the docs this seems to be the intended use pattern--either you know in advance that your file has a specific layout or you don't care. I have trouble imagining a use case that demands anything other than that.

I know of at least one, which is represented in e.g. node-based compositing applications.  The user would add an OpenEXR node or something like that, and the node would expose all of the data within the selected exr file so the user can use it in the composite.  But I think this is pretty niche, and can still be accomplished by just trying opening it as the different types.  So yeah, I think you're right that we can ignore this.  If it actually comes up at some point in the future, we can address it then.

It sounds like all we really need to do here is retain (something much like) the current InputFile API while exposing the more specialized stuff separately.

Yeah.  And I'm pretty sure we get that for free by just wrapping their InputFile API as we've already done, right?  So now it's just a matter of also wrapping the other *InputFile types.

There's also the Rgba variants for extra simplicity if needed.

Yeah.  I was assuming we'd write our own simplifications for that, rather than wrapping theirs, because it's that much less unsafe FFI surface area and should be straightforward.  But I'm not really picky.
Also, forgot to respond to this:

Using a builder whose methods take and return &mut Self, rather than Self, addresses the cons here. This is the approach taken by the cmake and gcc crates, for example, and we've already taken advantage of that in build.rs.

Ah!  That makes sense.  I've made that change to the new Header type.  The only downside is that you can't do this:
let header = Header::new()
    .set_resolution(256, 256)
    .add_channel("R", PixelType::FLOAT)
    .add_channel("G", PixelType::FLOAT)
    .add_channel("B", PixelType::FLOAT);

Because header is just a &mut reference and the actual Header doesn't live beyond the right-hand expression.  But I think that's a reasonable trade-off.

I was assuming we'd write our own simplifications for that, rather than wrapping theirs, because it's that much less unsafe FFI surface area and should be straightforward.

That makes sense to me.

The only downside is that you can't do this:

It looks to me like the upstream OutputFile implementation takes a reference and copies the Header rather than consuming it. If we respect that, I think we still get OutputFile::new(Header::new().set_size(256, 256).add_channel("R". PixelType::FLOAT)..., which is probably the main ergonomic case of interest.


[QUERY] AzureServiceTokenProvider rewrites the PATH variable when invoking Azure CLI

Query/Question
Why does the token provider rewrite the PATH? When installed outside of /usr/bin or /usr/local/bin and no path is provided in the AzureCLIPath environment variable, the token is not obtained and the problem is hard to debug. There is a comment stating that "// Default install location for Az CLI is included. If developer has installed to non-default location, the path can be specified using AzureCliPath variable." But I do not see any merit in deleting the PATH that the developer may expect to be present in the process.
The only thing I can come up with is preventing running different executable named az, but this does not protect anyone if the attacker is already able to install an executable inside a directory on the PATH or augment the variable.
Line 83 at AzureCliAccessTokenProvider.cs
Why is this not a Bug or a feature Request?
Because I believe there may be some rational decision as to why the current state is this way.
Setup (please complete the following information if applicable):

OS: Linux (based on source code works the same way on macOS and similar rewrite is also present for Windows)
Version of the Library used: 1.3.1

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Query Added
[x] Setup information Added

This is just to be overly cautious about not running a malicious program. The existing path environment variable could have various different directory paths in it, and we had made a decision to not trust all of those directory paths. The decision was to favor a white list of known paths or let the developer specify one.


Graph Statistics Output

Can ndmg.graph be manipulated to provide summary statistics in vector format for multiple graphs (such as [NNZ, Deg Seq, etc.])? I would like to save summary statistics from graphs generated in a pickle file if possible.

@jovo, do you have any suggestions for implementation?

i don't understand your question, you want to convert the output to a different format? from what to what? please be more clear, and @loftusa can help.

To clarify, I am trying to generate a "vector" for a graph that really contains several graph statistics as a list. I have multiple graphs and I would like to create a list for each graph that can then be concatenated by rows to make a data matrix.
It would be helpful if ndmg could generate statistics on a graph and save them in either a .npz or .pkl file. Or if multiple graphs are used as input, a saved data matrix would be nice.

@GaneshArvapalli oh, that seems like a function you can easily write?

@GaneshArvapalli @jovo ndmg_bids has a group function that computes summary statistics (including those you mentioned) and saves them in pickles, as well as plotting the results.

I've looked over the code and the group_level function combined with compute_metrics will be very useful for when I'm writing an implementation. I will update once it's been completed. Thank you!


Fix support for multiple root LOD objects in a single scene

Currently the code adds all LOD level node ids to each root LOD node, this changes it to add only the individual root node's LOD level node ids.

Oops, there's already a PR for this.  Closing in favor of #3


Visibility medium-up not working

I am using the sass version of Foundation for Sites 6 (migrating a site from F5 ) and it seems that the .show-for-medium-up is not working any more.
If only I had the time to dive into your mixins I would have made a pull request right away, sorry about that.

Excuse me, I had mistakenly opened the F5 Docs.


Position/token masking feature

First of all, thank you for this wonderful piece of work!
Is there currently a way to specify a token/position mask in case different samples in the same batch have differing lengths, or are there any plans to add this to the implementation?

Just discovered this is inferred by mask = molecule_atom_lens > 0, apologies for false alarm

@thomashopf no problem! feel free to join the discord and voice any other issues you see (will be faster to get to a resolution when subjected to crowd wisdom)


Bump to version 0.4.0

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


SMI meeting hiatus for GAMMA launch.

As discussed on Slack, SMI community meetings are on hiatus until October 12th to allow time for maintainers and community members to focus on the GAMMA launch.
Signed-off-by: Bridget Kromhout<EMAIL_ADDRESS>

What is the relationship between SMI and GAMMA now?

As per https://smi-spec.io/blog/announcing-smi-gateway-api-gamma/:

To that end, members of the Istio, SMI, and SIG Network communities have come together to collaborate on mesh use cases in the Gateway API project, starting a new group for Gateway API Mesh Management and Administration — the GAMMA Initiative. Together, we will investigate, design, and track Gateway API resources, semantics, and other artifacts related to service mesh technology and use-cases while seeking consistency between implementations of the Gateway API by service mesh projects.

Working within CNCF gives us the opportunity to build platforms that extend and integrate into Kubernetes. As these communities grow, we see additional opportunities to act as force multipliers. We’re excited to work together and for the entire cloud native community to enjoy the fruits of our collaboration.

Thanks, I saw that. I was just wondering if there was any update since then :)


Updated config_example.yml to include rss fields with explanation

Added rss fields and explanation to config_example

Everything looks good


Fix text area styles

Fixes #82

Changes proposed in this Pull Request:

Remove the height requirement from the Input fields.
Add a blui-condensed directive that applies the 56px height.

https://pxb-angular-theme-demo.web.app/material-components/input-components


Arduino IDE Package

Are there any plans to publish an updated version of this library on Arduino IDE? The version online still contains bugs such as #3 that are already fixed in master

Hello,
Thank you for pointing out this problem.
I will release a new version today.

The latest version has been released.
It takes a day for the Arduino library manager to take effect.

It looks like the latest version is now available for download in arduino, so I'm going to close this issue.
Feel free to reopen it if you have any other questions!


Hydrate all currencies that was loaded in cache

📝 Description
worked with @lambertkevin to solve ongoing bug in LLD.
see https://ledgerhq.atlassian.net/wiki/spaces/~5570585546a11e40f64481b3c5af5e8f0034c0/pages/4025254182/hydrateCurrency+should+be+called+for+each+data+stored+in+localStorage+to+truly+hydrate+everything+even+currency+that+weren+t+imported+as+account+yet
in order to make them available at load of the app (synchronously) BEFORE the accounts are loaded (eg tokens are needed to be loaded in order to not disappear through the serialisation)
❓ Context

Impacted projects: LLD
Linked resource(s): n/a

✅ Checklist

[ ] Test coverage
[ ] Atomic delivery
[ ] No breaking changes

📸 Demo

🚀 Expectations to reach
Please make sure you follow these Important Steps.
Pull Requests must pass the CI and be internally validated in order to be merged.

Added here unless with merge this one before, with LLD & LLM support: 572df86852f0f8c909c46136bd4706fbe0a6218d 👌

@lambertkevin yeah it will be find to land either of the PR. this is a bugfix so it may be good to document a changelog too

this work is going to get included as part of https://github.com/LedgerHQ/ledger-live/pull/2328