Mc agency homepage searcher

Fixes
#53 - "Alternative way of getting more urls: Automated Search Engine Calls"
Description
This performs several related actions:

Obtains all agencies from the PUBLIC.AGENCIES table in the PDAP Digital Ocean DB which both do not have a homepage_url and which have not already been searched for (as determined by whether their unique identifier is present in the PUBLIC.AGENCY_URL_SEARCH_CACHE table
Generates a search query for each agency based on information present in the database, and performs an automated Google Search API Call. At the free tier, up to 100 such queries can be made each day.
Saves 10 of the results for each agency to a csv.
Once all searches have been completed (either 100 or whenever the search quota is reached), these entries are put in a CSV, along with identifying information, and uploaded to the huggingface PDAP/possible_homepage_urls dataset
Following this, the agencies which have been searched for are added to PUBLIC_AGENCY_URL_SEARCH_CACHE
Also creates a yaml file which runs this functionality once per day.

Testing

Run test_agency_homepage_searcher_integration.py and test_agency_homepage_searcher_unit.py using pytest
Run main.py' to confirm functionality. Check https://huggingface.co/datasets/PDAP/possible_homepage_urls/tree/main/data to confirm search results added. Additionally, can check agency_url_search_cache` in database to confirm expected agencies are updated.
The yaml file agency_homepage_searcher.yaml can be verified via a specialized docker container, but if that's too much effort we can do a "dude just trust me" on this one, as I've verified it myself using said specialized docker container.
Note the environment variables referenced in the yaml file -- if these don't exist as Github secrets, this yaml file will not work in the repository.

@maxachis can you dm me the google key and id?

@maxachis can you dm me the google key and id?

I can do that, but my recommendation is to see if, using the README, you're able to obtain your own. I've added additional instructions under the Environment Setup section, so it should only take a few clicks to get your own.

Looks like requirements.txt needs some updates

I've cleaned up requirements.txt to resolve some issues, and then ran the main script successfully on a Docker container using only the requirements needed for running this (which are specified in agency_homepage_searcher/requirements_agency_homepage_searcher_action.txt. I tried to install everything in requirements.txt at once within the docker container and it took a long time and then bricked the container. Another reason why my initial thinking about consolidating the requirements files was wrong in the case of this repository.

@josh-chamberlain do we have a PDAP google project we can create a key for pipeline on?

@mbodeantor just added two secrets to this repo:
GOOGLE_SEARCH_ENGINE_ID and GOOGLE_CUSTOM_SEARCH_KEY

@josh-chamberlain we will also need a pipeline HUGGINGFACE_ACCESS_TOKEN in the Github env

@mbodeantor Made updates per your requests. Give it a shot now and see how it looks.

@maxachis thanks, looks like just the README running tests and script section missing

@mbodeantor Done. Ready for further review.

@maxachis Looks like there are still some errors cause the checks to fail

@josh-chamberlain Just want to confirm we have a HUGGINGFACE_ACCESS_TOKEN in the Github env

@maxachis Looks like there are still some errors cause the checks to fail

@mbodeantor This is related to bugs in my implementation of the type_and_docstring checks. I'm working on revising that in #77. Unfortunately, the type_and_docstring_check is not working right now.

@maxachis I hadn't added that HUGGINGFACE_ACCESS_TOKEN token in GitHub, by the way. It's there now.


"npm install pokemon-go-node-api" doesn't work

I have node 6.3 and npm 3.10.3 and it keeps giving me below error
npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build
Can someone help me with this error?

shot in the dark, you're using a mac? might have to go update XCode if you are.

might using win10 and newest nodejs?
u will need to compile bignum for yourself
so install visual studio (2015)
and install openssl 64 bit (for libeay.lib) (or how its called)
and try again
also you may just send us your npm-debug.log

#50
as this one is removing bignum dependency it may be fixed anyways soon


slic3r-prusa3d: 1.40.1 -> 1.41.0

Motivation for this change
1.41.0 isn't out yet, but I want to document what needs to be updated for the final release.
The latest alpha needs a few more dependencies. Also NLOPT needs to be set manually, as the package isn't found otherwise. :/
gtest is needed although it seems unittests aren't even build by default. Might be worth it to report that to upstream.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

1.41.0 has been tagged upstream, just waiting till they release it officially.

@grahamcofborg build slic3r-prusa3d

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: slic3r-prusa3d
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on aarch64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1000:72:   required from 'Slic3r::client::macro_processor<Iterator>::macro_processor() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >]'
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1180:33:   required from here
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:462:32: warning: unused variable 'mask' [-Wunused-variable]
             const std::string *mask     = nullptr;
                                ^~~~
[ 95%] Linking CXX static library liblibslic3r.a
[ 95%] Built target libslic3r
make: *** [Makefile:141: all] Error 2
builder for '/nix/store/9f338pkpvwvjn0n3xpjixlsc2hh4adcd-slic3r-prusa-edition-1.41.0.drv' failed with exit code 2
error: build of '/nix/store/9f338pkpvwvjn0n3xpjixlsc2hh4adcd-slic3r-prusa-edition-1.41.0.drv' failed

Success on x86_64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0
shrinking /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0/lib/slic3r-prusa3d/auto/Slic3r/XS/XS.so
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0/lib  /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0/bin
patching script interpreter paths in /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0
/nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0/bin/.slic3r-prusa3d-wrapped: interpreter directive changed from "/usr/bin/env perl" to "/nix/store/kdbzhdzm43r58smfx29x3233dagihxp5-perl-5.28.0/bin/perl"
checking for references to /build in /nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0...
/nix/store/n6p32swhj3p9ds0rn9n0i8zd7wbsc013-slic3r-prusa-edition-1.41.0

@GrahamcOfBorg build slic3r-prusa3d

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: slic3r-prusa3d
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on aarch64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1000:72:   required from 'Slic3r::client::macro_processor<Iterator>::macro_processor() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >]'
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1180:33:   required from here
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:462:32: warning: unused variable 'mask' [-Wunused-variable]
             const std::string *mask     = nullptr;
                                ^~~~
[ 95%] Linking CXX static library liblibslic3r.a
[ 95%] Built target libslic3r
make: *** [Makefile:141: all] Error 2
builder for '/nix/store/z0my0l3v811ivgjsi7l589szcmg1yvbv-slic3r-prusa-edition-1.41.0.drv' failed with exit code 2
error: build of '/nix/store/z0my0l3v811ivgjsi7l589szcmg1yvbv-slic3r-prusa-edition-1.41.0.drv' failed

Success on x86_64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
shrinking /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib/slic3r-prusa3d/auto/Slic3r/XS/XS.so
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib  /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin
patching script interpreter paths in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin/.slic3r-prusa3d-wrapped: interpreter directive changed from "/usr/bin/env perl" to "/nix/store/hjn5kq7yq18z31ajq7lfd6imjwz21lh6-perl-5.28.0/bin/perl"
checking for references to /build in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0...
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0

Any idea regarding the aarch64 failure?

@timokau Sadly no, but it seems to happen during linking of libslic3r.a
Likely the problem has been happening in earlier versions though. https://github.com/NixOS/nixpkgs/pull/43102 also failed.
I've marked aarch64-linux as unsupported for now.

@GrahamcOfBorg build slic3r-prusa3d

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: slic3r-prusa3d
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Failure on aarch64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1000:72:   required from 'Slic3r::client::macro_processor<Iterator>::macro_processor() [with Iterator = __gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >]'
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:1180:33:   required from here
/build/source/xs/src/libslic3r/PlaceholderParser.cpp:462:32: warning: unused variable 'mask' [-Wunused-variable]
             const std::string *mask     = nullptr;
                                ^~~~
[ 95%] Linking CXX static library liblibslic3r.a
[ 95%] Built target libslic3r
make: *** [Makefile:141: all] Error 2
builder for '/nix/store/z0my0l3v811ivgjsi7l589szcmg1yvbv-slic3r-prusa-edition-1.41.0.drv' failed with exit code 2
error: build of '/nix/store/z0my0l3v811ivgjsi7l589szcmg1yvbv-slic3r-prusa-edition-1.41.0.drv' failed

Success on x86_64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
shrinking /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib/slic3r-prusa3d/auto/Slic3r/XS/XS.so
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib  /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin
patching script interpreter paths in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin/.slic3r-prusa3d-wrapped: interpreter directive changed from "/usr/bin/env perl" to "/nix/store/hjn5kq7yq18z31ajq7lfd6imjwz21lh6-perl-5.28.0/bin/perl"
checking for references to /build in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0...
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0

Seems like that didn't work. I'm not sure what the best way to remove aarch64 from the platforms is. I've seen people explicitly specifying x86 and x86_64 explicitly, which doesn't really seem right to me either.

@timokau I've posted at https://discourse.nixos.org/t/marking-a-package-broken-for-certain-platforms/1057 regarding this question.

@timokau I've marked it as broken now. On my system it shows as broken when cross compiling. I have to wait to further work on that issue and would advocate for merging this PR in the mean time, as 1.41.0 is the first version that supports the Prusa MMU 2.0.
For that reason I would also like to backport this to 18.09.

@GrahamcOfBorg build slic3r-prusa3d

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: slic3r-prusa3d
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: slic3r-prusa3d
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: slic3r-prusa3d
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
shrinking /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib/slic3r-prusa3d/auto/Slic3r/XS/XS.so
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/lib  /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin
patching script interpreter paths in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0/bin/.slic3r-prusa3d-wrapped: interpreter directive changed from "/usr/bin/env perl" to "/nix/store/hjn5kq7yq18z31ajq7lfd6imjwz21lh6-perl-5.28.0/bin/perl"
checking for references to /build in /nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0...
/nix/store/dbxa9wbqdr0ckfzd0qh89kgv6pvw8fc5-slic3r-prusa-edition-1.41.0

Thank you, looks good! The aarch64 support probably isn't so essential that you must spent much time on it if you don't want to.

would advocate for merging this PR in the meantime, as 1.41.0 is the first version that supports the Prusa MMU 2.0.

The policy is to backport bug fixes and maybe additions, but not simply features. The reason for that is that every new feature has the potential to break something and the releases are supposed to be as stable as possible. You can however easily have a system based on the stable release and still install the latest version of some software from the unstable channel. The wiki has more info on that.


Panics when comparing varchar and array

Describe the bug
No response
To Reproduce
select 'a' = array['a'];

thread 'risingwave-main' panicked at 'Functions returning struct or list can not be inferred. Please use `FunctionCall::new_unchecked`.', src/common/src/types/mod.rs:147:47

Expected behavior
No response
Additional context
This won't panic:
select 1 = array[1];
ERROR:  QueryError: Feature is not yet implemented: Equal[Int32, List]
Tracking issue: https://github.com/risingwavelabs/risingwave/issues/112

#3692


Special characters used in bullet lists not rendered correctly

Sometimes special characters used in bullets don't seem to be rendered correctly, e.g. here:

I have the same issue in the raw source on GitHub:

These are actually the characters in the source of the file - so it is rendering exactly what it sees.
Maybe these should look like checkboxes and are actually intended this way?

🙈 They are supposed to be checkboxes, yes.

I think I did not get that becuase the normal list bullet is still there - without that I might have gotten it.

fixed this a while ago


ISPN-10471 Infinispan changes to support Quarkus using LOCAL cache

https://issues.jboss.org/browse/ISPN-10471

@wburns The changes LGTM, but the DistSyncTwoPhasesWriteSkewTxStateTransferTest failures seem related.

Hrmm, quite odd this PR is not changing any functionality, just refactoring the code very slightly to make it easier to replace or not start a thread in a static block. I will take a closer look.

@ryanemerson it looks like an intermittent failure in that test class itself. These changes have nothing to do with that test and a very minimal. I can't seem to reproduce it locally yet at least. I have started another build to get another data point though.

Rerun and the failure is gone. The JGroups one is a new failure on master from a different commit.

JGroups one is a new failure on master from a different commit.

Yep ... I introduced that one. It was a NPE that my changes in https://github.com/infinispan/infinispan/pull/7188 uncovered. I'll take a look at some point this week.


Add to() on the pipeline (inference documentation)

Someone pointed out to me I was missing moving the pipeline to the right device 😅 😓

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


Problem genning a rom.

Every time my friend or I gen an inverted MW rom, we get "No such region Agahnims Tower for player 1." Not particularly sure why this is happening.

I was getting a similar error when trying to generate a ROM with a spoiler log.  Try generating a seed without a spoiler log to try to advance further while @cassidoxa has a chance to look into it.

Yeah I tried that, neither worked, gave the same exact error.

I'm also not sure which branch you are grabbing the code from. It isn't clear from the GitHub page, but you should make sure you are using the code from the inverted-multiworld-bonta branch, not master.
https://github.com/cassidoxa/ALttPEntranceRandomizer/tree/inverted-multiworld-bonta

Yeah we were using that branch.

Are you using the latest code from that branch? It's been updated since I posted it in the discord. Also what settings are you trying to generate a seed with?

As far as I know I'm on the latest one, I've redownloaded the code recently. My settings are: All Dungeons, Keysanity, progressive equipment random, Entrance shuffle Vanilla, Include Ganon's Tower and Pyramid Hole in shuffle pool, Enemizer and Normal boss shuffle.

Thanks. I believe this is an enemizer issue, but I'm not sure why it's affecting Agahnim's Tower. I'll see if I can figure it out.

I've fixed an enemizer bug related to Ganons Tower but not Aga Tower. I'm not sure if it will work yet; I'm not on my WIndows machine to test it. But feel free to give it another shot.

Ok, I've got it in a state where it can generate ROMs with enemizer on. Make sure you don't check the "create spoilers" option as well.


Doesn't seem to work anymore (DM received, not my messages)

Hi,
so after i successfully deleted all my messages by hand, I used your .js to delete my correspondent's messages.
but I got this error:
{"message":"Cannot execute action on a DM channel","code":50003}
Also minor thing but the counter always increment:
295.92% (145/49)	Deleting ID:REDACTED REDACTED (REDACTED): REDACTED
Anyway thank you for sharing this

Are you trying to delete the DM of, someone else?

yes, that's what I meant by "my correspondent's messages".
But I sure that will never be possible as it server based and messages seems to belong to discord and not users
#GDPR

I understand, thank you for your time.


Cuda bindings (MVS, SIFT GPU)

Adds CUDA support when COLMAP was built with CUDA_ENABLED

use pycolmap.has_cuda in python to check for GPU support
device argument in functions to specify whether to use CPU ("cpu"), GPU ("cuda"), or "auto" for GPU if available else CPU.
all functions except for patch_match_stereo can be used when built w/o CUDA_ENABLED.

Reorganized pipeline functions (see pipeline/)
SIFT feature extractor and matcher (exhaustive, sequential, spatial, vocabtree) + options
Dense MVS reconstruction pipeline (undistort_images,patch_match_stereo, stereo_fusion) + options
SIFT GPU on numpy image (see sift.cc), both byte and float images supported
Allow interrupting long c++ functions via KeyboardInterrupt

Did you have a prebuild weel with cuda ?

We don't but any help is very much appreciated. Some pointers:

We'd need to install the Cuda toolkit in the CenOS manylinux image, either through yum (here is a good starting point) or via pip.
It would be nice to not package the Cuda libs in the wheel and instead depend on Cuda pip packages - we'd need to add these requirements to the pycolmap wheels.
I don't know whether we need to build a separate wheel for each version of Cuda


WGSL: Runtime-sized arrays not in 'storage' address space are being generated

Affected tests:

tests/autodiff/diff-ptr-type-array.slang

Example output:
WGPU error: Error while parsing WGSL: :8:67 error: runtime-sized arrays can only be used in the <storage> address space
fn MyPtrType_accumulate_0( this_0 : MyPtrType_0,  this_buffer_0 : array<f32>,  idx_0 : u32,  value_0 : f32)
                                                                  ^^^^^^^^^^

:8:51 note: while instantiating parameter this_buffer_0
fn MyPtrType_accumulate_0( this_0 : MyPtrType_0,  this_buffer_0 : array<f32>,  idx_0 : u32,  value_0 : f32)
                                                  ^^^^^^^^^^^^^

 - While validating [ShaderModuleDescriptor]
 - While calling [Device].CreateShaderModule([ShaderModuleDescriptor]).

May be array of runtime-sized array/buffer and therefore out of scope.

Yes, this is indeed just a slightly disguised variant of "array of runtime-sized-array", which falls into
the out-of-scope category 'Arrays of textures or buffers' mentioned in
https://github.com/shader-slang/slang/issues/5519.
The buffer here:
struct MyPtrType : IDifferentiablePtrType
{
    typealias Differential = MyPtrType;

    RWStructuredBuffer<float> buffer;
    uint offset;

    float load(uint idx) { return buffer[offset + idx]; }
    void accumulate(uint idx, float value) { buffer[offset + idx] += value; }
}

Is being passed in the array here:
void load_bwd(DifferentialPtrPair<MyPtrType[2]> b, uint idx, float grad)
{
    b.d[1].accumulate(idx, grad);
}

I will just modify the comment, leave the test disabled and then close this task.


Picker Control is showing checkboxes for all items

Description
The Picker control 7.0.11 is showing a checkbox to the left of each option, even when the is-selected class is not present on the spectrum-Menu-item
Steps to reproduce
1, Go to https://opensource.adobe.com/spectrum-css/picker.html#variants
Notice that all options have a blue checkbox to the left of the text.
Expected behavior
only options with the is-selected class should show the checkbox.
Screenshots

Environment

Version of the impacted component(s):
Browser(s) and OS(s):

Additional context
This can be fixed with the addition of this CSS:
ul.spectrum-Menu li.spectrum-Menu-item[role=option] .spectrum-Menu-checkmark{
  visibility: hidden;
}

ul.spectrum-Menu li.spectrum-Menu-item[role=option].is-selected .spectrum-Menu-checkmark{
  visibility:visible;
}

This should be resolved via #2226


Optifine + Complimentary Shaders results in glass not rendering.

Been trying to make a modpack that has shader support, and I have discovered that, as long as RLFoliage is installed, whenever my shader of choice is on (Complimentary Shaders) it causes glass blocks and glass panes to not render a texture. The affected blocks turn 100% transparent when the mod is installed, even if every feature in the config file is disabled.

This is an issue with the original BetterFoliage, from what I remember certain shaders set glass to translucent when Optifine itself doesn't usually do that in the first place, which causes some sort of rendering conflict between BetterFoliage and Optifine.
You can try disabling Anisotropic Filtering, Antialiasing, and VBOs in Optifine settings and see if that helps.
Alternatively, edit the shader pack and remove the line setting glass to translucent, layer.translucent = glass glass_pane.
Or, switch to a different shader pack, personally I recommend Sildur's Shaders as they are generally compatible with most 1.12.2 mods.

Thanks for the advice, I will experiment to see what works best for me.


Get error when run the Node.js APP

In https://github.com/hyperledger/fabric/blob/master/docs/API/CoreAPI.md#using-swagger-js-plugin
Run the Node.js app
$ node ./openchain.js
Get below error:
$ node ./openchain.js
Connected to REST API server!
Running Swagger API test...
C:\Work\blockchain\Workplace\src\github.com\hyperledger\fabric\docs\API\Samples
Sample_1\OpenchainSample_1\openchain.js:81
swagger.Devops.chaincodeDeploy({'ChaincodeSpec': chaincodeSpec},{responseCon
tentType: 'application/json'}, function(Devops){
^
TypeError: Cannot read property 'chaincodeDeploy' of undefined
at runSwaggerAPITest (C:\Work\blockchain\Workplace\src\github.com\hyperledge
r\fabric\docs\API\Samples\Sample_1\OpenchainSample_1\openchain.js:81:19)
at client.success (C:\Work\blockchain\Workplace\src\github.com\hyperledger\f
abric\docs\API\Samples\Sample_1\OpenchainSample_1\openchain.js:32:5)
at SwaggerClient.buildFromSpec (C:\Work\blockchain\Workplace\src\github.com
hyperledger\fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swag
ger-client\lib\client.js:420:10)
at Resolver.finish (C:\Work\blockchain\Workplace\src\github.com\hyperledger
fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client\l
ib\resolver.js:336:14)
at Resolver.resolve (C:\Work\blockchain\Workplace\src\github.com\hyperledger
\fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client
lib\resolver.js:253:10)
at Resolver.finish (C:\Work\blockchain\Workplace\src\github.com\hyperledger
fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client\l
ib\resolver.js:340:10)
at Resolver.resolve (C:\Work\blockchain\Workplace\src\github.com\hyperledger
\fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client
lib\resolver.js:253:10)
at Resolver.finish (C:\Work\blockchain\Workplace\src\github.com\hyperledger
fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client\l
ib\resolver.js:340:10)
at Resolver.resolve (C:\Work\blockchain\Workplace\src\github.com\hyperledger
\fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client
lib\resolver.js:253:10)
at Resolver.finish (C:\Work\blockchain\Workplace\src\github.com\hyperledger
fabric\docs\API\Samples\Sample_1\OpenchainSample_1\node_modules\swagger-client\l
ib\resolver.js:340:10)

@trayKBE  - I have a feeling that unfortunately that sample was never updated to work with the updated JSON-RPC based API now provided by the fabric

Thanks for your answer


Core bug with latest release

  Error thrown in test:

  TypeError {
    message: 'Cannot destructure property `splitRegexp` of \'undefined\' or \'null\'.',
  }

  noCase (node_modules/no-case/src/index.ts:20:9)
  maskString (src/index.js:199:25)
  maskProps (src/index.js:253:18)
  parseRequest (src/index.js:400:12)
  test/basic.js:518:15

@niftylettuce What's the reproduction? Are you passing null as the second argument somewhere?

@blakeembrey yeah <https://github.com/cabinjs/parse-request/blob/master/src/index.js#L199

I supposed I could switch from noCase to snakeCase, but just wanted to point it out that as soon as I version bumped and changed const noCase to const { noCase } it caused that exception.

@niftylettuce Thanks for the flag, I'm documenting it now - the second argument should be an object or undefined.

FWIW, all functions have an object as the second argument now. Documentation in no-case is here: https://github.com/blakeembrey/change-case/tree/master/packages/no-case#options. I might pull it up to the top-level README where it's more visible instead.

Added document to main README on options: https://github.com/blakeembrey/change-case#core.

You rock, thanks @blakeembrey 🎉 	Have an awesome rest of your weekend


Reduce production EC2 capacity

Now that 1.15.0 has been deployed with both performance improvements and the dropping of archived layers, we should be able to both go down in instance size (we should only need 32GB of memory now) and number of instances.
AC:

Test reducing instance size on staging
Deploy new smaller instances on production
Gradually reduce number of production instances and watch performance metrics

In terms of what instance to switch to - the natural choice is going down one size in our current class to r5.xlarge, but we should consider trying out r6g.xlarge (which uses ARM processors) instead, as it is 40% cheaper, and there's no reason to think it will affect our application; the only native binding in our server code is bcrypt which also has ARM bindings:
$ find node_modules -name '*.node'
node_modules/bcrypt/lib/binding/napi-v3/bcrypt_lib.node

For our instance types at least (at on-demand costs) ARM is only a 20% savings. Switching to AMD gets us 10% savings and we stay on x86_64 which seems good enough.
r5.xlarge	$0.252	4	32 GiB
r5a.xlarge	$0.226	4	32 GiB
r6g.xlarge	$0.2016	4	32 GiB

According the the cluster, staging is at 40% memory usage while production is at 49%
Production (1 at random) vs Staging
Mem used: 33220 vs 26469
Docker: 33.23GiB vs 25.15GiB
Leaving the instance type alone for now, but moving container_instance_app_desired_count from 6->4.

It looks like the memory usage may be due to the LRU cache that we've added (either that or we've got ourselves a memory leak, but it looks like the slope levels off around 56%, so I'm inclined toward the former):

There's a number we can tweak to control how much memory the cache is allowed to use, which I think is currently set at 80% of available memory. Given that we're so close I bet we could squish things a bit to fit within 32GB, but probably best to let @maurizi dig into it next week.

@BryanQuigley I tried load testing staging using r5a.xlarge instances, and found they doubled the time it took to load a large state like TX or PA after a cache miss, to the point where it would often time out (e.g. a cache-miss for Texas is 12-15 seconds on r5.2xlarge, but more than 30 seconds on r5a.xlarge).
I'm deploying an r6g.xlarge to staging now and load testing it to see what performance we get from that instance type.

I'm taking back my strong stance on the performance of the r5a.2xlarge - I need to retest with the exact same load tests (I had been on a different commit when testing the r5a.2xlarge instances).
And simply switching the base image to r6g.xlarge doesn't work - trying to start the server immediately crashes, presumably because we're not pushing an ARM-based Docker image, so I'm holding off on further attempts to try that for now 😢

Ok, back to report here with more accurate info re: r5.2xlarge vs r5a.2xlarge:
It's not actually file load times (and thus cache-misses) that are slower on the r5a.2xlarge, but rather the TopoJSON merge operation is slower: taking ~5s on an r5.2xlarge and ~8-9s on r5a.2xlarge to edit the official PA state house map (my load test used lots of merge operations to trigger cache eveictions, so I was measuring both).
That's a much bigger perf. hit than I'd expect for only a 10% savings - I'm not sure if that's worth it.

r5a.2xlarge doesn't sound worth it for 10%. That sounds like we could call this issue done for now unless we want to try with just 1 ec2 instance (which actually might be fine)

@BryanQuigley with the changes in #1172, once they're deployed I think we can try running using r5.xlarge - probably going from 2 r5.2xlarge to 3 r5.xlarge would be safest.


NAME_UNKNOWN when listing tags of partially pushed image

/v2/_catalog end point returned the repository but upon listing the tags I received:
{"errors":[{"code":"NAME_UNKNOWN","message":"repository name not known to registry","detail":{"name":"so0k/gitreceive"}}]}

docker/registry/v2/repositories# tree -L 2
.
├── so0k
│   ├── gitreceive <<< repository is here, but only partially pushed.
│   ├── gitreceive-dind
│   └── sinopia
└── test
    ├── api
    ├── web
    ├── worker
    └── ws

I fixed it by pushing the repository and making sure the push completed. Not sure what expected behavior is?

ping @pdevine

@so0k It looks like there may be a bug here. Could you provide us a full output of tree? I'd like to see how "valid" so0k/gitreceive and if we can detect that and not expose it in the catalog.
There really isn't a strong guarantee that the repository exists if listed. From the specification:

Subsequently, the presence of a repository in the catalog listing only means that the registry may provide access to the repository at the time of the request. Conversely, a missing entry does not mean that the registry does not have the repository. More succinctly, the presence of a repository only guarantees that it is there but not that it is not there.

Albeit, even this wording isn't strongly guaranteed. Proper client code should be handle the NAME_UNKNOWN error, treating it as an empty or untagged repository.

The catalog just looks to see if there are _layers directory in the directory walk and makes the assumption that if it exists, it's a valid repository.  @stevvooe, is there a way of guaranteeing that each of the layers have been pushed and that everything is consistent?  (Would we want that?)

@pdevine The paths are documented here. A valid repository would have either "_layers" or "_manifests".
The correct return for the tags API might be to have no tags, rather than NAME_UNKNOWN.

running in the same bug
curl -v  http://localhost:5000/v2/smt/tags/list
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 5000 (#0)
> GET /v2/smt/tags/list HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Docker-Distribution-Api-Version: registry/2.0
< Date: Fri, 31 Jul 2015 09:59:09 GMT
< Content-Length: 111
< Content-Type: text/plain; charset=utf-8
<
{"errors":[{"code":"NAME_UNKNOWN","message":"repository name not known to registry","detail":{"name":"smt"}}]}
* Connection #0 to host localhost left intact

/data/registry/docker/registry/v2/repositories # tree  -d -L 6
.
└── smt
    ├── ingest_preview
    │   ├── _layers
    │   │   └── sha256
    │   │       ├── 6e471a4b88178d29a20e9a2caaa1aac06ff9c62b97a0c882a5d97f99fc138cc4
    │   │       ├── a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    │   │       ├── c78d17052e177eee6518903c9ee885c5980fbaad5d42777b1521b6417c00398b
    │   │       └── da24b8f756263014a24b9d1676b6153dd573a4cd56a5039bf744dc698d01bba3
    │   ├── _manifests
    │   │   ├── revisions
    │   │   │   └── sha256
    │   │   │       └── ccb90a206b4ef40fee0fa8f334001f0a6923fb0df3a712f94af9e2b5a9adb7b0
    │   │   └── tags
    │   │       └── 01b0a80
    │   │           ├── current
    │   │           └── index
    │   └── _uploads
    └── videoengine_preview
        ├── _layers
        │   └── sha256
        │       ├── 22b5bc0143d369d3361379a947edddacf12e6a446df5e4354b29971265e83c50
        │       ├── a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
        │       └── e31ae55786c2adb12ce73d0460f778db38af1d7506ab848f83366d2b138263c5
        ├── _manifests
        │   ├── revisions
        │   │   └── sha256
        │   │       └── 402a423e72414f2bf4bdbe182f12d8cefda8b0cbe26c3023377040a640b6d529
        │   └── tags
        │       └── v0.1
        │           ├── current
        │           └── index
        └── _uploads

@Deshke This is not the same issue, nor is it a bug. The curl command http://localhost:5000/v2/smt/tags/list is requesting information for the repository smt, which does not exist.
You need to either request http://localhost:5000/v2/smt/ingest_preview/tags/list or http://localhost:5000/v2/smt/videoengine_preview/tags/list.

@stevvooe ah ok, then i missed the documentation on that part

Sorry for not providing you the exact folder structure of my registry storage as I had fixed the issue by pushing the problem image again. I will try to reproduce by doing another push and aborting mid-way.

I got the same error "NAME_UNKNOWN" when listing tags of one repository which had not been pushed completely, but catalog API can list it.

There is no guarantee that a partially uploaded repository is valid due to the current storage system.
This particular case is being tracked in #936 and I'm going to close this issue in favour of that.


[TE] Support schedulable TIR compute definitions in TOPI

This PR adds te.extern_primfunc which provides the interface around TE ExternOp that allows a TVMScript defined schedulable TIR PrimFunc to be inlined into a TE compute graph. The result is that TIR can be used for compute definitions in Relay OpStrategies and, paired with meta-scheduler support in relay as introduced in #10578, these compute definitions can be scheduled and tuned as demonstrated in the attached tests.
Prior to this, compute definitions were limited to those definable in TE only. As a consequence of this patch and ongoing improvements to TVMScript meta-programming (#11097), TOPI can be extended to include compute and scheduling functions targeting schedulable TIR uniformly.

cc @Hzfengsy

@Hzfengsy for context, as a rule of thumb, usually we don't use "requested changes" if the comment is not emotional :-)  in our case, it's just some syntactic nitpicking, so let's just use "comment" as review type

Thanks for the reminder of @junrushao1994. And I'm sorry for bringing ambiguity to @csullivan. I will change the Changes requested into Approve and we can merge it if we want.

Thanks @Hzfengsy. I think I prefer T.serial personally but I continue to be impressed by the TVMScript parser. I agree the linter made this a bit ugly. I want to add some additional tests in a follow up so I'll happily address the formatting then and consider the change to range.


bug: Incorrect hosts used for Memcached in Horizon and Keystone

Is this a bug report or feature request? (choose one): Bug

Kubernetes Version: N/A
Helm Client and Tiller Versions: N/A
Development or Deployment Environment?: N/A
Release Tag or Master: Master
Expected Behavior:
For Horizon and Keystone to use the correct value for Memcached in config files.
What Actually Happened:
Both Horizon and Keystone use the RabbitMQ hostname instead.
Any Additional Comments:
See:

https://github.com/att-comdev/openstack-helm/blame/master/horizon/templates/etc/_local_settings.tpl#L147
https://github.com/att-comdev/openstack-helm/blame/master/keystone/templates/etc/_keystone.conf.tpl#L25
https://github.com/att-comdev/openstack-helm/blame/master/keystone/templates/etc/_keystone.conf.tpl#L32

fixing this @v1k0d3n

@larryrensing thanks dude :)


Consume messages with multiple topics and custom timeout

This simplifies a bit of code, and makes two bigger changes:

Implement consumeNumberMessagesFromTopics, which reads from multiple topics.

Add custom timeout in consumeNumberMessagesFromTopics, instead of hard-coding 5 seconds. This also counts the total consume time toward the timeout, rather than timing out if there is a 5 second period of silence. E.g. if a user calls this method with number=12 and timeout=5.seconds, and a producer produces one message every 4 seconds, the method will now throw TimeoutException after 5 seconds. The previous behavior would receive all messages in 60 seconds and not throw an exception, because there was at least one message to consume every 5 seconds.

Since change 2 is an actual behavior change, I can take it out of this PR if backwards compatibility is necessary.
My use case is running a complicated algorithm that publishes many messages to many topics, and I want to confirm that the right thing was published everywhere. I know my producer should be done after no more than 30 seconds. But if it fails, I don't want my test to stall for more than 30 seconds.

I changed the kv to case syntax, and I added an resetTimeoutOnEachMessage option to preserve the old behavior as the default. If you prefer, I can split it out into two separate methods, but I thought adding a flag to the existing method might be nice to minimize code duplication.

Thanks, will release hopefully this weekend (I'll have limited access to my computer for the rest of the month)


All nodes drawn as one big circle

I have a problem where all nodes (that have at least one link) get drawn in one circle. Where I would like it to position them more like a mind map. Is there any way to do this?

Please use the bug report/feature request templates when opening issues, this helps us a lot.
Regarding your question, try to play around with the libraries' custom d3 configurations they should allow you to control the closeness of nodes within your network based on its density.


[BUG] MLResourceNotFoundException leads to 500 error

What is the bug?
The MLResourceNotFoundException is just a decorated RuntimeException with special handling for ML Stats.
However, it's used in cases where a document is not found which should generally result in a 404 error.
How can one reproduce the bug?
Steps to reproduce the behavior:

Follow any code path leading to the MLResourceNotFound exception handling in ModelAccessControlHelper.validateModelGropuAccess() which would be trying to register a model to a model group that doesn't exist, or having the model group index not exist.  This may be difficult to encounter the exception due to being caught earlier in the handling, but is appearing in the MultiTenancy branch due to tenant ID checks.

What is the expected behavior?
A resource "not found" should result in a 4xx series error, usually a 404.
Do you have any additional context?
An OpenSearchStatusException would probably be appropriate here but it's not quite as simple since we have to keep the current stats exclusion exceptions, so a more careful refactoring is needed.

Thanks @dbwiddis , good point. Need to research how to enhance this part.


Observatory: Stack traces containing _Closure.call give poor results in table view.

_Closure.call should be treated specially.
When it is treated like a user function, the table view shows all callers and all callees.
This folds together all callers and callees.
It is impossible to tell which of HashMap.forEach and sort is calling my compare or action function.
It is also confusing that there are several functions called _Closure.call, it looks like there is a different version for each different number of arguments.
It is probably best to simply ignore _Closure.call

There is a more versatile alternative to ignoring _Closure.call.
Generalize the idea of a focus function from one function to a sequence of functions.
If I can grow the focus from sort to sort + _Closure.call, that solves the problem of making the information available.
The current feature matches stacks containing [Caller] - X - [Callee] and presents statistics on all matches to [Caller] an [Callee].
If we can grow X to X - Y, we would match stacks containing [Caller] - X - Y - [Callee].
The UI would support moving a caller or callee into the focus area (between the two panes), or moving the first focus function back up to the callers or the last focus function down to the callees.

I had another experience where a sequence of focus functions would be helpful.
There is an expensive get:hashCode implementation (Object.hashCode). Where is the call?
The call to get:hashCode is deep in the implementation, but if I could join 3-4 frames into the focus I would see the operation in my code.


Fix flaky test in maxSurge integration tests

What type of PR is this?
/kind flake
/kind cleanup
/assign @liurupeng

What this PR does / why we need it
Which issue(s) this PR fixes

Fixes https://github.com/kubernetes-sigs/lws/issues/134
Special notes for your reviewer
Does this PR introduce a user-facing change?

None

/lgtm
/approve


Fix: Disable cache control and x formatted by header

@wojciechkrol @EmilJunker Thank you for the patience. Please review now.

@wojciechkrol @EmilJunker Any update?

@arpitmalik Your changes look good to me, although it's a bit difficult to review because of all the unrelated formatting changes you made. I must say that I'm not a big fan of stretching simple if conditions and function calls over multiple lines of code.

Please merge the code if it looks good. Formatting is done only to make the code readable.

@EmilJunker  Please merge now.

LGTM 👍
@wojciechkrol Can you please merge this as well as #63. Both of these pull requests would make great additions to this library.

@wojciechkrol  Can we please merge this on priority? Please check.

@wojciechkrol Can you please merge this on priority.

@wojciechkrol Reminder^

@wojciechkrol  Please be active on this. Merge this pull request as soon as possible.


Add base styles

Description
Creating an empty file that is called content development page
Issue #12
Fixes # (29)

Example: Fixes #10, #20 NOTE: GitHub issue numbers should be prefixed with # to aid with issue tracking.

Type of change
Please delete options that are not relevant.

[x] New feature (non-breaking change which adds functionality)
[x] This change requires a documentation update

Screenshot (optional)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] The file is executed in the browser
[x] The file can display the elements in the file

Test Configuration: (optional)

Firmware version:
Hardware:
Toolchain:
SDK:

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Closing this due to conflicting workflows.

Hello Mr. Mathenge,
My apologies for the confusion in resolving the issues. I would like to
confirm on something, are we supposed to do the issues on the main branch
or should we do them on different branches?
Thank you for your time.
On Mon, Oct 2, 2023, 1:23 PM Beulah Mathenge @.***>
wrote:

Closed #50 https://github.com/italanta/elewa-website-html/pull/50.
—
Reply to this email directly, view it on GitHub
https://github.com/italanta/elewa-website-html/pull/50#event-10524416099,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK47TORXTDXKBJS32F6SH43X5KI25ANCNFSM6AAAAAA5KW6UIM
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi @Ngaremaina ,
What I meant is, you should compare your changes to main.
What you have is

But ideally you should have

Your comparison was wrong.
PS: I am miss Mathenge, but Beulah is just fine :-)

My apologies for the inconveniences. Thank you very much for the
clarification. I will improve on that Beulah.
My sincere gratitude.
On Mon, Oct 2, 2023, 4:35 PM Beulah Mathenge @.***>
wrote:

Hi @Ngaremaina https://github.com/Ngaremaina ,
What I meant is, you should compare your changes to main.
What you have is
[image: image]
https://user-images.githubusercontent.com/109944021/271983404-d4943d32-2dc9-49d0-96f6-647f9ff235b3.png
But ideally you should have
[image: image]
https://user-images.githubusercontent.com/109944021/271983713-96fe9deb-bd1a-4502-9352-8e5bd7ebb1d7.png
Your comparison was wrong.
PS: I am miss Mathenge, but Beulah is just fine :-)
—
Reply to this email directly, view it on GitHub
https://github.com/italanta/elewa-website-html/pull/50#issuecomment-1743029658,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK47TOVJTTLKGL4SFLIDM6DX5K7JXAVCNFSM6AAAAAA5KW6UIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGAZDSNRVHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


Behat output colors not working in Github Actions

vendor/bin/behat --tags=javascript --format=progress --colors

I think this should output colors, but it does not work. Worth pointing out that it did work in Travis CI, but Github Actions doesn't seem to like it.

What do you mean by doesn't seem to like it ? what happens ?

There's no colors.

Any ideas, @stof ?

Just tested this and the colors show correctly in Github Actions, see screenshot, closing


generator-aspnetcore-spa have problems with ng2-translate

when using ng2-translate  in a project created using generator-aspnetcore-spa, gave me errors after searching i found that ng2-translate using [Http] and in the template we using [universal module] which is have http.
following is the error
An unhandled exception occurred while processing the request.
Exception: Call to Node module failed with error: Error: Uncaught (in promise): Error: This method is not implemented in Parse5DomAdapter: getCookie
Error: This method is not implemented in Parse5DomAdapter: getCookie
at new Error (native)
at _notImplemented (c:\Users\hamed\Documents\Visual Studio 2015\Projects\testTemplate2\ClientApp\dist\vendor.js:90933:12) [angular]
at Parse5DomAdapter.module.exports.Parse5DomAdapter.getCookie (c:\Users\hamed\Documents\Visual Studio 2015\Projects\testTemplate2\ClientApp\dist\vendor.js:91528:69) [angular]
is there any solution for that.

Sounds like ng2-translate doesn't support server-side prerendering, i.e., Angular Universal. You might want to report that to the ng2-translate maintainers.
As a workaround, you can either disable server-side prerendering, or amend your app to ensure that ng2-translate is not loaded or executed during server-side prerendering.

Hi, I'm facing the same issue with ng-completer (for autocomplete).
Steve you mentioned ensuring that the module is not loaded during server-side prerendering. How would I go about doing this?
Thanks

I have this problem while using material design 2 - beta 2 also. Does anybody have a solution on how to not load the module in server-side?


Sometimes the host or other players cannot see the items in the spell store

i think this has been fixed


jns

Contributor slices request

dome.eth:3000
jacopo.eth:2000

Contributor slices request
dome.eth:3000
jacopo.eth:2000

Contributor slices request

dome.eth:3000
jacopo.eth:2000

Contributor slices request

dome.eth:3000
jacopo.eth:2000

Contributor slices request

dome.eth:3000
jacopo.eth:2000

Left-aligned
Center-aligned
Right-aligned

git status
git status
git status

git diff
git diff
git diff

Command
Description

3000
dome.eth

2000
jacopo.eth

Contributor slices request

testth:3000
jacopo.eth:2000

### Contributor slices request
- testth:3000
- jacopo.eth:2000

Contributor slices request

testth:3000
jacopo.eth:2000

Hi Anon
This repository adopts a merge to earn mechanic and is represented by slicer: 0x775e6c6a298b704f95500e752cf5b649fb3bdd73
On a successful merge a defined number of slices, representing ownership over slicer's incomes and donations, will be minted to you, and funds are claimable trough slice.so interface.
To request slices please copy and paste the following message in comments and only define you address and the desidered amount of slices.
### Contributor slices request
- youraddress.eth:3000
- another.address.eth:2000


Store account name id map in separate config

in this PR discussion we discussed that storing the account id / account name map separately might be a better approach
see this discussion

cc @lamroger-nava we had discussed doing the same thing for AWS that i proposed doing for Azure in the tech spec 🔒 Tech Spec: Managing Azure Login Credentials for GitHub Actions

obsolete, got rid of account name map


Add INT32_MIN, INT32_MAX, INT64_MIN, INT64_MAX constants

These are available in GDScript, Expression and VisualScript expressions.
Since both PackedInt32Array and PackedInt64Array are exposed to GDScript, it makes sense to have constants for both 32-bit and 64-bit integers.
These constants aren't available in VisualScript Math constant nodes because it can only return doubles, not integers.
This closes https://github.com/godotengine/godot-proposals/issues/2411. This PR can be remade for the 3.x branch if desired.

Testing code
print(INT32_MIN)
print(INT32_MAX)
print(INT64_MIN)
print(INT64_MAX)

print()
print(-INT32_MIN)
print(-INT32_MAX)
print(-INT64_MIN)
print(-INT64_MAX)

print()
print(2 * INT32_MIN)
print(2 * INT32_MAX)
print(2 * INT64_MIN)
print(2 * INT64_MAX)

print()
var exp = Expression.new()
exp.parse("INT64_MAX")
print(exp.execute())

Should print:
-2147483648
2147483647
-9223372036854775808
9223372036854775807

2147483648
-2147483647
-9223372036854775808
-9223372036854775807

-4294967296
4294967294
0
-2

9223372036854775807

Why did you decide not to add INT8_MIN, INT8_MAX, INT16_MIN, INT16_MAX, UINT8_MAX, UINT16_MAX, UINT32_MAX?

I like this. We don't have to do all the defines in one pr.

Why did you decide not to add INT8_MIN, INT8_MAX, INT16_MIN, INT16_MAX, UINT8_MAX, UINT16_MAX, UINT32_MAX?

GDScript doesn't have unsigned integer types and 16-bit types. It does have a 8-bit type (part of PackedByteArray), but I think -127/127/255 are obvious enough for 8-bit :slightly_smiling_face:

They are rather general constants, they are not tied to a specific language. In addition, there are methods File.{get,store}_{8,16,32,64}. And 8,16,32 are unsigned.
For example:
Before:
extends File

func store_8c(val: int) -> void:
    store_8(clamp(val, 0, 255))

func store_16c(val: int) -> void:
    store_16(clamp(val, 0, 65535))

func store_32c(val: int) -> void:
    store_32(clamp(val, 0,<PHONE_NUMBER>))

After:
extends File

func store_8c(val: int) -> void:
    store_8(clamp(val, 0, UINT8_MAX))

func store_16c(val: int) -> void:
    store_16(clamp(val, 0, UINT16_MAX))

func store_32c(val: int) -> void:
    store_32(clamp(val, 0, UINT32_MAX))

They are rather general constants, they are not tied to a specific language. In addition, there are methods File.{get,store}_{8,16,32,64}. And 8,16,32 are unsigned.
For example:
Before:
extends File

func store_8c(val: int) -> void:
    store_8(clamp(val, 0, 255))

func store_16c(val: int) -> void:
    store_16(clamp(val, 0, 65535))

func store_32c(val: int) -> void:
    store_32(clamp(val, 0,<PHONE_NUMBER>))

After:
extends File

func store_8c(val: int) -> void:
    store_8(clamp(val, 0, UINT8_MAX))

func store_16c(val: int) -> void:
    store_16(clamp(val, 0, UINT16_MAX))

func store_32c(val: int) -> void:
    store_32(clamp(val, 0, UINT32_MAX))

I'm OK with adding these constants but I'm a tad concerned about the amount of boilerplate needed to do so, effectively adding new keywords to GDScript, etc. for this.
Wouldn't it be simpler to add those as constants in @GlobalScope instead?

It may be nice to have INT_MIN and INT_MAX as aliases for INT64_MIN and INT64_MAX for newbies. Seems like a lot of c++ compilers define those aliases for whatever the default int define is.

It may be nice to have INT_MIN and INT_MAX as aliases for INT64_MIN and INT64_MAX for newbies. Seems like a lot of c++ compilers define those aliases for whatever the default int define is.

I think explicit is better than implicit here.

Oh, like this, very useful.

This would be useful in networking too.
I share Akiens concerns however, this seems like a lot of code to add some constants. Not sure if there is a better way, though.

I dont think this PR looks right, either these are global constants or keywords. Just add them as global constants.
This also needs approval by @vnen to be merged.

Hi. I think these should be in @Globalscope alongside NAN and INF. Would be very handy 👍
Also just an idea. How about using something like INT_8_SIZE, INT_16_SIZE, INT_32_SIZE, INT_64_SIZE for maximums then just use negative sign to get minimum similar to how INF is handled?
print(-INT_32_SIZE) #MIN
print(INT_32_SIZE) #MAX
Removes the number of constants to be added and redundant cases plus it can help with special case -INT_16_SIZE  which would become 0 and plus a warning that is unsigned.

Any intention to salvage this?

I still think this is a good idea, the original developer has deleted the github account.

As discussed above, these should be added directly as constants in the @GlobalScope, not as language keywords.

As discussed above, these should be added directly as constants in the @GlobalScope, not as language keywords.

For reference, this was done by https://github.com/godotengine/godot/pull/68999.


feat: add Astra source connector

Thanks to @erichare we now have an AstraDB source connector.
updating constant names to be more aligned with AstraDB

Needs an example and docs

Also thanks @erichare !


Upgrade to newest Alerts srcdep

@jpkrohling could you please review and eventually merge?

Other than the comment above, it looks sane to me.

b1b8310 is fixing the metrics version.
@jpkrohling please merge.


Automation Step 1 done manually.

Running the commands manually.  I do notice the update_deps.sh terminated before it could update the proxy SHA:
sed: 1: "prow/release-commit.sh": extra characters at the end of p command

@ericvn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
e6a18d2fc320cbac8ad4d23c7a8c1e38f7bdf0ce
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
e6a18d2fc320cbac8ad4d23c7a8c1e38f7bdf0ce
link
/test lint_istio

unit-tests_istio
e6a18d2fc320cbac8ad4d23c7a8c1e38f7bdf0ce
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
e6a18d2fc320cbac8ad4d23c7a8c1e38f7bdf0ce
link
/test unit-tests_istio

lint_istio
66c0d92f73813788114152d2496e0ee62f1cfb30
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
66c0d92f73813788114152d2496e0ee62f1cfb30
link
/test lint_istio

unit-tests_istio
66c0d92f73813788114152d2496e0ee62f1cfb30
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
66c0d92f73813788114152d2496e0ee62f1cfb30
link
/test unit-tests_istio

lint_istio
39bed7870686c936653a64a1a090e2e1eaa5d388
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ericvn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
39bed7870686c936653a64a1a090e2e1eaa5d388
link
/test lint_istio

unit-tests_istio
39bed7870686c936653a64a1a090e2e1eaa5d388
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Option to disable key enhancement

Hi,
Not an issue but a remark...
Maybe is a good idea to make a boolean in the config file to remove the ToggleMenuControl. Ofc we can put nothing in config file to not let it trigger, but is will alway execute the native that is not nessesary. It is great that enableing/disableing event is in the config file already. I will make it work only ls cusom can have access to the menu.

With artifacts from development branch you can choose to:

Assign -1 as ToggleMenuControl so it doesn't toggle with any control
Expose the event to toggle the menu
Expose the command to toggle the menu
Disable the menu completely (no instance is created at all) and use exports API to edit values from you own script/ui

I know that in order to have a strong permissions system it needs to have a server side script, that's something I'll add for the future but I'm not focusing on it right now.
A workaround could be implementing permissions in your own script/ui and use exports to do what you want.

okay i ll have a look into it. Thanks for your reply


Returning cache expired data if there is no network

Hi,
I want a query to be cached during 12h, after 12h I want it to make a request to the server. The issue is that I also need to be able to return the data when there is no connection and in some cases, the cache will be expired and will return an error.
This is my code:
apolloClient.query(query)
            .httpCachePolicy(HttpCachePolicy.CACHE_FIRST.expireAfter(12, TimeUnit.HOURS))

I need to configure the cache in such a way that data is only requested to the server every 12h but cached data is returned if the user has no internet (even when 12h passed since the last successful request).
Is there a way to accomplish this? Can I configure the cache to don't remove the expired data (only setting a flag "expired" to it) so it can be reused?
Thanks!

Hi 👋  I'm afraid this is not possible using the Apollo APIs but maybe this can be done using the OkHttp cache. ApolloClient takes a OkHttpClient parameter so you could maybe configure the cache there?

Thanks a lot for the quick answer @martinbonnin. I found a very old issue where there is a discussion that could be related to this topic. The issue was closed and the API has changed a lot in the last years, do you know if there are plans to implement something like NETWORK_BEFORE_STALE policy?

Signals the apollo client to first fetch the data from the network request. If the network request fails, then the data is fetched from the http cache even if it has become stale.

There are a lot of improvements we'd like to do to the cache that we're trying to keep track of there: https://github.com/apollographql/apollo-android/issues/2331.
Most of them are around the normalized cache at this point so it'll most likely come first.

Do you think this change could be done to the HTTP cache? Is there a list of improvements for the HTTP cache?

The above ticket is a mixed bag that lists everything cache-related (HTTP and normalized, memory and SQL, etc...).
Changes to the HTTP cache can definitely be done but I have no idea when that could land.

The above ticket is a mixed bag that lists everything cache-related (HTTP and normalized, memory and SQL, etc...).

Then, can you add this to the list? I think is better to have it there and close this issue, what do you think?

Then, can you add this to the list? I think is better to have it there and close this issue, what do you think?

It should be there already :-). It's called Network before stale but I can rename if needed.

Sorry I just saw it. We can close this issue then. Thanks!!


cargo install [--git?] ignores .cargo/config.toml, making packages publishable-but-unbuildable, allthewhile they work when built normally

Problem
As given in title.
Steps

git clone --branch v2.0.0 https://github.com/thecoshman/http
cargo build it from the directory (works)
cargo install --git --branch v2.0.0 https://github.com/thecoshman/http (or whatever the spelling is, this is currently HEAD) –

   Compiling rand v0.7.3
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> /home/nabijaczleweli/.cargo/registry/src/index.crates.io-6f17d22bba15001f/brotli-6.0.0/src/lib.rs:8:39
  |
8 | #![cfg_attr(feature = "simd", feature(portable_simd))]
  |                                       ^^^^^^^^^^^^^

Removing features = simd from brotli fixes it.

Possible Solution(s)
No response
Notes
May have something to do with .cargo/config.toml setting env.RUSTC_BOOTSTRAP = 1? But the thing it's used for in the crate itself does work.
Version
$ cargo version --verbose
cargo 1.78.0 (54d8815d0 2024-03-26)
release: 1.78.0
commit-hash: 54d8815d04fa3816edc207bbc4dd36bf18014dbc
commit-date: 2024-03-26
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian 12 (bookworm) [64-bit]

The config env.RUSTC_BOOTSTRAP = 1 is telling stable rust to ignore that error. And config files are ignored for install. That is why you are seeing the error. RUSTC_BOOTSTRAP is a very heavy hammer, one only intended for building the compiler itself.

And yet it is the only way to achieve feature parity of win32 targets with unix ones, since I use it for st_dev and st_ino (https://github.com/rust-lang/rust/issues/63010). But, whatever.
Indeed, I haven't tested cargo install --git on windows, but this does also break that:
error[E0554]: `#![feature]` may not be used on the stable release channel
 --> src/main.rs:1:44
  |
1 | #![cfg_attr(target_os = "windows", feature(windows_by_handle))]
  |                                            ^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0554`.
error: could not compile `https` (bin "http") due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `https` (bin "httplz") due to 1 previous error
error: failed to compile `https v2.0.1 (http://github.com/thecoshman/http#152f4d70)`, intermediate artifacts can be found at `T:\-_-TEM~1\cargo-installbcOmti`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

So this is not "RUSTC_BOOTSTRAP doesn't inherit", as I thought, but
"cargo expressly ignores package configuration when installing", so just make it not do that?
Fixing "we choose to make certain packages publishable-but-unbuildable by ignoring configuration found in the distribution that allows them to be built in the usual case" is done by just not doing that.
Or, as I have just tested, having users set RUSTC_BOOTSTRAP=1 before installing. Not great, but sure.

So if I'm understanding, you are wanting cargo install to use the config file from the --git repo, right?
Config is environmental and not tied to the project (#2930, see #12738 for finding ways the right abstraction for representing config in the project).  According to these rules, cargo install should use the config of your current-dir independent of where the source is.  You can see this if you do cargo check --manifest-path <some-dir> that the config from <some-dir> won't be used, instead requiring something like #10098.  For various reasons, cargo install varies from this pattern and only the user-wide configuration is used and not the config for the current-dir.

Well, if I publish a package (be it via git or by uploading a tarball to crates.io), the fundamental expectation is that it will be built in the same way on the user's machine. This expectation is not being up-held when using the cargo install short-hand but it is if the user explicitly does what cargo install promises to fuse: downloading the tarball (or checking out a worktree), cargo build --release, mv target/... $CARGO_BINS.
If you already have an exception for cargo install for "various reasons", then this means that you can append this issue to those reasons and edit the exception to use the package's configuration, rather than none.

Well, if I publish a package (be it via git or by uploading a tarball to crates.io), the fundamental expectation is that it will be built in the same way on the user's machine.

That is not a fundamental expectation.  cargo build does dev profile by default while cargo install does release profile.  See also #7169.
btw #11036 is a related issue.
And as mentioned, that this is behaving something like cargo build in that its like  ```console
$ cargo build --manifest-path ~/.cargo/git/checkouts/somedep-e7ff1db891893a9e/d04355a/Cargo.toml
*(ie we aren't changing the current-dir on the users behalf)*

The difference is that current-dir is ignored.

This gets to the core of problem: config is environmental and not scoped to a project.  If you aren't in the environment then Cargo doesn't load the config.

> If you already have an exception for cargo install for "various reasons", then this means that you can append this issue to those reasons and edit the exception to use the package's configuration, rather than none at all.

This is something that could be re-evaluated.  It would take some research to see what the trade offs would be.  However, more likely to move forward is efforts like #12738.

Either way, this would be use-case driven and `env.RUSTC_BOOTSTRAP = 1` is not a sympathetic use case to me as you are publishing a package that purportedly can work on any stable release but fundamentally can't.  This is instead a package that requires a nightly toolchain and should recognize that.

if you're trying to imply that because cargo install defaults to --release (which you, in your belaboured expansion, also omitted, like me, because it's irrelevant) while cargo build doesn't, and this is ideologically significant, then idk what to tell you except "lol"
If it's ignored, then unignore it and use the one next to the manifest. or chdir to the build root. this seems very easy to fix.
And no, I'm publishing a package that can work on stable releases which include the windows_by_handle feature in its current or similar form, which is all of them since 1.38 (if I'm reading github's git tag --contains equivalent right; the code, after moving twice, is unchanged and still blames back to the original merge from exactly 5 years ago); this is no different to using any other feature, other than you don't like it.
Usually this is just called MSRV and ignored because it's implicit and fluctuates by accident. I opted into it explicitly. Egad!
I doubt you'll find many packages conforming to your much more stringent "works on any stable release" criterion precisely for this reason.
It's also obviously false that it requires a nightly toolchain, as proven by me using a range of stable toolchains to build it for the past seven years.

if you're trying to imply that because cargo install defaults to --release (which you, in your belaboured expansion, also omitted, like me, because it's irrelevant) while cargo build doesn't, and this is ideologically significant, then idk what to tell you except "lol"

I recommend to please respectfully engage with others and assume they are trying to also participate in good faith with you.  I am going to step away from this conversation for several days (at least) to let things calm down before further participation.

Hey folks, please treat each other with kindness and respect.


Revert "build(deps): update dependency org.apache.maven.plugins:maven-javadoc-plugin to v3.6.0"

Reverts googleapis/java-shared-config#656
This version update currently breaks javadoc generation with v1.9.0+ of the doclet used for Cloud RAD.

Let's see "downstream / javadoc-with-doclet (java-bigtable)".

downstream / javadoc-with-doclet (java-bigtable) (pull_request) Failing after 1m

Error: 4:087 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.6.0:aggregate (default-cli) on project google-cloud-bigtable-parent: Execution default-cli of goal org.apache.maven.plugins:maven-javadoc-plugin:3.6.0:aggregate failed: If a non-null excludes list is given, all elements must be non-null -> [Help 1]

https://github.com/googleapis/java-shared-config/actions/runs/6411009761/job/17405535175?pr=671

The repository declares the independent version (unnecessarily?).
https://github.com/googleapis/java-bigtable/pull/1924


remove unused amqp container from circle's lint job

Codecov Report

Merging #100 (8fa93ee) into master (b9e537f) will not change coverage.
The diff coverage is n/a.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Should some CSPICE functions be written in Python?

There are a few CSPICE functions that are just "numeric" functions.  These are functions that do things like.

Add and subtract arrays
Scale arrays
Take the linear combination of two similarly shaped arrays
Copy and negate arrays
Matrix multiplication of various sorts
Return π

There is no astronomy involved in any of these.  It would be simpler (and faster!) to just implement these in Python and discard the SWIG code.  We would of course still have tests to insure that these are returning the same answers as the SWIG functions.
Anything that deletes SWIG code and C code is a win as far as I'm concerned.  Are there arguments against this?

We decided the answer is...no.


 Why? Because every system puts it somewhere different with a different name.
I say that we only look for llvm-config and the user building from source (including our automated jobs) can use the llvm-config first found in the PATH.
Other option:
use a LLVM_CONFIG env variable that if not set, we will set to llvm-config which will then use first one in PATH.

Personally, I already use LLVM_CONFIG for everything and don't bother with search paths. However, I think we should keep the PATH approach for obvious reasons.
I also think we need to keep the numbered-llvm-config hierarchy where we favor (for example) llvm-config60 over llvm-config50.
But I agree we should try to get rid of platform-specific library path checks in the Makefile.

Unfortunately that numbered hierarchy doesn't work. I just discovered that.
I installed LLVM 7.0.1 from their release page and it installs llvm-config and it took me a while to figure out why I was building with 6.0.0 still.
ARRGHGHG!

Yeah, that's unfortunate.
Okay, now I'm in favor of your earlier suggestion:

use a LLVM_CONFIG env variable that if not set, we will set to llvm-config which will then use first one in PATH.

We tried to be clever, it turned out as clever usually does.


grpc single thread implementation with dialogflow cx finishing issue

environment:
GRPC 1.28.1
Redhat 7
service used from google apis is dialogflow cx v3
ref: https://cloud.google.com/dialogflow/cx/docs/reference/rpc/google.cloud.dialogflow.cx.v3
language: CPP/C++
Compiler: GCC 8.3.1
What did you do?
I am trying to do async streaming of audio input from the microphone to dialogflow cx(server) using grpc
single thread with completion queue and I follow this example, which is taken from speech api documentation
https://github.com/GoogleCloudPlatform/cpp-samples
the sample code is in -> cpp-samples/speech/api/streaming_transcribe_singlethread.cc
and my code flow is similar to that.
After creating all the resources including Channel, CompletionQueue, Context, streamer, Stub, etc
but for Dialogflow CX service.
if i have sent audio to the server but have not done with complete writing
as the user was still speaking so far but now he hangs up while still speaking. how to unwind the grpc resources.
I don't want to wait on any result from the server and want to abort the request quickly but smoothly.
At the moment i am following these steps to maintain graceful resource deallocation but it takes time to wait and server does
not send grpc status NOT ok to send finish as shown in the example, so i am sending finish at step c) from the client side.
a) while audio bytes were written, stop further audio sending
b) send Writes Done and wait for Writes_done complete
c) send finish
d) deallocate the resources
What actually are the steps to close the stream from client side
Can i send finish and deallocate resources without reading completion queue for any messages in there? see below concerns
Some experiments i did which led to segmentation fault.

sometimes if the user was starting to speak and he hangs up without client code sending any audio bytes but
sending Writes Done leads to segmentation fault 1) below

if finish is sent without waiting to read the completion queue for the Writes done, i see the segmentation fault 2) below

What did you expect to see?
smooth unwinding of grpc stack when i send Writes Done or Finish
What did you see instead?
segmentation fault

If i try to do WritesDone and try to finish i see this segmentation fault
#0  0x00007f00e29763d7 in raise () from /lib64/libc.so.6
#1  0x00007f00e2977ac8 in abort () from /lib64/libc.so.6
#2  0x00007f007ceb3db4 in grpc::CoreCodegen::assert_fail (this=,
failed_assertion=, file=, line=)
at src/cpp/common/core_codegen.cc:237
#3  0x00007f007bdd0c1c in grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpClientSendClose, grpc::internal::CallNoOp<4>, 	grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::ContinueFillOpsAfterInterception (this=0x7f00b80520e8)
at /home/user/xs.7861e0.rh7/grpc-<IP_ADDRESS>2777/include/grpcpp/impl/codegen/call_op_set.h:947
#4  0x00007f007bdd09a2 in grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpClientSendClose, grpc::internal::CallNoOp<4>, 	grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::FillOps (this=0x7f00b80520e8, call=0x7f00b8051e00)
at /home/user/xs.7861e0.rh7/grpc-<IP_ADDRESS>2777/include/grpcpp/impl/codegen/call_op_set.h:868
#5  0x00007f007bdc82af in grpc::internal::Call::PerformOps (this=0x7f00b8051e00, ops=0x7f00b80520e8)
at /home/user/xs.7861e0.rh7/grpc-<IP_ADDRESS>2777/include/grpcpp/impl/codegen/call.h:69
#6  0x00007f007bdd0fe8 in grpc_impl::ClientAsyncReaderWriter<google::cloud::dialogflow::cx::v3::StreamingDetectIntentRequest, 	google::cloud::dialogflow::cx::v3::StreamingDetectIntentResponse>::WritesDone (
this=0x7f00b8051de0, tag=0x7f00b8212990)
at /home/user/xs.7861e0.rh7/grpc-<IP_ADDRESS>2777/include/grpcpp/impl/codegen/async_stream_impl.h:584

Is there any timer that runs for the allocated channel(resource) as i have seen sometimes if i don't follow the above steps to gracefully unwind, sometimes i see this coredump on my box.
#0  0x00007fc7f45e3776 in publish_app_metadata (call=call@entry=0x7fc83c03b8a0,
    is_trailing=is_trailing@entry=1, b=<optimized out>, b=<optimized out>)
    at src/core/lib/surface/call.cc:1004
#1  0x00007fc7f45e61f3 in recv_trailing_filter (batch_error=<optimized out>, b=0x7fc83c03bce0,
    args=0x7fc83c03b8a0) at src/core/lib/surface/call.cc:1084
#2  receiving_trailing_metadata_ready (bctlp=0x7fc83c0cc700, error=<optimized out>)
    at src/core/lib/surface/call.cc:1528
#3  0x00007fc7f465e3cb in Run (location=..., error=0x0, closure=<optimized out>)
    at ./src/core/lib/iomgr/closure.h:245
#4  grpc_core::SubchannelCall::RecvTrailingMetadataReady (arg=0x7fc83c071b80, error=0x0)
    at src/core/ext/filters/client_channel/subchannel.cc:296
#5  0x00007fc7f46afa8f in Run (location=..., error=0x0, closure=<optimized out>)
    at ./src/core/lib/iomgr/closure.h:245
#6  recv_trailing_metadata_ready (user_data=<optimized out>, error=0x0)
    at src/core/ext/filters/message_size/message_size_filter.cc:235
#7  0x00007fc7f4612424 in Run (location=..., error=0x0, closure=<optimized out>)
    at ./src/core/lib/iomgr/closure.h:245
#8  recv_trailing_metadata_ready (user_data=<optimized out>, error=0x0)
    at src/core/ext/filters/http/client/http_client_filter.cc:212
#9  0x00007fc7f45c54e1 in exec_ctx_run (closure=<optimized out>, closure=<optimized out>, error=0x0)
    at src/core/lib/iomgr/exec_ctx.cc:153
#10 grpc_core::ExecCtx::Flush (this=0x7fc7e88c5cf0) at src/core/lib/iomgr/exec_ctx.cc:153
#11 0x00007fc7f45c13b6 in pollset_work (pollset=0x7fc830208980, worker_hdl=<optimized out>,
    deadline=<optimized out>) at ./src/core/lib/iomgr/exec_ctx.h:216
#12 0x00007fc7f464113c in run_poller (error=0x0, arg=0x7fc83016de30) at ./src/core/lib/iomgr/exec_ctx.h:216
#13 run_poller (arg=0x7fc83016de30, error=<optimized out>)
    at src/core/ext/filters/client_channel/backup_poller.cc:114
#14 0x00007fc7f45c54e1 in exec_ctx_run (closure=<optimized out>, closure=<optimized out>, error=0x0)
    at src/core/lib/iomgr/exec_ctx.cc:153
#15 grpc_core::ExecCtx::Flush (this=0x7fc7e88c5cf0) at src/core/lib/iomgr/exec_ctx.cc:153
#16 0x00007fc7f45d7b19 in run_some_timers () at ./src/core/lib/iomgr/exec_ctx.h:216
#17 timer_main_loop () at src/core/lib/iomgr/timer_manager.cc:237
#18 timer_thread (completed_thread_ptr=0x7fc8100218d0) at src/core/lib/iomgr/timer_manager.cc:284
#19 0x00007fc7f49ffaa3 in operator() (__closure=0x0, v=<optimized out>) at src/core/lib/gprpp/thd_posix.cc:140
#20 grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) ()
    at src/core/lib/gprpp/thd_posix.cc:145
#21 0x00007fc7f49ffaa3 in ThreadInternalsPosix (options=..., success=<optimized out>, arg=<optimized out>,
    thd_body=<optimized out>, thd_name=<optimized out>, this=<optimized out>)
   from /home/user/lib/libs_grpc++.so
#22 grpc_core::Thread::Thread (this=<optimized out>, thd_name=<optimized out>, thd_body=<optimized out>,
    arg=<optimized out>, success=<optimized out>, options=...) at src/core/lib/gprpp/thd_posix.cc:186

Please try with a modern gRPC version.


[BEAM-13800] Avoid packaging avro in the java harness jar.

Unfortunately we can't simply shade it, as it's used in the public API
(AvroCoder) of sdks:java:core.  However, outside that use, it should not
be needed when running in portable mode.  Users will have to provide
their own avro (typically by depending on sdks:java:core, but possibly
choosing another version explicitly or from elsewhere).

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Failure in sdks:java:container:pullLicenses.

Run Java_PVR_Flink_Docker PreCommit

Run Java PreCommit

Running into BEAM-13708 flake.

Run Java PreCommit

R: @emilymye

Thanks.
Do you know if the Java 17 presubmit expected to pass yet?

Run Java PreCommit

Would it have made more sense to exclude sdks-java-core from shading since we expect the user to supply it?

I would be OK with this, but it seemed significantly more invasive, as we need some stuff (e.g. DoFns, Coders) from sdks-java-core. This would imply that we're OK with them providing their version of these dependencies (which feels a lot like simply putting their jars on the classpath first).

I would see that as a benefit since it increases the likelihood that the serialized java objects from sdks-java-core will be compatible on the worker since the version that serialized them would be what was used at pipeline construction time and then used during execution.

Makes sense. https://github.com/apache/beam/pull/16740


Missed cast for fraction long value

https://github.com/FabLabsMC/FluidApi/blob/75c1ecdd37664e9a6e71db0d0c193e168e0704df/src/main/java/io/github/fablabsmc/fablabs/api/fluid/v1/math/Fraction.java#L307

oh right, since we changed to longs. We're gonna be changing this because of #5 leaning towards whole+ints at the moment, so we'll see.


Set C_Cpp.default.configurationProvider VSCode setting.

Without this, Intellisense doesn't work on my system for cesium-native opened on the extern directory. It shows red squiggles for most errors because it apparently can't resolve the include directory. It used to work, so I'm not sure what changed, but we already have this setting in cesium-native itself and there should be no harm in adding it here, too.

Thanks for the pull request @kring!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.


Add banner to all non-login screen pages

Create a banner to go on top of most pages that allows you to navigate to a list of students, teachers, rooms, and classes

Can you sketch out how you think this would work? There already is a material toolbar at the top, we could add stuff to that (i.e. a tab strip)

@guberti what needs to be done here?

@guberti ping

Ditched idea. Decided on a different approach.


[Feature Request]: async blob submissions

Implementation ideas
the api should have a way to let users submit async blob submission calls
should be delivered in tandem with https://github.com/celestiaorg/celestia-node/issues/3164
ref: https://github.com/celestiaorg/celestia-node/issues/3256

Any plans to return result statuses through a channel on async blob submission? Like INCLUDED, FINALIZED, CANCELLED etc

@0xRampey yes something like that, we are considering adding an endpoint to blob module that would be able to submit a tx and query for its status, returning the result through a channel once included.

The current Signer integration doesn't make blob submission async. Yes, it changed the tx submission mode from Block to Sync, but this line makes it equivalent to what we had before


timeFormat not applied

when I put custom time format, the format is applied in input field but is not applied in timepicker dropdown
<Datetime dateFormat={false} timeFormat={'hh:mm a'} viewMode={'time'} />
demo here

Hi @martinvondracek. If you change the timeFormat string to 'hh:mm A' - does it solve your issue?

Hi @simeg, yes it works with 'hh:mm A' but unfortunately I need with small 'a' - 'h:mm a'

This seems to be a bug, looking into it.

@martinvondracek this has now been fixed with the following commit: https://github.com/YouCanBookMe/react-datetime/commit/cf1e721e0d7c69b5ce55978c213ef463ab477ebc
The bug fix is published in version 2.8.1. Thanks.


External Validation of Purchase

I can't seem to figure out how to validate the receipt externally.
?What is the proper structure for:
{
    "data": {},
    "signature": ""
}

because mine looks like this:
function purchaseCompleted(e) {
	if (e.success && e.purchase) {
		alert('Purchase completed successfully');
                Ti.API.info(JSON.stringify(e.purchase);

///result is:

{
    "receipt": {
        "bubbleParent": true,
        "developerPayload": "P4yl04d",
        "productId": "subscriptiontrails",
        "packageName": "com.eagledevelopers.appname",
        "type": "subs",
        "purchaseState": 0,
        "apiName": "Ti.Proxy",
        "token": "hidden",
        "signature": "hidden",
        "purchaseTime":<PHONE_NUMBER>406,
        "orderId": ""
    }
}

I'm using this node module to validate and they have a web tool for testing on the fly. I can't get either to work.
http://iap.gracenode.org/
I've tried removing bubbleParent, apiName, and moving signature. No combo works.

I was missing developer payload, the structure should look like this:
{
    "data": {
        "packageName": "",
        "productId": "",
        "purchaseTime": 0,
        "purchaseState": 0,
        "developerPayload": "",
        "purchaseToken": "",
        "autoRenewing": false
    },
    "signature": ""
}

Well, something happened inbetween July 1st and now and subscription validation was failing. I got fed up trying to create the payload manually so I created a PR to get the RAW receipt from the Purchase class. You now just send the following to your backend, which is running validation module such as NPM:in-app-purchase
function purchaseCompleted(e) {
	Ti.API.debug('Purchase response: ' + responseString(e.responseCode));
	if (e.success && e.purchase) {
		alert('Purchase completed successfully');

		//Ti.API.log("GOOGLE Response: " + JSON.stringify(e));
		//Ti.API.log("GOOGLE Purchase: " + JSON.stringify(e.purchase));
		Ti.API.log("GOOGLE Receipt: " + JSON.stringify(e.purchase.getReceipt()

Your receipt will now be the following, which is exactly what you need to send to validate externally:
{
  "data": {\"stringified originalPurchaseJSON here"\},
  "signature": "string_signature_here"
}

Here's the PR
https://github.com/appcelerator-archive/ti.inappbilling/pull/23


Update code.gitea.io/git

Includes https://github.com/go-gitea/git/pull/110. Also updates repo indexer code to use newly-added ParseTreeEntries(..) function.

Codecov Report

Merging #3482 into master will decrease coverage by <.01%.
The diff coverage is 45.45%.

@@            Coverage Diff             @@
##           master    #3482      +/-   ##
==========================================
- Coverage   35.69%   35.68%   -0.01%
==========================================
  Files         281      281
  Lines       40708    40695      -13
==========================================
- Hits        14530    14523       -7
+ Misses      24029    24026       -3
+ Partials     2149     2146       -3

Impacted Files
Coverage Δ

models/git_diff.go
59.18% <0%> (-0.98%)
:arrow_down:

models/repo_indexer.go
48.3% <76.92%> (+0.85%)
: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 58771ac...7bd8b37. Read the comment docs.

LGTM