[flink] create table validate options

Purpose
A wrong table parameter can also be successfully built. I think it need validate options.

Tests
SchemaChangeITCase#testCreateTableWithInvalidOption
API and Format

Documentation

In executing the test cases for Hive3, the aforementioned problem was encountered.
cc @JingsongLi

Hi @MonsterChenzhuo , it is really hard to validate options.

We have so many options.
Some options have fallback options.
Issue of version compatibility, in some cases, older versions ignore some optimization options of newer versions.

Hi @MonsterChenzhuo , it is really hard to validate options.

We have so many options.
Some options have fallback options.
Issue of version compatibility, in some cases, older versions ignore some optimization options of newer versions.

😂


OpenVINO: Constant display error

Netron app and version: netron-7.9.9

Steps to Reproduce:

netron model.xml --host <IP_ADDRESS> --port 8081

@ylei1 please share a file to reproduce the issue, explain what the issue is and work with the OpenVINO team to submit a fix.

single-small-fq.zip
Here is a single block that I used for testing, as you can see, the netron parsed -1.847991704940796 to 0.23774106800556183 wrongly. Couldyou give me some advice why this error occurs?

@ylei1 opening the file shows below. Can you investigate or debug or your machine and check it is the correct file?

@ylei1 opening the file shows below. Can you debug on your machine and check it is the correct file?

Yes, I think it it correct


Sort by logging-state

Would be nice, if it would be possible to sort a list by the logging-state.
For example good for offline-logs, to easy find the logged caches.
Maybe two-step sorting: first by state, second by time?
Thanks

@Gacksi Have you looked at the History menu? From the main screen select options menu (same as you use to access settings) and there is a History option.
It will display caches that have been logged offline and online sorted by time logged.

Solved my problem! But maybe a sort-option would be also possible


First access of location assert screen does not show correct location.

The correct location of the hotspot is not shown when first going to location assert screen
Goto a hotspot that you have never gone to the location assert screen before and manage / location assert, select IOT and the default location it shows is SF
Go back to manage and press location assert again, the IOT and it shows the correct hotspot location with the green dot.
Reboot of phone sometimes seems to clear the correct location and you need to do this again
Sometimes it does not
On Android 12

Fixed in latest release on testfliht


BUG: fix stim_channel/misc usage in Sleep stage classification tutorial

Reference issue
Fixes #10360.
What does this implement/fix?
Fix arguments (stim_channel, misc) of read_raw_edf in the Sleep stage classification tutorial.

Thanks @rcmdnk!


Add missing Variable.Type null check.

Fixes #1412.

The fix is simple and so is the test but I'm worried. Such variables most probably have types but we just as probably skip walking these types of types (that's right!). So could you debug the case of such a variable and see if this is the case?
The code's at https://github.com/mono/CppSharp/blob/master/src/CppParser/Parser.cpp#L3388. You could help yourself with:
if (Var->name == "variable") // the name from your test
    __debugbreak();

You'd just have to enable native debugging in the project settings of the respective executable (presumably CSharp.Gen.exe since your test is in CSharp).

I assumed it was ok for an auto variable that depends on templates to be null. I just checked and the nullptr is returned from                         https://github.com/mono/CppSharp/blob/3ffa42aa2fd4ea9ff432660f5eb579701c609f17/src/CppParser/Parser.cpp#L2809

@josetr thank you for tracking it down. @tritao do you think there's anything we can do here?

We usually shy away from null checks for types in the AST layer since it usually just hides bugs.
In this specific case, we probably need to implement the type parsing in the parser layer.
That said, I don't think that would be a good use of time for anyone right now, since its not blocking anything.
So I am fine with merging this workaround, I would just request that you add a comment above the null check explaining the problem and/or linking to the issue.

@josetr the variable should definitely have some type but I cannot tell how long it would take to find it. It might as well be a bug in our version of Clang. So please just add 2 TODO comments, at your fix in C# and at the line you found in C++, and I'll merge.


Template Generation Bug in ParcelableArrayListNavTypeTemplate

Hello, just found out that you have a small typo in ParcelableArrayListNavTypeTemplate line 58:
                "[" + value.joinToString(encodedComma) { serializer.toRouteString(it) } + ]"
it ends in a compilation error, so it is currently not possible to use an ArrayList with a Parcelable as a destination argument.
Please fix the missing ":
                "[" + value.joinToString(encodedComma) { serializer.toRouteString(it) } + "]"

Thanks for reporting and checking the root cause 👏
That probably took you some time!
Will fix it today still probably!

Fixed, will be in today's release. Sorry it took me way longer than expected.. these days have been crazy with time 😕


Turn off rendering inner HTML by default

As a side effect of fixing ryandrewjohnson/react-localize-redux#11, inner HTML is rendered by default. To me, this seems problematic for two reasons:

It's unexpected; if I am passing a string in to be translated, I expect a string back. There are some instances where it may make sense to pass HTML through without rendering (for example, inside multi-lingual code samples).
It's a security risk; if user-generated content is ever passed through translate, it could cause injection of HTML elements and allow an XSS attack. An example of a use case for translating user-generated content is if you have crowd-sourced translations (either of general site content, or of user-submitted content).

I suggest turning this off by default. This PR includes:

Tests of my suggested behavior (off by default, can explicitly request inner rendering)
Code to make the tests pass

Thanks for sending this over. I like the idea of having the additional parameter to control the rendering of HTML, but I'm not in agreement with having it set to false by default.
If you're cool making these couple updates to the PR then I'd be good to merge it.

Change the additional argument to be an options object instead of a single boolean value. This will allow for additional options to be added in the future if needed without introducing breaking changes. Something like this...

const defaultOptions = {
   renderInnerHtml: true
};

return (value, data, options) => {
   const translateOptions = { ...defaultOptions, ...options };
   ...
}

Also add this options object so it can be added to localize as an additional argument as well. This way it will stay in sync with getTranslate.

Change the default value of renderInnerHtml to true instead of false. Here is my reasoning for that:

Although there could be potential security risks if you're loading translation content from third party sources, I believe a lot of people will be using their own data that they control. That being the case I think it makes more sense to have the user who is loading third-party (un-trusted) content to be the one to set renderInnerHtml flag to false to turn off that feature.
I have been giving some thought on enhancing the HTML detection to also include some checks for malicious scripts as well. In this case if one of these malicious scripts was detected the renderInnerHtml would be forced to false. If you have any interest in helping out with this let me know. It wouldn't be to catch all script injection scenarios, as that would be nearly impossible, but at least it could weed out the most obvious ones.

Let me know what you think.

I updated to use an options object instead. I went the route of putting it in state since that seemed to be the easiest way to get it consistent across the board (adding an options argument to pass into translate seems like a bad developer experience since then the developer would have to manage where that options object lives).
Could you check that the localize component works as you would expect? I honestly did not test it, although I expect it to work since the selector passes tests and the state should be the same here as it is in those tests. The tests just cover the pure functions elsewhere.
I did change renderInnerHtml to default to true, but I strongly disagree with the reasons for doing so. In my mind, the only reason to keep it true is because changing the default would be a surprise update that would break some people's code. I would suggest changing it to false when you bump the major version in the future, for these reasons:

It's true that most people use data under their control, however -- React already makes it so you have to consciously think about setting inner html, and it's off by default. Having your lib have it off by default as well fits the principle of least surprise.
HTML detection checking for malicious scripts is a bandaid over a bullet hole, in my opinion. It will give the appearance of security but you're playing whack-a-mole with attackers. Not good, when you can solve the problem by having the default be the secure option.
In general, I think the default should be for security, not for convenience. If you want this option on, it's not hard to add a setting to enable it one time. But if you don't need this option on, then you probably won't think about it -- and suddenly most users are living in a less secure world, because the default was less secure.

Food for thought. As it stands, I think that the changes fit your criteria. Let me know if you need anything else in this PR, and please consider changing your stance on the default, when you have the option to change it (when other breaking changes are made would be a good time).

Thanks for the update. I'm just reviewing them now, and working on tweaking things on my end, and will push when I'm done.
In regards to setting the renderInnerHtml to false by default you raise some good points. Especially the point you made where it makes sense to follow React's settings, which is to have this option off by default. I'm still trying to decide whether to change this now, and introduce the breaking change, or wait for some other breaking changes like you mentioned.

Awesome. If you want me to do any of the tweaks, let me know. I know the burden on maintainers can be high so if there's anything you prefer me to handle, feel free to throw it back my way.

Thanks for the offer I will definitely keep that in mind. In terms of the tweaks I've been thinking I may make a more significant change in how things work. Currently we have the setLanguages action that really only gets called once when bootstrapping your application. Now we're adding this setOptions action, which again would primarily only be called once, and usually when the app bootstraps.
I'm thinking instead of dispatching both these actions separately it makes more sense to maybe create a init action that handles both setting the languages and the options. So it would look something like this...
const defaultOptions = {
    renderInnerHtml: true,
};
export const init(languages, options = defaultOptions) {}

// with default options
store.dispatch(init(['en', 'fr']);

// override default language
store.dispatch(init(['en', 'fr'], { defaultLanguage:  'fr' });

// override renderInnerHtml
store.dispatch(init(['en', 'fr'], { renderInnerHtml:  false });

Also to avoid breaking changes I would keep the existing setLanguages action for now, and mark it as deprecated, and log out some sort of warning letting the user know this will be changing in next major version.
What do you think?

I like that a lot. I'm in favor of making that change. I have the time to
contribute to that change this weekend if you'd like me to do it.
On Tue, Aug 22, 2017 at 10:38 AM, Ryan Johnson<EMAIL_ADDRESS>wrote:

Thanks for the offer I will definitely keep that in mind. In terms of the
tweaks I've been thinking I may make a more significant change in how
things work. Currently we have the setLanguages action that really only
gets called once when bootstrapping your application. Now we're adding this
setOptions action, which again would primarily only be called once, and
usually when the app bootstraps.
I'm thinking instead of dispatching both these actions separately it makes
more sense to maybe create a init action that handles both setting the
languages and the options. So it would look something like this...
const defaultOptions = {
renderInnerHtml: true,
};export const init(languages, options = defaultOptions) {}
// with default optionsstore.dispatch(init(['en', 'fr']);
// override default languagestore.dispatch(init(['en', 'fr'], { defaultLanguage:  'fr' });
// override renderInnerHtmlstore.dispatch(init(['en', 'fr'], { renderInnerHtml:  false });
Also to avoid breaking changes I would keep the existing setLanguages
action for now, and mark it as deprecated, and log out some sort of warning
letting the user know this will be changing in next major version.
What do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ryandrewjohnson/react-localize-redux/pull/18#issuecomment-324047024,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxYBJhqnWBwaR2QdcOyqp-l3exF6C-Eks5saufvgaJpZM4O8s-8
.

I already have started, and I'm hoping to push it out tonight if possible. It would be great if you could review it though if you're up for it?

For sure! I can probably do that review on Thursday, otherwise it will be
on the weekend. I will make time for it.
On Tue, Aug 22, 2017 at 10:54 AM, Ryan Johnson<EMAIL_ADDRESS>wrote:

I already have started, and I'm hoping to push it out tonight if possible.
It would be great if you could review it though if you're up for it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ryandrewjohnson/react-localize-redux/pull/18#issuecomment-324051881,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxYBJtfo0eBzYBlNybCjBq_KZEY9jkkks5sauuJgaJpZM4O8s-8
.

That's great!
Another feature I've been thinking of adding is some sort of redux middleware to allow for translation data transformations. The use case being users who have existing data, or maybe some sort of third party translation data that isn't in the required format could then use the middleware to transform their data into the format required for react-localize-redux.
Haven't flushed out functionality, but middleware would allow the user to provide some sort of transformation function that would follow some sort of pre-determined interface. The transformation function would be written by user, and transform the user's data format to the required format for react-localize-redux. The middleware would then  listen for both addTranslation and addTranslationForLanguage and apply the transformation to the data coming in.
If this is something you'd be interested in helping out on let me know.

@ntietz I'm going to close this PR as we've diverted quite a bit from the original issue. I have created a new feature branch based off of your changes.
I have completed all the logic and I'm just working on updating the documentation, which I should be able to complete by tomorrow. When I'm done I'll create a new PR and have you review.


Nifti Orientations issues

Testing, sorry

Ok, Now I am sure.
I have a mesh and a volume NRRD.
The mesh and the NRRD volume match perfectly.
However, if I use the same volume as NIFTI, the mesh and the nifti doesn't match. It is wrong the orientations. The head in NIFTI is inverted, upside down

Hi @rwirz,
Yes there is something going on with the orientation, I am not sure where the problem is yet...

Are your test datasets available somewhere? (nrrd, nifti and the mesh)
Can I re-open the issue or did you figure it out?

Hi Nicolas,
I am using the MRI Head tumor volumes from 3D Slicer.
With NRRD is perfect as you see:

However, with NIFTI is wrong:

And the volumes with the tumor segmentation:
https://drive.google.com/open?id=0B24ZHnv6xHO4YlRkc2JZU0xRaVE

Thanks for the pointer - do you have a link to the volume by any chance? I can not find it googling around.

You can download from my google drive:
https://drive.google.com/open?id=0B24ZHnv6xHO4YlRkc2JZU0xRaVE

I got it figured out - I'll push a fix soon!


Chrome Web Store submission issues

Chrome Web Store is stuck at 4.0.1. Any new version is rejected for lacking privacy policy, which I added btw. and even move from AMO, because the page has to be "owned" by me. On any question I send I get only an automated reply, so I actually tend to drop support for installing the extension for Chrome-based browsers via Chrome Web Store.

I would keep the build scripts, just remove from Chrome Web Store, and provide instructions for loading the extension manually, if someone is interested.

I tried to fill all fields in the new Chrome Web Store interface today. The add-on is now pending review, and I cannot upload a newer version. I will try to upload 4.0.10 there, when the administration unlocks again.

Wow, the add-on was approved on Chrome Web Store, and published. It now has 4.0.5 available. I uploaded 4.0.10 now.


feature/consts-registry

Codecov Report
Base: 100.00% // Head: 97.14% // Decreases project coverage by -2.86% :warning:

Coverage data is based on head (f9413f9) compared to base (3e93a14).
Patch coverage: 55.76% of modified lines in pull request are covered.

: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      #35      +/-   ##
===========================================
- Coverage   100.00%   97.14%   -2.86%
===========================================
  Files           26       28       +2
  Lines          764      807      +43
  Branches       127      131       +4
===========================================
+ Hits           764      784      +20
- Misses           0       23      +23

Impacted Files
Coverage Δ

contracts/access-control/RBAC.sol
100.00% <ø> (ø)

contracts/libs/arrays/ArrayHelper.sol
100.00% <ø> (ø)

contracts/libs/utils/RecursiveStorageUtils.sol
0.00% <0.00%> (ø)

contracts/libs/utils/TypeCaster.sol
100.00% <100.00%> (ø)

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 at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Missing make target in README for containerized build

Description
In the README, we are currently not providing proper make target for containerized build. https://github.com/docker-slim/docker-slim/blob/b5d7fe290e94236657021a15d36fdbdd5d690107/README.md?plain=1#L898
Expected Behavior
we should provide build target

Actual Behavior

Steps to Reproduce the Problem

Specifications

Version:
Platform:

yes, good idea

cool, I will raise a PR for this

I think this issue is fixed, we can close it @kcq ?


Extend bedrock.yaml services to incorporate display name

As a:
SPK user
I want:
My bedrock.yaml file to track a display name for each of my services
So that:
I can use the display name when scaffolding pipelines, and when scaffolding my HLD
Describe the solution you'd like:

[ ] spk service create to take a parameter for display name ie. When I invoke spk service create fabrikam.homepage -n homepage -d packages  the resulting bedrock.yaml should resemble:

rings:
  master:
    isDefault: true
services:
  ./packages/fabrikam.homepage:
    displayName: homepage
    helm:
      chart:
        path: './components/container'

Acceptance Criteria:
Bedrock.yaml to have a field under services to track display name as a string
Describe alternatives you've considered:
None
Additional context:
It would be nice to be able to track service names as something separate than the path of the service (ie search instead of src/fabrikam.fiber.search)
Does this require updates to documentation?:
Yes

@bnookala @mtarng Was there an associated story that will consume this new field in the bedrock.yaml file? cc @evanlouie


Documentation should include "Basic" as a valid SKU for Azure Search Service

File: docs/reference/pkg/nodejs/pulumi/azure/search/_index.md
Azure Search Docs
Current docs say:

Valid values are free and standard

However, 'basic' is also valid.  The functionality already exists, but the documentation needs to be updated.

Hi @xtellurian
You are indeed correct here - I have just pushed a PR to the upstream terraform provider which we use to generate our documentation
Once that PR has been merged, this will make it's way to our site
Paul
https://github.com/terraform-providers/terraform-provider-azurerm/pull/4406


Update http4s-circe, http4s-dsl to 0.23.20

About this PR
📦 Updates

org.http4s:http4s-circe
org.http4s:http4s-dsl

from 0.23.18 to 0.23.20
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, version-scheme:early-semver, commit-count:1

Superseded by #1762.


Upgrade reqwest from 0.9 to 0.11

This is a breaking change, because it makes the functions async
Fixes #5
Please note, that this pr includes breaking changes and bumps the package version to 2.0.0 according to semver and rust rules.

Hi, changes like these need to be either applied in the upstream generator, or written using patch scripts as the code generated will be overridden when we update the specification.


import dlib on MacOS with M1 chips using Anaconda  make the kernel crashes.

Hello, this is a problem I get on MacOs using anaconda, when I want to import dlib :
Expected Behavior
importing dlib works and doesn't make the kernel crashes
Current Behavior
When I import Dlib in ipython, on Jupyter Notebook or Spyder (any IDE on anaconda), it crashes the kernel :
"the kernel appears to have died. it will restart automatically"
"
In [1]: import dlib
zsh: illegal hardware instruction  ipython -i
"
Steps to Reproduce
just download dlib via anaconda, when you write import dlib in any IDE on anaconda, it crashes the kernel.
Version used : 19.22
Downloaded via Anaconda
MacOs 64
IDE anaconda navigator
I tried to install twisted, cmake, boost, boost-python, as mentioned in various topics, but it still doesn't work.
Thank you in advance for your solutions,
Nolann

Ok, just resolved my problem, I uninstalled

I resolved my problem, I just uninstalled Anaconda, reinstalled it, with python 3.8.8, I used pip install (cmake, boost, dlib) instead of Conda install, it worked.


Removing event-stream dependency.

Please add a link to the user story in the PR description, at a minimum.


Some feedback

Thanks for the work. This could turn out very useful for many people...
I like the approach, and would love for this to be developed further. A couple of comments/questions though.
Also, please let me know if you want more code-style/QA feedback - Im happy to help.

iPod? You only initiate if platform is iPad or iPhone (ln 152), but later you check to see if its iPod (ln 121)
best-icon? why not just add them all and let the browser do the magic. If safari changes its logic this would no longer follow the platform as intented
I think web-app manifest urls are calculated from the base-url, which XHR is not. Minor thing, but base-urls are very common when routing clientside

I would love to see the start_url thing implemented like Paul Kinlands issue...

Thanks @filipbech

Regarding iPod miss, I'll check it.
For the best icon, there is an explanation: there is a bug today on iOS where when you add the page to the homescreen, a screenshot is taken instead of the icon; it happens randomly, and I'm talking only when the network is still up. Is the network is down when the user presses "Add to Home Screen", then the icon will never appear, therefore the best approach today is to set the icon in base64 to guarantee it's going to be used by Safari. It's part of my ToDo list, but that's the reason why I didn't let Safari just pick the icon.
I'll do a test suite for the base-url thing; sounds like something to be solved.

Regarding start_url like Paul says, look at my answer. I think I'm probably missing something there.

thanks for getting back to me... great explanation of the ios icon-bug... i didn't know that!
You can close this issue as it was just for getting in touch...
let me know if there is anything I can do to help!


What are the breaking changes?

Hey @leo ,
I've been looking at the releases and I see 7.0.0 and 8.0.0 which are major changes from 6.x.x. I'm keen to update it but not sure which are the breaking changes I should be aware of.
Could you let me know or point me to where they are?
Thanks!

I suggest comparting the output of npx<EMAIL_ADDRESS>help to npx serve@latest -h to understand what has changed exactly. Also read this and this if you have time.


Fix the issue where setting an undefined or empty string does not res…

…et the date in normal mode
Checklist
List of tasks you have already done and plan to do.

[ ] Fix linting errors
[ ] Tests have been added / updated (or snapshots)

Change information
Describe your modifications here.
Issues
#1776
The issues you want to close, formatted as close #1.
Related Links
Links related to this pr.

It has a same pr. Please check https://github.com/varletjs/varlet/pull/1779

Thanks fro your contribution !


type specifier does not work with namespace types

If using the type like this:
/** type:MyNamespace::MyType The stuff */
property alias stuff: someObject.stuff

The generated documentation will be wrong. It shows only MyNamespace as the type and the brief description instead reads ::MyType The stuff.
This becomes relevant if a namespaced C++ class is registered in QML and used within QML. For my case, the example is a class named QtAutoUpdater::Updater, which is registered in QML as de.skycoder42.QtAutoUpdater.Core.Updater and used as follows:
/** type:QtAutoUpdater::Updater The updater */
property Updater updater: null

Not adding "type" will set the type to Updater, which is not found by doxygen, as the namespace prefix is missing, and because the Updater class lives in a different namespace than the QML class.
EDIT: This also applies when trying to reference Qt QML classes directly, i.e. QtQuick.Item

Sorry for the super late answer. I am not active on this project right now, but I am happy to review PR if you feel like adding support for this.


doc: add initial microbit documentation

Add a basic description of the platform and some placeholders, this will
need to be refined.
Fixes #3351

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6120   +/-   ##
=======================================
  Coverage   52.88%   52.88%
=======================================
  Files         412      412
  Lines       40274    40274
  Branches     7801     7801
=======================================
  Hits        21297    21297
  Misses      15761    15761
  Partials     3216     3216

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 4637620...9160c0f. Read the comment docs.


WebGL bug not displaying dynamically created Canvas images

Preventing progress with ESPB WebGL.

To reproduce, force GaugeNeedleNode's options to 'webgl'

@samreid, can you confirm that using toCanvasNodeSynchronous now works with the WebGL renderer?

Yes, that fixes the problem.  Now the needle gauge and the skater dot are both appearing with renderer:webgl.  Thanks!


use POST to support large files

https://github.com/philschatz/etherpad-lite-client-js/commit/9d1343b905d317680502d25cb5701ed84ab12b25 is an old commit on @philschatz's fork ahead of this repo by only one commit, with a change to use POST to support large files.
Would it be possible to integrate this into the main package?
It is being used by https://github.com/philschatz/gh-board , and it would be nice if it was able to use released versions instead of git dependencies.

Sure! I'd prefer if someone actually opened a pull request though. My time these days is extremely limited :-(.
If you or the author or anyone else wants to do this, they should modify main.coffee and then run cake build to generate main.js. Adding these steps to the readme would be a great bonus :-).
I'll be happy to merge it and publish a new version.


Documentation: fix store gateway link in sharding.md

[ ] I added CHANGELOG entry for this change.
[ ] Change is not relevant to the end user.

Changes
Fix broken link (404) from sharding.md to store.md
Store.md link: components/store.md/
Sharding.md link: thanos/sharding.md
Verification
Appending the suggested relative URL to the sharding.md results in thanos/sharding.md/../../components/store.md/ which redirects to the correct page.

Ah, looks like this will be solved the same way as #3645

@rtreffer you're right!

Looks like it's done already. Thanks anyway for help 🤗

Looks like it's done already. Thanks anyway for help 🤗


Update to Cadence v1.0.0-preview.34

Description
Automatically update to:

onflow/cadence v1.0.0-preview.34
onflow/flow-go-sdk v1.0.0-preview.36
onflow/flow-go v0.35.14-crescendo-preview.27
onflow/flow-emulator v1.0.0-preview.32

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 43.83%. Comparing base (94040eb) to head (25e4657).

Additional details and impacted files
@@                     Coverage Diff                     @@
##           feature/stable-cadence      #61       +/-   ##
===========================================================
- Coverage                   58.49%   43.83%   -14.66%
===========================================================
  Files                          29       40       +11
  Lines                        2190     3365     +1175
===========================================================
+ Hits                         1281     1475      +194
- Misses                        724     1630      +906
- Partials                      185      260       +75

Flag
Coverage Δ

unittests
43.83% <ø> (-14.66%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


unresolved import hyper::Client

I can't seem to build a simple test that uses hyper; rustc gives me:
hyper_client.rs:8:5: 8:10 error: unresolved import hyper::Client. Did you mean self::hyper?
hyper_client.rs:8 use hyper::Client;
^~~~~
error: aborting due to previous error
I simply copy/pasted the examples/client.rs into my own test project/hyper_client.rs.
Any idea why this isn't working?
hyper_client.rs:
#![feature(env, old_io)]
extern crate hyper;
use std::env;
use std::old_io::stdout;
use std::old_io::util::copy;
use hyper::Client;
...
Cargo.toml:
[package]
name = "rust-test"
version = "0.0.1"
[dependencies]
hyper = "*"

Only possible thing I can think of is that you need to put extern crate rules inside your lib.rs (or main.rs if an executable).

Ok, I'm sure it's not your fault.
It's probably my fault, or I may have found an issue.
I'll close this and circle back for a deeper look shortly.


support python udf sidecar

What type of PR is this?

[ ] API-change
[ ] BUG
[ ] Improvement
[ ] Documentation
[x] Feature
[ ] Test and CI
[ ] Code Refactoring

Which issue(s) this PR fixes:
#439
What this PR does / why we need it:
Not Available
Special notes for your reviewer:
Not Available
Additional documentation (e.g. design docs, usage docs, etc.):
Not Available

@aylei


Add OpenFHE as a bazel-native build dependency

Tested with bazel build @openfhe//...:all
Part of https://github.com/google/heir/issues/385
This PR only adds the WORKSPACE dependency, so we don't yet have to worry about syncing the internal/external versions of OpenFHE via copybara.
New deps:

OpenFHE: https://github.com/openfheorg/openfhe-development
Cereal: https://github.com/USCiLab/cereal
RapidJSON: https://github.com/Tencent/rapidjson/

Hacks and workaround notes
Repo patches
I had to remove the following line from
bazel/openfhe/add_config_core.patch to make the build work.  We will
probably want to fix this if to get 128-bit int support, or infer it
from the system somehow instead of relying on cmake to generate it.
(Why can't this be passed as -DHAVE_INT128?)
+#define HAVE_INT128 TRUE

Was the bazel/openfhe/BUILD file necessary to mark a subpackage, or is it possible to remove the empty file? If not, can you mark that it's just a subpackage for openfhe deps' builds?

Yes, and done.


Added bower.json file

Closes #1

"The project moved to google code" - so since that one is closing where did it go from there?

It moved from SourceForge to Google Code to GitHub. Not moving again.

GitHub and Google Code have done the super silly thing to allow you to export a project from Google Code into GitHub directly, instead of having you fork from an immutable (till claimed by the original author) repository that would be autogenerated at first demand on GitHub. That way there are several ExplorerCanvas now on GitHub, but not sure which is the main one, plus you don't see them as related in GitHub to follow their tracks and merge from one to another etc.  If you click on the Fork number in the upper right it will show you the network and how the forks are related.

See webjars and cowlibob versions for example, maybe more there. Not sure if they were created via google code export, but most probably that's the case
Google code repos don't point to GitHub version unless edited (before freezing?) to have such text. So user thinks latest version is there and try to clone repository, but they're instead offered to export to GitHub where their project becomes the parent one, unrelated to exports from others

See https://github.com/cowlibob/explorercanvas
refers to google code version
(webjars one might be something like a wrapper, or unrelated, but not sure)
Google should allow project author to disable that feature in my opinion or generate a master project (frozen) on GitHub and fork from that. When an owner of the project exported themselves later (if they ever did) it would give it to them, although that could be optional and could have all autofork from immutable exported projects under a googlecode account at GitHub

on pull request

I see a "This branch has conflicts that must be resolved" here

This was done in https://github.com/arv/ExplorerCanvas/commit/b2a7c3b4fc191924404ddc5bf5036c6a58b18542


Reveal width not calculated correctly in IE

The full-width reveal modal width doesn't account for the scroll-bar in IE. Does it makes sense to change the logic in foundation.reveal.js (line 222)
from:
'width': eleDims.windowDims.width

to:
'width': eleDims.windowDims.outerWidth

outerWidth calculates the full-width of the browser window including the scrollbar.

Any thoughts on how to improve this? Not just for IE but for windows users browsing on Chrome as well

I have the same issue on Chrome for Mac OSX

The issue seems to resolve for me on Mac by adding
html{ overflow-y: scroll; }

Looks like there are a few issues happening there. We've started a conversation and we're going to create a lot of traction from this to get more bugs fixed and get more people involved.
I'm wondering if you have some more specific ideas or workarounds to share post we put up? http://foundation.zurb.com/forum/posts/38459-f6-reveal-modal-suggestions
Thanks!

There were substantial changes to reveal in v6.2 which fixed a number of issues.  @eliotc1986 @christianmagill can you confirm if this is still an issue for you today?  Thanks

@eliotc1986 @christianmagill I'm going to close this issue. Feel free to reopen it if the problem still exists in v6.2 or later.


[Logging v2] Update logging chart to upstream 3.8.4

The exact version may be subject to change: https://github.com/banzaicloud/logging-operator/releases

PRs for this issue are pending on the following issues being moved to test.

[ ] #30329 - partial fix
[ ] #30595 - full fix
[ ] #30383 - full fix

PRs for this issue are pending on the following issues being moved to test.

[ ] #30329 - partial fix
[ ] #30595 - full fix
[ ] #30383 - full fix

Would prefer to wait for the following change to be included in a release: https://github.com/banzaicloud/logging-operator/pull/676

Would prefer to wait for the following change to be included in a release: https://github.com/banzaicloud/logging-operator/pull/676

Chart 3.8.4 has been removed from upstream. Closing in favor of https://github.com/rancher/rancher/issues/30917

Chart 3.8.4 has been removed from upstream. Closing in favor of https://github.com/rancher/rancher/issues/30917


Tracing backend and FAAS

Is there a way by which we can propagate Span contexts via something like SNS in AWS. I have orchestrated all our Nodejs backends with Jaeger. I was wondering on how to integrate our AWS lambdas so as to trace the request from our backend to lambdas and back to our backend.

@Puneeth-n it's definitely possible to do that!
In fact, propagating context with SNS is very similar to how you do it with HTTP.
Amazon SNS supports message attributes that can be used with Inject/Extract methods to pass the context around.

@ledor473 Thanks for the reply. The lambdas would then send the span details out of bound to the collector directly over HTTP right?

It sounds like a great blog post! If you want to publish a how-to under our Medium publication, let me know!

Still getting the hang of it. Definitely my next project

@Puneeth-n can you please share your progress? I would love to read more about it

@idohalevi no didn't work on it anymore :/

@jpkrohling any insight on this? maybe best practices?

@idohalevi you'd basically need to rely on the instrumentation library (OpenTelemetry, OpenTracing) to read and write the context. There's some documentation about context propagation in the OpenTracing repository (linked by @ledor473 in a previous message), and I'm sure there's something similar in the OpenTelemetry area.

@jacobmarble got it. Thank you for your help.

I am going to close this since this is an issue for instrumentation, not for Jaeger.


Add Datasources to the Get Command

this simply adds datasources as an option for the Get command, in addition to the existing views and workbooks.

Code looks good. Can you add an e2e test in the e2e tests file and run it locally?

Done. Tests all passed.


riscv/fpu: Implement correct lazy-FPU functionality (attempt #2)

Second attempt at this:
https://github.com/apache/nuttx/pull/9486
There are two issues with smp mode:

Context restore routine in up_cpu_paused did not restore the correct address environment
FPU test in ostest crashes

Both very likely for the same reason

@masayuki2009 The last commit fixes the ksmp64 crash but I cannot verify the FPU test because I do not own an FPU capable board.
I noticed that rv-virt has FPU disabled, is this something I can fix ? Or is FPU unsupported by qemu ?

The problem with smp is up_cpu_paused:
  /* Save the current context at CURRENT_REGS into the TCB at the head
   * of the assigned task list for this CPU.
   */

  riscv_savestate(tcb->xcp.regs);

And later
  /* Then switch contexts.  Any necessary address environment changes
   * will be made when the interrupt returns.
   */

  riscv_restorestate(tcb->xcp.regs);

Only the integer context changes but no MMU or FPU restore is done. Maybe someone who knows how SMP works can comment on what up_cpu_paused is and what it is supposed to do? Is it supposed to be capable of handling context switches or ?

@masayuki2009 I enabled FPU for qemu-rv in arch/risc-v/Kconfig and ostest passes on smp64 now. So it seems the FPU issue with qemu-rv is also fixed by this PR.

I think the smp issue is now fixed, but I don't own an smp capable board to test it on actual hardware. On rv-virt FPU works both in SMP and non-SMP.

I think the smp issue is now fixed, but I don't own an smp capable board to test it on actual hardware. On rv-virt FPU works both in SMP and non-SMP.

@pussuw
Thanks for the fix. Let me check this PR tomorrow.

@pussuw
Hmm, ostest with maix-bit:smp (board) still crashes.
End of test memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena      1fb990   1fb990
ordblks         4        4
mxordblk   1f4020   1f4020
uordblks     7100     7100
fordblks   1f4890   1f4890

user_main: /dev/null test
dev_null: Read 0 bytes from /dev/null
dev_null: Wrote 1024 bytes to /dev/null

End of test [CPU1] riscv_exception: EXCEPTION: Illegal instruction. MCAUSE:<PHONE_NUMBER>000002, EPC:<PHONE_NUMBER>016bf8, MTVAL: 00000037ec3f44d4
[CPU1] riscv_exception: PANIC!!! Exception =<PHONE_NUMBER>000002
[CPU1] _assert: Current Version: NuttX  10.4.0 67e17d2acf Jun 21 2023 08:04:13 risc-v
[CPU1] _assert: Assertion failed panic: at file: :0 task(CPU1): FPU#1 0x80016b9c
[CPU1] up_dump_register: EPC:<PHONE_NUMBER>016bf8
[CPU1] up_dump_register: A0:<PHONE_NUMBER>000000 A1:<PHONE_NUMBER>000001 A2:<PHONE_NUMBER>000000 A3:<PHONE_NUMBER>403d58
[CPU1] up_dump_register: A4:<PHONE_NUMBER>000002 A5:<PHONE_NUMBER>000440 A6:<PHONE_NUMBER>000000 A7:<PHONE_NUMBER>000000
[CPU1] up_dump_register: T0:<PHONE_NUMBER>000000 T1:<PHONE_NUMBER>000000 T2:<PHONE_NUMBER>000000 T3:<PHONE_NUMBER>000000
[CPU1] up_dump_register: T4:<PHONE_NUMBER>000000 T5:<PHONE_NUMBER>000000 T6:<PHONE_NUMBER>000000
[CPU1] up_dump_register: S0:<PHONE_NUMBER>000000 S1:<PHONE_NUMBER>000001 S2:<PHONE_NUMBER>000000 S3:<PHONE_NUMBER>000000
[CPU1] up_dump_register: S4:<PHONE_NUMBER>000000 S5:<PHONE_NUMBER>403248 S6:<PHONE_NUMBER>000000 S7:<PHONE_NUMBER>000000
[CPU1] up_dump_register: S8:<PHONE_NUMBER>000000 S9:<PHONE_NUMBER>000000 S10:<PHONE_NUMBER>000000 S11:<PHONE_NUMBER>000000
[CPU1] up_dump_register: SP:<PHONE_NUMBER>40c720 FP:<PHONE_NUMBER>000000 TP:<PHONE_NUMBER>000000 RA:<PHONE_NUMBER>016bea
[CPU1] dump_stack: User Stack:
[CPU1] dump_stack:   base: 0x8040c030
[CPU1] dump_stack:   size: 00001968
[CPU1] dump_stack:     sp: 0x8040c720
[CPU1] stack_dump: 0x8040c720: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[CPU1] stack_dump: 0x8040c740: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[CPU1] stack_dump: 0x8040c760: deadbeef deadbeef deadbeef deadbeef 00000000 00000000 00000000 00000000
[CPU1] stack_dump: 0x8040c780: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[CPU1] stack_dump: 0x8040c7a0: 80016b9c 00000000 80006c9c 00000000 8040c010 00000000 00000001 00000000
[CPU1] stack_dump: 0x8040c7c0: 00000000 00000000 8000365a 00000000 00000000 00000000 00000000 00000000
[CPU1] show_tasks:    PID GROUP   CPU PRI POLICY   TYPE    NPX STATE   EVENT      SIGMASK          STACKBASE  STACKSIZE      USED   FILLED    COMMAND
[CPU1] show_tasks:   ----   ---  ---- --- -------- ------- --- ------- ---------- -------- 0x80400240      2048      1384    67.5%    irq
[CPU1] dump_task:       0     0     0   0 FIFO     Kthread N-- Running<PHONE_NUMBER>000000 0x80403ea0      2000      1136    56.8%    CPU0 IDLE
[CPU1] dump_task:       1     1     1   0 FIFO     Kthread N-- Assigned<PHONE_NUMBER>000000 0x80401270      2000      1104    55.2%    CPU1 IDLE
[CPU1] dump_task:       2     2     0 100 RR       Task    --- Waiting Semaphore<PHONE_NUMBER>000000 0x80406670      2992      2176    72.7%    nsh_main
[CPU1] dump_task:      39    39     0 100 RR       Task    --- Waiting Semaphore<PHONE_NUMBER>000000 0x8040aa20      1968      1456    73.9%    ostest
[CPU1] dump_task:      40    40     0 100 RR       Task    --- Waiting Semaphore<PHONE_NUMBER>000000 0x80407990      8064      1520    18.8%    ostest Arg1 Arg2 Arg3 Arg4
[CPU1] dump_task:      41    41     1 100 RR       Task    --- Running<PHONE_NUMBER>000000 0x8040c030      1968       720    36.5%    FPU#1

@masayuki2009 Thanks for testing. I think I need to make icicle smp capable so I can test it myself. Is it possible to provide me with the .elf file so I can see where EPC points to (the illegal instruction) ?

Nevermind, I don't need the .elf.
I can see the error now with icicle:nsh (no SMP). The instruction that causes the fault is:
static int fpu_task(int argc, char *argv[])
{
8001b3f8:   7175                    addi    sp,sp,-144
8001b3fa:   e506                    sd      ra,136(sp)
8001b3fc:   e122                    sd      s0,128(sp)
8001b3fe:   fca6                    sd      s1,120(sp)
8001b400:   f8ca                    sd      s2,112(sp)
8001b402:   f4ce                    sd      s3,104(sp)
8001b404:   f0d2                    sd      s4,96(sp)
8001b406:   ecd6                    sd      s5,88(sp)
8001b408:   a4a2                    fsd     fs0,72(sp)
So the first FPU instruction faults, something with the CPU status register is wrong.

@pussuw
nuttx-maix-bit-crash-pr9577.gz

@pussuw nuttx-maix-bit-crash-pr9577.gz

Thank you!

I was able to reproduce the ostest crash on qemu-rv and it should now be fixed. Also, rv-virt:ksmp64 is not crashing any longer either.
Changes since last PR round
Moving the MMU change and FPU restore to riscv_internal.h / riscv_restorecontext() works for single core but not for multicore, so they are both moved back into riscv_doirq.c. (and riscv_perform_syscall.c).
SMP seems to expect this order of execution, I don't know why though.
Why does the ostest crash happen ?
The crash is due to mishandling of the floating point control/status register (fcsr). The illegal istruction happes due to incorrect / stale rouding mode, from the risc-v spec:
Floating-point operations use either a static rounding mode encoded in the instruction, or a dynamic
rounding mode held in frm. Rounding modes are encoded as shown in Table 8.1. A value of 111 in
the instruction’s rm field selects the dynamic rounding mode held in frm. If frm is set to an invalid
value (101–111), any subsequent attempt to execute a floating-point operation with a dynamic
rounding mode will cause an illegal instruction trap. Some instructions that have the rm field are
nevertheless unaffected by the rounding mode; they should have their rm field set to RNE (000).
So the CPU (FPU status register) status was not updated correctly in the SMP case.

Getting the style error from https://github.com/apache/nuttx/pull/9824 here now. Should nxstyle ignore old errors or no ?

@masayuki2009 sorry to keep bothering you, but I still do not have an SMP capable board (I'm writing support for icicle), can you try this on maix-bit:smp once again ? I was able to reproduce the crash on qemu and also fix it, so I have some confidence it should be fixed for actual HW as well.

Now qemu-rv smp64 is rock solid. The trick was up_cpu_paused, I did not realize the full CPU context (integer + FPU regs) need to be saved there.
Could you @masayuki2009 verify with actual hardware that it works ? I think we should not merge before this is verified with HW.

Could you @masayuki2009 verify with actual hardware that it works ? I think we should not merge before this is verified with HW.

@pussuw
I confirmed that the latest PR works with the Sipeed Maix Bit (K210).

@pussuw please fix the style warning.

@pussuw please fix the style warning.

@xiaoxiang781216 I don't think I'm responsible for the style issue:
Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:243:18: error: Unmatched right parentheses
Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:276:18: error: Unmatched right parentheses
Error: Process completed with exit code 1.
It is the same as in here https://github.com/apache/nuttx/pull/9824
I thought the style check would not complain about issues that are already in upstream ?

@pussuw please fix the style warning.

@xiaoxiang781216 I don't think I'm responsible for the style issue: Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:243:18: error: Unmatched right parentheses Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:276:18: error: Unmatched right parentheses Error: Process completed with exit code 1.
It is the same as in here #9824
I thought the style check would not complain about issues that are already in upstream ?

No, the style checks the full source code. This design prefers the contributor fix the style issue in the old code base.

@pussuw please fix the style warning.

@xiaoxiang781216 I don't think I'm responsible for the style issue: Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:243:18: error: Unmatched right parentheses Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:276:18: error: Unmatched right parentheses Error: Process completed with exit code 1.
It is the same as in here #9824
I thought the style check would not complain about issues that are already in upstream ?

No, the style checks the full source code. This design prefers the contributor fix the style issue in the old code base.

But I'm still confused, the only change I made in assert.c is
static uintptr_t g_last_regs[XCPTCONTEXT_REGS] aligned_data(16);
The violation comes from a previous very recent commit (#9824), which was merged with the violation. The code added there is fine so I think the violation is a false alarm, but I have NO IDEA how to fix that.

@pussuw please fix the style warning.

@xiaoxiang781216 I don't think I'm responsible for the style issue: Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:243:18: error: Unmatched right parentheses Error: /home/runner/work/nuttx/nuttx/nuttx/sched/misc/assert.c:276:18: error: Unmatched right parentheses Error: Process completed with exit code 1.
It is the same as in here #9824
I thought the style check would not complain about issues that are already in upstream ?

No, the style checks the full source code. This design prefers the contributor fix the style issue in the old code base.

But I'm still confused, the only change I made in assert.c is
static uintptr_t g_last_regs[XCPTCONTEXT_REGS] aligned_data(16);
The violation comes from a previous very recent commit (#9824), which was merged with the violation. The code added there is fine so I think the violation is a false alarm, but I have NO IDEA how to fix that.

yes, it's a false alarm, that's why #9824 is merged with this warning.

Hmm, now looking at the code the fix for the violation should be pretty simple, I'll do it on Monday.

ok, you can try it.

@pussuw So in this PR, the FPU save and restore are migrated to riscv_swint()? I am curious whether the FPU will be restored correctly if a context switch is triggered in other exceptions?

@anchao A context switch always ends up in riscv_swint(), so yes. Are you experiencing some odd / unexpected behavior with FPU ? I have a project that heavily relies on the FPU and I have not seen any issues with it.
Note, that I do not use SMP, there was a problem with SMP in the first iteration of my lazy FPU patches, but that was related to address environment handling.

@pussuw No, I just noticed this commit when reviewing the code, current implementation may have certain risks if enable FPU in kernel mode and compiler generates code that uses floating-point registers in the interrupt handler.


[Query] Do we have a Slack channel for community based discussions?

Folks, I am an open source enthusiast of your product and just wanted check if we do have a Slack channel or anything similar for community based discussions. Searched, but could not find any. If there isn't in fact any, I would suggest to start one as this could be really useful to foster a stronger sense of community among users and contributors and help build real-time communications with increased collaboration. Let me know of your thoughts. Best regards.
@garyduan @gkosaka

Please check out https://rancher-users.slack.com/archives/C036F6JDZ8C

Hey @gkosaka, It seems that I must have an account with the domain rancher.com or suse.com to login to this workspace. How should I proceed in that case? Thanks.

Please use this link to generate a self-invite: https://slack.rancher.io/

Thanks @gkosaka. I was just able to join "neuvector-security".


Setting columns option in dxDataGrid with dataSource with OdataStore break the sorting.

Issue Type

bug report
Description
When i set the columns option and try to change sort in any column, data order doesn't change. If columns options isn't be used all works as expected.
Current Behavior
After click on columnt to sort, widget data will be reolad, but the order will not change.
Expected Behavior
Expected that sorting in widget with columns option will be the same as in the widget without columns option.
Steps to Reproduce

Set the dataSource with odata store to widget.
Set the columns option to widget.
Try to sort column.

Demo

Demo with React widget to reproduce (reuire to enable corse): https://stackblitz.com/edit/devextreme-react-5bymhn?file=index.js
Just want to say that original dxDataGrid (non react widget) work good, for example see this demo: https://codepen.io/anon/pen/mLJpRR
Environment Details

devextreme 18.1.1-pre-18093
devextreme-react 18.1.1-alpha.3
react 16.3.0

Hi!
Now it works as expected. DataGrid sorting configures inside the columns option. You should process changes of the columns option via optionChanged callback or use defaultColumns option if you don't want to control the columns.

Hi!
Ok, using defaultColumns option is good solution for us.
Thank you for all your assistance.


[ Documentation request ] Change the redirection link in typescript button under SDKs

Brief description

Clicking on typescript redirects us to a GitHub issue. Now that we have a fully functional SDK support for typescript, the redirection link need to be changed to this documentation page. Fix this in the SDKs section of docs and SDKs Integration section of Resources and Guide in Home page.

Remove the text (WIP) written after typescript as it is no more work in progress.

Your recommended content
You can refer to this file.

hey...pls consider me assigning this issue..would like to work on it

Yeah sure.

hey @SanskritiHarmukh  is this issue solved if not could I work on it.

hey @RJ025  lets give @tanmay-S12  a valid amount of time before we reassign , Meanwhile you may complete the other issue assigned to you:)

hey @RJ025 lets give @tanmay-S12 a valid amount of time before we reassign , Meanwhile you may complete the other issue assigned to you:)

thanks for coordinating...

yeah yeah for sure no problem @ShivamTyagi12345 @tanmay-S12

@tanmay-S12 I have modified the description and added another task. Please create a PR accordingly.

ohkay...
On Mon, 17 Oct, 2022, 12:33 am Sanskriti Harmukh, @.***>
wrote:

@tanmay-S12 https://github.com/tanmay-S12 I have modified the
description and added another task. Please create a PR accordingly.
—
Reply to this email directly, view it on GitHub
https://github.com/keploy/docs/issues/91#issuecomment-1280032176, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AVZH2QWWYDT336ILRVDUDATWDRGPLANCNFSM6AAAAAARGGNEMA
.
You are receiving this because you were mentioned.Message ID:
@.***>

@tanmay-S12 are you still working on it?

Since it's being a long time. Making the issue open for others.

Can you assign this issue to me?

@anvbey lmk if you need any help : )


[BugFix] Fix from-days statistics estimate error

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #10193
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

[FE PR Coverage Check]
:disappointed: fail : 3 / 10 (30.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/statistics/ExpressionStatisticCalculator.java
3
10
30.00%
[329, 330, 331, 333, 334, 345, 346]

run starrocks_admit_test


Expand button not changing to collapse when clicked if button is a sibling and not a child

Hi,
I needed to change the original code below but after the change, the when I click a collapsed item in navigation tree, it expands but the icon/button stays the same (expand: "+"). How can I fix it. I have tried updating theme.js and CSS both - but nothing is helping...
As you can see below in the last line of code, instead of prepending the button to anchor, I added is after the anchor as a sibling. What can I do so that the button toggles when clicked?
Original Code:
      // Add expand links to all parents of nested ul
        $('.wy-menu-vertical ul').not('.simple').siblings('a').each(function () {
            var link = $(this);
                expand =
                    $('<button class="toctree-expand" title="Open/close menu"></button>');
                expand.on('click', function (ev) {
                self.toggleCurrent(link);
                ev.stopPropagation();
                return false;
            });
            link.prepend(expand);
         });
    };

Updated Code:
      // Add expand links to all parents of nested ul
        $('.wy-menu-vertical ul').not('.simple').siblings('a').each(function () {
            var link = $(this);
                expand =
                    $('<button class="toctree-expand" title="Open/close menu"></button>');
                expand.on('click', function (ev) {
                self.toggleCurrent(link);
                ev.stopPropagation();
                return false;
            });
            link.after(expand);
         });
    };

My issues are resolving on their own ;-) . I figured this out.


Don't go from 100% to 0% if the swipe continues

I have a 270 degree slider. If I swipe beyond 100%, (or reach too close to the starting point), the slider resets to 0%!
Can you add a setting where the slider will stay at 100% (and symetrically at 0%) if we over (or under) swipe?
Thanks!

That was requested already and (good news!) I already implemented it. I'm currently implementing a few more features and fixes I have on my list before I commit the changes and update the pod. Should be out by tomorrow hopefully!

Released 1.3.0 and updated the pod!

I've upgraded to 1.3.0 and set maximumRevolutions to 0. But since my slider is 300 degrees (not a full circle), this doesn't work. Is there any reason why there is a limitation of this feature to work with only full circles?

I see... I may have misunderstood what you meant at first!
The reason why this works on full circles only is because semi-circular sliders stop at 100% by default. However, when you slide further, it would snap back at 0%, which (as I understand) is your issue here.
Even if the slider is a full circle and you set maximumRevolutions to 0, it would still snap to other values after 180 degrees beyond 100% (you could try it to get a better grasp on what I mean).
The problem with what you're asking for is that the slider computes the handle's angle and value based solely on the current touch location, neglecting any previous sliding. I.e: given a certain touch location, the handle would get drawn at its corresponding angle.
I thought of a couple workarounds off the top of my head now that could essentially solve this issue, but unfortunately it'll probably take a few days (possibly a couple of weeks) to implement it because I'm really busy these few days! Regardless, I'm reopening the issue in case anyone wants to implement it and PR in the time being. Have a good day!

Thank you! That's exactly what I mean.


Rust language analysis

Is your feature request related to a problem? Please describe.
As far as I know, there is no reverse engineering framework that really supports programs written in Rust, which is becoming a pretty popular language. I don't consider this a priority as it is far less common than C to this day, but it would be something nice to have.
Describe the solution you'd like
Right now, the Rust standard library and types are unrecognized  and renders the decompiler pretty useless as it only really handles conditionnal expressions and loops well. Also, most Rust program crash handling uses unwinding which stores the real name of every functions somewhere in the binary, while the names recognized by Ghidra looks seemingly random. For someone familliar with the Rust compiler's inner working, it should be relatively easy to do and, by itself, be extremely helpful.

How this relates with ghidra?

The request is to add some support for rust analysis in ghidra. Mostly, demangling the functions names as, right now, ghidra detects them as namespaces instead

Rust has as its tool the ability to make functions into hash code. This explains the process in detail: Here
But, it would be possible to extract some information from it through reverse engineering, and can highlight the reference by function as a heuristic result?

I've written a Ghidra Python script for demangling Rust symbols: https://gist.github.com/str4d/e541f4c28e2bca80d222434ac1a204f4
Currently it only supports the "legacy" mangling format, but that's still the default format as RFC 2603 hasn't yet been stabilised: https://github.com/rust-lang/rust/issues/60705

@str4d  great work!

It would also be nice to handle rust strings somehow. Rust doesn't use nul terminated strings like C (in fact it allows arbitrary nul bytes inside a string). Rust strings are represented using a combination of a pointer and a length. The current rust calling convention passes both as separate arguments according to the native C calling convention so a heuristic could maybe check if one argument is a pointer to something that looks like a string followed by an argument that looks like a length. As a sanity check it could then check if the resulting string is valid UTF-8 as in Rust non-UTF-8 strings are UB.

It would also be nice to handle rust strings somehow. Rust doesn't use nul terminated strings like C (in fact it allows arbitrary nul bytes inside a string). Rust strings are represented using a combination of a pointer and a length. The current rust calling convention passes both as separate arguments according to the native C calling convention so a heuristic could maybe check if one argument is a pointer to something that looks like a string followed by an argument that looks like a length. As a sanity check it could then check if the resulting string is valid UTF-8 as in Rust non-UTF-8 strings are UB.

Update: my script now supports most of the v0 mangling format. The main things missing are const generics (which are blocked on a pending change to the RFC) and decompression of backrefs (which I'll add next).

Update: my script now supports most of the v0 mangling format. The main things missing are const generics (which are blocked on a pending change to the RFC) and decompression of backrefs (which I'll add next).

It appears that demangling Rust strings exists in Ghidra 11.0, both for the legacy and v0 format: https://github.com/NationalSecurityAgency/ghidra/tree/fa8eff4d33f6323bcd8e26615d5a362046bb2756/Ghidra/Features/Base/src/main/java/ghidra/app/plugin/core/analysis/rust/demangler.


Feature/dynamic length images

fixes #40
@chetanddesai
Tested up to 5 or 6 digits (99999/99999 and 999999/999999)
Will create a separate pull request for the description one.
also changed the Build Description in the groovy

[Current coverage][cc-pull] is 25.72%

Merging [#41][cc-pull] into [master][cc-base-branch] will decrease coverage by 1.03%

@@             master        #41   diff @@
==========================================
  Files             6          6
  Lines           198        206     +8
  Methods           0          0
  Messages          0          0
  Branches         24         25     +1
==========================================
  Hits             53         53
- Misses          142        150     +8
  Partials          3          3

Powered by Codecov. Last updated by [7b8cc45...00c3796][cc-compare]
[cc-base-branch]: https://codecov.io/gh/SxMShaDoW/embeddable-badges-plugin/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/SxMShaDoW/embeddable-badges-plugin/compare/7b8cc459c2df02af59e8ec4455602776e4a1cb91...00c379604abaeca6e6dc7b04cc9126a05c9f3698
[cc-pull]: https://codecov.io/gh/SxMShaDoW/embeddable-badges-plugin/pull/41?src=pr


Fix module loading so it doesn't depend on subclasses()

In some Python implementations subclasses() does not retain its order.
This simply compares the before and after lists.
This allows it to be more future compatible, and work with Jython.

Jython ticket regarding random __subclasses__ ordering: http://bugs.jython.org/issue2514


How to execute get-account command from browser?

I'm unable to get the expected result when trying to execute the following command.
curl http://myHost:myPort/v1/chain/get_account -X POST -d '{"name":"inita"}' Refer
I am using Postman to execute post requests.
Expected Output:

Actual Output:

Need Help!

use "account_name"

@nanonano7 I got this in response :/

try http://testnet1.eos.io:80/v1/chain/get_account
if that works then your local eosd node is probably not set up correctly

@nanonano7  I ran this in my browser and got same error.

you have post JSON to it

@nanonano7 For http://testnet1.eos.io:80/v1/chain/get_account i have tried both ways - with and without params. In both cases i got same error. I am attaching the screen shot where I added params.

Response:

use {"account_name":"inita"} not name

Omg! Thanks a lot! It Worked! 💃

Thanks @nanonano7.

@Gagan0436 Please use telegram EOS Single Threaded or EOS Developers for questions/support. We want to keep GitHub issues as clean as possible.

@heifner Sure. Thank you for sharing. :)

@nanonano7 Hi can you please have a look into this issue
Any help will be appreciated!
Thanks!

how did you get account_name inita?
what api is used to create account_name? Account_Name or wallet names are different?
i tried get_account API with wallet name but it gives me this error

{
"code": 500,
"message": "Internal Service Error",
"error": {
"code": 3010001,
"name": "name_type_exception",
"what": "Invalid name",
"details": [
{
"message": "Name not properly normalized (name: test-wallet99, normalized: test.wallet) ",
"file": "name.cpp",
"line_number": 15,
"method": "set"
}
]
}
}

hyphens are not allowed in account names.
Also just to clarify.
Wallets are just software to manage your account/keys.

gittempo,
EOS has "regulations" regarding naming account names:
"Name should be less than 13 characters and only contains the following symbol .12345abcdefghijklmnopqrstuvwxyz."
Hope this helps


Documentation

This is a great plugin to use, but the learning curve is very steep.
Some documentation could ease the integration pain. I am willing to help with this, but I will need help myself.
And it begins with the simple stuff like:

You cannot add the device in Home Assistant if the "ACE Service Installer" is connected to the device at the same time. You will get an unknown error when you try this, so first close the ACE Service Installer.
Also it asks for a usename and password. This is the username "admin" alongside the "Owner" password.
Simple information, but together with the first point, makes a hell in trying to find out why it will not connect.

Other stuff I don't know yet are:

Does this plugin only uses the API or also modbus? Do I need to configure modbus and active loadbalancing or not?
Is there a "push preferred settings" button so the integration configures the modbus and balancing settings to a default or preferred state?
Are there examples of automations on how to best manage the amps so it stays under a certain Wattage or only uses a certain wattage compared to energy send back to the grid, energy used from the grid, production of solar, no charging if home battery not > 80% for example, etc...

Aside from very long form posts and a few lists in the github wiki, there is no sign of a much needed manual.

good question,
there is a kind of charging limit between 1 and 3 phase describe in this discussion:
https://github.com/leeyuentuen/alfen_wallbox/discussions/43
but if you want, you can always write something in the wiki page:
https://github.com/leeyuentuen/alfen_wallbox/wiki
What I've done is put them in 3 automation (only use when I use comfort):
first: if the active power of my P1 is higher then 4000, then I will put my wallbox to 0A:
alias: Wall Charge to 0A
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.p1_meter_3c39e722c91c_active_power
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition:
  - condition: and
    conditions:
      - condition: state
        entity_id: select.wallbox_solar_charging_mode
        state: Comfort
        for:
          hours: 0
          minutes: 0
          seconds: 0
      - condition: and
        conditions:
          - condition: numeric_state
            entity_id: number.wallbox_power_connector_max_current_socket_1
            above: 5
            below: 6.9
      - condition: numeric_state
        entity_id: sensor.p1_meter_3c39e722c91c_active_power
        above: 4000
      - condition: numeric_state
        entity_id: sensor.wallbox_active_power_total_socket_1
        above: 1
action:
  - service: alfen_wallbox.set_current_limit
    data:
      entity_id: number.wallbox_power_connector_max_current_socket_1
      limit: 0
mode: single

second is put them on 6A if the value is over 3000W
alias: Wall Charge to 6A
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.p1_meter_3c39e722c91c_active_power
    for:
      hours: 0
      minutes: 0
      seconds: 0
    from: null
    to: null
condition:
  - condition: and
    conditions:
      - condition: state
        entity_id: select.wallbox_solar_charging_mode
        state: Comfort
        for:
          hours: 0
          minutes: 0
          seconds: 0
      - condition: and
        conditions:
          - condition: numeric_state
            entity_id: number.wallbox_power_connector_max_current_socket_1
            above: 6
      - condition: numeric_state
        entity_id: sensor.p1_meter_3c39e722c91c_active_power
        above: 3300
      - condition: numeric_state
        entity_id: sensor.wallbox_active_power_total_socket_1
        above: 1
action:
  - service: alfen_wallbox.set_current_limit
    data:
      entity_id: number.wallbox_power_connector_max_current_socket_1
      limit: 6
mode: single

and third one is if thee value is lower then 1600W, then I set them from 6A to 16A for fully charge,
alias: wallcharge 6A to 16A
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.p1_meter_3c39e722c91c_active_power
condition:
  - condition: and
    conditions:
      - condition: state
        entity_id: select.wallbox_solar_charging_mode
        state: Comfort
        for:
          hours: 0
          minutes: 0
          seconds: 0
      - condition: and
        conditions:
          - condition: numeric_state
            entity_id: number.wallbox_power_connector_max_current_socket_1
            below: 17
      - condition: numeric_state
        entity_id: sensor.p1_meter_3c39e722c91c_active_power
        below: 1600
      - condition: numeric_state
        entity_id: sensor.wallbox_active_power_total_socket_1
        above: 1
action:
  - service: alfen_wallbox.set_current_limit
    data:
      entity_id: number.wallbox_power_connector_max_current_socket_1
      limit: 16
  - delay:
      hours: 0
      minutes: 0
      seconds: 30
      milliseconds: 0
mode: single

I've put my wallbox to only charge on 1 phase, so he can max go to 3600W charging

I'll figure out how to write on the wiki later this week. Thank you for your automation examples.
I see that you use a state platform on your P1 Power consumption. This is a value that changes every few seconds. Is it good for your car/charging station to change the amperage that frequently?
Also, another question; the service "set_current_limit", does it check if the current_limit is already this value and only pushes it when needed, or does it always pushes this value? This would simplify the automation a bit if it did the checks for me.

first one: normally it is just a value change on the device. don't think it will be a big issue. i've use the  for a while
second one: no, but on the automation, i check what for value i have as condition.

Also it asks for a usename and password. This is the username "admin" alongside the "Owner" password.
Simple information, but together with the first point, makes a hell in trying to find out why it will not connect.

Thanks @phulstaert for this info, still it doesn't work for me :-(  (even the service installer is closed)
It would be nice to have more information (logging?) on why this issue happens...

I'm sad to hear it does not work for you.
What error do you get? Can you post a screenshot?
Are you certain about the hostname/IP? Can you ping it? Have you set the IP as fixed in either your router (as a static DHCP lease) or in your Wallbox?
Are you certain about the Owner password? Does that work in the ACE Service Installer?
If i'm not mistaken, you can set the default logging level of home assistant higher; this would catch an error when adding the integration.
Just don't forget to turn if off again after you are done.

Thanks for your quick reply.
I'm 100% certain about the IP, and it works with the ACE Service Installer.
I also added a firewall rule for 502 (TCP, destination port), but I still get the same error.
![image](https://github.com/leeyuentuen/alfen_wallbox/assets/42445148/a0470769-1fe4-4a0a-abd1-
Here are the logs that appear:
2024-07-08 07:20:05.018 ERROR (MainThread) [custom_components.alfen_wallbox.config_flow] ClientError
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1025, in _wrap_create_connection
    return await self._loop.create_connection(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1120, in create_connection
    raise exceptions[0]
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1102, in create_connection
    sock = await self._connect_sock(
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 1005, in _connect_sock
    await self.sock_connect(sock, address)
  File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 641, in sock_connect
    return await fut
           ^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 681, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('<IP_ADDRESS>', 443)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/alfen_wallbox/config_flow.py", line 53, in _create_device
    await device.init()
  File "/config/custom_components/alfen_wallbox/alfen.py", line 105, in init
    await self.get_info()
  File "/config/custom_components/alfen_wallbox/alfen.py", line 128, in get_info
    response = await self._session.get(
               ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client.py", line 581, in _request
    conn = await self._connector.connect(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 544, in connect
    proto = await self._create_connection(req, traces, timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 944, in _create_connection
    _, proto = await self._create_direct_connection(req, traces, timeout)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1257, in _create_direct_connection
    raise last_exc
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1226, in _create_direct_connection
    transp, proto = await self._wrap_create_connection(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/connector.py", line 1033, in _wrap_create_connection
    raise client_error(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host <IP_ADDRESS>:443 ssl:<ssl.SSLContext object at 0x7f771ae73cd0> [Connect call failed ('<IP_ADDRESS>', 443)]

Hi Sam,
Do you have any special firewall rules? (like blocking everything incomming and outgoing?)
I ask this because you specify port 502 on the destination IP (I guess you are talking about the firewall on your HA instance? or on the hypervisor?)
If so, the Alfen Wallbox uses modbus (502) but a lot of commands are send by websocket (https / port 443).  But it doesn't even work with the firewall disabled :smiling_face_with_tear:
I'm using HASS in docker on my synology.
I tried again today, still without luck...

to be sure that you don't have other active instance? because the alfen wallbox support only 1 connection.
so if ace installer or myeve is logged in, then HA can't log in

There is only one websocket connection allowed. Try rebooting the wallbox, wait a minute and retry. This should have disconnected all other connections.
Does the logging give the same error now as before? (the 443 connection failed one)

Thanks! I had upgraded the Wallbox to 7.0 and made it reboot. I guess that's what did it... I tried numbers of times!


gnomeExtensions.pop-shell: unstable-2024-04-04 -> 1.2.0-unstable-2024-10-09

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for gnomeExtensions.pop-shell is: Keyboard-driven layer for GNOME Shell
meta.homepage for gnomeExtensions.pop-shell is: https://github.com/pop-os/shell
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.2.0-unstable-2024-09-18 in filename of file in /nix/store/4vad571bd9fqg82ww5kfakhdn4f642ya-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-09-18

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

gnomeExtensions.pop-shell

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4vad571bd9fqg82ww5kfakhdn4f642ya-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-09-18 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/a925de94c678cc4f791a2d2f03bc693bbc2142ef#gnomeExtensions.pop-shell

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4vad571bd9fqg82ww5kfakhdn4f642ya-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-09-18
ls -la /nix/store/4vad571bd9fqg82ww5kfakhdn4f642ya-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-09-18/bin

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

1 package built:

gnomeExtensions.pop-shell

Maintainer pings
cc @genofire for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for gnomeExtensions.pop-shell is: Keyboard-driven layer for GNOME Shell
meta.homepage for gnomeExtensions.pop-shell is: https://github.com/pop-os/shell
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.2.0-unstable-2024-10-09 in filename of file in /nix/store/b66a4909k6ck53v49cdn35gax5v68zq9-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-10-09

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

gnomeExtensions.pop-shell

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/b66a4909k6ck53v49cdn35gax5v68zq9-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-10-09 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/bcae88a81d045811aa86b8bed21c2d86d9e6dea1#gnomeExtensions.pop-shell

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/b66a4909k6ck53v49cdn35gax5v68zq9-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-10-09
ls -la /nix/store/b66a4909k6ck53v49cdn35gax5v68zq9-gnome-shell-extension-pop-shell-1.2.0-unstable-2024-10-09/bin

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

x86_64-linux

:white_check_mark: 1 package built:

gnomeExtensions.pop-shell

Maintainer pings
cc @genofire for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.


Feature request : dump ltc trace.

Hi,
We are planning to implement 84349466 and 84349468 stories about dumping trace to stdout or to provided file.
We have come up with these idea to implement it –
a) We can have local receptor client implementation which is replica of receptor client code , so that we can dump request and response immediately before sending request and after getting response as implemented by CLI .
We have done some initial implementation for this logic and it seems working fine . We are planning to place this file in ltc/receptort_client directory.  As this client implantation is exclusively for Lattice so in future we may have to sync up with receptor client. Here is quick view of trace on stdout.

b)  Other idea is to add trace logic in receptor client code and raise a PR to receptor repository.
But receptor client has been used by other component such as all CC bridge modules use it.  So putting condition for enabling trace may affect the performance little bit for these modules. As we have observed  graden-linux got many conditions removed based on [performance hit] (https://www.pivotaltracker.com/n/projects/1003146/stories/88539102) .
In both cases trace can be enable with setting environment variable.
Please provide feedback. If any of these idea looks good, we will be happy to raise PR
[#84349466]
Thanks and Regards
@AmitRoushan

We're not ready to consider forking the receptor client implementation into Lattice for this feature.
I agree though, we personally would enjoy this feature in our toolbox.  I think any way we slice it, we ought to attempt to do this right and see what the Diego team (the team that maintains receptor) thinks of supporting this functionality.  Another proposed solution (credit to @onsi) would be to inject an optional lager.Logger and simply log the trace directly to file (my current favorite), I didn't love the idea of the receptor simply barfing it out directly to Stdout anyway.  I checked the garden issue too, I don't see anything like logging as the root cause to their performance issues.
We'll discuss with them what they might consider, and report back whether we should proceed with putting together an implementation.
Thanks,
David

Lattice was a Cloud Foundry project focused on delivering the Diego application scheduler into the hands of users as quickly as possible before Diego was fully integrated to Cloud Foundry. Lattice served that purpose well, but now Diego is available as the application scheduler for Cloud Foundry, and Cloud Foundry is the best way to use Diego. Therefore, Lattice is no longer actively maintained.
Apologies for not addressing your issue.
-Stephen


“DatabaseIntegrityCheck” procedure to get the results delivered via email

Also is it possible to modify the “DatabaseIntegrityCheck” procedure to get the results delivered via email?

I've no connection to Ola but, from my perspective, I would have said "no" because that requires more functionality within the SP to maintain the database mail aspect rather than just the Integrity Check.  The SP is intended to do one task and do it well (which it does).
A way around this would be to have the output of the step go to a log file and then the next step of the job is a 'mail' step which picks up that file and sends it.  That's not a hard job for a DBA to manage.
I had a similar discussion this morning with one of my team to say that I won't give them all the answers they need to anything - but I will point them in the right direction such that they find the answers for themselves :)

SQL Server Agent has the ability to send a mail when the job fails or when the job completes.
Unfortunately it does not have an option to include output - files in the mail. Hopefully this can be improved in a later version of SQL Server.
I am not planning add mail sending functionality, to the stored procedures.


childOf selector

Proposed Changes
When we are reusing a component/ui inside different different UI. Then to correctly identify which component to select we are adding this childOf selector
eg we have a button element and its id is proceed. Now this button is used by two UI component in the same page. Now we have two view components id: add_to_cart and buy_now but the inner button have same id proceed. So if placement of  these two UI element is dynamic it becomes very difficult to correctly select which one represents add_to_cart and which represents buy_now to tap.
childOf selector into rescue. childOf selector tells maestro to select id or text which is child of provided selector.
eg if we want to tap on buy now button we can easily write.
tapOn:
   text: "proceed"
    childOf:
        - id: "buy-now"

this will first search for Element with id  "buy-now" then inside it's child tree it will try to find  element with id "proceed"
View

Testing

Issues Fixed

@sandeepjoshi19 please also raise a PR with documentation updates in https://github.com/mobile-dev-inc/maestro-docs and tag me as a reviewer :)

@axelniklasson Raised the PR but I am not able to add reviewers.
PR: https://github.com/mobile-dev-inc/maestro-docs/pull/31


Change code formatter to spring-javaformat

https://github.com/spring-io/spring-javaformat

Java 8 is not supported 😂


[application-gateway/ingress-controller-overview] Please add a link for azure.github.io/application-gateway-kubernetes-ingress

Please add a link for https://azure.github.io/application-gateway-kubernetes-ingress/ in this AGIC overview page or another page.
I couldn't find any link for azure.github.io/application-gateway-kubernetes-ingress in https://docs.microsoft.com/.
So, it seems Azure users cannot reach azure.github.io/application-gateway-kubernetes-ingress from https://docs.microsoft.com/.
azure.github.io/application-gateway-kubernetes-ingress has the following several effective pages for user configure AKS and Application Gateway.

https://azure.github.io/application-gateway-kubernetes-ingress/annotations/
https://azure.github.io/application-gateway-kubernetes-ingress/helm-values-documenation/

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

ID: 4ce7e4ca-0ac4-9d41-9546-b8f5e7ee654e
Version Independent ID: 476b4dc9-46e3-71eb-e08e-67137004b804
Content: What is Azure Application Gateway Ingress Controller?
Content Source: articles/application-gateway/ingress-controller-overview.md
Service: application-gateway
GitHub Login: @Caya
Microsoft Alias: caya

@mazgi , thank you for the feedback. We'll review this and get back to you shortly!

Hi - I've assumed ownership of this article. I am reassigning the issue to myself. We currently have a large backlog of GitHub issues so I'm prioritizing these and working them as I am able.  Please reply to this thread if you are still experiencing an issue with the article that is referenced, or if you feel the issue can be closed now.  Thanks! #reassign:greg-lindsay

This is being tracked as internal content issue: 91172
#please-close


Update to be consistent with second edition?

Are there any plans to update the rethinking.py code and code examples to be consistent with the second edition of the book? For example is there going to be an implementation of quap?

Hi @asett0, codes in this repository have not been updated to the latest Pyro versions. Please check out this repository for the updated codes of 2nd edition in NumPyro. It is easier to port NumPyro code to Pyro code than to update the current code in this repository.


make release script to only generate release build, and not deal with…

… git

Coverage remained the same at 12.672% when pulling 7dd4c4139d576aaf84a9fc99a851fda284b61e70 on u9520107:update-release-script into 678898d7eb619fcb2c157139039501c33d38c944 on ringcentral:master.


MAPREDUCE-7343. Increase the job name max length in mapred job -list.

https://issues.apache.org/jira/browse/MAPREDUCE-7343

Thanx @qizhu-lucas for the review!!!


Update dx-graphics-hlsl-buffer.md

The link doesn't work

@aschrein-AMD : Thanks for your contribution! The author(s) have been notified to review your proposed change.