How to fix up sendgrid-python, BadRequestsError

Traceback (most recent call last):
  File "sendmail.py", line 79, in <module>
    response = sg.client.mail.send.post(request_body=mail.get())
  File "/home/errong_leng/.local/lib/python2.7/site-packages/python_http_client/client.py", line 227, in http_request
    return Response(self._make_request(opener, request))
  File "/home/errong_leng/.local/lib/python2.7/site-packages/python_http_client/client.py", line 161, in _make_request
    raise exc
python_http_client.exceptions.BadRequestsError

The easy way is to catch this exception and print out the error body:
try:
    response = sg.client.mail.send.post(request_body=mail.get())
    print(response.status_code)
    print(response.body)
    print(response.headers)
except Exception as e:
    print (e.body)  #print (e.read()) 


Then you can know why bad request error reported, such as:
{"errors":[{"message":"Following RFC 1341, section 7.2, if either text/html or text/plain are to be sent in your email: text/plain needs to be first, followed by text/html, followed by any other content.","field":"content","help":null}]}

{"errors":[{"message":"The subject is required. You can get around this requirement if you use a template with a subject defined or if every personalization has a subject defined.","field":"subject","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.subject"}]}

{"errors":[{"message":"Each email address in the personalization block should be unique between to, cc, and bcc. We found the first duplicate instance of [errong.leng@gmail.com] in the personalizations.0.to field.","field":"personalizations.0","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.recipient-errors"}]}

Set up shadowsocks server on your google compute engine(ubuntu os) from shadowsocks-libev sources.

Refers:
https://github.com/shadowsocks/shadowsocks-libev

How to generate crash backtrace just from your serial crash log, without coredump file.

If your crash log have dump maps, user stacks, and you have symbols too,
You can try to get a backtrace via below python scripts.

[2-11624.8825] PC, LR MEMINFO
[2-11624.8825] --------------------------------------------------------------------------------------
[2-11624.8825] PC:46cbfc92, LR:46cbfc59
[2-11624.8825] --------------------------------------------------------------------------------------
[2-11624.8825] PC meminfo (0x46cc005d to 0x46cc0092)
[2-11624.8825] 0040:                                                                               
[2-11624.8825] 0060: be07e9cd 801cf8d0 f04fb085 f1010901 ea4f061b e0015707 d03142b4 f85446a3
[2-11624.8825] 0080: f0055b04 2b010303 ea4fd1f6 f8d85a15 ea4f3a14
[2-11624.8825] --------------------------------------------------------------------------------------
[2-11624.8825] LR meminfo (0x46cbf459 to 0x46cc0059)
[2-11624.8825] f440:                                                                0205ea02
[2-11624.8825] f460: bf0442a2 f8832201 d009202c f84269da 6a191020 f1016a9a ea020101 621a0201
[2-11624.8825] f480: e9ddb002 b0024500 bf004770 8000f3af 4506e96d 5413ea4f e9cd460d ea4f8e04
......
[2-11624.8831] * dump maps on pid (2548 - efl_webprocess)
[2-11624.8831] -----------------------------------------------------------
[2-11624.8831] 00010000-00011000 r-xp 00000000 b3:12 55716      /usr/lib/chromium-efl/efl_webprocess
[2-11624.8831] 00020000-00021000 r--p 00000000 b3:12 55716      /usr/lib/chromium-efl/efl_webprocess
[2-11624.8831] 00021000-00022000 rw-p 00000000 00:00 0         
[2-11624.8831] 00031000-00036000 rw-p 00001000 b3:12 55716      /usr/lib/chromium-efl/efl_webprocess
[2-11624.8831] 00036000-0007c000 rw-p 00000000 00:00 0          [heap]
[2-11624.8831] 0007c000-008ae000 rw-p 00000000 00:00 0          [heap]

[2-11624.8917] -----------------------------------------------------------
[2-11624.8917] * dump user stack
[2-11624.8917] -----------------------------------------------------------
[2-11624.8917] pid(2548) stack vma (0xbe729000 ~ 0xbe74c000)
[2-11624.8917] User Stack: (0xbe749e20 to 0xbe745f10)
[2-11624.8917] -----------------------------------------------------------

Fix up : Configurable attribute "copts" doesn't match this configuration

ERROR: /home/lenger/.cache/bazel/_bazel_lenger/e744db622218e02ee1e2cbf3b8750f17/external/nsync/BUILD:402:13: Configurable attribute "copts" doesn't match this configuration (would a default condition help?).
Conditions checked:
 @nsync//:android_arm
 @nsync//:android_arm64
 @nsync//:android_armeabi
 @nsync//:android_x86_32
 @nsync//:android_x86_64
 @nsync//:clang_macos_x86_64
 @nsync//:gcc_linux_aarch64
 @nsync//:gcc_linux_ppc64
 @nsync//:gcc_linux_x86_64_1
 @nsync//:gcc_linux_x86_64_2
 @nsync//:ios_x86_64
 @nsync//:msvc_windows_x86_64.

Solution:
vim /home/lenger/.cache/bazel/_bazel_lenger/e744db622218e02ee1e2cbf3b8750f17/external/nsync/BUILD


Add a default conditions there as marked as red line below:

NSYNC_OPTS_GENERIC = select({
    # Select the CPU architecture include directory.
    # This select() has no real effect in the C++11 build, but satisfies a
    # #include that would otherwise need a #if.
    ":gcc_linux_x86_64_1": ["-I" + pkg_path_name() + "/platform/x86_64"],
    ":gcc_linux_x86_64_2": ["-I" + pkg_path_name() + "/platform/x86_64"],
    ":gcc_linux_aarch64": ["-I" + pkg_path_name() + "/platform/aarch64"],
    ":gcc_linux_ppc64": ["-I" + pkg_path_name() + "/platform/ppc64"],
    ":clang_macos_x86_64": ["-I" + pkg_path_name() + "/platform/x86_64"],
    ":ios_x86_64": ["-I" + pkg_path_name() + "/platform/x86_64"],
    ":android_x86_32": ["-I" + pkg_path_name() + "/platform/x86_32"],
    ":android_x86_64": ["-I" + pkg_path_name() + "/platform/x86_64"],
    ":android_armeabi": ["-I" + pkg_path_name() + "/platform/arm"],
    ":android_arm": ["-I" + pkg_path_name() + "/platform/arm"],
    ":android_arm64": ["-I" + pkg_path_name() + "/platform/aarch64"],
    ":msvc_windows_x86_64": ["-I" + pkg_path_name() + "/platform/x86_64"],
    "//conditions:default": [],
}) + [
    "-I" + pkg_path_name() + "/public",
    "-I" + pkg_path_name() + "/internal",
    "-I" + pkg_path_name() + "/platform/posix",
] + select({
    ":msvc_windows_x86_64": [
    ],
    "//conditions:default": [
        "-D_POSIX_C_SOURCE=200809L",
        "-pthread",
    ],
})

fixed: embedded-redis: Unable to run on macOS Sonoma

Issue you might see below error while trying to run embedded-redis for your testing on your macOS after you upgrade to Sonoma. java.la...