[Feature Request] Convert io.rancher.container.requested_ip string to array

Rancher Version:
1.0.1
Docker Version:
1.11.1
OS and where are the hosts located? (cloud, bare metal, etc):
Ubuntu 14.04 - Amazon AWS
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single node rancher with external DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Feature Request:
I have a rancher stack and docker-compose have io.rancher.container.requested_ip for every container. Works fine, but just with scale = 1, because with scale = 2, container 2 have random ip, because IP is not available.
So, I propose convert io.rancher.container.requested_ip to 'array', like:
io.rancher.container.requested_ip = <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>, <IP_ADDRESS>
When I increase scale, rancher assigns next available ip from list.

+1

+1

In favor of @vincent99 's idea "label sucks, why not api fields", we should probably define a service field which includes all the requested IPs.

Available at v1.6. Now api field and label can be accepted as a comma-separated string. For standalone container only label works, and for service.launchconfig it works on both api and label.

Tested with rancher-server build from v1.6:
Able to pass comma separated ip addresses to io.rancher.container.requested_ip example ( "<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>,<IP_ADDRESS>") when creating service.
When service instances are scaled up , every instance of the service gets an ip from the requested ip list as expected.

@StrongMonkey , When I try to upgrade a service that has io.rancher.container.requested_ip set , I see that the ips on the upgraded service instances get random Ips.

Issue seen with upgrade is tracked in - https://github.com/rancher/rancher/issues/9395

Tested with rancher-server build from v1.6:
Able to create service with requestedIpAddres set as a field in launch config.
    launch_config = {"imageUuid": "docker:sangeetha/testnewhostrouting",
                     "requestedIpAddress": "<IP_ADDRESS>, <IP_ADDRESS>"
                    }

Service instances gets ipaddress from the requestedIpAddress list.

@JaviSabalete  With the next rancher server release  (v1.6.5) , io.rancher.container.requested_ip will accept  comma separated ip addresses.


⚠ Bofrost.fr has degraded performance

In 4a15e31, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1265 ms

Resolved: Bofrost.fr performance has improved in 56afcd1 after 6 minutes.


App not passing props to child

Inside a clean generated project, if I use console.dir(this.props) inside the Main.js file, in the console I can only see an empty Object, and given the way Main is called inside App.js I assume it should at least has a prop named 'actions'.
I'm sorry if this is a noob question, but I simply can't figure out what is happening.

That is ritght, the props object should have and actions prop. Just scaffolded a clean project and checked that this is true =>

Maybe you could post a gist of your Main.js file where you are trying to log the props.
Also a screen shot of your dev console could help here.

I'm sorry for the delay in answering back, here it's the gist of the Main.js file and the console output.

Please let me know if you need any other information.

Interesting, this is console.log from a fresh scaffolding? It is missing all the warnings it should have (see my screenshot). Can you please share your whole project? I'd like to run it locally - something major seems to be broken here,....

sure, you can see the project here. I really appreciate your responsiveness and I'll gladly help you solve this problem.

Alright, I see what is going on here. My PR for the template got merged, and I did not update this generator accordingly and had everything linked locally, so I did not got the error on my side :-/
The temporary fix for you would be to basically copy the contents of /src/components/run.js to /src/index.js and adapt the paths. This is what your index.js should look like:
import React from 'react';
import { render } from 'react-dom';
import { Provider } from 'react-redux';
import configureStore from './stores';
import App from './containers/App';

const store = configureStore();

render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('app')
);

I will update the generator accordingly - this may take a day or two.
Thank you for helping me find the problem :-)

AWESOME!! You're the best man! Let me know if you need with anything, I'm new to some of the technologies you're using here, but I'm more than happy to try.

I already made the change, will release a new version today (and close this issue). You are the real hero for opening up an issues, the bug has been here for over one month without anyone noticing ;-)


Feature request: split a geometry into "left" and "right" sides

See nbviewer summary here (a fuller description is below):
http://nbviewer.jupyter.org/urls/dl.dropbox.com/s/ll3mchnx0jwzjnf/determine left-right split.ipynb
(I have asked a SO question about this as well)
The ops.split function works great but I have run into a problem where I need to define a "left" and "right" side of the splitter, and determine which split objects are on each side. I have a partial implementation (which probably isn't very good) at the SO link above, but haven't been able to figure out the final step: determine which side (of A and B) is the "left" and the "right".

I'm also encountering this a very similar issue. I'm splitting one polygon with the boundary of another polygon. I want to determine which part of this splits were inside the boundary and which were outside. Unfortunately, the contains function doesn't seem to produce the right answer here:
MWE is here:
    from shapely import wkt
    s1 = wkt.loads('POLYGON ((0.2078438002058038 0.4705512467551718, 0.06235887659769469 0.3926495947966552, 0.0905172363484244 0.05993803878260231, 0.1407225797239911 0.05285641352680036, 0.4015832633478681 0.1267864397636866, 0.4800537098260661 0.3226047034925194, 0.2078438002058038 0.4705512467551718))')
    s2 = wkt.loads('POLYGON ((0.05369338383126491 0.08762298016215156, 0.08125203846017491 0.051955997058169, 0.2762563441942675 0.09091232767746611, 0.3858594380772172 0.1651373216721855, 0.274490453603779 0.3705956794695212, 0.2295401917449915 0.3841220513041212, 0.05369338383126491 0.08762298016215156))))')

    from shapely import ops
    parts = list(ops.split(s1, s2.boundary))

    for i, p in enumerate(parts):
        print('s2.contains(p{}) = {}'.format(i, s2.contains(p)))

This results in:
s2.contains(p0) = False
s2.contains(p1) = False
s2.contains(p2) = False
which should not be true. The p2 polygon is clearly "inside" the s2 polygon as shown here:

Note the above plot was generated with some custom drawing code:
    # Custom drawing code
    part1, part2, part3 = parts
    import kwplot
    plt = kwplot.autoplt()
    kwplot.figure(fnum=1, doclf=True, pnum=(1, 2, 1))
    kwimage.Polygon.from_shapely(s1).draw(color='red', alpha=.5)
    kwimage.Polygon.from_shapely(s2).draw(color='blue', alpha=.5)

    plt.text(s1.centroid.x, s1.centroid.y, 's1')
    plt.text(s2.centroid.x, s2.centroid.y, 's2')

    kwplot.figure(fnum=1, pnum=(1, 2, 2))
    kwimage.Polygon.from_shapely(part1).draw(alpha=.4, color='red')
    kwimage.Polygon.from_shapely(part2).draw(alpha=.4, color='green')
    kwimage.Polygon.from_shapely(part3).draw(alpha=.4, color='blue')
    plt.text(part1.centroid.x, part1.centroid.y, 'p1')
    plt.text(part2.centroid.x, part2.centroid.y, 'p2')
    plt.text(part3.centroid.x, part3.centroid.y, 'p3')


Resource usage of rework process info

metrics link
one pod uses significantly more CPU

one pod used 3x as much mem

FD don't seem to be closed quickly after processing the debug infos

The latest status after several improvements: (namespace="parca-devel" the latest main and namespace="parca" the latest stable release)
https://demo.pyrra.dev/prometheus/graph?g0.expr=avg by (namespace) (process_resident_memory_bytes{container%3D"parca-agent"})&g0.tab=0&g0.stacked=0&g0.show_exemplars=0&g0.range_input=2d&g1.expr=avg by (namespace) (process_open_fds{container%3D"parca-agent"})&g1.tab=0&g1.stacked=0&g1.show_exemplars=0&g1.range_input=2d&g2.expr=avg by (namespace) (rate(process_cpu_seconds_total{container%3D"parca-agent"}[5m]))&g2.tab=0&g2.stacked=0&g2.show_exemplars=0&g2.range_input=2d

The number of open FDs is higher but matched to the capacity of the object pool. It can be reduced. I'll introduce a flag tomorrow.


remove gradient on login button

Sorry it took so long.

Ok, sorry, not fast enough.

Oops, sorry. Yeah, I just did it in master.

No problem, I know, you need to keep up your streak :-)


resolve_binds_by_sym input option does not seem to change behavior

Hyprland Version
 System/Version info
Hyprland, built from branch HEAD at commit 1c460e98f870676b15871fe4e5bfeb1a32a3d6d8  (props: bump ver to 0.36.0).
Date: Wed Feb 28 00:32:40 2024
Tag: v0.36.0

flags: (if any)

System Information:
System name: Linux
Node name: mistral
Release: 6.7.6-arch1-2
Version: #1 SMP PREEMPT_DYNAMIC Thu, 29 Feb 2024 19:08:51 +0000

GPU information:
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] [1002:1638] (rev c6) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:

Bug or Regression?
Bug
Description
I use two different keyboards on Hyprland (namely fr,us), and I tried the new resolve_binds_by_sym option from the latest release. However, this option does not change my keybinds in regard to my current keyboard.
How to reproduce

create a keybind (e.g SUPER SHIFT + Q for killactive)
set input with fr, us without resolve_binds_by_sym
the keybind is triggered by the same combination in both keyboards (e.g leftmost key of second row)
set input with fr, us WITH resolve_binds_by_sym
the keybind is triggered by the same combination in both keyboards (e.g leftmost key of second row)

Expected behavior:
At step 5, the keybind is triggered by different key combination (e.g leftmost key of second row in AZERTY, leftmost key of first row in QWERTY)
Crash reports, logs, images, videos
No response

If I am not mistaken, this option was specifically created for multi-layout configuration, so that the binds are changed according to the layout.
That is what is said in the wiki, and also what I could guess from the PR https://github.com/hyprwm/Hyprland/pull/4851 that added this (disclaimer: I don't know much C++, but I could kinda guess what it does, I may be mistaken).

no the thing is you need to set the layout per-device for htis to work

patch.txt
try this

oops - that won't compile. This:
patch.txt


Compatibility with pythongosssss/ComfyUI-Custom-Scripts Autocomplete

See https://github.com/pythongosssss/ComfyUI-Custom-Scripts?tab=readme-ov-file#autocomplete for reference.
Currently, this script's autocomplete functionality only gets applied to ComfyUI string widgets in the node graph. It would be nice if the same autocomplete functionality is applied to the Controller widgets.

Thanks
On Thu, 19 Dec 2024 at 5:00 am, catboxanon @.***> wrote:

See
https://github.com/pythongosssss/ComfyUI-Custom-Scripts?tab=readme-ov-file#autocomplete
for reference.
Currently, this script's autocomplete functionality only gets applied to
ComfyUI string widgets in the node graph. It would be nice if the same
autocomplete functionality is applied to the Controller widgets.
—
Reply to this email directly, view it on GitHub
https://github.com/chrisgoringe/cg-controller/issues/466, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBLMA5KAHTSZ7Z5YISEHNT2GGZ2TAVCNFSM6AAAAABT3IB4K2VHI2DSMVQWIX3LMV43ASLTON2WKOZSG42DQNBTGMYTIMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Unsupported libcxx test issues categorized here

This issue tracks libcxx tests we would like to run but the tests require features that are not supported in the enclave unrelated to the functionality being tested:

[x] Requires pthread_create():

3rdparty/libcxx/libcxx/test/libcxx/utilities/memory/util.smartptr/race_condition.pass.cpp (Enabled with PR #1070 )

[ ] Enclave abort() results in SIGILL instead of SIGABRT:

3rdparty/libcxx/libcxx/test/libcxx/debug/debug_abort.pass.cpp

[ ] Requires c++17 support: Currently, libcxx enclaves are still built with c++14 and OE enclave support is with c++1 (Last updated, 11/15/2018)

3rdparty/libcxx/libcxx/test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp
3rdparty/libcxx/libcxx/test/std/algorithms/alg.sorting/alg.clamp/clamp.comp.pass.cpp
3rdparty/libcxx/libcxx/test/std/algorithms/alg.sorting/alg.clamp/clamp.pass.cpp
3rdparty/libcxx/libcxx/test/std/language.support/support.types/byte.pass.cpp

[x] Requires libgcc support: Enabled these tests with clang. (PR #1082 )

3rdparty/libcxx/libcxx/test/libcxx/containers/unord/next_pow2.pass.cpp
3rdparty/libcxx/libcxx/test/std/utilities/template.bitset/bitset.members/count.pass.cpp

[x] Locales other than C or POSIX locales are unsupported: => These will never be supported.

3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/hash.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/types.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.codecvt.byname/ctor_wchar_t.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/is_1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/is_many.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/narrow_1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/narrow_many.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/scan_is.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/scan_not.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/tolower_many.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/toupper_many.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.ctype/locale.ctype.byname/widen_many.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_en_US.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_ru_RU.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_zh_CN.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_string_en_US.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/curr_symbol.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/decimal_point.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/frac_digits.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/grouping.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/negative_sign.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/neg_format.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/pos_format.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/positive_sign.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_en_US.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_fr_FR.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_ru_RU.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_long_double_zh_CN.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.monetary/locale.money.put/locale.money.put.members/put_string_en_US.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long_double.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/date_order.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/date_order_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_date.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_date_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_one.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_one_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_time.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_time_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_weekday.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_weekday_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_year.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.get.byname/get_year_wide.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/category.time/locale.time.put.byname/put1.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/decimal_point.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/grouping.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locale.categories/facet.numpunct/locale.numpunct.byname/thousands_sep.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/overflow.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/pbackfail.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/seekoff.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/test.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale.convenience/conversions/conversions.buffer/underflow.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/assign.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/char_pointer.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/copy.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/default.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/locale_char_pointer_cat.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/locale_facetptr.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/locale_locale_cat.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/locale_string_cat.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.cons/string.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.members/name.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.operators/eq.pass.cpp
3rdparty/libcxx/libcxx/test/std/localization/locales/locale/locale.statics/global.pass.cpp

Changing title to indicate that these tests have been moved to tests.unsupported as they are not in tests.broken.

PR #1070 - Enabled 1 libcxx thread test
PR #1082 - Enabled 2 libcxx tests that build and run with Clang but do not build with gcc

Enclave abort() results in SIGILL instead of SIGABRT:
3rdparty/libcxx/libcxx/test/libcxx/debug/debug_abort.pass.cpp
This is expected enclave behavior that abort() will result in SIGILL and not SIGABRT. This test cannot be supported.

Opened new issue #1091 to cover the libcxx tests that require the C++17 flag. So, closing this issue.


ENH: Replace itkGPUKernelClassMacro calls by GetOpenCLSourceOf functions

Removed all (n = 22) itkGPUKernelClassMacro macro calls, as there is an upcoming breaking change of the macro definition with ITK 5.2 (introduced with ITK v5.2rc01).
Replaced the class definitions that were created by the macro by simple functions of the form GetOpenCLSourceOf...Kernel(), which just return the OpenCL source code as a string.
Allows compilation on ITK 5.1.1 and 5.1.2, as well as ITK 5.2.0 (release candidate 1 or 2).

For the record, I also informed Denis (@dpshamonin) about this pull request, this morning.

Why is it preferred to change these names?
This macro is now not valid:
https://github.com/InsightSoftwareConsortium/ITK/blob/9ff84420e55d2f86984f40f14861bddf0812b82b/Modules/Core/Common/include/itkMacro.h#L1230-L1231
and Python API, e.g.:
https://github.com/InsightSoftwareConsortium/ITK/blob/9ff84420e55d2f86984f40f14861bddf0812b82b/Modules/Core/GPUCommon/wrapping/test/itkGPUImageTest.py#L57-L60
It also seems better to have a consistent method name without the requirement to adjust the call for every object.

Thanks for your feedback so far @thewtex  However, one way or the other, it seems too early to drop ITK 5.1 compatibility for elastix right now. Can the ITK pull request I just did possibly provide a way out of this issue? Please have a look: "COMP: Fix itkGPUKernelClassMacro(kernel) backward compatibility", https://github.com/InsightSoftwareConsortium/ITK/pull/2337
Obviously, when https://github.com/InsightSoftwareConsortium/ITK/pull/2337 would be accepted, this SuperElastix/elastix pull request (#427) isn't really necessary anymore, and may be dropped.

Update: this pull request is marked as "draft", and is intended to be dropped, once pull request https://github.com/InsightSoftwareConsortium/ITK/pull/2337 "COMP: Fix itkGPUKernelClassMacro(kernel) backward compatibility" is merged onto ITK master branch

Closed: Superseded by pull request InsightSoftwareConsortium/ITK#2337 commit https://github.com/InsightSoftwareConsortium/ITK/commit/6c06a28d4314f0b314a9a9410317f1b942ad6d96 "COMP: Fix itkGPUKernelClassMacro(kernel) backward compatibility"


Bolding the axis

This is a feature request more than an issue: is it possible to put in evidence the axis with a chart option? I've not a way but generating a series of zero values!

Closing as abandoned. Please reopen if you can provide more information. Thank you.


Automatically pause when memory is limited

v86 should pause when the performance.memory values indicate low memory and the tab is not in focus, to avoid being unloaded. Additionally, an alert should be triggered to pause execution and further avoid being unloaded.

I don't think pausing will reduce memory usage, unless the guest is running new programs which cause the jit to generate new wasm modules. In that case it should be up to the user to pause the emulator.
Moreover, I'd rather fix the underlying issue, i.e. reduce memory usage by generating more compact wasm modules.

That would be nice.

Let's close this then.


Hardware-friendly decomposition

Context:
This PR attempts to remove needless complications in the code arising from the difference between how theorists define T matrices and the equivalent transformations that the chip implements.
Currently, the unitary is decomposed into Clements T matrices which are later converted to phases on the chip by rectangular_symmetric function. Decomposing the unitary directly into Mach Zehnder units would make the code simpler. It would also make it easier to modify the code and decompositions as planned in order to account for imperfect beamsplitters and also for power reduction, etc.
Description of the Change:

Adds MZ matrices to eventually replace T matrices to now represent the units on the chip.
Removes need for function rectangular_symmetric by modifying rectangular_phase_end_MZ to  directly calculate internal and external phases on chip.
Tests very similar to the ones already present are added.

Possible Drawbacks:

Doesn't match the theoretical conventions in Clements and Xanadu modular decompositions.

Possible reviewers could be @lneuhaus , @nquesada  and/or @ishdhand

CodeFactor found multiple issues last seen at 2fa0b43f300d92bae13c9424d1add9346de1e570:
Redefining name 'T' from outer scope (line 233)
strawberryfields\decompositions.py:499

No space allowed before :
if U[n, m] == 0 :
                ^

strawberryfields\decompositions.py:541

Trailing whitespace
strawberryfields\decompositions.py:493
strawberryfields\decompositions.py:654
strawberryfields\decompositions.py:661
strawberryfields\decompositions.py:492
strawberryfields\decompositions.py:548
strawberryfields\decompositions.py:500

No space allowed before :
if U[m, n] == 0 :
                ^

strawberryfields\decompositions.py:520

Documentation and formatting changes are fixed now. Comments about this or anything else are welcome!

Thanks so much, @josh146 for the very helpful comments! I learnt a lot :)

@shreyapkumar, is this ready to be merged in?

Yes, nothing more to add from my side!


python:3.6.4-slim can not guess extension well

It was not a language bug in my tests.
I have test python:3.6.4-jessie and python:3.6.4-slim, and python in jessie works well.
here is my python script:
import mimetypes, sys

print("python ver: %s" % (sys.version) )
print("ext: %s" % (mimetypes.guess_extension("application/vnd.openxmlformats-officedocument.wordprocessingml.document")) )

@tianon I am stuck at this. Can you tell me how I can add mime-support package to a 3.9-slim-buster image?

The same as you would for any OS package; likely by creating a Dockerfile to create a new image:
FROM python:3.9-slim-buster
RUN apt-get update && apt-get install -y mime-support && rm -rf /var/lib/apt/lists/*

(Though, looking at the description of the package, you probably just need the media-types package instead)


@iteles isn't a grinch

@iteles's profile says she's a grinch, she's not sent any pull requests but she's merged 10 pull requests so we should definitely show those on her profile and reduce her grinchyness by 2 sizes

:heart:

Boo! This is a definite case of mistaken grinch identity! 👎
Does this mean that merged PRs should be gifts (and displayed on the calendar), or there should be a new condition in the /users/show.html.erb template to say "if @iteles has 0 sent PRs, but n merged PRs, then display the merged_pull_requests partial"?

I'm obviously pro merged PRs being gifts. ;-)

TBH I'd prefer we end up removing the concept of gifts and the UI for managing them at some point as it almost all happens automatically anyway now.

there should be a new condition in the /users/show.html.erb template to say "if @iteles has 0 sent PRs, but n merged PRs, then display the merged_pull_requests partial"?

Sounds good to me 👍


whitespace nodes

The latest version is removing all my nodes only containing whitespace. It's introducing subtle rendering bugs where spaces are missing e.g.

Jos Shepherd

is getting output as:

JosShepherd

Is the whitespace stripping by design or is it a bug?

The whitespace stripping is by design. A non stripped parsing option is in the works.

cool beans. I've found the setting and I'm patching it manually until it becomes an option

Now you can do:

var $ = cheerio.load(html, { ignoreWhitespace: false });

to disable whitespace stripping. You can also enter any other options that node-htmlparser2 accepts.


feat: support google analytics [EP-1019]

Changes:

configure Google Analytics via GTM tag
refactor app environment variable reading from single location

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


"PLAYER_SERVER_PLAYER_INFO is not supported by your server", are you sure ?

Id like to use tablist packets with skript-packet
When i try to use the packet PLAYER_SERVER_PLAYER_INFO, i get an error saying
PLAYER_SERVER_PLAYER_INFO is not supported by your server

so far no problem
But the packet PLAYER_SERVER_PLAYER_INFO allow the server to update player's info in the tab (user list). (information from here)
So, how the server update and manage the tablist list if he dont use the PLAYER_SERVER_PLAYER_INFO packet ?

he use another similar packet ? No, acording to wiki.vg, PLAYER_SERVER_PLAYER_INFO is the only way to update tablist (with PLAYER_SERVER_PLAYER_INFO_REMOVE, but we have another problem with he)
skript-packet say wrong ? Probably not, but possible (you to confirm)
i miss something ? Totaly possible.

Im on the last version of paper 1.19.3, using the last version of skript and the last version of skript-packet.
The PLAYER_SERVER_PLAYER_INFO packet type is repertoried here (screen down there) and in all packettypes skript-packet expression

This issue is the result of the truble of an entier day : Now im locked here, and i dont understand how is it possible that "PLAYER_SERVER_PLAYER_INFO is not supported by your server".
Take this issue as a questionnement, because im not sure, and I probably miss somethings.
(and i created the issue #17 due to this truble)

can't replicate. works fine for me mc1.19.3, protocollib v5.0.0-snapshot.
on packet event play_server_player_info:
    set {packet} to event-packet
    broadcast {packet}

ok !
Problem patch when updating ProtocolLib from v5.0.0-SNAPSHOT-b600 to v5.0.0-SNAPSHOT-b612.
(before)

(after)

So, now its working !
I was locked for 2 weeks about that, the solution was just to update protocolib, so dumb.
It a mistake from me. moral: update protocolLib to the latest version
Thank for your help, and thank for skript-packet !!


fix(dashboardeditor): keep state of images to upload

Summary

Newly uploaded images need to be added to a local state and then passed back when onSubmit is called. This way the images are uploaded at once on save rather than during the editing process.

:tada: This PR is included in version 2.141.0-next.48 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.141.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


find_window_by_handle cannot convert nil to int

I'm getting this error after updating.
My lazy.nvim config:
{
    "luukvbaal/statuscol.nvim",
    init = function()
      vim.o.statuscolumn = "%@v:lua.ScSa@%s%T%@v:lua.ScLa@%=%{v:lua.ScLn()}%T%@v:lua.ScFa@ %{%v:lua.ScFc()%} %T"
    end,
    config = function()
      -- functions modified from statuscol.nvim
      --- Toggle a (conditional) DAP breakpoint.
      local function toggle_breakpoint(args)
        local status, persistent_breakpoints_api = pcall(require, "persistent-breakpoints.api")
        if not status then
          return
        end
        if args.mods:find "c" then
          persistent_breakpoints_api.set_conditional_breakpoint()
        else
          persistent_breakpoints_api.toggle_breakpoint()
        end
      end

      --- Handler for clicking the line number.
      local function lnum_click(args)
        if args.button == "l" then
          -- Toggle DAP (conditional) breakpoint on (Ctrl-)left click
          toggle_breakpoint(args)
        elseif args.button == "m" then
          c "norm! yy" -- Yank on middle click
        elseif args.button == "r" then
          if args.clicks == 2 then
            c "norm! dd" -- Cut on double right click
          else
            c "norm! p" -- Paste on right click
          end
        end
      end

      require("statuscol").setup {
        relculright = true,
        foldfunc = "builtin",
        separator = " ",
        Lnum = lnum_click,
        DapBreakpointRejected = toggle_breakpoint,
        DapBreakpoint = toggle_breakpoint,
        DapBreakpointCondition = toggle_breakpoint,
        -- when manually setting vim.o.statuscolumn, you shouldn't set below.
        -- setopt = true,
        -- order = "SNsFs", -- gitsigns, number, fold, separator
      }
    end,
  }

Thanks, should be fixed

The error is gone, but my line numbers are weird.

Do I have to change the statuscolumn option?

Oh yeah sorry, the ScLn() block should be reevaluated now (I changed this because the setopt version using the %! is evaluated). I hadn't considered setopt = false tbh but I think I'll keep it like that. You would need this now:
vim.o.statuscolumn = "%@v:lua.ScSa@%s%T%@v:lua.ScLa@%{%v:lua.ScLn()%}%T%@v:lua.ScFa@ %{%v:lua.ScFc()%} %T"

Works perfectly now. Thanks for your help!


Rollback a specific batch of migrations

Add a new option batch to the RollbackCommand.
Add a new function getMigrationsByBatch to the MigrationRepositoryInterface.
Implement getMigrationsByBatch in DatabaseMigrationRepository.

This new option allows the developer to rollback a specific batch of migrations. This can be helpful
in situations where a production bugfix introduced database changes after the current feature branch introduced database changes. The develop may not be able to rollback the production bugfix batch, but still wants to revert the batch from the current feature branch to make slight changes to the database migrations introduced in the current feature branch.
A PR to laravel/docs will also be submitted.

It is not a good practice to rollback on production. Production migrations should go forward only.

It is intended for rolling back a specific batch of migrations. The example is that a migration is introduced in your working copy as part of a production bug fix (main -> bugfix -> merge into main and develop). But it holds for any migration that comes in to your working copy from any branch.
The point is that once you have a migration younger than the latest migrations in your working copy, you may not want to roll back and redo those younger migrations, but you still may want to roll back a specific batch of migrations from before. Meaning, executing php artisan migrate:rollback --step 2 would also roll back the youngest migration (the one you don't control), but executing php artisan migrate:rollback --batch 5 would roll back the migrations from batch 5, and leave the migrations from batch 6 alone and in tact.
Akin to cherry picking which set of migrations you want to roll back.

I agree with @antonkomarev, wouldn't it be better to pull the bugfix changes into the feature branch to make adjustments on that branch?
The rollback could also throw exceptions when it expects a database structure that doesn't exist anymore because of later migrations:
// Migration A
public function down () : void {
    Schema::table('users', function (Blueprint $table) {
        $table->string('nickname')->after('lastname');
    });
}

// Migration B (already run)
public function up () : void {
    Schema::table('users', function (Blueprint $table) {
        $table->dropColumn('lastname');
    });
}

When trying to rollback migration A the lastname field won't exist, because it was dropped by migration B. Of course, in the end it's the developers choice and one could argue that the developer has to make sure the rollback will work, but I'm not sure if this is something that should be supported by the core? I'm seeing a lot of "Error when using migrate:rollback" issues because people tried to randomly rollback a migration to simply remove a column they added a few months back, instead of creating a new migration that drops the column.

Yes absolutely correct. Those arguments would ultimately lead to dropping the entire roll back functionality. I'm not sure if that's what's wanted either.
The way I see it is that a co-developer created a very valid but rather complex migration, and that migration ended up being merged into your current feature branch. You apply the migration in your working copy (as you do, because hey why not that particular feature is now in production), and about a day or later you figure that you need to change some migration that is part of the feature set that you are working on.
So your migrations are: 2022_02_17_064050_something_or_other.php and 2022_02_17_070812_other_than_that.php and your co-developer's migration is 2022_02_18_120000_lets_not_have_a_down_function_here.php.
This leads to a situation where you cannot roll back the last migration, because there's no down function. But you still want to roll back your misconstrued migrations and actually create proper migrations (since you're still working on a feature branch, you might as well, right? Right!) You're stuck.
Intro cherry picking which migration set to roll back, and you're good to go!

or maybe the down function wasn't tested properly, and you want to be able to by pass it...
or maybe ... whatever the reason you have for not wanting to roll back the younger migrations.
And since I refer to working copy / feature branch fairly often, it would be kind of clear that this is a possible command to execute intended for your working copy, rather then for production.
But then again, if we don't want functions / features that can break production, then we'd be looking at stripping all sorts of features out of Laravel :-)

Those arguments would ultimately lead to dropping the entire roll back functionality.

It is right. It is common no to write rollback migrations at all. Because there are many cases when a rollback is no longer possible. And no one ever tests rollback migrations, you can't be sure that it really works as expected. If you want to revert changes, you are writing new migration which will revert all the changes back.
I recently created a small library to check that migrations cannot be reverted:
https://github.com/antonkomarev/php-db-migration-validator

@antonkomarev Let's not get into a biased or even opinionated discussion about "no one" and "common" and "many cases".
I am merely proposing a way to cherry pick the roll back of a particular set of migrations without the need to also roll back the last migrations (which is what --step offers).

@PHPGuus Please enable maintainer edit access

@PHPGuus you're submitting from an organisation account. Please resubmit from your personal account because maintainer edit access cannot be granted on organisation PR's.


Thanos compact does not work on Windows

Thanos, Prometheus and Golang version used
thanos.exe --version
thanos, version 0.7.0 (branch: HEAD, revision: c6eaf68bec32aefd280318eaef6121d6ddb20d10)
  build user:       root@aa355daaf987
  build date:       20190902-15:35:44
  go version:       go1.12.5

What happened
Run the thanos compact command on an existing bucket (on-premise s3)
thanos.exe compact --objstore.config-file=bucket.yaml --consistency-delay=30m --retention.resolution-raw=30d --retention.resolution-5m=30d --retention.resolution-1h=30d --log.level=debug

The same command works correctly on a linux ecosystem but crash on windows.
Apparently on windows FS, it is impossible to mkdir the requested folder (see detailed logs)
What you expected to happen
Compaction to happen as on linux systems.
How to reproduce it (as minimally and precisely as possible):
use thanos.exe compact with the same command line args you have one running on linux ecosystem.
Full logs to relevant components
Logs

level=info ts=2019-09-16T15:10:31.7504834Z caller=compact.go:1029 msg="start of GC"
level=info ts=2019-09-16T15:10:31.7604868Z caller=compact.go:1035 msg="start of compaction"
level=warn ts=2019-09-16T15:10:31.7644854Z caller=prober.go:154 msg="changing probe status" status=unhealthy reason="compaction failed: compaction failed for group 0@{prometheus="si",prometheus_instance="alt",replica="prometheus-si-alt-0",stack="muc4"}: create compaction group dir: mkdir data\compact\0@{prometheus="si",prometheus_instance="alt",replica="prometheus-si-alt-0",stack="muc4"}: The filename, directory name, or volume label syntax is incorrect."
level=error ts=2019-09-16T15:10:31.765485Z caller=main.go:213 msg="running command failed" err="compaction failed: compaction failed for group 0@{prometheus="si",prometheus_instance="alt",replica="prometheus-si-alt-0",stack="muc4"}: create compaction group dir: mkdir data\compact\0@{prometheus="si",prometheus_instance="alt",replica="prometheus-si-alt-0",stack="muc4"}: The filename, directory name, or volume label syntax is incorrect."

Environment:

Windows 10

After a quick chat with @bwplotka he confirmed that  windows support is in the maybe priority list.
If someone can spend the time to implement proper testing and maintain it maybe it will be considered, but for now it should be considered unsupported.


[Diagnostics] Improve diagnostics involving macros

The main change here is to update the in expansion of macro note location for attached macros to that of the attribute instead of the declaration. But as that then makes the declaration it's on less obvious, I've added its name to the message as well. Since we just changed the location of macro_attached_to_invalid_decl I also added the declaration name there as well.

@swift-ci please test

@swift-ci please test

@swift-ci please test


Add tests to ensure a ValidationError is raised

These tests were added to cover a new Response validation case.
Second tests fails as there is a bug in Pydantic v2.1.1.
See:

Pydantic issue: https://github.com/pydantic/pydantic/issues/6901
FastAPI discussion comment: https://github.com/tiangolo/fastapi/discussions/9709#discussioncomment-6565813

I would argue this is not a bug in pydantic but a misuse of a performance-oriented validation escape hatch. You should only use model_construct if you are confident that you are creating the model in a valid way, as the whole point is to elide validation for the sake of performance. If you have bugs in your application code caused by that, I would advise against the use of model_construct. Also, the main reason to use model_construct is for performance, and given the massive performance improvements in pydantic v2, it may be worth benchmarking whether there are even any noticeable performance benefits to the use of model_construct anyway. In at least some cases (especially for shallow/simple models), model_construct can be comparable or worse in performance than model_validate anyway.
The reason this would have worked in earlier versions of FastAPI/pydantic was the use of the "secure cloned field", whose purpose was to prevent extra fields from being included at serialization time. But this came at the price of a massive performance overhead caused by revalidating data that in principle was already known to be valid.
We made specific changes in pydantic v2 to render the secure cloned field unnecessary, in particular, serializing models based on their schema rather than through recursive calls to the field attributes' dump methods, and accepting subclass instances as allowed for fields without revalidation, and this is responsible for significant performance improvements in versions of FastAPI using pydantic v2.
As a consequence, there are now issues with invalidly-constructed models not being validated properly, but again, I would consider this a misuse of model_construct rather than a bug in pydantic/fastapi.

Amazing writeup as always @dmontagu, thanks! And thanks @marielejeune, I think that would probably answer it, if you have more questions/problems, please create a new discussion question. 🤓


[Question/Request] Creating an HeapMap

What version of this plugin do you use? ($> cordova plugin list)
cordova-plugin-googlemaps 2.0.0-beta2-20170510-1500 "cordova-plugin-googlemaps"

What is your question, problem or request?

Hi, I'm trying to figure out how to integrate "properly" an HeapMap. I have found some thread which specify that old version of this plugin couldnt support it (https://github.com/mapsplugin/cordova-plugin-googlemaps/issues/757 , https://github.com/mapsplugin/cordova-plugin-googlemaps/issues/651)
So i would like discuss about your opinion how we can do this (with existing features, or/and with additional features).
Can you please give your point of view, on the following points :
With existing feature

With Tiles Overlay, by setting a low/medium opacity .
[-] Require to implement a server side heatmap image  generator based on url (http://server/z/x/y.jpg)
[-] Images are requested according zoom/lat/lng (so may impact server bandwith & server load)

Using Ground Overlay feature, by setting a low/medium opacity
[-] Require to implement a server side heatmap image generator (but easier than the one in Tiles)
[-] Images are requested according lat/lng area (so less bandwith/server load impact than Tiles Overlay)

With additional features

Integrating heatmapjs 270lines code ?
Adding from scratch an algorithm example base algorithm

What's the best solution according to you ? Any others ideas ?

Ohh, you used old version. (may be stable for you?)
I tell you one thing, I changed implementation of the TileOverlay.
Currently, working with callback.
  map.addTileOverlay({
    // Load image files from the local file path
    getTile: function(x, y, zoom) {
      return "(path to your image)" + zoom + "_" + x + "-" + y + ".gif"
    }
  }, function(tileOverlay) {

  });

It means you can generate any URL.
Unfortunately, data:image/(png|gif|jpeg);base64:.... is not available for TileOverlays.

While GroundOverlay supports data:image/(png|gif|jpeg);base64:.... protocol.
The possible solution of at this time is to generate heatmap tile images with JS side, then pass it to GroundOverlay.

Or support data:image/(png|gif|jpeg);base64... protocol for PluginTileoverlay.
(But I need to work)

If you (and someone) donate $1,000 USD to this project, I will implement the heatmap (like marker clustering which is working currently)

No, i'm using v2 beta2 (20170510).
I'm not sure if 1k$ is right price to support this feature. Actually HeatmapTileProvider is only available for Google Map Android Sdk, and unsupported on the Google Map IOS Sdk (https://github.com/googlemaps/google-maps-ios-utils/issues/59). It's not event on their roadmap, they expect a community PR for this.
So I can only see two possibilities to solve this :

Submitting PR which support heatmap for Google Map IOS Sdk, and then developing the Heatmap layer for this plugin (both IOS/Android)
Using JS only layer (which needs to communicate with this plugin when map is moving, etc.).

Well, this said, about the donation:
According the way you'll do it and the timeline, I may participate up to 50$ max. Also I wont participate if community is lacking to also financially participate. It could looks like selfish, however this plugin has a good popularity, so I dont see any reasons to be only supporter. If nobody is willing to participate i'll just hire a developper to integrate it for my project only.

No, i'm using v2 beta2 (20170510).

The v2 has been updated frequently. The latest version of right now is 2.0.0-beta2-20170625-1805.
You can check the latest version at
https://github.com/mapsplugin/cordova-plugin-googlemaps/blob/multiple_maps/plugin.xml#L2

Hooo nice to know, yeah it was kinda stable, but gonna check all commits, and try it, thx ;)

Google Maps Utility library (Android and iOS) are not developed by Google. They are developed by community.

i'll just hire a developper to integrate it for my project only.
Yes, you can. I don't mind.
If you hire an engineer, the code might be higher than $1,000USD (but depends on your country and the engineer)
In general, one Android engineer for one month is $5,000USD in the US at least.

$1,000USD is too cheep for me actually.
I'm not amateur or student programmer. I'm senior full stack engineer at work.
(And you know what I'm a member of GDE, so I'm an expert of Google Maps API certified by Google long years actually)
This plugin project is for that improving my skillset, improve Google Maps community, and help developers for non-native code developers (not Android and iOS developer).
Not work.
It means I need to work in my private time (such as after working hour, or holidays)
If you still feel selfish and the cost is expensive, you can hire someone or try by yourself.
The code is full open source.
You can fork the repository, and you can expand it. (Some people do this)
Or you can fundraise (like marker clustering).
Or you can just wait.
At least, I gave to you a hint (generate tile image, then pass it to ground overlay), you can try it.

Just to be clear: i'm not doubting about your skills, nor the time involved in this project. I know about the implication of such works (and again thanks for this lib, as i said in another threads). I'm just doubting about the community support/implication and was trying to quantify the work for this feature. Dont see any hostilities in what i said.

In order to implement the heatmap feature for this plugin, at least Java, Objective-C, and JS skills are required. The people who have those skills are expensive usually.
And these people are typically busy for another project. That's why kind of high amount (not too high for people who are really want the feature, and not too cheep for working people).
At least, no body works without any purpose. In order to involve someone who is not interested in this plugin but who has high skillset, someone need to pay for working.
It is difficult to evaluate the work to money.
You might feel "the heatmap is already implemented in JavaScript, so porting to this plugin should be easy", but actually it is not so easy.
The difficult thing is this plugin has three threads: browser, native (main thread), and native (background thread). This is really tricky.
For example, zooming-in faster case.
You control the map on the browser view.
But drawing heatmap images in native side takes kind of long seconds.
During the generating images in native side, you control the map (zoom-in) again.
In that case, the native side code has to do something, such as cancel the work or redraw the image (depends on developer).
If implementation is in only JS, it's easy. All threads are running on browser.
But handling with native code, not easy.
So what I want to say it is difficult to estimate the cost. Difficult or easy is really depends on implementation. That's why I asked fixed amount $1,000USD for all feature request cases.
If donation amount is reached to $1,000USD, and someone create this feature then send a pull request to this repository, I will check the pull request, and I will pass the amount to the developer.
Or nobody create the feature, I will pool the amount for future, and buy new devices or software for test (such as iPhone).

Thanks for these clarifications, it definitely gives a better view of the technical challenges.
I will on my side investigate some stuffs to get a whole idea. Meantime, I hope people who are interested about this feature will manisfest themselves.

@wf9a5m75 Is there any option to develop Heatmap support for 1000$ donation nowadays?

@homeportcz Maybe, asking to @sam2x that he archived to implement heatmap or not. If he archived to implement, and he agree with you to use his code, you can get his heat map soon.
If you really want to desire to implement heat map feature into this plugin as official, I can implement it if someone pay $1000 USD for my work, like HTMLInfoWindow, and MarkerCluster.

@wf9a5m75 Thanks, we will talk about it, as our company paid for MarkerCluster.
@sam2x Any news about your work? our company could donate some money for working implementation for iOS and Android.

@wf9a5m75 1000$ donation for implementing Heatmap for Android and iOS (same functions as https://developers.google.com/maps/documentation/android-sdk/utility/heatmap and https://developers.google.com/maps/documentation/ios-sdk/utility/heatmap) is confirmed by our company.
Could you estimate delivery time and pass paying details?
Thanks

@homeportcz Some hours later after answering your question (https://github.com/mapsplugin/cordova-plugin-googlemaps/issues/1518#issuecomment-518435322), my life stage was significantly changed. Let me hold your request one week, and sorry for inconvenience.

@homeportcz Thank you for waiting one week. Are you still interested in the heatmap feature?

@wf9a5m75 yes, we are still interested in.

ok, I will create it. I will send you more details to your email.


Contributing Video Tutorial Not Available

Yikes! Briefly, what seems wrong?
The video tutorial under the "How do I contribute?" section in the CONTRIBUTING.md file is not available anymore.
Expected Behavior
This link should take the user to the video tutorial that is hosted on YouTube where they can view it.
Current Behavior
The link does take the user to YouTube, but YouTube shows an error message that says "This video isn't available anymore" instead of the video itself.
Possible Solution
Perhaps the video was unlisted, set to private, or moved?
Steps to Reproduce

Click on the video link https://www.youtube.com/watch?v=I7WsK5amUTA

Unfortunately, I could not locate the video.


ci: integration tests with multiple lua versions on multiple platforms

Stacked on #228 (so we can run the busted integration test with multiple lua versions).

This may be blocked by

#213

Looks like we have a linker error on aarch64-darwin when installing busted:
called `Result::unwrap()` on an `Err` value: InstallError(BuildError(CommandFailure { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "Undefined symbols for architecture arm64:\n  \"_luaL_argerror\"
# ...

ah, what are these jj shenanigans?


Improve startup logs

we are currently not communicating what are we doing at startup. This makes it harder for potential users to notice what's wrong.
For example, we don't write that we're trying to connect to electrum server - which can take a long time if electrum server is not synced or never successfully finish in case of trying to connect to testnet electrum with mainnet flag on Itchysats.
Adding more feedback would allow user to find out about such situations and potentially mitigate them.

This project is unmaintained


Better bar visualization

I would use

Code
Result
Description

U+2592
▒
Medium shade

U+2593
▓
Dark shade

U+2588
█
Full block

instead of

Code
Result
Description

U+2591
░
Light shade

U+2592
▒
Medium shade

U+2593
▓
Dark shade

to improve the visualization of the bars, specially in iOS (Tested in Telegram Desktop and Telegram iOS).

Telegram shouldn't be an issue, since progress bars are inside <pre> blocks that make the font monospaced:

In Twitter, it's true that this looks pretty bad in iOS/Safari for Mac, but if I follow your suggestion, the age groups bars then look unaligned in Firefox and Chrome (Mac), because full blocks are wider than shade blocks in this font:

And still looks bad in iOS/Safari's font:

So, unfortunately the current situation seems to be the best we can do.

I was wrong about iOS (I didn't check the monospace font).
You're right.  It's the best comprimise.


Update build script to pass --skip_deps when called with --no-deps-check

This should fix #1459

I signed it!

(Note: CI failure on Travis is unrelated to this pull)

Should I re-push to trigger CI build again?

No that's ok, thanks. The CI was broken elsewhere, we're working to fix it!


train refinenet problem

i trained the refinenet used the kalantari_dataset (input_flies, i did not use the aligned files). i wonder if you used the train_refine.py to train the model,  i concat the optical flow as the input , which you used in infer.py , i have trained(55001,155001) iters ,but i don't think the result is good as the pretrained model , here is my output for ManStanding

It is hard to say what may be the issue here. Can you share your loss curves and maybe I can help you out?

here is the train loss curve

If  I am understanding you correctly you are finetuning our pretrained model on Kalantari et al's dataset right? We didnt have access to ground truth static images and collected our own dataset and used the scripts provided to train the refinement net. For different dataset you may need to experiment with hyper-parameter values. Also, its possible that our dataset is better suited to train the refinement model and you may not get as good result as we get from our dataset. In any case, looking at the loss curve I would suggest starting with a slightly lower learning rate and decreasing it in a step by step fashion only after  the loss curve stagnates

thanks, i just used the dataset  described  in https://github.com/rajat95/Deep-Deghosting-HDR/issues/5 to train the model from scratch, is this one the dataset you used to train the refinenet~ i want to know if the dataset and code are the same like yours~

I think learning rates need a little bit playing around with to get the same result. Also quality of flow files generated can also affect the result. But the script and dataset are the same as you quoted.


model metadata

we need better ways to keep track of models ... what data they were used on, what hyperparameters, etc

[ ] store info on what training data was used to train a model
[ ] use unique IDs for trained model weights
[ ] store all values from config file with model weights?
[ ] store metrics?
[x] during implementation, keep track of model implementation choices
[] ?

what type of database?

is this like MLFlow or Weights & Biases?

could be

First implementation in bf1962f

Implement Hugginface-style model cards see  #41


⚠ Bofrost.lu has degraded performance

In 72fb8b6, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2830 ms

Resolved: Bofrost.lu performance has improved in e88825c after 9 minutes.


Fixes #3139-Pause on menu

Contains
Fixes #3139 .
How to test
Pressing Escape in the game pauses the world time.
Outstanding before merging
Maybe the getPlayerCount() method could be a separate file, so that other developers may use it too.
The player count may be updated whenever a player joins/leaves so that the engine doesn't iterate over all clients every time the escape menu is pressed.
Maybe raise a new issue for this?

Huh, wonder why our build bot didn't catch this. Lets see:
Gooey: Test this please
@GooeyHub: Test this please
Thanks for the PR @Arihant-Joshi :-)
In which ways have you tested this one, curiously? Single player, one player connected to a headless server, server+client + client, 2 players on headless, etc?

@GooeyHub: ok to test

Hooray Jenkins reported success with all tests good!

To test for it working(or rather not working if more than one player in the server), I simply changed the line
       if(getPlayerCount()==1) {
to
       if(getPlayerCount()==2) {
(see commit
89aae6e
The menu stopped working(as the check to pause now was playerCount()==2) when only one player was connected, which is expected behavior(only for that test).

Anyhow there still seems to be an issue with my PR with the game time pausing after closing the inventory by pressing the escape key.
Need some time to work on it.

Fixed the issue with previous commits by changing the check from (ESCAPE) ButtonState.DOWN to
nuiManager.isOpen("engine:pauseMenu")
Also, should I put the code for checking the player count in a different class? If yes, where?

Heya @Arihant-Joshi. Sorry about the delay, coming out from a period without enough time to really dig into PRs :-)
So on looking at this more closely I see two issues:

You've got some trivial whitespace issues that violate our code style standards. Could you please make sure you have Checkstyle working in your IDE and run it before committing code? Easy fix :-)
I'm not sure this approach is right. Pausing the game is fair if you're playing in single player mode - but this approach actually also triggers if you're the sole player on a headless server. At that point time pauses locally but continues on the server, leading to some really weird issues

Ideally you should be able to base the check on some different logic, maybe related to whether the network system is live at all. If it isn't it is pretty safe to assume single player mode.
This does actually work fine in legit single player, for instance with JS running you finally wouldn't starve to death just from going AFK. But the implications of checking this way are problematic :-)

I did away with the approach of counting the number of players on a server, in favor of checking whether the Network Mode is None(Single Player).
Also did the thing using checkstyle :-)

Thanks! That works well now :-)
The trick in multiplayer is that you have both a client plus a server even if there's only one player active. The client thinks time is paused with the menu up but the server doesn't, resulting in strange behavior as you unpause and the server has been expecting time has in fact passed, and starts trying to update the player accordingly :-)
It would be possible to pause time both on the client and the server. You could even do it if any one player had that menu up but ... at some point that probably gets silly. Fair enough that single player is different, at least for now 👍
Added you to the game credits during the merge! I did remove one unused remaining variable, but that's trivial. Appreciate the style fixes.


HP Problem.

Can we fix the HP? is terribly calculated there. The wounds table for a character with 2 Earth should be
10 = (E)arth * 5
4 = E *2
4 = E *2
4 = E *2
... and so on.
And not
10 = (e) 5
14 = 10 + E2
...
that dont even make sense. lol. ty.

Which sheet does this concern?

Probably L5R It seems to fit his description.

Is there a rules page I can read so I can have a reference. Unless someone else fix it.

Or is it litterally 10 14 18 22 26 30 34 38?

If I understand correctly though you get your first wound at 10 then the next step would be earth * 2 which it is doing at the moment?

Hello,
I'm working to resolved some of the older issues in Github. Is this still a concern?
Thanks,
Cassie

No, it was never an issue actually, there's no problem with it, although there's a problem with the SIFRpg in the Damage and Wounds area. But i dont think this is the correct place to post it.

Thanks for the update. I'm going to close this issue but it if it needs to open again please let me know.


[Bug] Datasets that are nested don't stay long after reload.

While running the master to fix the integration with Truenas Scale Cobia. I noticed that my datasets would disappear soon after reload.

Home Assistant version: 2024.4.4
TrueNAS integration version: master after 1.2.5
TrueNAS version: TrueNAS-SCALE-23.10.2

home-assistant_truenas_2024-04-24T21-40-13.988Z.log

I have tried setting up same structure you have on one of my test VMs, but still cant reproduce the issue.
Can you check if this is correct?

Also, can you attach diagnostics?
I can see what is happening in debugs, but I dont understand why.

never mind, found the issue.
strange that I had different naming.

Fix comfirmed!


Update TOC to group them as Spring Boot, Data, Security and Cloud

New TOC for  “Getting Started Guides”
Getting Started Guide

Spring Boot // Overview
- Azure Key Vault
- Azure Storage
- Azure App Insights
Spring Data // Overview
- Azure Cosmos DB
- Azure Cosmos DB Gremlin API
Spring Security // Overview
Azure Active Directory
Spring Cloud // Overview
- Azure Event Hub
- Azure Event Hub Kafka API

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/spring-framework/toc.yml
:white_check_mark:Succeeded
View (azure-java-legacy) View (azure-java-preview) View (azure-java-stable)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/spring-framework/toc.yml
:white_check_mark:Succeeded
View (azure-java-legacy) View (azure-java-preview) View (azure-java-stable)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

(Adding @rloutlaw to the discussion.)
First of all, I like the suggested rearrangement of the TOC by Spring subject area. However, one of my main points of concern is that the suggested changes will create a much-deeper TOC hierarchy than we are currently using, which I think would impact article discovery.
If you look at the current Spring TOC, we have four top-level contents items: Getting Started Guides, Tutorials, Samples, and Reference. The remaining content is all bucketed under those primary TOC items. In short, this is a two-dimensional structure, so any particular article requires a maximum of one to two clicks to find it.
That being said, the suggested TOC would move several articles into a third-tier of the hierarchy, (e.g. a three-dimensional structure), which would require additional effort for article discovery. Having seen that sort of deeper-level TOC hierarchy before, there were several customers who abandoned using the TOC because it became too-unwieldy for them to use.
With that in mind, I would personally advise against taking this suggested change, although I am curious to see what @rloutlaw thinks. I'm open to discussion of a way where we can keep a two-dimensional structure and still rearrange the articles into Spring-based subjects.

The less levels we have on the TOC, the better.
But the structure makes sense.
The solution is to ensure the TOC items show up all expanded by default.

Good point.
We want a clear structure, meanwhile avoid hiding them. The new structure aligns with the way Spring organizes its projects, that may be more familiar to our customers.
Expanding them by default sounds a good solution to me!

Following up on our conversation earlier today, my initial worry was that having articles two levels deep in the TOC hierarchy might create a problem for content discoverability. @brunoborges suggested expanding the child nodes by default, which I could see becoming unnecessarily bloated quite rapidly, which would create an entirely separate problem for content discoverability.
That being said, I would propose one of the following two TOC layouts, which might serve our purposes without becoming unwieldly.
Suggestion #1: We could combine Yitao's and Bruno's suggestions and expand only the first-level children in the Getting Started Guide, and collapse the second-level children. For example:

Getting Started Guide // Expand children by default

Spring Boot // Collapse children by default

Azure Key Vault
Azure Storage
Azure App Insights

Spring Data // Collapse children by default

Azure Cosmos DB
Azure Cosmos DB Gremlin API

Spring Security // Collapse children by default

Azure Active Directory

Spring Cloud // Collapse children by default

Azure Event Hub
Azure Event Hub Kafka API

Tutorials // Collapse children by default
Samples // Collapse children by default
Reference // Collapse children by default

Or - we could promote the major Spring technology children to the parent level, and then collapse all children by default. For example:

Getting Started Guide // Collapse children by default
Spring Boot // Collapse children by default

Azure Key Vault
Azure Storage
Azure App Insights

Spring Data // Collapse children by default

Azure Cosmos DB
Azure Cosmos DB Gremlin API

Spring Security // Collapse children by default

Azure Active Directory

Spring Cloud // Collapse children by default

Azure Event Hub
Azure Event Hub Kafka API

Tutorials // Collapse children by default
Samples // Collapse children by default
Reference // Collapse children by default

What does anyone else think?

I suggest we go with the TOC that is best for the content we have today.
Once (if) we have more content, then we optimize the TOC again.
On Wed, Dec 12, 2018, 00:43 Robert McMurray<EMAIL_ADDRESS>wrote:

Following up on our conversation earlier today, my initial worry was that
having articles two levels deep in the TOC hierarchy might create a problem
for content discoverability. @brunoborges https://github.com/brunoborges
suggested expanding the child nodes by default, which I could see becoming
unnecessarily bloated quite rapidly, which would create an entirely
separate problem for content discoverability.
That being said, I would propose one of the following two TOC layouts,
which might serve our purposes without becoming unwieldly.
Suggestion #1 https://github.com/Azure/azure-docs-sdk-java/pull/1: We
could combine Yitao's and Bruno's suggestions and expand only the
first-level children in the Getting Started Guide, and collapse the
second-level children. For example:

Getting Started Guide // Expand children by default

Spring Boot // Collapse children by default

Azure Key Vault
Azure Storage
Azure App Insights

Spring Data // Collapse children by default

Azure Cosmos DB
Azure Cosmos DB Gremlin API

Spring Security // Collapse children by default

Azure Active Directory

Spring Cloud // Collapse children by default

Azure Event Hub
Azure Event Hub Kafka API

Tutorials // Collapse children by default

Samples // Collapse children by default
Reference // Collapse children by default

Or - we could promote the major Spring technology children to the parent
level, and then collapse all children by default. For example:

Getting Started Guide // Collapse children by default
Spring Boot // Collapse children by default

Azure Key Vault
Azure Storage
Azure App Insights

Spring Data // Collapse children by default

Azure Cosmos DB
Azure Cosmos DB Gremlin API

Spring Security // Collapse children by default

Azure Active Directory

Spring Cloud // Collapse children by default

Azure Event Hub
Azure Event Hub Kafka API

Tutorials // Collapse children by default
Samples // Collapse children by default
Reference // Collapse children by default

What does anyone else think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/azure-docs-sdk-java/pull/724#issuecomment-446441155,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH6z96L-jmoWXCAQ_ynTu5EzeAVCoTiks5u4G1qgaJpZM4ZHwVm
.

@rmcmurray both suggestions work for me. Slightly prefer the 1st one, since we do not have that many toturials today. Could you approve/re-send the PR for this change?
The key is to strucure the content in a Spring-native way. :)

@Matthew-Dong, FYI – There is a blocking issue with the build process that is currently under investigation.
The past few PRs that we have submitted have failed to get built properly, (such as the Build 38940 failed  listed above), so this PR might be held up for a couple of days while the build issue is resolved.

  This is the expected behavior of the build system.

OPS Build status updates of commit 6841f13:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/spring-framework/toc.yml
:white_check_mark:Succeeded
View (azure-java-legacy) View (azure-java-preview) View (azure-java-stable)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


(BOLT-940) Simplify setup for apply with Orchestrator

When Bolt connects to a target over the Orchestrator transport, we know
that the puppet-agent package is installed. Skip querying version to
check. That removes the requirement that the correct version of the
puppetlabs-puppet_agent module is installed in your PE infrastructure to
run apply_prep.

Updated.


About Chat Memory’s message management strategy and other storage implementations

Hi community,
I would like to ask, regarding Chat Memory, is the community ready to implement some other storage methods, such as Mysql, redis, etc.
Is there any message management strategy similar to Langchain4j's TokenWindow and TimeWindow for Message?
Thank you so much!

@tzolov can you answer this, thanks


Upgrade package dependencies

Upgrades devDependencies versions to latest versions, removing npm audit warnings
found 14 vulnerabilities (2 low, 11 moderate, 1 high) in 1887 scanned packages
  14 vulnerabilities require semver-major dependency updates.

Upgrading rollup slightly changes the built package.
Upgrading typescript triggered a type warning regarding calling execToplevelComputation with an undefined value.

Looks good, thanks!


Gooey command to run package as GUI, without having gooey as dependency

This is a feature request 🙂
If I understood correctly, we currently need to add Gooey as a dependency of a package to enjoy the generated GUI.
Would it be possible to have a command instead, like gooey my_package? Or maybe something more helpful for gooey, like gooey my_package.cli:main?
Gooey would "just" need to import the package/module, wrap the specified function into its Gooey object, and run it.
The immediate benefit is that we could have generated GUIs for every Python package that relies on argparse, instead of requiring the developers of each package to depend on Gooey.
Sorry if this has already been asked (I did not find such issue).

I closed my PR, maintainer didn't give any news (no problem, just cleaning up). Feel free to take it over.


Why JSX is not set to react-native?

I noticed from JSX docs that JSX has also option react-native for it.
Here are all three different modes for JSX

TypeScript ships with three JSX modes: preserve, react, and react-native. These modes only affect the emit stage - type checking is unaffected. The preserve mode will keep the JSX as part of the output to be further consumed by another transform step (e.g. Babel). Additionally the output will have a .jsx file extension. The react mode will emit React.createElement, does not need to go through a JSX transformation before use, and the output will have a .js file extension. The react-native mode is the equivalent of preserve in that it keeps all JSX, but the output will instead have a .js file extension.

So why react-native-typescript-transformer is telling us to configure JSX to react instead of react-native. Are there some drawbacks etc? :D

Hi Henrik,
Good question! I agree, the situation is a little confusing, and the reason
for it is historical rather than technical.
When React first appeared on the scene, most JS tooling was not compatible
with the JSX syntax. To mitigate this, people would only put JSX syntax in
files with the extension .jsx. Eventually the tooling caught up and now
most of us put JSX in .js files as though it were part of the ECMAScript
standard.
When TypeScript first added support for JSX, people were still using the
.jsx extension a lot, so the TS crew made .tsx files compile to .jsx
files. This is how the --jsx react option works.
The React Native ecosystem fully embraced the .js extension to the point
that the bundler metro doesn't even support loading .jsx files. This
posed a problem for people using TypeScript with React Native because
TypeScript only supported .jsx files. I can't actually remember how
people would use TypeScript with React Native back in those days, but it
was probably ugly.
The --jsx react-native option was added to to able to compile .tsx
files to ordinary .js files. It has no other difference to --jsx react.
So, as long as you're using react-native-typescript-transformer it
doesn't make a difference which option you use :)
On Mon, 19 Feb 2018 at 09:59 Henrik Raitasola<EMAIL_ADDRESS>wrote:

I noticed from JSX docs
https://www.typescriptlang.org/docs/handbook/jsx.html that JSX has also
option react-native for it.
Here are all three different modes for JSX
TypeScript ships with three JSX modes: preserve, react, and react-native.
These modes only affect the emit stage - type checking is unaffected. The
preserve mode will keep the JSX as part of the output to be further
consumed by another transform step (e.g. Babel). Additionally the output
will have a .jsx file extension. The react mode will emit
React.createElement, does not need to go through a JSX transformation
before use, and the output will have a .js file extension. The react-native
mode is the equivalent of preserve in that it keeps all JSX, but the output
will instead have a .js file extension.
So why react-native-typescript-transformer is telling us to configure JSX
to react instead of react-native. Are there some drawbacks etc? :D
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ds300/react-native-typescript-transformer/issues/46,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABL1qXK0yxmIg94nFj30n8SYHM-9tq5wks5tWUYSgaJpZM4SKSuZ
.

Hi Henrik,
Good question! I agree, the situation is a little confusing, and the reason for it is historical rather than technical.
When React first appeared on the scene, most JS tooling was not compatible with the JSX syntax. To mitigate this, people would only put JSX syntax in files with the extension .jsx. Eventually the tooling caught up and now most of us put JSX in .js files as though it were part of the ECMAScript standard.
When TypeScript first added support for JSX, people were still using the .jsx extension a lot, so the TS crew made .tsx files compile to .jsx files. This is how the --jsx react option works.
The React Native ecosystem fully embraced the .js extension to the point that the bundler metro doesn't even support loading .jsx files. This posed a problem for people using TypeScript with React Native because TypeScript only supported .jsx files. I can't actually remember how people would use TypeScript with React Native back in those days, but it was probably ugly.
The --jsx react-native option was added to to able to compile .tsx files to ordinary .js files. It has no other difference to --jsx react.
So, as long as you're using react-native-typescript-transformer it doesn't make a difference which option you use :)

Great explanation! So would it makes sense to change readme to use react-native if it doesn't matter and it semantically more relevant? :D

Sure, makes sense. I'll do that.

Hmm actually I misremembered what the react-native option does, which is highly embarrassing since I wrote it 🤦♀
It actually leaves the JSX untouched, which makes it identical to the preserve option except that it emits .js files instead of .jsx files. This is already mentioned in the README so I'll leave it untouched.

 I didn't notice it. Thanks for your help :)

0.57.3 is not support

hich would ca

thank you ,I set jsx 'react-native',but i got a error:can't find the variable React;
so I set jsx 'react',it works!


Undefined function theme-color()

Bootstrap 4.0.0-alpha.6 no longer have function theme-color(), replaced by built-in sass function map-get().

hi @uyab
actually Bootstrap v4.0.0-beta.2 supports theme-color() function as a wrapper for map-get()


feat: enable cert pinning for redirection capabilities

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


Integrate local bank payment gateway

how can i integrate  payment gateway which is from local bank?

Could please check the Payment APIs that we provide? furthermore your bank should provide sort of APIs to integrate with

@sanshanthan I am working on the same.
But I am making it work for Payu, Paytm and Razor pay.
Integration is still in progress.

@ashishsanchi Did you get a chance to integrate for Paytm? Otherwise, I will start working on it.

@naveenalavilli I have done Razor pay integration. Its working smooth.
I can share code if you want.

@ashishsanchi that helps! please share it with<EMAIL_ADDRESS>

@naveenalavilli  I have updated it at RazorPayPayment Integration

@ashishsanchi Did you get a chance to integrate for Paytm? Otherwise, I will start working on it.

I will be starting working on Paytm in this week, we can collaborate if you wish.
I am also making Mobile Application in Xamarin which is integrating with Simplcommerce


Update changelog with latest changes for 1.28

Here's an update to the CHANGELOG for OmniSharp 1.28. Also, this is an official heads-up/reminder to include a changelog update when making PRs. :smile:
cc @mholo65

I think both https://github.com/OmniSharp/omnisharp-roslyn/pull/1056 and https://github.com/OmniSharp/omnisharp-roslyn/pull/1054 should still be merged before 1.28 release

Agreed! Maybe changelog updates could be added to those PRs?

Since this is a markdown-only change, I'm going to go ahead and merge without waiting on the Mac build.

@DustinCampbell if you don't mind, we'd be really happy to get #1057 merged for 1.28 as well. I'll push the release bits for Cake.Scripting and friends to NuGet tonight and update that PR.

@mholo65 : We'll wait for you to be ready before releasing 1.28.


Add BYOK feature support to Terraform

Summary:
This PR adds encryption at rest support to Terraform.

Cluster creation with AWS CMK and GCP CMK
Adding EAR to existing cluster
Enable or disable EAR for existing EAR enabled cluster.

Testing:
Manually tested out all the scenarios.

Please check the update cluster flow also.

Will take the update cluster flow in the next PR.

Can you please add an example for each of the types of CMK clusters under: https://github.com/yugabyte/terraform-provider-ybm/tree/main/examples/resources/ybm_cluster ?


Fix some typos

Description
Two words were mispelled and there was an extra comma. They are fixed with this PR.
Fixes # (issue)
N/A
Type of change

[x] This change requires a documentation update

Checklist:
N/A

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] Any dependent changes have been merged and published in downstream modules

Thanks @deldesir for helping us to update the docs. Much appreciated.


Package: Adding build script to npm package.json

Adding build script to package.json, this way when the package is imported through npm, it is ready to use.

Thanks for the contribution. The problem being addressed here was already fixed by adding the files property. The next release will have the necessary files published to npm.


Please release a new version!

Please could you release a new version including the merged #205.

I did, https://github.com/mbedmicro/pyOCD/releases/tag/v0.6.1, its on pypi as well.

I was looking in the wrong place, thanks!


Cache a backup of the built app when dynamically installing JS packages

Is your feature request related to a problem? Please describe.
It's not a problem yet, but the fact that idom restore needs to rebuild the application is definitely an issue since that re-build could break in unforeseen ways and leave the package in an unusable state.
Describe the solution you'd like
When building the client-side app for the first time after a fresh install one of two things should happen:

A backup of the originally distributed app should be created that idom restore can use later.
New builds of the app shouldn't replace the originally distributed version and should instead be put in a new location.

I like option 2 best. From an implementation perspective I think this means there should be a BACKUP_BUILD_DIR and a BUILD_DIR. At import-time, if BUILD_DIR does not exist, BUILD_DIR should be created from a copy of BACKUP_BUILD_DIR.

Closed by: https://github.com/idom-team/idom/pull/313


DNN-23121: sanitize the properties.

we can't save these into db, as if some code read it and use decode in future, the issue will occur again. we should remove them for safety.

@zyhfish In that case sanitization into the DB done via Html.Encode would be preferred.

Hi @mitchelsellers , generally we shouldn't save those scripts, as its just like a bomb, we don't know who will read and how to display it. we should always remove them before saving into db.

I agree. HTML encoding should be preferred instead of removing content

code updated.


Update zio, zio-test, zio-test-magnolia, ... to 2.1.1 in main

About this PR
📦 Updates

dev.zio:zio
dev.zio:zio-test
dev.zio:zio-test-magnolia
dev.zio:zio-test-sbt

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

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

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

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

Superseded by #316.


Allow Advisor Organizations to Have More than One Report Approval Chain

Only one report approval chain is allowed per advisor organization.  However within an advisor organization, advisors advise different principal organizations or different milestones/tasks.  That means different report approvers within the same advisor organization must approve different reports within the same approval step.  This has resulted in 17 approval steps having five or more approvers in one step.  (Six approval steps have 11 or more approvers per approval step).  For every report needing approval at that step, each report approver must determine if they are the correct report approver to approve the report based on the report's milestones/tasks or the principal organization being advised.
Allow each advisor organization to have more than one approval approval chain.
Reference item 55

@dspCarlson now we also have approval chains for Location and Tasks. Can this be closed?

This is no longer a valid requirement but only because the situation doesn't present itself with the mission drawdown.


require the version of scipy to be  >= 0.16

Fix issue #138.  The minimal version of scipy should be 0.16, installing py-earth  with scipy versions from 0.13 to 0.15 triggered the same error in #137.

It seems a segmentation fault happens in pyearth.tests.test_earth.test_check_estimator, I also get it in the master.

@mehdidc Thanks for the fix and finding that segfault bug.  Merging this into master after fixing the segfault.


Sounds for placeables and tools WIP

Description
Task: Sound design for placeable items and tools.
Feature: #544
The game is lacking juice!!! So to help this red team aka DJ khaled team will be implementing sounds for things implemented by us across the semester. This includes placeables, items, tools etc
Dependencies

[ ] #385

Milestones
List of steps that need to be completed for this task.

[ ] List of things to be implemented (Oct. 11)
[ ] Have half the sounds implemented (Oct 14)
Completion Deadline: October 17

Documentation

TO BE DONE
will incl links to everywhere  I implemented sounds ig

Member

Shanon Lakshan Chandrasekara @86LAK
Peter ASMR @p-lahanas

i am the sound guy. i will write ticket probs tomoz :)

i wrote the task ticket 👍

Did a test run and got tractor working. took the noise from https://www.wavsource.com/sfx/sfx.htm
with policy https://www.wavsource.com/dis.htm

stuck until fishing guy does fishing stuff @JTrenerry


unify sources

currently, we have two different types of "source":

in memory stores (value, list, keyvalue, pq)
interfaces to external things (NSQ, websocket)

They distinguish themselves as the stores need locking but no parameters, whereas the interfaces need parameters but no locking.
The PQ is maybe a bit inbetween, as the ordering of the messages (high first or low first) could be set as a parameter.
The NSQ and Websocket sources also explore two different ways of dealing with params. The NSQ source explicity has params set on it by selecting the source and entering in values, whereas the websocket is explicitly dialled using a connection block.
This issue proposes two things:

stores and interfaces ought to be different types. They should be rendered differently in the UI, locking logic should be different, and their method vocab should be different.
for interfaces, we should ditch parameter setting in favour of connection blocks.

I agree. does this mean:

NSQ should get a 'connect' block?
locking only applies to stores and not interfaces?

yes and yes.

further, each interface (esp. now that we've ditched server) should literally have connect, receive, and send blocks. If we can figure it out, I'd love it if the send and receive blocks were common.

I think this has been thoroughly explored now. Closing.


The time zone of pods and nodes  are different,the backup jobs  can not be running at really times ！

Describe the bug

Hello, the longhorn pods date is not the same to the nodes ,so the running time is not the time we needed when we create a backup job 。Can the longhorn update the pods used the ENV like follow these:
env:
- name: LANG
value: "en_US.UTF-8"
- name: TZ
value: "Asia/Shanghai"
Thank you !
To Reproduce
Steps to reproduce the behavior:

install longhorn,check the pods used  UTC time,no  the CST+8
create a backup job,check the backup running time.

Expected behavior
the pods timezone ENV can be defined by users at installing  longhorn from Apps catalog.
Log
If applicable, add the Longhorn managers' log when the issue happens.

Environment:

Longhorn version:v0.6.2
Kubernetes version: v1.15.5
Node OS type and version: rancheros v1.5.4

@Jawenba Longhorn internally is using UTC across the system so we can make sure the timestamps of different logs are in the same timezone so it can be easily cross-checked.
Longhorn uses Kubernetes CronJob to schedule backups. According to the Kubernetes document:

All CronJob schedule: times are based on the timezone of the kube-controller-manager.
If your control plane runs the kube-controller-manager in Pods or bare containers, the timezone set for the kube-controller-manager container determines the timezone that the cron job controller uses.

So the fact Longhorn is using UTC timestamp in the log doesn't impact the running time of the recurring backup jobs.

@yasker ok,thank you!

你有解决这个问题不？按照他说CronJob用的是UTC，但事实上在业务层面是在时区下操作的，这要怎么处理，设置时区变量吗


Merge pull request #1 from Azure/master

Merge pull request #36 from eawagu/master

Hi @eawagu, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, AZPRBOT;

This PR has 0 Files changed. What is the purpose of the PR?


[action] app_store_build_number: Changed the sort value for when returning the list of builds from the Connect API for TestFlight builds

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

The ordering of the build was not valid when using a specific build number schema
Fixes: https://github.com/fastlane/fastlane/issues/14867
Description

The initial flag '-version' works only if you use integer values for sorting the list of builds and their version numbers.
Seeing that my is not the standard integer but rather a string in a specific format, for some reason the -version flag was not working, so with changing the flag to '-uploadedDate' it will reorder the build list based on the data of upload which should be the same as the one before function wise, or in other words, it will always fetch the news/last/uploaded version from TestFlight.

Hey @mollyIV 👋 ,
I am going to a quick investigate as soon as I can for additional details to provide here.
What I can say at this moment why I proposed this change is because of the order it was returning. So basically whatever I try, I was unable to get the list of all release by version, it will only return the first uploaded and not the last "version", maybe it has something to do with the way my versions are structure, in my project the CFBundleShortVersionString is of a structure 2.0.1 while the CFBundleVersion is structured as the short version + the current number of a build distributed: <IP_ADDRESS> (6 being the sixth iteration of the app uploaded to TestFlight).
My best guess why the -version flag wasn't working for me, was maybe perhaps of the way I version the builds. No matter how I call the action, it will always return me the first uploaded and never the last.
But if I changed the flag from -version to -uploadedDate I get the last uploaded build from TestFlight in a normal format.
I understand that my findings here are clashing with the original change made to this part of the code, but I didn't manage to find any other solution to my problem except this.
I'm open to any further discussion if needed!

@Kurt57 I've updated the PR with resolved conflicts.

@Kurt57 @mollyIV Hey guys, do you think it's possible to review this PR? Don't want to be pushy or anything just that it's kinda important, since it touches upon a certain detail of the entire action.
Thanks for taking the time!

Hey @vlazdra 👋

Hey guys, do you think it's possible to review this PR?

Sure it is, so sorry for such a delay 🙇 @joshdholtz may I kindly ask you to have a look at this and share your thoughts? 🙏:pray:

Done


librc: use return value of rc_getline for len instead of the buffer size

This needs a commit message.