Error on adding a custom viewer

Following error occurs when a custom viewer is added (MPO viewer):
shell.ts:249 Uncaught (in promise) RangeError: Maximum call stack size exceeded
at get tableNames [as tableNames] (shell.ts:249:5)
at get tables [as tables] (shell.ts:255:17)
at ny (dataframe.js:16:21)
at n.value (index.jsx:54:20)
at n.value (index.js:393:10)
at n.value (index.jsx:24:5)
at n.onFrameAttached (viewer.ts:354:10)
at c8.fQ (login.dart.js?270:460:27)
at J.Un (login.dart.js?270:18610:34)
at kj.sO (js_viewer_host_core.dart:43:25)
at dart.dFU.$2 (grok_api.dart:541:68)
at Object.fX (js_helper.dart:1521:16)
at dart.dlq (js_helper.dart:1489:11)
at js_dart2js.dart:667:13
at set dataFrame [as dataFrame] (viewer.ts:172:9)
at n.value (index.jsx:55:10)
at n.value (index.js:393:10)
at n.value (index.jsx:24:5)
at n.onFrameAttached (viewer.ts:354:10)
at c8.fQ (login.dart.js?270:460:27)
at J.Un (login.dart.js?270:18610:34)
at kj.sO (js_viewer_host_core.dart:43:25)
at dart.dFU.$2 (grok_api.dart:541:68)
at Object.fX (js_helper.dart:1521:16)
at dart.dlq (js_helper.dart:1489:11)
at js_dart2js.dart:667:13
at set dataFrame [as dataFrame] (viewer.ts:172:9)
at n.value (index.jsx:55:10)
at n.value (index.js:393:10)
at n.value (index.jsx:24:5)
at n.onFrameAttached (viewer.ts:354:10)
at c8.fQ (login.dart.js?270:460:27)
at J.Un (login.dart.js?270:18610:34)
at kj.sO (js_viewer_host_core.dart:43:25)
at dart.dFU.$2 (grok_api.dart:541:68)
at Object.fX (js_helper.dart:1521:16)
at dart.dlq (js_helper.dart:1489:11)
at js_dart2js.dart:667:13
at set dataFrame [as dataFrame] (viewer.ts:172:9)
at n.value (index.jsx:55:10)
at n.value (index.js:393:10)
at n.value (index.jsx:24:5)
at n.onFrameAttached (viewer.ts:354:10)
at c8.fQ (login.dart.js?270:460:27)
at J.Un (login.dart.js?270:18610:34)
at kj.sO (js_viewer_host_core.dart:43:25)
at dart.dFU.$2 (grok_api.dart:541:68)
at Object.fX (js_helper.dart:1521:16)
at dart.dlq (js_helper.dart:1489:11)
at js_dart2js.dart:667:13
at set dataFrame [as dataFrame] (viewer.ts:172:9)
at n.value (index.jsx:55:10)
at n.value (index.js:393:10)
at n.value (index.jsx:24:5)
at n.onFrameAttached (viewer.ts:354:10)
at c8.fQ (login.dart.js?270:460:27)
at J.Un (login.dart.js?270:18610:34)
at kj.sO (js_viewer_host_core.dart:43:25)
at dart.dFU.$2 (grok_api.dart:541:68)
at Object.fX (js_helper.dart:1521:16)
at dart.dlq (js_helper.dart:1489:11)
at js_dart2js.dart:667:13
at set dataFrame [as dataFrame] (viewer.ts:172:9)
at n.value (index.jsx:55:10)

let table = grok.data.testData('random walk', 1000, 2);
let view = grok.shell.addTableView(table);
and then:
let fc = Array.from(view.viewers)[1]
fc.add({type: "1"})
expected: no errors, just balloon


Dependencies

@mekras can you tell me why 0.4 message-factory is required? Ever since the 0.3 release we didn't have a single commit.
I also noticed that both the common psr7 implementations are required in the project. Why is that?

why 0.4 message-factory is required?

It's required by php-http/discovery 0.3

I also noticed that both the common psr7 implementations are required in the project. Why is that?

Are you talking about guzzle and diactoros? They are used for testing. I have cases, when tests were passed with the one implementation, but fails with the other.

Thanks for clarification.


feat(forge build): prettify compiled contract JSON artifacts

Component
Forge
Describe the feature you would like
It would be easier to read JSON artifacts by having them compiled in a pretty way, maybe using a setting in the foundry.toml file allowing you to specify tabs and spaces for the output.
Using an external tool to do so it's only a temporary workaround, 'cause the contract would be always compiled in a non-pretty form if you make some changes and have the need of rebuilding it.
Additional context
No response

Would be worth considering it as an optional feature which can be enabled on demand?
Eg in foundry.toml:
...
[output.fmt]
pretty = true


Check if a program is already installed and display a flag

So if your script is able to read the following registry keys:
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

I suggest adding a flag for each installed program, such as "(Already installed)" and the checkbox set to checked and readonly.

It might be better to run a "list" command for every package manager the script uses, and search their outputs for every installable program.


Add sorting of arrays in Javascript

MicroByte Title: Array in Javascript
Improvement Proposal: Add ways to sort an array in javascript(along with in-built methods) and add problems related to it
Benefits of proposed improvements: Sorting is a very essential and common task when it comes to arrays. It is also important to
let the readers know about the in-built methods for the same so that they come in handy during regular use and save time

can I work on this issue?

Actually I created this issue so that I can work on it.

okay

@Sreejan-22 same goes to this issue as the other one, if you wanna add code in the README.md, add it in collapsible markdown. Nevertheless, we encourage you add all your code in the src folder.

@anut123 You can try to go through the other content that we have and checkout whether if you have any ideas for improvements.

okay sir


Fallback to nvim's default socket location

There's probably some sane reason why you haven't already included this sort of thing. The stat behavior differing between platforms/versions, maybe?  Anyway, here are a few lines that helped me get rolling faster (though they might break things entirely for others).
BTW, thanks for making this tool; it's a time saver.

Sorry, but I can't merge this, since it's pretty opinionated. Preferring a socket "0" is just a bit too much and also fails for macOS which makes it too specific.
Thanks anyway!


features.md: add unsafe annotation list

https://github.com/opencontainers/runtime-spec/blob/main/features.md should return the list of unsafe annotations. (“org.systemd.”, “run.oci.”, etc.)

https://github.com/opencontainers/image-spec/pull/1061/files#r1194531089

I like this idea, though I think runtimes should opt for listing the precise annotations they consider unsafe rather than specifying namespaces (after all, the runtime should know which annotations they support and what they do). But the format should probably support specifying namespaces in cases where the runtime really wants to indicate a whole namespace is unsafe.

PR:

https://github.com/opencontainers/runtime-spec/pull/1205

I like this idea, though I think runtimes should opt for listing the precise annotations they consider unsafe rather than specifying namespaces (after all, the runtime should know which annotations they support and what they do). But the format should probably support specifying namespaces in cases where the runtime really wants to indicate a whole namespace is unsafe.

Yes.
Actually, a precise annotation string is also valid as a "prefix"


Explain why egresshttpbin and egressgithub doesn't work

When I look at the original code of these projects I don't understand why they fail. It's also not clear in the readme file why they fail and why they need an egress rule.

Unlike raw Kubernetes, Istio/Envoy block all outbound traffic from a pod (envoy intercepts all in/out traffic) as that is considered to be better/smarter for security reasons.  One of the more interesting attack vectors (if you are a blackhat hacker) is to install a small process on a remote server, have it collect interesting data and "phone home".   So, Istio/Envoy block that outbound traffic (pod to outside the service mesh).    Therefore, you must explicitly open up the egress routes, kind of like opening up ports in the firewall.

I recommend we close this. Egress works differently in Istio 0.8 anyway.

And also because we will rewrite the Egress application.


"canDrop", how to know what element we are on top of?

In the drop(props, monitor, component) method, we have three arguments. But in the canDrop(props, monitor) there isn't the component arg.
I want that when an item is dragged over another component I "split" that component in two parts of 50% (height). If the item is dropped in the higher part then he'll be placed above it, if it's dropped in the lower part then it'll be placed after.
I already have the code that detects whether the component is dropped in the top/bottom part. What I want now is to add a class based on whether the mouse is in the top/bottom part (but during the hover action, not the drop action).
I don't know if I can use the hover(props, monitor, component) method, because I don't see how I'm supposed to add a property in my component (which would add a CSS class in the DOM or alike) from it, since it doesn't belong to the component itself and doesn't have access to its context and so on.
I guess I'm missing something. :)

Hey, you're in luck!  I've implemented almost exactly this before, so let me throw together some code.

OK, so the idea is that you want to set state in your component, and then when the state is set, you add the class.
Let's say you're dragging a Foo into a Bar:
import React, { Component } from "react";
import classNames from "classnames";

class Bar extends Component {
  constructor(props) {
    super(props);

    this.state = {
      // Where a foo is hovering over the component.  One of null, "above", or "below"
      fooHover: null,
    };
  }

  render() {
    const { fooHover } = this.state;

    const classes = classNames("bar", {
      "bar-above": fooHover === "above",
      "bar-below": fooHover === "below",
    });
  }
}

The only question is how we set that state!
import { findDOMNode } from "react-dom";

const barTarget = {
  ...
  hover(props, monitor, component) {
    if (!monitor.canDrop()) {
      return;
    }

    const rawComponent = undecorate(component); // undecorate described below

    const { y } = monitor.getClientOffset();
    const { top, height } = findDOMNode(component).getBoundingClientRect();

    if (y < top + height/2) {
      rawComponent.setFooHover("above"); // setFooHover described below
    } else {
      rawComponent.setFooHover("below");
    }
  },
  ...
}

So basically, you want to call an instance method of your component, setFooHover, which will call setState.  That should look like this for performance reasons:
  // In Bar
  setFooHover(fooHover) {
    if (fooHover !== this.state.fooHover) {
      this.setState({ fooHover });
    }
  }

The reason why I am calling undecorate above is that react-dnd uses higher order components, and we want the unwrapped components.  This is an ugly complication of higher order components in my opinion.  Maybe you could implement this instead by dispatching an action to your flux store or something, but in case you decide to do it like me, here's my undecorate:
function undecorate(component) {
  let curr = component;
  while (typeof curr.getDecoratedComponentInstance === "function") {
    curr = curr.getDecoratedComponentInstance();
  }

  return curr;
}

Now if you implement this, everything will be looking good except for one small problem.  The class never goes away!  No one ever calls setHoverState(null) (there's no such thing as an endHover function in your barTarget).  The proper way to handle this is to use componentWillReceiveProps like this:
  componentWillReceiveProps(nextProps) {
    if (this.props.isFooOver && !nextProps.isFooOver) {
      this.setState({ fooHover: null });
    }
  }

(Don't forget to add { isFooOver: monitor.isOver()  } in your collecting function)
Let me know how it goes!

Thanks a lot for the detailled explanation! I'll let you know :)

Finally, I used the Redux approach, so I basically dispatched an event through a reducer when the drop event was fired.
    drop: (propsTargetItem, monitor, targetItem) ->
        draggedItem = monitor.getItem()# Item that has been dragged and eventually dropped.
        coordsDrop = monitor.getClientOffset()# Coords of the drop action.
        diff = monitor.getDifferenceFromInitialOffset()# Comparison of the initial click (dragging start) against the end of the click (dropping start).

        patternId = draggedItem.patternId
        patternPosition = draggedItem.position
        targetId = propsTargetItem.context.patternId
        targetPosition = propsTargetItem.context.position
        isCursorAboveHalf = GeoService.isAboveHalf(ReactDOM.findDOMNode(targetItem), coordsDrop.y)

        # Extract positions in the array of children.
        oldPosition = draggedItem.position# Current position of the item, which will be the old position as soon as the item is moved. (by the server through sockets)
        newPosition = calcDropPosition(targetId, patternId, patternPosition, targetPosition, isCursorAboveHalf)# Position where we will move the dragged item.

        # Dispatch only if the position has changed and is set.
        if oldPosition isnt newPosition and newPosition?
            draggedItem.moveDnDPattern(Object.assign({}, draggedItem, {newPosition: newPosition, oldPosition: oldPosition}))


Update Set-TenantAllowBlockListItems.md

We will update the UI so that branding is all the same: Tenant Allow/Block List.

Docs Build status updates of commit b29fe4e:
:clock10: Full build: the average full build time is 18 min(s) 6 sec(s), this is based on the last 1000 build(s) for this repository.

Docs Build status updates of commit b29fe4e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-TenantAllowBlockListItems.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


feat(statsd): Allow user defined metrics prefix

Summary
Allow user specifying their own metrics prefix.
Full changelog

Allow user specifying their own metrics prefix.

update: add statsd plugin schema migration

@depay this PR cant be merged as it is as we are making major changes to config https://github.com/Mashape/kong/pull/2400. So merging it over PR #2400 would be conflict mesh.
So I would manually move this feature over #2400.

Also all plugin related migrations need to go to kong.plugin.migrations.

@shashiranjan84 thanks, great work. feel free to close this PR as you need.


Add ApiConnectionNotification in trigger types list and indivisual explanation for ApiConnectionNotification

I'd like you to add ApiConnectionNotification in trigger types list and indivisual explanation for ApiConnectionNotification.
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#trigger-types-list
That trigger type is known as "When a new email arrives (V3)" trigger of Office 365 Outlook connector.
https://learn.microsoft.com/en-us/connectors/office365/#when-a-new-email-arrives-(v3)
Lots of users love to use that trigger.
Best Regards,
CSS Shingo Hanai (shhanai)

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 4a0dd3aa-82c2-4510-1413-a109eddf6303
Version Independent ID: 21f0f699-9267-821f-07aa-998f7dfc32f2
Content: Schema reference for trigger and action types - Azure Logic Apps
Content Source: articles/logic-apps/logic-apps-workflow-actions-triggers.md
Service: logic-apps
GitHub Login: @ecfan
Microsoft Alias: estfan

@ShingoHanai
Thanks for your feedback! We will investigate and update as appropriate.

@ShingoHanai Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.
@ecfan Can you please review it. Thanks

Hi @ShingoHanai,
Thank you for your request! I've created a work item on the backlog to prioritize relative to other deliverables.
#please-close


[Feature Request]: Signer support for fee grant module for blob submission

Background
Our users want to optimise their cluster operations, thus creating a scenario when 2-4 execution environments (like 4 OPStack chains) are using 1 celestia light node. However, each of the exec env is submitting blobs TXs from their own celestia account. Which brings us to a bad UX, where we have 4 accounts that needs to be funded and tracked.
With fee grant module and signer implementation done on node side, we can eliminate this situation. Meaning that each of the new celestia account for the exec env can be created and granted permissions from a single account to pass fee payments
Implementation ideas
ATM, we need something like a --fee-account $account_address for node's part. This is needed for blob submission
So we can have the following scenario:

Light node is initialised/started with an A account with 0 balances
The main account (living somewhere else) is granting A account perms to pass the fee payments to it
Light node can submit blobs and pass the fees to main account
Success for partners running multiple light nodes in their envs

https://gist.github.com/rootulp/c47606e177aad1f8959ea31fa077ca5e

https://github.com/celestiaorg/celestia-app/issues/3221


something wrong with rescale_L

To rescale Laplacian eigenvalues to [-1, 1], the formula should be $L' = 2L/l_max - I$.
I think the 33-th line in corsening.py should be like follows:
L /= lmax / 2

@tadpole You are right! But perhaps it's the version of python or numpy that actually matters.
I change it to L = 2 * L / lmax , the accuracy could achieve 99.080%.
The original version L /= lmax * 2 could achieve around 11% due to random guess.
But with your version L /= lmax / 2, loss could be nan and accuracy could be around 11%.


Possible regression to do with batch normalization

Hi,
I just tried your code for the first time and I was disappointed to see that even after 500+ episodes, the rewards for Pendulum env were still in <-1000 area. I poked around a little and after reverting the latest commit (f2425330b1b7c6fb264b0a6429d4e43c3b93a417) the algorithm works as expected and achieves good results after around 100 episodes. It seems like the commit above was a regression.

Oops thanks. I commented it out by default, the master branch has been updated.


Subscription response being ignored

The subscription queries are being sent correctly, but the response is being ignored by urql.
urql version & exchanges:

urql: 2.3.3 (dedupExchange, cacheExchange, subscriptionExchange)
urql/exchange-auth: 0.1.6
urql/exchange-multipart-fetch: 0.1.13
urql/exchange-retry: 0.3.0

Steps to reproduce

Setup client with graphql-ws
Trigger a subscription query

Expected behavior
The returned response should be read by urql and return to the hook that called the subscription.
Actual behavior
Nothing happens.
Basic Client Setup
const wsClient = process.browser ? createWSClient({
    url: URI.replace('https://', 'wss://'),
    lazy: false,
    keepAlive: 10_000, // ping server every 10 seconds
}) : null;

const client = createClient({
    url: URI,
    exchanges: [
        dedupExchange,
        cacheExchange,
        authExchange({
            // ...
        }),
        retryExchange({}),
        multipartFetchExchange,
        wsClient ? subscriptionExchange({
            forwardSubscription: operation => ({
                subscribe: observer => ({
                    unsubscribe: () => wsClient.subscribe(operation, observer),
                }),
            }),
        }) : null,
    ].filter(Boolean),
    async fetch (resource, init) {
        return await unfetch(resource, init).then(res => {
            parseSessionExpiresHeader(res.status, res.headers);
            return res;
        });
    },
    fetchOptions: {
        credentials: 'include',
    },
});

Sample Query
useSubscription({
    query: gql`
        subscription WatchForFlight ($topic: String!) {
            listen (topic: $topic) {
                relatedNode {
                    ...Flight
                }
            }
        }
        ${FLIGHT_FRAGMENT}
    `,
    pause: !flightNumber,
    variables: {
        topic: `flight:updated:${flightNumber}`,
    },
});

Ah, didn't realise you had a subscription in your reproduction!
I've switch the WS client from subscriptions-transport-ws with graphql-ws and the issue seems to be instantly reproducable. I switched out the client locally and it fixed the issue.
https://codesandbox.io/s/zealous-bartik-m1ift

I'm using Postgraphile for the API, which seems to support both protocols interchangeably based off the Sec-WebSocket-Protocol header sent with the request. (See https://github.com/graphile/postgraphile/blob/main/src/postgraphile/http/subscriptions.ts#L463-L487). What weird is the data does seem to be being returned in the websocket (when looking via inspect), but it never reaches the client.

Closing due to inactivity


Translate Contributing Guide in Bengali

I think we should start translating the contributing guide to Bengali.

Filename of Contributing guide - CONTRIBUTING.md
Propossing the file name of the Bengali translate file - CONTRIBUTING.bn.md

NOTE: Don't start working without any discussion

we will start our job as soon as possible
@ratanparai

There is some technical term, should we translate them also? or keep those as it is?

On 2/6/2018 12:53 AM, mhmohona wrote:

There is some technical term, should we translate them also? or keep
those as it is?

I think we should keep the technical terms as it is. Our goal is to make
the guide accessible while making sure nobody find any surprises when
they read more advanced tutorials. And most of the tutorials are written
in English. So we should write few lines describing what it means but
keep those in its original form.

Can we start translating the contribution file?

Can we start translating the contribution file?

@ashrafulais: It would be very helpful. Feel free to create a PR

@ashrafulais: It would be very helpful. Feel free to create a PR

I've started the translation. Currently, I've copied the original file, renamed it to CONTRIBUTING.bn.md and I will change the instructions to Bangla only. The technical terms will be the same.

@ashrafulais: thanks for the update

is it still open or can u assign this to me


Minor improvements

Minor fixes and improvements; nothing to write home about.

Changes Unknown when pulling 93fe7b866d16012675ff49f68e8b9e7b71d013c3 on minor-improvements into ** on master**.


[Suggestion] Introduce a new exec command for Discord?

##Platform
[x] Forge
[ ] Spigot
(1.12.2 and/ or 1.16.4)
Although you have stated that 1.12.2 won't be receiving further updates. it would be nice to have a working exec command for
this instance, maybe even a working commandJson would work for 1.12.2 and a default implementation viable for 1.16.4+, as I
run multiple modpacks on my servers that run on 1.12.2 and 1.16.4+
What I want possibly included into dcIntegration? Otherwise just an updated script.

I'm requesting a new and updating admin execute a command similar to #48, because when I tried to use the included
commandJson the newest dcIntegration did not support it. Maybe this could just be included in a new version of
dcIntegration? If not and this is such a specific issue then that's fine, but this command would be great to use in a specific
admin-only Discord channel separate from where the bot normally runs.

When using the code from #48, I receive an error to load, but without the included code it runs fine.
{"exec":{"adminOnly":true,"mcCommand":"","description":"Executes an command","useArgs":true,"argText":"<command>"}}
Error as followed
[modloading-worker-4/ERROR] [net.minecraftforge.fml.javafmlmod.FMLModContainer/LOADING]: Failed to create mod
instance. ModID: dcintegration, class de.erdbeerbaerlp.dcintegration.forge.DiscordIntegration
java.lang.ExceptionInInitializerError: null

Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: Invalid value on line 47: customCommandJSON =
{\"kick\":{\"adminOnly\":true,\"mcCommand\":\"kick\",\"description\":\"Kicks a player from the
server\",\"useArgs\":true,\"argText\":\"<player> [reason]\"},\"stop\":
{\"adminOnly\":true,\"mcCommand\":\"stop\",\"description\":\"Stops the server\",\"aliases\":
[\"shutdown\"],\"useArgs\":false},\"kill\":{\"adminOnly\":true,\"mcCommand\":\"kill\",\"description\":\"Kills a
player\",\"useArgs\":true,\"argText\":\"<player>\"},\"exec\":{\"adminOnly\":true,\"mcCommand\":\"\",\"description\":\"Executes
an command\",\"useArgs\":true,\"argText\":\"<command>\"}}```

#net.minecraftforge.fml.LoadingFailedException: Loading errors encountered: [
     Discord Integration (dcintegration) has failed to load correctly
?7java.lang.ExceptionInInitializerError: null

I might add such an command as an addon later

I might add such an command as an addon later

I would definitely appreciate that, would be useful for the 1.17 smp I host with friends.
I'll leave this open, but feel free to close it at your discretion if you want. I'm glad it's on your mind now.

Forgot to close this. Addon is now released. Get it from here: https://github.com/ErdbeerbaerLP/DiscordIntegration-Addon-Repository/tree/master/_Releases


ci: fix CodeQL security scans

Moved the file to the correct directory
Pinned the runner version to Ubuntu 20.04

Fixes #1836
Depends on #1912
Depends on #1910
Depends on #1908
Signed-off-by: Peter Somogyvari<EMAIL_ADDRESS>

@petermetz I approved because this is urgent, but I'd like to confirm one thing. In my understanding, the codes on "Unchanged files with check annotations" have not changed by this PR. Has it right?

@takeutak That is correct. Those files are being changed by the other PRs (the ones that this has listed as dependencies).
This PR only adds the check (which will keep failing until those other PRs are merged and then it will start succeeding)


Added support for synthesizing system verilog designs with vivado

I did this because I wanted to run my ECEN 220 and ECEN 323 labs through bfasst. Do you think this is something we should add to bfasst?

Sure, SystemVerilog support is great.  And adding your 220/323 designs.


[Hub Generated] Review request for Microsoft.ContainerService/aks to add version preview/2024-02-02-preview

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
ARM (Control Plane) API Specification Update Pull Request

[!TIP]
Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

[!NOTE]
As of January 2024 there is no PR assignee. This is expected. See https://aka.ms/azsdk/pr-arm-review.

PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Click here to see the details of Step 1, Breaking Changes review
If you are in purview of Step 1 of the diagram, follow the Breaking Changes review process.
IMPORTANT! This applies even if you believe your PR was mislabeled, for any reason, including tool failure.

Click here to see the details of Step 2, ARM review
See https://aka.ms/azsdk/pr-arm-review.

 Click here to see the diagram footnotes
Diagram footnotes
[1] See ARM review queue (for PR merge queues, see [2]).
[2] public repo merge queue, private repo merge queue (for ARM review queue, [1])
The ARM reviewer on-call engineer visits the merge queue twice a day, so the approximate ETA for merges is 12 - 24 hours.

Purpose of this PR
What's the purpose of this PR? Check the specific option that applies. This is mandatory!

[ ] New resource provider.
[x] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been generated using OpenAPI Hub).
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix OpenAPI spec quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.

Additional information

 Viewing API changes
For convenient view of the API changes made by this PR, refer to the URLs provided in the table
in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures
If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the
suppressions guide to get approval.

Getting help

First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
For help with PR workflow diagram Step 2 (ARM review), see https://aka.ms/azsdk/pr-arm-review.
If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run.
This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

Fixing failed CI Swagger LintDiff via PR #28428. looking for feature owner to confirm the changes are as expected.

/pr RequestMerge

Hi @FumingZhang , there's a failed check needs to be fixed:
❌ BreakingChange-Go-Sdk-Suppression-Approved

/azp run

@Alancere, @raych1 could you please help approve the BreakingChange-Go-Sdk-Suppression? Seems Alancere helped make the change #44c13a6


Split LLVM targets into subfolders to support CMake filtering.

Follow-up to https://github.com/google/iree/pull/2759.
Splitting iree/compiler/Dialect/HAL/Target/LLVM into

iree/compiler/Dialect/HAL/Target/LLVM (common code)
iree/compiler/Dialect/HAL/Target/LLVM/AOT
iree/compiler/Dialect/HAL/Target/LLVM/IR

So we can filter from builds using logic like
if(NOT ${IREE_TARGET_BACKEND_LLVM-IR})
  return()
endif()

with both targets in the same directory we'd need to use if/else wrapping, which is messier to handle (but not terribly so) in bazel_to_cmake.

Need to fix some CMake builds.

Need to fix some CMake builds.

Rebased and fixed.


Logscale

Fixes #413
I had a look and it turns out that I just had a bug in my initial cleanfigure code that caused the logplot not to work. It should work now out of the box.
That said please let me know if it breaks again. I will have a look asap.

LGTM, thanks!


Top-level docs rewrite

This change is

@abuehrle please take a look when you have a moment, this incorporates your changes to top-level docs fro from #30.

Thanks @peterbourgon!

I can't really effectively edit something using this inline tool in git. It's ok for typos, but for anything more substantial,  I am going to have to edit the file directly.
Typically, I run the sample on my own machine to ensure it works and test out the instructions. This is the only way to see if the 'workflow' works, and to be able to make structural suggestions.  Hope that's ok.

Questions:
What version of the following should we be using:
-docker
-kubernetes
-weave net
Can an individual set this up without using the provided scripts?  How do we achieve that?

What version of the following should we be using:

docker

Kubernetes Anywhere requires Docker 1.10 (current). I am testing 1.11 releases candidate right now, but we are still far from the final release, the -rc1 has only been out for some number of hourse now...

kubernetes

Kubernetes Anywhere provides v1.1 and v1.2 right now.

weave net

Latest, i.e. 1.4.6. We will switch to 1.5 as soon as it's released.

Can an individual set this up without using the provided scripts? How do we achieve that?

There are no external scripts as such, it's just Docker images. These images contains numerous small scripts which glue it all together, it would take forever to explain what each does and and it all fits in. There would be ifs all over the place. I don't see a point of breaking it up, the generalised multi-node instructions are already the most general thing we can have, although still quite verbose due to the nature of the beast...

README.md, line 383 [r2] (raw file):
Done.

Comments from the review on Reviewable.io

Review status: 0 of 1 files reviewed at latest revision, 10 unresolved discussions.

README.md, line 81 [r2] (raw file):
Done.

README.md, line 382 [r2] (raw file):
Done.

README.md, line 53 [r3] (raw file):
Done.

Comments from the review on Reviewable.io

Review status: 0 of 1 files reviewed at latest revision, 10 unresolved discussions.

README.md, line 28 [r2] (raw file):
Done.

README.md, line 34 [r2] (raw file):
Done.

README.md, line 37 [r2] (raw file):
Done.

README.md, line 39 [r2] (raw file):
Done.

Comments from the review on Reviewable.io

I'm leaning towards merging this as is, it's already so much better then the current readme...

Also, from conversation with @peterbourgon I should improve the note about Docker setup.

[ ] move the note about Docker setup into a separate section
[ ] ensure that version of Docker is specified more explicitly
[ ] state explictitly that local Docker is required (#54)
[ ] describe the issue with docker.service linking to relevant issue in Docker repo and stating explicitly that the instructions related to the host and not the toolbox container or anything
[ ] add a note about Debian 8 issue (https://github.com/kubernetes/kubernetes/issues/23816)

also, cc #55

I've addressed most of the concerns which resulted in quite a few changes. I'm going to merge it now, on the basis that it's better then the current version, so please file issues for any further improvements you may want to discuss. // cc @rade @peterbourgon @abuehrle

README.md, line 27 [r3] (raw file):
Done.

Comments from Reviewable

Reviewed 2 of 2 files at r7.
Review status: all files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

Comments from Reviewable

Reviewed 2 of 2 files at r7.
Review status: all files reviewed at latest revision, 10 unresolved discussions.

Comments from Reviewable


WIP: Added Pod Restart policy

Pod restart policies are defined in Kubernetes as operations that happen after a container exits. Lay groundwork for adding restart policies, and allow for containers to inherit restart policies from their pod if they are in one. Current restart policies are "never" (cleanup container after exit) and "always" (start the container after it exits).
Still TODO:
onFailure - restart a container only when it doesn't exit with 0
exponential backoff - allow for both always and onFailure to slow down on restarts if they continually exit. This is done in k8s
The TODO require some changes to conmon, so I'm putting this out there for folks to look at and begin to argue about while I look into that :)

I don't think this works as written - we need container cleanup to run after every container exits, no exceptions. We'd need Conmon patched to potentially accept multiple exit commands?
(Alternatively, cleanup would need to trigger further postrun actions. I don't know if I like that, but it could definitely be worked into a good way of doing this)
Anyways, what exactly are we trying to do here - restart the entire pod on a container in it exiting, or restart just the one container?

@mheon K8s restarts the one container.
on this branch running
podman run --pod demo alpine /bin/sh -c 'sleep 10' ```

has the container restart every 10 seconds, according to podman ps

Though, I do like the idea of adding this to container create. I thought about adding a cli option as well. But that route would avoid conmon changes which I like, though it may get Hacky.

Hm.
I'd honestly be OK making this a container flag as well - Docker has it on normal containers as well, and if we work out the mechanics it ought to work for every container, pod or no.
We can keep the pod handling (if the container doesn't specify, we use the pod value as default), but allow it to be specified per-container as well. Or maybe we allow --restart-policy on containers, but make it conflict with --pod so you have to use the pod handling if you're in a pod?

We'd probably want to make cleanup check restart policy and perform the appropriate action if and only if it detects a state change from running to stopped/exited (save the state before doing the syncContainer(), and see if it's changed afterwards). There might be other places it runs.

SGTM, I'll look into mimicing docker --restart

Further realization - we might not have the appropriate state loaded...
You basically would have to do an UpdateContainer() with the state first to grab the right state from the DB, then save the state, then syncContainer()...
It's gross (we hit the DB twice instead of once), but it should work.

Well this PR is about pod's not containers, although container restart might be a nice by product.
I see there being three states of a container running within a pod when the container exits.
1: Nothing (Default), which is what we have now
2: Container Restarts
3: Pod gets stopped.
Now we might want to differentiate between a container that exits with status == 0, versus a container that exits !=0.  We also want to clarify on restart count.


License

This project looks ideal for my needs.
The complication is I would like to import it into a project with a GPL License.
This is not a religious argument about licenses, just a practical request. Would it be possible for the original author to give this a dual License?
Thanks.
Jon

According to the GNU project, this license terms (also known as "The FreeBSD license") of the project here are compatible with the requirements of the GPL, so there should be no practical problem using the two projects together.  Just be sure to comply with the BSD license requirement to notify users of the BSD terms for the BSD-licensed component.


Re-scan of MBTiles directory after adding new files

When I run martin with a config file with a directory of MBTiles configured it all works great, but when I try to add new files it doesn't re-scan the directory and I need to re-run martin for it to publish them. Is there a way to make martin publish the new MBTiles files as soon as they are added in the directory?

Duplicate of #288, lots of requests for this, some work is being done in #1179


Does this project support bazel 5.2.0?

When I use bazel 5.2.0, the warning is : " The major revision of the Android NDK referenced by android_ndk_repository rule 'androidndk' is 25. The major revisions supported by Bazel are [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]. Bazel will attempt to treat the NDK as if it was r21. This may cause compilation and linkage problems. Please download a supported NDK version.".
Any suggestion? Thanks.

Hi, it looks like you're using the "native" version (i.e. the non-Starlark version) of android_ndk_repository (https://bazel.build/reference/be/android#android_ndk_repository)
Are you loading the rules_android_ndk version (i.e. Starlark version) of android_ndk_repository like this?:
https://github.com/bazelbuild/rules_android_ndk#getting-started

Thanks for reply.
What's the difference between WORKSPACE in your second url  and WORKSPACE in examples/basic ?
I've add the https://github.com/bazelbuild/rules_android_ndk#getting-started in the end of my project WORKSPACE, while
another error happend:
ERROR: /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/local_config_cc/BUILD:47:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'arm64-v8a'
ERROR: /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/local_config_cc/BUILD:47:19: Analysis of target '@local_config_cc//:toolchain' failed

Thanks again.

Ah, so is avatar-sdk/Session:libsession.so a cc_binary? If so, then other flags are needed, because only android_binary will use --fat_apk_cpu and --android_crosstool_top. You'll need to set --cpu and --crosstool_top (and maybe also set --host_crosstool_top to the default host toolchain). Is that was --config=android_arm64 does?

Yes, avatar-sdk/Session:libsession.so is a cc_binary.
And my project (mediapipe written by google) .bazelrc is as following:
# Android configs.
# Note: the documentation tells us to use @androidndk//:default_crosstool, but
# the automatic configuration transition uses //external:android/crosstool.
# Using it here works and spares us from having two different config_settings
# for Android.
build:android --crosstool_top=//external:android/crosstool
build:android --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
build:android --linkopt=-landroid
build:android --linkopt=-ldl
build:android --linkopt=-llog
build:android --linkopt=-lm
build:android --linkopt=-Wl,--gc-sections

build:android_arm --config=android
build:android_arm --cpu=armeabi-v7a
build:android_arm --fat_apk_cpu=armeabi-v7a

build:android_arm64 --config=android
build:android_arm64 --cpu=arm64-v8a
build:android_arm64 --fat_apk_cpu=arm64-v8a

So，your guess is exactly right.
I guess that some options(select which toolchain?) are also from my project(mediapipe) but not from the rules_android_ndk.
In other words,  ````rules_android_ndk``` don't work as expected.
Thanks.

Thanks for reply.
I've tried all your suggestions and it also be in error.
The error is:
ERROR: /home/zhu/mediapipe/mediapipe/util/BUILD:77:11: no such target '@androidndk//:cpufeatures': target 'cpufeatures' not declared in package '' defined by /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/androidndk/BUILD and referenced by '//mediapipe/util:cpu_util'

Thanks again.

The cpufeatures target that the native version of android_ndk_library was not added to the starlark version.
I added them with b718a4b96b392a2ed8e2585a350bfd6d1eaaedae and c76a94ff365cac3c4f9c218eca6195a9b662530b.
However, in the native version of android_ndk_library, the cpu features files would be included like
#include "ndk/sources/android/cpufeatures/cpu-features.h", and with the way that the starlark ndk respository is laid out, it would be #include "sources/android/cpufeatures/cpu-features.h" in the starlark version. So mediapipe might not compile with the file path without the ndk/ prefix. If it's possible to modify your local version of mediapipe temporarily, you could try that. If not, then mediapipe will need to be updated.

Looking through mediapipe's code with respect to my previous comment, and yeah, this import will fail with the starlark version of android_ndk_repository:
https://github.com/google/mediapipe/blob/6cdc6443b6a7ed662744e2a2ce2d58d9c83e6d6f/mediapipe/util/cpu_util.cc#L20
Probably the most straight forward thing to do would be to somehow make the starlark version of android_ndk_repository backwards compatible with the ndk/ prefixed import paths...

Thanks for reply. @ahumesky
I have changed WORKSPACE to follow your latest commit https://github.com/bazelbuild/rules_android_ndk/commit/c76a94ff365cac3c4f9c218eca6195a9b662530b. The no such target '@androidndk//:cpufeatures'  has gone. Thanks for your work.
As you mentioned, the #include "ndk/sources/android/cpufeatures/cpu-features.h in Mediapipe need to be changed to #include "sources/android/cpufeatures/cpu-features.h".
After this changes, everything is ok in compilation step. however, linker complained about as following:
ld.lld: error: unable to find library -lpthread

I find that https://github.com/bazelbuild/rules_android_ndk/issues/5#issue-1360980880 has mentioned in point (6). I have modified configs following https://github.com/gflags/gflags/pull/321/commits/59fb6443a82b84c6b5971b2f45403c78727b7604
, but failed again.
My libraries in external directory are

Any suggestion will be help.
Thanks again.

With https://github.com/bazelbuild/rules_android_ndk/commit/44dcd014f4b126f8941c29ff1b25e1584bd3eb26 changing the include path in mediapipe shouldn't be necessary anymore. We'll have to followup on the pthread issue next week.

Thanks for your work, @ahumesky
Glad to hear you will start the pthread issue.
Thanks again.

I see you found a workaround with https://github.com/bazelbuild/rules_android_ndk/issues/5#issuecomment-1385288459 glad you are unblocked.
I think unable to find library -lpthread is actually a symptom of this config_setting not working with the starlark version of android_ndk_repository:
https://github.com/tensorflow/tensorflow/blob/93905da81b2995eaba088b715c7d61dcbed51c31/tensorflow/tensorflow.bzl#L449
https://github.com/tensorflow/tensorflow/blob/a801af081952535b541852ad6ad96e0d536f2965/tensorflow/BUILD#L195
Tensorflow would need to use the new value of @androidndk//:toolchain instead of //external:android/crosstool.
Putting a bind in your top-level workspace file may work as a workaround:
bind("android/crosstool", "@androidndk//:toolchain")
If that doesn't work on its own, you might need to set --crosstool_top as well:
--crosstool_top=//external:android/crosstool

I hit the pthread issue outside of tensorflow so I imagine it's other places too. Seems like either way we should update that config setting in tensorflow to use the OS from the platforms repo

Hi, @ahumesky , Sorry for delay.
I have add the ind(name="//external:android/crosstool", actual="@androidndk//:toolchain") in my top-level WORKSPACE file, but it doesn't work.
I found that tensorflow has many //external:android/crosstool,  my grep command outputs are

Should I modify all of these config ? Furthermore，Should I modify all //external:android/crosstool in external directory ?
By the way, what is the meaning of  catch-22 ?
Thanks.

You might try
bind(
    name = "android/crosstool",
    actual = "@androidndk//:toolchain",
)

I don't think that the "//external:" is necessary.
By the way, do you have a directory called external at the top-level of your workspace? Bazel treats external differently because of the (unfortunate) binding schemes with bind (we would actually like to get rid of bind one day...).  See this issue for more details: https://github.com/bazelbuild/bazel/issues/4508
If the bind above doesn't work, then probably the most expedient solution is to change the config_settings in your local version of tensorflow to use @androidndk//:toolchain instead of //external:android/crosstool until this is sorted out with tensorflow. This is not so great because it makes upgrading tensorflow harder, and requires that you vendor the source code (which you might already be doing), but again it might be the most expedient.
Sorry for "catch-22" -- I should be a little more precise. "Catch-22" is when you have a problem and the solutions for it mutually conflict. So using --crosstool_top=//external:android/crosstool with the bind might fix one set of config_settings, but could cause other config_settings to break, so it's a "catch-22".

Hi， @ahumesky
The bind mentioned above doesn't work all the time. So i tried to change  the //external:android/crosstool in my local version.
Sorry, The external is not my customized directory but is generated by bazel (a cache directory), which location is ~/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external in my machine.
I have moved all  //external:android/crosstool to @androidndk//:toolchain located in above external directory manually. Finally, it works well. By the way, is there an update for above change when tensorflow will upgrade in the future?
Because it is not an elegant way.
Thanks for explaining the Catch-22.
Thanks again.

Hi, @ahumesky
I have changed api_level value at the top-level of my WORKSPACE.
I found that android_ndk_repository(name = "androidndk", api_level=26) is valid, but android_ndk_repository(name = "androidndk", api_level=25) is error.
Is 26 the smallest number of api level ?
Thanks.

Can you share what the error is?

Hi, @ahumesky I have changed api_level value at the top-level of my WORKSPACE. I found that android_ndk_repository(name = "androidndk", api_level=26) is valid, but android_ndk_repository(name = "androidndk", api_level=25) is error. Is 26 the smallest number of api level ? Thanks.

Hi, @ahumesky
There is no error but a phenomenon when I set api_level=25.
I have no question about this issue. I close this issue now.
Thanks a lot.
Best wishes.


Deferrable constraints

Hello,
On some DBMS (like PostgreSQL) it is possible to have deferrable constraints.
This is useful and we use this feature for almost all of our Foreign Key constraints.
It seems that it is not possible to have this feature when using the "addForeignKey" function.
It there something that I missed or it is not implemented in Phinx?
If it is not implemented, is there any chance to have this feature supported in Phinx?

PR welcome


Can access UMD globals from modules (regression?)

TypeScript Version:  Version 3.1.0-dev.20180804

Search Terms: UMD module import export as namespace
Code
// declaration.d.ts
export = angular;
export as namespace angular;

declare namespace angular {
  export interface Scope {}
}
export {};

// user.ts
export {}; // make me a module
let scope: angular.Scope;  // no import!

Expected behavior:
Should fail to compile, as user.ts is a module, but has no import for angular. The global should only be available in scripts, according to the docs:
https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#support-for-umd-module-definitions
Actual behavior:
Compiles without errors.
Playground Link: n/a, needs multiple files.
I believe this to be a regression, at least at some point TS worked as documented, giving an error here.

Apparently this is specific to types, for values TS works as expected:
console.log(angular.x);  // fails with angular.x being a variable

@RyanCavanaugh is this a documentation bug then, if working as intended?

@mprobst the docs say "global variable" and a type/namespace is not a variable. We'd take a PR to the TS Handbook repo if you want to add a clarifying remark

Mh, OK.
For some feedback: I'm maintaining a rather large TypeScript code base (Google's internal monorepo) that has several definitely typed libraries that people depend on. We had expected that the "needs import" restriction applies to all use from a module.
Allowing non-imported use is problematic for us:

it means code relies on global "background" type definitions.
it obscures code dependencies
it circumvents the "must have explicit build level dependency on all imports" constraints we implement in bazel
it causes code to inconsistently import the module with one prefix for values and use its types with another prefix (in particular for AngularJS, ng vs angular)

We can work around by removing those export as namespace statements in our vendor'ed copy of DefinitelyTyped, but at least for us, this feature is kind of working against code maintainability and our engineering goals in the large monorepo :-)

Good feedback - you may want to voice that in #10178 as well

@RyanCavanaugh Would you mind explaining why the team decided to have UMD namespaces visible in modules when they can be imported?

Another Stack Overflow user confused by UMD global types being accessible from modules.


What is the status of the repo?

Hello @robfig.
Nice job for putting this awesome library. I would like to know the status of the repo because it seems that some cool PRs have been provided, however no action or feedback have been taken on them.
Knowing the status of the repo can help us a lot.
Thanks.

There's a fork I'm working on with @gdgvda. We are already looking at some cool PRs from here as a starting point. For anyone interested, we would love to consider your proposals.

It would be good to start a process to transfer maintainership @robfig so that the work in the PRs could be appreciated.

Hello @robfig. Nice job for putting this awesome library. I would like to know the status of the repo because it seems that some cool PRs have been provided, however no action or feedback have been taken on them. Knowing the status of the repo can help us a lot.
Thanks.

@robfig hello ?


release: v1.0.0a14.post2

Merged in tag https://github.com/inveniosoftware/invenio-files-rest/tree/v1.0.0a14.post2


The height of the code smart hint is only one line

Issue Type: Bug

Type "set", a prompt will appear.
The height of this prompt is only one line.

VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:30:02.420Z)
OS version: Darwin x64 18.7.0

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2200)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
2, 2, 2

Memory (System)
16.00GB (0.19GB free)

Process Argv
--crash-reporter-id a4dfe931-70b3-4b59-8dac-6c4620b85c7e

Screen Reader
no

VM
0%

Extensions (1)

Extension
Author (truncated)
Version

vscode-language-pack-zh-hans
MS-
1.52.2

See https://github.com/microsoft/vscode/issues/110554#issuecomment-726624206

See #110554 (comment)

Works for me, thanks!

@hobeas Any clue how you got into this state? Did you resize the widget by any chance?

@hobeas Any clue how you got into this state? Did you resize the widget by any chance?

I haven't resized the widget. Even I haven't opened the settings for a long time.
This state appeared about last week. I guess it was caused after I updated v1.52.0.
Today I updated the new version v1.52.1 and saw that the problem still exists, so I submitted this issue.

ok, closing as duplicate.


updates to comply with SonarCloud quality checks

Codecov Report

Merging #60 (ea67eaf) into master (9b5c23a) will decrease coverage by 0.14%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #60      +/-   ##
==========================================
- Coverage   94.66%   94.52%   -0.15%
==========================================
  Files           9        9
  Lines          75       73       -2
  Branches        4        4
==========================================
- Hits           71       69       -2
  Misses          4        4

Impacted Files
Coverage Δ

src/app/auth/auth-service.service.ts
88.88% <ø> (ø)

src/app/auth/auth-guard.guard.ts
100.00% <100.00%> (ø)

src/app/footer/footer.component.ts
100.00% <100.00%> (ø)

src/app/header/header.component.ts
93.33% <100.00%> (ø)

src/app/home/home.component.ts
100.00% <100.00%> (ø)

src/app/landing/landing.component.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


feat(protocol): Custom contract to manage multi-sig prover for guardian tier

See this initial PR here: https://github.com/taikoxyz/taiko-mono/pull/14923
And the issue/discussion here: https://github.com/taikoxyz/taiko-mono/issues/14910
Moved it to a new PR, because previous was based on branch contestable-zkrollup, but we need the sgx eventually, so easier to use this branch as base now.

Maybe we should one admin-only function: replaceAddress(old, new)

We can use the changeGuardians() for that.


Reimplement check for non-regexp strings using RegexParser

This PR reimplements the check used in GpuStringSplit to determine if a string is a regular expression or not. The previous approach had limitations and now that we have a regular expression parser we can improve the check so that there are fewer false positives.
This change is needed to support the work for https://github.com/NVIDIA/spark-rapids/issues/3542

build


Appending to Metadata

Since setxattrs only works for replacement, I tried the below to append instead but metadata got deleted after !
a=fs.info('bucket/file')['metadata']
fs.setxattrs('bucket/file', kwargs={'test': 'me', **a} )
Any idea why ?

Closing as I figure it out the right syntax: **{'test': 'me', **a}
Will actually make a PR out of it for an enhanced version:

multiple blobs update in one call
use patch instead of put
allow other fixed meta settings e.g. content-type/-encoding

You could do
a = fs.info('bucket/file')['metadata']
a.update({'test': 'me', ...})
fs.setxattrs('bucket/file', **a)

Thanks but the put method wipes out all existing metadata, including Content-type if it was set before. Best is to use 'patch' in my opinion, which does append or replace only what is sent.

I don't know about PUT versus PATCH, feel free to experiment


ReleaseDC takes 2 arguments, not 1

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-releasedc

Fixed


CobiGen tutorial fails

Currently the Cobigen tutorial is failing. See for example this log file: https://github.com/devonfw-tutorials/tutorials/runs/5225406346?check_suite_focus=true
The first generation with CobiGen is successful. Then the input file is changed and another generation with CobiGen is failing.
This is because the Java project is not rebuilt after the entity class is changed.
Probably a buildJava("cobigenexample", false) command after the change file command could be the solution.

Hello, yesterday i created pull request for this issue https://github.com/devonfw-tutorials/tutorials/pull/201 with the proposed solution of rebuilding the project. The build still fails but the error has changed.
https://github.com/devonfw-tutorials/tutorials/runs/5231357532?check_suite_focus=true

@maybeec I will take this issue with me to discuss with the CobiGen team.
For now, I will remove the tutorial so we can keep the pipelines green while we investigate this issue.
@rvirod I will let you know when we have any news on this.
cobigen.zip


DeadlyReentry now has a minimum ModuleManager version.

DR comes with MM 2.6.5, so this makes sure that users actually have
that installed. :)

Look at me, merging my own PR! I'm living on the edge!


Specialize Hashtbl bucket representation

Benchmarks seem to indicate a minor improvement in hashtbl benchmarks:
Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90
  Time (mean ± σ):      34.7 ms ±   0.2 ms    [User: 33.4 ms, System: 0.9 ms]
  Range (min … max):    34.5 ms …  35.6 ms    84 runs

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90
  Time (mean ± σ):      32.5 ms ±   0.1 ms    [User: 31.2 ms, System: 0.9 ms]
  Range (min … max):    32.3 ms …  32.8 ms    91 runs

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90 ran
    1.07 ± 0.01 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 90

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90
  Time (mean ± σ):      23.1 ms ±   0.4 ms    [User: 41.8 ms, System: 1.3 ms]
  Range (min … max):    22.8 ms …  27.0 ms    127 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90
  Time (mean ± σ):      22.1 ms ±   0.1 ms    [User: 39.7 ms, System: 1.3 ms]
  Range (min … max):    21.9 ms …  22.6 ms    132 runs

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90 ran
    1.05 ± 0.02 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 90

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90
  Time (mean ± σ):      14.8 ms ±   0.3 ms    [User: 46.7 ms, System: 2.0 ms]
  Range (min … max):    14.3 ms …  17.6 ms    207 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90
  Time (mean ± σ):      13.9 ms ±   0.3 ms    [User: 43.4 ms, System: 2.0 ms]
  Range (min … max):    13.4 ms …  16.7 ms    219 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90 ran
    1.06 ± 0.03 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 90

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10
  Time (mean ± σ):     184.2 ms ±   1.1 ms    [User: 182.6 ms, System: 1.3 ms]
  Range (min … max):   183.6 ms … 188.2 ms    16 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10
  Time (mean ± σ):     174.4 ms ±   0.2 ms    [User: 172.9 ms, System: 1.2 ms]
  Range (min … max):   174.0 ms … 174.7 ms    17 runs

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10 ran
    1.06 ± 0.01 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 1 1_000_000 1000 10

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10
  Time (mean ± σ):     124.9 ms ±   0.9 ms    [User: 244.4 ms, System: 1.7 ms]
  Range (min … max):   124.3 ms … 127.8 ms    24 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10
  Time (mean ± σ):     122.5 ms ±   0.4 ms    [User: 239.8 ms, System: 1.7 ms]
  Range (min … max):   121.3 ms … 123.1 ms    24 runs

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10 ran
    1.02 ± 0.01 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 2 1_000_000 1000 10

Benchmark 1: kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10
  Time (mean ± σ):      69.7 ms ±   1.7 ms    [User: 263.8 ms, System: 2.6 ms]
  Range (min … max):    68.7 ms …  80.5 ms    43 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10
  Time (mean ± σ):      68.7 ms ±   0.4 ms    [User: 260.1 ms, System: 2.6 ms]
  Range (min … max):    67.6 ms …  69.4 ms    43 runs

Summary
  kcas-this/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10 ran
    1.01 ± 0.03 times faster than kcas-main/_build/default/test/kcas_data/hashtbl_bench.exe 4 1_000_000 1000 10

Benchmark 1: kcas-main/_build/default/test/kcas/xt_benchmark.exe 1 10000
  Time (mean ± σ):       7.3 ms ±   0.1 ms    [User: 6.3 ms, System: 0.7 ms]
  Range (min … max):     7.2 ms …   8.1 ms    409 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas/xt_benchmark.exe 1 10000
  Time (mean ± σ):       7.3 ms ±   0.1 ms    [User: 6.3 ms, System: 0.7 ms]
  Range (min … max):     7.2 ms …   8.1 ms    411 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  kcas-this/_build/default/test/kcas/xt_benchmark.exe 1 10000 ran
    1.00 ± 0.01 times faster than kcas-main/_build/default/test/kcas/xt_benchmark.exe 1 10000

Benchmark 1: kcas-main/_build/default/test/kcas/xt_benchmark.exe 2 10000
  Time (mean ± σ):      13.7 ms ±   0.1 ms    [User: 12.7 ms, System: 0.7 ms]
  Range (min … max):    13.6 ms …  14.1 ms    218 runs

Benchmark 2: kcas-this/_build/default/test/kcas/xt_benchmark.exe 2 10000
  Time (mean ± σ):      13.7 ms ±   0.1 ms    [User: 12.7 ms, System: 0.7 ms]
  Range (min … max):    13.6 ms …  14.0 ms    218 runs

Summary
  kcas-this/_build/default/test/kcas/xt_benchmark.exe 2 10000 ran
    1.00 ± 0.01 times faster than kcas-main/_build/default/test/kcas/xt_benchmark.exe 2 10000

Benchmark 1: kcas-main/_build/default/test/kcas/xt_benchmark.exe 4 10000
  Time (mean ± σ):      22.9 ms ±   0.1 ms    [User: 21.7 ms, System: 0.8 ms]
  Range (min … max):    22.7 ms …  23.2 ms    131 runs

Benchmark 2: kcas-this/_build/default/test/kcas/xt_benchmark.exe 4 10000
  Time (mean ± σ):      22.8 ms ±   0.1 ms    [User: 21.7 ms, System: 0.8 ms]
  Range (min … max):    22.6 ms …  23.2 ms    131 runs

Summary
  kcas-this/_build/default/test/kcas/xt_benchmark.exe 4 10000 ran
    1.00 ± 0.00 times faster than kcas-main/_build/default/test/kcas/xt_benchmark.exe 4 10000

Benchmark 1: kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      18.5 ms ±   1.7 ms    [User: 29.5 ms, System: 1.7 ms]
  Range (min … max):    16.8 ms …  21.6 ms    139 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (21.6 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 100000
  Time (mean ± σ):      18.1 ms ±   1.6 ms    [User: 28.8 ms, System: 1.7 ms]
  Range (min … max):    16.6 ms …  21.0 ms    145 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (20.6 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Summary
  kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 100000 ran
    1.02 ± 0.13 times faster than kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 100000

Benchmark 1: kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      34.2 ms ±   3.4 ms    [User: 56.8 ms, System: 2.3 ms]
  Range (min … max):    31.5 ms …  39.7 ms    76 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (39.3 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 200000
  Time (mean ± σ):      34.9 ms ±   3.6 ms    [User: 58.3 ms, System: 2.3 ms]
  Range (min … max):    31.4 ms …  39.6 ms    94 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 200000 ran
    1.02 ± 0.15 times faster than kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 200000

Benchmark 1: kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      67.2 ms ±   7.3 ms    [User: 114.5 ms, System: 3.5 ms]
  Range (min … max):    60.5 ms …  76.5 ms    39 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (75.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 400000
  Time (mean ± σ):      67.3 ms ±   7.3 ms    [User: 114.9 ms, System: 3.5 ms]
  Range (min … max):    60.8 ms …  76.6 ms    49 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Summary
  kcas-main/_build/default/test/kcas/xt_parallel_cmp_bench.exe 400000 ran
    1.00 ± 0.15 times faster than kcas-this/_build/default/test/kcas/xt_parallel_cmp_bench.exe 400000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 1 10000
  Time (mean ± σ):       3.8 ms ±   0.1 ms    [User: 2.7 ms, System: 0.7 ms]
  Range (min … max):     3.7 ms …   4.3 ms    739 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 1 10000
  Time (mean ± σ):       3.8 ms ±   0.0 ms    [User: 2.7 ms, System: 0.7 ms]
  Range (min … max):     3.7 ms …   4.1 ms    728 runs

  Warning: The first benchmarking run for this command was significantly slower than the rest (4.1 ms). This could be caused by (filesystem) caches that were not filled until after the first run. You are already using the '--warmup' option which helps to fill these caches before the actual benchmark. You can either try to increase the warmup count further or re-run this benchmark on a quiet system in case it was a random outlier. Alternatively, consider using the '--prepare' option to clear the caches before each timing run.

Summary
  kcas-this/_build/default/test/kcas/benchmark.exe 1 10000 ran
    1.00 ± 0.02 times faster than kcas-main/_build/default/test/kcas/benchmark.exe 1 10000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 2 10000
  Time (mean ± σ):       8.6 ms ±   0.0 ms    [User: 7.5 ms, System: 0.7 ms]
  Range (min … max):     8.5 ms …   8.9 ms    350 runs

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 2 10000
  Time (mean ± σ):       8.6 ms ±   0.0 ms    [User: 7.5 ms, System: 0.7 ms]
  Range (min … max):     8.5 ms …   8.8 ms    350 runs

Summary
  kcas-main/_build/default/test/kcas/benchmark.exe 2 10000 ran
    1.00 ± 0.01 times faster than kcas-this/_build/default/test/kcas/benchmark.exe 2 10000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 4 10000
  Time (mean ± σ):      13.6 ms ±   0.0 ms    [User: 12.5 ms, System: 0.7 ms]
  Range (min … max):    13.5 ms …  14.0 ms    220 runs

  Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 4 10000
  Time (mean ± σ):      13.6 ms ±   0.0 ms    [User: 12.5 ms, System: 0.7 ms]
  Range (min … max):    13.5 ms …  13.9 ms    220 runs

Summary
  kcas-main/_build/default/test/kcas/benchmark.exe 4 10000 ran
    1.00 ± 0.00 times faster than kcas-this/_build/default/test/kcas/benchmark.exe 4 10000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 1 200000
  Time (mean ± σ):      35.5 ms ±   0.2 ms    [User: 34.3 ms, System: 0.8 ms]
  Range (min … max):    35.1 ms …  35.9 ms    83 runs

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 1 200000
  Time (mean ± σ):      35.5 ms ±   0.2 ms    [User: 34.3 ms, System: 0.8 ms]
  Range (min … max):    35.0 ms …  36.1 ms    85 runs

Summary
  kcas-main/_build/default/test/kcas/benchmark.exe 1 200000 ran
    1.00 ± 0.01 times faster than kcas-this/_build/default/test/kcas/benchmark.exe 1 200000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 2 200000
  Time (mean ± σ):     131.9 ms ±   0.4 ms    [User: 130.4 ms, System: 1.1 ms]
  Range (min … max):   131.3 ms … 132.7 ms    22 runs

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 2 200000
  Time (mean ± σ):     132.0 ms ±   0.5 ms    [User: 130.5 ms, System: 1.1 ms]
  Range (min … max):   131.2 ms … 133.0 ms    22 runs

Summary
  kcas-main/_build/default/test/kcas/benchmark.exe 2 200000 ran
    1.00 ± 0.00 times faster than kcas-this/_build/default/test/kcas/benchmark.exe 2 200000

Benchmark 1: kcas-main/_build/default/test/kcas/benchmark.exe 4 200000
  Time (mean ± σ):     232.1 ms ±   0.4 ms    [User: 230.3 ms, System: 1.3 ms]
  Range (min … max):   231.5 ms … 232.8 ms    12 runs

Benchmark 2: kcas-this/_build/default/test/kcas/benchmark.exe 4 200000
  Time (mean ± σ):     232.2 ms ±   0.3 ms    [User: 230.5 ms, System: 1.4 ms]
  Range (min … max):   231.9 ms … 232.8 ms    12 runs

Summary
  kcas-main/_build/default/test/kcas/benchmark.exe 4 200000 ran
    1.00 ± 0.00 times faster than kcas-this/_build/default/test/kcas/benchmark.exe 4 200000


Change URL CC license in footer

"Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 4.0 International License." in the footer should refer to https://creativecommons.org/licenses/by/4.0/.

@Driesvanransbeeck any more info? Do i just choose where to put this?


Trying to get in touch regarding a security issue

Hello 👋
I run a security community that finds and fixes vulnerabilities in OSS. A researcher (@scgajge12) has found a potential issue, which I would be eager to share with you.
Could you add a SECURITY.md file with an e-mail address for me to send further details to? GitHub recommends a security policy to ensure issues are responsibly disclosed, and it would help direct researchers in the future.
Looking forward to hearing from you 👍
(cc @huntr-helper)

Hi hello.
The email address for my GitHub account is below.

<EMAIL_ADDRESS>

Also, regarding the "SECURITY.md" file, I would like to ask you to create one.
Please describe the following two points.

Supported Versions
Reporting a Vulnerability

If you don't mind, please use Hunrt for communication.
Thank you very much.

Hello @psmoros
Here's https://github.com/uasoft-indonesia/badaso/blob/main/SECURITY.md
Thanks in advance


👤added: Username instead of 'You' when sending messages.

Summary
When the user sends a message, instead of showing 'You' in the sent message, and the agent's name in the received message with whom he is talking, the user's name will be shown, the same one that appears just below in the left corner in Nav. Also added in place of 'You', the translation for its respective language.
Change Type

[x] Translation Update

Before:

After:

Thanks for this! I would prefer if it was a setting based on preference. Could you add it to Settings under Account? if you need guidance on this, let me know.

Thanks for this! I would prefer if it was a setting based on preference. Could you add it to Settings under Account? if you need guidance on this, let me know.

something like this?

Yes except the message should me much shorter and active tense. “Display username in messages”

It should not default, because You is what official ChatGPT shows.

Thanks for this! I would prefer if it was a setting based on preference. Could you add it to Settings under Account? if you need guidance on this, let me know.

Sorry for the delay in responding. I was at work all day and only managed to address what you asked for tonight. I would have appreciated your guidance; it would have been much quicker and simpler for me. Anyway, here it is, and if you want me to change anything, just let me know. 🙂

It should not default, because You is what official ChatGPT shows.

I left it as disabled by default, the only thing I thought would be interesting is that, just like in ChatGPT, the translation of 'You' to its respective language like 'You' in pt-BR.

It should not default, because You is what official ChatGPT shows.

I left it as disabled by default, the only thing I thought would be interesting is that, just like in ChatGPT, the translation of 'You' to its respective language like 'Você' in pt-BR.

Thanks so much for the work on this. Going to review it now and I can resolve the conflicts. Sorry I couldn't provide guidance earlier on!

not a big mess but I made a mistake in pushing the resolution of merge conflicts to your repo! 😬
I've started a new PR with your original commits to clean this up, sorry! https://github.com/danny-avila/LibreChat/pull/1592
I would fix your fork's main branch but I don't have access.


code coverage: Remove coveralls

Currently, coveralls cannot make any comment in github pull request
regarding code coverage status even the data is uploaded to their
website correctly(showed in travis CI log).
Since the codecov.io is working well. Drop the use of coveralls.

Haven't we used one for unit tests and the other for integration tests?

Haven't we used one for unit tests and the other for integration tests?

I failed to get it coveralls up and running. It seems the coveralls works well if uploaded by
travis host instead of container. I read the python coveralls code, still no luck on why it fails
to show in nmstate project page and making github comment. Only got the URL holding
coverage data.
We can do that after somehow we got coveralls works again.

Closing as I am using personal master branch a lot which should not how unmerged changes.
This is trivial issue. We can review it again when we have time.


#706 Grid<> should have extra fields: cellWidth and cellHeight of type int

add properties cellWidth and cellHeight to Grid<>;
add new constructor which takes cellWidth and cellHeight along with other parameters;
add tests to check that new constructor and getters are working as intended;
closes #706

Codecov Report

Merging #852 into dev will increase coverage by 0.25%.
The diff coverage is 15.09%.

@@             Coverage Diff              @@
##                dev     #852      +/-   ##
============================================
+ Coverage     59.45%   59.71%   +0.25%
- Complexity     2307     2322      +15
============================================
  Files           251      251
  Lines         11317    11339      +22
  Branches       1025     1032       +7
============================================
+ Hits           6729     6771      +42
+ Misses         4279     4259      -20
  Partials        309      309

Impacted Files
Coverage Δ
Complexity Δ

...com/almasb/fxgl/cutscene/dialogue/DialogueScene.kt
0.00% <0.00%> (ø)
0.00 <0.00> (ø)

...almasb/fxgl/app/services/FXGLAssetLoaderService.kt
82.42% <0.00%> (-1.02%)
27.00 <0.00> (ø)

fxgl/src/main/kotlin/com/almasb/fxgl/dsl/FXGL.kt
11.05% <0.00%> (-0.54%)
1.00 <0.00> (ø)

...rc/main/java/com/almasb/fxgl/pathfinding/Grid.java
96.96% <77.77%> (-3.04%)
40.00 <6.00> (+3.00)
:arrow_down:

...lin/com/almasb/fxgl/core/collection/PropertyMap.kt
89.87% <100.00%> (ø)
38.00 <0.00> (ø)

.../src/main/kotlin/com/almasb/fxgl/app/LoopRunner.kt
97.61% <0.00%> (+2.38%)
12.00% <0.00%> (+1.00%)

...put/src/main/kotlin/com/almasb/fxgl/input/Input.kt
87.98% <0.00%> (+6.73%)
128.00% <0.00%> (+7.00%)

.../main/kotlin/com/almasb/fxgl/input/InputCapture.kt
50.00% <0.00%> (+50.00%)
4.00% <0.00%> (+4.00%)

Continue to review full report at Codecov.

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


Serialize settings as JSON when sending them to the main process

Fixes #16789
Config settings of type Color should be written to the config file as a string like #af01cd. To achieve this, the class overrides toJSON .
When I refactored the config system to IPC settings to the main process for writing, this behavior was inadvertently broken because sending a value over electron's IPC does not serialize it as JSON; it uses its own serialization mechanism that does not preserve objects' toJSON methods.

Thanks! I dug far enough to figure out why it was breaking, but not where 😆.

@Arcanemagus Yeah, thanks so much for the info in your report. That made it very easy to fix!


Fix #244 - Fix failing test with libxmlsec-1.2.36, also make libxmlse…

Fix failing test with libxmlsec-1.2.36, also make libxmlsec version available from Python.

I rebased it on #250 who fixed precommit.ci error with Python 3.11, so this should merge after #250. Would be nice if someone who understands XML singing would look at my commit (b0f48a3c5e4393508b38cec052d0c657f1f11c55) and could confirm, that it's OK that<X509SubjectName> and <X509SKI> are empty. Maybe @lsh123 himself could help? :-)

If I understand the test correctly, the test signs file with an RSA key from "rsakey.pem". In this case, there is no certificate for the key thus there is nothing to write out any X509 information into the output. I am not sure if this is a good test but the current output is correct.
You should consider using a key + cert from a pkcs12 file as a more realistic example. That should populate the X509Data (you should probably remove the X509Certificate content as well so it is "filled in" by xmlsec during signing).

Side note -- would be great if you can test 1.3.0-rc candidates (latest is RC3: https://github.com/lsh123/xmlsec/discussions/612). There are quite a lot of changes and some are API/ABI breaking (https://github.com/lsh123/xmlsec/discussions/593).

If I understand the test correctly, the test signs file with an RSA key from "rsakey.pem". In this case, there is no certificate for the key thus there is nothing to write out any X509 information into the output. I am not sure if this is a good test but the current output is correct.

There is also ctx.key.load_cert_from_file(self.path('rsacert.pem'), consts.KeyDataFormatPem), so certificate data should be there. Point is that with libxmlsec version prior to 1.2.36, the elementes <X509SubjectName> and <X509SKI> are filled but with 1.2.36 they are empty.
I found that you marked the elements DEPRECATED (in docs/api/xmlsec-x509.html), so I figured that this might be intentional. Is it?

Sorry I missed that there is a cert. In this case something is not correct. XMLSec should write out all the X509Data children nodes. Not sure what do you mean by "deprecated", which specific function was deprecated?

Not sure what do you mean by "deprecated", which specific function was deprecated?

Not a function, but elements, you can see it in the commit from you I linked (github folded the docs/api/xmlsec-x509.html because the diff is too big), you can see it also here: https://github.com/lsh123/xmlsec/blob/01e95e393275fee0328e37ca14f522eedc640810/docs/api/xmlsec-x509.html#L94

Not sure what do you mean by "deprecated", which specific function was deprecated?

Not a function, but elements, you can see it in the commit from you I linked (github folded the docs/api/xmlsec-x509.html because the diff is too big), you can see it also here: https://github.com/lsh123/xmlsec/blob/01e95e393275fee0328e37ca14f522eedc640810/docs/api/xmlsec-x509.html#L94

Ah that's just to move this code from public to private :) It's internals and nobody should be using it outside of xmlsec itself.

But indeed I see empty nodes in 1.2.37:
 <X509SubjectName/>
 <X509SKI/>

Let me investigate (https://github.com/lsh123/xmlsec/issues/616)

Thanks, it's indeed a change in behavior and the fix is here:
https://github.com/lsh123/xmlsec/commit/c4529d3661278aa1b4657d03406871bae3aa9f12
It shouldn't have any real world impact since XMLSec code in 1.2.36 / 37 was selecting the "best" output (X509Certificate first, then subject, then ....). But nevertheless, I will rollout 1.2.38 with this (and a couple other bug fixes) soon.

So I added file with signed result for xmlsec-1.2.36 and 37 so tests will pass. Also added function for the version of xmlsec so we can do specific decisions on xmlsec version in clear way. Ready for CR.


Cannot switch thread local variables function-wise during backward propagation

We cannot switch thread local variables on a granularity of Chainer functions, that could be problematic in some situation.
For example, we can temporarily enable/disable cuDNN by switching the value of chainer.config.use_cudnn (e.g. with using_config('use_cudnn', False)). But in backward propagation, we cannot disable it only a part of functions in a computational graph.
Let's consider the following chain:
class Model(Chain):

    def __init__(self):
        with init_scope():
            self.l1 = L.Convolution2D(...)
            self.l2 = L.Convolution2D(...)
            self.l3 = L.Convolution2D(...)

We can disable cuDNN only in the second convolution as follows:
    def __call__(self, x):
        h = self.l1(x)
        with using_config('using_cudnn', False):
            h = self.l2(h)
        return self.l3(h)

But as all backward propagation of Chainer functions are embedded in Variable.backward, we cannot switch it without editing the library code.
This problem is reported by aoikaneko in the Japanese user forum. Thank you!

I summarized the offline discussion:

Currently some functions are preserving cuDNN status (whether cuDNN was used) in forward path as an attribute of the node. This is because cuDNN backward in such functions expects the input to be retained in the forward path.
e.g., https://github.com/chainer/chainer/blob/v4.0.0b3/chainer/functions/activation/relu.py#L31-L47
Use of iDeep is also determined by the thread-local configuration, so there is a same issue as cuDNN.
After the discussion, it may be insufficient to just keep boolean flag, as the backward of the FunctionNode may be implemented with another FunctionNode call.  In such case we need to keep the config value (e.g., never) used in the forward stage instead of a boolean flag, and use that config in the backward path.
Framework-level solution (e.g., preserve all configuration values in forward and restore it in backward, by inserting code around function hook invocation) sounds possible, but we need to consider the overhead this change will introduce.
We should also discuss what config should be kept from forward to backward. (e.g., is it OK to run backward with debug config value used in forward?)

Any update on this issue?


fix logic for kubernetes version

Notes for Reviewers
This PR fixes #7582
Signed commits

[x] Yes, I signed my commits.

Codecov Report
Patch coverage has no change and project coverage change: -4.14 :warning:

Comparison is base (e54b47f) 16.10% compared to head (b198cfd) 11.97%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #7587      +/-   ##
==========================================
- Coverage   16.10%   11.97%   -4.14%
==========================================
  Files         120      120
  Lines       16655    16655
==========================================
- Hits         2683     1995     -688
- Misses      13485    14338     +853
+ Partials      487      322     -165

Flag
Coverage Δ

gointegrationtests
?

unittests
11.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 12 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

@MUzairS15
To ensure consistency, can we merge this PR?
We already merged the corresponding changes in remote provider.

Yes ready to merge from long.


Probabilities are calculated incorrectly

When sub-patterns are eliminated, it shouldn't change the relative probabilities of the overall patterns.  (Pattern: "Fluctuating", "Small Spike", etc.  Sub-pattern: what day of the week the spike is on, etc.)
Looking at the game code, it first chooses a pattern with certain probabilities based on the previous week's pattern, then independently chooses a sub-pattern for that pattern (except for Decreasing which doesn't have a choice of sub-patterns).  So only when a pattern is eliminated from consideration have we learned anything new about that initial decision.
Example from my week so far: Previous week Fluctuating.  Buy for 96.  Prices 86, 81, 77.
On Sunday, all we know is the previous week's pattern.  Thus this week's pattern could be Large Spike (35%), Small Spike (30%), Fluctuating (20%), or Decreasing (15%).  So far so good.  Adding in the prices through Tuesday AM eliminates Fluctuating as a possible pattern, and also eliminates a few possible subpatterns of Large Spike and Small Spike.  What have we learned about the game's initial choice of pattern?  Only that it didn't choose Fluctuating.  Thus the overall probabilities of the remaining patterns should be Large Spike (35%/80% = 43.75%), Small Spike (30%/80% = 37.5%), and Decreasing (15%/80% = 18.75%), with the probabilities of the remaining sub-patterns apportioned within those overall probabilities.
Instead, Turnip Prophet appears to be looking at the probabilities of all the non-eliminated sub-patterns and assigning probabilities to the patterns from those, showing Large Spike (55.5%), Decreasing (38.8%), Small Spike (5.66%).
Give me a few days to look into Turnip Prophet's code and I can submit a pull request to fix it.

It's certainly possible that people more knowledgeable than I have already considered this and come to a different conclusion as to what the prices tell us about the initial choice of pattern.  If so, feel free to close this issue. :)


Update README.md

Adding information for also downloading pi 4 firmware

This PR should be rejected because the content isn't correct


New injection manager for Helidon

New implementation of a Jersey injection manager to handle separation of JAX-RS applications. The new injection manager uses two underlying managers: one that is shared among all applications and one to register classes and singletons returned by the application. For a Helidon application that defines N JAX-RS applications, there will be N+1 of these core managers.
Lookups and injections are carried out by first consulting the shared manager and then the one for the application. This may potentially add some runtime overhead that would need to be tested using our micro-benchmarks.
PR #3166

The only (naïve) question I have is: shouldn't you check the application-specific InjectionManager first and then fall back on the shared one?

The only (naïve) question I have is: shouldn't you check the application-specific InjectionManager first and then fall back on the shared one?

There's no overlap between them, and most of the beans will be in the shared one, so checking it in the reverse order will be more costly.


Correct beautifulsoup syntax, cleanup json, handle missing etymology

This should work better.
However, I have to use this branch:
https://github.com/andersjohansson/thesaurus/tree/ajfixes-working
Because I can't get it working with the asyncio functions. As I understand it it needs to be called in a different way, maybe update documentation for that?

Thanks for your contribution!
I add instructions on the usage of fetching list of words in Readme


float array to SimpleTensor or ICLTensor

Problem description:
How should I convert float array to ICLTensor or SimpleTensor so that tensor can be used in APIs like CLGemm?

Hi @shubh809
Please take a look at the documentation explaning how to move data to/from ACL's tensors: https://arm-software.github.io/ComputeLibrary/v19.05/architecture.xhtml#S4_6_4_working_with_objects
In ACL it's a good practice to use the helper function execute_window_loop() for this purpose.

Thanks


[New Snap] ETHSign Keychain

Checklist
All items in the list below needs to be satisfied.

[ ] Is the Snap repository publicly accessible and linked in this ticket? https://github.com/EthSign/keychain-snap
[ ] Is the Snap distributed on npm and linked in this ticket?
[ ] Has an audit been performed and the audit report attached or linked in this issue?
[ ] Is a complete list of discovered vulnerabilities from the audit documented in this issue?
[ ] For vulnerabilities that have been deemed necessary to be addressed, are the links to the fixes attached to this issue?
[ ] For vulnerabilities that have been deemed not necessary to be addressed, is a reason for each of them documented in this issue?
[ ] The corresponding pull request in this repo has been merged.

Audit report: ethsign_keychain_audit_final.pdf

Discovered vulnerabilities:

OS-ETH-ADV-00 [med] | Insecure Signature-Based Authorization

Fixed in commit 3716c36. See audit report for details.

OS-ETH-ADV-01 [med] | Insecure Encryption

Fixed in 8d59cf4. See audit report for details.

OS-ETH-ADV-02 [low] | Denial Of Service Via Batching

Fixed by introducing a patch on the back-end server, which is now rate-limited by one request per seven seconds and has a batch limit. See audit report for details.

OS-ETH-SUG-00 | GraphQL Injection

Informational only. Not addressed.

OS-ETH-SUG-01 | Vulnerable NPM Packages

Informational only. Not addressed.

OS-ETH-SUG-02 | Validate Remote Procedure Call Parameters

Informational only. Not addressed.

OS-ETH-SUG-03 | Information Disclosure Via Errors

Informational only. Not addressed.


Is this project still actively developed?

Hi!
We're potentially forward-porting some of this code to fabric 1.4.0 and we're wondering if this project is still active on your end? If so, we are wondering what the roadmap for future use and development for this project looks like.
Thank you so much for your time!

The project right now is not active. What's the function you want to port to fabric 1.4.0.

Currently, we're looking to port features in this order -

Initial token generation.

Token transactions.

Support for decentralized autonomous organization activities, such as voting with tokens as stakes.

We're currently trying to port the code in small, manageable pieces by moving the minimum we need to a fork of Fabric 1.4.0. Any advice that you could give on this process would be great!
Cheers and thanks!

I have an additional question -
How did you manage to debug the go code running in the docker containers when you were changing fabric? It looks like inkchain-baseos is not based off of the golang:1.11.6 image, and therefore doesn't have go available after deployment.

@bryanedds Fabtoken already introduced int fabric 2.0, did you guys look at that?

We don't debug the code.
发自我的 iPhone

在 2019年4月18日，下午12:04，Bryan Edds<EMAIL_ADDRESS>写道：
I have an additional question -
How did you manage to debug the go code running in the docker containers when you were changing fabric? It looks like inkchain-baseos is not based off of the golang:1.11.6 image, and therefore doesn't have go available after deployment.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Catch up changes

Hi @imerzan  what's the reason you removed lot of my code changes without any notice? Did they cause any problems to you?
After your modification, the library is not usable anymore to me :-(

I hope it was just an unintentional mistake, prehaps you based your PR on a very old version of the files

Error while I was fetching upstream changes disregard

i had not approved any PRs that i remember...


Implements DeleteRecord

This commit implements the DeleteRecord endpoint. It firstly checks
whether the record exists, if does, deletes, otherwise returns NotFound.
Closes #9

/retest

/retest


Ensure endianness

TypedArrays use native endianness but a lot of algorithms here assume a specific endianness. We need to find a efficient way to switch between them. Checking endianness is as simple as:
var write = new Uint16Array([0xffdd])
var check = new Uint8Array(write.buffer)[0] === 0xff ? 'big' : 'little'

I wrote this https://github.com/mafintosh/convert-endianness to easily deal with these situations
Just noting that we should heavily optimise for cases with LE, as very few systems have BE