Add multicluster support

Adds support for tracking jobs in multiple clusters. The invocation syntax is a bit clunky as a result:
$ /opt/timberlake/bin/timberlake \
      -bind :8000 \
      -cluster-name c1,c2 \
      -resource-manager-url rm1,rm2 \
      -history-server-url hs1,hs1 \
      -namenode-address nn1,nn2 \
      -yarn-logs-dir /var/log/hadoop-yarn/apps
      -yarn-history-dir /tmp/staging/history/done
      -pprof"

One needs to be careful to align cluster details consistently or things will break. Additionally, this assumes that YARN directories are the same for all clusters. I'm intending to add support for configuration files that lay out cluster mappings more intuitively in a future PR.
This also extends job history retention, 5k jobs per cluster on the server side (prev. 5k globally), and 10k jobs on the client (prev. 5k). The server side isn't much of a concern, as the intention is to run JT on a dedicated box in a multicluster setting. The client settings have not been thoroughly tested at the new limit, but dialing it back would be pretty straightforward.
The only visual regression for single clusters is the addition of a cluster column, which isn't useful in a single cluster setting:

I have a TODO to fix this and will file a GH issue as well.
There are a few other changes rolled into this PR, including improved error logging and eslint fixes. A possibly major change is the switch from PropTypes to flow (with js/job.jsx as the PoC), happy to 🏈 that to a separate PR if it's distracting).
r? @stripe/data-platform @jbalogh

This is super exciting! I can take a more detailed look tomorrow, but one suggestion for the awkward invocation syntax - maybe we should move to using a config file?

@abull-stripe agreed! 😸

I'm intending to add support for configuration files that lay out cluster mappings more intuitively in a future PR.

Sounds good, :| should have read that more carefully

I've updated the PR to only include the "cluster" column when there are multiple clusters. This is done via a server endpoint that returns the number of clusters. It seems like overkill, but scanning the job list on each render to count the number of distinct clusters is expensive at scale (and i don't know of another way the client can ever be sure there aren't multiple clusters).

👍
looks good to me!


7/26/2022 Publish

Docs Build status updates of commit 00996d6:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

2017-03-09-profile/docs-ref-autogen/containerapp.yml
:bulb:Suggestion
View (azure-cli-2017-03-09-profile)
Details

2017-03-09-profile/docs-ref-autogen/containerapp/github-action.yml
:bulb:Suggestion
View (azure-cli-2017-03-09-profile)
Details

2017-03-09-profile/docs-ref-autogen/monitor/scheduled-query.yml
:bulb:Suggestion
View (azure-cli-2017-03-09-profile)
Details

2018-03-01-hybrid/docs-ref-autogen/containerapp.yml
:bulb:Suggestion
View (azure-cli-2018-03-01-hybrid)
Details

2018-03-01-hybrid/docs-ref-autogen/containerapp/github-action.yml
:bulb:Suggestion
View (azure-cli-2018-03-01-hybrid)
Details

2018-03-01-hybrid/docs-ref-autogen/monitor/scheduled-query.yml
:bulb:Suggestion
View (azure-cli-2018-03-01-hybrid)
Details

latest/docs-ref-autogen/ams/asset.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/containerapp.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/containerapp/github-action.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/mariadb/server.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/monitor/scheduled-query.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/mysql/flexible-server.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/mysql/server.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/postgres/flexible-server.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

latest/docs-ref-autogen/postgres/server.yml
:bulb:Suggestion
View (azure-cli-latest)
Details

2017-03-09-profile/docs-ref-autogen/containerapp/auth.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/apple.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/facebook.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/github.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/google.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/microsoft.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/openid-connect.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/auth/twitter.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/dapr.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

2017-03-09-profile/docs-ref-autogen/containerapp/env.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile)

This comment lists only the first 25 files in the pull request.

2017-03-09-profile/docs-ref-autogen/containerapp.yml

Line 381, Column 83: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 91: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 112: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 120: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

2017-03-09-profile/docs-ref-autogen/containerapp/github-action.yml

Line 44, Column 113: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 44, Column 121: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

2017-03-09-profile/docs-ref-autogen/monitor/scheduled-query.yml

Line 252, Column 93: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 255, Column 116: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

2018-03-01-hybrid/docs-ref-autogen/containerapp.yml

Line 381, Column 83: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 91: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 112: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 120: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

2018-03-01-hybrid/docs-ref-autogen/containerapp/github-action.yml

Line 44, Column 113: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 44, Column 121: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

2018-03-01-hybrid/docs-ref-autogen/monitor/scheduled-query.yml

Line 252, Column 93: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 255, Column 116: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/ams/asset.yml

Line 243, Column 93: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 249, Column 116: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/containerapp.yml

Line 381, Column 83: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 91: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 112: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 381, Column 120: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/containerapp/github-action.yml

Line 44, Column 113: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'owner' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.
Line 44, Column 121: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'repository-name' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/mariadb/server.yml

Line 78, Column 202: [Suggestion: disallowed-html-tag - See documentation] HTML tag 'SingleIP' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

This comment lists only the first 25 errors (including error/warning/suggestion) in the pull request.
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Add slack invitation and The Game links in live

Use this link: https://hackupc2017w.slack.com/signup
For The Game link, ask @albertnez

Link doesn't work. Not adding that. I can add a comment asking to send an email to request access.
We will add the link to the game during the event. Same as the starting and ending hours

done


no build,  debian jessie arm

Trying to run this script on an RPi 1.
sudo ./X11rdp-o-matic.sh --branch v0.9 --withfreerdp
this is as far as it gets before dropping to command line.  It did load dialogs first time. I did have xrdp loaded via the distribution but removed it before running your script.  Are there some dependencies I need to load that the script doesn't>  Both gcc make are latest.   I see you only suppot debian 7.  Is this an issue with arm box (raspberrypi running debian jessie arm, raspbian).  I looked in the script but can't identify why it's bailing.
----------------------------------------------------------------------
Obtaining list of available branches...
----------------------------------------------------------------------
devel gh-pages itamarjp-patch-1 master v0.6 v0.7 v0.8 v0.9
----------------------------------------------------------------------
Using branch ==>> v0.9 <<==
----------------------------------------------------------------------
Using the following xrdp configuration : --prefix=/usr
----------------------------------------------------------------------

found some build instructions for Jessie, Debian 8 here.  So will do this manually.


How can I build runtime with Intel OneDNN?

I installed latest Intel OneDNN and MKL from its official release 2022.0.2, then run 'source /opt/intel/oneapi/setvars.sh' to let OneDNN and MKL environment settings in effect.
I started to build wenet on local:
cd runtime/server/x86
mkdir build
cd build
cmake ..
make -j8
The errors happened in the linking to indicate that all functions 'mkl_xxx' are not defined which is used by libmkl_intel_thread.so. Below are selected from hundreds of lines of Error info:
/usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_spblas_lp64_zzeros' /usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_lapack_xzpttrs'
/usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_spblas_ccsr1ttlnf__smout_par' /usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_pds_lp64_fct_cmplx_block'
/usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_spblas_dcsr0ttluc__mmout_par' /usr/bin/ld: /opt/intel/oneapi/mkl/2022.0.2/lib/intel64/libmkl_intel_thread.so: undefined reference to mkl_feast_dfeast_scsrev'
......
I also installed the docker image on my server. Although the inference can be run but I notice there is no MKL and OneDNN is installed. I guess the docker image doesn't utilize OneDNN, right?
My server is an ICL and OS is Ubuntu 20.04.

I think if you want it works, your libtorch should be built with the specific OneDNN and MKL.


Corrects the driver name

Passes the correct driver name.
Signed-off-by: irbekrm<EMAIL_ADDRESS>

/approve


Accordion bug - "global is not defined"

Current Behavior
Accordion usage couses app to crash when clicking on expand icon fast
Expected Behavior
Accordion working correctly
Tamagui Version
1.74.8

Platform (Web, iOS, Android)
Web

Reproduction
1. Copy paste example accordion code from docs https://tamagui.dev/docs/components/accordion/1.0.0
2. When i click expand button twice FAST, app crashes.

Errors:

1. The above error occurred in the <Square> component
2. "Uncaught ReferenceError: global is not defined" from "_SpringAnimation.stop"

System Info
System:
    OS: Windows 10 10.0.19045
    CPU: (16) x64 AMD Ryzen 7 2700 Eight-Core Processor
    Memory: 1.63 GB / 15.95 GB
  Binaries:
    Node: 16.19.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.19.3 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 117.0.5938.149
    Edge: Spartan (44.19041.1266.0), Chromium (117.0.2045.47)
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @storybook/addon-essentials: ^7.4.5 => 7.4.5
    @storybook/addon-interactions: ^7.4.5 => 7.4.5
    @storybook/addon-links: ^7.4.5 => 7.4.5
    @storybook/addon-onboarding: ^1.0.8 => 1.0.8
    @storybook/blocks: ^7.4.5 => 7.4.5
    @storybook/react: ^7.4.5 => 7.4.5
    @storybook/react-vite: ^7.4.5 => 7.4.5
    @storybook/testing-library: ^0.2.1 => 0.2.1
    @tamagui/config: ^1.74.8 => 1.74.8
    @tamagui/lucide-icons: ^1.74.8 => 1.74.8
    @tamagui/vite-plugin: ^1.74.8 => 1.74.8
    @types/react: ^18.2.15 => 18.2.23
    @types/react-dom: ^18.2.7 => 18.2.8
    @typescript-eslint/eslint-plugin: ^6.0.0 => 6.7.3
    @typescript-eslint/parser: ^6.0.0 => 6.7.3
    @vitejs/plugin-react-swc: ^3.3.2 => 3.4.0
    eslint: ^8.45.0 => 8.50.0
    eslint-plugin-react-hooks: ^4.6.0 => 4.6.0
    eslint-plugin-react-refresh: ^0.4.3 => 0.4.3
    eslint-plugin-storybook: ^0.6.14 => 0.6.14
    prettier: 3.0.3 => 3.0.3
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    react-native-svg: ^13.14.0 => 13.14.0
    storybook: ^7.4.5 => 7.4.5
    tamagui: ^1.74.8 => 1.74.8
    typescript: ^5.0.2 => 5.2.2
    vite: ^4.4.5 => 4.4.9

Removing the animation prop from square solves the problem
<Square animation="quick" rotate={open ? '180deg' : '0deg'}>

this maybe a reanimated bug, can you do: globalThis['global'] = globalThis and does it fix?

including a patch on our side in the next release, but would be nice to open an issue on reanimated if you have time, they should migrate to use the standard globalThis not the RN-specific global


Measure per hop latency

@ldemailly please update this issue

the data is now published on
https://istio.io/docs/performance-and-scalability/synthetic-benchmarks/

@ldemailly the linked doc doesn't seem to have the per hop latency. Maybe I am missing something

s1->s2 and s2->s1 is per hop


Swift 4 support?

Hi @thePsguy, thanks for the cool library. I am having an issue with the last released source.
I believe it's the right time to update it for the latest Swift?
Argument of '#selector' refers to instance method 'animateIndeterminate(sender:)' that is not exposed to Objective-C

Hey @hemagshah,
Indeed. I'll be fixing this and the other issue in a few days. If you find anything else, feel free to create an issue.
Thanks!

Thanks for the quick response. @thePsguy, looking forward to seeing/making a better ButtonProgressBar for iOS!

Hey @hemangshah, Version 1.0.1 has been pushed and fixes this issue. You should be able to update to it by running pod update.


Fix warning on router-link for entities with suffix

Related to https://github.com/jhipster/jhipster-vuejs/issues/253

Please make sure the below checklist is followed for Pull Requests.

[ ] Travis tests are green

[ ] Tests are added where necessary

[ ] Documentation is added/updated where necessary

[ ] Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

This PR didn't fix yet:
[vue-router] missing param for named route "BankAccountEdit": Expected "bankAccountId" to be defined

thank you @sahbi-ktifa


Image caption position relative to block width not page width

When using center aligned images that are only, say, 80% of the page width, it would be great if the caption of that image is also aligned with the image.
Current behaviour:

Expected behaviour:

The behaviour of
caption:
  align: center

would still be the same, however, left and right alignment would be limited to the image width.

We should follow what we did for tables and allow the image_caption_max_width key to be set to fit-content.


Minor tweaks to Dockerized Jenkins README

Emphasized that the jobs themselves will not work in the Dockerized Jenkins. Apparently several people (including myself) have missed that fact and attempted to run a Dockerized Jenkins to replicate the CI environment.
Fixed anchor link
Added link to seedjobconfig.xml
Added directions for finding plugins

Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

R: @Ardagan


Zones picking in combined HSQC/HMBC without labels. Displayer crashed when zoomed HMBC is picked

(1) When the dataset 'HSQC/HMBC cytisine' (General section) ist chosen and only the HSQC is displayed, the zones tool does not show the dots for the defined crosspeaks, even though the zones table gets populated.
(2) When the HSQC is deselected and the HMBC is picked with the zones tool, this only works as long as the entire spectrum is visible. If you first zoom into a region to selectively pick the zones, the interface crashes.

Second point can not be reproduced but maybe fixed in the meantime.

I made a movie for the second point (first, zones on entire spectrum - without the zone-centers being picked! - and then zoom-in and zones from expanded reagion - leads to crash (at least on my computers)
bug_617.zip

@nes-cgn
I fixed it right now. To show the zones you have to set negative  or positive signal  visible by click on the eye icon, like what we have in below image

Not so sure. At least for me, if I have the HMBC active (HSQC also deactivated by eye icons to avoid confusion), I can zoom in this region and then select 2-3 zones, but again, at some point it crashed


Prefix the method name with the class name for validation errors

instance.errors.full_messages will now produce something like:
["SomeClass: The attribute can't be blank"]
Full disclosure... I have no idea what else this will effect (especially in the UI) ¯\_(ツ)_/¯

Looks great, thank you.

LGTM, even the test failures show who this affects and they all seem like legitimate things to change in the tests.

cc @mzazrivec

Full disclosure... I have no idea what else this will effect (especially in the UI) ¯_(ツ)_/¯

There's only one way to find out.  We get burned by indirect validation failures often enough that we should just fix anything that this change affects.


Infinite loop when SoapySDRServer goes down

If I halt SoapySDRServer while using it, Pothos spews forever lines like:
2015-11-01 21:28:55 Pothos.Block.callSlot: SDRSource0[setFrequency]: Exception: SoapyRPCPacker::send() FAIL: send() [32: Broken pipe]

This was happening only when it had failed to open the device because it was already in use (SoapyRTLSDR).

Its just printing once a second, right? If so, its probably the background evaluator (it has a 1 second timer when there's no other stimulus).
The evaluator is trying to re-apply the same failed setting. I think what should happen is that when a call fails, it should give up on the block and try to re-init the block from scratch. Once that happens, it will try to make the block, fail when it tries to instantiate the SDR device, and then yield a different more sensible error message.
Related issue, this sounds like something to add to it: https://github.com/pothosware/pothos-gui/issues/97

It printed many, many times per second and caused the pty it was running in to stop responding to input.

Sorry, after git pulling updates, it does indeed print only once per second.

This is added to the gui issue tracker now: https://github.com/pothosware/pothos-gui/issues/97


soc/intel_adsp: DMA Stability fix for cavstool

There is a hardware bug with stream reset, it won't stop the stream.
I thought it was limited to just the early versions, but it turns out
that 2.5 has it too in some variants.  Which is frustrating, because
the TGL chromebook I have doesn't like the START clear.  But all
systems work with an extra delay between them, so do that.
Signed-off-by: Andy Ross<EMAIL_ADDRESS>

Verified this PR fixed the issue: DSP firmware loading failed from time to time in CAVS25, CAVS18, and have also verified no impact on CAVS15.  Fixes #41862


Update sitl_run to fetch the SDF filename from the model.config file

Problem
Since the seperation from the SITL Gazebo model and world files, there is no way to run a simulation on the jinja generated models. These models produce a file called model-gen.sdf, but currently it expects a file called model.sdf
Solution
The solution is to update the sitl_run.sh file to rather fetch the SDF filename from the model.config file, instead of assuming that the SDF filename is the same as the model's.
Alternatives
An alternative solution would be to just rename the generated SDF files to model.sdf and omit the -gen part. However, this means that these can't be ignored when pushing code and I don't think it is preferable to have generated code living in the codebase. Therefore, I think my current proposed solution is a better one.

Cool!

@Jaeyoung-Lim Sorry, yeah those are because I merged some branches. Will do.

@Jaeyoung-Lim Please let me know if there is anything else I can/should do.

@antonerasm Thanks!


Build bundle for modern browsers and legacy browser separately

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

There is about 47% desktop browsers and about 45% mobile browsers run ES2015 without any problem. By https://www.netmarketshare.com
There is new simplest solution yet how to deploy separate javascript to modern browsers and transpiled to older browsers. And it is use to

Step 2 might not be necessary, the newer version of uglify is fully es6 compatible.
Any news on the progress of this issue? We're targeting only recent browsers and would love to lose the 10kb core-js, 2.5kb regenerator and 1kb babel-runtime deps + the size improvements by having es6 over es5 in all files.

Updates on this? Some time has passed and there's more browser support across the board. The latest versions of Chrome, Safari, Firefox, Edge, iOS Safari, and Chrome for Android support type="module" and the nomodule attribute according to caniuse.
Looks like @babel/preset-env has an option for module output:
"presets": [
  ["@babel/preset-env", {
    "targets": {
      "esmodules": true
    }
  }]
]

And uglify has a compress option to specify version output:
new UglifyJsPlugin({
  uglifyOptions: {
    compress: {
      ecma: 6,
    }
  }
});

Quick demo of module/nomodule (view source)
Very much looking forward to the day when Next can let the browser decide which Ecma version to download!

Updates on this?
In general, when there's no comment there's no update.

@timneutkens  I imagine that making support for this implies big changes on the Next.JS codebase. Am I wrong?
@radeno wouldn't be better if instead of using <script type="module"> to load the generated bundle for modern browsers, and <script nomodule> for legacy, just add paths for the next.js server and differ which bundles need to be loaded based on the user-agent? (That's how meteor 1.7 works currently)

@JonatanSalas The user-agent solution would not be viable if your Next.JS server was behind a caching layer like a CDN.

@alexparish yeah, but using the approach explained here will lead to issues too except in the case that you can make a custom babel config to support transpiling those unsupported features.
@alexparish would you mind to explain me this?

Or at least the cache key would need to contain the user-agent which could cause problems for some use cases.

Why you consider it should cause some problems using the user-agent as the cache-key and in which cases?

@JonatanSalas Sure! I assumed your proposal would involve the Node server rendering the appropriate script tag for the user agent. If you have a caching solution in front of the Node server then the first version of the document will get cached and all user agents will be sent the same HTML and therefore script tag. To work round this any cache providers used would need to be configured appropriately. This is a burden that I don't think Next.js should put on its users.

@alexparish I see your point! Thanks for the explanation.

Nuxt.js recently merged this feature in: https://github.com/nuxt/nuxt.js/pull/4231

Hi all,
Can we start by providing a feature to remove polyfills from next.js commons bundle.
Right now what happens is that next is published to npm transpiled. So:
https://github.com/zeit/next.js/blob/d9c462bf379709db8070ff19217b12149f97b63f/packages/next/client/index.js#L18-L20
gets transpiled as
var _interopRequireDefault = require("@babel/runtime-corejs2/helpers/interopRequireDefault");
var _promise = _interopRequireDefault(require("@babel/runtime-corejs2/core-js/promise"));
if (!window.Promise) {
  window.Promise = _promise.default;
}

And this gets uploaded to npm registry. And now there is no way of removing the dependency on @babel/runtime-corejs2/core-js/promise. (I tried to pass variouspreset-env options to next/babel but then this is hardcoded into the npm registry so can't do anything. 😭 )

Related RFC: #7563

Fixed in https://github.com/zeit/next.js/pull/7704

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.


python book added

What does this PR do?
Add resource
For resources
Description
Python For Data Analysis is a book for all of those who are interested or want to get started with data analysis
Why is this valuable (or not)?
This book can be the first stepping stone to get started with data analysis
How do we know it's really free?
This book is completely free as well as the site do not require any login

Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

:warning: NOT FREE
Take care about DMCA. That a link is public on the internet does not mean that its content is free. See CONTRIBUTING guidelines

we don't accept files hosted on google drive, dropbox, mega, scribd, issuu and other similar file upload platforms
use the link with the most authoritative source (meaning the author's website is better than the editor's website, which is better than a third party website)

no file hosting services (this includes (but is not limited to) Dropbox and Google Drive links)

We only accept contents with free licenses like CC (giving creator attributions).
Excerpts or resumes are also not valid.

/labelthis: invalid
/lockthis: off-topic


Update Ecosystem and Developer Docs for Witnet Oracle

Overview
Update the ecosystem listing for Witnet as well as the developer documentation for price feeds.
Changes

update ecosystem project list for Witnet
replace witnet.svg
update price-feeds.md developer documentation for Witnet

Should we merge this to the docs branch?

Codecov Report
Base: 47.12% // Head: 77.71% // Increases project coverage by +30.59% :tada:

Coverage data is based on head (fed30f3) compared to base (3b96718).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff              @@
##           develop     #323       +/-   ##
============================================
+ Coverage    47.12%   77.71%   +30.59%
============================================
  Files           99       39       -60
  Lines         3875     1324     -2551
  Branches       765      202      -563
============================================
- Hits          1826     1029      -797
+ Misses        2049      295     -1754

Flag
Coverage Δ

boba-contracts
?

contracts
77.71% <ø> (ø)

core-utils
?

data-transport-layer
?

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

Impacted Files
Coverage Δ

packages/boba/contracts/contracts/AtomicSwap.sol

packages/data-transport-layer/src/utils/index.ts

...ices/l1-ingestion/handlers/state-batch-appended.ts

.../contracts/contracts/L1MultiMessageRelayerFast.sol

...kages/data-transport-layer/src/utils/validation.ts

packages/core-utils/src/optimism/alias.ts

...es/boba/contracts/contracts/LP/L1LiquidityPool.sol

...ba/contracts/contracts/DAO/governance/Timelock.sol

packages/core-utils/src/optimism/fees.ts

...ices/l1-ingestion/handlers/transaction-enqueued.ts

... and 50 more

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Should we merge this to the docs branch?

@Boyuan-Chen https://github.com/bobanetwork/boba/issues/333 created Issues here will address that separately.


When converting a certain byte sequence, python protobuf works, swift-protobuf does not

My system: OSX 10.11.6
Swift version: Apple Swift version 3.0.1
protoc compiler: libprotoc 3.3.0
swift-protobuf version: v0.9.26 (commit 118dbd3f91127cd9b85fc4160637ba1e92358335)
Python version: 3.6.1
The proto files I'm using are in proto2 syntax. All of the generated swift proto files work as expected and are able to be instantiated from the data I get back from the server, except for one.
The problematic proto definition looks like this:
message SubscribeToFriendsResponse {
	optional uint32 max_friends = 1;
	optional uint32 max_received_invitations = 2;
	optional uint32 max_sent_invitations = 3;
	repeated Role role = 4;
	repeated Friend friends = 5;
	repeated invitation.Invitation sent_invitations = 6;
	repeated invitation.Invitation received_invitations = 7;
}

For reference, here are the rest of the proto definitions.
I've been working with swift protobuf but also python protobuf, which is where this gets strange. With the generated python protobuf files, I am able to take the data returned by the server and instantiate a protobuf object, like so (forgive the long data sequence, but it's using this sequence that the problem arises):
def testing_function(self):
    bytes_from_server = [8, 200, 1, 16, 200, 1, 24, 200, 1, 34, 21, 8, 1, 18, 17, 98, 97, 116, 116, 108, 101, 95, 116, 97, 103, 95, 102, 114, 105, 101, 110, 100, 34, 18, 8, 2, 18, 14, 114, 101, 97, 108, 95, 105, 100, 95, 102, 114, 105, 101, 110, 100, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 9, 242, 16, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 145, 166, 180, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 37, 136, 124, 2, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 222, 230, 245, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 108, 43, 5, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 236, 235, 184, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 151, 22, 4, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 224, 254, 144, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 110, 12, 0, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 241, 219, 160, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 190, 111, 252, 2, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 146, 171, 175, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 187, 22, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 196, 150, 150, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 230, 220, 3, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 169, 169, 148, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 15, 147, 21, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 141, 254, 139, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 42, 205, 110, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 175, 229, 139, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 88, 191, 31, 0, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 162, 181, 130, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 127, 203, 19, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 210, 171, 242, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 116, 171, 19, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 208, 141, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 104, 98, 9, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 129, 175, 199, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 178, 5, 112, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 193, 222, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 26, 37, 17, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 232, 158, 216, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 103, 88, 2, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 150, 143, 244, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 55, 222, 3, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 245, 184, 140, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 21, 205, 2, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 141, 220, 163, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 38, 169, 103, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 238, 182, 129, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 181, 140, 54, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 162, 211, 228, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 45, 185, 162, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 233, 168, 181, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 244, 194, 182, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 255, 175, 233, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 227, 175, 163, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 197, 210, 189, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 153, 160, 33, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 217, 149, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 239, 136, 36, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 154, 230, 139, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 191, 229, 134, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 149, 146, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 5, 214, 115, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 192, 204, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 163, 195, 244, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 157, 231, 138, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 103, 176, 249, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 235, 209, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 170, 54, 133, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 254, 217, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 187, 148, 245, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 196, 158, 161, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 95, 56, 202, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 194, 136, 202, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 31, 251, 140, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 240, 225, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 235, 42, 109, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 133, 246, 152, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 166, 250, 243, 17, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 135, 180, 206, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 224, 47, 200, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 189, 224, 151, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 242, 60, 237, 14, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 133, 142, 132, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 6, 45, 4, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 200, 180, 140, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 84, 56, 250, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 171, 176, 226, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 95, 232, 130, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 160, 147, 129, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 8, 57, 24, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 164, 239, 162, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 100, 190, 149, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 248, 188, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 61, 225, 120, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 234, 254, 186, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 155, 55, 74, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 225, 199, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 7, 10, 32, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 145, 238, 189, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 99, 217, 14, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 195, 250, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 240, 71, 247, 17, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 140, 133, 189, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 47, 7, 10, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 146, 197, 186, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 136, 166, 18, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 220, 147, 191, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 90, 171, 84, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 177, 244, 143, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 141, 130, 104, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 226, 243, 139, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 21, 180, 18, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 193, 136, 202, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 199, 4, 34, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 224, 171, 214, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 183, 58, 127, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 150, 216, 203, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 185, 202, 205, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 158, 146, 165, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 66, 84, 56, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 214, 254, 147, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 90, 213, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 182, 188, 169, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 67, 165, 104, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 151, 152, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 98, 25, 223, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 138, 130, 216, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 203, 4, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 252, 233, 148, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 236, 51, 185, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 197, 154, 179, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 56, 62, 200, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 155, 230, 206, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 56, 177, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 161, 175, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 54, 162, 28, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 234, 227, 172, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 186, 124, 125, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 136, 174, 198, 5, 42, 55, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 29, 104, 130, 19, 0, 0, 0, 0, 18, 22, 10, 16, 103, 114, 111, 117, 112, 95, 109, 101, 109, 98, 101, 114, 115, 104, 105, 112, 18, 2, 72, 1, 26, 1, 2, 32, 3, 48, 141, 217, 215, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 190, 104, 63, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 191, 128, 155, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 229, 33, 253, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 208, 186, 192, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 150, 16, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 243, 174, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 86, 193, 102, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 174, 166, 168, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 157, 135, 17, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 172, 209, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 51, 196, 145, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 213, 152, 248, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 207, 10, 190, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 218, 155, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 90, 71, 188, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 212, 148, 212, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 101, 26, 198, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 133, 228, 243, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 69, 3, 104, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 158, 240, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 211, 49, 172, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 206, 129, 170, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 139, 75, 141, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 248, 176, 182, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 45, 142, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 242, 203, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 173, 182, 40, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 152, 160, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 40, 116, 102, 4, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 137, 176, 143, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 228, 186, 48, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 202, 156, 229, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 241, 108, 181, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 152, 180, 162, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 38, 194, 8, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 157, 158, 212, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 176, 141, 208, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 215, 178, 170, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 114, 148, 109, 21, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 163, 203, 146, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 255, 239, 205, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 242, 202, 182, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 106, 126, 203, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 144, 137, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 58, 173, 138, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 131, 206, 154, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 28, 137, 254, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 149, 230, 205, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 92, 204, 212, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 181, 184, 165, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 149, 198, 21, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 250, 233, 207, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 49, 120, 26, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 223, 172, 182, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 145, 205, 95, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 151, 133, 169, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 255, 221, 103, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 218, 178, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 31, 62, 244, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 215, 255, 213, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 179, 84, 104, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 247, 162, 220, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 22, 21, 142, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 130, 182, 148, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 40, 119, 147, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 136, 243, 167, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 216, 35, 129, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 164, 240, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 193, 1, 201, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 223, 204, 227, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 131, 21, 96, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 160, 143, 137, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 169, 148, 137, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 147, 150, 252, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 230, 138, 142, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 172, 146, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 65, 198, 109, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 169, 134, 220, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 227, 127, 203, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 251, 213, 199, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 107, 108, 187, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 159, 194, 213, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 26, 3, 109, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 162, 159, 183, 195, 5, 66, 38, 9, 68, 249, 91, 102, 167, 228, 176, 108, 18, 14, 65, 112, 111, 112, 116, 111, 120, 105, 110, 35, 49, 54, 51, 52, 24, 1, 40, 157, 185, 180, 193, 5, 53, 0, 0, 0, 0, 66, 35, 9, 16, 217, 36, 136, 176, 253, 68, 226, 18, 11, 68, 114, 83, 101, 120, 121, 35, 49, 53, 49, 50, 24, 1, 40, 247, 188, 136, 202, 5, 53, 111, 114, 80, 0, 66, 40, 9, 65, 8, 198, 176, 232, 47, 9, 74, 18, 16, 71, 97, 109, 101, 114, 71, 105, 114, 108, 55, 50, 35, 49, 55, 50, 49, 24, 1, 40, 217, 163, 236, 201, 5, 53, 0, 0, 0, 0, 66, 41, 9, 108, 137, 64, 238, 126, 103, 245, 250, 18, 17, 74, 101, 119, 87, 105, 116, 104, 87, 105, 110, 103, 115, 35, 49, 57, 57, 49, 24, 1, 40, 219, 173, 215, 201, 5, 53, 0, 0, 0, 0]
    data = bytes(bytes_from_server)
    body = proto.SubscribeToFriendsResponse()
    body.ParseFromString(data)
    print body

This function results in a properly instantiated python protobuf object, SubscribeToFriendsResponse, and the printed result looks like this:
max_friends: 200
max_received_invitations: 200
max_sent_invitations: 200
role {
  id: 1
  name: "battle_tag_friend"
}
role {
  id: 2
  name: "real_id_friend"
}
friends {
  id {
    high:<PHONE_NUMBER>7927936
    low: 1110537
  }
  role: 1
  privileges: 1
}
friends {
  id {
    high:<PHONE_NUMBER>7927936
    low: 41715749
  }
  role: 1
  privileges: 1
}
friends {
  id {
    high:<PHONE_NUMBER>7927936
...
(I can link to full output if desired)

Now, with that exact same long byte sequence returned by the server and using that same protobuf object, but in Swift instead of python, I get a schema mismatch error. Here is that same function, but in swift:
func testingFunction(){
    let bytesFromServer: Array<UInt8> = [8, 200, 1, 16, 200, 1, 24, 200, 1, 34, 21, 8, 1, 18, 17, 98, 97, 116, 116, 108, 101, 95, 116, 97, 103, 95, 102, 114, 105, 101, 110, 100, 34, 18, 8, 2, 18, 14, 114, 101, 97, 108, 95, 105, 100, 95, 102, 114, 105, 101, 110, 100, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 9, 242, 16, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 145, 166, 180, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 37, 136, 124, 2, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 222, 230, 245, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 108, 43, 5, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 236, 235, 184, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 151, 22, 4, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 224, 254, 144, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 110, 12, 0, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 241, 219, 160, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 190, 111, 252, 2, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 146, 171, 175, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 187, 22, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 196, 150, 150, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 230, 220, 3, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 169, 169, 148, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 15, 147, 21, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 141, 254, 139, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 42, 205, 110, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 175, 229, 139, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 88, 191, 31, 0, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 162, 181, 130, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 127, 203, 19, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 210, 171, 242, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 116, 171, 19, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 208, 141, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 104, 98, 9, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 129, 175, 199, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 178, 5, 112, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 193, 222, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 26, 37, 17, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 232, 158, 216, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 103, 88, 2, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 150, 143, 244, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 55, 222, 3, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 245, 184, 140, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 21, 205, 2, 0, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 141, 220, 163, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 38, 169, 103, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 238, 182, 129, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 181, 140, 54, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 162, 211, 228, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 45, 185, 162, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 233, 168, 181, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 244, 194, 182, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 255, 175, 233, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 227, 175, 163, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 197, 210, 189, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 153, 160, 33, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 217, 149, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 239, 136, 36, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 154, 230, 139, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 191, 229, 134, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 149, 146, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 5, 214, 115, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 192, 204, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 163, 195, 244, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 157, 231, 138, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 103, 176, 249, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 235, 209, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 170, 54, 133, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 254, 217, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 187, 148, 245, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 196, 158, 161, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 95, 56, 202, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 194, 136, 202, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 31, 251, 140, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 249, 240, 225, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 235, 42, 109, 3, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 133, 246, 152, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 166, 250, 243, 17, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 135, 180, 206, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 224, 47, 200, 3, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 189, 224, 151, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 242, 60, 237, 14, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 133, 142, 132, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 6, 45, 4, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 200, 180, 140, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 84, 56, 250, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 171, 176, 226, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 95, 232, 130, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 160, 147, 129, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 8, 57, 24, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 164, 239, 162, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 100, 190, 149, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 248, 188, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 61, 225, 120, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 234, 254, 186, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 155, 55, 74, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 225, 199, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 7, 10, 32, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 145, 238, 189, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 99, 217, 14, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 195, 250, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 240, 71, 247, 17, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 140, 133, 189, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 47, 7, 10, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 146, 197, 186, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 136, 166, 18, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 220, 147, 191, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 90, 171, 84, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 177, 244, 143, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 141, 130, 104, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 226, 243, 139, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 21, 180, 18, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 193, 136, 202, 200, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 199, 4, 34, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 224, 171, 214, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 183, 58, 127, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 150, 216, 203, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 185, 202, 205, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 158, 146, 165, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 66, 84, 56, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 214, 254, 147, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 90, 213, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 182, 188, 169, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 67, 165, 104, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 132, 151, 152, 192, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 98, 25, 223, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 138, 130, 216, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 203, 4, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 252, 233, 148, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 236, 51, 185, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 197, 154, 179, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 56, 62, 200, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 155, 230, 206, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 212, 56, 177, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 161, 175, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 54, 162, 28, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 234, 227, 172, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 186, 124, 125, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 136, 174, 198, 5, 42, 55, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 29, 104, 130, 19, 0, 0, 0, 0, 18, 22, 10, 16, 103, 114, 111, 117, 112, 95, 109, 101, 109, 98, 101, 114, 115, 104, 105, 112, 18, 2, 72, 1, 26, 1, 2, 32, 3, 48, 141, 217, 215, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 190, 104, 63, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 191, 128, 155, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 229, 33, 253, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 208, 186, 192, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 231, 150, 16, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 176, 243, 174, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 86, 193, 102, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 174, 166, 168, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 157, 135, 17, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 172, 209, 151, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 51, 196, 145, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 213, 152, 248, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 207, 10, 190, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 218, 155, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 90, 71, 188, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 212, 148, 212, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 101, 26, 198, 19, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 133, 228, 243, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 69, 3, 104, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 158, 240, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 211, 49, 172, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 206, 129, 170, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 139, 75, 141, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 248, 176, 182, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 152, 45, 142, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 242, 203, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 173, 182, 40, 5, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 152, 160, 128, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 40, 116, 102, 4, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 137, 176, 143, 189, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 228, 186, 48, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 202, 156, 229, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 241, 108, 181, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 152, 180, 162, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 38, 194, 8, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 157, 158, 212, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 176, 141, 208, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 215, 178, 170, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 114, 148, 109, 21, 0, 0, 0, 0, 26, 1, 2, 32, 3, 48, 163, 203, 146, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 255, 239, 205, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 242, 202, 182, 188, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 106, 126, 203, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 239, 144, 137, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 58, 173, 138, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 131, 206, 154, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 28, 137, 254, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 149, 230, 205, 190, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 92, 204, 212, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 181, 184, 165, 193, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 149, 198, 21, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 250, 233, 207, 196, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 49, 120, 26, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 223, 172, 182, 191, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 145, 205, 95, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 151, 133, 169, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 255, 221, 103, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 218, 178, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 31, 62, 244, 20, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 215, 255, 213, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 179, 84, 104, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 247, 162, 220, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 22, 21, 142, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 130, 182, 148, 197, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 40, 119, 147, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 136, 243, 167, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 216, 35, 129, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 144, 164, 240, 195, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 193, 1, 201, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 223, 204, 227, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 131, 21, 96, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 160, 143, 137, 202, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 169, 148, 137, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 147, 150, 252, 198, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 230, 138, 142, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 199, 172, 146, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 65, 198, 109, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 169, 134, 220, 199, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 227, 127, 203, 21, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 251, 213, 199, 201, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 107, 108, 187, 4, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 159, 194, 213, 194, 5, 42, 31, 10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 26, 3, 109, 18, 0, 0, 0, 0, 26, 1, 1, 32, 1, 48, 162, 159, 183, 195, 5, 66, 38, 9, 68, 249, 91, 102, 167, 228, 176, 108, 18, 14, 65, 112, 111, 112, 116, 111, 120, 105, 110, 35, 49, 54, 51, 52, 24, 1, 40, 157, 185, 180, 193, 5, 53, 0, 0, 0, 0, 66, 35, 9, 16, 217, 36, 136, 176, 253, 68, 226, 18, 11, 68, 114, 83, 101, 120, 121, 35, 49, 53, 49, 50, 24, 1, 40, 247, 188, 136, 202, 5, 53, 111, 114, 80, 0, 66, 40, 9, 65, 8, 198, 176, 232, 47, 9, 74, 18, 16, 71, 97, 109, 101, 114, 71, 105, 114, 108, 55, 50, 35, 49, 55, 50, 49, 24, 1, 40, 217, 163, 236, 201, 5, 53, 0, 0, 0, 0, 66, 41, 9, 108, 137, 64, 238, 126, 103, 245, 250, 18, 17, 74, 101, 119, 87, 105, 116, 104, 87, 105, 110, 103, 115, 35, 49, 57, 57, 49, 24, 1, 40, 219, 173, 215, 201, 5, 53, 0, 0, 0, 0]
    let data = Data(bytes: bytesFromServer)
    do {
           let response = try Bnet_Protocol_Friends_SubscribeToFriendsResponse(protobuf: data)
           print("test worked: \(response)")
     } catch let e {
           print("Error: \(e)")
     }
}

This results in:
Error: schemaMismatch
It seems like it is something particular to this byte sequence, as I've instantiated a SubscribeToFriendsResponse object (in both python and swift) and manually set all of the properties to try to represent the same byte sequence once serialized. Once serialized, it does not result in the same byte sequence that the server returns. However I am able to re-instantiate the proto object from the byte sequence I produced, both the python SubscribeToFriendsResponse and the swift SubscribeToFriendsResponse (with the exact same byte sequence). So something about this afore-pasted byte sequence is causing the python protobuf to work but the swift one to result in a schema mismatch. Any ideas? One idea that came to me as I'm writing this is that there may be an issue converting special characters. I'm going to look into it but I wanted to post this anyway since it's an issue regardless.

0.9.26 is very old; a lot of things have been changed and fixed since then.
Could you try a newer version?

Are you sure you're using the same proto definitions everywhere?  It looks like your server has a different idea of Friends than you do:
Here's a tear down of the first "friends" object in your sample message:
42, 31,   // Field 5, 31 bytes ("friends" in your message above)
    // Field 2, 18 byte subobject ("id" field of "Friend" object, has two 8-byte fields
    10, 18, 9, 0, 0, 0, 0, 0, 0, 0, 1, 17, 9, 242, 16, 0, 0, 0, 0, 0,
    // Field 3, 1 byte, value [1] ("role" field of "Friend" proto)
    26, 1, 1,
    // Field 4, value 1 ("privileges" field of "Friend" proto)
    32, 1,
    // Huh?  Field 6 here holds a large number value.  Friends message expects field 6 to be a string
    48, 145, 166, 180, 193, 5,

Some other protobuf implementations treat field type mismatches like this as "unknown" fields, but SwiftProtobuf is not forgiving of this type of mismatch.

Okay, updated to 0.9.904 and regenerated the swift structs. Have a lot of errors to fix in the project (you're right, a lot has changed), but will report back when I'm able to run it. What happened to serializedProtobufSize()?

What happened to serializedProtobufSize()?

As with many other things, we've made that internal for now, since we want our v1 release to only expose things we're absolutely positive won't ever change.  We'll expose more stuff as we go forward.
For anything you were relying on that has become internal:  Please file an Issue here explaining how you were using it.  The more we understand your usage, the better job we can do of exposing things that really make sense to everyone.

Welp, that did it. Whatever the bug was, it's been fixed since the latest version. That'll teach me not to update my version regularly 😓

Glad to hear it's working for you!


Slow Download Speed and Frequent Retry Errors in geedim

My colleagues and I have been using the geedim library to download data, and we've encountered some issues that didn't exist before. It seems like the library has recently faced some restrictions:
Slow Download Speed: The data download process has become extremely slow, which wasn't an issue previously.
Frequent Retry Errors: We are now seeing messages like "Tile downloaded failed, retry 3 of 5" very frequently. This is a new problem that didn't occur before.
It appears that the library might be facing some recent limitations. Has anything changed recently that could be causing these issues? Are there any solutions or workarounds available?
Thank you for your assistance!

We have confirmed that the issue is not related to our network

def calculate_spm_by_gee(m: str, shp_path: str, output_dir: str):
    roi = ee.FeatureCollection(shapefile.Reader(shp_path).__geo_interface__)

    def rmCloud(image):
        cloudShadowBitMask = (1 << 4)
        cloudBitMask = (1 << 3)
        qa = image.select("QA_PIXEL")
        mask = (qa.bitwiseAnd(cloudShadowBitMask).eq(0)
                .And(qa.bitwiseAnd(cloudBitMask).eq(0)))
        return image.updateMask(mask)

    def apply_scale_factors57(image):
        optical_bands = image.select('SR_B.').multiply(0.0000275).add(-0.2)
        thermal_bands = image.select('ST_B6').multiply(0.00341802).add(149.0)
        return image.addBands(optical_bands, None, True).addBands(thermal_bands, None, True)

    def apply_scale_factors89(image):
        optical_bands = image.select('SR_B.').multiply(0.0000275).add(-0.2)
        thermal_bands = image.select('ST_B.*').multiply(0.00341802).add(149.0)
        return image.addBands(optical_bands, None, True).addBands(thermal_bands, None, True)

    def addNDWI57(image):
        ndwi = image.normalizedDifference(['SR_B2', 'SR_B4']).rename('addNDWI57')
        return ndwi

    def addNDWI89(image):
        ndwi = image.normalizedDifference(['SR_B3', 'SR_B5']).rename('addNDWI89')
        return ndwi

    if int(m) < 2012:
        l5 = (ee.ImageCollection("LANDSAT/LT05/C02/T1_L2")
              .filterDate(f"{m}-01-01", f"{m}-12-31")
              .filterBounds(roi)
              .filter(ee.Filter.lte('CLOUD_COVER', 30))
              .map(rmCloud)
              .map(apply_scale_factors57)
              .mean()
              .select(['SR_B1', 'SR_B2', 'SR_B3', 'SR_B4']))

        ndwi = addNDWI57(l5)
        water = ndwi.gt(-0.005).updateMask(ndwi.lt(10))
        water = water.updateMask(water.gt(0.5))

        l5elicloud = ee.ImageCollection("LANDSAT/LT05/C02/T1_L2").map(rmCloud).map(apply_scale_factors57)
        mean_ecloud = l5elicloud.mean().clip(roi)
        SPM = mean_ecloud.expression(
            '0.0430 + 45 * red', {
                'red': mean_ecloud.select('SR_B3'),
            }).float()
        mean_ecloud = mean_ecloud.addBands(SPM.rename("SPM"))
        SPM = ee.Image(water).multiply(SPM).toFloat()

    elif int(m) == 2012:
        l7 = (ee.ImageCollection("LANDSAT/LE07/C02/T1_L2")
              .filterDate(f"{m}-01-01", f"{m}-12-31")
              .filterBounds(roi)
              .filter(ee.Filter.lte('CLOUD_COVER', 30))
              .map(rmCloud)
              .map(apply_scale_factors57)
              .mean()
              .select(['SR_B1', 'SR_B2', 'SR_B3', 'SR_B4']))

        ndwi = addNDWI57(l7)
        water = ndwi.gt(-0.005).updateMask(ndwi.lt(10))
        water = water.updateMask(water.gt(0.5))

        l7elicloud = ee.ImageCollection("LANDSAT/LE07/C02/T1_L2").map(rmCloud).map(apply_scale_factors57)
        mean_ecloud = l7elicloud.mean().clip(roi)
        SPM = mean_ecloud.expression(
            '0.0430 + 45 * red', {
                'red': mean_ecloud.select('SR_B3'),
            }).float()
        mean_ecloud = mean_ecloud.addBands(SPM.rename("SPM"))
        SPM = ee.Image(water).multiply(SPM).toFloat()

    elif int(m) > 2012:
        l8 = (ee.ImageCollection("LANDSAT/LC08/C02/T1_L2")
              .filterDate(f"{m}-01-01", f"{m}-12-31")
              .filterBounds(roi)
              .filter(ee.Filter.lte('CLOUD_COVER', 30))
              .map(rmCloud)
              .map(apply_scale_factors89)
              .mean()
              .select(['SR_B2', 'SR_B3', 'SR_B4', 'SR_B5']))

        ndwi = addNDWI89(l8)
        water = ndwi.gt(-0.005).updateMask(ndwi.lt(10))
        water = water.updateMask(water.gt(0.5))

        l8elicloud = ee.ImageCollection("LANDSAT/LC08/C02/T1_L2").map(rmCloud).map(apply_scale_factors89)
        mean_ecloud = l8elicloud.mean().clip(roi)
        SPM = mean_ecloud.expression(
            '0.0430 + 45 * red', {
                'red': mean_ecloud.select('SR_B4'),
            }).float()
        mean_ecloud = mean_ecloud.addBands(SPM.rename("SPM"))
        SPM = ee.Image(water).multiply(SPM).toFloat()

    imagename = "SD_" + m + "_SPM" + ".tif"
    filename = os.path.join(output_dir, imagename)
    geemap.download_ee_image(SPM, filename, scale=30, crs='EPSG:4326', max_tile_size=4, region=roi.geometry())

Hello.  I was able to download an "SPM" image using your code without any retries or other problems.  I used a 1 degree by 2 degree region.  Other download tests I've tried are working too.  I suspect the problem is related to your network.  It is more network reliability than bandwidth that would cause problems like these.

@dugalh  Unfortunately, I've tried several network nodes, but still exist this error

You can try setting the num_threads argument to a small value (e.g. 4) to reduce the number of concurrent requests.  The default value is based on the number of CPU cores, with a maximum of 32.
Also see the notes here if you are not using a cloud project: https://developers.google.com/earth-engine/guides/usage#legacy_quota_decrease.  The current Earth Engine concurrent request limit for legacy projects (20) is less than the geedim maximum (32), so could be the cause of your problem.

@dugalh Thank you for your reply. First, I removed the toFloat() in the line SPM = ee.Image(water).multiply(SPM).toFloat() in the code, and after that, the download process started. I'm not sure why, but previously it was stuck at 0% the entire time. I also followed your suggestion to reduce the number of concurrent threads and specified the project during the initialization. The issue has improved; although the download is slower, at least it's now working.


make it possible for profiles to have different countries

example: Joyce Akello has Uganda and South Sudan. I chose Uganda for now.

Not needed in my view, as it is rather unusual that one person can be in two countries at once :D


CSS for mdl-1.1.1 components missing

MDL 1.1.1 list component does not align properly because the required CSS styles are missing.
A workaround is to include original 1.1.1's css before the extra css.
Hope you can update this soon. Thanks!

What do you mean? Everything looks fine here http://tleunen.github.io/react-mdl/#/lists

I just realized i was on react-mdl 1.3.0 (that supports mdl 1.0.6). My mistake, will close this ticket.
Thanks for the quick feedback.


Memory16

Extracted from https://github.com/powdr-labs/powdr/pull/1790
This PR adds std and witgen support for the new 16-bit limb memory machine.

The current version only supports 24-bit addresses. I think it's fine for now, but we should fix it later.
Github fails miserably at showing the proper diff, but:

the new file double_sorted_32.rs is the same as the old unique double_sorted.rs, minus the common parts which
were left in the outermost double_sorted.rs which dispatches calls depending on the field
the new file double_sorted_16.rs is very similar to the 32 case, but adjusted for 2 value fields.

There are probably more common things we can extract, but this here is enough for a first version.

Thinking about how to resolve this:
To compare the time step, it would suffice to change the range constraint of m_diff_upper to bytes. Then, the diff is range-constrained to be at most $2^{24}$. Since we increase the time step by 4 in each CPU cycle, that means that we can prove traces up to length $2^{22}$. If that is too small, we can also constrain m_diff_upper to be 12 Bits.
For the address, doing the same would reduce the addressable space even more. I think it would be better to represent the address as 2 16-Bit limbs (as in the main machine) and assert that the address increases. This would also allow us to address the full 32-Bit space.
To assert that the address increases, there are two options with different performance implications:

Use the AddSub16 machine:

AddSub16 would commit (again) to both addresses (4 16-bit limbs), the diff (2 16-Bit limbs) and two carry bits, but only once for each address change (= for each unique address accessed, not for each memory access).
Memory16 would have to either also commit to the result, or we add an assert_gt operation to AddSub16. Also, we'd have to add a bus interaction to the memory (translates to an expected 0.5 extra witness column).

Inline assert_gt: We could re-use diff_upper & diff_lower (this time both 16-bit constrained) and would have to add two witness columns to store the carry bits.

I feel like option 1 would be simpler and not too expensive if the number of unique addresses used is low in practice. If many unique cells are used, option 2 might be cheaper, because it removes bus interactions and commits only to 2 extra values (but for each memory access).

Having looked at the witgen part a bit more, I think you can just remove the DoubleSortedWitnesses wrapper and call the two variants directly in the machine extractor. That should also help git figuring out the right diff ;)
I think it would just work, because in try_new() we fail if the column names don't exactly match the listed one, so it would always pick the right one. And you could have DoubleSortedWitnesses16 on BN254.

Will do!


[ALLUXIO-2333]Mark class BlockMasterWorkerServiceHandler final

https://alluxio.atlassian.net/browse/ALLUXIO-2333
public final class BlockMasterWorkerServiceHandler implements
BlockMasterWorkerService.Iface {

Can one of the admins verify this patch?

ok to test

Jenkins add to whitelist

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11904/
Test PASSed.

Merged build finished. Test PASSed.


Use http scheme for SOLR service tunnel URL

This isn't solely exposed as the tunnel URL, it's also there directly on the project container (and externally) as:
platform relationships --property solr.0.url

if anyone's relying on that starting with solr:// (even though they shouldn't) then it could break something. Hmm.

Sorry, so what would be the best solution here? Maybe there is a way to notify about this change in advance? Or maybe it worth introducing a new method for decorating just tunnel URLs?


Installer damages FreeBSD 14's ability to boot

Fresh install of FreeBSD, with pkg install of doas, and git. Also with a user paul added to wheel
Reboot confirmed as working - can SSH into paul. Can also login and do things from non-ssh console.
So with nothing else, installed I do:
git clone https://github.com/Wamphyre/BSD-XFCE && sh BSD-XFCE/xfce_desktop.sh
# and answer all the questions posed in default ways
sh BSD-XFCE/intel_gpu_install.sh

Then I reboot, then I see:

Rebooting subsequent times gets to the same spot. I repeated everythng (reformat drive, install FreeBSD14 from scratch, add paul, git, doas, go back into the cloned repo for BSD-XFCE, all the other steps ... and get right back to the error of the attached screenshot

I guess it is because of the renamed loader.conf... doesn't load the zfs module then this happens.
Before you reboot, rename (back)
cp /boot/loader.conf.bk /boot/loader.conf


chore: typos in scroll-tech / zkevm-circuits

https://github.com/scroll-tech/zkevm-circuits/blob/a08da074cecee804005bfd7eb3e46f02ac2ee5cc/zktrie/src/state.rs#L72
"is not need" should be "is not needed"
https://github.com/scroll-tech/zkevm-circuits/blob/a08da074cecee804005bfd7eb3e46f02ac2ee5cc/bus-mapping/src/rpc.rs#L118
"it's" should be "its"
https://github.com/scroll-tech/zkevm-circuits/blob/a08da074cecee804005bfd7eb3e46f02ac2ee5cc/gadgets/src/is_zero.rs#L4
"witnesses" should be "witnesses:"
https://github.com/scroll-tech/zkevm-circuits/blob/a08da074cecee804005bfd7eb3e46f02ac2ee5cc/gadgets/src/is_zero.rs#L17
"implementation" should be "implementing"

no

I don't quite understand what "No" means.

no

I don't quite understand what "No" means.

Neither do I... unfortunately it seems to me that this user had no intention of contributing anything to the discussion.... maybe someone from the team will speak up?

no

I don't quite understand what "No" means.

Neither do I... unfortunately it seems to me that this user had no intention of contributing anything to the discussion.... maybe someone from the team will speak up?

It would be good. Unfortunately, the issue has been open for a long time, but there is no reaction from the team. Maybe @DreamWuGit will respond

thanks for the typos pointed.  We may need to add some spelling check in CI to fix these and prevent typos in future. TODO.

Disagree with your last one but made a PR for the sake of closing this out.

thanks for the typos pointed. We may need to add some spelling check in CI to fix these and prevent typos in future. TODO.

can I do this TODO ? I would deliver it as soon as possible. thanks a lot.

thanks for the typos pointed. We may need to add some spelling check in CI to fix these and prevent typos in future. TODO.

can I do this TODO ? I would deliver it as soon as possible. thanks a lot. @lispc

that's welcome!

thanks for the typos pointed. We may need to add some spelling check in CI to fix these and prevent typos in future. TODO.

can I do this TODO ? I would deliver it as soon as possible. thanks a lot. @lispc

that's welcome!

well, the enhanced PR had been merged. I think the other project repositories of scroll also need this TODO, how do you think about that? I would check these repositories whether this TODO exists,I would push this TODO to them if they don't have.I would refer to you in related PR.


Improve rate limit tests

Codecov Report
Patch and project coverage have no change.

Comparison is base (3f9df0e) 73.33% compared to head (2e1dce2) 73.33%.

:exclamation: Current head 2e1dce2 differs from pull request most recent head b022599. Consider uploading reports for the commit b022599 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #301   +/-   ##
=======================================
  Coverage   73.33%   73.33%
=======================================
  Files          42       42
  Lines        4782     4782
=======================================
  Hits         3507     3507
  Misses       1022     1022
  Partials      253      253

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


🔧 Fixing Deprecation Warning

Regarding Issue #25
This warning is raised when you try to get the event loop before running it.
I was getting also this Error:
/Users/xxxxxxx/mailcat/mailcat.py:1818: DeprecationWarning: There is no current event loop
  jobs = asyncio.gather(*[print_results(checker, target, req_session_fun, args.verbose) for checker in checkers])

The fix works and I have tested it multiple times.

I see that you defined the new function in a top-level context, and then you are checking again if it's the call of the main. Suggest making all the new lines in the second nesting level, and just main without if __name__=='main' context

@soxoj I have taken off Tutby

@soxoj Please check script.
Now everything is working, no more errors anywhere.

@soxoj Please check the script. It seems everything is working nicely now.

Checked, all good, thanks!


ID(r) can be very inefficient for relationships

Apparently the best way to do this (until Neo4j 3.0 comes around) is START r=rel(123).
@mrstif originally found this when saving ActiveRel objects

That's gross. They claimed that this was fixed in 2.2.0.

Do you know where they said that?  Was it a GH issue or something that we can look at?

It was on the old "Is Cypher fast yet?" page leading up to the 2.2.0
release, just a query that matched and returned a rel by its ID. There was
a bug in the old planner that they said they fixed. Sounds like there's
something else going on now, though.
On Tuesday, November 3, 2015, Brian Underwood<EMAIL_ADDRESS>wrote:

Do you know where they said that? Was it a GH issue or something that we
can look at?
—
Reply to this email directly or view it on GitHub
https://github.com/neo4jrb/neo4j/issues/1032#issuecomment-153555669.


Ansible playbook with docker on travis

This pull request add test to run ansible-playbook with docker connection on Travis CI.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

This pull request includes some tweaks

update docker version. docker in trusty, docker exec could only use container id, not container name
set remote_user, Ansible 2.0.2, try to run docker exec with -u self._play_context.remote_user, Ansible 2.1.0 will includes fix for this ansible/ansible#15043, and Ansible 2.0.1 works without this workaround


#7518 Fixed type mismatch between EntityRepository#__construct() and its documented constructor arguments

Thanks @koftikes!


port bluetooth timeout setting [1/2]

This feature has been tested on resurrection remix 8.6.7 fajita and enchilada for a week, there were no issues since the first test.
Original:
https://review.calyxos.org/c/CalyxOS/platform_frameworks_base/+/235
https://review.calyxos.org/c/CalyxOS/platform_frameworks_base/+/2330

both pulls have to be merged https://github.com/ResurrectionRemix/Resurrection_packages_apps_Settings/pull/1294


CloudInitConfigDrive has bad format if userData and networkData is passed at the same time

What happened:
When the following VMI is started
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: fedora
spec:
  domain:
    cpu:
      cores: 2
      model: host-model
    devices:
      disks:
      - disk:
          bus: virtio
        name: containervolume
      - disk:
          bus: virtio
        name: cloudinitvolume
      interfaces:
      - bridge: {}
        name: default
      - bridge: {}
        name: secondary
    resources:
      requests:
        memory: 1024M
  evictionStrategy: External
  networks:
  - name: default
    pod: {}
  - multus:
      networkName: bridge-network-kvcluster
    name: secondary
  volumes:
  - containerDisk:
      image: registry:5000/kubevirt/fedora-with-test-tooling-container-disk:devel
      imagePullPolicy: IfNotPresent
    name: containervolume
  - cloudInitNoCloud:
      networkData: |
        version: 2
        ethernets:
          eth0:
            dhcp4: true
            dhcp6: true
          eth1:
            addresses: [ <IP_ADDRESS>/24 ]
            dhcp4: false
            dhcp6: false
            gateway4: <IP_ADDRESS>
      userData: |-
        #cloud-config
        password: fedora
        chpasswd: { expire: False }
    name: cloudinitvolume

The cloud-init is not loaded and failing with error
 cloud-init[653]: 2022-09-30 08:54:56,336 - util.py[WARNING]: Broken config drive: /dev/vdb

What you expected to happen:
The cloud-init sectin to be applied correctly.
How to reproduce it (as minimally and precisely as possible):
Apply the VMI from the description and virtctl console it.
Environment:

KubeVirt version (use virtctl version):  v0.53.0
Kubernetes version (use kubectl version): 1.23
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Install tools: N/A
Others: N/A

AFAIU, you're using the netplan format on a cloud init config drive data-source. That format is not supported for that data source - you'll have to use the correct format for config drive, or fall-back to no cloud data sources.

I missunderstood cloud-init networkData v2 + config drive thanks @maiqueb, closing this nonsense.


Feature: Make recommended list of friends

Describe the bug
As a new user, I don't know anyone. I would like the app to recommend friends to me. If I don't have friends in real life, I don't know who to search for. So it would be nice for the application to recommend me friends.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

We really tried this in multiple ways. however we realized that friend recommendation is actually super complex and it's kinda out of the scope of this project.


RN Firebase with Expo for tvOS

Hello!
I recently started writing an app for AndroidTV and tvOS with the expo framework.
For some time now I've been trying to figure out if it's possible to use the react-native-firebase package.
I've followed all the instructions for editing the app.json config (but only core @react-native-firebase/app for now)
When I build for iOS (for the sake of experiment) - everything seems to work as it should:

npx expo prebuild --clean
npx expo run:ios

However, if I do the same for the tvOS target:

"prebuild": "EXPO_TV=1 expo prebuild --clean"
"ios": "EXPO_TV=1 expo run:ios"

Then when installing dependencies, the console is overflowing with errors. Here is the output in the xcodebuild-error.log file:

The following build commands failed: CompileC /Users/dev-folks/Library/Developer/Xcode/DerivedData/MyTVProject-gxdeyjpvmigpvnewixfnajufgiqo/Build/Intermediates.noindex/MyTVProject.build/Debug-appletvsimulator/MyTVProject.build/Objects-normal/arm64/AppDe legate.o /Users/dev-folks/Desktop/dev/3_digital/MyTVProject/ios/MyTVProject/AppDelegate.mm normal arm64 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler (in target 'MyTVProject' from project 'MyTVProject') Building workspace MyTVProject with scheme MyTVProject and configuration Debug (2 failures)

When I opened the project via Xcode - I saw the error:

/Users/dev-folks/Desktop/dev/3_digital/MyTVProject/ios/MyTVProject/AppDelegate.mm:2:9 'Firebase/Firebase.h' file not found

I tried to install the firebase-ios-sdk package directly via Xcode and rebuild the project and it seems to work. However, I think this scenario excludes smooth operation from the js part of the application. For now the expo interface is the maximum for me. I don't feel very confident with the rn-cli and especially with native projects.
I searched a lot, but I'm not sure that I've seen even one case where a person said that everything worked out for him. Could you please guide me?
Thanks!

"@react-native-tvos/config-tv": "^0.0.10",
"@react-native-firebase/app": "^21.2.0",
"expo": "~51.0.38",

// some founded issues
https://github.com/invertase/react-native-firebase/discussions/5722
https://github.com/react-native-tvos/react-native-tvos/issues/551

It is being fixed from the react-native-firebase side
https://github.com/invertase/react-native-firebase/pull/8111

👋  react-native-firebase 21.4.0 is publishing in our CI now
Please let me/us know if anything doesn't work out - our underlying SDKs support tvOS so this should be an easy use case for us to cover

@mikehardy Thank you very much! I have to finish some things in the project first, and then I can test it. However, with the previously mentioned patches, fb analytics worked without problems on tvos version 18.0. tomorrow, I think, I will come back to this with version 18.1


How can i format the phone number in real time?

How can i format the phone number in real time?
I'm trying to use the methods like onChangeText and binding the value property, but nothing so far.

Got it working. For those who had the same issue?
                textInputProps={{
                    value: normalizePhone(value)
                }}


Add link to Tableau UI, and correct alt text

@craigkovatc   I made the your changes directly in a branch that has been now merged with the dev branch. The PR to merge dev to master for TC18 will have your additions.

Thanks @d45 !


Round Block-Inserting Suggestion

What Happened
is:open label:enhancement Allow "Round" blocks to be placed in any round slot.
Ex: [Play sound "(variable value used as sound name)"] or [Change rotation degrees by "(Ui _Up pressed)"]
The "True" or "False" output, being replaced with a 1 or 0 output instead. Also maybe add small symbols on each block type and allow us to right click a block to delete it, or duplicate it. (It would just help coding feel more natural to me since I often use scratch)
How to Reproduce
Just a suggestion
Block Coding Plugin Version
v0.7.1
Godot Engine Version
v4.3
Operating System
Windows 11
Logs or command-line output
No response
Anything else?
No response

Round blocks may have different types, so they can't be placed anywhere. For example a Vector3 round block can't be placed into a slot that expects a String block.
There are however some conversions happening and they should be improved.

In my personal opinion, type conversion should be explicit, such as using a string to integer block, that way it's value can be accurately inferred. Then, types can also have unique visual indicators, such as shapes or icons, to avoid confusion about which type it is. In Scratch, if some code accidentally adds a string and an integer, the issue might be misinterpreted. Also, in GDScript, using the + operator between a string and an integer produces an error.


Add support of strict errors

Would be nice if active_interaction could handle strict errors.
For example:
errors.add :passenger_count, 'This trip has no seats available', strict: true

strict mode throws ActiveModel::StrictValidationFailed exception. It is very useful when you want to stop any further validations.
alternative would be to add return if errors.any? after each "strict" validation.
Thoughts?

After looking at the internals of active_model/errors.rb, there is no easy way to make it work, so I guess the best is to advise not to use 'strict' mode at all.

Interesting. I haven't heard of strict errors before. In this scenario I usually do return errors.add :something. Unfortunately that only works if you're in execute (and not in a proc).
I'm not sure I understand how strict currently behaves based on your explanation. Are you saying it throws ActiveModel::StrictValidationFailed? If that's the case, the interaction should ignore the error and it will bubble up through your stack. I can see how that is unexpected, but everything's doing exactly what it said it would do.
If we wanted to handle this, it seems like the right place to do so is in ActiveInteraction::Runnable#run.

@tfausak  instead of adding error to the errors object :strict mode raises it as the exception. However the exception is missing the field's data, so it's impossible to accurately rescue exception and append info back to errors object.
As you've said return errors.add :something only works inside execute, which is not always the case.
My expectation that the interaction object run method always returns outcome object with errors. And strict mode breaks that expectation.
While I think there is no easy way to support strict mode, I feel there is a good use case for halting execution if there are errors. (see my workaround above) @tfausak would you like a separate issue for it?

I was able to get :strict to work as expected in both uses of validation on an ActiveInteraction::Base object.
On validates:
> class I < ActiveInteraction::Base
>   integer :i
>   validates :i, numericality: { greater_than: 5 }, strict: true
>   def execute; puts i; end
> end
=> :execute
> o = I.run(i: 2)
ActiveModel::StrictValidationFailed: I must be greater than 5

On errors.add:
> class I < ActiveInteraction::Base
>   integer :i
>   def execute; errors.add(:i, :invalid, strict: true); end
> end
=> :execute
> o = I.run(i: 1)
ActiveModel::StrictValidationFailed: I is invalid

We haven't re-implemented the errors. We use the existing ActiveModel::Errors module so anything it can do we should (in theory) be able to do.

I'm going to close this. If I'm missing something or didn't understand please let me know.


Update root certs and mbedTLS api to add root certs

The previous PEM method of adding certs wasn't working for all scenarios. This adds them in byte form.
Also changes the mbedtls api to use mbedtls_x509_crt_parse_der_nocopy() so that it doesn't have to create a copy of the previous string (uses the cert array as a static array).

A few comments:

Please add instructions on what these arrays are and how to generate them (i.e. xxd or other tools).
Are they base64 encoded? If yes, then can they be DER binary instead to save space?
Out of scope likely but we need to make sure customers do not copy-paste this implementation. We should have proper documentation like in C-SDK to keep CA certificates in a proper CA store. This is different on different TLS stacks and devices. (E.g. Espressif's x509 certificate bundle: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_crt_bundle.html).

A few comments:

Please add instructions on what these arrays are and how to generate them (i.e. xxd or other tools).
Are they base64 encoded? If yes, then can they be DER binary instead to save space?
Out of scope likely but we need to make sure customers do not copy-paste this implementation. We should have proper documentation like in C-SDK to keep CA certificates in a proper CA store. This is different on different TLS stacks and devices. (E.g. Espressif's x509 certificate bundle: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_crt_bundle.html).

https://github.com/Azure-Samples/iot-middleware-freertos-samples/pull/140
Added for additional notice about certificates.


How to execute a Put with a specific key

For my models, I have a compound key that I'd like to create but not concern the callers of the api - I want to do something like put('id -> generateId())(model)
The Id's are only for generating unqiueness on persistence and have no meaning for the end users, so I don't want to include them in the model...
Is this possible?

Hi Steven - hmm, that would work for insertion, but what about updates, deletes and queries? without knowing the id you're out of luck 🤔

I'm mostly concerned with the initial put

Oh I see. My strategy in this case is usually to provide a smart constructor and hide the default one:
case class Foo private (id: String, name: String)

object Foo {
  def apply(name: String): Foo =
    Foo(generateId(), name)
}

Closing as I think this is orthogonal to the library, feel free to reopen if you disagree.


MIC-105 create enum for isSaferCustodyTeamInformed column

part of aligning backend data model with frontend request body for MIC-105

Codecov Report
Attention: Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 82.91%. Comparing base (f2fa58c) to head (2d5b3f0).

Files
Patch %
Lines

...rventionplanapi/enumeration/OptionalYesNoAnswer.kt
80.00%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##               main      #66      +/-   ##
============================================
- Coverage     82.92%   82.91%   -0.01%
- Complexity      433      434       +1
============================================
  Files           106      107       +1
  Lines          1622     1627       +5
  Branches         48       48
============================================
+ Hits           1345     1349       +4
- Misses          257      258       +1
  Partials         20       20

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Stand-alone-button: customizing retured path (v2.0.0-alpha7)

Hi guys,
is there any opportunity to customize the returned path when using the standalone button?
At the moment the full path will be returned into my inputfield, eg:
_https://subdomain.domain.tld/public/img/mv/filemgr/home/03.jpg_
Let's say the rootdirectory for that user is /filemgr. Is it possible to adjust the returned value so I only receive home/03.jpg or /home/03.jpg
Laravel 5.7
Filemanager: v2.0.0-alpha7

Sorry for late reply. Example code for getting relative urls, and explanations about why the full urls are returned can be found in https://github.com/UniSharp/laravel-filemanager/issues/1233 .