Paraview crashes after importing converted .vtu/.vtk files from .f3grid (FLAC3D)

I converted a .f3grid file from FLAC3D to .vtu and .vtk. After important the file to Paraview to visualise the mesh, Paraview crashes and closes. Now I don't know if the problem is in the converted files or it is a issue with Paraview.
Thank you

@keurfonluu Best append the meshes here. (I think GitHub wants you to zip them first though.)

@nschloe @keurfonluu here the mesh files:
testmodell3.zip
Thank you for your help

The problem is with FLAC3D itself (either the mesh file, or reading this file).
Using https://github.com/tianyikillua/paraview-meshio-reader to read the original FLAC3D file, ParaView also crashes.
<meshio mesh object>
  Number of points: 68796
  Number of elements:
    wedge: 38
    hexahedron: 61142
  Cell data: flac3d:zone

So we only have (read) 68796 points, however
np.any(mesh.cells["hexahedron"] >= mesh.points.shape[0], axis=1).sum() = 1253

so we have 1253 hexahedron elements that refer to non-existing nodes!

Perhaps that's something we should assert against when writing a file.

Thank you @tianyikillua for your remark. I will check the file and try again. It looks like i found my problem. I will let you know soon.

Alright, there now is meshio-info which prints some details and issues if it found some.
meshio-info /tmp/testmodell3.f3grid

<meshio mesh object>
  Number of points: 68796
  Number of elements:
    wedge: 38
    hexahedron: 61142
  Cell data: flac3d:zone

ATTENTION: Inconsistent mesh. Cells refer to nonexistent points.

Let's call this fixed.

Let's call this fixed.

Not necessarily.
Like Abaqus / Nastran, each cell is defined using the unique but not necessarily naturally ordered id's of the nodes.
In this case, the last node is referred to with the id 69773, even though it is the 68796th and the last point of the mesh.

Currently it seems to me that _flac3d.py assumes that these id's correspond to the natural ordering of nodes. These id's are not used and converted to the natural ordering of nodes, as did for Abaqus / Nastran.

I tried with a different mesh file. It worked fine. I could import and visualize in paraview without problem.
The problem should be in fact what @tianyikillua mentioned. Our meshing tool does not necessary use an ordered list of Id's for nodes. We have always gab in the node list.  The reason for that is that we use oftly extruded meshes: i.e. We mesh a 2D model and extrude "manually" in the third direction to get a 3D-model. During this process, the user defines which Id-number he wants to use for the next layer of nodes.
The .f3grid file i tested yet was modeled in 3D and meshed in ANSYS then converted to FLAC3D. Because of ANSYS, the nodes are necessarily ordered. Therefore I could convert the mesh properly.
It would be nice if _flac3d.py can deal with those kind of meshes.
Thank you guys for your support.

Aliright, reopening. So this is now a feature request for node ids in flac3d.

I'll look into that today.

Should be fixed now with PR #511.

Thank you @keurfonluu. I would have never thought the meshio community is so reactive. You solved all my issues in just few hours. Thank you very much.

Alright, closing again. :smiley:

hello @keurfonluu ,
i tried the newest version you pushed on github and already merged by @nschloe . I still get the crashing issue in paraview with the test file I uploaded here. Could you please try again if it works fine on your side? thank you.

You will have to re-read the FLAC3D and then convert it to any format you want. The problem is not with ParaView but with how we read the mesh file.

hello @tianyikillua ,
this is what i did. first i upgraded meshio:

then i re-read the test-file and convert to vtu and vtk:

finally I tried to visualize those files in paraview. it crashed

here are the files i converted:
testmodell5.zip

The updates have not been pushed to the official package index PyPI, where pip uses.
You can do pip install -U git+https://github.com/nschloe/meshio to download and install the latest development version.

ahhh that is the problem. I tried pip install -U git+https://github.com/nschloe/meshio and I got an error. I will wait until @nschloe push it to the official package index.
Thank you @tianyikillua

You can also clone the GitHub repo and install using the local archive by executing from the root directory:
pip install -U .

I tested my meshing file again with the newest version. It works very fine. The flac3d routine is now able to deal with non-ordered node ids.
thank you @nschloe for uploading the newest version on PyPI. Thank you @keurfonluu for updating the routine. Thank you @tianyikillua for finding error ;)
We can close this issue for good.


Add migration step to ensure code repo is visible

Resolved all conversations, but let me know if you have any concerns about the way I resolved them.


Compile with c++11 on Linux as well

The new version of node-minidump does not compile on Linux as there was one flag missing to enable c++11 features.
I would have used -std=c++11 instead of -std=c++0x, but for the support of older GCC version, the later one works better.
Bug reporting the issue:
https://github.com/electron/electron/issues/7892
Tested on:
OS: Ubuntu 12.04 (old I know but had no choice)
Compiler: GCC 4.9.4

Thanks for this 🚢 Published in 0.11.0


Multiple regions nginx-proxy-manager

We're currently utilizing Cloudflare GEO-DNS, which necessitates the establishment of multiple nginx-proxy-manager servers across various global locations.
However, a centralized management solution would greatly streamline operations. Is there a mechanism available, such as an API with CURL commands, to facilitate tasks like adding new proxy servers?
Our ideal scenario involves synchronizing all servers to ensure each proxy is mirrored across the network. It's worth noting that all servers are configured uniformly, so if it interacts with a DOCKER application, the proxy settings remain consistent throughout the network.

Just wondering if anyone has suggestions for this? as we are currently actively looking for a solution.

You could use reverse proxy with tengine in front of all instance like HI load balancing. all instance could orchestrate in different clusters with karmada & k8s and use HI entry point with nginx or tengine as a reverse proxy load balancer, the orchestration could be automatic depending on the traffic, I would use two types of nginx, one as a proxy server and one as a reverse proxy. I'm working on something similar right now, and I'd like to use the GUI from nginx proxy manager

We will most likely end up coding our own system, as we believe there is some limitations to using this tool, while it is great for small businesses, for multi-region and syncing it's just not possible without a lot of modification.
Believe it or not, it's very easy to roll out a nodeJS app, that can update server KNGIX and then reload them with cronjobs on each server.
Ideally what you want to be able to do is write each server and then just paste that content on each server.
yes this tool allows for ease of use, but we are now talking about advance tools.

+1


The NextCloud disk is not mounted in xubuntu 18.04

Problem description
The cloud-init script fails to configure and mount the NextCloud disk in xubuntu 18.04
Logs

cloud-init log
2020-04-20 16:35:37,943 - stages.py[INFO]: Loaded datasource DataSourceNoCloud - DataSourceNoCloud [seed=/dev/vdb][dsmode=net]
2020-04-20 16:35:38,084 - stages.py[INFO]: Applying network configuration from fallback bringup=False: {'ethernets': {'enp1s0': {'dhcp4': True, 'set-name': 'enp1s0', 'match': {'macaddress': '26:54:06:c4:9b:b0'}}}, 'version': 2}
{'type': 'physical', 'name': 'enp1s0', 'mac_address': '26:54:06:c4:9b:b0', 'match': {'macaddress': '26:54:06:c4:9b:b0'}, 'subnets': [{'type': 'dhcp4'}]}
{'enp1s0': {'dhcp4': True, 'set-name': 'enp1s0', 'match': {'macaddress': '26:54:06:c4:9b:b0'}}}
2020-04-20 16:35:38,850 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 8 column 6: "while scanning a plain scalar
  in "<unicode string>", line 8, column 6:
      - [https://crownlabs.polito.it/clou ...
         ^
found unexpected ':'
  in "<unicode string>", line 8, column 11:
      - [https://crownlabs.polito.it/cloud/rem ...
              ^
Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details."
2020-04-20 16:35:38,862 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 8 column 6: "while scanning a plain scalar
  in "<unicode string>", line 8, column 6:
      - [https://crownlabs.polito.it/clou ...
         ^
found unexpected ':'
  in "<unicode string>", line 8, column 11:
      - [https://crownlabs.polito.it/cloud/rem ...
              ^
Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details."
2020-04-20 16:35:38,862 - util.py[WARNING]: Failed at merging in cloud config part from part-001
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 140, in handle_part
    self._merge_part(payload, headers)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 116, in _merge_part
    (payload_yaml, my_mergers) = self._extract_mergers(payload, headers)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 95, in _extract_mergers
    mergers_yaml = mergers.dict_extract_mergers(payload_yaml)
  File "/usr/lib/python3/dist-packages/cloudinit/mergers/__init__.py", line 83, in dict_extract_mergers
    raw_mergers = config.pop('merge_how', None)
AttributeError: 'NoneType' object has no attribute 'pop'
2020-04-20 16:35:39,478 - __init__.py[INFO]: Created new group lxd
2020-04-20 16:35:48,094 - cc_apt_configure.py[INFO]: No custom template provided, fall back to builtin
2020-04-20 17:13:30,313 - stages.py[INFO]: Loaded datasource DataSourceNoCloud - DataSourceNoCloud [seed=/dev/vdb][dsmode=net]
2020-04-20 17:13:30,960 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 8 column 6: "while scanning a plain scalar
  in "<unicode string>", line 8, column 6:
      - [https://crownlabs.polito.it/clou ...
         ^
found unexpected ':'
  in "<unicode string>", line 8, column 11:
      - [https://crownlabs.polito.it/cloud/rem ...
              ^
Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details."
2020-04-20 17:13:30,986 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 8 column 6: "while scanning a plain scalar
  in "<unicode string>", line 8, column 6:
      - [https://crownlabs.polito.it/clou ...
         ^
found unexpected ':'
  in "<unicode string>", line 8, column 11:
      - [https://crownlabs.polito.it/cloud/rem ...
              ^
Please check http://pyyaml.org/wiki/YAMLColonInFlowContext for details."
2020-04-20 17:13:30,987 - util.py[WARNING]: Failed at merging in cloud config part from part-001
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 140, in handle_part
    self._merge_part(payload, headers)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 116, in _merge_part
    (payload_yaml, my_mergers) = self._extract_mergers(payload, headers)
  File "/usr/lib/python3/dist-packages/cloudinit/handlers/cloud_config.py", line 95, in _extract_mergers
    mergers_yaml = mergers.dict_extract_mergers(payload_yaml)
  File "/usr/lib/python3/dist-packages/cloudinit/mergers/__init__.py", line 83, in dict_extract_mergers
    raw_mergers = config.pop('merge_how', None)
AttributeError: 'NoneType' object has no attribute 'pop'

Maybe quoting the link should work @giorio94

Closing, since #223 correctly fixed this issue.


Fixes for Intel in debug mode

This PR is ready for merging, pending review
Feature or improvement description
The Intel compiler (ifort (IFORT) 2021.4.0 20210910 from the OneAPI install on Ubuntu) throws runtime errors without these changes.

In ServoDyn, the TRANSFER function was throwing an error at runtime about the result of the TRANSFER not matching the size of the C_CHAR array on the LHS.  Adding the optional size seems to fix this (probably not necessary for avcOUTNAME, but added to eliminate confusion... or from my failure to note it wasn't necessary at the time).
Passing the various unallocated y%WriteOutput arrays to the WrOutputLine resulted in the following error at runtime in debug:

forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable WRITEOUTPUT when it is not allocated

Image              PC                Routine            Line        Source
FAST.Farm<PHONE_NUMBER>220FC2  Unknown               Unknown  Unknown
FAST.Farm<PHONE_NUMBER>AF4F99  fast_subs_mp_writ        4948  FAST_Subs.f90
FAST.Farm<PHONE_NUMBER>AD84BB  fast_subs_mp_fast        4016  FAST_Subs.f90
FAST.Farm<PHONE_NUMBER>AD79B2  fast_subs_mp_fast        3934  FAST_Subs.f90
FAST.Farm<PHONE_NUMBER>867D0F  fastwrapper_mp_fw         504  FASTWrapper.f90
FAST.Farm<PHONE_NUMBER>7ED72D  fast_farm_subs_mp        1711  FAST_Farm_Subs.f90
FAST.Farm<PHONE_NUMBER>89027F  MAIN__                    109  FAST_Farm.f90
FAST.Farm<PHONE_NUMBER>406E12  Unknown               Unknown  Unknown
libc-2.31.so       00007FE06F5E00B3  __libc_start_main     Unknown  Unknown

Related issue, if one exists
Related conversation on PR #664:  https://github.com/OpenFAST/openfast/pull/664/files/2d5a2cd5fc456a77a6dc6cca444e3e0763d5548c..41579a7ed30e0f05c47ebd5260b47852eee85d8d#diff-bc64b5f80cb30c32b06ed3e52051ba117d0f3e765f375de9cd5bc7a81c6e0006
Impacted areas of the software
No changes in software operation for other compilers or compile settings is expected.
Test results, if applicable
No test results change with this.  And no, I'm not writing a unit test for this...

@bjonkman, do you mind weighing in on the allocate issue?  I think you've seen something similar before and likely have a better solution than what I put in.

Codecov Report

Merging #902 (a9d6f2e) into dev (34ef10e) will decrease coverage by 8.60%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev    #902       +/-   ##
==========================================
- Coverage   11.17%   2.57%    -8.61%
==========================================
  Files         211      69      -142
  Lines      310652   61745   -248907
  Branches   181332   34456   -146876
==========================================
- Hits        34714    1589    -33125
+ Misses     231806   58722   -173084
+ Partials    44132    1434    -42698

Flag
Coverage Δ

regtests
?

unittests
2.57% <ø> (ø)

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

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

@andrew-platt , your solution should work fine. An alternative method would be to add the allocatable attribute on the variable definitions in the WrOutputLine routine. I used that method in HydroDyn when I was debugging in there a while back, but don't think I've actually pushed any of those changes to my OpenFAST fork.
Out of curiosity, have you checked what is in those two arrays after the transfer function in ServoDyn when the source character string is shorter than the output character array? I'm guessing they had some undefined values before this change. Are they now repeating the source? or blank? or ???

@bjonkman, the transfer was keeping the c_null_char after all.  I made a mistake in my quick code for counting the number of null characters by stepping through the array from index 1 to len(avcOUTNAME) instead of size(avcOUTNAME).  The transfer is populating the rest of the array with null characters, in this case 12584 null characters following 17 characters in the name for a total of 12601 charcters.
so the code
   CHARACTER(KIND=C_CHAR)                    :: avcOUTNAME(p%avcOUTNAME_LEN)         ! OUTNAME (in: Simulation RootName; out: string for logging channels Name:Units;)
   avcOUTNAME  = TRANSFER( TRIM(dll_data%RootName)//C_NULL_CHAR,   avcOUTNAME, p%avcOUTNAME_LEN )

do i=1,p%avcOUTNAME_LEN
   if(avcOUTNAME(i) == C_NULL_CHAR)   cnt=cnt+1
enddo
print*,'avcOUTNAME: ',p%avcOUTNAME_LEN,' Null chars: ',cnt
write(CU,*) avcOUTNAME(1:p%avcOUTNAME_LEN)

produces:
 avcOUTNAME:        12601  Null chars:        12584
 LESinflow.T1.SrvD

[output truncated]


Exports: "Not cumulative" instead of "Non-cumulative"

Noticed that our English language IPTT exports are using an unexpected phrasing in the C/NC column -- "Not cumulative" in place of "Non-cumulative"
It looks fine in French and Spanish.

Fixed.


[5.2] Backport of "Fix integrity constraints for database session driver."

Do these things need fixing for this PR to be approved? Because some of these issues aren't connected to this PR.

Laravel 5.2 is not supported anymore.

OK cool, Does that mean PR's to this branch wont be considered anymore?


Introduction Review

Hi Nathan, could you review the Intro chapter?  it's a shorter one this time.  updated main pdf here
Thanks for all your help!
Also, @munkm

You bettcha, I'm just finishing up the results section now!

I received the pdf via slack, thanks!


Improvements to Fake Resolver

This change is

No significant performance differences

Performance differences noted:
Benchmark                    allocs_per_iteration    atm_add_per_iteration    atm_cas_per_iteration    cpu_time    locks_per_iteration    real_time    writes_per_iteration
---------------------------  ----------------------  -----------------------  -----------------------  ----------  ---------------------  -----------  ----------------------
BM_EmptyCore                                                                  0.999999046072                       1.0
BM_LameChannelCallCreateCpp                          12.0

No significant performance differences

No significant performance differences

This looks pretty good.  The only substantive issue is the one about simplifying the interface for the response generator.  Please let me know if you have any questions.

Reviewed 26 of 26 files at r1.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

src/core/ext/filters/client_channel/parse_address.c, line 65 at r1 (raw file):

#else /* GRPC_HAVE_UNIX_SOCKET */

int grpc_parse_unix(grpc_uri *uri, grpc_resolved_address *resolved_addr) {

This should have the same signature as the "real" version (return bool, first argument const).

src/core/lib/channel/channel_args.c, line 353 at r1 (raw file):

bool grpc_channel_arg_get_boolean(const grpc_arg *arg) {
  const grpc_integer_options options = {0, INT_MIN, INT_MAX};

Should we be a bit more strict with input for this type by requiring that the value be either 0 or 1?  Anything else would be treated as invalid and default to false.

test/core/end2end/fake_resolver.c, line 60 at r1 (raw file):

#define GRPC_ARG_FAKE_RESOLVER_LB_ENABLED "grpc.fake_resolver.lb_enabled"
#define GRPC_ARG_FAKE_RESOLVER_BALANCER_NAMES
"grpc.fake_resolver.balancer_names"

I don't think these two args should be necessary.
Recall that the resolver result is simply a set of channel args.  The grpc_fake_resolver_response_generator_set_response() method already takes a set of channel args as input.  Given that, I think it would make things a lot simpler to have the caller construct the exact set of channel args that we want the resolver to return, and then have the resolver simply return them as-is.  We can provide a helper function to make it easier to construct the right channel args, which would take lb_enabled and balancer_names as parameters, but we should not need to pass them in as channel args.

test/core/end2end/fake_resolver.c, line 73 at r1 (raw file):

grpc_channel_args* channel_args;
grpc_lb_addresses* addresses;

If you take my suggestion above about having the caller pass in the exact set of channel args to be returned by the resolver, then these fields are probably not necessary.  Instead, I think we just need this:
grpc_channel_args* result;

test/core/end2end/fake_resolver.c, line 77 at r1 (raw file):

  // mutex guarding the rest of the state
  gpr_mu mu;

It looks like this code wasn't completely updated when Craig changed the resolvers to run in the client_channel combiner lock.  I think it no longer needs its own mutex.

test/core/end2end/fake_resolver.c, line 263 at r1 (raw file):

    grpc_exec_ctx* exec_ctx,
    const grpc_fake_resolver_response_generator* response_generator,
    const grpc_uri* uri, const grpc_channel_args* args) {

If you take my suggestion above about having the caller pass in the exact set of channel args to be returned by the resolver, then there's no need for the uri parameter here, and the body of this function gets a lot simpler.  I think that all it needs to do is this:
r->published = false;
r->result = args;
fake_resolver_maybe_finish_next_locked(exec_ctx, r);

test/core/end2end/fake_resolver.c, line 267 at r1 (raw file):

  fake_resolver* r = response_generator->resolver;
  GPR_ASSERT(r != NULL);
  gpr_mu_lock(&r->mu);

As mentioned above, I think the fake resolver no longer needs its own mutex.  However, we will need to enter the combiner lock before we change any of the resolver's state.

test/core/end2end/fake_resolver.c, line 321 at r1 (raw file):

if (0 != strcmp(args->uri->authority, "")) {
gpr_log(GPR_ERROR, "authority based uri's not supported by the %s scheme",
args->uri->scheme);
return NULL;
}
grpc_lb_addresses* addresses =
build_addresses(exec_ctx, args->uri, args->args);
if (addresses == NULL) return NULL;

These checks are probably not necessary.

Comments from Reviewable

Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

src/core/lib/channel/channel_args.c, line 353 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Should we be a bit more strict with input for this type by requiring that the value be either 0 or 1?  Anything else would be treated as invalid and default to false.

FYI, looks like Craig just implemented something similar in #10449, so you can probably just steal his version from there.

Comments from Reviewable

Review status: 20 of 26 files reviewed at latest revision, 8 unresolved discussions.

src/core/ext/filters/client_channel/parse_address.c, line 65 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This should have the same signature as the "real" version (return bool, first argument const).

Done.

src/core/lib/channel/channel_args.c, line 353 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
FYI, looks like Craig just implemented something similar in #10449, so you can probably just steal his version from there.

Ah, nice. I don't that that function in this PR after all, now that the lb_enabled arg is gone.

test/core/end2end/fake_resolver.c, line 60 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

#define GRPC_ARG_FAKE_RESOLVER_LB_ENABLED "grpc.fake_resolver.lb_enabled"
#define GRPC_ARG_FAKE_RESOLVER_BALANCER_NAMES
"grpc.fake_resolver.balancer_names"

I don't think these two args should be necessary.
Recall that the resolver result is simply a set of channel args.  The grpc_fake_resolver_response_generator_set_response() method already takes a set of channel args as input.  Given that, I think it would make things a lot simpler to have the caller construct the exact set of channel args that we want the resolver to return, and then have the resolver simply return them as-is.  We can provide a helper function to make it easier to construct the right channel args, which would take lb_enabled and balancer_names as parameters, but we should not need to pass them in as channel args.

Done.

test/core/end2end/fake_resolver.c, line 73 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

grpc_channel_args* channel_args;
grpc_lb_addresses* addresses;

If you take my suggestion above about having the caller pass in the exact set of channel args to be returned by the resolver, then these fields are probably not necessary.  Instead, I think we just need this:
grpc_channel_args* result;

Done.

test/core/end2end/fake_resolver.c, line 77 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
It looks like this code wasn't completely updated when Craig changed the resolvers to run in the client_channel combiner lock.  I think it no longer needs its own mutex.

Done.

test/core/end2end/fake_resolver.c, line 263 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
If you take my suggestion above about having the caller pass in the exact set of channel args to be returned by the resolver, then there's no need for the uri parameter here, and the body of this function gets a lot simpler.  I think that all it needs to do is this:
r->published = false;
r->result = args;
fake_resolver_maybe_finish_next_locked(exec_ctx, r);

Done.

test/core/end2end/fake_resolver.c, line 267 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
As mentioned above, I think the fake resolver no longer needs its own mutex.  However, we will need to enter the combiner lock before we change any of the resolver's state.

Lock removed. In this particular test, I don't think we don't need to deal with the combiner lock because there's no threading involved. Otherwise, yes, both operations would have to live under the same combiner lock.
I've suffixed the set_response function with _locked to signal that it ought to be called from a locked context, same as the other relevant functions in the resolver.

test/core/end2end/fake_resolver.c, line 321 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

if (0 != strcmp(args->uri->authority, "")) {
gpr_log(GPR_ERROR, "authority based uri's not supported by the %s scheme",
args->uri->scheme);
return NULL;
}
grpc_lb_addresses* addresses =
build_addresses(exec_ctx, args->uri, args->args);
if (addresses == NULL) return NULL;

These checks are probably not necessary.

Done.

Comments from Reviewable

No significant performance differences

This looks really good.  Most of the remaining comments are minor.

Reviewed 6 of 6 files at r2.
Review status: all files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

test/core/client_channel/resolvers/fake_resolver_test.c, line 65 at r2 (raw file):

grpc_channel_args *channel_args =
grpc_channel_args_copy_and_add(NULL, &generator_arg, 1);

Could just say:
grpc_channel_args channel_args = {1, &generator_arg};

That way, there's no need to destroy it later.

test/core/client_channel/resolvers/fake_resolver_test.c, line 78 at r2 (raw file):

const grpc_arg *lb_addresses_arg =
grpc_channel_args_find(res->resolver_result, GRPC_ARG_LB_ADDRESSES);
GPR_ASSERT(lb_addresses_arg != NULL &&
lb_addresses_arg->type == GRPC_ARG_POINTER);
const grpc_lb_addresses *addresses = lb_addresses_arg->value.pointer.p;

const grpc_arg *expected_lb_addresses_arg = grpc_channel_args_find(
res->expected_resolver_result, GRPC_ARG_LB_ADDRESSES);
GPR_ASSERT(expected_lb_addresses_arg != NULL &&
expected_lb_addresses_arg->type == GRPC_ARG_POINTER);
const grpc_lb_addresses *expected_addresses =
expected_lb_addresses_arg->value.pointer.p;
GPR_ASSERT(grpc_lb_addresses_cmp(addresses, expected_addresses) == 0);

Couldn't this whole thing be replaced with a single call to grpc_channel_args_compare()?

test/core/client_channel/resolvers/fake_resolver_test.c, line 119 at r2 (raw file):

grpc_resolver_next_locked(&exec_ctx, resolver, &on_res_arg.resolver_result,
on_resolution);

Right after this, let's also call grpc_resolver_next_locked() a second time to make sure that the resolver does not invoke the callback when there's no new data to return.  (We'll probably need the callback to set a bit in on_res_arg to indicate whether it's been called.)

test/core/end2end/fake_resolver.c, line 267 at r1 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
Lock removed. In this particular test, I don't think we don't need to deal with the combiner lock because there's no threading involved. Otherwise, yes, both operations would have to live under the same combiner lock.
I've suffixed the set_response function with _locked to signal that it ought to be called from a locked context, same as the other relevant functions in the resolver.

The fake resolver is a general-purpose library, not something that's specific to this test.  I think people will wind up writing additional tests using this in the future, and it will be very surprising to them if this doesn't work right in a threaded environment.
Also, simply adding the _locked suffix to this function name doesn't really work, since there's no way the caller can invoke it from a place where they hold the combiner lock.  This function is fundamentally different than the resolver methods, because it's called by the application from outside of C-core.

test/core/end2end/fake_resolver.c, line 69 at r2 (raw file):

  grpc_resolver base;

  // passed-in parameters

This comment is out of date now.  Might want to say something about how this is the last data injected from the response generator.

test/core/end2end/fake_resolver.c, line 100 at r2 (raw file):

  if (r->next_completion != NULL && !r->published) {
    r->published = true;
    *r->target_result = grpc_channel_args_copy(r->results);

I think we can probably avoid copying it here, since we'll never return the same result twice.  In fact, we can probably also do without the published boolean -- instead, just move results to *target_result and then set results to NULL.

test/core/end2end/fake_resolver.h, line 72 at r2 (raw file):

grpc_channel_args* grpc_fake_resolver_response_create(
const char** uris, const char** balancer_names, const bool* is_balancer,
size_t num_items);

It seems a bit cumbersome to have three different arrays for this data.  There are two possible alternatives.  First, we can use a struct here, and then have an array of the struct.  Second, we could just pass in a grpc_lb_addresses struct, since we already have a bunch of helper functions for creating and populating that struct.

test/cpp/grpclb/grpclb_test.cc, line 583 at r2 (raw file):

  grpc_fake_resolver_balancer_names_arg(lb_server->balancer_name),
  grpc_fake_resolver_lb_enabled_arg()};

Looks like this test still needs to be updated for the changes in the fake resolver code.

Comments from Reviewable

No significant performance differences

Review status: 19 of 29 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

test/core/client_channel/resolvers/fake_resolver_test.c, line 65 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

grpc_channel_args *channel_args =
grpc_channel_args_copy_and_add(NULL, &generator_arg, 1);

Could just say:
grpc_channel_args channel_args = {1, &generator_arg};

That way, there's no need to destroy it later.

We only compare the addresses argument (the user of the fake resolver cannot inject all necessary arguments, such as the subchannel factory, see other comments). Still, this code has been simplified.

test/core/client_channel/resolvers/fake_resolver_test.c, line 119 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

grpc_resolver_next_locked(&exec_ctx, resolver, &on_res_arg.resolver_result,
on_resolution);

Right after this, let's also call grpc_resolver_next_locked() a second time to make sure that the resolver does not invoke the callback when there's no new data to return.  (We'll probably need the callback to set a bit in on_res_arg to indicate whether it's been called.)

Done, but at the end of the test. Otherwise it messes the flow of the test a little bit.

test/core/end2end/fake_resolver.c, line 267 at r1 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
The fake resolver is a general-purpose library, not something that's specific to this test.  I think people will wind up writing additional tests using this in the future, and it will be very surprising to them if this doesn't work right in a threaded environment.
Also, simply adding the _locked suffix to this function name doesn't really work, since there's no way the caller can invoke it from a place where they hold the combiner lock.  This function is fundamentally different than the resolver methods, because it's called by the application from outside of C-core.

Done. It took me a bit to fully grok combiners.

test/core/end2end/fake_resolver.c, line 69 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This comment is out of date now.  Might want to say something about how this is the last data injected from the response generator.

I've gone back to saving and using the channel args given at the time of fake resolver creation. Some arguments are only available deeper in the stack (subchannel factory). Others are just more conveniently populated by the runtime even if the user could potentially provide them (the server uri arg).

test/core/end2end/fake_resolver.c, line 100 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I think we can probably avoid copying it here, since we'll never return the same result twice.  In fact, we can probably also do without the published boolean -- instead, just move results to *target_result and then set results to NULL.

Done.

test/core/end2end/fake_resolver.h, line 72 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

grpc_channel_args* grpc_fake_resolver_response_create(
const char** uris, const char** balancer_names, const bool* is_balancer,
size_t num_items);

It seems a bit cumbersome to have three different arrays for this data.  There are two possible alternatives.  First, we can use a struct here, and then have an array of the struct.  Second, we could just pass in a grpc_lb_addresses struct, since we already have a bunch of helper functions for creating and populating that struct.

Done.

test/cpp/grpclb/grpclb_test.cc, line 583 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

  grpc_fake_resolver_balancer_names_arg(lb_server->balancer_name),
  grpc_fake_resolver_lb_enabled_arg()};

Looks like this test still needs to be updated for the changes in the fake resolver code.

Done.

Comments from Reviewable

Just a few issues remaining.

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

src/core/ext/filters/client_channel/lb_policy_factory.h, line 98 at r3 (raw file):

 * Returns true upon success, false otherwise. Takes ownership of \a
 * balancer_name. */
bool grpc_lb_addresses_set_uri(grpc_lb_addresses *addresses, size_t index,

Suggest calling this grpc_lb_addresses_set_address_from_uri().

src/core/ext/filters/client_channel/subchannel.c, line 801 at r3 (raw file):

if (strcmp(uri->scheme, "ipv4") == 0) {
GPR_ASSERT(grpc_parse_ipv4(uri, addr));
} else if (strcmp(uri->scheme, "ipv6") == 0) {
GPR_ASSERT(grpc_parse_ipv6(uri, addr));
} else {
GPR_ASSERT(grpc_parse_unix(uri, addr));
}

This can now be replaced with a call to grpc_parse_uri().

src/core/ext/transport/chttp2/client/insecure/channel_create.c, line 74 at r3 (raw file):

  grpc_arg arg;
  arg.type = GRPC_ARG_STRING;
  arg.key = gpr_strdup(GRPC_ARG_SERVER_URI);

Why add gpr_strdup() here?  This seems wrong, since the value is just going to be copied by grpc_channel_args_copy_and_add_and_remove() and then never referenced again.

test/core/client_channel/resolvers/fake_resolver_test.c, line 78 at r2 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
We only compare the addresses argument (the user of the fake resolver cannot inject all necessary arguments, such as the subchannel factory, see other comments). Still, this code has been simplified.

I see your point.  However, in principle, this seems insufficient, because the resolver can populate any channel args it wants to, not just GRPC_ARG_LB_ADDRESSES.  Hmm... would it make sense to instead filter out those individual args that we know can't be provided?
I could go either way on this one.  Your call.

test/core/client_channel/resolvers/fake_resolver_test.c, line 119 at r2 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
Done, but at the end of the test. Otherwise it messes the flow of the test a little bit.

I don't see this change.

test/core/client_channel/resolvers/fake_resolver_test.c, line 84 at r3 (raw file):

}

static void test_response_generator() {

Suggest just calling this test_fake_resolver().

test/core/end2end/fake_resolver.c, line 69 at r2 (raw file):
Previously, dgquintas (David G. Quintas) wrote…
I've gone back to saving and using the channel args given at the time of fake resolver creation. Some arguments are only available deeper in the stack (subchannel factory). Others are just more conveniently populated by the runtime even if the user could potentially provide them (the server uri arg).

Any args added by the subchannel code are not relevant here, since the args returned by the resolver are the ones given to the subchannel code as input.  But you're right about GRPC_ARG_SERVER_URI.
In principle, I'd prefer to see the full set of args populated via the response generator, since a resolver could potentially remove args as well as set them, and unconditionally merging the original args doesn't leave us with any way to do that.  Would it be reasonable to only copy GRPC_ARG_SERVER_URI from the original args?
I could go either way on this.  Your call.

test/cpp/grpclb/grpclb_test.cc, line 677 at r3 (raw file):

  gpr_log(GPR_INFO, "Server[%s] bye bye", sf->servers_hostport);
  gpr_free(sf->servers_hostport);
  // gpr_free(sf->balancer_name);

This can presumably be removed.

Comments from Reviewable

Performance differences noted:
Benchmark                                     allocs_per_iteration    atm_add_per_iteration    atm_cas_per_iteration      cpu_time  locks_per_iteration      real_time  writes_per_iteration
--------------------------------------------  ----------------------  -----------------------  -----------------------  ----------  ---------------------  -----------  ----------------------
BM_ClosureSchedOnExecCtx                                                                                +9.50                               +9.50
BM_ErrorHttpError<ErrorWithNestedGrpcStatus>                                                                                +31.50                              +31.50

Performance differences noted:
Benchmark                                                                allocs_per_iteration    atm_add_per_iteration    atm_cas_per_iteration      cpu_time  locks_per_iteration      real_time  writes_per_iteration
-----------------------------------------------------------------------  ----------------------  -----------------------  -----------------------  ----------  ---------------------  -----------  ----------------------
BM_Base16SomeStuff/64                                                                                -49.00                              -49.00
BM_HpackEncoderEncodeHeader<RepresentativeServerTrailingMetadata>/1/16k                                                                                -85.50                              -85.50
BM_IsolatedFilter<MessageSizeFilter, SendEmptyMetadata>                                                                                -11.00                              -11.00

Review status: 27 of 28 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

src/core/ext/filters/client_channel/lb_policy_factory.h, line 98 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Suggest calling this grpc_lb_addresses_set_address_from_uri().

Done.

src/core/ext/filters/client_channel/subchannel.c, line 801 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…

if (strcmp(uri->scheme, "ipv4") == 0) {
GPR_ASSERT(grpc_parse_ipv4(uri, addr));
} else if (strcmp(uri->scheme, "ipv6") == 0) {
GPR_ASSERT(grpc_parse_ipv6(uri, addr));
} else {
GPR_ASSERT(grpc_parse_unix(uri, addr));
}

This can now be replaced with a call to grpc_parse_uri().

Done.

test/core/client_channel/resolvers/fake_resolver_test.c, line 78 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I see your point.  However, in principle, this seems insufficient, because the resolver can populate any channel args it wants to, not just GRPC_ARG_LB_ADDRESSES.  Hmm... would it make sense to instead filter out those individual args that we know can't be provided?
I could go either way on this one.  Your call.

This is in the test code, so we know we've only set the address. I've added a comment pointing it out.

test/core/client_channel/resolvers/fake_resolver_test.c, line 119 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
I don't see this change.

Not sure why. I can see it on github. Refresh?

test/core/client_channel/resolvers/fake_resolver_test.c, line 84 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Suggest just calling this test_fake_resolver().

Done.

test/core/end2end/fake_resolver.c, line 69 at r2 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Any args added by the subchannel code are not relevant here, since the args returned by the resolver are the ones given to the subchannel code as input.  But you're right about GRPC_ARG_SERVER_URI.
In principle, I'd prefer to see the full set of args populated via the response generator, since a resolver could potentially remove args as well as set them, and unconditionally merging the original args doesn't leave us with any way to do that.  Would it be reasonable to only copy GRPC_ARG_SERVER_URI from the original args?
I could go either way on this.  Your call.

The problem happens in grpclb_test, where extra channel args are needed. For simple tests like fake_resolver_test, the test writer can provide everything. Not so in more complex ones like grpclb_test.

test/cpp/grpclb/grpclb_test.cc, line 677 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
This can presumably be removed.

no, this definitely needs to stay :) Done.

src/core/ext/transport/chttp2/client/insecure/channel_create.c, line 74 at r3 (raw file):
Previously, markdroth (Mark D. Roth) wrote…
Why add gpr_strdup() here?  This seems wrong, since the value is just going to be copied by grpc_channel_args_copy_and_add_and_remove() and then never referenced again.

This was a typo caught by tests. I don't know why reviewable is showing you this version. The github one is updated. Anyhow, I hope it's gone now.

Comments from Reviewable

No significant performance differences

Reviewed 1 of 2 files at r4, 5 of 5 files at r5.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

src/core/ext/filters/client_channel/subchannel.c, line 801 at r5 (raw file):

  grpc_uri *uri = grpc_uri_parse(exec_ctx, uri_str, 0 /* suppress_errors */);
  GPR_ASSERT(uri != NULL);
  if (!grpc_parse_uri(uri, addr)) memset(addr, 0, sizeof(*addr));

Why not GPR_ASSERT() here, like the original code was doing?


Subclass declared default overwriting constructor assignments using parent method

🔎 Search Terms
subclass default initial value replaced overwrote overwritten
🕗 Version & Regression Information

I was unable to test this on prior versions because I'm not very smart, i just found this bug

⏯ Playground Link
https://www.typescriptlang.org/play?#code/MYGwhgzhAECC0G8BQ1XTNAvNAjAbjWiRTWAHsA7CAFwCcBXYas2gCjFoHMIBKREwqmoALAJYQAdPQAOAEzDUApuy688A6AF9ihGfKWtptMtN79BaAGYtorclWrQA1ooCe0URWhGTZ5BYsRcQBtF1cAXSxvY1NQt3D1AMF7CDIQRQkQMk5WMIAaaCCIOIieRIDtQm1tJFBIGAAhaEUADyUKWRh4fzQAIyiAJnUNFLpGZjYObj4eiwgZRUnVMo1CAHo1wrFJPQVlKbUNauJR6H7sCkUAd2gG1gQzgC5oAGYC4GeXrRXaylT0zLZVgAciUNBwwIKvQk50w2BeKxSaQyWRyoMUNAGkLOEmAWDhrxWQA
💻 Code
import { assert, describe, it } from "vitest";

describe("typescript classes", () => {
  it.only("should overwrite default values", () => {
    class A {
      b = 1;
      c = 1;

      constructor(args) {
        this.update(args);
      }

      update(props) {
        for (const key in props) {
          this[key] = props[key];
        }
      }
    }

    class B extends A {
      b = 2;
      c = 2;

      constructor(args) {
        super(args);
        // this.update(args);
      }
    }

    const b = new B({ b: 3, c: 3 });
    assert.equal(b.b, 3);
    assert.equal(b.c, 3);
  });
});

🙁 Actual behavior
in my version (5.3.3), both are 2
🙂 Expected behavior
i would expect the properties b and c to be 3
Additional information about the issue
I'm just a fool who got bit by this, maybe i'm just doing something wrong

You can run this code in your browser console and see that b.b and b.c are both 2. This is JavaScript behavior; nothing to do with TypeScript here.

You are indeed correct, thank you for pointing it out to me


Refresh page, Sometimes when redirect, it will first redirect to the not found page

Describe the bug
Refresh page, Sometimes when redirect, it will first redirect to the not found page
To Reproduce
https://www.loom.com/share/eacec5fa356d4e2db77af5e3f31f86c1
Expected behavior
No response
Additional context
No response
Logs/tracebacks
No response

@aligo After the refresh there is still an intermediate process, a content-free background will exist for a few seconds

I'll follow this issue.


permissions/RBAC for using AzAPI terraform provider

Hi,
may i know what is the permissions/rbac required to run the provider?

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

ID: 027fca70-797d-1605-34ab-63df7f422da3
Version Independent ID: 027fca70-797d-1605-34ab-63df7f422da3
Content: Overview of the Terraform AzAPI provider
Content Source: articles/terraform/overview-azapi-provider.md
Service: terraform
GitHub Login: @TomArcherMsft
Microsoft Alias: tarcher

Hi @Equalitism - you might want to ask your question on the Microsoft Q&A site as well. Thanks!

@Equalitism Thanks for your feedback. The Quickstarts for AzAPI:

Quickstart: Deploy your first Azure resource with the AzAPI Terraform provider
Quickstart: Deploy your first Azure update resource with the AzAPI Terraform provider

If these links aren't sufficient, please open an issue against the product.
Thanks!


Update logic to 1.2.14

After making all changes to the cask:

[x] `brew cask audit --download {{cask_file}}` is error-free.
[x] `brew cask style --fix {{cask_file}}` left no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the contribution. It was merged directly as 1aa96170ead3e2bb659a240ac5087f78bc147540. Your contribution is still credited to you.


Content update - Attached events overview (user story 1878475)

@adegeo this ported article and code project are ready for your review. Internal preview
The Framework version of this article incorrectly distinguishes an attached event from a regular routed event. For example:

It states "The concept of an attached event enables you to add a handler for a particular event to an arbitrary element rather than to an element that actually defines or inherits the event." However, that definition is also applicable to non-attached routed events.
It implies that the qualified event name syntax <owner type>.<event name> is unique to attached events. However, that syntax is also applicable to non-attached routed events.

An attached event is distinguished from a routed event by its backing code. Both this article and the Routed Events Overview article conflate an attached event with the XAML syntax that attaches a handler for a regular routed event (with CLR wrapper) to an arbitrary tree element (i.e. not the event source). Attaching a handler for a regular routed event to an arbitrary tree element doesn't transform the routed event into an attached event.
The clearest difference between attached and non-attached events is that an attached event can be defined in a non-element class (e.g. the Mouse class). This is because the attached event backing code calls the UIElement.AddHandler and UIElement.RemoveHandler methods on a passed in UIElement instance. In contrast, the CLR wrapper for non-attached routed events calls those methods directly on the owning class, which requires the owning class to derive from UIElement. Perhaps there are other differences I'm not seeing.
This blog post, stackoverflow discussion, and my tests helped clarify the attached event concept for me. Apart from reworking the introduction and inserting a few clarifications, the rest of the article has minimal rework.

@adegeo, thanks for the review!


Opentelemetry context propagation

Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Is your feature request related to a problem? Please describe.
Would like to stitch together producer, consumer spans as well as subscriber acknowledgement of message and any processing leading up to the ack.
Describe the solution you'd like
Similar to what is described https://github.com/googleapis/nodejs-pubsub/issues/1389
Describe alternatives you've considered
Any alternative solutions or features you've considered.
Additional context
Any other context or screenshots about the feature request.

According to https://github.com/googleapis/nodejs-pubsub/issues/1389#issuecomment-908455893 this might already be in the works?

You might find this a more useful read: https://github.com/googleapis/google-cloud-go/pull/5034
My idea is to do something in pubsub-nodejs

You might find this a more useful read: googleapis/google-cloud-go#5034 My idea is to do something in pubsub-nodejs

Thanks @weyert! I posted this workaround for nodejs maybe it could help
I will try to come up with a similar code snippet for Java in the coming days

We are tracking OpenTelemetry support via a ticket in the public issue tracker since it is a cross-language request: issuetracker.google.com/183608476.


Wraps tests in IIFE.

This PR fixes #15790
The changes included in this PR are to fix our broken unit tests around scrollable views.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 41.509%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
26535

Relevant Lines:
57951

💛  - Coveralls


Create mdusd.txt

Adding MDUSD

@nikhilsharma5 The first verification stage is complete: the official domain for  Northgate High School is www.northgatehighschool.org, to the best of my knowledge. This is just an informational note. The pull request is still under review. The review may take some more time. I greatly appreciate your patience. Here is the proof of domain ownership: https://www.northgatehighschool.org/district

@nikhilsharma5 Thank you for your patience while waiting for a review and processing your request. Pull request merged.
Please start requesting the licenses in about an hour, to let the changes to propagate through our system.


feat: Adds image and instructions on how to get DevCard page

Description
This PR adds image and instructions on how to get DevCard page
What type of PR is this? (check all applicable)

[x] 🍕 Feature
[ ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents
Fixes https://github.com/open-sauced/docs/issues/222
Mobile & Desktop Screenshots/Recordings

Steps to QA
NA
Added to documentation?

[ ] 📜 README.md
[] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

Hi @Haimantika, well done. Thanks for working on this issue.
@BekahHW  is not currently available. She will review and give feedback once she is available.
Pending that time, I will tag other maintainers to review the PR.
@CBID2 and @adiati98, @Haimantika awaits your feedback. Thank you!

Hi @Haimantika, well done. Thanks for working on this issue.
@BekahHW is not currently available. She will review and give feedback once she is available.
Pending that time, I will tag other maintainers to review the PR.
@CBID2 and @adiati98, @Haimantika awaits your feedback. Thank you!

Thanks for pinging me @Lymah123! :) I just gave some feedback! :)

Hi @Haimantika, well done. Thanks for working on this issue.
@BekahHW is not currently available. She will review and give feedback once she is available.
Pending that time, I will tag other maintainers to review the PR.
@CBID2 and @adiati98, @Haimantika awaits your feedback. Thank you!

Thanks for pinging me @Lymah123! :) I just gave some feedback! :)

Thank you for the prompt response. @CBID2!

Hi @Haimantika, well done. Thanks for working on this issue.
@BekahHW is not currently available. She will review and give feedback once she is available.
Pending that time, I will tag other maintainers to review the PR.
@CBID2 and @adiati98, @Haimantika awaits your feedback. Thank you!

Thanks for pinging me @Lymah123! :) I just gave some feedback! :)

Thanks @CBID2 :D
I have hyperlinked the image in the third point, let me know if you want me to structure it differently.

@Haimantika thank you for the changes! I left some reviews here for you. 😊
Also, I run your branch locally, and the link to the image leads to "Page Not Found" as screen recording below:

I see in the "files changed" tab that .svg is unabled to render because it's an invalid image source.
I would love to have confirmation from @BekahHW if we should use .png instead for the image like other images in the static folder.
Once Bekah confirmed, let's use Bekah's image here as it already has good size and arrow pointing to the card. You can download Bekah's image on the issue by following these steps:

Right click on the image.
Click "Save image as..."
Save the image as get-dev-card.png.

Please let me know if you can't dowload it, so I can help you with it. Thanks!

Hi, thanks for the feedback. The image is not getting downloaded after multiple tries.

Apologies for just coming into this. I was off for Christmas and I'm trying to catch up.
Thanks everyone for the help.
@Haimantika, apologies for the confusion with the SVG v. png. Please save it as a png if that works. You'll need to generate the image yourself or save the image by right clicking and choosing save image as. From there, you'll add the image to the file path specific in the issue.

Thanks @BekahHW. @adiati98 I have accepted your change, let me know if anything else is needed from my end.


Corporate Liaison Issues

Description
The new map update has introduced some issues for the CL, mainly that their office is less functional than the previous one.

On round start, no items spawn in the fridge on the left, save for a medkit and a bottle of space cleaner.
None of the buttons in the office appear to do anything (I assume they're meant to close the shutters, but they don't).
The added soda fountain in the CL's office doesn't seem to work, or if it does, no glasses are given to fill with liquid.
The sink in the bathroom seems to be facing the wrong way (nitpick, not important at all)

Additional context
I'm unsure what is and isn't intentional, and I don't expect this to be fixed any time soon since it seems low priority, but it would be nice to have some of the functionality returned to the CL role (getting cash, alcohol, privacy shutters, etc.)

Fixed all of these except buttons for next update

Buttons still dont work?


Fixed log message to show remote network_id

Just made log message clear. Printing "proto" object does not even show remote network_id.

Coverage remained the same at 30.17% when pulling 3d3384abbd9c59cf66153d56d0436ffb6e42c8a8 on danielnovy:master into 7fba230eac4c04f5a42244cb33f783f973767701 on ethereum:master.

especially the if condition was wrong. it should be:
if network_id != self.config['eth'].get('network_id', proto.network_id):
            log.warn("invalid network id", remote_network_id=network_id,
                     expected_network_id=self.config['eth'].get('network_id', proto.network_id))
            raise eth_protocol.ETHProtocolError('wrong network_id')

output now is:
WARNING:eth.chainservice	invalid network id	expected_network_id=7 remote_network_id=0
pushed a working update.


Missing options in preferences

Please use the form below, leaving the prefilled data to help us. Thank you.
Page link: preferences
Document link: preferences-dialog.md
My Issue/Suggestion
In paragraph 6, the two bottom options on the dialog are missing, see screenshot.

@BartLuijtenMx Thank you for flagging this. Additional information regarding these options have been added to the document, as seen in this PR.


dev-only requirements.txt file

There are a few modules that are required at build or compile time but not at runtime. As such they shouldn't actually be deployed. We should write a separate requirements.txt including them.

kaitai-struct isnt needed at runtime, what else though

stuff like flake8, or libraries only used by tests (I don't think there are any like that right now, but we might want freezegun at some point)


Data Inaccuracy for the "Ash, Frost and Storm " Node

Hi
I noticed an issue with the data for the "Ash, Frost and Storm " Node. I suspect that it may have changed since the 3.22 release. Here's a worked example:
Dataset: LethalPrideSeeds.csv
Seed: 11894
Summary of  "Double Damage" nodes:

Notable
Effect

Ash Frost and Storm
+_double_damage

Blacksmiths Clout
+_double_damage

Blunt Trauma
+_double_damage

Dervish
+_double_damage

Golem Commander
+_double_damage

Potent Connections
+_double_damage

Prismatic Skin
+_double_damage

Ribcage Crusher
+_double_damage

Throatseeker
+_double_damage

Totemic Zeal
+_double_damage

In-game Nodes:

Ash, Frost and Storm - +20 Strength
Potent Connections  - Double Damage
Totemic Zeal - Double Damage

You can also see the in-game nodes in this tool:
https://vilsol.github.io/timeless-jewels/tree?jewel=2&conqueror=Akoya&seed=11894&location=6230&mode=seed

Hey, thanks for the info. It is solved now in latest CSVs.


List of EpiDoc projects

Some of you may have seen the recent call on the MARKUP list for info on projects using EpiDoc. Do you agree that DHARMA should be added to that list?
The information they call for is concise:
title - host institution or location
Documentation (URL):
Source files (URL):
Publications:
and the list-in-progress, with just a few items as yet, is here: https://sourceforge.net/p/epidoc/wiki/Examples/
Given the examples already on the list, multiple links for each of the above categories may be given, e.g. for documentation we can list the EGD, TG, possibly the ZG, and so on. If you'd like me to, I can start compiling the items to add here, but I'm not sure exactly what and how much of our work should be made public at this stage, so please help with suggestions. I'm especially unsure what, if anything, should be mentioned as a publication, about which the original email says, "Publications should be focussed on the markup and project descriptions".

Thanks, Dan!
Arlo already circulated the information to Axelle and myself.
Axelle will take care of this and she will also clean the readme-s on github.
Axelle had a query (not yet answered by Arlo) about the inclusion of the Campa and EIAD projects on the same page.
Let us compile in the present issue the items to be included ??
Documentation: EGD, TG, possibly the ZG, and so on ...
Source files:
Publications:

I see for the moment no publication "focussed on the markup and project descriptions" to be included.

Thanks, Dan!
Arlo already circulated the information to Axelle and myself.
Axelle will take care of this and she will also clean the readme-s on github.
Axelle had a query (not yet answered by Arlo) about the inclusion of the Campa and EIAD projects on the same page.
Let us compile in the present issue the items to be included ??
Documentation: EGD, TG, possibly the ZG, and so on ...
Source files:
Publications:

I see for the moment no publication "focussed on the markup and project descriptions" to be included.

Thanks and sorry for being slow rto answer: in my view, EIAD and Campā should not be mentioned as they will intregrate DHARMA and are not documented in any way.
Le 25 janv. 2021 à 10:17, manufrancis <notifications<EMAIL_ADDRESS>a écrit :
Thanks, Dan!
Arlo already circulated the information to Axelle and myself.
Axelle will take care of this and she will also clean the readme-s on github.
Axelle had a query (not yet answered by Arlo) about the inclusion of the Campa and EIAD projects on the same page.
Let us compile in the present issue the items to be included ??
Documentation: EGD, TG, possibly the ZG, and so on ...
Source files:
Publications:
I see for the moment no publication "focussed on the markup and project descriptions" to be included.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/erc-dharma/project-documentation/issues/111#issuecomment-766672604, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGMAE6RUTEHWFZG3OXEBKTS3UZK5ANCNFSM4WOVW6OQ.

Thanks and sorry for being slow rto answer: in my view, EIAD and Campā should not be mentioned as they will intregrate DHARMA and are not documented in any way.
Le 25 janv. 2021 à 10:17, manufrancis <notifications<EMAIL_ADDRESS>a écrit :
Thanks, Dan!
Arlo already circulated the information to Axelle and myself.
Axelle will take care of this and she will also clean the readme-s on github.
Axelle had a query (not yet answered by Arlo) about the inclusion of the Campa and EIAD projects on the same page.
Let us compile in the present issue the items to be included ??
Documentation: EGD, TG, possibly the ZG, and so on ...
Source files:
Publications:
I see for the moment no publication "focussed on the markup and project descriptions" to be included.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/erc-dharma/project-documentation/issues/111#issuecomment-766672604, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGMAE6RUTEHWFZG3OXEBKTS3UZK5ANCNFSM4WOVW6OQ.

@danbalogh about your questions regarding what we should made public, I was thinking we should only provide links to what has been official shared for the guide, and so rather than sharing the current google Docs links, I guess we could provide the link EGD version 1 in project-documentation repository.

@danbalogh about your questions regarding what we should made public, I was thinking we should only provide links to what has been official shared for the guide, and so rather than sharing the current google Docs links, I guess we could provide the link EGD version 1 in project-documentation repository.

I also think it's better if the Documentation link is to the published guides deposited on HAL. Am I right to think that if we share a link to, for instance, EGD v1, and subsequently issue EGD v2, we will not need to update the link, i.e. that the original link will take the user to a page where both v1 and v2 are shown?

I also think it's better if the Documentation link is to the published guides deposited on HAL. Am I right to think that if we share a link to, for instance, EGD v1, and subsequently issue EGD v2, we will not need to update the link, i.e. that the original link will take the user to a page where both v1 and v2 are shown?

We can provide the HAL without the suffix version, when done it directs people by default to the latest version of a document.
So https://hal.archives-ouvertes.fr/DHARMA/halshs-02272407 would be the equivalent of https://hal.archives-ouvertes.fr/DHARMA/halshs-02272407v3.

We can provide the HAL without the suffix version, when done it directs people by default to the latest version of a document.
So https://hal.archives-ouvertes.fr/DHARMA/halshs-02272407 would be the equivalent of https://hal.archives-ouvertes.fr/DHARMA/halshs-02272407v3.

Thanks, this sounds good.

Thanks, this sounds good.

Has anything been submitted to the EpiDoc folks about DHARMA? I do not see our project listed as yet under https://sourceforge.net/p/epidoc/wiki/Examples/

All the cleaning for it has been done, but I understood you would be the one making the submission. Am I wrong?

Since Manu above said, "Axelle will take care of this and she will also clean the readme-s on github.", I thought you two had discussed this.

Dear Dan, my mistake ; -)
Could you please email the EpiDoc folks?
Maybe you can share the following link with them: https://erc-dharma.github.io/ ?
Axelle has added links towards the project documentation in the top menu.

Done. It seems that this overview page eliminates the need to give separate links to files and documentation, so I've just sent them this:
title - project DHARMA (ERC 809994) – Paris, Berlin and Naples
Documentation and Source files: https://erc-dharma.github.io/
Publications: none concerning the project as a whole

Thanks

Thanks both Dan and Axelle !


Incorrect error message XGROUP_GROUP_NOT_FOUND_MSG

Describe the bug
In fakeredis/_msgs.py, the message XGROUP_GROUP_NOT_FOUND_MSG uses %s  for substitution placeholders. But that's not the  right syntax for .format, which uses curly braces. The %s don't get replaced:
redis.exceptions.ResponseError: NOGROUP No such consumer group '%s' for key name '%s'

I would say that the fix is XGROUP_GROUP_NOT_FOUND_MSG = "NOGROUP No such consumer group '{1}' for key name '{0}'", and do a pull request but with that change:
redis.exceptions.ResponseError: NOGROUP No such consumer group 'b'nonexistent_group'' for key name 'b'foo''

It's still not quite right because the objects passed to the formatter are bytes, not str.
Anyway you might not like my quick fix: maybe you want to pass the parameters in the order they appear in the message, so that it's {} {} rather than {1} {0}, or maybe you want to name them. There are no other messages in that file with substitution placeholders in "the wrong order" for me to copy the style.
To Reproduce
import asyncio
import fakeredis.aioredis

async def main():
    async with fakeredis.aioredis.FakeRedis(decode_responses=True, version=6) as client:
        await client.xadd(name='foo', fields={'message': 'bar'})
        await client.xreadgroup('nonexistent_group', 'some_consumer', {'foo': '>'}, count=1)

if __name__ == '__main__':
    asyncio.run(main())

Traceback probably isn't very relevant, but since the template asks for it...
Traceback (most recent call last):
  File "fake_bug.py", line 11, in <module>
    asyncio.run(main())
  File "Lib\asyncio\runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "Lib\asyncio\runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "Lib\asyncio\base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "fake_bug.py", line 8, in main
    await client.xreadgroup('nonexistent_group', 'some_consumer', {'foo': '>'}, count=1)
  File "Lib\site-packages\redis\asyncio\client.py", line 518, in execute_command
    return await conn.retry.call_with_retry(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "Lib\site-packages\redis\asyncio\retry.py", line 59, in call_with_retry
    return await do()
           ^^^^^^^^^^
  File "Lib\site-packages\redis\asyncio\client.py", line 492, in _send_command_parse_response
    return await self.parse_response(conn, command_name, **options)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "Lib\site-packages\redis\asyncio\client.py", line 539, in parse_response
    response = await connection.read_response()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "Lib\site-packages\fakeredis\aioredis.py", line 156, in read_response
    raise response
redis.exceptions.ResponseError: NOGROUP No such consumer group '%s' for key name '%s'

Expected behavior
redis.exceptions.ResponseError: NOGROUP No such consumer group 'nonexistent_group' for key name 'foo'

or similar.
Desktop (please complete the following information):

OS: Windows 10
python version: 3.11.4
redis-py version: 4.6.0
full requirements.txt? n/a

Hi, would you want to create a PR with the fix and a test for this?

Also the terms of my employer's copyright waiver for open source contributions are such that it's best if I use my personal laptop to make the change, and that in turn means I'll be logged in using a different github user name (this is my work account because I found the issue while working). Sorry for any confusion, it's just technically if I use work resources to write the code, they own the copyright on 10 lines of your project. I don't even know the internal process I have to go through to release those lines under an open source license, so it's best if I own them.

All contributions and contributors are mentioned in the release notes, and anyone can track them through PRs/commits. With that said, any contribution to this package is under the BSD3 license - so you can't "own" lines of code.
I think your company should go through the process of identifying open-source packages it uses and whether it wants to support/contribute to open-source projects or not. It is ok if not, though it will not encourage me to prioritize this bug.

They're not intentionally obstructing me, they just don't have a general policy. It makes sense for them not to authorise me to release their entire codebase under BSD, not so much for them not to authorise me to write and release one test. I agree that ideally they should do the work to produce a policy, but as things stand I'd have to get case-by-case approval for the company to contribute code to open source projects. It's hassle, so I'd rather just make absolutely sure of the difference between stuff they own that I can't give away, and stuff I own that I can.


[BUG] - Recent updates to theme cause issues for JupyterHub

Describe the bug
The 2023.1.1 release of the nebari-jupyterhub-theme causes problems for jupyterhub trying to spawn.
Expected behavior
Jupyterhub should spin up without any issues.
How to Reproduce the problem?
Deploy nebari with the image tag for jupyterhub set to 2023.1.1.
Command output
Loading /usr/local/etc/jupyterhub/secret/values.yaml
No config at /usr/local/etc/jupyterhub/existing-secret/values.yaml
Loading extra config: 01-theme.py
Loading extra config: 02-spawner.py
Loading extra config: 03-profiles.py
[I 2023-01-31 23:39:11.990 JupyterHub app:2479] Running JupyterHub version 1.5.0
[I 2023-01-31 23:39:11.990 JupyterHub app:2509] Using Authenticator: oauthenticator.generic.GenericOAuthenticator-14.1.0
[I 2023-01-31 23:39:11.990 JupyterHub app:2509] Using Spawner: cdsdashboards.hubextension.spawners.variablekube.VariableKubeSpawner-0.6.3
[I 2023-01-31 23:39:11.990 JupyterHub app:2509] Using Proxy: jupyterhub.proxy.ConfigurableHTTPProxy-1.5.0
[E 2023-01-31 23:39:12.002 JupyterHub app:2989]
    Traceback (most recent call last):
      File "/opt/conda/lib/python3.9/site-packages/jupyterhub/app.py", line 2986, in launch_instance_async
        await self.initialize(argv)
      File "/opt/conda/lib/python3.9/site-packages/jupyterhub/app.py", line 2521, in initialize
        self.init_db()
      File "/opt/conda/lib/python3.9/site-packages/jupyterhub/app.py", line 1723, in init_db
        dbutil.upgrade_if_needed(self.db_url, log=self.log)
      File "/opt/conda/lib/python3.9/site-packages/jupyterhub/dbutil.py", line 112, in upgrade_if_needed
        orm.check_db_revision(engine)
      File "/opt/conda/lib/python3.9/site-packages/jupyterhub/orm.py", line 811, in check_db_revision
        alembic_revision = engine.execute(
    AttributeError: 'Engine' object has no attribute 'execute'

Stream closed EOF for dev/hub-8c4d6f865-8cxqn (hub)

Versions and dependencies used.
No response
Anything else?
No response

@trallard I ran into this issue when I was testing the most recent changes to the nebari-jupyterhub-theme==2023.1.1. Unfortunately I don't have time to resolve this issue today ahead of the release so I have pinned the theme version to the previously working version for now: https://github.com/nebari-dev/nebari-docker-images/pull/48

This appears to be due to a recent sqlalchemy release:  https://github.com/sqlalchemy/sqlalchemy/releases/tag/rel_2_0_0

Closed by: https://github.com/nebari-dev/nebari-docker-images/pull/49


need way to test bleeding_edge pkgs

it's really hard to try out bleeding_edge pkgs right now... there's no way to point Pub at file paths without changing every pubspec transitively. This is becoming impractical with our large number of pkgs in polymer.
is this something we can fix in Pub, the SDK, both? neither?

This issue has been moved to dart-lang/pub#613.


👋 How enable red outline error boxes like ST3???

Tell me how to enable this error display style

@alexdima Thank you for paying attention to my request.

sad


Crit pep

Sorry, but last commit drop capability!
Critical!
Fixed it.

Includes PEP for iOS/macOS support.

This is why it wasn't working on my iOS devices 👍

@englercj @bigtimebuddy Crit!

Deployed.


Reduce size

[x] I have searched the issues of this repo and believe that this is not a duplicate

OS version and name: Mac OS X 10.12.1

Serverless.app version: 0.0.5

Issue
Right now the dashboard is roughly 50mb in total size (the previous version was more than 100mb when I uninstalled it).

Electron apps are basically 100mb in size as the base vanilla app :P Not much I can do this shrink that.
I will checkout the rest of what is packaged and see if we can get it down


Fix flavor matching in dotenv.gradle

getCurrentFlavor is returning flavor in lower case but loadDotEnv just compare flavor with the key in envConfigFiles directly
Example:
If the flavor named as tempRelease, getCurrentFlavor will return temprelease and the comparison will be failed

@booker-dragon do you have any problem reading from .env?
For example, when using multiple flavors I can read from staging and production
project.ext.envConfigFiles = [
development: ".env",
production: ".env.production",
staging: ".env.staging",
]
But when runing in development flavor, it doesnt read from .env


Application panicked impl From

Aim
Implement From for structure:
 struct A {
    data: u8
}

impl From<u8> for A {
    fn from(data: u8) -> A {
        A{data}
    }
}

fn main() {
    let _: A = Into::into(3);
}

Expected Behavior
Implement from for a structure and then allow to use into.
Bug
The application panicked (crashed).
Message:  internal error: entered unreachable code: Failed to find trait impl during monomorphization. The failed constraint(s) are:
A: From
Location: compiler/noirc_frontend/src/monomorphization/mod.rs:1022
To Reproduce

Project Impact
Blocker
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
No response
Installation Method
Binary (noirup default)
Nargo Version
nargo version = 0.26.0 noirc version = 0.26.0+c46b164ce56e6a8f81255fb17eb6539bd040f336
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

This doesn't panic for me on master. We should perhaps be automatically casting 3 into a u8 but there's existing issues open for this.
$ nargo compile
error: No matching impl found for `A: From<Field>`
   ┌─ /home/tom/Programming/aztec/noir/temp/src/main.nr:12:16
   │
12 │     let _: A = Into::into(3);
   │                ---------- No impl for `A: From<Field>`
   │
   = Required by `Field: Into<A>`

Aborting due to 1 previous error


This is open source, read the code. You can simply not open it, it's fine.

yes fair enough i guess but i have no clue about code and i just want my silly little skins to work in my sily little game :(

it is just a false positive. im using this skin changer for almost a month and nothing happened. just allow it through your antivirus and it will run smoothly.
now its your choice

That is a false positive. The skin changer as well as the injector uses some Win32 API's that aren't commonly used in normal programs. The project is open-source, so you are welcome to compile the skin changer on your own, otherwise disable your antivirus and add the folder with the binaries to the exclusion list.


logs: strip properly

Codecov Report

Merging #34 into master will increase coverage by 0.07%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #34      +/-   ##
==========================================
+ Coverage   56.58%   56.66%   +0.07%
==========================================
  Files          12       12
  Lines        1693     1696       +3
==========================================
+ Hits          958      961       +3
  Misses        629      629
  Partials      106      106

Impacted Files
Coverage Δ

pkg/api/log.go
77.19% <100%> (+1.26%)
:arrow_up:

Continue to review full report at Codecov.

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


Instance.HideLoading()  not HIDE  in IOS

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

[*] iOS
[] Android
[] UWP
[] NET Standard 2.0

Version of OS(s) listed above with issue (if android - please include version of Xamarin.Android.Support.* you are using)
(from .csproj)

IOS Versión [12.1]

Version of ACR UserDialogs Library
Versión 7.04
Expected Behaviour
Firts, ALLAN , thank you the Library  👍 👍
The Issue is IN IOS the call to " UserDialogs.Instance.HideLoading();" not HIDE the alert
In Android Work Properly 👍
In IOS the Alert NOT DISAPERING :-(
Actual Behavior
If applicable, please include entire exception - type, message, stacktrace
Code of Conduct
** NOTE 1 In service are ine error (Json incorrect, for example)
** NOTE 2 IN IOS the ALERT NO DISAPEARING
View: (MainView)
(press button)
async private void EnergyPrices_Clicked(object sender, EventArgs e)
{
using (UserDialogs.Instance.Loading(ResourcesRespond.UI_HOMETAB_RECOVERING_FROM_SERVER))
{
await Task.Delay(100);
await Navigation.PushAsync(new EnergyPrices()); // OK
}
}
View: (EnergyPrices.cs)
public EnergyPrices () // ctor
{
InitializeComponent ();
BindingContext = ViewModelLocator.Instance.Resolve();
}
ViewModel:
public EnergyPricesViewModel(IEnergyPricesServices energyPricesServices, ILogActions logActions)  // ctor
    {
        _energyPricesServices = energyPricesServices;
        _energyPriceValues = new ObservableCollection<GridEnergyPrices>();
        _logActions = logActions;
        _itemError = null;
        this.GetEnergyPrice();
}

    private  void GetEnergyPrice()
    {
        List<CDM> _energyPrice = new List<CDM>();
        titleerror = ResourcesRespond.UI_ERROR_ENERGYPRICES_TITLE;
        message = ResourcesRespond.UI_ERROR_ENERGYPRICES_ERROR;
        Task t = Task.Run(async  () => {
            try
            {
                _energyPrice = await _energyPricesServices.GetEnergyPrice();  // **NOTE 1
            }
            catch (Exception ex) // ¿Problemas con la serializacion?
            {
                messageDev = $"Error :";
                _itemError = new LogItemError() { Message = ex.Message, Title = titleerror };

#if (!DEBUG)
message = messageDev;
#endif
}
});
t.Wait();
        if (_itemError != null)
        {

                UserDialogs.Instance.HideLoading();  // ** NOTE 2
                UserDialogs.Instance.Alert(message, titleerror, ResourcesRespond.UI_DISPLAYALERT_OK);
                _logActions.InsertErrorLog(new LogItemError { Message = _itemError.Message, Title = _itemError.Title });
        }

// Bla bla
// bla bla
// Process _energyPrice for View
//
}

HideLoading has no effect on Loading.  It is the composite method to ShowLoading.
using (UserDialogs.Instance.Loading(...))
{
}

I see a navigation within your loading call which is not supported - see point #3 in https://github.com/aritchie/userdialogs/blob/master/docs/faq.md

Thanks Allan, I'll make the code changes.
My mistake was that Android works as I expected and not in IOS.
Thank you for the quick response.

Hi Allan:
As the issue is closed (I don't want to open another one), but I want to say how it solves the problem.
Simply moving then “Binding” from “Constructor”  to  “On Appering”
**NO
namespace Respond.Portable.Views.EnergyPrices
{
[XamlCompilation(XamlCompilationOptions.Compile)]
public partial class EnergyPrices : ContentPage
{
public EnergyPrices ()
{
InitializeComponent ();
this.slideView.Commands.Add(new CustomSlideViewCommand());
BindingContext = ViewModelLocator.Instance.Resolve();
}
}
}
** YES
namespace Respond.Portable.Views.EnergyPrices
{
[XamlCompilation(XamlCompilationOptions.Compile)]
public partial class EnergyPrices : ContentPage
{
public EnergyPrices ()
{
InitializeComponent ();
this.slideView.Commands.Add(new CustomSlideViewCommand());
}
protected override void OnAppearing()
{
base.OnAppearing();
BindingContext = ViewModelLocator.Instance.Resolve();
}
}
}
The call to View.
async private void EnergyPrices_Clicked(object sender, EventArgs e)
{
using (UserDialogs.Instance.Loading (ResourcesRespond.UI_HOMETAB_RECOVERING_FROM_SERVER))
{
await Task.Delay(100);
await Navigation.PushAsync(new EnergyPrices()); // OK
}
}
Thank.
Ignacio
De: Allan Ritchie<EMAIL_ADDRESS>Enviado el: miércoles, 22 de mayo de 2019 2:30
Para: aritchie/userdialogs<EMAIL_ADDRESS>CC: Ignacio Lakidain<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Asunto: Re: [aritchie/userdialogs] Instance.HideLoading() not HIDE in IOS (#613)
Closed #613https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faritchie%2Fuserdialogs%2Fissues%2F613&data=02|01||c098cb1d106447917a5b08d6de4c8f60|62f653bf9c21465bbdbf1b18ba164624|0|0|636940818161200509&sdata=JOSCc%2BqOkhwk7klz0Hjr0W1FQ26tXUftC21eYHUykdo%3D&reserved=0.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Faritchie%2Fuserdialogs%2Fissues%2F613%3Femail_source%3Dnotifications%26email_token%3DAHTBANCAIMCEALPRDHKU5Y3PWSHWVA5CNFSM4HOKABO2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGORSEQPYI%23event-2357790689&data=02|01||c098cb1d106447917a5b08d6de4c8f60|62f653bf9c21465bbdbf1b18ba164624|0|0|636940818161200509&sdata=Hvpj4qTwDULNxcPbqAp%2BRnHCEyHBqgtEmOMnk0bDpas%3D&reserved=0, or mute the threadhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAHTBANCBBF3DEMSDVPPTFT3PWSHWVANCNFSM4HOKABOQ&data=02|01||c098cb1d106447917a5b08d6de4c8f60|62f653bf9c21465bbdbf1b18ba164624|0|0|636940818161200509&sdata=%2BbmUZ9R1Ss0Z%2BjI%2BCutiYE%2FVVf04IrUbCObmMGwnTgo%3D&reserved=0.


Hydration error in local dev env when Next.js website loads

Here's the error

Happens in website
Suspecting Material UI and styled-components doesn't work with the latest Next. I think I've seen an article about that. Switching to emotion might help. FYI, dashboard was set up to have MUI with styled-components. That could be changed, too, it doesn't really matter too much at this point.
react-dom.development.js?3c4a:29840 Download the React DevTools for a better development experience: https://reactjs.org/link/react-devtools
next-dev.js?36dd:20 Warning: Prop `className` did not match. Server: "MuiBox-root css-1bfdwoj" Client: "sc-gsnTZi gNgodm MuiBox-root"
    at div
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at Box (webpack-internal:///../../node_modules/@mui/system/esm/createBox.js:35:72)
    at div
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at Toolbar (webpack-internal:///../../node_modules/@mui/material/esm/Toolbar/Toolbar.js:69:82)
    at div
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at Container (webpack-internal:///../../node_modules/@mui/system/esm/Container/createContainer.js:121:19)
    at header
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at Paper (webpack-internal:///../../node_modules/@mui/material/esm/Paper/Paper.js:93:82)
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at AppBar (webpack-internal:///../../node_modules/@mui/material/esm/AppBar/AppBar.js:127:83)
    at TopNavigationComponent (webpack-internal:///./components/TopNavigation/TopNavigation.component.tsx:29:88)
    at div
    at O (webpack-internal:///../../node_modules/styled-components/dist/styled-components.browser.esm.js:31:19811)
    at Container (webpack-internal:///../../node_modules/@mui/system/esm/Container/createContainer.js:121:19)
    at Index
    at InnerThemeProvider (webpack-internal:///../../node_modules/@mui/system/esm/ThemeProvider/ThemeProvider.js:21:70)
    at ThemeProvider (webpack-internal:///../../node_modules/@mui/private-theming/ThemeProvider/ThemeProvider.js:47:5)
    at ThemeProvider (webpack-internal:///../../node_modules/@mui/system/esm/ThemeProvider/ThemeProvider.js:41:5)
    at MyApp (webpack-internal:///./pages/_app.tsx:33:11)
    at ErrorBoundary (webpack-internal:///../../node_modules/next/dist/compiled/@next/react-dev-overlay/dist/client.js:2:3209)
    at ReactDevOverlay (webpack-internal:///../../node_modules/next/dist/compiled/@next/react-dev-overlay/dist/client.js:2:6089)
    at Container (webpack-internal:///../../node_modules/next/dist/client/index.js:57:1)
    at AppContainer (webpack-internal:///../../node_modules/next/dist/client/index.js:170:11)
    at Root (webpack-internal:///../../node_modules/next/dist/client/index.js:337:11)

See more info here: https://nextjs.org/docs/messages/react-hydration-error
window.console.error @ next-dev.js?36dd:20
printWarning @ react-dom.development.js?3c4a:86
error @ react-dom.development.js?3c4a:60
warnForPropDifference @ react-dom.development.js?3c4a:9571
diffHydratedProperties @ react-dom.development.js?3c4a:10414
hydrateInstance @ react-dom.development.js?3c4a:11306
prepareToHydrateHostInstance @ react-dom.development.js?3c4a:12564
completeWork @ react-dom.development.js?3c4a:22181
completeUnitOfWork @ react-dom.development.js?3c4a:26596
performUnitOfWork @ react-dom.development.js?3c4a:26568
workLoopSync @ react-dom.development.js?3c4a:26466
renderRootSync @ react-dom.development.js?3c4a:26434
performConcurrentWorkOnRoot @ react-dom.development.js?3c4a:25738
workLoop @ scheduler.development.js?ba31:266
flushWork @ scheduler.development.js?ba31:239
performWorkUntilDeadline @ scheduler.development.js?ba31:533

So far, what I have tried:

Removing withNX in next.config.js
Replacing Next MUI v5 implementation code from a couple of example repos
Downgraded Next to 12
Downgraded React to 17
Removed @mui/styled-engine

Of course each time rm -rf node_modules && rm -rf yarn.lock && rm -rf apps/website/.next
🤪 Most wtf part is that if I remove code block by block, the error shifts up in the DOM. This suggests it's some configuration issue still.
If this is still going to be a big issue, we can switch to styled-components on the website part, since I suspect this would give us much more flexibility in terms of design variations.
If someone knows what could be causing this weird issue, let's fix it, if not - no problem to switch to plain styled-components.


Create ext-sd_wan

Relevant information
Creating a new class of entities for network sd-wan appliances.  There is still limited data available from customers on these so we will likely be coming back in later to define golden metrics, for now just getting the basics for the entities in the UI.
Checklist

[x] I've read the guidelines and understand the acceptance criteria.
[x] The value of the attribute marked as identifier will be unique and valid.
[x] I've confirmed that my entity type wasn't already defined. If it is I'm providing an
explanation above.

Blocking this with #743 so the build is fixed but otherwise LGTM


no-unsafe-any: Clean up documentation and implementation

PR checklist

[X] Addresses an existing issue: #2127
[ ] New feature, bugfix, or enhancement

[ ] Includes tests

[X] Documentation update

Overview of change:
Cleaned up noUnsafeAnyRule.ts.

@andy-hanson thanks!


 Also you have to place and break mud blocks to get mud balls.

It's a feature bruh :p


Reverse dependencies (--query --referrers)

Hi!
Thank you for developing this tool!
I was wondering if it is feasible to include a way to inspect reverse dependencies? Specifially, I was thinking about a way to add information obtained from nix-store --query --referrers. I need this command quite often, and it is very long (and hard to remember).
Thanks for you input!
Dominik

looks like this can be done with nix-store -q --referrers <store path> (or --referrers-closure)


Add PPNV endpoints to Humans

add PPNV Service

Please use an appropriate PR title like "Add PPNV endpoints to Humans"

Please use an appropriate PR title like "Add PPNV endpoints to Humans"

done


Add support for overriding the markdown-it options

This commit overrides the markdown option with a configuration
object.
Fixes #66
Sorry for the reformatting - perhaps we should add a .prettierrc config as well?

Update the PR with a new implementation - please let me know what you think!

@selbekk Great! I'm going to take a look again this weekend. Thanks for your generous cooperation. One thing I can say by overlooking your changes: It'll be great if we have tests for each case 😉 (you can leave that for me, I'm happy to add by myself to confirm the behavior properly)

For sure! :-) It's been fun contributing - thanks for creating a really great library!


torch.nn.TopK is not support

Hello,The TopK operator is used in the model I want to deploy. I checked the document(https://docs.xilinx.com/r/en-US/ug1414-vitis-ai/Operators-Supported-by-PyTorch) and said TopK is not supported. If I want to use Vitis AI,what should I do?

you can use graph runner mode by implementing your own customer op of topk;
please refer to the https://docs.xilinx.com/r/en-US/ug1414-vitis-ai/Custom-OP-Workflow part for detail.
you can implementation your own logic of topk in post process part.  You can search by "grep -i topk vai_src_tree/ -R " and find lots of topk function in current vai source code.

you can use graph runner mode by implementing your own customer op of topk;
please refer to the https://docs.xilinx.com/r/en-US/ug1414-vitis-ai/Custom-OP-Workflow part for detail.
you can implementation your own logic of topk in post process part.  You can search by "grep -i topk vai_src_tree/ -R " and find lots of topk function in current vai source code.

Thank you, I have read the code about TopK in  src/vai_library/cpu_task/ops/topk/topk.cpp, but I found a small error in the provided code during verification. When I  modified this error, the verification was correct. Can I submit a PR to correct this error?

you can paste your fix here and I'll check it.  thanks.

hello，This is my modified code，I just modified one line
https://github.com/zyt1024/Vitis-AI/commit/4af2ac44f85445f1965ab6630074f865fb038049

hello，This is my modified code，I just modified one line
zyt1024@4af2ac4
hello，This is my modified code，I just modified one line
https://github.com/zyt1024/Vitis-AI/commit/4af2ac44f85445f1965ab6630074f865fb038049

you can paste your fix here and I'll check it. thanks.

hello，This is my modified code，I just modified one line
https://github.com/zyt1024/Vitis-AI/commit/4af2ac44f85445f1965ab6630074f865fb038049

your fix is not correct.
Your fix cause blank gap in the output buffer.

Closing since no activity for more than 3 months, please reopen if you still have question, thanks


Fix trec sacrebleu

Fixes Gradio app for sacrebleu and trec_eval.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Wrap BossaAPIInterface

The interface mapped by JNA is ugly. Everything mapped to dll must be public to work properly. Wrap and encapsulate BossaAPIInterface and nested classes.

great. Now add:

[ ] error checking.


Release Version that Works with Visual Studio 2022?

Would it be possible, please, if you've got a moment, now Visual Studio 2022 is out, to help us VSIX devs and release a built version of the head of the code to NuGet?
I seem to need it for testing a VS2022 VSIX that references v17 of the SDK.  If there's a workaround let me know please.  I have built my own version and it works, but I don't really want to publish that separately on NuGet.

Quite so. I'll get right on that.

Done: https://github.com/microsoft/vssdktestfx/releases/tag/v17.0.15
Thanks for bringing this to my attention.

Thank you so much, much appreciated

I spoke too soon.  This fails to install for me with error 'Unable to find package Microsoft.Internal.VisualStudio.Interop.  No packages exist with this id in sources'.
I think the clue is the 'Microsoft.Internal' bit?
I'm a little confused as to why my build worked though, as that managed to download Microsoft.Internal.VisualStudio.Interop.17.0.0-preview-2-31221-277.  That doesn't fit the constraints for the new package (>=17.0.319), and in any case my own build now fails to install if I have a clear cache, so I'm guessing the package has disappeared for non-Microsoft people.
Am I doing something wrong, or is this broken unless you work at Microsoft??

Oh, that package is available from a public feed, but not nuget.org. When you built from this repo, the nuget.config allowed you to pull down that package. But when I pushed this package to nuget.org with an updated dependency version and you then installed to your own repo, the feed wasn't in your nuget.config file so it can't find it.
I'm not sure how we should fix this. Let me reactivate the issue to track.

I was able to work around this problem by adding this to my nuget.config file (take from the NuGet config in this repository):
 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <packageSources>
     <clear/>
     <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
+    <add key="vs-impl-public" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vs-impl/nuget/v3/index.json" protocolVersion="3" />
+    <add key="vssdk-public" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/vssdk/nuget/v3/index.json" protocolVersion="3" />
   </packageSources>
 </configuration>

@reduckted Yes, thank you, that works as a workaround

@reduckted I had the same issue and this worked for me as well, thanks for posting that!


Set color for status bar when scrolling page

How I can set color for status bar when page scrolled.
Now it is transparent...

Thx!

This is not related to NativeBase. Here's a link which might help you
http://stackoverflow.com/questions/39297291/how-to-set-ios-status-bar-background-color-in-react-native


public name and model in Config:ProductInfo

I am using the latest master and would like to obtain how many hardware input (ie: HDMI in) for ATEM mini (for example, ATEM mini has 4 whilst ATEM mini extreme has 8).
I can't find any useful information except ProductInfo with name and model enum so that I can obtain it by myself.
Is it possible to public those variables in the master in the future?
https://github.com/Dev1an/Swift-Atem/blob/b1ab46e3e59353cf18a9093b8fc9ed53917f6e47/Sources/Atem/Messages/Configuration.swift#L39-L50

Yes i've made them public in the development branch

But I think what your looking for is the topology ("_top") command.


null is evil

Take it for granted or listen to The billion dollar mistake from Tony Hoare.
For data consistency #20, Validation should not allow a field to null or undefined.

An unspecified field/property should be an empty string


Is there any way to get the list of NER labels?

Is there any way to get the list of NER labels?

Hello:  As with other ML tasks, preproc.get_classes() should work.


'startGameDownload': TypeError: Cannot read properties of undefined (reading 'id')

When I try to download any game:
Error occurred in handler for 'startGameDownload': TypeError: Cannot read properties of undefined (reading 'id')
    at getSteamGameIconUrl (file:///home/thomas/hydra/out/main/index-NFpcPGOw.js:65:23)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async startGameDownload (file:///home/thomas/hydra/out/main/index-NFpcPGOw.js:826:45)
    at async WebContents.<anonymous> (node:electron/js2c/browser_init:2:77963)

Probably you forgot to edit your .env
Happened to me as well.

I filled .env but maybe with wrong values:

MAIN_VITE_STEAMGRIDDB_API_KEY= I put my steam API KEY
MAIN_VITE_ONLINEFIX_USERNAME= steam username
MAIN_VITE_ONLINEFIX_PASSWORD= steam password
MAIN_VITE_SENTRY_DSN= React js sentry dns
RENDERER_VITE_SENTRY_DSN= same value as above

I tried with and without " ".

Hey dude. I had this problem yesterday with the "getSteamGameIconUrl" function. It is caused by the lack of steamgriddb api key in the .env and you have to restart the application with "yarn dev" to work.

I filled .env but maybe with wrong values:

MAIN_VITE_STEAMGRIDDB_API_KEY= I put my steam API KEY
MAIN_VITE_ONLINEFIX_USERNAME= steam username
MAIN_VITE_ONLINEFIX_PASSWORD= steam password
MAIN_VITE_SENTRY_DSN= React js sentry dns
RENDERER_VITE_SENTRY_DSN= same value as above

I tried with and without " ".

"MAIN_VITE_ONLINEFIX_*" It's not about steam

https://www.steamgriddb.com/
Create an account on this site and generate an API KEY
Copy the API KEY and put it on .env in MAIN_VITE_STEAMGRIDDB_API_KEY

Thanks that was it. I put steam API key (20e to get a game and then a key) instead of steamgriddb.


README.md updated - fix typos and broken links

README.md updated - fix typos and broken links

Thanks!


ModuleNotFoundError: No module named 'nni.compression.pytorch'

Describe the issue:
from nni.compression.pytorch.utils import count_flops_params
ModuleNotFoundError: No module named 'nni.compression.pytorch'
Environment:

NNI version: 3.0
Training service (local|remote|pai|aml|etc):
Client OS:
Server OS (for remote mode only):
Python version: 3.8
PyTorch/TensorFlow version: 1.12-gpu
Is conda/virtualenv/venv used?: conda
Is running in Docker?: no

try delete .pytorch

try from nni.compression.pruning.basic_pruner import FPGMPruner