I think this is a typo mistake

Hi there i was trying to use this package and while reading the docs I found this type syntax ...
.
.
.

Version 0.30.1 is released. https://pub.dev/packages/flutter_platform_widgets/versions/0.30.1 which addresses this

No the same syntax error is still exits .

check the parentheses .

return PlatformAppBar(     title: new Text('Platform Widgets'),     leading: PlatformIconButton()),     trailingActions: <Widget>[       PlatformIconButton(),     ],   );

should be return PlatformAppBar(     title: new Text('Platform Widgets'),     leading: PlatformIconButton(),     trailingActions: <Widget>[       PlatformIconButton(),     ],   );

Thanks. I have updated the master branch. It will get updated to pub.dev when another release is made


Functions called twice by macro RETURN_IF_NOT_OK in error condition

Description:
The macro RETURN_IF_NOT_OK should only be used with variables, but it is also used with function calls. If the function fails, it is called again, because the macro is defined like this:
#define RETURN_IF_NOT_OK(variable)                                                                 \
  if (!variable.ok()) {                                                                            \
    return variable;                                                                               \
  }

There are other similar macros, e.g. RETURN_IF_STATUS_NOT_OK.
This is a problem because some functions return a different result when called for the second time.
Repro steps:
This configuration uses an unknown command operator: example.yaml.gz
Validating this configuration reports the error correctly:
$ ./envoy --mode validate -c example.yaml
...
[2024-10-16 17:23:12.487][108939][critical][main] [external/envoy/source/server/config_validation/server.cc:71] error initializing configuration 'example.yaml': Not supported field in StreamInfo: DOES_NOT_EXIST

But in serve mode, envoy reports a different and wrong error:
./envoy --mode serve -c example.yaml
...
[2024-10-16 17:24:21.360][109304][critical][main] [external/envoy/source/server/server.cc:412] error initializing config '  example.yaml': Duplicate static GenericSecret secret name token
[2024-10-16 17:24:21.361][109304][info][main] [external/envoy/source/server/server.cc:1038] exiting
Duplicate static GenericSecret secret name token

This happens because RETURN_IF_NOT_OK is used with a function call in source/server/server.cc:
RETURN_IF_NOT_OK(config_.initialize(bootstrap_, *this, *cluster_manager_factory_));

config_.initialize() is called twice, but secrets can only be initialized once.
Bugfix:
Probably the macro RETURN_IF_NOT_OK and similar macros should be defined in a different way.
If the macro cannot be changed, all usages of the macro must be checked and maybe fixed, for example:
auto status = config_.initialize(bootstrap_, *this, *cluster_manager_factory_);
RETURN_IF_NOT_OK(status);

@mkauf RETURN_IF_NOT_OK is defined here https://github.com/envoyproxy/envoy/blob/ee6163435be32f0efd3ad068e90ea89c974991c3/envoy/common/exception.h#L59-L62, which is different from your post?

@tyxia I have debugged old code. You are right, this bug has been fixed by #35482.
I have seen that a related issue has been reported by a different user: #36697, this is also fixed.


ConfigResponse Protobuf Broken

There is an issue parsing ConfigResponse from the AuxBrain API as noted here.
In addition to failures using your attempts in Javascript, I've tried using Scala and Dart libraries unsuccessfully.
I believe I've tracked down the underlying cause using protoscope which can parse raw protocol buffer data and show the underlying structure in terms of tag numbers and values.
Here's an excert of the protoscope output of a ShellSpec taken from the dlcCatalog section of a ConfigResponse:
...
  2: {
      1: {"ei_depot_1_new_order"}
      4: 20
      5: 0
      6: 0.0  # 0x0i64
      12: {
        1: 100
        2: {
          1: {"ei_depot_1_new_order"}
          2: {
            14:SGROUP
            13: 101
            13:EGROUP
            13:EGROUP
            14:SGROUP
          }
          3: {"rpo"}
          4: {
            "https://www.auxbrain.com/dlc/shells/ei_depot_1_new_order_36e225eeb89397d3698046a"
            "14321db3b.rpoz"
          }
          5: {"d385b916e34fcc09fde5dbc6baf33101928f47a3b9ee479f9688cb2eb3d2e745"}
          6: 1
          7: 241532
        }
      }
      13: {"new_order"}
      14: 0
      17: -1.691003821822219e09   # 0xc1d932aaeb749f3ci64
      21: 651
    }
...

Most of the ShellSpec messages have an identical structure as this one, except this particular one:
...
  2: {
    1: {"ei_depot_1_pink"}
    3: {"Pink"}
    4: 16
    5: 0
    6: 0.0  # 0x0i64
    12: {
      1: 100   # AssetType given via the enums value defined in the definition file
      2: {
        1: {"ei_depot_1_pink"}
        2: {
          14:SGROUP
          13: 101
          13:EGROUP
          13:EGROUP
          14:SGROUP
        }
        3: {"rpo"}
        4: {
          "https://www.auxbrain.com/dlc/shells/ei_depot_1_pink_17632cbe8c95299bfe7101c1df22"
          "f2af.rpoz"
        }
        5: {"1429dd3fd2f18d66e891aeb9b5dacabac600fc5147b21f362fa51e0ecd8cf2ee"}
        6: 1
        7: 257372
      }
      1: {"ei_depot_1"}    # <-- This looks to be the culprit
    }
    13: {"pink"}
    14: 0
    15: 0
    17: -1.691003821822258e09   # 0xc1d932aaeb749fe0i64
    21: 46
  }
...

Notice that the ShellSpec.ShellPiece denoted by the 12 tag number has 2 child elements with the same tag number of 1. The first child has a value of 100 and the second has a value of {"ei_depot_1"}. Theses both signify that the ShellSpec.ShellPiece has an asset type of Depot_1 but the representation is complement different. I'm not sure if this is the only example of this, but it's the first case that blows up my protobuf parser.
I suspect that the Python parsing code doesn't care about this while other languages do (the proper behavior IMO).
If this is all true, then I think the only fixes are to either modify the parser for whatever language you're using (yuck), or better (but probably less likely), is to have AuxBrain fix their definition of this shell in particular on the server side.

Following up, I can confirm that after removing the 'culprit' field from my initial analysis and then reencoding with protoscope, I was able to successfully parse the edited message using the standard Dart protobuf library. Gaining more confidence this is the real issue.
It's still confusing to me how the Python protobuf library could emit this encoding in the first place though.

Seems like the additional mystery field is an unknown field which is preserved on the Python side. If I call DiscardUnknownFields on the Python object before saving the ShellSpec in question, I'm able to successfully parse the message in Dart. Reelevant Documentation.
Seems like unknown fields shouldn't be so exotic that a popular Javascript, Dart, etc. protobuf library wouldn't be able to handle it.

Nice find. I'll update my python config fetcher to discard that field as well.

I don't think that will have an effect in your script since you're saving the json representation, but don't think it will hurt either. Or maybe I'm missing a piece of what your python stuff is doing.
I've developed a workaround where I search for the unknown field byte sequence and modify the tag number which works fine, but has the potential (however unlikely) to break in the future if aux decides to add additional fields to the shellspec struct that will use my modified tag number. I can share if you're interested, but it's probably not something you'd want to use in something as widely used as your site.


[WIP] feat(table): add getRowDescriptor property

Description of the problem
The Table component now has several methods, each of which interacts with the display of the string -- getRowId, getRowClassNames, isRowDisabled.
It seems that it would be logical to make one method instead of 3, which will improve the user experience.
In the future, this method can be expanded, for example, you can add a description of whether the line should change the background on hover.
The proposed solution
Set up all 3 props, add a new one.
https://st.yandex-team.ru/UXRFC-393

https://github.com/gravity-ui/uikit/blob/dc062af8f514a570dcbacaa7a61dfb05a21a4b96/src/components/Table/hoc/withTableSelection/withTableSelection.tsx#L241 - getRowDescriptor should be used here too

Also could you please add tests and stories with new property?

https://github.com/gravity-ui/uikit/blob/1c551f72df06bde4b6fa7745e501ce1586f9eb69/src/components/Table/hoc/withTableActions/withTableActions.tsx#L118 - new property should also be used here.


Activate the never_go_down again switch (fix slowdown issue)

Tried this in dev and on prod, seemed to eliminate the slowdown issue.
We were having a lot of 'idle' and 'idle in transaction' connection issue with pgpool.
Connection should never go idle now which should let new connections in.

Setting SetMaxIdleConns(-1) is the culprit, will try to work around it. (I don't know why it fails with sqlite)


下拉框select设置了宽度, 并且设置filterable之后, 文本过长省略没有title显示, 即使设置了render-tag也不行

TuSimple/naive-ui version (版本)
2.37.0
Vue version (Vue 版本)
3.3.9
Browser and its version (浏览器及其版本)
120.0.6099.199
System and its version (系统及其版本)
windows 10
Node version (Node 版本)
Reappearance link (重现链接)
https://codesandbox.io/p/devbox/naive-select-vue-dnjhwr
Reappearance steps (重现步骤)
选择下拉框选项, 鼠标移入, 设置filterable的下拉框没有title
Expected results (期望的结果)
希望选择选项后, 设置过filterable的下拉框, 文本省略也有title
Actual results (实际的结果)
选择选项后, 设置过filterable的下拉框, 文本省略没有title, 设置render-tag也没有
Remarks (补充说明)

I'm not quite understanding what you're aiming for. I'm not sure if it's the google translation to English. Looking at the example, it seems like 3 functional select components. When I select an object from any of the components, all the components are set. I'm not exactly sure what you are referring to as far as title. I see the text above the select options that refers to a title and they don't seem to be changing or disappearing in any use case.

function renderLabel(option: SelectOption) {
  if (option.type === "group") return option.label + "(Cool!)";
  return h(
    "span",
    {
      title: option.label,
      class: "my-tag",
    },
    option.label
  );
}

 <n-select
    :options="options"
    :filterable="true"
    :style="{ width: '200px' }"
    :renderLabel="renderLabel"
  />

You should use renderLabel rather than renderTag


[WIP]Ipv6 Support

What type of PR is this?
Add one of the following kinds:
/kind feature
What this PR does / why we need it:

workload mode supports IPv6

[ ] Control plane supports configuration issuance related to IPv6
[x] eBPF programs support IPv6
[ ] Authentication process supports IPv6
[x] Kmesh management supports IPv6

ads mode supports IPv6

[ ] Control plane supports configuration issuance related to IPv6
[ ] eBPF programs support IPv6
[ ] Kmesh management supports IPv6

[ ] OE 23.03 adaptation
[ ] IPv4-mapped IPv6 scenario
[ ] Document refresh

Which issue(s) this PR fixes:
Fixes https://github.com/kmesh-net/kmesh/issues/291
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report
Attention: Patch coverage is 40.00000% with 24 lines in your changes missing coverage. Please review.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Flag
Coverage Δ

unittests
36.98% <40.00%> (+4.96%)
:arrow_up:

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

Files
Coverage Δ

pkg/controller/workload/bpfcache/backend.go
66.66% <ø> (+66.66%)
:arrow_up:

pkg/controller/workload/bpfcache/frontend.go
32.00% <ø> (+32.00%)
:arrow_up:

pkg/controller/workload/bpfcache/service.go
66.66% <ø> (+66.66%)
:arrow_up:

pkg/controller/workload/cache/workload_cache.go
66.66% <100.00%> (ø)

pkg/auth/rbac.go
56.75% <57.14%> (ø)

pkg/bpf/bpf_kmesh_workload.go
0.00% <0.00%> (ø)

pkg/controller/workload/workload_processor.go
43.65% <50.00%> (+28.04%)
:arrow_up:

pkg/nets/nets.go
20.68% <0.00%> (-7.89%)
:arrow_down:

pkg/utils/test/bpf_map.go
38.77% <33.33%> (-1.77%)
:arrow_down:

... and 2 files with indirect coverage changes


WIP: Kirkstone next

I'm opening this so others see the WIP. If others want to join in porting sunxi to kirkstone feel free to do so.

Hi @HerrMuellerluedenscheid!
Thanks a lot for the contribution! Just a short heads up, review will be delayed because I'm out of office this week.
One thing early: can you please add your SOB to the patches?
Thanks!

I'm a little puzzled:
NOTE: u-boot-1_2022.01-r0 do_patch: --- Patch fuzz start ---
Applying patch 0003-Integration-of-Mender-boot-code-into-U-Boot.patch
patching file include/env_default.h
Hunk #2 succeeded at 26 with fuzz 2.
patching file scripts/Makefile.autoconf

Now at patch 0003-Integration-of-Mender-boot-code-into-U-Boot.patch

--- Patch fuzz end ---
NOTE: u-boot-1_2022.01-r0 do_patch: Applying patch '0001-nanopi_neo_air_defconfig-Enable-eMMC-support.patch' (../meta-sunxi/recipes-bsp/u-boot/files/0001-nanopi_neo_air_defconfig-Enable-eMMC-support.patch)
NOTE: u-boot-1_2022.01-r0 do_patch: Applying patch '0002-Added-nanopi-r1-board-support.patch' (../meta-sunxi/recipes-bsp/u-boot/files/0002-Added-nanopi-r1-board-support.patch)
WARNING: u-boot-1_2022.01-r0 do_patch: Fuzz detected:

Applying patch 0003-Integration-of-Mender-boot-code-into-U-Boot.patch
patching file include/env_default.h
Hunk #2 succeeded at 26 with fuzz 2.
patching file scripts/Makefile.autoconf

The context lines in the patches can be updated with devtool:

    devtool modify u-boot
    devtool finish --force-patch-refresh u-boot <layer_path>

Don't forget to review changes done by devtool!

WARNING: u-boot-1_2022.01-r0 do_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz]

Point is that that patch does not change a file that was patched by any of the patches there were modified in this MR.

Closing this for now as I got a little stuck and don't really have time to continue unfortunately.


mismi-cli: Apply coding standards

Mainly just making sure all external imports are qualified or
explicit. No functional changes.
! @olorin @tmcgilchrist

🚌


Text wrap in bottom Nav actions.

Describe the bug
In the contents of the bottom nav, the text for the "My class" label gets wrapped for smaller android screens when the user switches between contents of the bottom nav, which leads icon for my class uplifted a bit higher (seems like overflowing)  as compared to other icons which sets a bad UI example.
To Reproduce
Steps to reproduce the behavior:
1.swipe between the contents of the bottom nav and stay on my class label
currently on the web:

Expected behavior

icon for "my class" label should be even with other labels means behave same as other labels no text wrap
Environment (please complete the following information):

OS: windows
Browser: chrome

@Abhishek-kumar09 can i work on this ?

@Abhijay007 I reported this earlier & just create a PR regarding this.

Nice!! 😁 as you opened a PR for this issue but from next time At least
take mentor's permission before opening a PR . At least give mentors some
time to review issue once and approve it!!
On Thu, 18 Mar 2021, 12:44 Rajat Gupta, @.***> wrote:

@Abhijay007 https://github.com/Abhijay007 I reported this earlier &
just create a PR regarding this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/codeforcauseorg/edu-client/issues/114#issuecomment-801690153,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APLHP3Q2MX5DTD4MSAXMXHLTEGR55ANCNFSM4ZLEEH3A
.

@Abhijay007, I reported this earlier #27 and was assigned

Ok
On Thu, 18 Mar 2021, 14:55 Rajat Gupta, @.***> wrote:

@Abhijay007 https://github.com/Abhijay007, I reported this earlier #27
https://github.com/codeforcauseorg/edu-client/issues/27 and was assigned
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/codeforcauseorg/edu-client/issues/114#issuecomment-801767259,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APLHP3UAMSC4O4NVFUMRSCTTEHBJRANCNFSM4ZLEEH3A
.

bug still exists for smaller screens:

@Abhishek-kumar09  can I work on this?


Write ATS for TG requirement 42

An <inspire_common:DEFAULT> style for each theme shall be as defined in the "Portrayal" section of the INS DS, Article 14.

Agreed, could be part of Data spec test (but then still it is hard, because the names are placeholders). I think it is not testable for View Services.


Backtraces are not detected as Python backtraces

When sending any kind of error backtrace the python language_integration_version isn't being picked up as Python for some reason.
The appsignal.log seems correct to list: language_integration_version: Some("python-0.1.1")
But the backtrace has the wrong format:
[2023-06-07T12:23:28 (agent) #413][Trace] Add OpenTelemetry exception to span: name: "ValueError" message: "Something went wrong" backtrace_json: "Traceback (most recent call last):\n  File \"/usr/local/lib/python3.11/site-packages/appsignal/cli.py\", line 299, in run\n    raise ValueError(\"Something went wrong\")\nValueError: Something went wrong\n"

It should be using backtrace, not backtrace_json, and not include lines that don't start with File.
Something must be wrong with the language detection, but we set the _APPSIGNAL_LANGUAGE_INTEGRATION_VERSION correctly.

The language integration is empty for the agent aggregator.
It should by default use the one from the config. Turns out the aggregator gets initialized with the language_integration_version from the config, but not the collector payload. We set it much later on the collector payload, so we can't use it to fetch the language integration version.
Either set it on the collector payload on initialization or have the HttpMessage handler check both the config and the OpenTelemetry resource attribute, and I prefer the former.


add notebook

Ⅰ. Describe what this PR does
II. Does this pull request fix one issue?

III. Special notes for reviewers if any.

Codecov Report

Merging #200 (6612853) into master (0eb96cd) will increase coverage by 2.19%.
The diff coverage is 69.16%.

:exclamation: Current head 6612853 differs from pull request most recent head 311e496. Consider uploading reports for the commit 311e496 to get more accurate results

@@            Coverage Diff             @@
##           master     #200      +/-   ##
==========================================
+ Coverage   23.18%   25.38%   +2.19%
==========================================
  Files          75       76       +1
  Lines        4502     4727     +225
==========================================
+ Hits         1044     1200     +156
- Misses       3319     3376      +57
- Partials      139      151      +12

Flag
Coverage Δ

unittests
25.38% <69.16%> (+2.19%)
:arrow_up:

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

Impacted Files
Coverage Δ

controllers/model/modelversion_controller.go
72.97% <50.00%> (ø)

controllers/notebook/notebook_controller.go
69.33% <69.33%> (ø)

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 0eb96cd...311e496. Read the comment docs.


ViewSlot error on 1.5.0

I'm submitting a bug report

Library Version:
1.5.0

Node Version:
14.19.0

NPM Version:
6.14.16

JSPM OR Webpack AND Version
Webpack 5

Browser:
all

Language:
all

Current behavior:
The latest release, 1.5.0, seems to completely break my app. The following stacktrace occurs:
------------------------------------------------
Inner Error:
Message: Cannot set properties of undefined (setting 'viewSlot')
Inner Error Stack:
TypeError: Cannot set properties of undefined (setting 'viewSlot')
    at new ViewSlot (aurelia-templating.jss:1291:1)
    at Object.invoke (aurelia-dependency-injection.jss:384:1)
    at InvocationHandler.invoke (aurelia-dependency-injection.jss:357:1)
    at Container.invoke (aurelia-dependency-injection.jss:543:1)
    at StrategyResolver.get (aurelia-dependency-injection.jss:101:1)
    at Container._get (aurelia-dependency-injection.jss:504:1)
    at Container.get (aurelia-dependency-injection.jss:494:1)
    at Container.elementContainerGet [as get] (aurelia-templating.jss:2336:1)
    at aurelia-dependency-injection.jss:383:51
    at Array.map (<anonymous>)
End Inner Error Stack
------------------------------------------------

    at new AggregateError (aurelia-pal.jss:30:1)
    at Container.invoke (aurelia-dependency-injection.jss:546:1)
    at StrategyResolver.get (aurelia-dependency-injection.jss:101:1)
    at Container._get (aurelia-dependency-injection.jss:504:1)
    at Container.get (aurelia-dependency-injection.jss:494:1)
    at Container.elementContainerGet [as get] (aurelia-templating.jss:2336:1)
    at aurelia-dependency-injection.jss:383:51
    at Array.map (<anonymous>)
    at Object.invoke (aurelia-dependency-injection.jss:383:1)
    at InvocationHandler.invoke (aurelia-dependency-injection.jss:357:1)```

@michaelbull you are reporting an issue related to templating in templating-router repo. So I guess:

your app upgraded to<EMAIL_ADDRESS>just fine?
then your app crashes when upgraded<EMAIL_ADDRESS>
Can you also run
npm ls aurelia-templating

to see if there's any duplication of modules?

@michaelbull I think you are getting 2 different versions of templating with 1.5.0

can you explicitly install the latest version of templating?

I can confirm that with<EMAIL_ADDRESS>&<EMAIL_ADDRESS>it does indeed work.
This must mean that anyone that installs the latest aurelia-bootstrapper with aurelia-ui-virtualization is going to hit this problem though surely? This would indicate that they are depending on dynamic versions of aurelia-templating and some breaking change has occurred and has been automatically picked up by npm install because of the version not being explicitly pinned.

for aurelia-binding, apps generated from our cli will have it aliased to the top level module in node_modules and it will work. Maybe we should do the same thing for aurelia-templating?
cc @3cp

If<EMAIL_ADDRESS>requires<EMAIL_ADDRESS>and aurelia-ui-virtualization@any requires<EMAIL_ADDRESS>then installing<EMAIL_ADDRESS>should bring the common dependency aurelia-templating to 1.11.1. Shouldn't this be the expectation?

That is not my expectation as I do not have an explicit dependency on aurelia-templating-router.
I have the following in my 'shared' project (which acts as a base for all Aurelia apps within my company):
    "aurelia-bootstrapper": "2.3.3",
    "aurelia-http-client": "1.3.1",
    "aurelia-loader-nodejs": "1.1.0",
    "aurelia-pal-nodejs": "2.0.0",
    "aurelia-webpack-plugin": "5.0.3"

Then in my individual apps I have:
    "my-shared-project": "...",
    "aurelia-configuration": "2.0.0",
    "aurelia-i18n": "3.1.4",
    "aurelia-ui-virtualization": "1.0.0-rc2",

Last week this worked. This week, because of the versions not being explicit, I run npm install without changing a single one of these versions, and everything breaks because the versions have somehow resolved aurelia-templating-router to a version that isn't compatible with something else.
If you are following semver, and are using dynamic dependency versions in all of the first-class Aurelia projects, then how can this happen unless a breaking change has been made in one of these libraries without bumping a major version?

This part

the versions have somehow resolved aurelia-templating-router to a version that isn't compatible with something else.

confused me. My understanding is npm install should resolve to a single, latest version of templating.

If you are following semver, and are using dynamic dependency versions in all of the first-class Aurelia projects, then how can this happen unless a breaking change has been made in one of these libraries without bumping a major version?

I'll assume this is a rhetorical question, and you can explain why npm install behaved in such way. So if you can give some comment explaining that, it'd be great.
For a breaking change has been made in one of these libraries without bumping a major version: there's been one breaking change here: https://github.com/aurelia/templating-resources/pull/411/files#diff-c2551d45d62d2a8cbbe2fbb4b9430778e2215efe0f345b6d709fa5bd8edeb360R10-R11 though we won't be strictly following semver for this instance, as it would unnecessarily create more trouble. The lib aurelia-templating-resources was bumped 1 minor version for that "security" resolution.

My understanding is npm install should resolve to a single, latest version of templating.

Yes, I agree because the version of templating that I am pulling from bootstrapper or whever is dynamic and will take the latest 1.x version.

'll assume this is a rhetorical question, and you can explain why npm install behaved in such way. So if you can give some comment explaining that, it'd be great.

I was trying to explain the original question that you asked if it matches my expectation.

though we won't be strictly following semver for this instance, as it would unnecessarily create more trouble

This answers my question.
All of the Aurelia projects have dynamic dependency versions on "1.x" of others, which means consumers will just auto-upgrade when running npm install, and they will break their app because they unknowingly adopted a breaking change via a transitive dependency chain that presumes everything is okay as long as a major version bump hasn't occurred - obviously it was not okay in this instance.
If semver isn't going to be followed when making breaking changes, but dynamic dependency versions are going to be defined in every first-party Aurelia project, then you are guaranteed to end up breaking things for the consumer of the packages, as evidenced by the current situation of anyone trying to install aurelia-bootstrapper and aurelia-ui-virtualization today.

though we won't be strictly following semver for this instance, as it would unnecessarily create more trouble

This may have caused more trouble for you as maintainers, but as the end-user of your product this has caused the ultimate trouble of breaking all apps just by simply running npm install on a different day, without changing a single line of code in any of the project or anything in the package.json.

The duplicated version sounds like from an existing lock file. Once you remove all node_modules and lock file, the version should be resolved to just one.

It seems there are 2 matters being conflated here:

There's an issue by simply upgrading a core Aurelia module. Maybe applications need to declare common dependencies themselves to ensure this issue not happening again. It's not a direct issue with Aurelia.
There's an inaccurate versioning recently in one of the Aurelia core module releases. This is because the changes isn't practically breaking: no serious applications rely on the default sanitizer.

This may have caused more trouble for you as maintainers, but as the end-user of your product this has caused the ultimate trouble of breaking all apps just by simply running npm install on a different day, without changing a single line of code in any of the project or anything in the package.json.

Believe it or not, this causes issue to the entire Aurelia ecosystem. We had a bad experience releasing aurelia-binding v2 before, for a not really breaking change change, and it was a headache for folks for awhile until we had to resolve to hacks in our default CLI template.
I hope all the original questions have been answered.


Add support to fetch the certificate

Signed-off-by: Hemant Chaudhari<EMAIL_ADDRESS>Description
Add support to fetch the certificate
Issues Resolved
None
Check List

[ ] New functionality includes testing.

[ ] All tests pass($ tox).

[ ] New functionality has been documented in the README if applicable.

[ ] New functionality has been thoroughly documented in the examples (please include helpful comments).
[ ] New endpoints supported are updated in the endpoints-support.md file.

[ ] Changes are documented in the CHANGELOG.

Hi @sijeesh , @svt-kmcdaniel
All parameters that we have as part of "get_all" are not applicable to get call on certificates. In order to keep the code in sync and not to make any changes to current architecture we followed the same.
However due to this we do see some parameters getting added to URL string, but they would not be consumed by API, REST will simply ignore those extra parameters.
Please let us know if this approach is fine for this implementation.
Regards,
Hemant Chaudhari

Hi @sijeesh , @svt-kmcdaniel
All parameters that we have as part of "get_all" are not applicable to get call on certificates. In order to keep the code in sync and not to make any changes to current architecture we followed the same.
However due to this we do see some parameters getting added to URL string, but they would not be consumed by API, REST will simply ignore those extra parameters.
Please let us know if this approach is fine for this implementation.
Regards,
Hemant Chaudhari

@ its fine, the extra parameters will be ignored.
If there is any error with extra parameters, we don't have to use the general implementation of get_all,  just make a GET call from the resource's get_all method and get the response.


Rancher Up - GKE Nodes not present.

Rancher versions:
Master 5/8/2018
Steps:
Create a new cluster with Rancher up, using the below YAML File.
clusters:
    test:
        googleKubernetesEngineConfig:
            disableHorizontalPodAutoscaling: false
            disableHttpLoadBalancing: false
            disableNetworkPolicyConfig: false
            diskSizeGb: 100
            enableAlphaFeature: false
            enableKubernetesDashboard: false
            enableLegacyAbac: false
            nodeCount: 1
            type: googleKubernetesEngineConfig
            machineType: g1-small
            zone: us-central1-f
            clusterIpv4Cidr: null
            credential: "$pasteYourGkeCredentialInHere"
            projectId: rancher-dev
            masterVersion: 1.9.6-gke.1

Results:
Cluster is created, however there are no nodes present.

Available with Rancher CLI v2.0.2-rc1

@StrongMonkey Exported yaml from cluster. Attempted rancher up with exported yaml after deleting cluster that was in use. (So name would still be unique.) Did not see new cluster start on rancher server.

same https://github.com/rancher/rancher/issues/13353#issuecomment-396411313

Validated with Rancher CLI v2.0.2-rc1. Able to create GKE cluster Closing issue.


A lot of bugs I found

Please add a different layout file for landscape /portrate view as landscape is not responsive
As when other app which is using camera and also we have our app opening bar code scanner the app app camera crash
did change dependency function is required i think
also a lot more please solve

This will help https://www.youtube.com/watch?v=w-n0jUrUtPI&list=PLQhQEGkwKZUqZC2QAp_u4ZAzqpsCCRvmM&index=10 https://www.youtube.com/watch?v=QpnVENc9dIA&list=PLQhQEGkwKZUqZC2QAp_u4ZAzqpsCCRvmM&index=11


Cursor position is incorrect when prompt includes multi-byte character

This is my bash prompt
PS1='\[\033[0;33;44m\]\w\[\033[0m\] \! 🎵  '
The cursor is positioned incorrectly in Hyper:

It is correct in Terminal:

If I change 🎵 to $ in my prompt, the cursor is positioned correctly in Hyper:

Hyper 1.3.1
Electron 1.4.15
darwin x64 15.6.0

Duplicate #1506


Login issue on server

Getting login issue on server but if I run this project on local then its working fine

Manual check was required

This means LinkedIn is asking for a manual check: a recaptcha or asking to optionally add a phone number.
This is very common when you try to login at a new device. More details how to solve here: https://github.com/linkedtales/scrapedin/blob/master/README.md#tips


isSlugUnique v3

Hi folks,
Before the V3 we had exported the isSlugUnique helper for use into the schema.
Now I just saw the function createIsSlugUnique that so for I understood it's for generate the same function.
What is the correct way to use it? I'm trying do this:
// Helper code file
import { createIsSlugUnique } from '@sanity/document-internationalization';
import { getCliClient } from 'sanity/cli';

const client = getCliClient({ apiVersion: '2021-10-21' });
export const isSlugUnique = createIsSlugUnique(client);

//Schema
import { isSlugUnique } from '../../helpers';

....
  fields: [
    {
      name: 'internalName',
      type: 'string',
      title: 'Internal name',
      description: 'For internal use within Sanity',
      localize: false,
    },
    {
      name: 'slug',
      type: 'slug',
      title: 'Slug',
      description: 'Used to generate the page URL (eg., "/careers" or "/contact")',
      validation: (rule: Rule): Rule => rule.required().error('You need a unique slug for the URL'),
      options: {
        source: 'internalName',
        maxLength: 200,
        isUnique: isSlugUnique,
      },
    },
....

But I'm getting the following error after use that:

This is how we implemented it.
isUnique: async (slug, context) => {
        const { getClient } = context;
        const client = getClient({ apiVersion: '2021-10-21' });
        const validate =  createIsSlugUnique(client);

        return validate(slug, context)
      }

Thank you so much @lourencelinao it worked like a charm.


Reading OpenCV generated exr image causes "Cannot handle YCA image now!" error

I am able to use exrdisplay to read images from https://github.com/openexr/openexr-images, so I believe I build openexr correctly. However, I am having trouble to read the exr images generated by OpenCV. The OpenCV code that I used to generate exr image is
cv::Mat test = cv::Mat(480, 640, CV_32FC1, cv::Scalar(1.1f));
cv::imwrite("test.png", test);

It's a single channel image with all value 1.1f, but when I attempt to load it with exrdisplay
./exrdisplay test.png

I get an error message
Cannot handle YCA image now!
Warning: Environment variable CTL_DISPLAY_CHROMATICITIES is not set; using default value (chromaticities according to Rec. ITU-R BT.709).
Warning: Environment variable EXR_DISPLAY_VIDEO_GAMMA is not set; using default value (2.2).

and there is nothing shown in the image.
But the weird thing is if I do sudo apt-get install openexr-viewers instead of building from source. I am actually able to read the exr image successfully. Is it possible that some of the new commits breaks something?

Looks like this has always been the behavior of exrdisplay.  If no channel name is passed on the command line, it will assume it's trying to display RGB and when it encounters a channel named Y, you'll run into this case.  You can use it to display the file by running 'exrdisplay -c Y yourfile.exr'

Thanks, the -c Y flag solves it for me


[Backport main] Made hybrid search active by default by flipping feature flag default

Backport https://github.com/opensearch-project/neural-search/pull/274/commits/174f2c9579b9d374592142de190eec794ff33f2e from https://github.com/opensearch-project/neural-search/pull/274

@martin-gaievski can you fix the build issue too. I know this is a backport to main from 2.x or you want to take that fix change separatly?

@martin-gaievski can you fix the build issue too. I know this is a backport to main from 2.x or you want to take that fix change separatly?

Yes, exactly. Actually I created PR for fixing build issues few days back: https://github.com/opensearch-project/neural-search/pull/285.


Update .editorconfig

Add a few more settings to avoid issues with manual edits

difficult to test, but ok to merge, lets try it


Timesheet - 13/01/2022 - Aries Cambarijan

Task 1
Meeting with Led
Sourcing Candidates in LinkedIn
Inviting Candidates to apply
Proof of Work
https://docs.google.com/document/d/1rkAaJlcnIQZv8xqzTI3SUh1GTtMNR2L3mx3vA3cSD54/edit?usp=sharing
Time Spent
2 hours

Total Time Spent
2 hours
Account Number
96d79abb34b4df4201725c6208fd5580f264f70f3e69d58d61b94a8b5da503da

Hey @arieskath1030 I don't have access to the doc. Can you please add it to thenewboston google drive?


[PKG-4970] 1.4.5 Initial build

dedupe_Lehvenshtein_search 1.4.5 :snowflake:
Destination channel: Snowflake
Links

PKG-4970
Upstream repository

Explanation of changes:

Recipe from scratch
Includes upstream tests

Should the repo be AnacondaRecipes/dedupe_levenshtein_search-feedstock (no h before the v)?

Should the repo be AnacondaRecipes/dedupe_levenshtein_search-feedstock (no h before the v)?

You're absolutely correct, it should be fixed now.


not getting any numeric data in the converted json

Hi,
My CSV files are having a lot to numeric data. But in the resultant json, all the numeric data is converted to string.
Example,
My CSV file
Temperature,Humidity,Wind_Speed,Pressure,starttime
78,53,51,42,2015-03-01T00:06:38.000
57,70,14,36,2015-03-01T00:25:28.000
66,60,15,47,2015-03-01T01:11:26.000
Result JSON
[ { Temperature: '78',
Humidity: '53',
Wind_Speed: '51',
Pressure: '42',
starttime: '2015-03-01T00:06:38.000' },
{ Temperature: '57',
Humidity: '70',
Wind_Speed: '14',
Pressure: '36',
starttime: '2015-03-01T00:25:28.000' },
{ Temperature: '66',
Humidity: '60',
Wind_Speed: '15',
Pressure: '47',
starttime: '2015-03-01T01:11:26.000' } ]
But I want something like
[ { Temperature: 78,
Humidity: 53,
Wind_Speed: 51,
Pressure: 42,
starttime: '2015-03-01T00:06:38.000' },
{ Temperature: 57,
Humidity: 70,
Wind_Speed: 14,
Pressure: 36,
starttime: '2015-03-01T00:25:28.000' },
{ Temperature: 66,
Humidity: 60,
Wind_Speed: 15,
Pressure: 47,
starttime: '2015-03-01T01:11:26.000' } ]
I tried my options but nothing seems to help. Also, I do not have any control to change my input csv files.
Any help in this matter will greatly help.
Thanks

Have you tried checkType:true parameter?
~Keyang
On 24 May 2017 at 12:01, rimita<EMAIL_ADDRESS>wrote:

Hi,
My CSV files are having a lot to numeric data. But in the resultant json,
all the numeric data is converted to string.
Example,
My CSV file
Temperature,Humidity,Wind_Speed,Pressure,starttime
78,53,51,42,2015-03-01T00:06:38.000 57,70,14,36,2015-03-01T00:25:28.000
66,60,15,47,2015-03-01T01:11:26.000
Result JSON
[ { Temperature: '78', Humidity: '53', Wind_Speed: '51', Pressure: '42',
starttime: '2015-03-01T00:06:38.000' }, { Temperature: '57', Humidity:
'70', Wind_Speed: '14', Pressure: '36', starttime:
'2015-03-01T00:25:28.000' }, { Temperature: '66', Humidity: '60',
Wind_Speed: '15', Pressure: '47', starttime: '2015-03-01T01:11:26.000' } ]
But I want something like
[ { Temperature: 78, Humidity: 53, Wind_Speed: 51, Pressure: 42,
starttime: '2015-03-01T00:06:38.000' }, { Temperature: 57, Humidity: 70,
Wind_Speed: 14, Pressure: 36, starttime: '2015-03-01T00:25:28.000' }, {
Temperature: 66, Humidity: 60, Wind_Speed: 15, Pressure: 47, starttime:
'2015-03-01T01:11:26.000' } ]
I tried my options but nothing seems to help. Also, I do not have any
control to change my input csv files.
Any help in this matter will greatly help.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Keyang/node-csvtojson/issues/171, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCs96qPP13t4sk-OvlPrchqfaMHb3fXks5r9A3xgaJpZM4Nk8W1
.

Close due to no activity


Side-by-Side not working on new build

Just installed the new build 3143 and Side-by-Side is not working correctly

It seems to work for me just fine in 3144. Have you tried that build?

I also just tried in 3143 (on a separate system), and things also seem to work. I'm going to close this for now; if you continue having issues, feel free to reopen with the following information:

Operating system
Any errors or warnings you see in the Sublime Text console
Any other error messages you are encountering


Rename 'args' in lambda structs to 'params'

args should be used for application/calls and params for lambdas/functions.

Codecov Report

Merging #70 (5640340) into main (73458ed) will not change coverage.
The diff coverage is 86.66%.

@@           Coverage Diff           @@
##             main      #70   +/-   ##
=======================================
  Coverage   89.33%   89.33%
=======================================
  Files          20       20
  Lines        1753     1753
=======================================
  Hits         1566     1566
  Misses        187      187

Impacted Files
Coverage Δ

src/ast/expr.rs
61.53% <ø> (ø)

src/codegen/js.rs
90.86% <ø> (ø)

src/infer/constraint_solver.rs
87.73% <50.00%> (ø)

src/types.rs
67.59% <50.00%> (ø)

src/codegen/d_ts.rs
84.56% <100.00%> (ø)

src/infer/context.rs
96.36% <100.00%> (ø)

src/infer/infer.rs
95.20% <100.00%> (ø)

src/infer/substitutable.rs
77.14% <100.00%> (ø)

src/parser/decl.rs
100.00% <100.00%> (ø)

src/parser/expr.rs
99.31% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

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


Non-breaking space characters passed via props are double-escaped in component template output

Version
2.5.2
Reproduction link
https://jsfiddle.net/srobertson203/98Lp2ch0/
Steps to reproduce

Create a new component that accepts a string prop.
Use the handlebar syntax to display the prop within the component's template.
Use the component in a Vue application and pass a string containing a non-breaking space character for the prop.

What is expected?
The non-breaking space character should be escaped as an HTML entity in the raw HTML, but appear as a normal space in the rendered HTML.
What is actually happening?
The non-breaking space character is double-escaped as an HTML entity and instead appears as   in the rendered HTML.

As shown in the jsfiddle, all other characters that should be escaped as HTML entities (such as & and < or >)are behaving as expected. It's only the non-breaking space character that's double-escaped.

The browser is escaping it before passing it as an attribute. Add console.log(document.querySelector('#app > *')) before new Vue to see it
That's why it looks like it's escaped twice 😅

I've made 3 cases in the jsfiddle below - that might help explain the problem.

First case is that   get turned into
Second case is that in a long list of UTF-8 characters only NON-BREAKING SPACE is the one to be escaped.
And third when getting the same list of characters, but retrieving it from a regular HTMLElement with document.querySelector('#test').title the character aren't escape.

https://jsfiddle.net/98Lp2ch0/16/

for folks that are looking for a workaround for this:
When passing a string with non-breaking spaces as a prop, I just replaced the spaces with characters unlikely to be part of the string, in my case 'zzz'
var newName = program_name.replace(/\s/g,'zzz');
Then, in the actual component where I need to display or use this prop, I have a computed function that undoes the above action and replaces the placeholder chars with spaces again
correctedProgramName(){ //this reverses the space-replacing we had to do in reporting-dashboard.js
        let correctedProgramName = this.program_name.replace(/zzz/g, ' ')
        return correctedProgramName
      }

I see this closed, but I do not see the reason why since a fix is not provided.

PR https://github.com/vuejs/vue/pull/11599 will fix this issue:
Fixed Reproduction link: https://jsfiddle.net/juniortour/q2dxc65h/
After:

Before:

Thanks, Junior, it looks like it is not being reviewed by anyone yet :(

The browser is escaping it before passing it as an attribute. Add console.log(document.querySelector('#app > *')) before new Vue to see it
That's why it looks like it's escaped twice 😅

Hey @posva I see you closed this one, but the PR with the fix is not approved, is there a procedure to get it approved? Thanks.


Azure DevOps Pipeline fails to download tasks after using latest vmImage: windows-2019 released on 20240825.1.0

Description
Described it in detail in this Stackoverflow question:
https://stackoverflow.com/questions/78923577/azure-devops-pipeline-fails-to-download-tasks-after-using-latest-vmimage-windo
Platforms affected

[X] Azure DevOps
[ ] GitHub Actions - Standard Runners
[ ] GitHub Actions - Larger Runners

Runner images affected

[ ] Ubuntu 20.04
[ ] Ubuntu 22.04
[ ] Ubuntu 24.04
[ ] macOS 12
[ ] macOS 13
[ ] macOS 13 Arm64
[ ] macOS 14
[ ] macOS 14 Arm64
[X] Windows Server 2019
[ ] Windows Server 2022

Image version and build link
20240825.1.0
Is it regression?
20240818.1.0
Expected behavior
Install tasks correctly
Actual behavior
Fails to install tasks with generic ##[error]Object reference not set to an instance of an object. error
Repro steps
Run pipeline with windows-2019 latest vmImage with the following extensions in the yml:
Downloading task: PowerShell (2.242.1)
Downloading task: CmdLine (2.244.3)
Downloading task: InstallSSHKey (0.238.1)
Downloading task: Cache (2.198.0)
Downloading task: NuGetToolInstaller (1.238.1)
Downloading task: NuGetCommand (2.244.1)
Downloading task: Bash (3.244.1)
Downloading task: VSBuild (1.231.0)
Downloading task: ArchiveFiles (2.244.1)
Downloading task: PublishPipelineArtifact (1.242.0)

I am almost sure this is a duplicate of https://github.com/microsoft/azure-pipelines-tasks/issues/20356
It is not an image regression but rather regression in the AzureDevOps agent. It should be fixed by now.

Hi @robertoandrade - I hope your issue is fixed by now as it is related to AzureDevops agent, this issue is not related to runner images.
Thanks:)


Management Console Process List should show Business Key as a column

Description
The business key is searchable and it is a required field in the launching of a process instance (as per swagger ui), but when in the mgmt console, you cannot see the ID:

Implementation ideas
Add business key as a column to the process list

Hi Stephen, the current design incorporates the business key as a part of the id(the first column). It is seen as a blue-colored label adjacent to the process name. To view the id of the process instance,  you can hover over the process name(id column) and it appears as a pop-up. In any case, I will take it up with the team and have a discussion if we can move it as a separate column.
Thanks.

In many cases a business key is a incrementing value. Having it in the column would give the ability to sort?

yes if we move it to a column we can sort the table using business keys

@pefernan @paulovmr is this still a valid issue?


⚠ GitHub has degraded performance

In c7a546b, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 138 ms

Resolved: GitHub performance has improved in 7b94757.


Error in gtest lib directory

When linking roc-cl-unittest, ld raises the error
ld: cannot find -lgtest
ld: cannot find -lgtest_main

despite the fact that the googletest library has just compiled and should be linked against. This seems to be due to an error in src/unittest/CMakeLists.txt. If I change line 66 from
link_directories(${binary_dir}/googletest)

to
link_directories(${binary_dir}/lib)

then it seems to link fine.

It looks like ExternalProject_Get_Property(googletest binary_dir) gets a correct folder for binary_dir - googletest-build, but the libs to link are in a subfolder lib, not in a subfolder googletest. So your fix looks correct.
Please create a pull request with your fix. Thanks.


Adopt TransformDialectExtension

This revision adds support for dynamic registration of ops into the transform dialect (see https://reviews.llvm.org/D123135 for more context).
With this support we can now avoid artificial boundaries and don't need to duplicate ops to allow defining new transform dialect ops.
This PR also performs a minimal port of one such op out of iree-dialects and into iree/compiler/Codegen/TransformDialectExtensions.
For registration, we piggy-back on Interfaces.cpp::registerCodegenInterfaces for now. This layering should be improved in the future.

Ill look in detail later, but please dont include an LLVM bump as part of a PR. If this requires a specific commit from core, either cherry pick it into iree-llvm-fork or wait for IREE to catch up to the point you need.

This is an artifact of how github shows PRs and the lack of stacked commits.
The LLVM bump is already isolated in #8779

@benvanik I'd love some suggestions on the layering of the transform registrations.
Atm I am piggy-backing on interfaces but it creates weird dependencies.

Is there a reason to move this into iree/compiler/....
Loosely iree/compiler/... is what IREE core team is on the hook for maintaining functional correctness. Moving this into iree compiler core is effectively moving this out of "experimental" state which requires some use case. I am not clear what that is yet....

I am confused .. didn't we specifically make room in iree/compiler/... under a flag to allow bringing up the transform dialect in IREE ? Didn't we also add temporary copies of HAL operations in LinalgExt + iree/compiler/Codegen/Common/SetNumWorkgroupsFromLinalgExtPass.cpp that we should retire when it was possible to register transform dialect ops dynamically outside of the transform dialect?
This PR is the first step of the cleanup, the followup PR drops the HAL operations from LinalgExt as we had discussed and moves the corresponding transform in IREE.
To properly use the transform dialect and Linalg in general I expect 2 immediate patterns to be useful in IREE because they depend on IREE code:

Tile -> InParallel which is a nice abstraction to represent tiling+parallelism+distribution+tensors in Linalg. This is needed as a pattern somewhere that can link with IREE code because of the HAL materialization of distribution.
Bufferization which requires IREE specific-code and also needs to be registered from a place that can link with IREE code.

Now none of this has to live in iree/compiler/... specifically but it needs to:

be able to link with IREE
be able to register ops in the transform dialect at startup time

Please advise where you'd prefer this to live and the layering.
As for use case: this brings the results of https://arxiv.org/abs/2202.03293 without having to hack copies of the experimental retired sandbox CodegenStrategy C++ code, so consider it a replacement for those old abstractions.

I layered this in a more isolated fashion in iree/compiler/Codegen/TransformDialectExtensions, this can move further if necessary but the essential visibility requirements can't change atm.
One solution to fully isolate this form IREE would be for IREE to have a BYOC type of model and itself expose dynamic registrations.
This is much more involved obviously than just adding a flag like we've been doing so far.

Is there a reason to move this into iree/compiler/....
Loosely iree/compiler/... is what IREE core team is on the hook for maintaining functional correctness. Moving this into iree compiler core is effectively moving this out of "experimental" state which requires some use case. I am not clear what that is yet....

I am confused .. didn't we specifically make room in iree/compiler/... under a flag to allow bringing up the transform dialect in IREE ? Didn't we also add temporary copies of HAL operations in LinalgExt + iree/compiler/Codegen/Common/SetNumWorkgroupsFromLinalgExtPass.cpp that we should retire when it was possible to register transform dialect ops dynamically outside of the transform dialect? This PR is the first step of the cleanup, the followup PR drops the HAL operations from LinalgExt as we had discussed and moves the corresponding transform in IREE.
To properly use the transform dialect and Linalg in general I expect 2 immediate patterns to be useful in IREE because they depend on IREE code:

Tile -> InParallel which is a nice abstraction to represent tiling+parallelism+distribution+tensors in Linalg. This is needed as a pattern somewhere that can link with IREE code because of the HAL materialization of distribution.
Bufferization which requires IREE specific-code and also needs to be registered from a place that can link with IREE code.

I am trying to get an idea of what the goals are here. This is what I had in mind. The immediate goal for using the transform dialect were

Replace existing use of the Codegen Driver in CPU backend with using the transform dialect approach. The initial work of this I assumed was meant to target single threaded computation (this is how I initially setup the pipeline for use with the Transform dialect). For the single threaded case, I think you wouldnt require anything from HAL to lower to LLVM, and would allow you to verify things are working as expected. There is some amount of "feature parity" needed with what is done currently with CodegenDriver, and then we can start rolling that into the main IREE compiler stack. So the initial setup of pipeline to insert passes from iree-dialects guarded by a flag was meant to enable this evaluation without having this built in iree/compiler/...
I assumed the TileOp abstraction is something needed to verify multi-threaded performance. I think moving over IREEs codegen to use TileOp is fairly disruptive. In terms of ordering, it would be better to make this transition (if needed) later on based on a better understanding of what the trade-offs are. So having the TileOp connected to the HAL "parallelism abstraction" as it is today (duplicate ops in iree-dialects that get converted to the actual ops in IREE) I thought connects things enough to allow for evaluating multi-threaded performance with transformation dialect (again without having to build out this code in iree/compiler/...). Then we can evaluate if we actually need to use the TileOp to realize that performance. AFAICS the final code generated with TileOp and what is done currently in IREE should be similar. If that is not the case it would be good to get an idea of why there is a mismatch. That will give us a better place to decide which path to take.

So with either of these, my understanding is that the silo carved out for using the transformation dialect within iree-dialects should not need to move any code into iree/compiler/... to evaluate that things connect and work e2e. Also, iree-dialects was meant as a place to stage things before they can move upstream. So just "simulating" by keeping things in iree-dialects vs within iree/compiler/... is useful IMO. IIUC the registration you have here is just to avoid the duplicate ops in iree-dialects for the HAL ops needed to connect things. I dont think those duplicate ops are that much of a problem for a time being.

Now none of this has to live in iree/compiler/... specifically but it needs to:

be able to link with IREE
be able to register ops in the transform dialect at startup time

Please advise where you'd prefer this to live and the layering.
As for use case: this brings the results of arxiv.org/abs/2202.03293 without having to hack copies of the experimental retired sandbox CodegenStrategy C++ code, so consider it a replacement for those old abstractions.

FTR, the use of CodegenStrategy (by copying code from sandbox) was explicit recommendation made to us to use the upstream vectorization related work in a way that connects "correctly". It took us a while to move everything over to use the CodegenStrategy. There are a lot of things IREE needs to "support" and is non-trivial amount of work to make the transition happen (took two of us 2-3 months to make this happen, but it did also involve some changes to IREE itself that was needed to connect everything). So moving to transform dialect is also going to be non-trivial amount of work, and needs to be moved in a more gradual fashion. Keeping the code in iree-dialects and moving things needed more deliberately into iree/compiler/... based on a good understanding of what it is used for by people in IREE (me, Hanhan and Diego, for example and prioritized appropriately w.r.t other things on peoples plate), is a way to manage that switch. It would be too disruptive to do a binary switch.
As Stella mentioned, if there is a disconnect between the work plan and progression that I have in my mind, vs. what you were planning, this needs to be hashed out before landing code?

Thanks Mahesh - given all of the moving parts, it does seem like this raises to design-doc territory. I think there is a lot more work hiding here than may be visible, and that increases the need to have a documented path forward. That will also increase our ability to fan it out to additional people as needed too.

I still do not understand the concern: there has never been a question of a binary switch on anything.
Still there seems to be issues with the mere existence of one op related to parallelism + tensors so I will reorder things and keep my work on parallelism in a private branch.


[help wanted] or [doc request] How to run a container successfully from the begining?

Issue Description
Being Interested in this project, but many important docs are absent, maybe it's in progress.
What I want  is an operation guide. For example, I failed to pull images with pouch cli, but I don't know the reason and how to deal with it:
root@pouch:~# pouch pull hub.c.163.com/public/nginx
hub.c.163.com/public/nginx:latest: resolving      |--------------------------------------|
elapsed: 0.0 s                     total:   0.0 B (0.0 B/s)
failed to decode: expected comma after array element

Log:
^[[34mINFO^[[0m[2017-11-23 16:56:22.239031803] Calling POST /images/create?fromImage=hub.c.163.com%2Fpublic%2Fnginx&tag=1.2.1, client @
^[[33mWARN^[[0m[2017-11-23 16:56:22.677394554] reference for unknown type: application/json; charset=utf-8  ^[[33mdigest^[[0m=sha256:ef9bd0fa2c97429562ecc209772ef07ebb9dfd66dc310ea02739d1f026dbf7b8 ^[[33mmediatype^[[0m="application/json; charset=utf-8" ^[[33msize^[[0m=16914
^[[33mWARN^[[0m[2017-11-23 16:56:22.740036552] reference for unknown type: application/json; charset=utf-8
^[[33mWARN^[[0m[2017-11-23 16:56:22.840122439] reference for unknown type: application/json; charset=utf-8
^[[31mERRO^[[0m[2017-11-23 16:56:22.885262391] failed to pull image hub.c.163.com/public/nginx:1.2.1: failed to pull image: could not fetch content descriptor sha256:ef9bd0fa2c97429562ecc209772ef07ebb9dfd66dc310ea02739d1f026dbf7b8 (application/json; charset=utf-8) from remote: not found
2017/11/23 16:56:22 http: multiple response.WriteHeader calls
^[[31mERRO^[[0m[2017-11-23 16:56:22.885360467] invoke /images/create?fromImage=hub.c.163.com%2Fpublic%2Fnginx&tag=1.2.1 error failed to pull image: could not fetch content descriptor sha256:ef9bd0fa2c97429562ecc209772ef07ebb9dfd66dc310ea02739d1f026dbf7b8 (application/json; charset=utf-8) from remote: not found. client @
^[[34mINFO^[[0m[2017-11-23 16:56:22.885379420] End of Calling POST /images/create, costs 646 ms. client @
^[[33mWARN^[[0m[2017-11-23 16:56:22.939421369] reference for unknown type: application/json; charset=utf-8
^[[34mINFO^[[0m[2017-11-23 16:56:22.939496507] fetch progress exited, ref: hub.c.163.com/public/nginx:1.2.1.
^[[31mERRO^[[0m[2017-11-23 16:56:22.939578421] failed to write object: http: wrote more than the declared Content-Length

Is it compatible with docker registry?

duplicate #123  close it.

It seems don't support pull images from other registry

root@pouch:~# pouch images
IMAGE ID             IMAGE NAME                                               SIZE
f1ca87d9adb6         docker.io/library/nginx:alpine                           434

root@pouch:~# pouch create f1ca87d9adb6
container's id: ffb9da7559fe80f0052e034e11686d101d6ea5d78721b9ee73a62115a6242274, name: ffb9da

root@pouch:~# pouch start ffb9da -i
failed to start container ffb9da: Image not found

User Guide is necessary.

@shenlanse Thanks a lot for your feedback. This issue is really important.
And fixing this issue in our scope. We plan fix this before this weekend.
And we will let you know if we have any progress. If fixed, we sincerely invite you to test and have this feature.

After thinking for a while, I think it is necessary for all pouch members to know this staff. Promote this issue to priority/P0.

Please try: pouch create docker.io/library/nginx:alpine ,  Now the Image ID is not supported. @shenlanse

@skoo87 @allencloud  Works fine. Thanks.

Maybe there is a bug when I stop the container.
It shows that I failed to stop container,  but the container has been stopped successfully.
[root@node1 ***]# pouch ps
Name     ID       Status    Image
883b1e   883b1e   Running   docker.io/library/nginx:alpine
[root@node1 ***]# pouch stop 883b1e
failed to stop container 883b1e: failed to destroy container: 883b1ecc65403e4d77da92d6f5fb94acf0f9fecfb088ab6275e1e0e5e16f2253: time out
[root@node1 ***]# pouch ps
Name     ID       Status    Image
883b1e   883b1e   Stopped   docker.io/library/nginx:alpine

Thanks for your report, I will try to reproduce the problem and fix it. @ZeroMagic


Release notes for march 2022

2022.03 🔨 - New notes for a new month

Nice! What do you think about adding changes in the examples and tutorials repos to the release notes as well? I think @tong has made some updates there :)

@MoritzBrueckner Good idea! I added that just now

Super cool!


Prevent calendar days from shifting and from going to next / previous month when VoiceOver is enabled

When VoiceOver is enabled and I swipe from Friday to Saturday or from Sunday to Saturday, the calendar days shift (or scrolls). In this same use case, after swiping past the end of the month, the calendar partially shifts to the next month.
So far, the affected devices and OS':

iPhone 5 / iOS 9.3.5
iPhone 6+ / iOS 10.1+
iPad Pro / iOS 10.1+

Oddly, I was not able to reproduce on an iPhone 6 / iOS 10.1+.
Is there any way to prevent this shifting / scrolling or can you at least point in me in the right direction in the Objective-C FSCalendar code as to where this needs to be fixed? In my calendar, when VoiceOver is enabled, I am using previous and next month buttons to navigate to the previous/next month and want to prevent day swiping to switch to next/previous month (Result 2 below).
The following reproduction steps assume Xcode 8.x...

Download, the latest SwiftExample project/app (as of 11/28/2016).
In LoadViewExampleViewController:loadView after the calendar instance has been created, add the following lines:

calendar.scope = .month
calendar.scrollDirection = .vertical
calendar.scrollEnabled = false

On one of the affected devices, enable VoiceOver by going to: Settings > General > Accessibility > VoiceOver (toggle on)
Build and run the sample app on one of the affected devices.
Tap LoadView.
Tap on a Friday and swipe right to Saturday or tap on a Sunday and swipe left to Saturday.

Result 1:
Notice the shifting down of the header and days.

Now tap the day before the last day of the month.
Begin swiping right.

Result 2:
As you approach the beginning of the next month, notice the shifting towards the next month. If you continue to swipe right, the calendar will continue to advance.
Click here to view a video demonstrating the issues above.

So it appears that this is related to the itemSize calculation in FSCalendarFlowLayout.m in the if (!self.calendar.floatingMode) block:
self.collectionView.fs_width/7.0-(self.scrollDirection == UICollectionViewScrollDirectionVertical)*0.1
@WenchaoD: Would you explain this calculation.  I imagine 7.0 represents the number of days in a week, but I am not clear about: -(self.scrollDirection == UICollectionViewScrollDirectionVertical)*0.1.
If I change 7.0 to a higher value like 7.5, the shifting no longer occurs on swipe to Saturday (at least on the iPad - need to test on other devices.) This isn't the perfect solution in my calendar's case because I have implemented a bottom cell divider that appears as a single line - the calculation change above adds a space between each cell now.


implement stack instead of fully random

As a card deck, shuffle stack of entries and pick from stack until empty, refill and repeat.

keycap image should not just be one of many images; it should be first "card" in "stack", other images (if any) will be randomized

implemented different approach for now, commit 103a3114bab1f36aa5aeb0c241b55e1131d96ef3

fixed in b72a08b


getting Key error 0

Hi @PriyabrataThatoi 👍
Can you please share a Colab notebook or GitHub notebook where I can test this and find out where the key error is coming from? If you cannot, then please provide some more input on what the data is (link) and what settings you used?
Thanks
Auto-TS

Hi @PriyabrataThatoi 👍
I noticed that you have entered 'catboost' as the input argument for category_encoders field. However, the correct input is 'CatBoostEncoder'. Can you please check your inputs and try again.
Here is the documentation for inputs to featurewiz:
https://github.com/AutoViML/featurewiz#api
Thanks,
Auto-TS

I tried that, now it is showing a different error:
Dataframe.iloc only supports selecting columns. It must be used like
‘df.iloc[:,column_indexer]
On Wed, Dec 8, 2021 at 8:19 AM AutoViz and Auto_ViML <
@.***> wrote:

Hi @PriyabrataThatoi https://github.com/PriyabrataThatoi 👍
I noticed that you have entered 'catboost' as the input argument for
category_encoders field. However, the correct input is 'CatBoostEncoder'.
Can you please check your inputs and try again.
Here is the documentation for inputs to featurewiz:
https://github.com/AutoViML/featurewiz#api
Thanks,
Auto-TS
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AutoViML/featurewiz/issues/8#issuecomment-988854819,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7RX3YPBUYITLOC4M7RSE3UP5SP7ANCNFSM5JME6NXA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

--
Regards
Priyabrata Thatoi
Contact: +1(405) 762-6874

Hi @PriyabrataThatoi 👍
I hope all these problems have been fixed with the latest release. Just update featurewiz using:
pip install featurewiz --no-deps --ignore-installed
This will force featurewiz to be upgraded.
Hope this helps
AutoViML


DeviceInfo Import error

Unable to prepare setup for platform eyeonwater.sensor: Platform not found (cannot import name 'DeviceInfo' from 'homeassistant.helpers.device_registry' (/usr/src/homeassistant/homeassistant/helpers/device_registry.py)).
Getting a strange error when importing DeviceInfo from its proper place as described in the CLI.
Temporary Solution
I am reverting back to importing it from another library until this issue is resolved or further understood.
Old:    from homeassistant.helpers.entity import DeviceInfo
Proper:     from homeassistant.helpers.device_registry import DeviceInfo

@disforw I started to work on adding unit tests for the integration (following the HA requirements). And it's going to take some time.
Will take a look at this one after finishing with unit tests

Posting documentation on the change:
https://github.com/home-assistant/core/pull/95641


Error processing Pyrogram account: 'NoneType' object has no attribute 'run'

MCF_PocketFi

ive got a similar error with blum
[MasterCryptoFarmBot] [10:13:58] [MCF_Blum] [INFO] 🟡 Renewing access token...
[MasterCryptoFarmBot] [10:14:17] [MCF_Blum] [INFO] 🟡  Unable to send request, retrying...
[MasterCryptoFarmBot] [10:14:45] [MCF_Blum] [ERROR] ⭕ xxx failed to get balance!
[MasterCryptoFarmBot] [10:15:00] [MCF_Blum] [ERROR] ⭕ xxx failed to get balance!
[MasterCryptoFarmBot] [10:15:19] [MCF_Blum] [ERROR] ⭕ 'NoneType' object has no attribute 'get' failed to login!
[MasterCryptoFarmBot] [10:15:19] [MCF_Blum] [ERROR] ⭕ xxx failed to login!

ive got a similar error with blum
[MasterCryptoFarmBot] [10:13:58] [MCF_Blum] [INFO] 🟡 Renewing access token...
[MasterCryptoFarmBot] [10:14:17] [MCF_Blum] [INFO] 🟡  Unable to send request, retrying...
[MasterCryptoFarmBot] [10:14:45] [MCF_Blum] [ERROR] ⭕ xxx failed to get balance!
[MasterCryptoFarmBot] [10:15:00] [MCF_Blum] [ERROR] ⭕ xxx failed to get balance!
[MasterCryptoFarmBot] [10:15:19] [MCF_Blum] [ERROR] ⭕ 'NoneType' object has no attribute 'get' failed to login!
[MasterCryptoFarmBot] [10:15:19] [MCF_Blum] [ERROR] ⭕ xxx failed to login!

That's not similar. and that's totally clear xxx failed to get balance Check your connections and create an issue for Blum not everywhere.

MCF_PocketFi

Can you send a full line of the error?


Can't seem to add this package into project

Hello, i got the following message when i was trying to add this package to my project:
`flutter pub add flutter_awesome_select
Resolving dependencies...
async 2.5.0 (2.8.2 available)
characters 1.1.0 (1.2.0 available)
charcode 1.2.0 (1.3.1 available)

flutter_awesome_select 6.0.1
horizontal_data_table 3.5.0 (3.6.0 available)
http 0.13.3 (0.13.4 available)
js 0.6.3 (0.6.4 available)
matcher 0.12.10 (0.12.11 available)
meta 1.3.0 (1.7.0 available)
path 1.8.0 (1.8.1 available)
path_provider 2.0.4 (2.0.8 available)
path_provider_linux 2.1.2 (2.1.5 available)
path_provider_macos 2.0.3 (2.0.5 available)
path_provider_platform_interface 2.0.1 (2.0.3 available)
path_provider_windows 2.0.4 (2.0.5 available)
pedantic 1.11.1 (discontinued replaced by lints)
platform 3.0.2 (3.1.0 available)
plugin_platform_interface 2.0.2 (2.1.2 available)
process 4.2.3 (4.2.4 available)
provider 6.0.1 (6.0.2 available)
shared_preferences 2.0.7 (2.0.12 available)
shared_preferences_linux 2.0.3 (2.0.4 available)
shared_preferences_web 2.0.2 (2.0.3 available)
shared_preferences_windows 2.0.3 (2.0.4 available)
source_span 1.8.0 (1.8.1 available)
sqflite 2.0.0+4 (2.0.1 available)
sqflite_common 2.0.1+1 (2.2.0 available)
syncfusion_flutter_core 19.3.55 (19.4.42 available)
syncfusion_flutter_datepicker 19.3.55 (19.4.42 available)
test_api 0.2.19 (0.4.9 available)
vector_math 2.1.0 (2.1.1 available)
win32 2.0.5 (2.3.3 available)
Downloading flutter_awesome_select 6.0.1...
Could not decompress gz stream Connection closed while receiving data, path = ''
pub finished with exit code 66`

Flutter Doctor:
`flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 2.0.3, on Microsoft Windows [Version 10.0.19042.1415], locale en-MY)
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[√] Chrome - develop for the web
[√] Android Studio (version 4.1.0)
[√] IntelliJ IDEA Community Edition (version 2018.3)
[√] Connected device (3 available)
• No issues found!`
Anyone knows what seems to be the problem here?

@RayBrimstone try 6.1.1-beta
I released the package with pub publish so I do not know what causes the issue on your side

Hello i tried again today and it's working. Thank you for the help @vasilich6107


Installation

I have been trying to install msmexplorer-d3 and I run into the error
File "app.py", line 87
print "if youre developing locally, you need to get the MONGOLAB_URI"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(print "if youre developing locally, you need to get the MONGOLAB_URI")?
when trying to run python app.py
I am not familiar with MONGOLAB or with heroku and I feel like the problem is within these two dependencies.
Any help would be appreciated.
Cheers,
Dylan

Well, this particular error is due to two things: 1) using Python 3 to run a Python 2.7 app (see conda-requirements.txt for a full list of dependencies) and 2) it seems that MONGOLAB_URI has be changed to MONGODB_URI. You can find more information about this in the Heroku docs.
It seems that the demo is also affected by these changes. In all honesty, I have not been maintaining this package since starting msmbuilder/msmexplorer, so I'm not 100% sure how much work it might take to get this working on Heroku again.


Ability to delete picture on quiz

Currently students can only upload a picture for quiz image questions, but not remove it if they don't like it

Also make the ability to delete files.
Apparently uploading again only works after refreshing -- which means something breaks after the first upload! Fix that!

I forgot to close this issue. I've fixed delete for both quizzes and labs


Add and configure Rubocop

Please add and configure the Rubocop gem, with a reasonable config file. Don't make it so strict, but consider a good styleguide to follow.
Fix the offenses and ship it.

It's merged now. We are able to fix now the more complex codes in code, where rubocop get disabled for some methods.
Thanks @ViniciusAlmeidaSilva


Parameters to tune cancel-out unit

Hi Thomas,
I tried to add the parameters to tune the cancel-out window to the event setup. Let me know if you feel it should be done differently, I tried compiling and running it on an EDM file I had still available. (Unfortunately my cancel-out samples became unavailable sometime in the past two weeks, so I couldn't test it on those immediately.)
What's still missing is the eta fine bit -- for the moment this hasn't been making much difference in my studies, but I hear something was fixed in the BMTF emulator regarding that, so I'll implement it next.
Cheers,
Dinyar

Hi Dinyar,
thanks for putting this in. Unfortunately, there has been a major change to the conditions format after l1t-tsg-v4. Most of the functionality has been moved to a helper class in order not to touch the CondFormats package (The conditions people are very sensitive to changes there).
For most of the files that changed this has no effect but notably the setters and getters in CondFormats/L1TObjects/interface/L1TMuonGlobalParams.h have been moved to a helper class.
The producers then create a helper object instead of the condFormats object.
The helper class:
https://github.com/cms-l1t-offline/cmssw/blob/l1t-integration-CMSSW_8_0_2/L1Trigger/L1TMuon/interface/L1TMuonGlobalParamsHelper.h
Cheers,
Thomas

closing this since it has been taken care of already in PR https://github.com/thomreis/cmssw/pull/26


Fix typos

Found via codespell -H -L wit,thre

Thanks!

!stable-docs

:partying_face: :partying_face: :partying_face: :partying_face: :partying_face:


progress with Alex

Didn't see a way to leave comments on each individual file, so I'm leaving them in this format:

for the change on frontend/.env, this was done so that the app worked locally on my machine as I had previously been receiving a noapi error
frontend/src/ui/LandingBlurb/LandingBlurb.stories.tsx: this change was done in order to make landing blurb it's own folder directory because the landingblurb component within it needed to have a container so that we could change it's behavior upon selection of the occupation.
frontend/src/ui/LandingBlurb/LandingBlurb.tsx: this change was made so that the landingblurb could be clicked to expand the title text (to keep the original behavior of being able to expand and collapse that blurb).
frontend/src/ui/LandingBlurb/LandingBlurbContainer.tsx: this was the meat of the PR, the useEffect function in there was what was being used to change the behavior of the landingblurb container once the user had selected the occupation

As far as testing the changes, when I tried running npm start I got an error saying that LandingBlurbContainer didn't exist in the file structure of  import { LandingBlurbContainer } from '../LandingBlurb', even though I definitely saw a LandingBlurbContainer.tsx file in that folder

awesome. Thanks a bunch!
On Fri, Feb 19, 2021 at 1:47 PM Allan Zheng<EMAIL_ADDRESS>wrote:

Didn't see a way to leave comments on each individual file, so I'm leaving
them in this format:

for the change on frontend/.env, this was done so that the app
worked locally on my machine as I had previously been receiving a noapi
error
frontend/src/ui/LandingBlurb/LandingBlurb.stories.tsx: this change
was done in order to make landing blurb it's own folder directory because
the landingblurb component within it needed to have a container so that we
could change it's behavior upon selection of the occupation.
frontend/src/ui/LandingBlurb/LandingBlurb.tsx: this change was made
so that the landingblurb could be clicked to expand the title text (to keep
the original behavior of being able to expand and collapse that blurb).
frontend/src/ui/LandingBlurb/LandingBlurbContainer.tsx: this was
the meat of the PR, the useEffect function in there was what was being used
to change the behavior of the landingblurb container once the user had
selected the occupation

As far as testing the changes, when I tried running npm start I got an
error saying that LandingBlurbContainer didn't exist in the file structure
of import { LandingBlurbContainer } from '../LandingBlurb', even though I
definitely saw a LandingBlurbContainer.tsx file in that folder
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/codeforboston/jobhopper/pull/309#issuecomment-782268349,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMD2CR7QDHMEJZCWMBHWFLS72W3LANCNFSM4X2TA4ZQ
.


feature: qemu encryption support

What this PR does / why we need it:
feature: qemu encryption support

Does this PR need to be backport to the previous release branch?:

release/3.9

/cc @zexi
/area keystone glance region
/hold

/hold cancel


view! macro with the with! macro leads to weird formatting

Hello,
thanks for this great project!
I've noticed some inconsistent behavior with some code like this:
    #[test]
    fn with_with_macro() {
        let formatted = view_macro!(view! { {move||with!(|scope| view!{
"hi"
 })}});
        insta::assert_snapshot!(formatted, @r#"
        view! {
            {move || with!(|scope| view! {

                    "hi"

            })
            }}
        }
        "#);
    }

I might expect this to be formatting something like in the test... However this is formatted like:
view! { {move || with!(| scope | view! {
 "hi"
 })} }

It just adds spaces everywhere in the statement which actually makes the code quite unreadable for more complex examples.
This is the simplest case I found.

Hi,
Rust macros can take arbitrary streams of tokens. It does not have to be valid rust syntax, therefore this formatter cannot know how the contents of a macro need to be formatted.

Is there a way to make leptosfmt to treat certain macros, such as those provided by leptos as valid?
Happy to take a stab at providing a PR!

could you tell me more about your use case, what does with! do?

https://github.com/leptos-rs/leptos/releases/tag/v0.5.0-rc1
From the leptos release notes:
with!() and update!() macros
Nested .withI() calls are a pain. Now you can do
let (first, _) = create_signal("Bob".to_string());
let (middle, _) = create_signal("J.".to_string());
let (last, _) = create_signal("Smith".to_string());
let name = move || with!(|first, middle, last| format!("{first} {middle} {last}"));

instead of
let name = move || {
	first.with(|first| {
		middle.with(|middle| last.with(|last| format!("{first} {middle} {last}")))
	})
};

They are a new macro leptos provides to simplify using multiple signals with the .with method.

Ah, I wasn't aware of with! with_value! and update! macros. I didn't know they were leptos specific.
Wouldn't it be more performant to do:
view! {
{with!(...)}

instead of
with!(|...| view! {
....
 }) as you would be recreating the dom element with every observed change?
Is it common to use call the view! macro inside these macros? If so, I could make leptosfmt aware of these as they are leptos specific.

It just adds spaces everywhere in the statement which actually makes the code quite unreadable for more complex examples.

I do agree that the default formatting behaviour of unknown macros is far from ideal. The least it should do is keep the original formatting intact.

Wouldn't it be more performant to do:

Probably, but not all code is optimized right away 🤷. The other approach is valid and functionally performant so it shouldn't be mangled at the least. As an interim, I have avoided using the with! macro which seems sufficient for now.
imo, without this tool, using leptos is really hard due to  rustfmt not being able to format view! macros.

I've noticed leptosfmt tends to mess up the contents of most other macros other than view!. Shouldn't it just leave code in other macros alone? It seems far too invasive at the moment.

I've noticed leptosfmt tends to mess up the contents of most other macros other than view!. Shouldn't it just leave code in other macros alone? It seems far too invasive at the moment.

Indeed, however this is the default behaviour of the prettyplease crate and didn't got around pushing an update yet.
See my previous comment in this issue:

I do agree that the default formatting behaviour of unknown macros is far from ideal. The least it should do is keep the original formatting intact.


style guide: Stop aligning parameters at = and/or $

I think the 'old' style of aligning parameter is quite bad and we should stop doing this.

Adding a new paramter should not cause a refactor. But I think we should enforce the new style for new parameters and ignore the existing style in a file. What do you think about that?

If we are changing this for a class/define variable list, are we planning to change this for a resource definition's => which has the same "feature."  I agree with the change, but I might agree less with the resource definition change (because the => alignment makes it easier to read)

Personally, I find it easier to read code when things are all vertically aligned. Also git diff does have a -w option to not show lines where the only change is whitespace, and some git web interfaces have a checkbox to do the same thing. (For me this is true of almost every language, not just Puppet/Ruby.)
As long as there's a way to tell the linter to accept the old format (or to ignore whitespace between tokens entirely), I have no objections.

There's a slight typo... "Sometimes were was an additional alignment". I believe this should be "Sometimes there was an additional alignment".

I would agree that the downside of having to refactor when adding a parameter is not good. However I am not so sure about the longterm readability.
For long parameter lists I think the old style makes it a lot easier to search for a specific one (when ordered alphanummerically).
On short parameter lists the old style is very cumbersome and makes them less readable.
I think currently we dont order alphanummerically first, instead we order by required parameters and optional parameters (I think)?
In that case the old one doesnt really add much value in my opinion, so we could drop it.

Just like other people here, my preference go to aligned types / names / default value because it is ways more comfortable for me to work with these lines when items are vertically aligned.
For sure, rebasing commits that change types can be a PITA, but only when we change the column where alignment take place.  When using a syntax that use tabs, it's easy to use say "2 tabs" in general and if a line overflow, just put a single space and not align this line; but because puppet files don't use tabs (and 2 spaces soft-tabs), when I have a little overflow I trend to "fix" it by re-aligning all members…  leading to these conflicts.  But I am ready to pay this rebase conflict risk when dealing with such changes :shrug:.
Having a rule that says that we should align fields is probably an annoyance.  Maybe we can just remove this line?  If people have to deal with aligned fields and it's annoying, they can remove the extra spacing and be happy.  If people have to deal with unaligned fields and it's annoying, they can add extra spacing and be happy.  I don't think that happen so often that we will have to deal with issues where a module go back and forth from a form to the other; and since people trend to contribute to some modules and not all, the module they contribute to the most are likely to use the alignment that fit them best in the end?

I would still bias to the alignment of = making it easier to read for me but I feel the frustration it creates when a new parameter knocks everything about.

I would still bias to the alignment of = making it easier to read

I understand that. But should the parameters be readable? That's the whole purpose of the REFERENCE.md. Provide the readable list of all parameters, their datatypes and the default values.

I find it easier to read if I have some space between things, for syntax and code for itself it is not required i know, but to get an overview and read and compare things I very much like this alignment. It is not nice to rebase, but I think it is worth the work to keep things aligned to better understand/read/view them.

My preference:

Ordering

First we have paramaters without defaults, odered alphabetical.
Next we have all parameters with defaults, ordered alphabetical.
If the module has more than one entry point (e.g. server and client) the parameters should be grouped and then ordered alphabetical.

Alignment

All parameter groups (see above) should align at $ and =

I do agree that alignment increases readability, but personally, I don't think it's worthwhile, given the documented annoyances for modification.
I stopped aligning parameter sections shortly after I started declaring the data types, since the lines were getting way too long.
The use of should indicates to me that this is a recommendation, not a requirement, so this doesn't seem like such a big deal either way.

Couldn't agree more with what @bugfood wrote. Data types made alignment impractical. For complex data types (or just long names) it breaks readability by making the lines so long that you can no longer easily see what the lines are. So you may mistake the data type from the line below with the default value from the line you're reading.

Also a fair point about custom data types, though if you introduce a custom data type and only use it once that's not a good experience for the module consumers. Perhaps a separate discussion.
I think @bugfood said it best: we have the word should. So that gives flexibility to who's making changes. What is important to me is that we're consistent. I guess there are 3 levels we can be consistent (and not at all):

organization (our entire GH namespace)
module
file
not at all

My suggestion is to keep it consistent at the file level. I love consistency, but I usually don't care beyond a single file.


cilium: encryption, replace Router() IP with CiliumInternal

Apparently I thought the RouterIP should be the same as the CiliumInternalIP
for a local Node. And this is usually the case, but it is not required. We
have had a couple reports of cases where encryption was not able to connect
because of this.
Fix by using the CiliumInternalIP in all cases.
Fixes: 05ea001368660 ("cilium: populate wildcard src->dst policy for ipsec")
Signed-off-by: John Fastabend<EMAIL_ADDRESS>

This change is

test-me-please

Coverage decreased (-0.002%) to 44.477% when pulling e80489f0bc8f5a914ac83943a730490c97bbd35d on vxlan-encrypt-fix into b969ec8c427becc8e3fe2166e825c932a2ab0a6a on master.


Browser tab crash

Hi
I'm using vuePDF to load dynamically 5 pdfs of many pages from an amazon s3 server and it works fine at first but it makes the browser tab completely crash at some point (Chrome).
My app is a nuxt 3 vue 3 app.
This bug didn't happen yet on Firefox tho
Do you have any incomming fix/info about that ? Thanks

Seems a memory problem.
Try using destroy function on pdfs that you don't need display anymore.
const { pdf } = usePDF(pdfSample)

function destroyPdf(){
  pdf.value?.destroy()
}

I updated the package and tried that but it still doesn't work

Plz provide a code sample and steps to reproduce it, I can't do much without it.


cargo-binstall: 1.2.0 -> 1.2.1

Diff: https://github.com/cargo-bins/cargo-binstall/compare/v1.2.0...v1.2.1
Changelog: https://github.com/cargo-bins/cargo-binstall/releases/tag/v1.2.1
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

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

1 package built:

cargo-binstall


Add toolbar

Is there a way to add Toolbar to uservoice activities? I can't do it without changing the activities in Uservoice, which has its own set of problems

Do you mean in place of the ActionBar?

Yes

any update on adding toolbar instead of ActionBar ?


Upgrade to git publish plugin for documentation

Due to a conflict with jgit and the Nebula plugins this work has been stuck in various branches of my personal fork for a long time. The latest versions of nebula.netflixoss have resolved some of those jgit conflicts and @sghill helped me resolve some other issues to hopefully get this working.
Once this is merged it should get rid of the final gradle related warning we have lying around during the build.

Coverage decreased (-0.02%) to 90.874% when pulling 35f1c6a9e5b1de7eec4cbca64f9f2d0629cc4f18 on tgianos:gradleGitPublishLatest into ddee8f273b9850753b8cf256288cd9df96954c90 on Netflix:master.


UTF-8 encoding is buggy

It is not possible to save/open files with text using accents, the encoding is almost always wrong.
For instance: if you write Acentos não funcionam to a file and save it when you open it again it will read Acentos n達o funcionam.

Thanks. It has already reported in #22 and we had tried to fix it in another way (#53).
This issue have caused by the jschardet's encoding detection.
In next version v0.0.9, the feature of reopening with specified encoding would be able to help it.
So we marked wontfix. I would report this issue to jschardet if we received too many similar issues.

It seems odd to me that it doesn't open with UTF-8 by default, or even make an attempt to recognize the character encoding. There's even an npm package for it.

Hi there it's still buggy in 0.0.13. Tanks anyway Marp is very useful. :)


Update adopting-cloud-update.md

added public preview note

Violation will be resolved through another PR


Update MapsIndoors SDK version

Remember to update the CHANGELOG before merging in. 🙏🏻

Is this the new SDK which includes the hover and selection?

@andreeaceachir142 No, the zoom 999 feature. The other one is still in beta for a while yet.


update table

issue https://github.com/kubernetes/website/issues/24413

review page
/assign @kbhawkey

/assign @sftim

Hi @Arhell .
Thanks for updating the table to use the table shortcode.
@tengqm pointed out (in PR #24024) that second column has three values in the other columns for "Accept" header.
It is a minor difference in the display. What do you think?

/assign @tengqm

Looks like markdown table is incapable of merge shells.
We may want to keep the HTML version which is not ugly.

If the Markdown doesn't do what's needed let's keep the HTML.

/close


Any chance of becoming an official grav plugin?

Hello,
Your plugin sounds so nice but I have no clue how to install it...
I downloaded it and put it in the plugins folder of my website...
But the "admin panel" doesn't show it at all...
And I have no idea how to implement it in my website...
So maybe you could almost put a "how to install-guide"
Do you still continue developing it?
Is there any chance it could become a grav-official-plugin (installable from tghe admin panel)?

Hi prinla,
actually, I don't have the time to make this a full plugin.
I started this mostly out of curiosity ;) Just to see if it is possible and how frontendediting and wysiwyg could be implemented.
If you want to try this, you have to checkout the repository into a subfolder of the plugin dir. Then it should appear in the plugin list of the admin-plugin, where you could enable it.
You need to create a user with site.editor rights. With this one you have to login at the frontend!

hi Bugunter,
i installed the plugin and it shows up in Grav.
Where can i create a user with site.editor rights.
I modified the Admin Account under Acess with site.editor: true but it wont work.

Hi @NHISystems
I added a short section to the readme.md, hope that helps


[Event Request] Table 36 "Sales Header" - Function OnDelete - OnDeleteBeforeOnDeleteRecordInApprovalRequest

Could You please, add the following event to the Table 36 "Sales Header"
Object: Table 36 "Sales Header"
Function: OnDelete
Publisher Event: OnDeleteBeforeOnDeleteRecordInApprovalRequest
Reason: To implement custom business logic and avoid deletion of approval request
Where is the event placed (see image attached)?:

Insert next 3 lines
IsHandled := false;
OnDeleteBeforeOnDeleteRecordInApprovalRequest(Rec, IsHandled);
if not IsHandled then
Above the line
ApprovalsMgmt.OnDeleteRecordInApprovalRequest(RecordId);
Event Code:
[IntegrationEvent(false, false)]
local procedure OnDeleteBeforeOnDeleteRecordInApprovalRequest(var SalesHeader: Record "Sales Header", var IsHandled: Boolean)
begin
end;
Thanks in Advance

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


[Connector-V2] Add Sentry Sink Connector

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
https://sentry.io/welcome/
Sentry is a Application monitoring and Error Tracking software.
Here is some doc can help to add sentry sink connector.
https://docs.sentry.io/platforms/java/
Usage Scenario
No response
Related issues
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Closed by #2584


Is it possible to use the current plugin with c#?

Is it possible to use the current plugin with c#?

I had to do a bit of research before answering your question, so I'm sorry for the delay. Just now using GDExtension in general from C# is a work-in-progress in Godot. There seems to be some ways of creating C# bindings for GDExtensions, but they seem a bit hacky to me. In GodotSteam GDExtension documentation there's a workaround to use GDScript as glue code between C# and GDExtension. So that could be one way of using this extension, too, until the C# bindings for GDExtensions is in better shape in Godot overall.

I stand corrected, you can use this with C# even without the bindings!
This is what you need to do, for instance with a Behaviour Tree leaf node, if you want to add a ticking method:

Extend the node with a script as usual.
Change the UtilityAI node class name to be just Node
When ticking the root node, use the node Call() method: SomeRootNode.Call("tick", this, delta);

On my main test scene, this is how the _PhysicsProcess method looks like where I have the node UtilityAIBTRoot:
        public override void _PhysicsProcess(double delta)
	{
		GetNode("UtilityAIBTRoot").Call("tick",this, delta);
	}

Then on the leaf node:
using Godot;
using System;

public partial class testleaf : Node
{

	public int on_tick(Variant user_data, double delta)
	{
		GD.Print("Test!");
		return -1;
	}

}

And this seems to work just fine!

I stand corrected, you can use this with C# even without the bindings!我纠正了，即使没有绑定，您也可以将其与 C# 一起使用！
This is what you need to do, for instance with a Behaviour Tree leaf node, if you want to add a ticking method:这是你需要做的，例如，如果你想要添加一个滴答方法，那么使用行为树叶节点：

Extend the node with a script as usual.像往常一样使用脚本扩展节点。
Change the UtilityAI node class name to be just Node将 UtilityAI 节点类名更改为仅 Node
Add the on_tick method exactly as it would be spelled in GDScript.添加与 GDScript 中的拼写完全相同的 on_tick 方法。
When ticking the root node, use the node Call() method: SomeRootNode.Call("tick", this, delta);勾选根节点时，使用 node Call（） 方法： SomeRootNode.Call("tick", this, delta);

On my main test scene, this is how the _PhysicsProcess method looks like where I have the node UtilityAIBTRoot:在我的主要测试场景中，这是我拥有节点 UtilityAIBTRoot 的 _PhysicsProcess 方法的样子：
        public override void _PhysicsProcess(double delta)
	{
		GetNode("UtilityAIBTRoot").Call("tick",this, delta);
	}

Then on the leaf node:然后在叶节点上：
using Godot;
using System;

public partial class testleaf : Node
{

	public int on_tick(Variant user_data, double delta)
	{
		GD.Print("Test!");
		return -1;
	}

}

And this seems to work just fine! The same way seems to work for State Tree as well and I guess with the Agent Behaviours (I don't have time to test it just now), so as long as you name your methods exactly as they would be named in GDScript, they should work.这似乎很好用！同样的方式似乎也适用于状态树，我想使用代理行为（我现在没有时间测试它），所以只要你完全按照 GDScript 中命名的方法命名，它们就应该有效。

Thanks,


build: Respect environment LDFLAGS

Prepend them to libSDL2_image_la_LDFLAGS. This fixes the build when
using clang and LTO.
Clang needs -flto in both the CFLAGS and LDFLAGS.

This shouldn't be necessary in an Autotools build system, because the generated Makefile.in includes both the library's libfoo_la_LDFLAGS and the user-supplied LDFLAGS in the link line:
libSDL2_image_la_LINK = $(LIBTOOL) $(AM_V_lt) $(AM_LIBTOOLFLAGS) \
	$(LIBTOOLFLAGS) --mode=link $(OBJCLD) $(AM_OBJCFLAGS) \
	$(OBJCFLAGS) $(libSDL2_image_la_LDFLAGS) $(LDFLAGS) -o $@

so perhaps something else is going wrong?
Autotools build systems expect the LDFLAGS to either be passed to configure as an argument like LDFLAGS=-flto, placed in the environment at configure time like LDFLAGS=-flto ./configure ..., or passed to make as an argument like make LDFLAGS=-flto. Which one are you doing?

This is an error that occurs when using the %configure macro in Fedora's rpm config. But now I think this is just a case of an old libtool stripping the -flto.