version `GLIBC_2.32' not found (required by tusd)

Describe the bug
tusd_liunx_amd64.tar.gz binary is not working on Ubuntu20.04 or Debian11, It says
tusd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by tusd)
tusd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by tusd)

But the tusd_linux_386.tar.gz binary is working fine on older versions of OS.
On Ubutnu22.04 or Debian12 all binaries works as expected. Also there is no problem with ARM binaries.

glibc is provided by the OS (Debian or Ubuntu). Typically, Linux binaries compiled on newer OS releases don’t run on older OS releases for that reason.

But I think we should support the recent older OS.
I tested which last version that not encounters this problem, found v1.10.0, this works fine on Ubuntu20.04 and Debian11.
To Reproduce
Steps to reproduce the behavior:

Download v1.11.0 binary tusd_linux_amd64.tar.gz
Run on a machine which have Ubuntu20.04 or Debian11 and x86_64 arch.

Expected behavior
Binaries should support older OS versions.

This looks very similar to https://github.com/tus/tusd/issues/909. Can you please try out the solutions from there?

We can't upgrade or downgrade glibc because we don't know what will break on that.
The other option we are left with is do our own compilation, it will work surely but doing it on every upgrade of our app Zulip will be costly and also currently we don't want to add GO as dependency.

I see. But I am not sure what we can do on our end to help with this. Do you have any idea?

I'm not sure on which OS version you compiled the binaries, But I think compiling on a lower version should work on a latest version also. Did you use Ubuntu22 or Debian12 to compile binaries for v1.11.0? In case you remember which OS version you used for v1.10.0 because it works as expected, might help.

Thanks @Acconut , Is there any specific reason for using latest one? Because it is restricting the recent older OS versions.

I got a workaround for now, which is I forked the repo and did a fork release altering the release.yml file to use ubuntu-20.04 for binary building. In case someone wants to use that if they encounter similar thing, feel free to, Here is the link to the release - https://github.com/brijsiyag/tusd/releases/tag/v1.11.1
Please note this is not an official release.
Thanks a lot @Acconut for the information.

Is there any specific reason for using latest one?

I would like to keep using the latest image, yes. This way we do not have to worry about keeping the image up-to-date. Ideally, the OS that is used for cross-compilation should not influence the output binary, so changing the Ubuntu version is not the correct solution to this problem IMO.
I was wondering because at Transloadit, we also use tusd on Ubuntu 20.04 without issues. However, we are running tusd v2 in production already (the pre-releases), for which we disabled CGO (see https://github.com/tus/tusd/commit/edf8238af91b5c1ab56d6953078593c3e646bfaa). If I remember correctly, this ensures that the output binaries are statically linked and will not use libc at all. Hence, there can be no issues with glibc.
I would encourage you to also try v2 on your system and see if that helps. Maybe we can also incorporate that commit into tusd v1.

I would like to keep using the latest image, yes. This way we do not have to worry about keeping the image up-to-date.

Agree, wasn't a great question.
I tried v2.0.0-rc19, seems working fine on Debian11.

changing the Ubuntu version is not the correct solution to this problem IMO.

Yeah it is not, It is going to take time before we roll out chunk upload, So a release with CGO disabled commit will sure help if that works.
Off topic - If you are using v2 at Transloadit, will you recommend us using that in production? Because of lack of v2 features, we are doing some temporary work to get it done.
Thank you!!

Because of lack of v2 features, we are doing some temporary work to get it done.

If you are integrating tusd from scratch, I would recommend you to go with v2. Even though it is a pre-release, we use it in production without issues. There are no problems with stability, but documentation is still lacking and we might make some minor breaking changes. This is why the release is not yet complete. But building on v1 now does not make a lot of sense because v2 is be released in the next weeks and then we cannot develop v1 any further. So you would likely want to switch in the near future anyways.

I think this can be closed now. tusd v2 has been released and its release binaries are compiled without CGO and thus should not cause this issue.


A problem with camera

When I use camera to get the picture, the response.didCancel is always true after taking the photo and can't get the picture. What's wrong? It's correct in getting picture from Image Library.

On iOS or on Android ?

Are you sure that you use the latest version of the package ?

on Android, my package version is 0.18.15 @yfuks

I didn't test in iOS, because my project just use in Android. @yfuks

Can you try to run the example and tell me if you face the same issue ?

I would try it later, thanks

@yfuks I run the Example in four phones and three XiaoMi phones's  didcancel all is true, and the Sumsung Note 4 can get the image, so it's the issue of device, three XiaoMi Phones' Android version include Android 4.4.4, 5.0.2 and 5.1.1.

Since i don't have any XiaoMi phones's to test can you try to debug further ?
If you can test with allowsEditing: false and allowsEditing: true to see if there is a difference.
And in your ImagePickerModule.java try to find why Line 313 the activity result is not Activity.RESULT_OK
If you find something in your stack trace it could be great to paste it there :)

allowsEditing: false is ok to get the image, thanks a lot, nice guy.
I will try to debug ImagePickerModule.java later. Now my time is limited and facing deadline.
Otherwise can i know how you debug java code in RN project? just like Native Android？

I am facing the same problem with Meizu MX4( android 5.1).
And allowsEditing: false did solve my problem.

I am facing the same problem with iOS( 9.3).

Post your JS code

How can we move this forward?
@HughLi are you still having the problem?  I don't believe this is an issue on iOS. Just tested multiple scenarios with the Example project and it seems fine.
Will close soon if no update.

Old issue + no response from OP = closing


Support to Turnip 3.0.0 (beta)

https://github.com/jnicklas/turnip/releases/tag/v3.0.0.pre.beta.2
https://github.com/jnicklas/turnip/releases/tag/v3.0.0.pre.beta.3

Coverage decreased (-0.02%) to 95.55% when pulling 3c1a1a299c8c78e6431b7eb095f94632c27d4510 on turnip_v3 into d696be2df4edf9439eb467dee07f4e9e29df093d on master.

Coverage decreased (-0.02%) to 95.55% when pulling 93639a6c696a29992f6b6c29d4658f59ab63bb41 on turnip_v3 into d696be2df4edf9439eb467dee07f4e9e29df093d on master.


[AutoPR storage/resource-manager] [SRP] Add account sku to file/blob service response

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/7694

(message created by the CI based on PR content)

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/8379


remove redundant any check in InferRequestContentTypes

side effect of avoid an extra enumeration over the SupportedRequestFormats

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.88%. Comparing base (a17b464) to head (29b5e87).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2824      +/-   ##
==========================================
- Coverage   92.09%   88.88%   -3.21%
==========================================
  Files          91       91
  Lines        3062     3060       -2
  Branches      526      525       -1
==========================================
- Hits         2820     2720     -100
- Misses        242      340      +98

Flag
Coverage Δ

Linux
88.88% <100.00%> (-3.21%)
:arrow_down:

Windows
?

macOS
?

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

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


DownloadFileRevisited is just an assertion, right?

DownloadFileRevisited for Java is just an assertion, right? Because it isn't downloading anything at all, at least not in my case.
I suppose I need to instantiate the actual download function complimentarily, but I'm a newbie into Java and Selenium so I just want to be sure I'm not missing something here.
BTW, thanks for the great job and tutorials on Selenium WebDriver,
Dave.

The code in DownloadFileRevisited is just performing a HEAD request. This doesn't download anything. You can learn more about it here.


Fix miss of prevOrder in UtxoOps

(for review) this doesn't need an encoder migration, unlike #357, because utxoops are not part of the state.

@donhardman just curious: How did you find this? This is a really impressive bug find/fix!


Wrong capitalization of minimumintegerDigits in lib.d.ts

courtesy of @punya:
Here's an example of correct capitalization for this property: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat/resolvedOptions

fixed by #4858


Ensure we're supporting Laravel 4

Do we really need to?

Not yet sure but we got several times the question in the past few days. Even if simple to upgrade from 4 to 5, I understand it can heavy for some users. You think it's a lot of work @vinkla? Our Rails plugin targets multiple major releases without too much effort, is that something doable with Laravel? Is it common to have 1 version per major version (in that case, is it 1 or N github repositories?)?

The problem is that your current releases points against Laravel 5+ and it means that future versions will point against a downgraded versionen of Laravel. Which could cause some problems. For starter, you won't be able to use my Algolia package since it only supports Laravel 5 and above.
IMO if it is necessary to support Laravel 4 I think you should create a separate package. You'll need to create a custom Algolia manager and update the provider class to support Laravel 4. Other than that I think most of the other stuff should work fine. I don't think it would take that long to build since you already have most of the classes in this repository.


Reduce the number of unsafeRun* calls in fs2-grpc

While it may be impossible to completely remove unsafeRun* calls while depending on the Java API, this at least reduces the number of calls needed for setup of each request (by one).

@fiadliel Why did you close the PR?

While it may be impossible to completely remove unsafeRun* calls while depending on the Java API, this at least reduces the number of calls needed for setup of each request (by one).

I like that reasoning, btw.

@fiadliel I think that we end up a bit bad in those benchmarks due to thread context shifts. Every time when grpc calls us with new data we do a async boundary shift (even if we use Dispatcher's unsafeRunSync() and have the GRPC side blocking/waiting, I believe.
I tried, just for the fun of it, to increase the number of CPU's in that benchmark to something like 20 and that resulted in half the throughput of grpc-java (which did not improve in the same way as we did) - That makes me think, half the throughput indicates a context shift somewhere.

I closed the PR because I had to re-add either an unsafeRunAndForget or .start; the server implementation has to run in the background before the listener value returns. So I wanted to think a bit more.
And maybe the answer here is that instead of setting a Deferred in onMessage, that is where the implementation should be run (for the unary request case).
But now we're running on the gRPC thread pool (Cached, I think). And only for the unary case, might be better not to have a disparity with the streaming case…

@fiadliel Was it something along the lines of #486 you thought of with regards to:

And maybe the answer here is that instead of setting a Deferred in onMessage, that is where the implementation should be run (for the unary request case).


Enhance the Readme

Hello,
First of all, I would like to thank you for that program ! It seems good.
For the installation, I had a few problems. I think you should add this to your README :

python-tk dependency : apt install python-tk python3-tk
install the program with these commands :

python3 setup.py build
python3 setup.py install

I am on mac and I am getting OSError: cannot open resource when trying to run flowkey-dl. It seems to have to do with the fonts fnt = [ImageFont.truetype('FreeMono.ttf', sz) for sz in font_size]. Do you know how to fix this? I didn't run apt install python-tk python3-tk because I believe Tkinter should already be installed with python on mac.

As far as I know, tkinter should be included in python by default. However, I added the note as you suggested.
Did the installation using pip fail?
The font issue is separate, but I added additional workarounds: if freemono is not found, I now try to load arial, and if that is not there the default is loaded - which is fixed size but better than crashing the app. The fix would be to install the corresponding font on your system, such that ImageFont finds it. See https://pillow.readthedocs.io/en/stable/reference/ImageFont.html

Your fix worked, thanks @MatthiasLienhard!

@MatthiasLienhard Actually when trying to save a sheet I get this error:
saving raw image of sheet  -  to /Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/raw/5SbNyQhdXTR8gGkLJ.png
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/tkinter/__init__.py", line 1883, in __call__
    return self.func(*args)
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/flowkey_dl_gui.py", line 127, in save
    save_png(self.image, self.url.get(), self.artist.get(), self.title.get())
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/flowkey_dl.py", line 164, in save_png
    Image.fromarray(image).save(filename, pnginfo=metadata)
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/PIL/Image.py", line 2155, in save
    fp = builtins.open(filename, "w+b")
FileNotFoundError: [Errno 2] No such file or directory: '/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/raw/5SbNyQhdXTR8gGkLJ.png'

Seems like it is related to the Tkinter changes you might've made?

@MatthiasLienhard Actually when trying to save a sheet I get this error:
saving raw image of sheet  -  to /Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/raw/5SbNyQhdXTR8gGkLJ.png
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/tkinter/__init__.py", line 1883, in __call__
    return self.func(*args)
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/flowkey_dl_gui.py", line 127, in save
    save_png(self.image, self.url.get(), self.artist.get(), self.title.get())
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/flowkey_dl.py", line 164, in save_png
    Image.fromarray(image).save(filename, pnginfo=metadata)
  File "/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/PIL/Image.py", line 2155, in save
    fp = builtins.open(filename, "w+b")
FileNotFoundError: [Errno 2] No such file or directory: '/Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/raw/5SbNyQhdXTR8gGkLJ.png'

Seems like it is related to the Tkinter changes you might've made?

You have to create the "raw" directory. /Users/SGGS1234/opt/anaconda3/lib/python3.8/site-packages/flowkey_dl/raw/
@MatthiasLienhard I was talking about this in my other issue.

I assume all for all separate issues there is at  least a workaround

I assume all for all separate issues there is at  least a workaround


CLI should use canonical s3cli; instead uses an old fork of s3cli

Code: https://github.com/cloudfoundry/bosh-cli/blob/281ef97040c00319c9b4588483e9434184f83ba6/releasedir/s3_blobstore.go#L11
This fork is 200 commits behind the s3cli and most likely doesn't work with many s3-compatible blobstores like Google Cloud Storage. Should we bump this dependency (will require minor code changes) to enable better release blobstore support?

We noticed this when we tried to build the vsphere CPI on a fresh workstation:
bosh create-release  --tarball
Blob download 'vsphere_cpi_mkisofs/cdrtools-3.00.tar.bz2' (2.0 MB) (id: 93d9103d-44cf-47da-9343-49c1a4bea480 sha1: 6464844d6b936d4f43ee98a04d637cd91131de4e) started

Blob download 'vsphere_cpi_mkisofs/cdrtools-3.00.tar.bz2' (id: 93d9103d-44cf-47da-9343-49c1a4bea480) failed

Getting blob '93d9103d-44cf-47da-9343-49c1a4bea480' for path 'vsphere_cpi_mkisofs/cdrtools-3.00.tar.bz2':
  Getting blob from inner blobstore:
    Getting blob from inner blobstore:
      BucketRegionError: incorrect region, the bucket is not in 'us-east-1' region
       	status code: 301, request id:

Exit code 1

This was due to our final.yml missing an explicit region:
---
final_name: bosh-vsphere-cpi
blobstore:
  provider: s3
  options:
    endpoint: https://s3-us-west-1.amazonaws.com
    bucket_name: bosh-vsphere-cpi-blobs

The latest s3cli is able to autodetect the region based on the hostname.

@cunnie we wouldnt mind a pr to bump it to the latest version.

Bumped in https://github.com/cloudfoundry/bosh-cli/commit/06d6d5b0fc70bb74a4042eea681ae2654c381f88. New CLI is coming up.

Fixed in https://github.com/cloudfoundry/bosh-cli/releases/tag/v0.0.85.


Feat/injective perpetual

Before submitting this PR, please make sure:

[X] Your code builds clean without any errors or warnings
[X] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
This PR introduces the Injective Perpetual Gateway connector.
Tests performed by the developer:

Unit tests added for the new code.
Manually tested the functionality.

Tips for QA testing:
Please test that the newly introduced endpoints for the clob perpetual Injective connector work as expected.
Link to client PR: https://github.com/hummingbot/hummingbot/pull/6200
Link to PRP: https://snapshot.org/#/hbot-prp.eth/proposal/0x1e36039ae9ff72c133b2bcf4e7c3aa66b25693b195ac3e5c31ab7fe3f813d745

Hi @petioptrv, good day to you. Would it be possible to know the next possible update? Thank you 🙇🏼

Hi @rapcmia, I'll look into all this right now

@rapcmia, I've pinged the Injective team for assistance with the trading pairs anomaly. I suspect that Helix is filtering out those pairs for some reason.
Also, I pushed the missing json file in this commit.
Tagging @vic-en

@rapcmia, I've received confirmation from the injective team that this is a decision that they've made to exclude those markets from the Helix app. They are, however, still available to trade on the injective chain.

Hi @petioptrv , upon checking get orders, and delete PERP commands not fixed yet (no commit was provided to fix the issue)
I did some initial tests:
for INJ-USDT was able to place buy order to OPEN, failed to place sell order (bot can't see INJ balance maybe)
also successfully refreshing buy orders to OPEN (no stuck orders on exchange)
successfully cancelled buy order to OPEN after stop command
for ETH-USDT bot don't place any order to OPEN, no buy/sell order

@nikspz, the get and delete were added after-the-fact via comment edit. We will be addressing those today.

for INJ-USDT was able to place buy order to OPEN, failed to place sell order (bot can't see INJ balance maybe)
This is normal. The INJ/USDT PERP contract is collateralized in USDT, so the USDT balance is the only one that counts here. If most of the balance was used to create the long position open order, then there may have not been sufficient USDT for the short position open order. The logs reflect that.

for ETH-USDT bot don't place any order to OPEN, no buy/sell order
USDT should be the collateral here too. There were no attempts to place orders on two of the runs... This seems to me like Perp MM is deciding not to place orders, but logs are missing to clarify why. Have you tried using another strategy here or reducing the order size? If this persists, I can add debug statements in Perp MM to see why it decides not to place orders.

@rapcmia, actually, the market ID, in this case, is the hash of the INJ/USDT PERP market. I don't think you can see the order has (order ID) using this approach. You can use the get command though.
curl -s -X GET -k --key $GATEWAY_KEY --cert $GATEWAY_CERT "https://localhost:15888/clob/perp/orders?chain=injective&network=mainnet&connector=injective_perpetual&market=INJ-USDT&address=$INJECTIVE_SUBACCOUNTID"

This will give you all orders for the account and market up to a certain number of orders. You can get the orderHash from that information. This will work for both get and delete.

@petioptrv
got orders lost events during the bot run again, usually lost after
ERROR - Unhandled error in background task: <AioRpcError of RPC that terminated with:
	status = StatusCode.NOT_FOUND
	details = "object not found"details = "object not found"

Tried to test Client side, set up tight spreads to OPEN/CLOSE position firstly was able to OPEN and CLOSE few positions according or close to take profit (0.2)/ stop loss(0.15) spread set up:

injper04.18.2023.zip
logs_injper1804.log
Then I ran client little bit and its stuck with creating stop loss 😬
restarted the bot, bot was able to retrieve position 👍
and created/fill order to CLOSE position ( closed with price was worse then set up by strategy)
but after order refresh time created only buy order to OPEN
then after bot stopped, order stuck on the exchange 🙄

tried another strategy,
bot is trying place 2 orders to OPEN,
return Unhandled error in background task: No update for order for sell OPEN order.
then after order refresh time bot tries to cancel sell OPEN order, but there's no order on the exchange
https://www.loom.com/share/1ab64c35055243599d4a06be17140e7c

The above issues have been addressed in the client PR.


Auth args

I think this does a decent job of allowing users to specify their own set of args to use for authenticated methods. These changes are minimal, but add flexibility for the use of alternate argument names, or using other methods for authentication, i.e. HTTP headers in the auth_backend.

Hi,
On new release (1.0.0), you will can override the view[1][2] for this proposite.
In next steps, I will add a some examples.
Thank you.
[1] - https://github.com/cenobites/flask-jsonrpc/blob/release/v1.0.0/flask_jsonrpc/views.py#L34
[2] - https://flask.palletsprojects.com/en/1.1.x/views/


Training Step: Combining Worker Parameters Before Accumulating in Master

Need Guagua Support, already don in Guagua develop branch.
While in NNParams should implements Combinable interface.

Done in develop-0.2.8 branch


Trigger events ?

Hi,
I would like to interact with certificate creation. Is there a way to execute a script when certificates generation is complete ? One of my goal was to copy new certificates in a custom location, it could be also useful to alert for generation errors.
Thanks !

I gave up on that one as it is not a critical feature for my project. It's still waiting in the backlog for some spare time.


sound_obj.volume(int) TypeError: 'int' object is not callable

Python 3.9.0
Windows 10 Version 2004 OS Build 19041.572
Not sure if this is my fault or libs fault, but when running this code:
sound_obj.volume(current_volume)
where current_volume is an int between 0 and 100, and
sound_obj = AudioPlayer("sound/soundfile.mp3") and is currently playing with block=False, and audioplayer is imported as:
from audioplayer import AudioPlayer
A TypeError is raised, TypeError: 'int' object is not callable.
I understand that the sound_obj.volume is an int being returned from the AudioPlayer class, but I looked at the code inside the library and I'm not the best with decorators and couldn't understand how the volume was supposed to be set.

Solved the issue, just had to check your example. Proper way to do it:
sound_obj.volume = volume_value, where volume_value is from 0-100. I learned this from the example, but you might want to consider adding this in the docs so it's a little more clear. Thanks for publishing this lib though, very useful.

Hi,
volume is a property, not a method, so use obj.volume = value
I will improve the documentation with code snippets.


AttributeError: module 'modules.sd_models' has no attribute 'read_metadata_from_safetensors'

I cant put safetensors file in LyCORIS File

Your sd-webui version is too old
I will add a notice on the ReadMe

ohh ,alright thank you


Safety margin issue

This is not a real PR, but a minimal working example of #26. Running
julia --project test/safety_margin_issue.jl

multiple times yields different results each time.
I realize that this is after a bunch of changes that I've made to the schedule synthesis part, so it could be something that I did there broke it. Still, would be very helpful to find out the cause of this!

It would be nice if we could get a more minimal example that simply shows the problem on the main branch to verify that it isn't because of all the other changes here.  Shouldn't be any need to make a whole branch for it, just a short script I could copy and paste should suffice.  I could take a shot at it myself if you don't have the time, just let me know. :slightly_smiling_face:

I'll take a look today and get back to you. I think last time I tried it was only showing up in my branch so maybe something there messed things up. I'll follow up after I try it out on main.

Seems like I cannot reproduce the problem in main and the issue is likely in the changes I made after. From my initial investigation, the issue seems to stem from bounded_runs_iter() sometimes exits earlier even when using the same constraint. I.e., running
reachable = bounded_runs_iter(a, z_0, n, H, safety_margin=d_max)
if size(reachable, 1) != H+1
    @info "Size mismatch"
    return d_max
end

10 times in a row sometimes enters the if scenario even when none of the parameters have changed. My next step is to do a diff between the two branches on bounded_runs_iter and see if I made any changes there


setup-gradle is not able to use the configuration cache

I am trying to get configuration cache to work with setup-gradle github action.. but it doesn't seem to be working.
Here is the reason that shows up every time:
Calculating task graph as configuration cache cannot be reused because file '../../../../../../src900954567/src/actions-runner/_work/messaging/messaging/settings.gradle.kts' has been removed.
We are using aws hosted github runners.
The relevant github action setup is as follows:
    - name: Setup Java
      uses: actions/setup-java@b36c23c0d998641eff861008f374ee103c25ac73 # v4.4.0
      with:
        distribution: 'corretto'
        java-version: 17
    - name: Setup Gradle
      uses: gradle/actions/setup-gradle@d156388eb19639ec20ade50009f3d199ce1e2808 # v4
      with:
        gradle-version: "wrapper"
        cache-read-only: false
        cache-encryption-key: ${{ inputs.gradle-encryption-key }}
        cache-overwrite-existing: true
        add-job-summary-as-pr-comment: on-failure
        cache-cleanup: never

Thanks for the report and apologies for the delayed reply. You are likely running into #21 which makes it tricky to get configuration-cache reuse working.

I did have an included settings build but removing it hasn't fixed the issue. I still get the same problem and I no longer have included builds.

Yes buildSrc contains outputs that need to be present in order to benefit from config-cache reuse.
Closing as a duplicate of #21


When using the Full Calendar format, the time cannot be displayed correctly

Obsidian Version:
Desktop v1.6.7

This is working—I haven't been able to reproduce. Is it fixed in the current version?


rtl8812au无线网卡驱动在新的openwrt固件中网卡不稳定易死机。比如无线网卡测网速立马死机断网。重启正常！4月28号以前的固件没有这个现象？

Issue template:

Please make sure that the issue subject starts with <package-name>:
Issues related to end of life (EOL) releases are not supported or maintained and will be closed
Remove lines from top till here and fill in the following questions

Steps to reproduce:
Example: Replace the following lines and remove this

go to: Network → Interfaces → LAN (an interface with a static address) → DHCP server tab → IPv6 RA settings tab
set RA MTU and RA Hop Limit to arbitrary non-default value
Save & Apply
go to: IPv6 RA settings tab again

Actual behavior:
Example: Replace the following lines and remove this

option ra_mtu '1500' is set correctly in /etc/config/dhcp
In LuCI though, RA MTU and RA Hop Limit are still displaying the default values in light gray font color.

Expected behavior:
Example: Replace the following lines and remove this
RA MTU and RA Hop Limit are displaying the correct values found in /etc/config/dhcp in black font color.

Additional Information:
OpenWrt version information from system /etc/openwrt_release
Example: Replace the following lines and remove this
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='21.02.0-rc4'
DISTRIB_REVISION='r16256-2d5ee43dc6'
DISTRIB_TARGET='x86/64'
DISTRIB_ARCH='x86_64'
DISTRIB_DESCRIPTION='OpenWrt 21.02.0-rc4 r16256-2d5ee43dc6'
DISTRIB_TAINTS=''

Duplicate of #5565


Regarding pull-to-refresh issue

Hi,
I am writing an application for BB10 webworks (7681280). In my application I have created a container under which the content is shown. Content is occupied 7682067 which is 2 pages in height. When I trigger pull-to-refresh being on the top of the container, it works fine, no issues observed. When I scroll down the container, lets say I am at the end of the container and when I try to scroll up to see the content at the top it triggers pull-to-refresh action instead of scrolling up the container to the top.
Can some one help to understand if the approach is wrong or a known issue from Hammer.js.
Similar behaviour is observed in the example "Pull-to-refresh.html".
Thanks in advance.

Closing this due to age and inactivity this is from V1 also pull to refresh was removed


Feature: Make _sc_triggers.name unique and required

@glutamate
Currenlty _sc_triggers.name is not.
I suggest to did this + migration script to set up names:
update _sc_triggers set name = 'action'+id where name is null or name = "";

trigger name is required in the new Trigger form as of #812


Enable download stats for deepforest-tree and deepforest-bird

The models are produced using Deepforest,  a python package.
https://github.com/weecology/DeepForest

@henrykironde I've checked the deepforest models and have two comments:

is it expected that cropmodel-deadtrees weights file is called cropmodel-deadtrees.pl (instead of a .pt extension)? If not, you can rename it with the "rename" button on this page.
it seems deepforest-livestock doesn't have a weights file yet so downloads are not counted (since nothing is been downloaded ^^)

is it expected that [cropmodel-deadtrees](https://huggingface.co/weecology/cropmodel-deadtrees/tree/main) weights file is called cropmodel-deadtrees.pl

@Wauplin  we do have both .pl and .pt, How can I update that ?

@henrykironde you can open a new PR to update the download count rule like this:
countDownloads: `path_extension:"pt" OR path_extension:"pl"`,

and it'll do the trick :)


Toggle feature

Hi!
I have 6 colorpicker inputs in the same page.
I'm wondering if it's possible to have the inputs with a toggle behavior. I mean:

In the first click the color picker opens.
In the second click it closes if it's the same input.
Opens another color picker if I click in another input, just like it works now.

Is it possible?
Many thanks!

Sorry I dont understand your case. so from my point of view it's not possible ;)

I managed achieve what I needed. I used the accordion widget from Bootstrap to expand/collapse the set of picker color. Thanks anyway!
Cheers,
Ana

Great that you figure it out!


Convert to Bash?

Is there a specific reason to use /bin/sh over explicit /bin/bash ?
Doesn't the standard-shell cause more problems (since its different on more platform?)

sh is more cross-platform, e. g. in FreeBSD there is no bash in default setup. So i prefer sh here.

/bin/sh is actually just the default shell iirc
So its just a symlink to the actually used shell like /bin/bash on debian (whats it on mac/freebsd and co btw?)
=> I thought we could gain stability by explicitly using a certain shell instead of "the standard one on a specific system"?


LargeTexture on Sprite3D

Operating system or device - Godot version:
Current master branch, Linux
Issue description (what happened, and what was expected):
I can't use a LargeTexture on a Sprite3D. It just displays a white rect.
Is there any other way of handling large textures (>1024px) in 3D i don't know of?
Edit: My problem is not disk space but the texture size limitation on mobile devices.

Try using a standard ImageTexture with lossy compression (WebP) instead of a LargeTexture.

Does Godot split the textures into pieces then or handles very large textures in another way?
Because we can't use very big textures on mobile devices...

Seems like it's not splitting the texture..

Have you tried with a Quad?

A Quad renders only white, too.

First of all thank you for your report and sorry for the delay.
We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.
We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?
For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.
Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.
Thanks in advance.
Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

There is no way to test a large texture on Godot 3 since it does not have any means to import in that format, this issue may be relevant to Godot 2 only.

Closing then as I doubt this will be fixed in the 2.1 branch by now.


match doesn't rebind this

It seems that match doesn't do the right thing that switch does with this:
foo:
  match @bar
  | foo => bar

compiles to:
  foo: (function(){
    var ref$;
    switch (ref$ = [this.bar], false) {
    case !foo(ref$[0]):
      return bar;
    }
  }())

wow, that was fast! thanks :)


None vs exceptions in returns

As discussed, we should improve the exception and return handling for certain parts of the code. Per @jrmontag suggestion, perhaps we limit exceptions to areas where the code actually breaks and return None in areas where a non-required field is not present.
As an example,
def get_geo_coordinates(tweet):
    """
    return the geo coordinates, if they are included in the payload
    else raise 'unavailable field' error
    """
    if "geo" in tweet:
        if tweet["geo"] is not None:
            if "coordinates" in tweet["geo"]:
                [lat, lon] = tweet["geo"]["coordinates"]
                return {"latitude": lat, "longitude": lon}
    raise(NotAvailableError("Geo coordinates are not included in this Tweet"))

could be changed to return None or {}.

Done.
Currently, the only time a getter will raise an error is if the user tries to get poll data from activity streams Tweets (poll data is currently unavailable in any activity streams formatted data).


Add methods for getting and setting individual color channels for all color spaces.

Objective
Fixes #7746 except for making them const which is blocked on const float arithmetic.
Solution
Added a bunch more methods for getting and setting individual color channels for every color space.
Changelog
Added

X_Y Get the Y value in linear X colorspace.
set_X_Y Set the Y value in X colorspace.
with_X_Y Returns this color with Y set to a new value in X colorspace.

For all the remaining channels and color spaces.

For the docs on all the set_ functions, it doesn't just return in the given kind, it also modified self.
I so much want to remove that file 🙁

I so much want to remove that file 🙁

I personally think using a crate like palette is the way to go


openmp scheduler throwing runtime error for set_num_threads_with_affinity()

Output of 'strings libarm_compute.so | grep arm_compute_version':
arm_compute_version=v21.05 Build options: {'Werror': '1', 'debug': '0', 'neon': '1', 'opencl': '0', 'openmp': '1', 'cppthreads': '0', 'os': 'linux', 'arch': 'armv8.2-a', 'build': 'native'} Git hash=b'dfc8109764b0dd97cb35b0664f8d3cb350aeb20b'
Platform:
NeoverseN1
Operating System:
Linux (Ubuntu 20.04)

Problem description:
When I switch the acl scheduler from cppthreads to openmp, there is a runtime assertion from set_num_threads_affinity() function. However, when I just skipped the check (by commenting the assertion from IScheduler.cpp) I'm able to proceed and use openmp scheduler properly. Would like to understand the rational for this assertion logic and how to overcome this for OpenMP scheduler.
Steps to reproduce the issue:

build acl with openmp backend
scons Werror=1 -j8 debug=0 neon=1 opencl=0 openmp=1 cppthreads=0 os=linux arch=armv8.2-a build=native

Build oneDNN with these ACL libraries and test benchdnn, eg:
DNNL_VERBOSE=1 benchdnn --conv --dtag=nhwc --stag=nhwc --wtag=nhwc --cfg=f32 --mb=1 ih224oh112kh7sh2dh0ph3_iw224ow112kw7sw2dw0pw3_ic3_oc64

Here is the error log:
terminate called after throwing an instance of 'std::runtime_error'
what(): in set_num_threads_with_affinity src/runtime/IScheduler.cpp:50: Feature for affinity setting is not implemented
Aborted (core dumped)

Hi! Thanks for raising this issue. The set_num_threads_with_affinity method is not implemented for OMP scheduler, hence the error. Please use the set_num_threads method instead.

Thanks for the details.


Wrong syntax on library information example code

The example on retrieving library information returns undefined as the version is nested one further level down than the example provided IE: libraryInfo.libraryInfo.version. Rather than the duplication of 'libraryInfo' I changed the function argument to data so it becomes data.libraryInfo.version however will defer to Adobes knowledge.

Thank you for submitting this contribution. We will review and respond asap.

@arobsco Thank you for submitting the report. This has been resolved and the documentation has been updated: https://docs.adobe.com/content/help/en/experience-platform/edge/fundamentals/debugging.html#retrieving-library-information


setup.sh doesn't work with Cloudflare

I followed the tutorial and can't seem to make Cloudflare to work with certbot. Tried using CSR (origin cert in Cloudflare) but still didn't work.
Step 7 in deploy of uploading the code to the server is the problem. It seems it can't point to my domain properly.
Essentially I can't ssh using the domain (instead of IP).
git remote add prod<EMAIL_ADDRESS>ssh: connect to host [redacted.xyz] port 22: Operation timed out

I only have a passing familiarity with using Cloudflare--am I correct in assuming that your domain is pointed at a Cloudflare IP address rather than at your server's IP? In steps 5 and 6, were you able to run the scp / ssh commands using your domain, or did you use your server's IP address instead? Assuming you used the IP address and that worked fine, you should be able to do the same in step 7 I believe.
As for step 6 of actually running setup.sh, I'm assuming you'd need to comment out the certbot bit and follow Cloudflare's instructions for installing a cert on your server.

Thanks @jacobobryant
So I just forgo using cloudflare completely, seems an unnecessary hassle. And it works.
But now I'm getting this when I bb deploy:
fatal: invalid refspec '' Error while executing task: deploy

Sorry my bad, it was a typo when I uncomment the task
biff.tasks/deploy-cmd ["git" "push" "prod" "main:master"]
It's missing a colon 😂

ah, glad you got it working!


Education Page

Initial Requirements:

Have a chronologically (by year and trimester) ordered list of courses taught by members of the group [1] [2]
Each course should have a small description, link to KEATS/KCL and list of recommended readings [1] [2]
Should be grouped by the lead lecturer [2]

To be discussed:

N/A

References:

http://engineering.nyu.edu/microbioengineering/teaching.html
http://svl.stanford.edu/teaching/

Discussion from 23/04/2020 meeting group

[ ] Add Schema
[ ] Add years in the top


[Question] Trying to connect with Redis Server

Hi,
I am trying to use your FromCache() Extention and using Redis Cache as caching provider. I have configured the QueryCacheManager.Cache like this
var connectionMultiplexer = ConnectionMultiplexer.Connect("localhost:6379");			 QueryCacheManager.Cache = new RedisObjectCache(connectionMultiplexer.GetDatabase(), Newtonsoft.Json.JsonConvert.SerializeObject, (type, s) => Newtonsoft.Json.JsonConvert.DeserializeObject(s, type));
And when I am using your default CacheKeyFactory then it is throwing me below error

And when I configure the CacheKeyFactory to
QueryCacheManager.CacheKeyFactory = (context, key) => { // Custom cache key generation logic var cacheKey = $"{key}_{context}"; return cacheKey; };
then it throws me this error

And this is how I am using your FromCache() Extention
`IQueryable users = _context.User;
var service = _context.User.FromCache("A1").ToList();`
Basically I have tested your FromCache() Extention with IMemoryCache everything as default that time it works fine for me, then I have a requirement where I need to support Distributed Caching then I got to know this library supports Redis which is used for distributed caching.

Hello @akash159chauhan ,
Do you think you could create a runnable project with the issue? It doesn’t need to be your project, just a new solution with the minimum code to reproduce the issue.
The current issue is to early and happens on the GetObjectQuery, which normally is only related to the LINQ query, so we are currently unsure how to reproduce this issue.
Best Regards,
Jon

Sponsorship
Help us improve this library
Performance Libraries
context.BulkInsert(list, options => options.BatchSize = 1000);
Entity Framework Extensions • Dapper Plus
Runtime Evaluation
Eval.Execute("x + y", new {x = 1, y = 2}); // return 3
C# Eval Function

Hi Jon, this is the link of the Project https://github.com/akash159chauhan/WebApplication you can check the UserController where I am testing your Library, and also suggest if I am doing something wrong as I have very small knowledge of using Cache.

Hello @akash159chauhan ,
In your project, you are currently using a package that is for EF6 and not EF Core 6. You need to use the following package and match the EF Core major version, which the one from this package (in this case, `v6.x): https://www.nuget.org/packages/Z.EntityFramework.Plus.EFCore/6.18.3
Unfortunately, after looking more, it looks like we still doesn't support Redis for EF Core. We already have more tasks than we currently handle in the short-term plan, so unfortunately, adding support to Redis is not something we can currently do.

Hi Jon,
Yes I know that you have not given support of Redis for EF Core but it is supported in EF6 package, and I have tested with the package version which you have suggested but the problem is still same.
Aand I want to know if I create a custom class and Inherit with ObjectCache, to give the similar support of Redis like you have created RedisObjectCache then can FromCache() extentions will support this custom class out of the box, or I also have to create similar FromCache() extention to support Redis. As my need is that I want to support two caching functionality:

First which is going to use IMemoryCache for non-distributed environment
Second which is going to use Redis for Distributed environment.
And on the basis of Cache Configuration the FromCache() extension will going to switch between the above two cache.

Hello @akash159chauhan ,
The only way to know your answer is to try it on your side. Unfortunately, as we do not support it yet, we don't have the answer yet either to your question.

Hi Jon, did you have any running working example of using RedisObjectCache(). And Example or Unit Test can do a work for me. Thanks.

It has been a long time since we played with Redis but we have a lab that look like this:
public string SerializeObject(object objToSerialize)
{
	return Newtonsoft.Json.JsonConvert.SerializeObject(objToSerialize);
}

public object DeserializeObject(Type entiType, string serializedString)
{
	return Newtonsoft.Json.JsonConvert.DeserializeObject(serializedString, entiType);
}

var lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{

	string cacheConnection = "<IP_ADDRESS>:6379,allowAdmin=true";
	return ConnectionMultiplexer.Connect(cacheConnection);
});

QueryCacheManager.Cache = new RedisObjectCache(lazyConnection.Value.GetDatabase(), SerializeObject, DeserializeObject);


Fix output warnings from optional resources

Fixes the warnings from Terraform about splat syntax requirements.

@Oralordos I wonder if we should do something about the original mis-spelling of inbound ?
The API seems to indicate that it is called allow_inboud_http_api

@blaisep Use version 0.10.8 there is an issue with 0.11.x and backward compatibility

@Oralordos Thank you for submitting this fix! It looks fine, but since this is an official HashiCorp repo, i wanted to abide by the official Terraform 11 convention for Referencing Attributes from Resources with Count = 0. I've implemented that in #12.
Also, thank you to @blaisep for the typo call-out. I've fixed that in #13. Therefore, I'm going to close this PR and not merge.


Segmentation fault on training

Hi,
whenever I try to run train.py, I get a segmentation fault error. After some debugging, I found out that it crashes on the following instruction (line 136):
_, gs = sess.run([g.train_op, g.global_step])
What could be the cause? Did anyone experience the same error before?
Please let me know if you need more detail.
Python interpreter version: 2.7, 3.6.1 (same outcome with both versions)
Tensorflow version: 1.14.0

Update: preprocessing the data seems to resolve the issue.
I would then assume that it's mandatory to do so, , even if the documentation does not specify it. Can someone motivate this?


Fix sandbox regressions

🤦♂

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Building or testing the playground has failed.
If the tests failed, results can be found here:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/15954/merge/testResults/

You have changed file(s) that make changes to the playground.
You can test the snapshot here:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/15954/merge/
The snapshot playground with the CDN snapshot (only when available):
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/15954/merge/?snapshot=refs/pull/15954/merge
Note that neither Babylon scenes nor textures are uploaded to the snapshot directory, so some playgrounds won't work correctly.

You have changed file(s) that made possible changes to the sandbox.
You can test the sandbox snapshot here:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/SANDBOX/refs/pull/15954/merge/

You have changed file(s) that make changes to the playground.
You can test the snapshot here:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/15954/merge/
The snapshot playground with the CDN snapshot (only when available):
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/15954/merge/?snapshot=refs/pull/15954/merge
Note that neither Babylon scenes nor textures are uploaded to the snapshot directory, so some playgrounds won't work correctly.

Snapshot stored with reference name:
refs/pull/15954/merge
Test environment:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15954/merge/index.html
To test a playground add it to the URL, for example:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15954/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15954/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15954/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15954/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15954/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15954/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15954/merge/testResults/webgpuplaywright/index.html

WebGL2 visualization test reporter:
https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/15954/merge/testResults/webgl2playwright/index.html


RuntimeError: CUDA error: an illegal memory access was encountered

When i put torch.cuda.synchronize() to test the inferfence time, it causes error.
import bitblas
import torch
import time

# enabling debug output
# bitblas.set_log_level("Debug")

model = bitblas.Linear(
    in_features=1024,
    out_features=1024,
    bias=False,
    A_dtype="float16",  # activation A dtype
    W_dtype="int4",  # weight W dtype
    accum_dtype="float16",  # accumulation dtype
    out_dtype="float16",  # output dtype
    # configs for weight only quantization
    group_size=None,  # setting for grouped quantization
    with_scaling=False,  # setting for scaling factor
    with_zeros=False,  # setting for zeros
    zeros_mode=None,  # setting for how to calculating zeros
    # Target optimization var for dynamic symbolic.
    # For detailed information please checkout docs/PythonAPI.md
    # By default, the optimization var is [1, 16, 32, 64, 128, 256, 512]
    opt_M=[1, 16, 32, 64, 128],
)

# Create an integer weight tensor
intweight = torch.randint(-7, 7, (1024, 1024), dtype=torch.int8)

# Load and transform weights into the BitBLAS linear module
model.load_and_transform_weight(intweight)

# Save the state of the model
# torch.save(model.state_dict(), "./model.pth")

# # Load the model state
# model.load_state_dict(torch.load("./model.pth"))

# Set the model to evaluation mode
model.eval()

# Create a dummy input tensor
dummpy_input = torch.randn(1, 1024, dtype=torch.float16)

# Perform inference
st = time.time()
output = model(dummpy_input)

torch.cuda.synchronize()

end = time.time()
print(end - st)

here is my cuda info:

maybe you forget to put the input tensor and weight tensor to cuda.

yes, I think it is on cuda by default.


Push Notifications - Multiple apps using same Parse Server

Hi,
Previously when using Parse's hosted solution, I used to be able to send Push Notifications to multiple iOS applications that were using the same Parse app.
Obviously, the bundle id's were different so the .p12 certs had to be uploaded for both apps, dev and prod, which meant I had 4 certs for one Parse app.
On Parse Server, I tried adding more than 2 certs to replicate this behaviour, and it didn't seem to work.
Any suggestions?
Thanks

Just specify all of your configurations in an array. I can confirm that this works as expected.
From https://github.com/ParsePlatform/parse-server/wiki/Push#2-configure-parse-server

For iOS, if you need to support both the dev and prod certificates, you can provide an array of configurations like
...
If you have a list of certificates, Parse Server's strategy on choosing them is trying to match installations' appIdentifier with bundleId first. If it can find some valid certificates, it will use those certificates to establish the connection to APNS and send notifications. If it can not find, it will try to send the notifications with all certificates. Prod certificates first, then dev certificates.

Thanks for the response.
In my index.js now, I have the iOS push certificates like this:
push: {
    ios: [
      {
        pfx: 'aps-dev-2.p12', // Dev PFX or P12
        bundleId: 'bundleId2-here',
        production: false // Dev
      },
      {
        pfx: 'aps-prod-2.p12', // Prod PFX or P12
        bundleId: 'bundleId2-here',
        production: true // Prod
      },
      {
        pfx: 'aps-dev-1.p12', // Prod PFX or P12
        bundleId: 'bundleId1-here',
        production: false // Prod
      },
      {
        pfx: 'aps-prod-1.p12', // Prod PFX or P12
        bundleId: 'bundleId1-here',
        production: true // Prod
      }
    ]
  },

Please note that the first 2 entries were here previously and worked without issue.
Now when trying to send a push with all 4 specified, and targeting installations that I know will use one of the 3rd or 4th certificates, my server crashes with these logs:
2016-07-01T21:46:22.769285+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=POST path="/parse/classes/_PushStatus" host=sporter-mobile.herokuapp.com request_id=cb1b136f-947d-4ff9-81c9-169931e18de5 fwd="<IP_ADDRESS>" dyno= connect= service= status=503 bytes=
Strange!
Any ideas?
Thanks

@nickjf89 Are you able to test locally so you can get the full error message instead of just heroku logs?
I suspect that perhaps you don't have the .p12 files on your server. Can you confirm that they're there and in the same directory as the file that has your push configuration? I typically give an absolute path to the file by using __dirname as the current directory:
pfx: __dirname + "/push_certs/push-cert-dev-1.p12",

Hi nick,
Did you solved this issue?? May I ask how?? Thank you.

 I was pointing to the wrong directory. If they're there, they work!

@nickjf89 , @JeremyPlease :
hi man, I tried but failed, can you point me out where I'm wrong?
My p12 files' path are:

My cloud code in index.js are:
push: {
ios: [
{
pfx: __dirname +'/push_certs/DevPushLoveAgainPro.p12', // Dev PFX or P12
bundleId: 'com.app1',
production: false // Dev
},
{
pfx: __dirname +'/push_certs/ApplePushLoveAgainPro.p12', // Prod PFX or P12
bundleId: 'com.app1',
production: true // Prod
},
{
pfx: __dirname +'/push_certs/DevPushLoveAgainFree.p12', // Prod PFX or P12
bundleId: 'com.app2',
production: false // Prod
},
{
pfx: __dirname +'/push_certs/ApplePushLoveAgainFree.p12', // Prod PFX or P12
bundleId: 'com.app2',
production: true // Prod
}
]
}

Hey guys, any body there can help to answer my question? Really appreciate!

@allen8300 Your question is best suited for posting on Stack Overflow. You can post your complete code, configuration, and reproduction steps there.


connect_activate with mutable variables

Using a mutable variable in a connect_activate closure gives an error: cannot borrow captured outer variable in an `Fn` closure as mutable
Example code:
let item = MenuItem::new_with_label("Add one");

struct Variable {
    pub value: u32
}

let mut x = Variable {
    value: 0
};

impl Variable {
    pub fn add(&mut self, x: u32) {
        self.value += x;
    }
}

item.connect_activate(move |_| {
    x.add(10);
});

Rc<RefCell<YourVariable>>

item.connect_activate(move |_| {
    Rc< RefCell<x> >.add(10);
});

in that example gives chained comparison operators require parentheses and expected expression, found `>`

O.O

Do you even rust?

So, going from basics. Copy/paste this macro into your code. Then use it as follow.

item.connect_activate(move |_| {
    Rc< RefCell<x> >.add(10);
});

in that example gives chained comparison operators require parentheses and expected expression, found `>`

I just started out with Rust, yeah, but thanks for the help anyhow. It seems to work

No problem, it just caught me completely off guards. Hope it helped!

I'm sorry for saying it; but it still doesn't work.
    let item = MenuItem::new_with_label("Add one");

    #[derive(Clone)]
    struct Variable {
        pub value: u32
    }

    let mut x = Variable {
        value: 0
    };

    impl Variable {
        pub fn add(&mut self, x: u32) {
            self.value += x;
        }
    }

    item.connect_activate(clone!(x => move |_| {
        x.add(10);
    }));

The macro is at the top of the file.
Yet I keep getting the same error. I'm not sure what I'm doing wrong...

You still don't use Rc<Refcell<T>>. Try this:
let item = MenuItem::new_with_label("Add one");

#[derive(Clone)]
struct Variable {
    pub value: u32
}

let mut x = Rc::new(RefCell::new(Variable {
    value: 0
}));

impl Variable {
    pub fn add(&mut self, x: u32) {
        self.value += x;
    }
}

item.connect_activate(clone!(x => move |_| {
    x.borrow_mut().add(10);
}));

Nice, now it does work :smile:  thanks again


Add a persistence hook based on cockroachdb/pebble.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

357 of 359 (99.44%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.05%) to 98.663%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

hooks/storage/pebble/pebble.go
357
359
99.44%

Totals

Change from base Build<PHONE_NUMBER>:
0.05%

Covered Lines:
6049

Relevant Lines:
6131

💛  - Coveralls

Hello, does it works out of box now?
Will it still cause cached file unlimited grow?

Will release a new version so that go mod can update?


Is it any method to check current file was be formated?

I want to display a tips went I save file.

I'm sorry, I don't understand what you're asking. What is that you want to display when you save a file? I don't know what "tips" means in this context.

sorry, I means that whether the file can be able to formatting, whether the file is already been formatted to the best.

No, such function does not exist yet. If want/need it, you need to write it yourself.

thx


Feature/robot  automation fix

Critical Changes
Changes
Issues Closed
New Metadata
Deleted Metadata

@davisagli @boakley can you plz review this.


Time decay of t-digest

Hey @tdunning,
This is a re-posting of the now closed #55. I'm interested in re-opening the exploration into how to properly decay a t-digest. The t-digest is attractive due to its high precision and relatively compact serialization with no range configuration. It is a perfect fit for approximate quantile estimation of large data sets. It seems to me that it could additionally be a good data structure to track activity on a server.
The common data structure people reach for in the context of server monitoring is the HDR histogram. The especially nice thing about the histogram in this setting is that it is robust to non-uniform sampling rate. A common monitoring architecture today (using something like https://prometheus.io/) will collect a snapshot of values from servers periodically where the collecting server chooses the timestamp. Histograms can report cumulative values and then can subtract the previous timestamp's bucket counts from the current to get a view of the data between the two.
The t-digest doesn't offer this convenient subtraction mechanism making it more difficult to use in this sort of setting. One solution people sometimes offer is to use collection as a trigger to reset the t-digest. This is problematic in the face of more than one collector (as is the recommendation for HA prometheus).
An alternative to only reporting the cumulative distribution would be to sample a distribution which represents the previous trailing period. I've experimented with this a bit and it seems roughly reasonable though with some unexpected behavior as few new points are recorded and the count decays away.
The approach in the blog post linked to #55 feels both high in terms of overhead and it is not completely obvious to me exactly how to map that idea on to the t-digest. Have you given this topic more thought? Do you have a hunch on good approaches?

My feeling for this is that addition is more robust than subtraction.
As such, we can build a history of digests for relatively small periods and
occasionally combine them into larger intervals. This is the same sort of
thing that has to be done with hyper-log-log and most other sketch data
structures. They may support subtraction, but the result usually inherits
relative accuracy from the operands which is disastrous.
In the case of HA collectors, you can get perfect consistency if all events
have an event time. You can also retire digests for time periods as soon as
possible if you have a watermark for the stream of data, but simply
overwriting a digest with late updates probably is just fine as well.
If events don't have event times or you don't want to respect them then you
have to depend on processing time. This is bad juju because it means that
the results of a program depend on when it is run, but it can be done. In
that case, the different HA collectors will have slightly discrepant
results.
On Tue, May 7, 2019 at 8:40 PM ajwerner<EMAIL_ADDRESS>wrote:

Hey Ted,
This is a re-posting of the now closed #55
https://github.com/tdunning/t-digest/issues/55. I'm interested in
re-opening the exploration into how to properly decay a t-digest. The
t-digest is attractive due to its high precision and relatively compact
serialization with no range configuration. It is a perfect fit for
approximate quantile estimation of large data sets. It seems to me that it
could additionally be a good data structure to track activity on a server.
The common data structure people reach for in the context of server
monitoring is the HDR histogram. The especially nice thing about the
histogram in this setting is that it is robust to non-uniform sampling
rate. A common monitoring architecture today (using something like
https://prometheus.io/) will collect a snapshot of values from servers
periodically where the collecting server chooses the timestamp. Histograms
can report cumulative values and then can subtract the previous timestamp's
bucket counts from the current to get a view of the data between the two.
The t-digest doesn't offer this convenient subtraction mechanism making it
more difficult to use in this sort of setting. One solution people
sometimes offer is to use collection as a trigger to reset the t-digest.
This is problematic in the face of more than one collector (as is the
recommendation for HA prometheus).
An alternative to only reporting the cumulative distribution would be to
sample a distribution which represents the previous trailing period. I've
experimented with this a bit and it seems roughly reasonable though with
some unexpected behavior as few new points are recorded and the count
decays away.
The approach in the blog post linked to #55
https://github.com/tdunning/t-digest/issues/55 feels both high in terms
of overhead and it is not completely obvious to me exactly how to map that
idea on to the t-digest. Have you given this topic more thought? Do you
have a hunch on good approaches?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tdunning/t-digest/issues/127, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB5E6TALZF4V2IEACX32UTPUJDTNANCNFSM4HLOD3VQ
.

If events don't have event times or you don't want to respect them then you
have to depend on processing time. This is bad juju because it means that
the results of a program depend on when it is run, but it can be done. In
that case, the different HA collectors will have slightly discrepant
results.

I tend to agree with this point-of-view. The metrics world roughly falls in to 2 camps, push based and pull based. Ideally the pull-based metrics would would have agreed to some amount of server buffering of recent data where the client dictates the timestamp. This at least would have made HA easier to implement without the complications discussed. Unfortunately Prometheus seems to be the winning and in that world the collector assigns the timestamp. The Prometheus push gateway is even worse as there the Prometheus server assigns the timestamp based on when the collector reads from the push gateway. Alas event times in the Prometheus metrics world isn't really an option.

As such, we can build a history of digests for relatively small periods and
occasionally combine them into larger intervals.

This has added memory overhead for each of the finer granularity time windows.

For some more context, I'd love to hack soon on adding first-class support for t-digests into prometheus (https://github.com/prometheus/prometheus/issues/2682). Prometheus today allows you to report histogram buckets where each bucket is a timeseries and then provides query-language support to aggregate them. These things are often hundreds of buckets and give pretty low precision with a pre-configured range. t-digests could use a similar pattern such that instead of a timeseries per bucket you have two timeseries per centroid based on the index of the centroid where the total number of timeseries is 2*delta. The high-index timeseries will be NaN most of the time but prometheus does a good job with compression (I need to verify that it compresses contiguous NaNs well but that's what I have in mind).
I'm worried about the aliasing and lost due to ticking at a fixed rate that's on the order of the collection rate. I'm worried about the overhead (primarily memory overhead) of keeping multiple t-digests at a finer granularity and merging them at read time and rolling them off the end of the ring-buffer. I suppose this could be made better by eliminating the write buffer of the merging digest for "sealed" t-digests making this approach somewhat more attractive.
Something I've been playing with lately is just quantizing time in to some tick unit, say maybe 1 second, and then using EWMA techniques on the count. Imagine we have some value alpha < 1, I add points with a weight of alpha and then every tick unit I merge the centroids and decay their count by 1-alpha.
The formula for choosing the decay factor is driven by the tick rate and a user-provided timescale (say 5 minutes).
averageTickAge = tau / (2 * tick)
alpha = 2 / (averageTickAge + 1)

This approach seems to get close to what I want to see. It seems particularly in the middle of the distribution to track the trailing distribution on roughly the timescale provided. The problem as far as I can tell is that the decaying seems to flatten out and become fatter-tailed over time. I suspect the addition of some decay threshold to filter out centroids which have been sufficiently decayed will help and I'm going to experiment with that. Perhaps that value should just be alpha^(2 * averageTickAge).
Does this basic approach of quantizing time and using a traditional EWMA over weights seem reasonable? If yes, then there's the details of how sound are the actual details of this approach.

Restarting.
Yes. This approach to decay sounds pretty reasonable, but you will have very little idea about accuracy as things begin to decay. I suppose that you can still say that the invariants hold as much as they ever did, but I don't think you can say much more than that.
Is the cost of windowed digests all that high? If you have compression = 100, then sealed digests will only have about 100 floats to store or fewer if there are not very many samples. This is on the order of a kilobyte or so. How many of these do you think you will need to keep in memory? Even keeping millions isn't that big of a deal.

Restarting.
Yes. This approach to decay sounds pretty reasonable, but you will have very little idea about accuracy as things begin to decay. I suppose that you can still say that the invariants hold as much as they ever did, but I don't think you can say much more than that.
Is the cost of windowed digests all that high? If you have compression = 100, then sealed digests will only have about 100 floats to store or fewer if there are not very many samples. This is on the order of a kilobyte or so. How many of these do you think you will need to keep in memory? Even keeping millions isn't that big of a deal.

On the topic of integration with Prometheus, I think that sounds like a great idea.
How can I help?

On the topic of integration with Prometheus, I think that sounds like a great idea.
How can I help?

I don' have any answers but maybe these thoughts can whet your appetite on the problem (or discourage, who knows).
The first step to first class support in prometheus will be to figure out how to structure the data. The basic unit of the prometheus data model is, as I like to think about it, is a time series. A time series is a set of timestamp keys and floating point values. A time series is identified by a set of labels (and importantly a special _name label). The fact that these time series might be gauges or counters or rates is pretty abstracted from the storage layer. In practice this means the storage layer has two data structures, and index from sets of labels to timeseries ID and then a timeseries as a columnar representation of the (ts, val). It uses delta encoding etc to make the timeseries storage compact. Another very important (albeit somewhat sad) truth about the prometheus ecosystem is that you don't get event timestamps, only collection timestamps.
To make this more explicit, below find the representation of a histogram:
raft_process_applycommitted_latency_bucket{store="1",le="14847"} 1
raft_process_applycommitted_latency_bucket{store="1",le="18431"} 2
raft_process_applycommitted_latency_bucket{store="1",le="19455"} 4
raft_process_applycommitted_latency_bucket{store="1",le="21503"} 10
raft_process_applycommitted_latency_bucket{store="1",le="22527"} 16
raft_process_applycommitted_latency_bucket{store="1",le="23551"} 21
raft_process_applycommitted_latency_bucket{store="1",le="24575"} 25
raft_process_applycommitted_latency_bucket{store="1",le="25599"} 30
raft_process_applycommitted_latency_bucket{store="1",le="26623"} 35
raft_process_applycommitted_latency_bucket{store="1",le="27647"} 41
raft_process_applycommitted_latency_bucket{store="1",le="28671"} 48
raft_process_applycommitted_latency_bucket{store="1",le="29695"} 51
raft_process_applycommitted_latency_bucket{store="1",le="30719"} 55
raft_process_applycommitted_latency_bucket{store="1",le="31743"} 62
raft_process_applycommitted_latency_bucket{store="1",le="32767"} 70
raft_process_applycommitted_latency_bucket{store="1",le="34815"} 84
raft_process_applycommitted_latency_bucket{store="1",le="36863"} 99
raft_process_applycommitted_latency_bucket{store="1",le="38911"} 110
raft_process_applycommitted_latency_bucket{store="1",le="40959"} 120
raft_process_applycommitted_latency_bucket{store="1",le="43007"} 134
raft_process_applycommitted_latency_bucket{store="1",le="45055"} 144
raft_process_applycommitted_latency_bucket{store="1",le="47103"} 149
raft_process_applycommitted_latency_bucket{store="1",le="49151"} 153
raft_process_applycommitted_latency_bucket{store="1",le="51199"} 160
raft_process_applycommitted_latency_bucket{store="1",le="55295"} 166
raft_process_applycommitted_latency_bucket{store="1",le="57343"} 168
raft_process_applycommitted_latency_bucket{store="1",le="59391"} 172
raft_process_applycommitted_latency_bucket{store="1",le="61439"} 175
raft_process_applycommitted_latency_bucket{store="1",le="63487"} 180
raft_process_applycommitted_latency_bucket{store="1",le="65535"} 182
raft_process_applycommitted_latency_bucket{store="1",le="69631"} 185
raft_process_applycommitted_latency_bucket{store="1",le="73727"} 193
raft_process_applycommitted_latency_bucket{store="1",le="77823"} 199
raft_process_applycommitted_latency_bucket{store="1",le="81919"} 208
raft_process_applycommitted_latency_bucket{store="1",le="86015"} 217
raft_process_applycommitted_latency_bucket{store="1",le="90111"} 227
raft_process_applycommitted_latency_bucket{store="1",le="94207"} 232
raft_process_applycommitted_latency_bucket{store="1",le="98303"} 243
raft_process_applycommitted_latency_bucket{store="1",le="102399"} 248
raft_process_applycommitted_latency_bucket{store="1",le="106495"} 251
raft_process_applycommitted_latency_bucket{store="1",le="110591"} 254
raft_process_applycommitted_latency_bucket{store="1",le="114687"} 258
raft_process_applycommitted_latency_bucket{store="1",le="118783"} 261
raft_process_applycommitted_latency_bucket{store="1",le="122879"} 265
raft_process_applycommitted_latency_bucket{store="1",le="126975"} 267
raft_process_applycommitted_latency_bucket{store="1",le="139263"} 268
raft_process_applycommitted_latency_bucket{store="1",le="147455"} 272
raft_process_applycommitted_latency_bucket{store="1",le="155647"} 274
raft_process_applycommitted_latency_bucket{store="1",le="163839"} 276
raft_process_applycommitted_latency_bucket{store="1",le="180223"} 278
raft_process_applycommitted_latency_bucket{store="1",le="196607"} 281
raft_process_applycommitted_latency_bucket{store="1",le="524287"} 282
raft_process_applycommitted_latency_bucket{store="1",le="1.179647e+06"} 283
raft_process_applycommitted_latency_bucket{store="1",le="1.245183e+06"} 284
raft_process_applycommitted_latency_bucket{store="1",le="1.835007e+06"} 285
raft_process_applycommitted_latency_bucket{store="1",le="5.767167e+06"} 286
raft_process_applycommitted_latency_bucket{store="1",le="+Inf"} 286
raft_process_applycommitted_latency_sum{store="1"} 2.7738338e+07
raft_process_applycommitted_latency_count{store="1"} 286

It might be (is) the case that this histogram is configured for even larger buckets but because they have no values, they are omitted. These le values indicate the cumulative number of events (since process start) that have a value less than the bucket value. When fetching calculating what happened in some time interval, it grabs all of the buckets and then can do subtractions from the beginning to the end after accounting for counter restarts.
A significant barrier to the windowing approach is that prometheus has no mechanism to control retention per time series (https://github.com/prometheus/prometheus/issues/1381). This makes windowing schemes feel less tractable.
I want to explore windowing schemes more but haven't had much time. I started to think through them one day here: https://github.com/ajwerner/tdigest/blob/9165f388a6b2c88703b9630c9d15e59d2d212d7e/windowed/windowed.go#L12-L120

I don' have any answers but maybe these thoughts can whet your appetite on the problem (or discourage, who knows).
The first step to first class support in prometheus will be to figure out how to structure the data. The basic unit of the prometheus data model is, as I like to think about it, is a time series. A time series is a set of timestamp keys and floating point values. A time series is identified by a set of labels (and importantly a special _name label). The fact that these time series might be gauges or counters or rates is pretty abstracted from the storage layer. In practice this means the storage layer has two data structures, and index from sets of labels to timeseries ID and then a timeseries as a columnar representation of the (ts, val). It uses delta encoding etc to make the timeseries storage compact. Another very important (albeit somewhat sad) truth about the prometheus ecosystem is that you don't get event timestamps, only collection timestamps.
To make this more explicit, below find the representation of a histogram:
raft_process_applycommitted_latency_bucket{store="1",le="14847"} 1
raft_process_applycommitted_latency_bucket{store="1",le="18431"} 2
raft_process_applycommitted_latency_bucket{store="1",le="19455"} 4
raft_process_applycommitted_latency_bucket{store="1",le="21503"} 10
raft_process_applycommitted_latency_bucket{store="1",le="22527"} 16
raft_process_applycommitted_latency_bucket{store="1",le="23551"} 21
raft_process_applycommitted_latency_bucket{store="1",le="24575"} 25
raft_process_applycommitted_latency_bucket{store="1",le="25599"} 30
raft_process_applycommitted_latency_bucket{store="1",le="26623"} 35
raft_process_applycommitted_latency_bucket{store="1",le="27647"} 41
raft_process_applycommitted_latency_bucket{store="1",le="28671"} 48
raft_process_applycommitted_latency_bucket{store="1",le="29695"} 51
raft_process_applycommitted_latency_bucket{store="1",le="30719"} 55
raft_process_applycommitted_latency_bucket{store="1",le="31743"} 62
raft_process_applycommitted_latency_bucket{store="1",le="32767"} 70
raft_process_applycommitted_latency_bucket{store="1",le="34815"} 84
raft_process_applycommitted_latency_bucket{store="1",le="36863"} 99
raft_process_applycommitted_latency_bucket{store="1",le="38911"} 110
raft_process_applycommitted_latency_bucket{store="1",le="40959"} 120
raft_process_applycommitted_latency_bucket{store="1",le="43007"} 134
raft_process_applycommitted_latency_bucket{store="1",le="45055"} 144
raft_process_applycommitted_latency_bucket{store="1",le="47103"} 149
raft_process_applycommitted_latency_bucket{store="1",le="49151"} 153
raft_process_applycommitted_latency_bucket{store="1",le="51199"} 160
raft_process_applycommitted_latency_bucket{store="1",le="55295"} 166
raft_process_applycommitted_latency_bucket{store="1",le="57343"} 168
raft_process_applycommitted_latency_bucket{store="1",le="59391"} 172
raft_process_applycommitted_latency_bucket{store="1",le="61439"} 175
raft_process_applycommitted_latency_bucket{store="1",le="63487"} 180
raft_process_applycommitted_latency_bucket{store="1",le="65535"} 182
raft_process_applycommitted_latency_bucket{store="1",le="69631"} 185
raft_process_applycommitted_latency_bucket{store="1",le="73727"} 193
raft_process_applycommitted_latency_bucket{store="1",le="77823"} 199
raft_process_applycommitted_latency_bucket{store="1",le="81919"} 208
raft_process_applycommitted_latency_bucket{store="1",le="86015"} 217
raft_process_applycommitted_latency_bucket{store="1",le="90111"} 227
raft_process_applycommitted_latency_bucket{store="1",le="94207"} 232
raft_process_applycommitted_latency_bucket{store="1",le="98303"} 243
raft_process_applycommitted_latency_bucket{store="1",le="102399"} 248
raft_process_applycommitted_latency_bucket{store="1",le="106495"} 251
raft_process_applycommitted_latency_bucket{store="1",le="110591"} 254
raft_process_applycommitted_latency_bucket{store="1",le="114687"} 258
raft_process_applycommitted_latency_bucket{store="1",le="118783"} 261
raft_process_applycommitted_latency_bucket{store="1",le="122879"} 265
raft_process_applycommitted_latency_bucket{store="1",le="126975"} 267
raft_process_applycommitted_latency_bucket{store="1",le="139263"} 268
raft_process_applycommitted_latency_bucket{store="1",le="147455"} 272
raft_process_applycommitted_latency_bucket{store="1",le="155647"} 274
raft_process_applycommitted_latency_bucket{store="1",le="163839"} 276
raft_process_applycommitted_latency_bucket{store="1",le="180223"} 278
raft_process_applycommitted_latency_bucket{store="1",le="196607"} 281
raft_process_applycommitted_latency_bucket{store="1",le="524287"} 282
raft_process_applycommitted_latency_bucket{store="1",le="1.179647e+06"} 283
raft_process_applycommitted_latency_bucket{store="1",le="1.245183e+06"} 284
raft_process_applycommitted_latency_bucket{store="1",le="1.835007e+06"} 285
raft_process_applycommitted_latency_bucket{store="1",le="5.767167e+06"} 286
raft_process_applycommitted_latency_bucket{store="1",le="+Inf"} 286
raft_process_applycommitted_latency_sum{store="1"} 2.7738338e+07
raft_process_applycommitted_latency_count{store="1"} 286

It might be (is) the case that this histogram is configured for even larger buckets but because they have no values, they are omitted. These le values indicate the cumulative number of events (since process start) that have a value less than the bucket value. When fetching calculating what happened in some time interval, it grabs all of the buckets and then can do subtractions from the beginning to the end after accounting for counter restarts.
A significant barrier to the windowing approach is that prometheus has no mechanism to control retention per time series (https://github.com/prometheus/prometheus/issues/1381). This makes windowing schemes feel less tractable.
I want to explore windowing schemes more but haven't had much time. I started to think through them one day here: https://github.com/ajwerner/tdigest/blob/9165f388a6b2c88703b9630c9d15e59d2d212d7e/windowed/windowed.go#L12-L120

OK. That's interesting. Sad as well.
Things like Hdr histograms have constant bin boundaries so this idea of having a different time series for each bin (or for each cumulative sum) is easy to hack into a simple time series database. I have done the same sort of thing with Open TSDB and accumulated similar karmic debt.
The centroids in a t-digest wander around, however. That makes this much harder.
One possibility is to not use an additive measure if Prometheus allows that. does it?

OK. That's interesting. Sad as well.
Things like Hdr histograms have constant bin boundaries so this idea of having a different time series for each bin (or for each cumulative sum) is easy to hack into a simple time series database. I have done the same sort of thing with Open TSDB and accumulated similar karmic debt.
The centroids in a t-digest wander around, however. That makes this much harder.
One possibility is to not use an additive measure if Prometheus allows that. does it?

One possibility is to not use an additive measure if Prometheus allows that. does it?

There's nothing at all that bounds us to using an additive measure. That's an assumption of the data type encoding. One could imagine doing something like the below. That ends up being pretty good because it will mean highly compressed histograms will have mostly zero values. Sure the values in the low buckets won't compress well, but that seems fine. We aren't trying to do optimal storage here, just something that works. We can also leverage meta buckets to indicate things like start time and window sizes. I think the below encoding could get you a pretty long way. At query time you pull all of the buckets and merge where appropriate. It might be that there are multiple different readings corresponding to the same open window, that seems fine. At least, it seems fine if you could compact them away. In a more advanced time series database that allowed per series retention and compactions, then it really would be totally fine. Alas.
tdigest{bucket="1",type="count"} 1
tdigest{bucket="1",type="val"} 18431
tdigest{bucket="2",type="count"} 2
tdigest{bucket="2",type="val"} 22527
tdigest{type="start"} <timestamp>

One possibility is to not use an additive measure if Prometheus allows that. does it?

There's nothing at all that bounds us to using an additive measure. That's an assumption of the data type encoding. One could imagine doing something like the below. That ends up being pretty good because it will mean highly compressed histograms will have mostly zero values. Sure the values in the low buckets won't compress well, but that seems fine. We aren't trying to do optimal storage here, just something that works. We can also leverage meta buckets to indicate things like start time and window sizes. I think the below encoding could get you a pretty long way. At query time you pull all of the buckets and merge where appropriate. It might be that there are multiple different readings corresponding to the same open window, that seems fine. At least, it seems fine if you could compact them away. In a more advanced time series database that allowed per series retention and compactions, then it really would be totally fine. Alas.
tdigest{bucket="1",type="count"} 1
tdigest{bucket="1",type="val"} 18431
tdigest{bucket="2",type="count"} 2
tdigest{bucket="2",type="val"} 22527
tdigest{type="start"} <timestamp>

When I said that you don't get an event time I meant event time is collection time. At query time you do, of course, get a timestamp.

When I said that you don't get an event time I meant event time is collection time. At query time you do, of course, get a timestamp.

Things like Hdr histograms have constant bin boundaries so this idea of having a different time series for each bin (or for each cumulative sum) is easy to hack into a simple time series database. I have done the same sort of thing with Open TSDB and accumulated similar karmic debt.

That's true with a constant configuration. It's also sort of terrible. In the system I currently work on, we, a long time ago, hard-coded all of the buckets to end up having quite high precision in the nanoseconds and only second-level precision in the seconds. It was a bad choice for the system. We can never change it now. With the above proposed centroid count, one could change their compression factor and everything would adjust nicely.

Things like Hdr histograms have constant bin boundaries so this idea of having a different time series for each bin (or for each cumulative sum) is easy to hack into a simple time series database. I have done the same sort of thing with Open TSDB and accumulated similar karmic debt.

That's true with a constant configuration. It's also sort of terrible. In the system I currently work on, we, a long time ago, hard-coded all of the buckets to end up having quite high precision in the nanoseconds and only second-level precision in the seconds. It was a bad choice for the system. We can never change it now. With the above proposed centroid count, one could change their compression factor and everything would adjust nicely.

This proposed encoding looks totally usable.
On Mon, Jan 18, 2021 at 4:23 PM ajwerner<EMAIL_ADDRESS>wrote:

One possibility is to not use an additive measure if Prometheus allows
that. does it?
There's nothing at all that bounds us to using an additive measure. That's
an assumption of the data type encoding. One could imagine doing something
like the below. That ends up being pretty good because it will mean highly
compressed histograms will have mostly zero values. Sure the values in the
low buckets won't compress well, but that seems fine. We aren't trying to
do optimal storage here, just something that works. We can also leverage
meta buckets to indicate things like start time and window sizes. I think
the below encoding could get you a pretty long way. At query time you pull
all of the buckets and merge where appropriate. It might be that there are
multiple different readings corresponding to the same open window, that
seems fine. At least, it seems fine if you could compact them away. In a
more advanced time series database that allowed per series retention and
compactions, then it really would be totally fine. Alas.
tdigest{bucket="1",type="count"} 1
tdigest{bucket="1",type="val"} 18431
tdigest{bucket="2",type="count"} 2
tdigest{bucket="2",type="val"} 22527
tdigest{type="start"}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tdunning/t-digest/issues/127#issuecomment-762526778,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5E6UCFQP3FOOUK7YQAILS2TGIHANCNFSM4HLOD3VQ
.

This proposed encoding looks totally usable.
On Mon, Jan 18, 2021 at 4:23 PM ajwerner<EMAIL_ADDRESS>wrote:

One possibility is to not use an additive measure if Prometheus allows
that. does it?
There's nothing at all that bounds us to using an additive measure. That's
an assumption of the data type encoding. One could imagine doing something
like the below. That ends up being pretty good because it will mean highly
compressed histograms will have mostly zero values. Sure the values in the
low buckets won't compress well, but that seems fine. We aren't trying to
do optimal storage here, just something that works. We can also leverage
meta buckets to indicate things like start time and window sizes. I think
the below encoding could get you a pretty long way. At query time you pull
all of the buckets and merge where appropriate. It might be that there are
multiple different readings corresponding to the same open window, that
seems fine. At least, it seems fine if you could compact them away. In a
more advanced time series database that allowed per series retention and
compactions, then it really would be totally fine. Alas.
tdigest{bucket="1",type="count"} 1
tdigest{bucket="1",type="val"} 18431
tdigest{bucket="2",type="count"} 2
tdigest{bucket="2",type="val"} 22527
tdigest{type="start"}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tdunning/t-digest/issues/127#issuecomment-762526778,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5E6UCFQP3FOOUK7YQAILS2TGIHANCNFSM4HLOD3VQ
.


Fix Trezor signing

Currently fails due to changes introduced in latest firmware

For future reference fields extra_data, branch_id and version_group_id are mandatory in refTxs obj from now on. If one of them is not present it will result in errors. See https://github.com/trezor/connect/issues/594 for more detailed example.

Currently SC signing is randomly failing. Needs further debugging.


chore(package): update npm-pkgbuild to version 6.10.6

Coverage remained the same at 36.377% when pulling 8c3402996faed883ad50876b7a4fd94cea47ad53 on greenkeeper/npm-pkgbuild-6.10.6 into c88446f22016443cd48dca1dc1588dc5c1581292 on master.


Bravo!

Provide a description of requested docs changes
Great job on providing mini-tutorials that show exactly what a feature does. (e.g. showing how to use Color Picker). Saves the user time spent on his or her own experimentation or exploration.  Also encourages usage of the feature.

Thanks!!!


Update CountingSort.java

Thanks for the ideas but there are a few issues with your changes. I’ll clean them up later.