Fix exception in when realm_domains change without its UI visible

The function populate_realm_domains_table is called from server_events_dispatch.js for all users when the organization's domains change. However, it appears that the logic expects the realm_domains_table to be present. This is likely easy to fix -- we can just exit without doing anything if the table is not already present in the DOM in the code path coming from server_events_dispatch, since there's nothing to live-update in that case.
export function populate_realm_domains_table(realm_domains) {
    const $realm_domains_table_body = $("#realm_domains_table tbody").expectOne();
    $realm_domains_table_body.find("tr").remove();

    for (const realm_domain of realm_domains) {
        $realm_domains_table_body.append(
            render_settings_admin_realm_domains_list({
                realm_domain,
            }),
        );
    }
}

Tagging as a release goal as we try to avoid having any of this class of bug in the project.
@ganpa3 FYI since you worked in this code path recently; I'm guessing it's not actually a regression but not totally sure.

@timabbott #23322


Cannot create an instance of "CompositionImage"

I try to use the user control ImagePopupViewer but in VS 2017 it says in XAML designer:
Method not found: 'void Windows.UI.Composition.Vector2KeyFrameAnimiation.InsertKeyFrame(Single, System.Numerics.Vector2);
for below statements:
    <common:CompositionImage x:Name="BackgroundImage" Stretch="Fill" Grid.RowSpan="2" />
    <common:CompositionImage x:Name="PrimaryImage" Margin="10" Grid.Row="0" MinHeight="300" MinWidth="300"/>

Target version: 15063
Min version: 14393

The XAML Designer will not render it correctly.
Though when you run the application, it should work fine.

Actually the SamplesNative Project is targeted to x64 and adjust all other projects to target to x64 then problem solved.


maintenance on mod_manager functions

I'm porting this change from 1.3.x into master so that it isn't lost.

Here's a link to the PR, in case you wanted to look at it https://github.com/modcluster/mod_cluster/pull/184


Port python packaging to Content.Packaging

Requires https://github.com/space-wizards/RobustToolbox/pull/4547
Some of this is still pretty bad but I just want some semblance of parity so I can ship audio metadata for audio rework.

Quick notice: removing the .py files will break watchdogs git method.

Quick notice: removing the .py files will break watchdogs git method.

<EMAIL_ADDRESS>Yes it's already a semi broken piece of work but lots of servers still use it instead of a proper cdn
I added back the python scripts for now so I can check upstream works with the changes in prod but will update watchdog prior to adding the audio metadata pass.


React-Scripts dependencies with CVEs

Is your proposal related to a problem?
Snyk reports vulnerabilities in react-scripts dependency tree:
✗ Medium severity vulnerability found in dot-prop
Description: Prototype Pollution
Info: https://snyk.io/vuln/SNYK-JS-DOTPROP-543489
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Fixed in: 5.1.1
✗ Medium severity vulnerability found in @hapi/hoek
Description: Prototype Pollution
Info: https://snyk.io/vuln/SNYK-JS-HAPIHOEK-548452
Introduced through<EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>From<EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>><EMAIL_ADDRESS>Fixed in: 8.5.1, 9.0.3
Please note that although the above references<EMAIL_ADDRESS>v3.4.0 has not updated these dependencies and therefore has the same problem.
Describe the solution you'd like
Release a new version of react-scripts that updates to the latest versions of workbox-webpack-plugin and optimize-css-assets-webpack-plugin, which should resolve this issue.
Describe alternatives you've considered
None
Additional context
N/A

I'll add some from<EMAIL_ADDRESS>(latest)
Description: Prototype Pollution
Info: https://app.snyk.io/vuln/SNYK-JS-YARGSPARSER-560381**
Introduced through<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>›<EMAIL_ADDRESS>

+1 for yargs-parser

yargs-parser has had breaking changes in its releases since 16.1.0: https://github.com/yargs/yargs-parser/releases
In the meantime, forcing resolution to an pre-breaking change release of yargs-parser seems to work

@shmily40686 any workaround you found?

any fix planned ?

Please file with webpack-dev-server about yargs-parser. There's nothing we can from our end to update their dependencies.

There is a webpack-dev-server issue: https://github.com/webpack/webpack-dev-server/issues/2559

FYI: https://github.com/webpack/webpack-dev-server/pull/2581 has been merged and<EMAIL_ADDRESS>has been released with the fix

When might we expect the next release of react-scripts?

When might we expect the next release of react-scripts?

Hope that this is soon because a new high priority vulnerability has been raised now:
Denial of Service in the web-pack dependency

@ianschmitz do you know when the next release will happen? I think it would be nice if we could get security related changes published as soon as possible after being reviewed and merged.
I would love to help if I can. If there are specific tasks needed or technical blockers, I would be happy to be involved and pick up some work?

I am also getting this error for react-scripts > webpack-dev-server > yargs > yargs-parser, Is there any solution to it ?  My website build is getting failed because of this error.
                  === npm audit security report ===

                             Manual Review
         Some vulnerabilities require your attention to resolve

      Visit https://go.npm.me/audit-guide for additional guidance

Low             Prototype Pollution
Package         yargs-parser
Patched in      >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2
Dependency of   react-scripts [dev]
Path            react-scripts > webpack-dev-server > yargs > yargs-parser
More info       https://npmjs.com/advisories/1500
found 1 low severity vulnerability in 1690 scanned packages
1 vulnerability requires manual review. See the full report for details.

I am also getting this error for react-scripts > webpack-dev-server > yargs > yargs-parser, Is there any solution to it ? My website build is getting failed because of this error.
                  === npm audit security report ===

                             Manual Review
         Some vulnerabilities require your attention to resolve

      Visit https://go.npm.me/audit-guide for additional guidance

Low Prototype Pollution
Package yargs-parser
Patched in >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2
Dependency of react-scripts [dev]
Path react-scripts > webpack-dev-server > yargs > yargs-parser
More info https://npmjs.com/advisories/1500
found 1 low severity vulnerability in 1690 scanned packages
1 vulnerability requires manual review. See the full report for details.

Same here. I am tracking this issue here https://github.com/zw627/react-router-github-pages/issues/11

`                       === npm audit security report ===
                                           Manual Review

Some vulnerabilities require your attention to resolve
Visit https://go.npm.me/audit-guide for additional guidance
Low             Prototype Pollution
Package  yargs-parser
Patched in  >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2
Dependency of   react-scripts
Path  react-scripts > webpack-dev-server > yargs > yargs-parse
More info   https://npmjs.com/advisories/1500
found 1 low severity vulnerability in 1620 scanned packages
1 vulnerability requires manual review. See the full report for details.`

Getting the same issue mentioned above, is there any new version of react-script which will fix this issue.
Low             Prototype Pollution                                                                                Package         yargs-parser                                                                                Patched in      >=13.1.2 <14.0.0 || >=15.0.1 <16.0.0 || >=18.1.2                                                                                Dependency of   react-scripts [dev]                                                                                Path            react-scripts > webpack-dev-server > yargs > yargs-parser                                                                                More info       https://nodesecurity.io/advisories/1500

I am having the same issue, any updates on this?

Same issue here.
vulnerability-report.txt
Getting nearly 5000 low severity vulnerabilities with react-scripts 3.4.1.
found 4982 low severity vulnerabilities in 1641 scanned packages
4982 vulnerabilities require manual review. See the full report for details.
Attached is the vulnerability report.

Same issue here.
Getting nearly 5000 low severity vulnerabilities with react-scripts 3.4.1.
found 4982 low severity vulnerabilities in 1641 scanned packages 4982 vulnerabilities require manual review. See the full report for details.

Most of these are not related to yargs-parser - they're from a new vulnerability raised by npm for lodash. This PR https://github.com/lodash/lodash/pull/4759 has already been merged to fix the issue, so npm will probably release a patch based on the PR.

Same issue here.
Getting nearly 5000 low severity vulnerabilities with react-scripts 3.4.1.
found 4982 low severity vulnerabilities in 1641 scanned packages 4982 vulnerabilities require manual review. See the full report for details.

Most of these are not related to yargs-parser - they're from a new vulnerability raised by npm for lodash. This PR https://github.com/lodash/lodash/pull/4759 has already been merged to fix the issue, so npm will probably release a patch based on the PR.

Good to know, I just spent a while trying unsuccessfully to fix this.

Same issue here.
Getting nearly 5000 low severity vulnerabilities with react-scripts 3.4.1.
found 4982 low severity vulnerabilities in 1641 scanned packages 4982 vulnerabilities require manual review. See the full report for details.

Most of these are not related to yargs-parser - they're from a new vulnerability raised by npm for lodash. This PR https://github.com/lodash/lodash/pull/4759 has already been merged to fix the issue, so npm will probably release a patch based on the PR.

Thanks a lot for the update @EoghanBonass

No problem @shridharbhandiwad and @jacobwicks 🙂
The lodash PR was merged into what I assume is a release branch (lodash:4.17.15-post), so this needs to be fully released and then whitelisted by npm for the lodash vulnerability to be resolved.

re: workbox, would it makes sense to make it optional?
I feel that there was a time when Google pushed PWA and I think that was perhaps the impetus of adding it in, right?
But today, is it all that common to use web workers?

when other dependencies are updated the yargs-parser get rollback to its previous older versions.
on updating outdated packages, yargs-parser needs manual audit to update its new patch again.

cc @vigomesbr

When will this be fixed?
Does it actually matter? In other words, does any of the broken lodash or yargs code end up in the final build?

There are no and have been no vulnerabilities here that would affect Create React App projects. These are all false positives because none of this code ends up in a build.
This is all, unfortunately, wasted effort.

I’m going to close as there’s no real vulnerabilities and they’re all transitive. This means that if you are determined to spend time on false positives (for example, maybe your company adopted a policy that treats false positives from npm audit as real issues) then you need to file issues in the transitive dependencies. Once those are fixed you need to regenerate the lockfile. There is nothing actionable for Create React App here.


PROD-2058 implement endpoints for property specific messaging

Closes https://ethyca.atlassian.net/browse/PROD-2058
Description Of Changes
Implements API endpoints for property-specific messaging. The following new endpoints were added:

GET /messaging/templates/summary- get paginated list of all templates
GET /messaging/templates/default/{template_type}- get the default messaging template by type. This is not dependent on the DB at all, rather hard-coded in the BE.
POST /messaging/templates/{template_type}- create a new messaging template . Use req body formatted like:

content: Dict[str, Any]
properties: Optional[List[str]]
is_enabled: bool

PUT /messaging/templates/{id}- update an existing messaging template. Use req body formatted like:

content: Dict[str, Any]
properties: Optional[List[str]]
is_enabled: bool

PATCH  /messaging/templates/{id}- update an existing messaging template. Use req body formatted like:

content: Optional[Dict[str, Any]]
properties: Optional[List[str]]
is_enabled: Optional[bool]

GET /messaging/templates/{id}- get an existing messaging template by id
DELETE /messaging/templates/{id} - delete a messaging template by id

Code Changes

[ ] Adds new endpoints to support property-specific messaging
[ ] Adds endpoint tests

Steps to Confirm

[ ] Attempt to add / edit / create /delete messaging templates via endpoints. See endpoint tests in ops/api/v1/endpoints/test_messaging_endpoints.py for details of how the endpoints should function.

Pre-Merge Checklist

[ ] All CI Pipelines Succeeded
Documentation:

[ ] documentation complete, PR opened in fidesdocs
[ ] documentation issue created in fidesdocs
[ ] if there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry

[ ] Issue Requirements are Met
[ ] Relevant Follow-Up Issues Created
[ ] Update CHANGELOG.md
[ ] For API changes, the Postman collection has been updated
If there are any database migrations:

[ ] Ensure that your downrev is up to date with the latest revision on main
[ ] Ensure that your downgrade() migration is correct and works

[ ] If a downgrade migration is not possible for this change, please call this out in the PR description!

Pipeline failures dependent on https://github.com/ethyca/fides/pull/4993 being merged

Ticket to move endpoints to plus as a follow-up: https://ethyca.atlassian.net/browse/PROD-2211


AspNet Request IP Layout Renderer with IPv4

Hi,
I am using this layout renderer in .net core 2.0 on linux, where IPv6 is disabled:
When the server starts up, I get a message like this from the Kestrel logger:
{ "date": "2018-04-17 22:04:40.6051", "level": "WARN", "logger": "Microsoft.AspNetCore.Server.Kestrel", "aspnetUser": " ", "message": Unable to bind to http://localhost:5000 on     the IPv6 loopback interface: 'Error -97 EAFNOSUPPORT address family not supported'. }

Is there a way, in the configuration, to force it to bind to IPv4 instead of IPv6?
The current layout renderer ends with RemoteIpAddress.. Is there a way to add this to what it logs, without having to recreate or make a pull request, against that renderer?
HttpContextAccessor?.HttpContext?.Connection?.RemoteIpAddress.MapToIPv4()
Thanks!

I think it would be nice to add an option "Ip4" (boolean) to the AspNetRequestIpLayoutRenderer (disabled by default, so it's backwards compatible).
Could you please send a PR for that?

@304NotModified Are you still interested in implementing this feature? I can send a PR

yes, would be great!

As I can see there is no MapToIPv4 in .Net Framework 3.5 so we cannot implement in all platforms. Is that OK ?

That's not a problem, as long as it's documented :)

The problem is that NLog.Web project is an "old style" project and it targets .Net 3.5 If we want to support MapToIPv4 in Asp.Net MVC style projects we will need to convert the project to new csproj style first and create several target frameworks.

IpAddress-ToString() will show IPv4-format if request comes from IPv4-address (And show IPv6-format for IPv6-address)
Sounds like two issues from the original poster:

Figure out why the Kestrel complains about IPv6 loopback interface
Change RemoteIpAddress output so it lookup the host using its IPv6-address, and checks if the host also has a IPv4-address, and if so then display the IPv4-address (Sounds very exotic and mostly for local network requests).

Not sure I understand how MapToIPv4 will solve any other those two issues. It will just truncate the IPv6-address into a "random" IPv4-address:
https://github.com/Microsoft/referencesource/blob/master/System/net/System/Net/IPAddress.cs#L738


Add new empty catalog module

Only contains the generated "Hello, World" code so far.

A bit more extra changes will be needed to add Documentation support for this package.
Currently the documentation setup is a bit of wonky, which is why I did not add it to the generate-module.sh script.
But I think we can live with it until the module is further along, right?

 Currently it is just about providing a few things so folks aren't blocked.


Keywords as Foriegn key

Use Keywords are ReferenceField instead of a StringField (better validation). Also, why not also use this ReferenceField in Procedures.
Finally, I think the Keywords table doesn't need the program field as it can simply be included when creating the hash_index itself.

Agreed on Keywords as ReferenceField. Procedures becomes more difficult as each procedure will use the ReferenceField in a different way. We currently subclass this correctly with ME so we should able to make it work however.
The reason I originally left program is that I was toying with catching if the execution program and Keyword program were different we could potentially catch errors. Not sure if this is all that realistic however. I do think the subclassing is useful where KeywordSet.values hold the actual keywords so that we can add creation data, comments, provenance, etc.


Hard strict mode

Hmm, same strict mode finds a lot locally but not on CI

Codecov Report

Merging #438 (0e1e431) into master (ce7782d) will decrease coverage by 0.03%.
The diff coverage is 92.75%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@             Coverage Diff              @@
##             master     #438      +/-   ##
============================================
- Coverage     87.15%   87.12%   -0.03%
+ Complexity      372      364       -8
============================================
  Files            32       32
  Lines          1432     1429       -3
  Branches        164      165       +1
============================================
- Hits           1248     1245       -3
  Misses          115      115
  Partials         69       69

Files Changed
Coverage Δ

tracker/src/main/java/org/matomo/sdk/Matomo.kt
84.37% <84.37%> (ø)

...c/main/java/org/matomo/sdk/LegacySettingsPorter.kt
100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


(FR) language chooser option for twitter GUI / tweetdeck

perhaps this repo twitter/twitter.github.io would have been a better place to ask this question?
see here: https://github.com/twitter/twitter-text/issues/291
I have actually gone through ALL your repos on https://twitter.github.io/projects.html to find something related, but your language processing team works closed source, I suppose? Please forward to them, thanks. Perhaps tomorrow you meet one of them in the cafeteria by chance ...

Hi there - this is the repository for the Twitter open source web portal - unfortunately we are not able to accept questions about the twitter.com website itself via GitHub.
Closing as invalid.


Updates for Crystal 0.29.0

Any chances of getting this updated?

Will try to pick this up soon again. Thanks for your interest


zoom behavior disables click events on child elements

hello,
i encountered some difficulties to migrate some code from d3 API v3 to v4. Most of the issues are fixed but now i'm completely stuck on the new zoom behavior.
My zoom behavior is a bit special : only on X-axis, for both pan (translation) + "zoom". But i don't zoom the images, i rescale the x-axis only. All of this worked well with v3.
I call zoom as usual with svg.call(zoom), it's the top level element. But, when zoom is active, the clickable labels do not respond to "click" events anymore. If i reload everything just by commenting the call(zoom) then it works. You can play with the 2 buttons to see the effect by yourself.
Addendum: sometimes the clicks work with zoom! But then, if you start a pan action from an item, it becomes inactive again and it blocks all the other items as well. There's something wrong going on with the event chain : it works randomly and eventually gets stuck.
The zoom behavior seems to be attached on the svg only, but still it has an effect on other child elements. I tried to remove the zoom behavior from the clickable labels after setting the zoom on the main svg, but it has no effect.
I tried to apply the zoom behavior only on the specific elements (every concerned subitem), but then it becomes a mess. It seems better to keep it on the higher level (svg).
I tried to read more about the events, preventDefault and so on, but let's admit it, it is very hard to understand what is going on and what changed. With d3 v3 i didn't have this problem.
Any suggestion? Help is much welcome. Thank you in advance !
For info here is the code used to create the zoom behavior and the events handlers
// setup zoom allowing only pan+zoom on X
  var zoomPanX = d3.zoom()
    .scaleExtent([1, 9]) // zoom scale x1 to x9
    .translateExtent([[-width/2, 0], [width+width/2, height]]) // pan limits in the viewport (pan offsets = +/-{w/2})
    .on("zoom", zoomed)
    .on("end", zoomended);

  function zoomed() {
    var transform = d3.event.transform;
    // constraint transformation, no translation on Y axis
    transform.y = 0;
    // recompute a new scale with current transformation
    xScale = transform.rescaleX(xScaleBase);
    xAxis.scale(xScale);
    redrawSvg(false); // no transition
  }

  // ...
  // enable click events --- the issue is : selectSerie is not triggered on click anymore
  chart.selectAll("g.legend")
    .on("click", selectSerie);

  // ...
  // activate zoom on chart (svg)
  chart.call(zoomPanX);

[Update 2016-10-29] i removed the sample showing the issue as it was not an independent piece of code and it has been solved with d3v4 meanwhile. You can see the current result in action and it's fun ;)
http://psionic-storm.com/classement-des-heros/

The difference with v4 is documented here in the release notes:

The zoom behavior now consumes handled events, making it easier to combine with other interactive behaviors such as dragging.

Here “consumes handled events” means event.stopImmediatePropagation and where possible event.preventDefault. More details are found in the API Reference’s table of handled events. Note the complication that due to browser bugs, the mousedown event cannot have its default behavior prevented; see d3/d3-drag#9 for details.
(For the implementation, see the calls to nopropagation and noevent in zoom.js and noevent.js.)
The motivation for this change is to avoid accidental concurrent gestures. In v3, the default behavior was to allow concurrent gestures, which often lead to undefined behavior. In v4, the behaviors consume events and thus are exclusive by default. As a result, v4 makes it much easier to combine behaviors; for an example, see Drag & Zoom II. In contrast; the v3 Drag + Zoom example required you to explicitly stop propagation on the source event of a drag manually to prevent a concurrent zoom gesture.
An implication of this change in v4 is that if you apply the zoom behavior to an element, and then register a mousedown event listener on that element, you will never see mousedown events because the zoom behavior will have consumed the event. However, the normal rules of event propagation still apply, so if you register the mousedown event listener before applying the zoom behavior, or if you use a capturing event listener, or you register a non-capturing listener on a descendant element, your mousedown listener will see the event before the zoom behavior and thus have a chance to handle the event. You can then call event.stopImmediatePropagation to prevent the zoom behavior from seeing it, if desired, or you can elect to allow propagation and concurrent interactions. You can also use zoom.filter to control which events the zoom behavior uses to initiate a zoom gesture.
The click event is a special case. In general, it is not recommended to combine clicking and zooming on the same element because the interpretation of a sequence of input events is ambiguous: should a sequence of mousedown, mousemove*, mouseup be interpreted as a click, or as a panning gesture? Often the desired answer depends on whether the mouse moved between mousedown and mouseup: we only want a click if the mouse has not moved. This is implemented in nodrag.js, and note where g.moved is set to true in zoom.js.
Unfortunately, the definition of “moved” is also ambiguous. The d3-drag and d3-zoom behaviors consider the mouse to have moved if any mousemove event is received between mousedown and mouseup. If you have a particularly sensitive mouse, it can be difficult to click because the a mousemove event is inadvertently dispatched and the click is instead interpreted as a (small) panning gesture. Also, there may be a browser or platform bug (#65) where a mousemove event is dispatched even if the mouse did not move at all.
When #65 (and d3/d3-drag#28) is fixed, the zoom behavior will be more robust at distinguishing between input event sequences that are clicks and those that are small panning gestures. If desired, you can also avoid the ambiguity by stopping propagation on mousedown on your clickable elements, such that you can only pan by clicking on the background of the chart.

Thank you sir! Many thanks for the time you spent answering this with so many details. It was really useful, much appreciated!
The good news : with this i found a solution!
But there are a few mysterious points and it might be useful to other developers. Also, maybe a guideline should be written on how to disable zoom on specific sub elements. Though it works for me, i'm not sure my solution is the best for all.

Changes with 4.2.8
From yesterday, the example i gave you to illustrate the problem suddenly worked! I couldn't reproduce the problem, that was a bit crazy... But then i noticed that you delivered a new version 4.2.8 a few hours before! So, the problem of concurrent events that used to happen in 4.2.6 and 4.2.7 does not happen in 4.2.8 anymore. This new version should fix an issue about "interrupting transition events", that i don't use here. My observation is that with 4.2.8, the zoom doesn't eat the event so the click events on sub elements also triggers (both zoom and click)! So, something else changed.
But considering what you wrote, i need a more reliable solution so i went back to 4.2.6 just to validate the correction as follows.

Capturing events to disable zoom on sub elements
The solution i found is to intercept the "mousedown" events as you suggested. This might help others, so here it is: chart.selectAll(".activable").on("mousedown", function() { d3.event.stopImmediatePropagation(); })
But, strangely, this works regardless of the order! If i call chart.call(zoomPanX) before or after this, it's the same, which is weird as i would expect the zoom to be disabled only if i capture the mousedown events before. So it works, but i can't really understand what's going on with the events...

How to completely disable the zoom on a sub element?
With this solution, the effect is that the mousedown does not trigger the pan. The click event is correctly triggered. But, when i release the button, the pan becomes effective from the point i first clicked! It's a bit hard to describe, but technically speaking, the stopImmediatePropagation on mousedown did not prevent completely the pan, and this regardless of the order of the callbacks. Logically, i thought that mouseup event could be used the same way, but it had no effect. In my case, it's not really annoying as it still works, but i suggest a guideline should be given on how to properly disable zoom on a sub element. Maybe there is something missing internally for doing this in an easier way.

The only change in 4.2.8 was fixing the reporting of transition interrupt events, and your code looks like it is using transitions, so perhaps it is related. (Also, the zoom behavior will initiate a transition by default on double-click to zoom in.)

It works regardless of order because the activable elements (chart.selectAll(".activable")) are descendants of the chart element (chart), and per the browser event propagation rules I linked previously, non-capturing listeners on descendant elements will receive events before non-capturing listeners on ancestor elements. The only time that order matters if you register the same type of listener (capturing or non-capturing) on the same element.

Sorry, but not sure I understand. If you prevent the zoom behavior from seeing the initial mousedown event, it won’t be listening for any subsequent mousemove and mouseup events, so I can’t see how anything would happen on mouseup.

Thank you again, your comments are very helpful. :+1:

To be sure, i removed all transitions and it is the same : with 4.2.8 the click events fire correctly although the zoom is active. I can't explain it.
That wasn't clear to me but now it is. Many things to be aware of, not easy to grasp it all if not coding such handlers at "low level".
Sorry for me, I don't manage to reproduce it and i may have misinterpreted the real effect of the click action as it now triggers correctly. The pan now seems totally disabled when intercepting mousedown as expected. Good!

@mbostock said:

If desired, you can also avoid the ambiguity by stopping propagation on mousedown on your clickable elements, such that you can only pan by clicking on the background of the chart.

I was curious about using this approach since I want people to be able to click points but also to be able to pan after dragging far enough. In my solution, the SVG is set up as follows:
<svg>
  <g>
    ... everything else ...
  </g>
</svg>

The zoom handler is attached to the <svg> node itself, so we listen for mouse events on the <g> tag to intercept before it reaches the zoom listener. In the code below this.svg refers to the d3-selected <svg> tag and this.svg.select('g') the d3-selected <g> tag.
The basic idea is to only propagate a mousedown event to the zoom listener if the mouse has moved far enough away from the mousedown point. In this example, the mouse must move 5 pixels (mouseMoveThreshold) before the zoom mousedown handler is called. Here's the code:
// setup special mouse handling to enable click instead of pan unless the mouse
// moves mouseMoveThreshold many pixels
let mouseDowned = false;
let mouseDownCoords;
let mouseDownEvent;

// Number of pixels a mouse needs to move before a drag is registered when
// the mousedown takes place on the highlight circle.
const mouseMoveThreshold = 5;

// note: it is important select a node that covers the whole mousedownable area
// but is beneath the node where the zoom is attached. In this case
// we have <svg><g>...</g></svg> and we attach the zoom to svg and this
// listener to the g.
this.svg.select('g')
  .on('mousedown.highlight', () => {
    mouseDowned = true;

    // create a copy of the mousedown event to propagate later if needed
    mouseDownEvent = new MouseEvent(d3.event.type, d3.event);

    // keep coords handy to check distance to see if mouse moved far enough
    mouseDownCoords = [mouseDownEvent.x, mouseDownEvent.y];

    // do not propagate this mousedown to zoom immediately
    // we will fake it with the mouseDownEvent if the mouse moves far enough.
    d3.event.stopPropagation();
  });

this.svg.on('mouseup.highlight click.highlight', () => {
  mouseDowned = false;
});

this.svg.on('mousemove.highlight', () => {
  // skip tracking mouse move if we didn't mousedown on the highlight item
  if (!mouseDowned) {
    return;
  }

  const mouse = [d3.event.x, d3.event.y];
  const distance = lineLength(mouse, mouseDownCoords);

  // we have reached a big enough distance to pass over to the zoom handler
  if (distance > mouseMoveThreshold) {
    mouseDowned = false;

    // dispatch original mouse down event to the zoom handler
    // note that here the mousedown event is dispatched directly on the
    // zoom element (this.svg), which bypasses our mousedown listener above.
    this.svg.node().dispatchEvent(mouseDownEvent);
  }
});

// setup zoom controls
this.zoom = d3.zoom()
  .scaleExtent([1, 10]) // min and max zoom scale amounts
  .translateExtent([[0, 0], [width, height]])
  .on('zoom', this.handleZoom);

this.svg.call(this.zoom);

// helper to compute length of a line (distance between two points)
function lineLength(a, b) {
  return Math.sqrt(Math.pow(a[0] - b[0], 2) + Math.pow(a[1] - b[1], 2));
}

we can get mouseXY  by  d3.mouse(theZoomNode)  in  handleZoom , then  dispatch event   or  pass to your handler  directly .

I would like to hook in on @pbeshai's preliminary citation.

If desired, you can also avoid the ambiguity...
What it might make it a bit easier, I am not having clickable objects, just hovering ones.
I have a world map and like to show country details via tool tips while still maintaining zoom & pan by d3js v4.
I am struggling with the exclusive thing where I can make the labels to show on countries but not pan & zoom on countries the same time. pan & zoom on the water (the background) is always possible, but not enough. Are there any directions with examples to solve this in way to have the ability to pan & zoom & show labels on countries and still to pan & zoom on the water?
The relevant code parts are below (will provide full function if required):

//enable pan and zoom
  svg.append("rect")
    .attr("width", width)
    .attr("height", height)
    .style("fill", "none")
    .style("pointer-events", "all")
    .call(d3.zoom()
      .scaleExtent([1 / 2, 4])
      .on("zoom", zoomed));

  function zoomed() {
     g.attr("transform", d3.event.transform);
  }

//do responsive and projection stuff here

<EMAIL_ADDRESS>function ready(error, world) {
          if (error) throw error;
        var country = g.selectAll('.country')
          .data(topojson.feature(world, world.objects.countries).features)
          .enter().append("g")
            .attr("class", "country");

        var tooltip = d3.select("body")
          .append("div")
          .style("position", "absolute")
          .style("z-index", "10")
          .style("visibility", "hidden")
          .style("background", "#eaf4fd")
          .style("padding", ".1em")
          .text("a simple tooltip");

        var wDat = #{fgView.worldPltdat}; //server side data injection

        wdArr = Object.keys(wDat).map(function ( key ) { return wDat[key]; });

        var dmMax = d3.max(wdArr, function(d) { return d; });
        var dmMin = d3.min(wdArr, function(d) { return d; });
        var colorScale = d3.scaleQuantile()
          .domain([dmMin, dmMax])
          .range(colors);

        country.append('path')
          .attr('d', path)  // re-project path data
          .attr("id", function(d) { return d.id; })
          .style("fill", function(d) {var cs = colorScale(wDat[i18nic.numericToAlpha3(d.id)]); return cs != null ? cs : 'oldlace';})
          .style("stroke", "#666")
          .style("stroke-width", ".015em")
          .on("mouseover", function(d){
            showCoLbl(d);
          })
          .on("mousemove", function(d) {
            showCoLbl(d);
          })
          .on("mouseout",  function(d) {
            tooltip.style("visibility", "hidden");
          });

        function showCoLbl(d) {
          tooltip.text(i18nic.numericToAlpha3(d.id) + " | " + Math.round(wDat[i18nic.numericToAlpha3(d.id)]) + " | " + i18nic.getName(d.id, "de"));
          tooltip.style("visibility", "visible")
            .style("top", (d3.event.pageY-10)+"px")
            .style("left",(d3.event.pageX+10)+"px");
        }
      });

I am curious why "if (!filter.apply(this, arguments)) return;" is not called on "touchmove" e and "touchend", etc. It is currently only called on "touchstart".
I am thinking this 'filter' function can be used to control the event propagation. Maybe I am missing something.

@namwkim The zoom.filter function only applies to events that can initiate a zoom gesture; it does not apply to events once the zoom gesture has already initiated. If you want to prevent other events from reaching the zoom behavior, you’ll need to capture them before they reach the zoom behavior and then call event.stopPropagation or event.stopImmediatePropagation.
If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.
Thank you! 🤗


Allow build using default configuration for VS2019

This is not optimal implementation, but at least it allow build
for those who do not have VS2017. If both VS2017 and VS2019 installed
VS2017 should be used.
Important assumptions which I made when build using VS2019

VC Toolset would be v14.2
Windows SDK would be 10.0.17763.0

Closes: #699

Wouldn't it be better to 1. keep the toolset on v141 (you can download it from VS2019's option page) and let people upgrade and 2. use vswhere to figure out the paths for VS2019 and VS2017? All this would mean is that they would have to start gradle from a developer command prompt then and they could just use either normally.

@chuggafan Being required to use the command prompt instead of PowerShell as I'm currently doing would be quite a big downgrade.

I in general agree with @chuggafan on the point that better keep vs141. I doubt that NSA want to maintain big matrix of options for building Ghidra. Other reason why I put vs142 is more selfish, I optimize for default VS 2019 setup which comes with vs142. Both options valid in my opinion.
I just want to hear Gidra's team opinion on the matter and change PR accordingly. Other thing which I think would be practical to improve, is make PlatfromToolset and WindowsTargetPlatformVersion configurable via Gradle properties. But that will require change how build of VS solutions happens. It will require invoking of MSBuild instead of devenv.exe. With devenv.exe hard to pass arguments to the build process, so better avoild that, but that change is really overkill for making project build in VS2019 as is.

I just talked to @ghidra1 about this.  We use Visual Studio 2017 because we are reliant on the Windows SDK 8.1 for building for Windows 7.  Upgrading to 2019 would require a more complicated set of instructions for getting this SDK, which has been removed from 2019.  At this time we do not think this complication adds enough benefit to our already complicated build, so we are not going to put in 2019 support into the main source repository.
People are of course welcome to tweak our build to fit their needs, so we can keep this open as a reference if you'd like.  I'm sure one day we will upgrade our default, but for now we are sticking with 2017.

Ok. Thanks for explanation. Just in case I want to mention that that current change implemented in such way that it does not require any changes in build for you (as far as I’m aware) and the only risk is that if you have both VS2017 and VS2019 installed on build server.
Also if it possible incorporate change with supported by NSA would be only VS2017 and VS2019 would be unofficial. If I understand this is maybe non-technical concern for you.
I raise these concerns since they are address your unwillingness to upgrade windows sdk from 8.1, and at the same time maintain community desire to have VS2019

We definitely want to stay up to date with what the community is using, but the other thing to consider is that if we accept a pull-request, we are taking on the responsibility of maintenance and testing, and unless we have a 2019 environment set up, we can't effectively do that.  I'm sure we will upgrade to the latest studio at some point, but we just aren't quite ready at this moment...we have too many other priorities going on.
We appreciate all pull-requests, but in general, I think ones involving the build will be the hardest for us to accept because they require us to change our environment, which can be a slow process.

Thanks again for response. Your perspective and reasoning very transparent for me. My question allow me receive response which clearly outline your limitations, and as such I can constrain myself on the working/resolving issues which are likely would not be accepted by Ghidra. Or I may decide to maintain my own fork with desired by me changes.

Thanks for understanding!  I am going to close this for now, but we'll use it as a reference when we eventually upgrade.

FYI for anyone searching who has VS2019 and wants to build this. You can simply change the string here: nativeBuildProperties.gradle
I know this is not a permanent fix and doesn't resolve multiple build configs, but if you have issues it is a simple local fix to build which I think is a good enough alternative for now.
Change this to 2019 if you are running 2019
project.ext.VISUAL_STUDIO_BASE_DIR = "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017"
Change this to Preview or Enterprise if you are running a non Pro version of VS
project.ext.VISUAL_STUDIO_INSTALL_DIR = project.ext.VISUAL_STUDIO_BASE_DIR + "\\Preview"

Here is the entirety of my local changes to enable using dev environment with vs2019 (I have "community" edition installed which is already supported), latest sdk, and bison/flex from WSL:
diff --git a/GPL/nativeBuildProperties.gradle b/GPL/nativeBuildProperties.gradle
index 2a4db4e6..b69c17b8 100644
--- a/GPL/nativeBuildProperties.gradle
+++ b/GPL/nativeBuildProperties.gradle
@@ -17,7 +17,7 @@ apply plugin: 'c'

 // Unclear if we can rely on the VisualCpp plugin to identify the correct Visual Studio paths

-project.ext.VISUAL_STUDIO_BASE_DIR = "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017"
+project.ext.VISUAL_STUDIO_BASE_DIR = "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019"
 project.ext.WINDOWS_KITS_DIR = "C:\\Program Files (x86)\\Windows Kits\\10"

 project.ext.VISUAL_STUDIO_INSTALL_DIR = "/"
diff --git a/Ghidra/Features/Decompiler/build.gradle b/Ghidra/Features/Decompiler/build.gradle
index a4f7130c..27402f12 100644
--- a/Ghidra/Features/Decompiler/build.gradle
+++ b/Ghidra/Features/Decompiler/build.gradle
@@ -461,7 +461,8 @@ Task createBisonTask(String filename, String binaryName, boolean qualifyVariable
                        file(outputHeadersDir)mkdirs()
                }

-               executable 'bison'                      // use bison program to process yacc files
+               executable 'ubuntu'                     // use bison program to process yacc files
+               args "run", "bison"

                // specify the bison's output file
                args "-o", "$outputCppDir/${filename}.tab.cc"
@@ -490,7 +491,8 @@ Task createLexTask(String filename, String binaryName) {
                String outputDir = "build/generated/${binaryName}/cpp"
                String inputFile = "src/decompile/cpp/${filename}.l"

-               executable 'flex'                       // the program to execute
+               executable 'ubuntu'                     // the program to execute
+               args "run", "flex"

                // set up inputs and outputs so that gradle knows when this needs to be rebuilt

diff --git a/Ghidra/Features/PDB/src/pdb/pdb.vcxproj b/Ghidra/Features/PDB/src/pdb/pdb.vcxproj
index d797613c..243ff49e 100644
--- a/Ghidra/Features/PDB/src/pdb/pdb.vcxproj
+++ b/Ghidra/Features/PDB/src/pdb/pdb.vcxproj
@@ -13,18 +13,18 @@
   <PropertyGroup Label="Globals">
     <ProjectGuid>{343E9778-3C04-476E-8F90-A114AA7AA108}</ProjectGuid>
     <Keyword>Win32Proj</Keyword>
-    <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
+    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
   </PropertyGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
     <ConfigurationType>Application</ConfigurationType>
     <UseDebugLibraries>true</UseDebugLibraries>
-    <PlatformToolset>v141</PlatformToolset>
+    <PlatformToolset>v142</PlatformToolset>
   </PropertyGroup>
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
     <ConfigurationType>Application</ConfigurationType>
     <UseDebugLibraries>false</UseDebugLibraries>
-    <PlatformToolset>v141</PlatformToolset>
+    <PlatformToolset>v142</PlatformToolset>
   </PropertyGroup>
   <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
   <ImportGroup Label="ExtensionSettings">

It would be nice if the main repo adopted some method to build with modern tooling (defaulting to whatever the core ghidra devs prefer is fine, of course).

@kant2002, I'd like to resurrect your work on this to try to get official 2019 support into Ghidra.  Would you mind rebasing on master and we can start to test things out?

No problem. If I do that, it's only by mistake. Let me restore it. Do you want support VS2019 ?

The goal is to support both 2017 and 2019.  We also still need to continue building with Windows SDK 8.1 so the PDB stuff can run in Windows 7.

We also need to support both VS2017 and VS2019 being installed at the same time.  Apparently this has confused Gradle in the past.  Not sure if that's still a problem.


fux scrubber texture/model and balance

hi, i guess this is already planned since the great work you are currently doing with textures, but it would be cool to revamp the flux scrub visuals since it doesn't fit with thaumcraft theme
also i wanted to give some suggestion about balancing, since flux is a big deal in thaumcraft:
-the ability to change rateo of flux and aura that delete each other
-the amount of item consumed per operation
-the time of the operation
also/alternatively, this can be something to integrate with thaumic augmentation: it might be a more complex machine that uses impetus and the item as a catalist to create a reaction for aura and flux to nullifie each other

flux scrubber will be overhauled in the future.
i'm not sure what you mean by "operation", which operation do you mean?
thank you for the suggestion.

ok, great!
operation was a generic way for: each consumption of salis mundus (if i remember correctly was salis mundus the item consumed, right?) that result in the removal of aura and flux
at least, this is how i guess the machine work


examples: Switch example deployment to use release tags

Discussion: https://github.com/coreos/container-linux-update-operator/pull/71#pullrequestreview-36907630, https://github.com/coreos/container-linux-update-operator/pull/70#pullrequestreview-35125422

Added to the bump-release script to update the manifest if you can review that again.


Global might be undefined and module breaks

to insure that global is present
When Importing via require in webpack global is undefined and module is unusable. Proposal to fix

webpack 1.12.2 – everything is fine. And the fix should be done in the global scope, imo, if it happens.

okay thanks


feat(api): fi and optimizer functionality integration

Why is this change necessary?

This change mirrors the addition of new requested functionality related to fiab and optimizer products

How does it address this issue?

[x] It utilizes the updated swagger document that was generated with the fi and optimizer change

Why is the change done this way?

Remain consistent with workflow

What side effects does this change have?

Side effects should be minimal

What testing was done to confirm this works?
Testing will happen when this PR generates various PR's on the various language's SDK repo

Closing in favor of requested changes in service API soon to be released.

Closing in favor of requested changes in service API soon to be released.


Deriving RollPass and ThreeRollPass from Common Base

As an idea to solve the issues that rose in #241
This is a breaking change, so at least new minor version.
For example the report breaks with this PR, because there is a check for RollPass only, which yields now results in 3RP only sequences.
This would also simplify future intro of multiple rolls as in #104

I believe there are still some places where RollPass needs to be changed to BaseRollPass.
One example i found:
https://github.com/pyroll-project/pyroll-core/blob/77e9edab877bc7b85434e66ae5b65f71795041af/pyroll/core/roll_pass/hookimpls/deformation_unit.py#L94-L96

I believe there are still some places where RollPass needs to be changed to BaseRollPass. One example i found:
https://github.com/pyroll-project/pyroll-core/blob/77e9edab877bc7b85434e66ae5b65f71795041af/pyroll/core/roll_pass/hookimpls/deformation_unit.py#L94-L96
Or am i understanding this wrong?

So you don't have to change all the references from RollPass to BaseRollPass as every RollPass is also a BaseRollPass.
In the case that you mentioned it is no problem. I just noticed, that when running the tests 2 fail to converge.

test_solve3 -> Seems to be an error in report due to the new Class
tests/roll_pass/test_roll_pass_profile_locations_disks.py -> I don't understand why this error never appeared before since hook and self don't match

Yes but previously this function was also able to be used by ThreeRollPasses, what is now no longer possible. So from my understanding these general functions should all specify BaseRollPass so that other more specific classes can use them aswell.

Yes but previously this function was also able to be used by ThreeRollPasses, what is now no longer possible. So from my understanding these general functions should all specify BaseRollPass so that other more specific classes can use them aswell.
PS: I also use this function in the zouhar-package for ThreeRollPasses which is where i noticed that for example.

Your right, I thought the hirachy was still BaseRollPass -> RollPass -> ThreeRollPass but now is BaseRollPass -> RollPass, BaseRollPass -> ThreeRollPass. So you can adjust those and commit.

test_solve3 -> Seems to be an error in report due to the new Class

This is why I said

For example the report breaks with this PR, because there is a check for RollPass only, which yields now results in 3RP only sequences.

@RichardPfr you are right with this hook. But this impl has nevertheless to be implemented on BaseRollPass, and not on DeformationUnit. So then the isinstance check is not necessary

The wrong place of this hook impl made me missing it.
I fixed, moved and simplified it.
@BaseRollPass.Profile.contact_lines
def contact_contour_lines(self: BaseRollPass.Profile):
    rp = self.roll_pass
    return [linemerge(cl.intersection(self.cross_section.exterior)) for cl in rp.contour_lines]

rebase


Fix typo in container registry domain

Hi Biometria-se/grizzly-cli!
This is not an automatic, 🤖-generated PR, as you can check in my GitHub profile, I work for GitHub and I am part of the GitHub Security Lab.
While performing a code search for container registry domains we noticed that this repo contains a misspelled domain name.
If a malicious actor were in control of that misspelled domain, they could potentially perform an attack on the software supply chain of this project and/or steal the credentials used to connect to the container registry (depending on how the misspelled domain name of the container registry is used - In some cases it's only a matter of wrongly tagged container images)
Please verify the changes made with this PR and check your documentation for similar typos.

Hey!
First off, really sorry I've missed this and thanks for bringing it to our attention. However, the misspelled registry domain is only in a unittest, that makes sure that an environment variable is set to the value of a supplied argument. There's no actual communication with any registry. I'll change it to something more random.


All-zero matrix when calculating IBP loss

Hi,
Thank you for sharing this awesome project! I have a problem when calculating the IBP loss with your code below.
  def neg_log_IBP(self, matrix, alpha=3.):
          matrix = torch.sigmoid(matrix)
          matrix_hard = (matrix > .5).float()
          matrix = matrix_hard - matrix.detach() + matrix

          N, _ = matrix.shape
          m = matrix.sum(dim=0)
          m = m[m.nonzero()].squeeze()
          K = len(m)
          def log_factorial(value):
              return torch.lgamma(value + 1)
          logp = 0.
          logp += K * math.log(alpha)

          for n in range(N):
              new_features = torch.clamp(matrix[n] - matrix.sum(0), min=0., max=1.).sum()
              logp -= log_factorial(new_features)

          logp -= alpha * sum([float(1) / i for i in range(1, N + 1)])
          logp += (log_factorial(N - m) + log_factorial(m - 1)).sum()
          logp -= special.gammaln(N + 1) * K
          return - logp

It seems after the thresholding, the resulting  m[m.nonzero()].squeeze() usually be an all-zero matrix. I have to manually set the value to torch.tensor(0.0) when all-zero matrix appears. I'm wondering have you observe similar behavior in your experiment or did I do something wrong with initialization? Will this affect the final trained skilled module performance?
Thank you!

+1
Hi @Yuzz1020, I have similar questions as well.  did you figure out the reason the answers to your questions? Thanks!

I have similar issue for len(m)
Traceback (most recent call last):
  File "/home/pouramini/polytropon/src/polytropon/polytropon.py", line 124, in <module>
    logger.warning("forward %s: %s", skilled_variant, skilled_model.forward(task_ids, labels=inputs["input_ids"], add_prior=True, **inputs))
  File "/home/pouramini/polytropon/src/polytropon/polytropon.py", line 78, in forward
    aux_loss = [self.neg_log_IBP(p) for n, p in self.model.named_parameters() if "skill_logits" in n]
  File "/home/pouramini/polytropon/src/polytropon/polytropon.py", line 78, in <listcomp>
    aux_loss = [self.neg_log_IBP(p) for n, p in self.model.named_parameters() if "skill_logits" in n]
  File "/home/pouramini/polytropon/src/polytropon/polytropon.py", line 94, in neg_log_IBP
    K = len(m)
  File "/home/pouramini/anaconda3/lib/python3.9/site-packages/torch/_tensor.py", line 705, in __len__
    raise TypeError("len() of a 0-d tensor")
TypeError: len() of a 0-d tensor

Hi all! I pushed a new version of neg_log_IBP which hopefully should be more robust. A few notes:

having a full-zero matrix is weird, because the auxiliary loss discourages that. There are two differentiable terms, the first one encourages the columns of Z to be unique (so a full-zero matrix is penalised).
@puraminy which version of Pytorch are you using? In my version, the length of an empty (0-d) tensor is 0, so it should not throw an error.

Thank you for your attention, I use:
torch==1.12.0
torchaudio==0.12.0
torchvision==0.13.0

I tried to put it in try block:
      try:
            K = len(m)
        except:
            K = 0

I am have
torch==1.12.1
and cannot replicate your error.

By using your latest code, the problem was resolved, and currently I can't reproduce it ... Also, I used my local t5-base (Maybe it had a role).
I'm reading your paper to understand what your code does. Because I had a similar idea for generation using T5. However, I currently don't know what your example code (at the end of file does). I decoded the generated token ids, and they are part of the same inputs.
I read more, but you may explain the example or guide me in future how can I use your code to restrict generation with T5


[BugFix] Fix the NPE and enable oss fileIO interface while reading paimon

Why I'm doing:
What I'm doing:
Fixes #36294
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

@mergify backport branch-3.2


iOS requires NSCalendarsUsageDescription - Should be fixed in newer permissions plugin

Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[x] iOS
[] Android
[] UWP
[] .NET Standard

Version of OS(s) listed above with issue
14.1
Version of Library
1.0.0
Expected Behaviour
Should not require any unnecessary permissions
Actual Behavior
When uploading to app store get this error:
ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSCalendarsUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).
It looks like the problem is in the older Plugin.Permissions
https://github.com/jamesmontemagno/PermissionsPlugin/issues/112
I have added the newer version to the solution Plugin.Permissions 6.0.1 but still get same error. It looks like some methods may be depreciated that this plugin is using.
Code of Conduct

No Library Update Requests
No Timeline Requests
Please read through the documentation and FAQs
Please be respectful of my time. I put a lot of effort into my libraries.  I try to support the issue requests within a day.  I'm not psychic, so please take the time to fill out the above form as complete as possible

I'm sorry but this plugin is long been closed as per the readme.  I forgot to close the issues.


NTR:PMID:29641590

PMID:29641590
refers to
increased 23S ribosome assemlby
increased 22S ribosome assembly
abnormal pre40S ribosome assembly
normal 90S ribosome asembly
I could not find equivalents for these in GO, so I am not sure what they mean?
also need abolished 20S rRNA precursor level

increased 23S ribosome assembly
increased 22S ribosome assembly

From a look at the paper, I think 22S and 23S are rRNA processing intermediates, not ribosomes or pre-ribosomes. I can therefore add 'increased RNA level' terms for them.

abnormal pre40S ribosome assembly
normal 90S ribosome assembly
I could not find equivalents for these in GO, so I am not sure what they mean?

GO has mostly kept S values in narrow synonyms for their ribosome-related BP and CC terms (although there are "90S preribosome" terms). That makes sense because of some variations from the most typical values in some taxa.
It's pretty clear that the "pre-40S ribosome"* is a small subunit precursor, but I don't know whether 40S assembly is exactly the same as "ribosomal small subunit assembly" (GO:0000028) or more specific.
*any idea why it's that way round instead of "40S preribosome"?

also need abolished 20S rRNA precursor level

I can add '20S rRNA precursor absent from cell'. It makes no sense in English to say a substance (as opposed to a function or process) is "abolished".

increased 23S rRNA precursor level FYPO:0007063
increased 22S rRNA precursor level FYPO:0007064
20S rRNA precursor absent from cell FYPO:0007065
normal 90S preribosome assembly FYPO:0007066
edit file: 114cdf13de728d46a2edc8df48ad44e699753af4
release: f39d67cf78a0e54b72f8640494fba5de2839405c

For this one

abnormal pre40S ribosome assembly

Let me know whether you prefer to add "abnormal ribosomal small subunit assembly" (xp using GO:0000028, and a synonym with the 40S value), or a 40S-specific term without a logical def.

abnormal ribosomal small subunit assembly
will do...

OK, it's in, with some narrow synonyms
abnormal ribosomal small subunit assembly FYPO:0007069
edit file: acdfbfe9b718918abefdb3028b88da2a593d5599
release: 5ad6d1599f99294af45bb7b7b41421872e81e194


Unexpected reserved word

Hi, I installed with the npm command (got the warning below)
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '>=14' },
npm WARN EBADENGINE   current: { node: 'v12.22.9', npm: '8.5.1' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '>=14' },
npm WARN EBADENGINE   current: { node: 'v12.22.9', npm: '8.5.1' }
npm WARN EBADENGINE }
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '<EMAIL_ADDRESS>npm WARN EBADENGINE   required: { node: '>=14' },
npm WARN EBADENGINE   current: { node: 'v12.22.9', npm: '8.5.1' }
npm WARN EBADENGINE }
npm WARN deprecated<EMAIL_ADDRESS>Please use another csrf package
I ran this command, from your example with changed directory):
fz-browse --run $'find -E ~/downloads -iregex ".*.(jpg|gif|png|jpeg)$" -print0 | xargs -0 exiftool -q -m -p '$Directory/$Filename  $DateTimeOriginal  $Comment' | grep {input} | awk '{print $1}'' --preview "echo {target}"
file:///usr/local/lib/node_modules/fz-browse/cli.mjs:66
const server = await createServer({
^^^^^
SyntaxError: Unexpected reserved word
at Loader.moduleStrategy (internal/modules/esm/translators.js:133:18)
at async link (internal/modules/esm/module_job.js:42:21)

updating node according to https://www.freecodecamp.org/news/how-to-update-node-and-npm-to-the-latest-version/ got me a bit further, fz-browser start and displays an URL, the URL displays:
Error: Cannot find module 'history'
Require stack:

/usr/local/lib/node_modules/fz-browse/dist/server/entry-server.js
at Module._resolveFilename (node:internal/modules/cjs/loader:1090:15)
at Module._load (node:internal/modules/cjs/loader:934:27)
at Module.require (node:internal/modules/cjs/loader:1157:19)
at require (node:internal/modules/helpers:119:18)
at Module. (/usr/local/lib/node_modules/fz-browse/dist/server/entry-server.js:29:15)
at Module._compile (node:internal/modules/cjs/loader:1275:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1329:10)
at Module.load (node:internal/modules/cjs/loader:1133:32)
at Module._load (node:internal/modules/cjs/loader:972:12)
at ModuleWrap. (node:internal/modules/esm/translators:168:29)

npm WARN EBADENGINE current: { node: 'v12.22.9', npm: '8.5.1' }

It looks like your node.js is old.
Can you use Node.js 18+?

Error: Cannot find module 'history'

https://github.com/azu/fz-browse/blob/d9a22750ee6a1f2bb986bef838258eb62fb640be/package.json history is mising.
It

Do you have a fix and want me to test?

fixed in v1.0.3
Can you try it?

I re-installed it by running sudo npm install --global fz-browse
It starts OK, serves a page but the only thing it displays is "hit: 0/0"
I'm going to update nodejs, it's 12.xxx right now and get back to you.

node -v : v19.7.0
nodejs -v: v12.22.9 (latest package on ubuntu)
then I'm no js dev so I have no idea of what to do next to bring the environment to latest, any hint?


Issue when opening a shared keepass file in gdrive

User A shares a keepass file with user B in gdrive and user B creates a shortcut to this shared keepass file.
When user B tries to open this shared keepass file with KeeAnywhere, user B get's the following error.

please fix this
:(


The changes merged in the PR is not live in production

The PR, https://github.com/decentralized-identity/didcomm.org/pull/69, is merged with the main, but it doesn't seem to be available in production at https://didcomm.org/
Looks like some build errors for most.

Fixed in PR #82


[Recommendation] Add GuiType.ANVIL

I think we can agree that anvils are a requirement for the trimuph gui system, now I don't know if there's an existing branch that works on that issue/recommendation, but I I would like to see if there is any possible ways to patch this in, since using Bukkits Inventory management is completely useless once your use this gui lib.

I really would like this as well!


Option to configure ecosystem for testnet

lbrycrd --testnet | --regtest
lbrynet:

daemon-settings.yml: blockchain_name: lbrycrd_testnet

chainquery: blockchain name is currently hardcoded according to Jack.

There are a number of big changes for --testnet and --regtest which should be discussed with @tiger5226 and possibly @jessopb as I've merged in the Refactor branch @tiger5226's independent container files into the main Dockerfile for lbrycrd such that there's simply an environment variable and a few lines of code in the start.sh for the RUN_MODE=testnet and RUN_MODE=regtest.

This feature and branch cannot be merged without @tiger5226 and #61

https://github.com/lbryio/chainquery/blob/master/e2e/e2e.sh needs updated to use the new compose files.

tested updating last night and was unsuccessful
OCI runtime exec failed: exec failed: container_linux.go:344: starting container process caused "process_linux.go:91: executing setns process caused \"exit status 21\"": unknown

@Leopere is aware


Not sure how this works..

Hello,
I just installed all the requirements for this. ran the code and only really got to the part where it opens chrome, goes to the discord website and then it closes again. Can you help me out with this please? I haven't really done any coding stuff before.
thanks!

Hello,
I just installed all the requirements for this. ran the code and only really got to the part where it opens chrome, goes to the discord website and then it closes again. Can you help me out with this please? I haven't really done any coding stuff before.
thanks!

To make sure people don't accidentally delete all their friends I have added a isTest variable. Please change this to false in file /src/Discord.py and run it again.


Problem in GPGSA Sentence

if i create a new GPGSA sentence, the Fix Indicator is always on NOFIX, no matter what is given to the Constructor
        var sateliteList = new List<Satellite>
        {
            new Satellite(19, new Azimuth(30.3), new Elevation(10.5), new SignalToNoiseRatio(50), true),
            new Satellite(28, new Azimuth(40.3), new Elevation(70.4), new SignalToNoiseRatio(50), true),
            new Satellite(14, new Azimuth(50.3), new Elevation(40.2), new SignalToNoiseRatio(50), true),
            new Satellite(18, new Azimuth(60.3), new Elevation(30.6), new SignalToNoiseRatio(50), true),
            new Satellite(27, new Azimuth(160.3), new Elevation(70.0), new SignalToNoiseRatio(50), true),
            new Satellite(22, new Azimuth(260.3), new Elevation(70.0), new SignalToNoiseRatio(50), true),
            new Satellite(31, new Azimuth(200.3), new Elevation(90.3), new SignalToNoiseRatio(50), true),
            new Satellite(39, new Azimuth(10.3), new Elevation(20.3), new SignalToNoiseRatio(50), true),
            new Satellite(24, new Azimuth(5.3), new Elevation(40.7), new SignalToNoiseRatio(50), true)
        };

        var gpsGPGSA = new GpgsaSentence(FixMode.Manual, FixMethod.Fix3D,
            sateliteList ,
            new DilutionOfPrecision((float) 1.2), new DilutionOfPrecision((float) 1.2),
            new DilutionOfPrecision((float) 1.2));

the value of the sentence is like this:
"$GPGSA,A,1,19,28,14,18,27,22,31,39,24,,,,1.2,1.2,1.2*36"
what am I doing wrong?

Hi.
This is only a code mirror. Please ask at codeplex for help. I'm not a dotspatial developer. Sorry.
Regards
Michael


Unbuntu apt-get and plugins gives wrong version of jenkins

So after a week of fighting with the code i realized that jenkins was installing at the wrong version when i use a plugin hash.
When installing jenkins on unbuntu 12 using this code it works fine, also when you add in the plugins one by one it works, but when you switch to hiera and use a plugin hash the wrong version of jira gets installed.  I new jira did not look right but it took me a week of focusing on the dam plugins not working to give up and start with the basics lol my bad!!!!!
if you add this to debian.pp file after the source it fixed it for me. Tbis is a common fix for debian it forces the apt-update at the correct location.
->
Exec['apt_update'] -> Package['jenkins']

Duplicate of #453


Paginate calls to fetch more events

Currently the events are requested from relays in getEventsOfEvent
The information from relays will be limited to what can fit in the stream. Most relays cap at no more than 500 events per subscription.  To ensure fuller coverage of events, it may be prudent to paginate through from a desired starting point (the created_at of the event being referenced) and use since/until fields in the filter to get a range of selected events.

Events are now fetched by time ranges, and cycled. closing.


Add ERC: Unified Token

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

Here is the discussion incase someone is wondering:

Also suggestion using _ as parameter prefix for function input params:
tokenId -> _tokenId, amount -> _amount etc
While this could be done after major modifications


Render the rest of the A-Frame Scene outside the MindAR Target

TLDR: Is there a way to render the rest of the scene outside of the MindAR target?
I know that is stated in the documentation that:

Remember this. The AR engine only does ONE thing! - It updates the visibility and positions of a-entity

But I think that being able to explore the rest of the scene using the Magic Window while interacting with the marker's positions is something that enhances a lot of augmented reality experiences.
In AR.js, this is currently possible, but the positions of the objects anchored to the marker get an offset. There are things that can be worked around, but the thing stopping me from using AR.js is that I don't know how to pause the AR.js engine in order to use the camera for other things, as it is possible in MindAR.

I tried placing objects outside the MindAR target, but they are automatically hidden. Here's the behavior I would like to achieve:

Start scanning.
When the image target is found, capture the anchor.
Keep the objects visible (using only sensors like the gyroscope, etc.) even when the target is lost.

@dariocavada This is exactly what I wanted to do. I basically just want to use the image tracking to initialize the camera location in a virtual scene. The user can then look around, assuming the camera stays in the same place. I kinda, almost got this working with this:
      const target = document.querySelector(".ar-target");
      target.addEventListener("targetFound", event => {
        setTimeout(() => {
          var upsideDown = document.querySelector(".upside-down")

          var targetPosition = new THREE.Vector3();
          var targetOrientation = new THREE.Quaternion();
          target.object3D.getWorldPosition(targetPosition);
          target.object3D.getWorldQuaternion(targetOrientation);

          upsideDown.object3D.setRotationFromQuaternion(targetOrientation);
          upsideDown.object3D.position.x = targetPosition.x / 1000;
          upsideDown.object3D.position.y = targetPosition.y / 1000;
          upsideDown.object3D.position.z = targetPosition.z / 1000;
          camera.components.camera.camera.near = 0.1;
          camera.components.camera.camera.updateProjectionMatrix();
        }, 100);

        console.log("Pausing tracking... ");
        camera.setAttribute("look-controls", "enabled", true);
        mindarSystem.pause(true);
      });

The tricky parts that took me a bit to figure out:

The position coordinates are divided by 1000. Apparently the anchor is in mm and the aframe scene in m.
I needed to add a small delay before copying the target pose.
I needed to change the camera near clipping plane. MindAR sets it to 10 which is way to far for my scene.

This still does not work properly. The virtual scene is not close to staying in sync with the physical scene when using the look-controls.
I would be very grateful if anyone has suggestions to get this working.


updated the dashboard to the latest metrics

https://github.com/tobbez/deluge_exporter migrated to be compatible with deluge2, so there was some metric name changes. I fixed them (and also the load/change/export added some new fields and bumped the schema version.)

Thank you! I changed the bandwidth interval to 5m but it's ok.


 Not sure what the problem is, but this may help someone else.

Thanks for the update. The simple is actually needed for older <2.0 versions (around 1.7).


Add example for pinia-plugin-persistedstate

Add example for pinia-plugin-persistedstate
pinia-plugin-persistedstate is maintained and used more than pinia-plugin-persist
https://npmtrends.com/pinia-plugin-persist-vs-pinia-plugin-persistedstate
(untested.. something like?)
import { defineStore } from 'pinia'
import { encryptStorage } from 'path/to/encryptStorage';

export const useStore = defineStore('store', {
  state: () => ({
    return: {
      first: 'John',
      last: 'Doe',
      accessToken: 'xxxxxxxxxxxxx'.
    },
  }),
  persist: {
    storage: encryptStorage,
    paths: ['accessToken'],
  },
})

Hello @shadowbq ,
let me put it in the examples.
Thank you very much

The rehydration of the pinia-plugin-persistedstate does not work with encrypt-storage.


Compiler Error: Stack Overflow

The following code made the compiler stack overflow. If you uncomment the types, you get some errors about how the last function has a wrong type signature. But, these type annotations seem to throw the compiler into a nasty loop. Unfortunately, I have no idea what went wrong here.
type alias Vector =
  { x : Float
  , y : Float
  }

type alias Position =
  { position : Vector }

setX : (a -> a) -> { b | x : a } -> { b | x : a }
setX update record =
  { record | x <- update record.x }

setPosition : (a -> a) -> { b | position : a } -> { b | position : a }
setPosition update record =
  { record | position <- update record.position }

setXPosition : (Float -> Float) -> Vector -> Vector
setXPosition =
  setPosition (setX .position)

yields the error
COMPILER ERRORjump to error
Looks like you ran into an issue with the compiler!
It crashed with the following message:

stack overflow

Maybe it was <https://github.com/elm-lang/elm-compiler/issues/832>

If not, try to find it at <https://github.com/elm-lang/elm-compiler/issues>
and open a new issue if it seems like you found an unknown bug.

The error points to this issue about infinite types not being detected. I have no idea if this is a question of infinite types. If it is, please feel free to close this issue.

@evancz :neckbeard:

I get notified for all issues already, no need to ping me.
It is either #832 or it is #656. Can you figure out which one so we can close this? If possible maybe the code to get the error can be shrunk down to be another example case.

I'm gonna guess it is #832 and we'll revisit it when we fix that one, thanks for the report!


Multiple-user tutorial

Hello,
Thank you for the great app. I am able to set-up git with dropbox for myself using the README and wiki tutorial. But I wonder if you could create a tutorial for multi-use case. The reason I asked is because I am not sure how I can share the dropbox remote repository with a colleague. Right now, the remote repository is under Dropbox/Apps/my-app/project/. Should we just share the project folder with another people?
Thanks!
Jincheng

Yes, just share the project folder, and have the collaborators access it using git-remote-dropbox as well.

I'd remind the people you share it with that they shouldn't let the Dropbox desktop app sync the repo directory. I've never tried using this to collaborate on a repo with other people... interesting to know that this is even recommended.

Not just recommended, it's what git-remote-dropbox was designed for :)

After adding the remote, you can treat it just like a regular Git remote. The Dropbox-backed remote supports all operations that regular remotes support, and it provides identical guarantees in terms of atomicity even when there are concurrent operations, even when using a shared folder.

Thanks @echuber2 and @anishathalye ! I think this is where it is getting quite confusing. Let me explain:
(1) In order to use git-remote-dropbox, we need to request an API access to Dropbox. Basically one will create a personal connected app to Dropbox (in my case the app name is jw-git). When we git remote add origin "dropbox:///path/to/repo", it actually add the repo under Dropbox/Apps/jw-git/repo. In other word, it is under the personal app directory I created. Would that be a problem if I share a folder under my personal app directory? Would my colleague be able to push or pull from that folder?
(2) For my colleague, again in order to use git-remote-dropbox, he/she will create a personal connected app to Dropbox. But since the repo is under my app, it seems that the step of creating his/her own app is not necessary.
(3) For git to the Dropbox remote, I have to use my token for that personal app, but how my colleague will be able to pull or push to it if he/she doesn't have my token, or should I share the token with him/her as well?
In the end, people may wonder, why don't you just use github/bitbucket to do this. The main reason for me is that I am a biologist who is analyzing some sequencing data. I am trying to use version control because there are a lot of back-and-forth with how the data should be analyzed, and I don't want to create a million different copies of my analysis code. Meanwhile, analyzing sequencing data would generate intermediate and output files (e.g. dataset or figures) that are too big and many to sync with github server. I really don't see a good solution for this kind of niche applications.
Thanks!

I suppose Anish will answer too and I don't want to take up a lot of space here, but this is what I do. I created a folder in my Dropbox account called gitsafe which is where I put all repos. Then, I explicitly mark gitsafe as not synced by the Dropbox app on any computer I have, using the selective sync feature. So the gitsafe directory does not show up in my Dropbox folder under my home directory locally. However, the git-remote-dropbox program can still use these remotes on the Dropbox server through my account token. Since all of the remotes I create are under gitsafe, I only had to deal with selective sync once per machine I set up initially (to mark gitsafe not-synced).
Your colleague would have to accept the share of the repo folder, mark it not synced in the Dropbox desktop app, and then interact with it only as a git remote. Since the folder is shared with your colleague's Dropbox account, your colleague can use their own credentials to interact with it. Do not give them your credential token. I'm pretty sure that's a huge security risk to your account.
I do think you could use plain old GitHub or etc. for this, though. Git itself has weaknesses for large binary data regardless of your hosting solution, even using this app. For that reason there is git-lfs:
https://git-lfs.github.com/
But this costs a surcharge to use on GitHub so that may be a good reason to use the Dropbox solution. I haven't looked at how the price scales competitively.
Also, you can use .gitignore files to mark all those intermediate and temporary files not tracked by git at all.

Thanks @echuber2 ! This makes a lot of sense. And I guess to use the gitsafe  solution, I would need to select that "Full Dropbox" access instead of "App Folder", and so would my colleague.
And thank you very much for your suggestions related to git-lfs. I'll check it out. At this moment, as long as the git-remote-dropbox solution works for me, I'll stick with dropbox because I have nearly 1 TB data/files synced with dropbox now. Meanwhile, I do hope dropbox would provide better solutions because I think all the infrastructure are there (Dropbox version history).
Thanks!

Yes, just share the project folder, and have the collaborators access it using git-remote-dropbox as well. They'll have to create their own token. The path might also look different for them (wherever the shared folder appears for them in their Dropbox).

"They'll have to create their own token": do you mean they need to go and create their own dropbox app and generate a token?

Yes, just share the project folder, and have the collaborators access it using git-remote-dropbox as well. They'll have to create their own token. The path might also look different for them (wherever the shared folder appears for them in their Dropbox).

"They'll have to create their own token": do you mean they need to go and create their own dropbox app and generate a token?

"They'll have to create their own token": do you mean they need to go and create their own dropbox app and generate a token?

Yes, that is correct.

"They'll have to create their own token": do you mean they need to go and create their own dropbox app and generate a token?

Yes, that is correct.

Fixed by #98.


After installing v0.5.0, the "dce version" still shows up as v0.4.0

Version

DCE CLI v0.4.0
Darwin C02XC78CJGH5 17.7.0 Darwin Kernel Version 17.7.0: Sun Jun  2 20:31:42 PDT 2019; root:xnu-4570.71.46~1/RELEASE_X86_64 x86_64
go version go1.14.2 darwin/amd64
Terraform v0.12.20

Describe the bug
Trying to upgrade v0.4.0 to v0.5.0.
When installing DCE CLI with version 0.5.0, the dce version in terminal still appears as 0.4.0.
To Reproduce
Steps to reproduce the behavior:

When I type this Command, I get the following output

Download the zip file
wget https://github.com/Optum/dce-cli/releases/download/v0.5.0/dce_darwin_amd64.zip
Unzip to a directory on your path
unzip dce_darwin_amd64.zip -d /usr/local/bin
    ~ dce version     **0.4.0**
Expected behavior
Version should be 0.5.0 but shows 0.4.0

I think this occurred because "0.5.0" was built on somebody's developer machine before the 0.5.0 tag was created or their local repository was missing the tag: https://github.com/Optum/dce-cli/blob/3aa9d1b4db7284abb3d37d429a6ed6f64d9218cb/Makefile#L1

I think this occurred because "0.5.0" was built on somebody's developer machine before the 0.5.0 tag was created or their local repository was missing the tag: https://github.com/Optum/dce-cli/blob/3aa9d1b4db7284abb3d37d429a6ed6f64d9218cb/Makefile#L1

My suggestion for this fix would be to make sure the builds that get uploaded to GitHub or whatever come from a CI/CD server that builds when a tag is pushed. Discipline that and this is closed.

My suggestion for this fix would be to make sure the builds that get uploaded to GitHub or whatever come from a CI/CD server that builds when a tag is pushed. Discipline that and this is closed.


AnalyticalListPage

Info/docu:

https://pages.github.tools.sap/CPES/CPAppDevelopment-dev/Analytics-Setup-Use/
https://github.com/SAP-samples/fiori-elements-opensap/blob/main/week3/unit1.md
https://ui5.sap.com/#/topic/2a9df06673d34f72b238549d49da8bfb
https://github.tools.sap/fiori-elements/feature-showcase
https://ui5.sap.com/#/topic/d80a360638ad4cf193cc55eee92bff2e
https://wiki.one.int.sap/wiki/display/fioritech/Table+-+using+analytical+table+type

Hi @stewsk ,
thank you for this example. Maybe you have some tips in Analytical List Page fails with Error: adding element with duplicate id for OData V4 endpoint how I can get my ALP working.
Best Regards
Gregor

Test error is/was due to "odata_new_parser": true

The "Fiori Application Generator" in VS Code generated some files that same to be unnecessary for a CAP app (and which are not present in the travel_processor app):

webapp/annotations/annotation.xml
webapp/localService/metadata.xml
webapp/manifest_all_json

I have removed these files with commit https://github.com/SAP-samples/cap-sflight/pull/302/commits/ee4d86931c10c7fffed8a8b8abc4df65141165ee
@c-kobo @stefan0816 : can you verify that removing these files is ok? If they are indeed unnecessary, can the "Fiori App Generator" be adapted to not generate these files in the first place?

looks good from runtime side.
I wonder why the UI Tests fail...

I wonder why the UI Tests fail...

The tests are unstable. That would be a topic for our next sync.


API improvement proposal

I have the following proposal for a slightly API change.
The expression:
thing = Optional.of(some_func_may_return_none()).get_or_default('23')

could be written in a shorter way like
thing = Optional(some_func_may_return_none()).get('23')

Another idea is, to rename the class to Opt to prevent confusion with the builtin type Optional. So the final expression would be (by default):
from optional import Opt
thing = Opt(some_func_may_return_none()).get('23')

I've integrated this here: https://github.com/mreiche/python-streams


Block rotations randomly shuffle

Seems to happen randomly, waiting randomly causes it to happen
Possible solution would be to have the block rotations depending on the current block position relative to the chunk or something so that they're fixed but still safe

which mode do you have enabled? "No Rotations" or "Secure Random"?

Secure Random, this doesn't happen with No Rotations, only Secure Random because it generates a different value for the same blocks each time

yeah this is the intended behavior then.
A consistent function could be reversed. Even knowing just relative position in the chunk is information that could possibly be useful for attackers.
I'm open to suggestions but i can't think of any good solutions

perhaps a hash with the chunk coordinate and a random hash that is unique to each game instance? (i.e randomly generated upon the game starting)

i added a new "random offset" mode https://github.com/rfresh2/NoTextureRotations/commit/18855a38d1eac032df65c4d70df430742e0795bd
a new random offset is generated on every game launch.
however, if you were to reveal the coordinates of block rotations/offsets during the game session it is possible to reverse the offset.  i've added a note to the setting description regarding this.
but anyway this should get you the behavior you were wanting

Looks good, I suppose I can close this issue now


mediainfo-gui: 24.04 -> 24.06

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/mediainfo/versions.
meta.description for mediainfo-gui is: Supplies technical and tag information about a video or audio file (GUI version)
meta.homepage for mediainfo-gui is: https://mediaarea.net/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 24.06 with grep in /nix/store/rvs7ixcibrpyfjdp3y3alzmx52yrdq8x-mediainfo-gui-24.06
found 24.06 in filename of file in /nix/store/rvs7ixcibrpyfjdp3y3alzmx52yrdq8x-mediainfo-gui-24.06

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

mediainfo-gui

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rvs7ixcibrpyfjdp3y3alzmx52yrdq8x-mediainfo-gui-24.06 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A mediainfo-gui https://github.com/r-ryantm/nixpkgs/archive/6091c2a39648b59c7c10cb2d2cd722c39260be17.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/6091c2a39648b59c7c10cb2d2cd722c39260be17#mediainfo-gui

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rvs7ixcibrpyfjdp3y3alzmx52yrdq8x-mediainfo-gui-24.06
ls -la /nix/store/rvs7ixcibrpyfjdp3y3alzmx52yrdq8x-mediainfo-gui-24.06/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

mediainfo-gui

Maintainer pings
cc @devhell for testing.

Result of nixpkgs-review pr 324208 run on x86_64-linux 1

1 package built:

mediainfo-gui


[BUG] Pods using xfs filesystem fails with health check

Describe the bug
Pods using Storage class with fstype: xfs fails CrashLoopBackOff
To Reproduce
Steps to reproduce the behavior:
Create Storage class with fstype: xfs
Create pvc
Create pod to use the pvc
Expected behavior
Pods should be in running state and mountpoint should be accessible
Log
Events:
  Type     Reason                  Age                     From                      Message
  ----     ------                  ----                    ----                      -------
  Warning  FailedScheduling        <unknown>               default-scheduler         running "VolumeBinding" filter plugin for pod "mysql-868cbbc584-2m22v": pod has unbound immediate PersistentVolumeClaims
  Warning  FailedScheduling        <unknown>               default-scheduler         running "VolumeBinding" filter plugin for pod "mysql-868cbbc584-2m22v": pod has unbound immediate PersistentVolumeClaims
  Normal   Scheduled               <unknown>               default-scheduler         Successfully assigned default/mysql-868cbbc584-2m22v to ip-172-31-3-136
  Normal   SuccessfulAttachVolume  3m56s                   attachdetach-controller   AttachVolume.Attach succeeded for volume "pvc-7b0baf16-778e-46a9-a14a-2fc3a2e94b8b"
  Normal   Killing                 2m52s (x3 over 3m32s)   kubelet, ip-172-31-3-136  Container mysql failed liveness probe, will be restarted
  Normal   Pulled                  2m50s (x4 over 3m51s)   kubelet, ip-172-31-3-136  Container image "mysql:5.6" already present on machine
  Normal   Created                 2m50s (x4 over 3m51s)   kubelet, ip-172-31-3-136  Created container mysql
  Normal   Started                 2m50s (x4 over 3m51s)   kubelet, ip-172-31-3-136  Started container mysql
  Warning  Unhealthy               2m42s (x10 over 3m42s)  kubelet, ip-172-31-3-136  Liveness probe failed: ls: cannot access '/var/lib/mysql/lost+found': No such file or directory

Environment:

Longhorn version: 0.8.1
Kubernetes version: 1.18.2, k3s v1.18.2-rc2+k3s1
Node OS type and version: Ubuntu 18.04

Additional context
Liveness:       exec [ls /var/lib/mysql/lost+found]

We need to find a way to check XFS's availability since it doesn't have lost+found.
Also, let's check if ls /<data-dir> works.

@ShylajaDevadiga thanks for providing the information about reproducing this issue.
After discuss with @yasker, since we don't support xfs filesystem auto re-mount in Longhorn. So we don't need the livenessprobe to trigger pod restarting and trigger longhorn to re-mount the volume.
Please refer to this document:
https://longhorn.io/docs/0.8.1/high-availability/recover-volume/
Thanks,
Bo


Update to work with Hadoop 2.7.1

Update to work with Hadoop 2.7.1

Thanks! Merged into master, 14f298d3.


feat(SQS): State streaming integration POC (ADR-003)

Closes: #XXX
What is the purpose of the change
This shows a working prototype of utilizing state-streaming wiring to detect what pools were changed within a block so that we can push only the affected pools.
The ADR can be found here

This was merged to main in https://github.com/osmosis-labs/osmosis/pull/7879


Update specifications to accommodate image-spec/v1.1.0

https://github.com/opencontainers/image-spec/releases/tag/v1.1.0

I think we can use this issue to update signature specification to cover the following:

OCI signature storage per OCI image spec v1.1
Signature discovery per OCI distribution spec v1.1


:loudspeaker: Kairos release v2.0.0-alpha1

🗺 What's left for release

[ ]

🔦 Highlights
Alpha release to test immucore
✅ Release Checklist

[ ] Stage 0 - Finishing Touches

[ ] Check kairos/packages, and for any needed update
[ ] Make sure CI tests are passing.
[ ] Consider cutting an rc, alpha, ... based on changes on the CI

[ ] Stage 1 - Manual testing

How: Using the assets from master, make sure that test scenarios not covered by automatic tests are passing, and that docs are still aligned

[ ] Fedora flavor install, and manual upgrade works
[ ] ARM images (openSUSE, alpine) boots and manual upgrade works

[ ] Stage 3 - Release

[ ] Tag the release on master.

[ ] Stage 4 - Update provider-kairos

[ ] Update go mod to consume kairos-io/kairos.
[ ] Check if any changes on the pipelines and building pieces are required

[ ] Flavor changes
[ ] osbuilder version bumps

[ ] Update the CORE_VERSION file of kairos-io/provider to match the release tag of kairos-io/kairos
[ ] Tag the release on provider-kairos

[ ] Stage 5 - Announcement

[ ] Blog post announcement

cc @mudler I consider all pending tasks for immucore to be minor things:

https://github.com/kairos-io/kairos/issues/919 happens already without immucore so its not a critical issue.
https://github.com/kairos-io/kairos/issues/922 After a quick look, doesnt look that there is much room for improvement here, most mounts are ok.
https://github.com/kairos-io/kairos/issues/163 not in scope for 2.0.0-alpha
https://github.com/kairos-io/kairos/issues/997 very recent, not in scope for 2.0.0-alpha

So it should be ok to cut the alpha from the immucore point of view.

Crap, as soon as I say that, a build from master with immucore from master does not work lol

Needs - https://github.com/kairos-io/packages/pull/144
Needs - https://github.com/kairos-io/kairos/pull/1088/
Needs - Kairos repo bump to pick immucore version 0.13

lots of failures in here! https://github.com/kairos-io/kairos/actions/runs/4386811283/jobs/7681367639

lots of failures in here! kairos-io/kairos/actions/runs/4386811283/jobs/7681367639

Trying to push the name quay.io/kairos/framework:v2.0.0-alpha1 but framework images are now quay.io/kairos/framework:v2.0.0-alpha1_${{ matrix.flavor}}

so we build Image quay.io/kairos/framework:v2.0.0-alpha1_ubuntu-22-lts and need to use the same name for the signing

https://github.com/kairos-io/kairos/pull/1108


Technical site crashes with valid report call and invalid region parameter

Calling the frontend site with a valid report input and invalid report region parameter does not return an error code but crashes the server software.
Example:  <root_url>/en/reports/pip/foo

This bug was fixed in commit 1637e8f6d10db03f34d2c964c37adc2f30358e2c