text:
[Python] gRPC unable to listen on IPv4 and also blocks out the port on IPv4

What version of gRPC and what language are you using?
grpcio v1.57.0
What operating system (Linux, Windows,...) and version?
Tried on: Ubuntu 22.04, Ubuntu 20.04, WSL2 (Ubuntu 20.04)
What runtime / compiler are you using (e.g. python version or version of gcc)
python v3.10.12
What did you do?
I simply used the examples & tutorials provided and start a gRPC server.
def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    route_guide_pb2_grpc.add_RouteGuideServicer_to_server(RouteGuideServicer(), server)
    server.add_insecure_port("0.0.0.0:50053")
    server.start()
    server.wait_for_termination()

OR
def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    route_guide_pb2_grpc.add_RouteGuideServicer_to_server(RouteGuideServicer(), server)
    server.add_insecure_port("localhost:50053")
    server.start()
    server.wait_for_termination()

OR
def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    route_guide_pb2_grpc.add_RouteGuideServicer_to_server(RouteGuideServicer(), server)
    server.add_insecure_port("127.0.0.1:50053")
    server.start()
    server.wait_for_termination()

What did you expect to see?
I expect to see it listening on IPv4 like a good boy.
What did you see instead?
But it did not and when ahead and open IPv6 while blocking IPv4 port out (I couldn't use IPv4 port, nor could I connect to it).

I am able to connect it through the IPv6 address it decided to use without my permission.
I am also able to connect it if I port forward from IPv4 --> IPv6 and starting the server on IPv6 strictly only with "[::]:50053"
Anything else we should know about your project / environment?

Same problem here, it makes gRPC unusable.

I can reproduce it locally, @markdroth do you know if this is expected? Maybe it's related to dual stack?

Same problem here with grpcio version 1.60.0 and python 3.11. I tried it on grpc node js and works fine.
Just change from 0.0.0.0 or 127.0.0.1 to IP address of the machine. Big issue.

@XuanWang-Amos I doubt this has anything to do with the dualstack changes, since those changes were all on client side, and this is a server-side issue.

This behavior should be entirely dictated by core. It's easily reproducible and it really does seem like this is not the best behavior here. @yashykt Do you know what's going on here? Does C++ have the same behavior?

Sorry, this fell into the cracks. I just tested this out. Works for C++.
For some context, gRPC Core intentionally treets "0.0.0.0" as a family agnostic wildcard and the server should be listening on both ipv4 and ipv6.

authors: JC3 Jefferson111 XuanWang-Amos gnossen markdroth nishit-rapidops yashykt


text:
Memory Leak When Terminating Synchronous Example

When I terminate the Greeter_Service using ctr+c I Valgrind reports the following memory leak:
~/grpc/examples/cpp/helloworld$ valgrind --leak-check=full ./greeter_server
==5127== Memcheck, a memory error detector
==5127== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5127== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5127== Command: ./greeter_server
==5127==
I0401 06:04:21.182220402    5127 socket_utils_common_posix.c:148] Disabling AF_INET6 sockets because ::1 is not available.
Server listening on 0.0.0.0:50051
^C==5127==
==5127== Process terminating with default action of signal 2 (SIGINT)
==5127==    at 0x531ADA0: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.S:185)
==5127==    by 0x57E3CDB: std::condition_variable::wait(std::unique_lockstd::mutex&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==5127==    by 0x4E6458A: grpc::Server::Wait() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x412166: RunServer() (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==    by 0x412262: main (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==
==5127== HEAP SUMMARY:
==5127==     in use at exit: 5,328,398 bytes in 200 blocks
==5127==   total heap usage: 863 allocs, 663 frees, 5,365,368 bytes allocated
==5127==
==5127== 624 bytes in 1 blocks are possibly lost in loss record 112 of 120
==5127==    at 0x4C2DB95: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5127==    by 0x4013504: allocate_dtv (dl-tls.c:322)
==5127==    by 0x4013504: _dl_allocate_tls (dl-tls.c:544)
==5127==    by 0x53160D2: allocate_stack (allocatestack.c:588)
==5127==    by 0x53160D2: pthread_create@@GLIBC_2.2.5 (pthread_create.c:537)
==5127==    by 0x57E9172: std::thread::_M_start_thread(std::shared_ptrstd::thread::_Impl_base, void ()()) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==5127==    by 0x4E6092A: grpc::DynamicThreadPool::DynamicThread::DynamicThread(grpc::DynamicThreadPool) (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E60F93: grpc::DynamicThreadPool::DynamicThreadPool(int) (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E603AD: grpc::CreateDefaultThreadPool() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E68D40: grpc::ServerBuilder::BuildAndStart() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x412121: RunServer() (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==    by 0x412262: main (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==
==5127== 262,159 bytes in 1 blocks are possibly lost in loss record 117 of 120
==5127==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5127==    by 0x50DE379: gpr_malloc (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50DE3DE: gpr_malloc_aligned (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50E044F: gpr_stack_lockfree_create (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50CBF17: grpc_server_create_from_filters (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50CD294: grpc_server_create (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x4E64744: grpc::Server::Server(grpc::ThreadPoolInterface*, bool, int, grpc::ChannelArguments const&) (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E68E58: grpc::ServerBuilder::BuildAndStart() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x412121: RunServer() (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==    by 0x412262: main (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==
==5127== 262,159 bytes in 1 blocks are possibly lost in loss record 118 of 120
==5127==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5127==    by 0x50DE379: gpr_malloc (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50DE3DE: gpr_malloc_aligned (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50E044F: gpr_stack_lockfree_create (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50CBF7F: grpc_server_create_from_filters (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50CD294: grpc_server_create (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x4E64744: grpc::Server::Server(grpc::ThreadPoolInterface*, bool, int, grpc::ChannelArguments const&) (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E68E58: grpc::ServerBuilder::BuildAndStart() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x412121: RunServer() (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==    by 0x412262: main (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==
==5127== 262,159 bytes in 1 blocks are possibly lost in loss record 119 of 120
==5127==    at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5127==    by 0x50DE379: gpr_malloc (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50DE3DE: gpr_malloc_aligned (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50E044F: gpr_stack_lockfree_create (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x50CC154: grpc_server_register_method (in /usr/local/lib/libgrpc.so.0.14.0-dev)
==5127==    by 0x4E62AFB: grpc::Server::RegisterService(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const*, grpc::Service*) (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x4E68EC0: grpc::ServerBuilder::BuildAndStart() (in /usr/local/lib/libgrpc++_unsecure.so.0.14.0-dev)
==5127==    by 0x412121: RunServer() (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==    by 0x412262: main (in /home/ochowie/grpc/examples/cpp/helloworld/greeter_server)
==5127==
==5127== LEAK SUMMARY:
==5127==    definitely lost: 0 bytes in 0 blocks
==5127==    indirectly lost: 0 bytes in 0 blocks
==5127==      possibly lost: 787,101 bytes in 4 blocks
==5127==    still reachable: 4,541,297 bytes in 196 blocks
==5127==         suppressed: 0 bytes in 0 blocks
==5127== Reachable blocks (those to which a pointer was found) are not shown.
==5127== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5127==
==5127== For counts of detected and suppressed errors, rerun with: -v
==5127== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)

Sorry to be blunt, but, my answer would be, "so ?"
You did stop the server using CTRL-C, meaning no shutdown path took place, and the example clearly states that there's no shutdown implemented in it anyway. I fail to understand the point you're trying to make here. There's no bug here, aside from the fact the example doesn't demonstrate how to initiate a shutdown.

Fair point. However, I did move the wait into a different thread and used the main thread to shutdown the server after receiving input from cin. Here is the code I used, it's possible there is an issue with my code and I'm still not shutting the server down correctly but it is similar to an SO thread on shutting a server down (and I haven't found any other examples).
` auto waitFn = & {
server->Wait();
};
std::thread serverThread (waitFn);

int test;

std::cin >> test;
server->Shutdown();`

Right, okay. So as you do this, you're in fact not waiting on the server to actually shut down. You're initiating the shutdown, and it's probably starting to take place into the other thread, but as Shutdown() is a non-blocking call, you go at the end of main() without all of the shutdown sequence to actually happen, which exits the process without waiting for the threads to finish cleanly.
There's several things you can do at that point to make it right:
-) Wait on a semaphore or something after calling server->Shutdown(), and trigger that semaphore after server->Wait().
-) Invert your logic and do the console reading + shutdown from another thread, while doing the wait in main.
-) Initiate the shutdown in the SayHello callback. The server will only reply to one hello then exit.
-) Add another message to shutdown the server.

Thanks for the help. Closing this down.

source: gharchive/issue

authors: nicolasnoble ochowie

repo: grpc/grpc

license_type: permissive

license_source: github-api


text:
*.orig files are unnecessary?

These files is generated for merge code?
https://github.com/grpc/grpc/blob/master/tools/doxygen/Doxyfile.c%2B%2B.internal.orig
https://github.com/grpc/grpc/blob/master/src/core/lib/http/parser.c.orig

Looks like they were erroneously introduced in dd385b6a19832992f130e55f33a02514b0bb4058.

@ctiller: what would you think of adding .orig-screening to the sanity tests?

https://github.com/grpc/grpc/pull/7242 was trying to remove one. I just
added another one. THanks.
On Fri, Jul 8, 2016 at 5:01 PM, Nathaniel Manista notifications@github.com
wrote:

@ctiller https://github.com/ctiller: what would you think of adding
.orig-screening to the sanity tests?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/7280#issuecomment-231499804, or mute
the thread
https://github.com/notifications/unsubscribe/AJp0Ciw9pMvT9XTDNfQcJD2fjdDRbmSJks5qTuTWgaJpZM4JH41o
.

Uuuuuugh. Sorry about this. Mea culpa.

@nathanielmanistaatgoogle @ctiller I have added *.orig in .gitignore file, and added orig file screen, but the screening really needs? In fact, I think that it is OK for adding *.orig in .gitignore.

Fixed #7296

authors: dgquintas nathanielmanistaatgoogle thinkerou yang-g


text:
Recursive stack corruption in PHP7

Hi,
I got a segmentation fault today while using pixelfedrations/vitess-pdo-php which uses gRPC as its communication backend. I tried to see what actually happens with gdb and I saw there is an endless recursion:
#0  0x00005555556d4ec0 in zif_count ()
#1  0x000055555578fe4b in dtrace_execute_internal ()
#2  0x000055555581cc54 in ZEND_DO_FCALL_SPEC_HANDLER ()
#3  0x00005555557de72b in execute_ex ()
#4  0x000055555578fd29 in dtrace_execute_ex ()
#5  0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#6  0x00005555557de72b in execute_ex ()
#7  0x000055555578fd29 in dtrace_execute_ex ()
#8  0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#9  0x00005555557de72b in execute_ex ()
#10 0x000055555578fd29 in dtrace_execute_ex ()
#11 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#12 0x00005555557de72b in execute_ex ()
#13 0x000055555578fd29 in dtrace_execute_ex ()
#14 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#15 0x00005555557de72b in execute_ex ()
#16 0x000055555578fd29 in dtrace_execute_ex ()
#17 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#18 0x00005555557de72b in execute_ex ()
#19 0x000055555578fd29 in dtrace_execute_ex ()
#20 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#21 0x00005555557de72b in execute_ex ()
#22 0x000055555578fd29 in dtrace_execute_ex ()
#23 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#24 0x00005555557de72b in execute_ex ()
#25 0x000055555578fd29 in dtrace_execute_ex ()
#26 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#27 0x00005555557de72b in execute_ex ()
#28 0x000055555578fd29 in dtrace_execute_ex ()
#29 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#30 0x00005555557de72b in execute_ex ()
#31 0x000055555578fd29 in dtrace_execute_ex ()
#32 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
.
.
.
#120735 0x00005555557de72b in execute_ex ()
#120736 0x000055555578fd29 in dtrace_execute_ex ()
#120737 0x000055555581c920 in ZEND_DO_FCALL_SPEC_HANDLER ()
#120738 0x00005555557de72b in execute_ex ()
#120739 0x000055555578fd29 in dtrace_execute_ex ()
#120740 0x000055555582889f in zend_execute ()
#120741 0x000055555579fa43 in zend_execute_scripts ()
#120742 0x0000555555740a48 in php_execute_script ()
#120743 0x000055555582a508 in do_cli ()
#120744 0x000055555562481a in main ()

I don't know how php native extensions work. Though I will continue trying to figure it out.

Can you share some code snippet that caused this?

Sorry for false alarming, I found that there was a recursion in my code so it wasn't gRPC. Though PHP 7 has a bug that it doesn't keep track of recursive methods and it will crash if someone does it so.

authors: mdhheydari stanley-cheung


text:
Use shortname for shortname for json_run_localhost tests

Whenever this goes in, it'll throw the scheduling and flakiness metrics for a few days.
However, once it is in, future changes to scenarios won't further mess up this data.

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

source: gharchive/pull-request

authors: ctiller grpc-jenkins


text:
Refactor ServerServiceDefinition and move it to Grpc.Core.Api nuget.

Followup for #17778

change ServerServiceDefinition so that it no longer references internal Grpc.Core types.  Instead, it stores lambdas that are later used to invoke AddMethod<,>() calls on ServiceBinderBase (the advantage is that it preserves generic context)
move ServerServiceDefinition and ServiceBinderBase
refactor Interceptor code as the new ServerServiceDefinition makes intercepting the handlers easier.

Known failures: https://github.com/grpc/grpc/issues/17561

@JunTaoLuo @JamesNK I believe the review comments have been addressed sufficiently, so I'm going to merge now. If there are still any concerns, we can address in a followup PR.

One suggestion if you could swap out the dictionary for a hashset of string. It’s not important though.

@JamesNK   I considered that, but HashSet.Add doesn't throw if the key already exists, so using dictionary.Add seemed safer in terms of preserving the old behavior.

Not sure if we can access your link without an @google.com login. We'll just wait for the packages to be available on packages.grpc.io.

Not sure if we can access your link without an @google.com login. We'll just wait for the packages to be available on packages.grpc.io.

The link is public, so you should be able to just download.
But packages.grpc.io  already has the nugets: https://packages.grpc.io/archive/2019/02/977df7208a6e3f9a62a6369af5cd6e4b69b4fdec-a9f2947c-fd01-4598-9af0-93e276d53335/index.xml

authors: JamesNK JunTaoLuo jtattermusch


text:
Remove XdsClient from channel args to fix subchannel sharing.

Each channel has its own XdsClient, which is added to channel args.  The channel args then form the key used in the subchannel pool.  This means that each channel winds up using a different key for the same address, which inhibits subchannel sharing.  Removing the XdsClient from channel args before we get down to the leaf LB policy fixes this problem.

Known issues: #23066


text:
Fix fetching CXX variable in setup.py

While building the Python package for a poky-based custom distribution I have stumbled upon an issue caused by the mechanism of subprocess invocation.
setup.py in check_linker_need_libatomic function verifies whether inclusion of atomic library is necessary. It is done by invoking a C++ compiler in a subprocess and the compiler's name is read from CXX environmental variable. In a bitbake managed build context this variable holds not only compiler's executable but various compiler flags as well, in my case the contents of this variable are:
arm-poky-linux-gnueabi-g++ -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wdate-time --sysroot=<redacted>/build/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/grpcio/1.43.0-r0/recipe-sysroot

Proposed solution of the issue is to split the contents of the variable and take only the first element of the resulting list. Possibly it would be better to preserve all the flags though I don't think it is necessary as we only need to know whether -latomic switch is required (I don't think the outcome depends on CPU model, instruction set or floating-point ABI).
This PR resolves #25362

@kacper-ka can you be more specific about what are the example value of CXX in your case, and why will it contain that many content?

@kacper-ka In your case, if the content of CXX includes unwanted arguments, you can clean it before compiling. On the other hand, people can put magic in the CXX env var. E.g., add a Python wrapper to compiler, add a few compiler arguments. I think gRPC should at least not actively blocking those usages.
CC @gnossen

I cannot clear the CXX variable - that was my first shot at the problem. There's no way to recreate the variable before the actual compilation takes place and the flags present in the variable are required to properly build the extension for the target system.

Oh, my bad. I thought this is changing how CXX is used in the entire script. But it only updates the check_linker_need_libatomic test.
Alternatively, how about putting all content split from CXX to the check?
cxx_tokens = shlex.split(os.environ.get('CXX', 'c++'))
cpp_test = subprocess.Popen(cxx_tokens + ['-x', 'c++', '-std=c++11', '-'],

I don't think there is an official standard for the CXX environment variable. Please correct me if you have better sources, but to the best of my knowledge, the original source of the CXX variable is GNU Make, which separates things between CXX and CXXFLAGS. For that reason, I'm inclined to say that what Poky is doing is a misusage of the environment variable.
With that said, this PR does not change behavior for what I would consider to be well-formed input (a CXX env var containing only a binary path), so I don't have any objections to making this PR.

Also I do not fully understand your argument regarding wrapping the compiler - that would also fail, just as in my case. The issue is with the subprocess invocation mechanism, which interprets the first element of provided list as literal executable. Should CXX contain wrapped compiler invocation, the subprocess creation will fail. However in that case my proposal of extended solution makes much more sense - read CXX, split it and pass all the elements to subprocess.Popen. Nevertheless that may cause another issues, should the CXX contain flags conflicting with the ones appended by the check_compiler_needs_libatomic

Nevertheless that may cause another issues, should the CXX contain flags conflicting with the ones appended by the check_linker_needs_libatomic

If CXX contains flags that will cause issues to this compile test, it will cause more trouble down the line. I agree that the usage is not completely legit in the sense of CXX and CXXFLAGS separation. gRPC as a library should promote backward compatibility when possible.
Can you try add all CXX content to the subprocess command?

Sure, I'll get to it tomorrow.

This breaks on platforms that actually need libatomic, because in that case there is a second usage of cxx that was not updated. It fails with:
Traceback (most recent call last):
  File "/build/source/nix_run_setup", line 8, in <module>
    exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))
  File "setup.py", line 263, in <module>
    if check_linker_need_libatomic():
  File "setup.py", line 219, in check_linker_need_libatomic
    cpp_test = subprocess.Popen(
  File "/nix/store/g3vx4am2vamnidfn13mfpi7qqcjw0i2s-python3-3.10.5/lib/python3.10/subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/nix/store/g3vx4am2vamnidfn13mfpi7qqcjw0i2s-python3-3.10.5/lib/python3.10/subprocess.py", line 1720, in _execute_child
    and os.path.dirname(executable)
  File "/nix/store/g3vx4am2vamnidfn13mfpi7qqcjw0i2s-python3-3.10.5/lib/python3.10/posixpath.py", line 152, in dirname
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not list

authors: gnossen kacper-ka lidizheng lopsided98


text:
Set Correct Platform Tag in Wheels on Mac OS with Python 3.10

Intended to fix https://github.com/grpc/grpc/issues/28387
After much experimentation (seriously, look at the commit history), I found that the "ARCHFLAGS" approach just wasn't working. Instead, I simply rename the artifact. This has been tested to work on an M1 mac running with Rosetta.
This is a hack. Long term, we'll need to figure out why distutils is not generating the proper platform and fix that. We'll also want to generate both arm64 artifacts and a proper universal2 artifact containing both x64 and arm64 artifacts. However, this will unbreak M1 users in the short term.
Side note: This PR also updates the Python 3.10 patch version installed on MacOS.

@gnossen , should we expect a new release of grpcio (and the other grpc libraries) in order to pick up the change in https://github.com/grpc/grpc/pull/29857?

Yes. I'm expecting expecting a release candidate later today (pacific time) and 1.47.0 will follow in a couple of days.

authors: eapolinario gnossen


text:
[PSM Interop] Legacy tests: fix xDS test client build (v1.57.x backport)

Backport of #33796 to v1.57.x.
https://github.com/grpc/grpc/pull/33699 incorrectly changed the legacy builds to not just use the test driver from the master, but also to build from it. This PR fixes the issue, and also updates the python job to work use the driver from master.

[ ] grpc/core/v1.56.x/branch/linux/grpc_xds_v3
[ ] grpc/core/v1.56.x/branch/linux/grpc_xds_v3_python


text:
Support AF_UNIX for windows

#22285
Unix domain socket has been added to windows: AF_UNIX comes to Windows
Golang net pkg has adopted this long ago:
https://go-review.googlesource.com/c/go/+/125456
https://go-review.googlesource.com/c/sys/+/132555
grpc-go already support this.
AF_UNIX on windows is seamlessly integrated with winsock API.
The modification needed are:

Set the right address family AF_UNIX depending on the address config, instead of using AF_INET6 all the time.
Ignore socket options for tcp.

@drfloob Can you review?

Hi @youyuanwu. This feature has been in discussion for a while. In short, we need to consider whether unix sockets can be treated identically within gRPC across platforms, or if there are subtle semantic differences that require a bit more scrutiny. There are a few folks reviewing the concept now, and we'll get back with you soon.
Thank you for the contribution regardless!

The PR has been tested manually with grpc-go, which already supports AF_UNIX on windows.
run_tests.py with c++ tests passes locally.

I have also done some testing of this with my own C++ server and C# client (grpc-dotnet which already supports AF_UNIX). No issues found.

Sorry for the delay, @youyuanwu. We've gotten consensus that this seems pretty safe to implement, so we can continue with the code review. Unfortunately, I'm going to be out for the remainder of the year, so we'll have to pick it up in January, but I'll do a quick first pass today.

@drfloob The last test run had failures when event engine listener is turned off. I cannot see the test run links anymore and do not remember the config to turn on/off, so please rerun the pipeline again.
Let me know if that use case needs to be supported as well.

I am updating this page 100 times a day, looking for the moment when the PR will be merged in production. This is a great achievement and I am looking forward to using it.

@youyuanwu
You can see the previous failures by hovering your mouse over the red "x" on the right, next to every individual commit

I do not remember the config to turn on/off, so please rerun the pipeline again.

I kicked off CI again, but you can disable the event_engine_listener experiment with the env var GRPC_EXPERIMENTS=-event_engine_listener, or if you're running tests through bazel: bazel test --test_env=GRPC_EXPERIMENTS=-event_engine_listener.
You'll likely want to test with:

GRPC_EXPERIMENTS=event_engine_client,event_engine_listener
GRPC_EXPERIMENTS=-event_engine_client,-event_engine_listener

@drfloob All failed windows tests has the config: experiment=no_event_engine_listener
Does this feature need to support no_event_engine_listener? I only changed event engine listener. I assume that there is another iomgr path for listener that I never changed. If this is required I will give a shot later this week.

Does this feature need to support no_event_engine_listener? I only changed event engine listener. I assume that there is another iomgr path for listener that I never changed. If this is required I will give a shot later this week.

Support for iomgr is necessary (that experiment enables iomgr listeners, effectively). There is indeed another file that I missed. src/core/lib/iomgr/tcp_server_windows.cc. I'm guessing we're looking at a too-small sockaddr.

Status: experiment=-event_engine_listener is supported now.
One more finding:
This change might have exposed a separate potential deadlock bug in windows event engine client.
With $env:GRPC_EXPERIMENTS="event_engine_client enabled. The client of uds will hit assert in debug mode about potential deadlock if server is not listening. This is related to grpc_core::ExecCtx dispatching pending tasks that uses locks. Will create a spearate issue about this, since I do not think the current change is the culprit.
@drfloob Can you rerun the ci?

I see the mutex re-acquisition problem https://source.cloud.google.com/results/invocations/419395f4-3a67-4bd1-9c73-f3fe2a43c1e5/targets/%2F%2Ftest%2Fcore%2Fend2end:connectivity_test@experiment%3Dpromise_based_client_call/log

I see the mutex re-acquisition problem https://source.cloud.google.com/results/invocations/419395f4-3a67-4bd1-9c73-f3fe2a43c1e5/targets/%2F%2Ftest%2Fcore%2Fend2end:connectivity_test@experiment%3Dpromise_based_client_call/log

Yes. This is the symptom. The easiest repro is to create any uds client that try connect to a non-existent server. Somewhere inside "event_engine_tcp_client_connect()" has the problem.

@youyuanwu I have a fix in the linked PR. Thanks for helping us find some bugs!

@drfloob I rebased with master with your change. The locking issue has been fixed by your change.

@youyuanwu Your change is merged, thanks for adding this feature!

@drfloob Thanks for the review and help. I will leave the documentation change to you, to say that uds is no longer unix only.

Hey, did this make it into main?

Hey, did this make it into main?

Yes. https://github.com/grpc/grpc/commit/a58f83c947be52d4b622aa0d32435323b81a8e5e

authors: dpservis drfloob lostobject youyuanwu


text:
Unit Test Failures in Cloud-Nuke CircleCi

Seeing errors in circleCi Test Pipeline
Fatal error: concurrent map writes
=== CONT  TestEgressOnlyInternetGateway_GetAll/timeAfterExclusionFilter

We should be able to just get rid of "t.Parallel()" to avoid issue like this. Since we are mocking everything, t.Parallel() shouldn't really affect performance too much. Otherwise, we would have to change the structure of the test quite a lot or introduce locking in the code base.

Hi @denis256, thinking of just getting rid of t.Parallel() in test cases. WDYT?

I believe t.Parallel() should fix the issue. If that doesn't fix it, we can explore other options. When users are using the cloud-nuke, there shouldn't be any scenario where any resource update the map variable concurrently because we usually update that when all the results are available.

It seems like the error is happening when we are updating Nukables map[string]error in the BaseAwsResource.
We can definitely put mutex lock around it but since it only happens for test scenarios, I'm a bid redundant to modify code to pass test cases. I would prefer to remove t.Parallel() instead.

Eliminating t.Parallel() might appear as a straightforward solution, but it will hide the issue with parallel access which may appear in the future if it is decided to implement concurrent removal.
We can go the quick route now - remove t.Parallel() and add another issue to fix concurrent access to the map.
Looking at the last tests - it is not failing, or affected resources weren't present in AWS or it is not failing each time?

Hey @denis, when that use case arise, I think it will be a pretty simple fix to introduce mutex.Lock in the BaseResource when updating the map.

repo: gruntwork-io/cloud-nuke

license: MIT


text:
Code validation excludes *.tf.json files.

checkFolderContainsTerraformCode only checks for *.tf file extensions and excludes valid *.tf.json files.
See the following:
https://github.com/gruntwork-io/terragrunt/blob/a316898e9043efe4d5333efeeee941a16a738608/cli/cli_app.go#L592
Upon inspection of the validation logic, I think we could solve this by using zglob.Match instead of zglob.Glob to check for the existence of both **/*.tf && **/*.tf.json files.

Good point. Are you up for a PR to fix this?

repo: gruntwork-io/terragrunt

license: mit

license_source: bigquery


text:
[WIP|awaiting feedback] Custom provider support

Hi,
I love terraform and I want to use it for my homelab, but support for custom providers is pretty mixed - while it's very easy to write them, using them is completely different story.
This PR contains basic implementation of custom provider support for terragrunt.
Fortunatelly Go since version 1.11 support compiling programs outside of GOPATH and it allows us to easily compile them in terragrunt cache directory.
In current implementation Go compiler is required on host computer for module compilation. In future I would like to add support for zips with binary and building with Docker.
Usage
terraform {
    custom_provider "PROVIDER_NAME" {
        source = "PROVIDER_SOURCE"
    }
}

Example usage:
terraform {
    custom_provider "xenserver" {
        source = "git::git@github.com:terra-farm/terraform-provider-xenserver.git?ref=87d0c36bce49e47036acba4e99712eb2672def52"
    }
}

Implements #631

Oh, this seems super cool! ❤

Thanks for your contribution! This is indeed an exciting feature and something I had in mind as well so love that there is a community contribution!
I think this is a good start for an incremental version focused on installing custom providers, but there are a few high level design questions that should be thought through. In particular, this sets the precedent for terragrunt to implement provider management features. Given that, I think we should at least think through the UX implications of this feature. Here are a few questions that pop to mind:

How do we keep the custom_providers block DRY across modules that share the provider?
Certain providers are likely to be reused across many modules. It seems like the system could easily get overloaded in an apply-all or validate-all if they all start compiling in parallel. Is there a way to detect and cache provider versions so that it is only compiled once?
It is fairly common practice to regularly wipe the terragrunt cache. I'm not sure if compiling and storing the providers there is the most efficient. I wonder if we should store providers in a different folder? In fact, should this actually just store the providers where terraform expects them (.terraform.d/plugins or TF_PLUGIN_CACHE_DIR)?
If we address caching here, would it make sense to actually expand this to a larger feature of general provider management? That is, should there be a way to specify provider versions that terragrunt should prefetch into a plugin directory? <= This actually feels like a different tool, but one way I see this working in terragrunt is that you can run a command like terragrunt plugin install which will install all the terraform providers in the terraform provider dir for the given tree.

To help think through these questions and more, can you actually summarize your thoughts around the features into an RFC as suggested in our contribution guidelines?

Hummm... This is nice feature indeed. But I think that Hashicorp is already working on the provider distribution issue.

https://github.com/gruntwork-io/terragrunt/issues/631#issuecomment-629150093
https://www.terraform.io/docs/registry/providers/docs.html
https://registry.terraform.io/browse/providers

authors: barryib jereksel lorengordon yorinasub17


text:
🛑 ReMindCare I3M is down

In b517504, ReMindCare I3M (https://remindcare.i3m.upv.es/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ReMindCare I3M is back up in 51150bb.

repo: grycap/status


text:
🛑 volkstanzwannwo.at is down

In 4ab3244, volkstanzwannwo.at (https://volkstanzwannwo.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanzwannwo.at is back up in 1fb2552.


text:
🛑 volkstanzwannwo.at is down

In bda4f21, volkstanzwannwo.at (https://volkstanzwannwo.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanzwannwo.at is back up in af691ef.


text:
🛑 volkstanzwannwo.at is down

In 38ea986, volkstanzwannwo.at (https://volkstanzwannwo.at) was down:

HTTP code: 0
Response time: 0 ms

Resolved: volkstanzwannwo.at is back up in 6774fe8.


text:
move out card on closing

v1 feature

Still not working sometime

authors: barmanrajdeep gs-akhan

repo: gs-akhan/salesforce-debugger


text:
Update index.html

index 확장 브랜치 개발
다 작업 되었습니다.

확인했습니다.


text:
Set jetty user as system user

There doesn't seem to be a way to set the jetty user / group created by the module as a system user.

Hi,
Now it's a system user, but jetty still needs /bin/bash, it doesn't start properly on centos with /sbin/nologin.
I commited on master if you want to try.

Almost there :) Could you just make the jetty group a system group as well?

done. You can even force uid/gid if you are using the same across servers

authors: gsick jopasserat

repo: gsick/puppet-jetty


text:
Carefully consolidate the boot modules so that the kernel knows where…

… they are
I'm not sure I like these changes.  It does enable something that didn't work before, but it's still mega-hacky.

Why do you only need alignment, not padding? Is last_used inclusive or exclusive?
Other than that looks good to me.

Now that we have #60, this is no longer going to happen.

authors: allanlw gsilvis

repo: gsilvis/silvos


text:
Template doesn't work after restoring a backup

Hi, there is a probable bug that prevent the correct saving-restoring of the templates.
Here there are the steps that should reproduce it.

On a normal installation of the extension (I was using ESGST greasmonkey script 8.1.5) enable the first dark template. (All works correctly).
Backup all the data
Restore all the data on another computer that has ESGST greasmonkey on it (but is set with the default template).
The various options are available on the other computer but the template doesn't change.

It seems not a problem with the backup file, once the backup is restored on the second computer the template mechanism stops to work so it is not possible to activate the dark template neither through the option panel.
NOTE: The same issue occurs also with the ESGST firefox extension. I just installed the extension and without doing anything else imported the backup of my greasemonkey ESGST (8.1.7) that works correctly with the dark template. On the ESGST firefox extension all the options are correctly imported but the template is the standard one. Changing the template from the option menu doesn't produce any change.
NOTE 2: From the browser console I can see the following error message
"TypeError: e is undefined"       esgst.js:1:370270
I hope this could be it could be helpful, feel free to ask if you need more details.
Thanks for this amazing extension/script!

Yes sorry, I meant theme.
Your suggestion worked, now I have the dark theme again.
Thanks a lot.
Have a nice evening!

By "template" do you mean "theme"? If so, click the "Update" button in the additional options of the theme.

Where is this Update button? I'm having the same issues in Chrome since I just went from the userscript to the extension as suggested by the update. Once I restored the backup, the theme "2.SGv2 Dark by SquishedPotatoe" was enabled in settings, just as it was when I took the backup. However it doesn't seem to load. Disabling it, and then enabling it in settings doesn't make any difference either.
Console shows an error when I click the setting to enable it: https://i.imgur.com/tL3H3fE.png
Is it perhaps trying to load the "additional options" you're talking about?

@Marabon Make sure to click the name of the theme

arrow pointing in the screenshot. It opens the "additional options" dialog. Then toggle off the SteamGifts option and toggle it back on. A popup will come up asking page width settings -- click "Generate" and voila everything will be good again.

@DFNCTSC Thanks, I was expecting those additional options to show up when I clicked the enable thing to the left. (Clicking Update worked)
The error I linked a screenshot of might still be relevant for @gsrafael01 to take a look at. I do see the spacing change when going through the steps I mentioned, just nothing added, which seems understandable as innerHTML probably is trying to show me something, but failing.

authors: DFNCTSC Git-GT Marabon


text:
Replace PaserSetting.HelpWriter Throwing exception

There's a higher than likely chance that this is just me being a derp. But when I try to replace the HelpWriter with null or anything for that matter i get a InvalidOperationException.
The code I'm using.
Parser.Default.Settings.HelpWriter = null;
CommandLinePaserVersion: 2.0.275-beta

Can you post the stack trace? More than likely we fail to do a null check somwhere...

I'm more of a java guy when it comes to stack traces so i have no idea if this little bit is what you're looking for
   at CommandLine.ParserSettings.set_HelpWriter(TextWriter value)
   at WerewolfBot.Program.Main(String[] args) in c:\users\cole\documents\visual studio 2015\Projects\WerewolfBot\WerewolfBot\Program.cs:line 20

repo: gsscoder/commandline


text:
Issue on page /S46_logistics_learning.html

The expectation-maximization or EM algorithm is an algorithm that allows us to estimate measurement and motion models even when the state is only observed from measurements.

Maybe it should be 'estimate states' rather than 'estimate measurement'?

Oops, did not see this issue until now. No, it's supposed to be "measurement [models] and motion models".

authors: dellaert odats

repo: gtbook/robotics


text:
Update doc example

Part of #730.
cc @sdroege @EPashkin

Updated.

@GuillaumeGomez Thanks

Removed the unneeded connect_delete.

For me this PR ready for merge.
@GuillaumeGomez, thanks

Yes, go ahead :)

authors: EPashkin GuillaumeGomez sdroege

repo: gtk-rs/gtk


text:
[BUG] gtk4::PrintJob::default() cause crash

System:    Host: rafalkom Kernel: 5.13.0-28-generic x86_64 bits: 64 compiler: gcc v: 11.2.0 Desktop: GNOME 40.5
           tk: GTK 3.24.30 wm: gnome-shell dm: GDM3 Distro: Ubuntu 21.10 (Impish Indri)

RUST_BACKTRACE=full RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address cargo run  -Zbuild-std --target x86_64-unknown-linux-gnu

Bug description
gtk4::PrintJob::default()

cause panic:

(crash_thing:67269): Gtk-CRITICAL **: 13:09:57.517: gtk_printer_get_backend: assertion 'GTK_IS_PRINTER (printer)' failed

(crash_thing:67269): GLib-GObject-CRITICAL **: 13:09:57.518: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
AddressSanitizer:DEADLYSIGNAL
=================================================================
==67269==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000078 (pc 0x7fd9fcfb87a6 bp 0x62100011ddb0 sp 0x7ffef745d4d0 T0)
==67269==The signal is caused by a READ memory access.
==67269==Hint: address points to the zero page.
    #0 0x7fd9fcfb87a6  (/lib/x86_64-linux-gnu/libgtk-4.so.1+0x3867a6)
    #1 0x7fd9fc851c66  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x22c66)
    #2 0x7fd9fc852ed4  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x23ed4)
    #3 0x55bd994a3151  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x6ff151)
    #4 0x55bd994a08a9  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x6fc8a9)
    #5 0x55bd990f3f83  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x34ff83)
    #6 0x55bd990dc33c  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x33833c)
    #7 0x55bd990d1747  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x32d747)
    #8 0x55bd990cb487  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x327487)
    #9 0x55bd990caa6a  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x326a6a)
    #10 0x7fd9fc842c0e  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x13c0e)
    #11 0x7fd9fc85eea5  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x2fea5)
    #12 0x7fd9fc860883  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x31883)
    #13 0x7fd9fc860ad2  (/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x31ad2)
    #14 0x7fd9fc9659d7  (/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdb9d7)
    #15 0x7fd9fc965bb5  (/lib/x86_64-linux-gnu/libgio-2.0.so.0+0xdbbb5)
    #16 0x55bd990cbee8  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x327ee8)
    #17 0x55bd990cb8d7  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x3278d7)
    #18 0x55bd990d13c6  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x32d3c6)
    #19 0x55bd990d313a  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x32f13a)
    #20 0x55bd990d0704  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x32c704)
    #21 0x55bd990ccaf3  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x328af3)
    #22 0x55bd998e5bdd  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb41bdd)
    #23 0x55bd998f3cce  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb4fcce)
    #24 0x55bd998fce7a  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb58e7a)
    #25 0x55bd998f1f72  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb4df72)
    #26 0x55bd996a4289  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x900289)
    #27 0x55bd997412fb  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x99d2fb)
    #28 0x55bd998f3acd  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb4facd)
    #29 0x55bd998fce7a  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb58e7a)
    #30 0x55bd998f2c6b  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0xb4ec6b)
    #31 0x55bd996a45a9  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x9005a9)
    #32 0x55bd99740c49  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x99cc49)
    #33 0x55bd990cca55  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x328a55)
    #34 0x55bd990d182b  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x32d82b)
    #35 0x7fd9fc3fefcf  (/lib/x86_64-linux-gnu/libc.so.6+0x2dfcf)
    #36 0x7fd9fc3ff07c  (/lib/x86_64-linux-gnu/libc.so.6+0x2e07c)
    #37 0x55bd990381e4  (/home/rafal/Projekty/Rust/gtk_rs_fuzzer/Project/target/x86_64-unknown-linux-gnu/debug/crash_thing+0x2941e4)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libgtk-4.so.1+0x3867a6)
==67269==ABORTING

Issue found by fuzzer - https://github.com/qarmin/gtk-rs-fuzzer

We should drop the Default implementation in this case, it seems to require having a Printer object set

authors: bilelmoussaoui qarmin


text:
按 README 所说无法得到 Linux 下的静态库

GmSSL 3 采用了cmake构建系统。下载源代码后将其解压缩，进入源码目录，执行：
mkdir build
cd build
cmake ..
make
make test
sudo make install

我只能得到位于 /usr/local/lib 目录下的一个动态库（libgmssl.so.3.1）和两个软链接（libgmssl.so, libgmssl.so.3），然而：

在make install完成后，GmSSL会在默认安装目录中安装gmssl命令行工具，在头文件目录中创建gmssl目录，并且在库目录中安装libgmssl.a、libgmssl.so等库文件。

可 /usr/local/lib 目录下并没有 libgmssl.a 静态库文件，我编译的是 v3.1.1 版本的仓库，希望能得到一点帮助，十分感谢！

把 CMakeLists.txt 中的最后一行改为：add_library(gmssl STATIC ${src})

如果是 ubuntu 系统更新以下 库即可
sudo ldconfig

centos
sudo /sbin/ldconfig

authors: TENX-S nonameless10 yanxianhe

repo: guanzhi/GmSSL


text:
Code Cleanup with R# - File Layout is annoying

Some of the current settings are annoying and should be changed:
R# claims to support placing backing fields above their properties in FIle Layout.
But this does not work.
https://youtrack.jetbrains.com/issue/RSRP-484909/Support-Place-backing-field-above-property-in-file-layout
I want this, and it's super annoying that the global reformat we did screwed this up. To this end, I want to change the default Ctrl-E/C profile to NOT apply file layout.
It can be applied separrately with a "File Layout" profile.
Sorting is annoying
I configured properties, methods, etc... to sort based on name. This is annoying when it actually makes having related things near each other. For example in ViewLayout.cs, the logical order of X, Y, Width, Height is exactly that. But because we have sorting on, they get placed as Height, Width, X, Y.
What else?

I've noticed this for a long time and I thought you wanted it that way, anyway...

You should grab the file layout extensions R# extension, which actually provides this. I use that.
The settings are not quite right yet, even using that, but I just haven't cared enough since it's such a minor thing.

Also, there might be a way to make it ignore things like underscores for purposes of sorting.
But typical guidelines are to have private and static stuff up top (which includes constructors) and then everything else follows.
Personally, I like to also have all properties be placed before methods, but that's just my pref.

authors: BDisp dodexahedron tig


text:
Don't include/link source mapping in distribution files.

Source mapping files does not belong in distribution files see;
https://github.com/guillaumepotier/Parsley.js/blob/master/dist/parsley.js#L2387
https://github.com/guillaumepotier/Parsley.js/blob/master/dist/parsley.min.js#L18

What actual problem is this causing for you?

It expect missing *.js.map files from Parsley.js that does not belongs in production.

I'm sorry, I still don't understand what actual issue you are facing. What's "it"?

Its that you enforce to include the sourcemaps when using the /dist files otherwise it ask for .js.map files that does not exists, to bypass this I have to use /src files to manage my own build compiled with e.g. babel, but the issue was that in the project I was trying to apply this we was using quite simple gulp setup without es6 structure.

AFAIK, the comment about the sourcemap has no adverse consequence in production, even if you choose not to use the sourcemap.
I personally feel that the sourcemap should be provided nevertheless, it won't be downloaded unless some developper wants to look at the source.
See also #1108

Thanks for the reply, for a nice repo!

authors: futhr marcandre


text:
Implementation with L1-norm using scipy wrapper of LP solver HiGHS

https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.linprog.html

Update cvxpy to version >= 1.1.14 which supports HIGHS

repo: guillermo-navas-palencia/ropwr