Integration testing requirements

On today's Pangeo ML WG call, @nbren12 re-raised the perennial issue of the need for integration testing of the many layers of our stack, particularly when it comes to cloud i/o.
This has been discussed in many different related issues:

https://github.com/pydata/xarray/issues/3831#issuecomment-595747237
https://github.com/pydata/xarray/issues/4648
https://github.com/zarr-developers/zarr-python/issues/528
https://github.com/zarr-developers/zarr_implementations
https://github.com/pangeo-data/rechunker/issues/86
etc.

The feeling from heavy users is that there are still lingering intermittent bugs related to cloud i/o that render workflows unstable. One way to the bottom of this is to get more rigorous about system-wide integration testing.
Some questions we need to resolve to move forward with this idea, and my initial responses, are:

What are the workflows we want to test?

Write random data to cloud
Read back data
Copy data
Rechunk data

How big does the test need to be in order to be realistic?

My sense: > 100 GB

Which combinations of libraries do we want to include?

dask (w/o xarray)
xarray (via dask)
gcsfs
s3fs
adlfs
rechunker

How do we orchestrate an integration test like this? Here is one idea

Build dedicated docker containers with the desired environments using GitHub workflows
Connect to dask clusters from GitHub workflows (maybe could use Coiled to make this easy; otherwise will need dedicated dask_kubernetes or dask_gateway set up for the purpose)
Launch integration tests on remote dask clusters from github workflows

If we can agree on a clearly scoped plan, I think we can support the cloud computing costs. We can also considering asking Anaconda (@martindurant) to spend some time on this via our Pangeo Forge contract with them.
cc @jhamman @cisaacstern @tomnicholas @dcherian

Thanks for getting the ball rolling on this @rabernat! I think the tests you propose would reveal the main issues that have challenged us and make sure these issues don't creep back into the codebase once they are fixed. At least on the gcsfs side, I get the impression that a lot of people have been challenged by intermittent I/O issues: dask/gcsfs#327, dask/gcsfs#323, dask/gcsfs#315, dask/gcsfs#316, dask/gcsfs#290
Beyond just reliability and catching bugs, would be cool if these tests were also leveraged to monitor performance.

If our NASA proposal gets funded, we were planning to put some time towards something like this.

@scottyhq and @dcherian - when do you expect to know about the NASA proposal? My understanding is that the scope is a lot broader than just cloud i/o. Would it be a problem if we bootstrapped something on a shorter timescale and then handed it off if / when your proposal is funded?

Another simple way to get some coverage is to install a fixed set of libraries and run their test suites. This will often find errors related to API changes. This is the usual process of preparing a "distribution" like nix or Debian. FYI, I have been working on packaging some of the pangeo stack with the nix package manager. Here's a package I added for gcsfs package. Therefore, there is some level of integration testing being done by their CI servers against specific versions of dask/xarray etc: https://hydra.nixos.org/build/142494940.

when do you expect to know about the NASA proposal?

:man_shrugging:

My understanding is that the scope is a lot broader than just cloud i/o.

Yeah I think so.

Would it be a problem if we bootstrapped something on a shorter timescale and then handed it off if / when your proposal is funded?

Of course! I don't see an issue at all.

when do you expect to know about the NASA proposal?

Our proposal has a start date of 6/30/2021 to give you a ballpark timeline. If funded I'd definitely be interested in collaborating on this. I don't know how many issues are specific to gcsfs, but NASA is still pretty focused on AWS, so we'd want to use s3 storage as well.

How about we run a github self-hosted runner on a Kubernetes cluster that also has dask gateway configured? That way, we get all the goodness of GitHub actions without having to deal with nasty auth stuff.

A couple of notes:

for gcsfs, recent improvements should have helped things in the version currently waiting on conda-forge. Of course, full-scale testing would still be useful. This would require a real bucket on GCS and payment
for s3fs, there is already a proposal to add minio as an additional test runner to moto, which would certainly find some edge cases, particularly for non-AWS S3s. Testing against real S3 would, again, require money.
to my mind, designing xarray+dask+storage tests amounts to running some specialised recipes that fill much of the parameter space in (number of chunks, size of chunks, number of files, number of threads/processes

Thanks for the input Martin. The plan is to indeed spend real money to test the whole stack at scale on real cloud providers.


CFE_SB_SetMsgTime sets CCSDS_TlmSecHdr_t Time field in native endianness

Is your feature request related to a problem? Please describe.
CFE_SB_SetMsgTime populates the CCSDS_TlmSecHdr_t Time field with native endianness format instead of using macros.
ccsds.h definition of the time headers are network byte order.
Describe the solution you'd like
Define actual standard, confirm across stakeholders and fix.
Describe alternatives you've considered
None
Additional context
None
Requester Info
Jacob Hageman - NASA/GSFC

Also an issue in GetMsgTime.

Really the Time field isn't CCSDS, this whole scheme needs better abstraction and careful refactor.

Duplicate of #92


About the switch between stubborn and peanut

Hi, I see there is implementation for switching between corner goal and prediction goal, but seems that the switch step is set to 0.
Does peanut just rely on the prediction model for deciding the long-term goal at a frequency?
Thanks for your interesting and inspiring work!

That's right, it always uses the prediction. We thought that it might be interesting to switch between the two policies, but we found it doesn't really help. Maybe it is worth exploring further though!

Thanks for the reply.
I have one more question, I run the evaluation and find that the evaluation can stop at a certain step (< 500 steps) for some unsuccessful episodes. How do you implement it?

Hmm it should not stop. Can you show the error message?

Oh that's a normal failure case, it will happen if there is a false positive detection and the agent calls "stop" as it thinks it reached the target.

Yeah, I see.
And for the prediction model, seems the map size for training is 960 * 960, but during inference, the map size is 720*720.
Am I right?
Moreover, I find that only the target prediction inside the local map is used for update the global goal. Is it reasonable to train the prediction model only  with the local maps?
Thanks for your patience.

Currently it is set that way, but maybe that is actually a mistake -- if you try 960 during inference, let me know what happens!
It is better to predict using global map than only using local map. See the ablation study in our paper for comparison

I thought the performance might not be significantly impacted. But actually,  a 1% decrease in success rate on the validation set when using the map size 960, which is perplexing to me.

I believe only very few episodes need the agent to go outside of the 720 size map, so there is not much benefit to predicting out there. And then the new predictions causes some slightly different behavior sometimes which leads to 1% decrease in success (not really significant).


Is this library support React-Native?

Hi,
I wonder if this library support react-native 0.4, if it is, where can I get the examples? thanks a lot :)

it uses the normal react API, so yes.


Intro/Outro video content for Zarf Doom Deployment video

Outcome: We want to produce a high-quality/professional intro and outro that bookend the Doom deployment YouTube tutorial video. Basic premise is "Hi, I'm Mallory Grim with Defense Unicorns. Welcome to our Zarf Tutorial video series. In this video we are going to use Zarf to deploy the hit 1993 game Doom to a 'bring your own' Kubernetes cluster"
Background: We want to try to maximize reusability by having the content that won't change be separate from the content that will change as changes are made to the Zarf product. If everything were all one video it would all need to be reshot whenever a user-facing change is made to Zarf in order to keep it up to date.
Acceptance Criteria:

@mgrim2 / @edengebrezgi to fill in more details

Notes:

We like this video by Confluent as an example of kinda like what "feel" we are looking for
Target finish date: January 18

Have the links to the recorded intro/outro. Would like feedback/review from @Madeline-UX and @RothAndrew
https://drive.google.com/drive/folders/1HbLjCsvh0rxrUAKlDXmUozOTTK_ODztk?usp=sharing

Looking at this now


examples

Not working in chrome
http://codepen.io/tofanelli/pen/WxKEgP

It was not working because the address of the JS and CSS wasn't correct. But already copied to the server, try now.


BUG: error in calculation of p-values in sp.stats.wilcoxon when there are ties in ranked differences

Describe your issue.
P-values for one-sided wilcoxon signed-rank tests are inconsistent depending on the ordering of the input for the same test in cases where there are ties in the ranked differences.
Specifically, testing for A>B and B<A should, in theory, give the same p-value for the one-sided tests, but do not give the same p-value in instances where there are ties in the ranked differences and the average rank is assigned (a decimal value).
This problem arises when calculating the 'exact' p-value as the null distribution for a given N is coded as an array requiring integer slicing to get the appropriate p-value. This results in A>B and B<A not actually being the same, despite being the same.
Reproducing Code Example
var1 = [62, 66, 61, 68, 74, 62, 68, 62, 55, 59]
var2 = [71, 71, 69, 61, 75, 71, 77, 72, 62, 65]
print(stats.wilcoxon(var1, var2, alternative = 'less'))
print(stats.wilcoxon(var2, var1, alternative = 'greater'))

Error message
n/a

SciPy/NumPy/Python version and system information
1.11.1 1.24.3 sys.version_info(major=3, minor=11, micro=5, releaselevel='final', serial=0)
Build Dependencies:
  blas:
    detection method: pkgconfig
    found: true
    include directory: /Users/sammichekroud/anaconda3/include
    lib directory: /Users/sammichekroud/anaconda3/lib
    name: openblas
    openblas configuration: USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS=
      NO_LAPACK=0 NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP=0 VORTEX MAX_THREADS=128
    pc file directory: /Users/sammichekroud/anaconda3/lib/pkgconfig
    version: 0.3.21
  lapack:
    detection method: pkgconfig
    found: true
    include directory: /Users/sammichekroud/anaconda3/include
    lib directory: /Users/sammichekroud/anaconda3/lib
    name: openblas
    openblas configuration: USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS=
      NO_LAPACK=0 NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP=0 VORTEX MAX_THREADS=128
    pc file directory: /Users/sammichekroud/anaconda3/lib/pkgconfig
    version: 0.3.21
  pybind11:
    detection method: pkgconfig
    include directory: /Users/sammichekroud/anaconda3/include
    name: pybind11
    version: 2.10.4
Compilers:
  c:
    commands: arm64-apple-darwin20.0.0-clang
    linker: ld64
    name: clang
    version: 12.0.0
  c++:
    commands: arm64-apple-darwin20.0.0-clang++
    linker: ld64
    name: clang
    version: 12.0.0
  cython:
    commands: cython
    linker: cython
    name: cython
    version: 0.29.36
  fortran:
    commands: /var/folders/nz/j6p8yfhx1mv_0grj5xl4650h0000gp/T/abs_66h0hq6x34/croot/scipy_1691606685645/_build_env/bin/arm64-apple-darwin20.0.0-gfortran
    linker: ld64
    name: gcc
    version: 11.2.0
  pythran:
    include directory: ../../../../../../../../../../../Users/sammichekroud/anaconda3/lib/python3.11/site-packages/pythran
    version: 0.13.1
Machine Information:
  build:
    cpu: aarch64
    endian: little
    family: aarch64
    system: darwin
  cross-compiled: false
  host:
    cpu: aarch64
    endian: little
    family: aarch64
    system: darwin
Python Information:
  path: /Users/sammichekroud/anaconda3/bin/python
  version: '3.11'

This problem arises when calculating the 'exact' p-value as the null distribution for a given N is coded as an array requiring integer slicing to get the appropriate p-value.

Specifically:
https://github.com/scipy/scipy/blob/5e4a5e3785f79dd4e8930eed883da89958860db2/scipy/stats/_morestats.py#L4166
and
https://github.com/scipy/scipy/blob/5e4a5e3785f79dd4e8930eed883da89958860db2/scipy/stats/_morestats.py#L4175-L4176
r_plus should not be rounded down before this calculation if it is legitimately greater than int(r_plus). Well, it's tough to say what should happen, since the null distribution pmf is calculated under the assumption that there are no ties. So the other way to look at this is that this alternative is calculated correctly, conservatively including the probability mass at int(r_plus) since the assumption is violated, and the other alternative should include the extra probability mass in its calculation. But in any case, adjusting the rounding procedure for one of the alternatives is the way to fix this.
There is a rewrite of wilcoxon in gh-19770 which can incorporate this.

yep, i also noticed that this is an issue of rounding by coercing to integer, but it makes two tests that are equivalent, non-equivalent - happening (at least in my case) because both R+ and R- are being rounded down. For true equivalences of the tests, int(rplus) + int(rminus) = max_rank should be forced to be true.
An alternative solution would be to allow individual control of the ranking method used - at the moment, r = _stats_py.rankdata(abs(d)) doesn't allow any control over how ties are handled (it just uses the 'average' default in rankdata. Being able to specify the method with which ties are handled would get over this too as the issue arises when the test statistic is not an integer


:?;:/:?:

Hello! It looks like this PR was opened by mistake. If that's not the case, please update the PR description to give more context and reopen it. In the meantime I am going to close this PR. Thanks!


New scRNAseq kits

Select the target metadata schema name (can be multiple), or choose 'Other' if not listed.
Other
If 'Other' is selected, please enter the schema name below.
scRNAseq
Describe the change request (use a numbered list if many).
New library_preparation_kits

Chromium Next GEM Automated Single Cell 5' Kit v2, 24 rxns PN-1000290
Chromium Next GEM Automated Single Cell 5' Kit v2, 4 rxns PN-1000298
Chromium Next GEM Single Cell 5' Kit v2, 16 rxns PN-1000263

New sample_indexing_kit

Dual Index Kit TT Set A, 96 rxns PN-1000215

New preparation_instrument_kits

Chromium Next GEM Chip K Single Cell Kit, 48 rxns PN-1000286
Chromium Next GEM Chip K Single Cell Kit, 16 rxns PN-1000287

The next-gen schemas don't have scRNAseq type and the option for RNAseq is either RNAseq (with probes) or RNAseq. Which one is it for this ticket?

No probes!

Official names:
library_preparation_kits

10X Genomics; Chromium Next GEM Automated Single Cell 5' Kit v2, 24 rxns; PN 1000290
10X Genomics; Chromium Next GEM Automated Single Cell 5' Kit v2, 4 rxns; PN 1000298
10X Genomics; Chromium Next GEM Single Cell 5' Kit v2, 16 rxns; PN 1000263

sample_indexing_kit

10X Genomics; Dual Index Kit TT, Set A (96 rxn); PN 1000215

preparation_instrument_kits

10X Genomics; Chromium Next GEM Chip K Single Cell Kit, 48 rxns; PN 1000286
10X Genomics; Chromium Next GEM Chip K Single Cell Kit, 16 rxns; PN 1000287


fix e2e test

Fixed problem with e2e test crashing

I checked the resources for this issue and everything seemed fine.
Also, one of the multiple requests thrown by metric left a failure log, so there is still a possibility that e2e parallelization or something else is involved, causing the network to disconnect.


feat: parameterize proof generation and verification

Divide ProofGen and ProofVerify to the Initialization, Challenge Calculation and Finalization phases.
This is done by introducing 3 operations; ProofInit, ProofFinalize and  ProofVerifyInit, that handle the computations that were previously part of ProofGen and ProofVerify.
This is to allow for extensions of BBS, like predicate proofs, combining 2 BBS proofs, combining BBS proofs with other Pedersen-style commitments and much more, without requiring them to re-define the entire operations from scratch.

Advantages: Not a breaking change.
Disadvantages:  More operations/ larger document.

I think this is a useful set of changes, and that is how implementations have been written previously in order to allow for proof combinations. The additional complexity, especially with separating out the core operations does me a little nervous about getting the draft adopted though.

Discussed on the WG call at 25th of Sep. Merging.


[BUG] Grid tool is not working properly on hex grid in v1.3.3

Module Version: v1.3.3.
Describe the bug
The Grid tool is no longer snapping to the actual grid, instead it is completely misaligned. The Grid tool was working fine before I upgrade Foundry. It seems the tool is not taking into account the actual grid type and size configured for the scene. The other tools work fine.
There are no errors in the console.
To Reproduce
Steps to reproduce the behavior:

Go to enable hex grid
Click on Grid Tool
Attempt to reveal a hex
Snapping is incorrect (fog reveals fine though)

Expected behavior
To properly snap to the actual grid used in the scene.
Screenshots
I have colored the grid red and put measurement controls that properly snap to grid (default foundry). In addition, the grid settings for the map.

Browser:

Firefox latest 130.0.1
MS Edge 130

Foundry Version:

v12.331

Game System:
Forbidden Lands v12.1.0
Additional context
No module that interacts with the grid are loaded, I also tried on clean world with just this module enabled.

I have run into exactly this same issue.

I can't reproduce this issue. I've created a new world on the Forbidden Lands system and it works as expected.
Could you try creating a new world and test the module there?

Yes, when I create new world, import the core module the reveal is misaligned:

Would you like to send you the world for review?

Same issue here,  the fog revealing is not aligned with the grid. I'm using the same world as @r-valyar. That is forbidden land. If you want to try @mclemente you can just download the free module for forbidden land and create a new world using that module.


Migration of Attachments doesn't work for VSTS

During my migration-project from VSTS->VSTS, I faced the problem, that attachments are not migrated succesfully. I enabled the "Attachment-Processors" and according to my understanding of the log file, all attachments have been detected and moved correctly. Unfourtunateley in the target-projects all attachments have 14KByte and are unreadable. This happened with all files, independ from the file format.
I added the configuration for my productive-migration and a log from a test-migration. Please let me know, if I should provide more information.
Config.json.txt
example.log.txt

I have not seen this before and have done many migrations of attachments to VSTS. Recently I have seen 0kb as the size but the file is fine...

I have just migrated TFS(local)->VSTS without this attachment problem. I have migrated txt, doc and pdf files.
Maybe you can check out the export folder in the tool, to see if the problem is in export step or in the import step

Hello, i'm testing this tool and also have detected this issue after migrating from VSTS to another VSTS.
The problem is related with the Export Migrator, after setting up the config file with the AttachementExportMigratorConfig enabled, the downloaded file is corrupted and after debugging i think that the problem is related with the code line  webClient.DownloadFile(wia.Uri, fpath);  No exception is detected but this is not working.


choose a license

We need to choose a license and add a License.md file.
http://choosealicense.com/
The code already is published in the EnEff-BIM project under the MIT license, so we should probably use the same license here.

closed by 559694b4791a595308b0040004d9b19b78ad57d0


Use type keywords

This makes Mirror code consistent and compiles with .net conventions

this is why I hate C#'s 'let's add another option that does exactly the same' decisions.
@MichalPetryka can you fix conflicts please? then I will merge. reason being that we can't have those discussions. we need to do one way everywhere. and since we won't change all 'int's to 'Int32' everywhere in Mirror, we need to use 'int' here like your PR suggests.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


chore: set np dependency as devDependency

So depending on react-native-update-apk no longer inject
np's dependencies and font assets (not sure this commit
will fix the root cause of the issue, could simply have
happened from rerunning yarn, albeit unlikely).
--
@mikehardy so much package of yours I happen to depend on! Big thanks.

Sorry for the delay @nuKs I was traveling and had an "apple signin + react-native-firebase" emergency :-). I just released this as 4.2.1 and then released 4.3.0 on top of that with a tiny feature, if you want to move back to mainline. Thanks again for the contribution - I actually noticed it in my work project as a warning on yarn install and thought "why the heck is np coming in here?" and realized I hadn't released it yet :sweat_smile:

@mikehardy
Hehe, that's all good. Thanks for taking care!
 Open Source, man :-). Cheers!


pre_gen hook doesn't appear to be loading custom extensions

Latest version of cookiecutter from master. Last commit ceafa1dc1b5eb70835ffba5dc7457df269d77ba8
In my pre_gen_project hook, I have this code: {{cookiecutter.should_be_list | to_sequence}} which turns a string into a list but cookiecutter raises a TemplateAssertionError jinja2.exceptions.TemplateAssertionError: no filter named 'to_sequence'. I know that my to_sequence filter isn't the issue because when I use it in other parts of my template and remove it from the pre_gen hook, everything executes successfully.
Are the custom extensions intended to only be loaded after the pre_gen hook is finished executing?

Hi @cheungnj,
Thanks for the issue!
This looks like an oversight, we should be using the same Jinja environment to render hooks as we do elsewhere.
This looks like a relatively easy fix to implement- would you like to submit a PR?
Essentially, we should be using cookiecutter.environment.StrictEnvironment instead of just jinja2.Template in cookiecutter.hooks.run_script_with_context.

Hey @cheungnj! 👋
I've just pushed a PR adding two tests that replicate this bug. As @michaeljoseph said, we would happily review a PR from you to address this issue, feel free to base your branch off of #856.
Please let us know in case of any questions!

@michaeljoseph @hackebrot
I'd be happy to submit a PR for this. Thanks for the opportunity to contribute!

Hey @cheungnj! 👋
FYI The tests have been merged into master!


Indirect addressing mode needs to return entire page when lo(0xFF)

Following the 6502 spec, there is a bug in architecture when indirect addressing mode is used.
Not sure if this thing affects all the indirect addressing like indirect, x and indirect, y but probably yes.
We need to check if the lo(ADDRESS) is 0xFF and, then, consider a full page return, so:
LDX #$02
STX $3000

LDX #$04
STX $3100

LDX #$03
STX $30FF

JMP ($30FF)

the jump will consider the hi(0x3000) + lo(0x30FF) = 0x0203
NB: WE CAN'T USE EASY6502 TO VALIDATE THIS BECAUSE THEY ARE NOT RESPECTING THIS BEHAVIOUR AS WE CAN SEE IN THE PICTURE:

So, if I understood correctly, to simulate this bug we need to do something like this In the indirect function?
If address & 0x00FF = 0xFF

Then:
Address & 0xFF00 = hi
Address = lo

Else:
Address + 1 = hi
Address = lo


[Feature] ambiguous error messgae when creating target in VelaUX

Is your feature request related to a problem? Please describe.

[Feature] The api error message should tell exactly what went wrong, rather than having no idea what went wrong

Describe the solution you'd like

Describe alternatives you've considered

Additional context

@QianChenglong Your cluster name includes ".", this is invalid.

@QianChenglong Your cluster name includes ".", this is invalid. Advice renames the cluster.

Join by vela cli is ok.Maybe the validation is missing here.

Error messages should be user-friendly, clearly stating what went wrong and what the correct rules are.

ui can't rename the name.


Support of this library

Hi @terrillo ,
This library has many pull requests in pending status but there is no review.
Can you please give the project to the community and add contributors.
Very interesting things are done by other contributors but code is not merged.
Kind regards.

Hey @younss, made couple of releases. https://github.com/terrillo/rn-apple-healthkit/releases
Also working on a new 1.0v branch to fix some core issues. https://github.com/terrillo/rn-apple-healthkit/issues/120
If you interested in becoming a contributor. Send me an email.
Thanks


Refactor service package

Service relies heavily on sync.Mutex and sync.RWMutex now. There are almost certainly deadlock possibility. We should make subscription service non-blocking.

Fixed with #3.


Add more vendored deps required for dep-collector 🤣

In #290 I tried to fix the logic that automatically installs
dep-collector when it is not present on your system, but it looks like
I missed at least one dependency.
I think it is deeply ironic that we have to manually collect and add the
dependencies for a tool called dep-collector which is supposed to be
make it easy to managed deps 🤣
^^ Or am I doing something wrong?????

@bobcatfish  although the name might imply it, dep-collector is not a go dependency management tool. Anyway, in order to avoid this dependency hell I think we should follow Matt's advice in https://github.com/knative/build/pull/487#issuecomment-443476057 about adding it to the required list of tools instead.

I'm still a bit confused about this @adrcunha , added a comment to https://github.com/knative/build/pull/487#issuecomment-443833317
Happy to remove these manually added dependencies if we can!


internal state weirdness

Had some weirdness pop up in the logs overnight.
Version: github.com/sijms/go-ora/v2 v2.7.6
runtime error: integer divide by zero triggered at github.com/sijms/go-ora/v2.(*DataSet).Next:325
Also a bunch of scan errors missing destination name SOME_COLUMN in *SomeType, but looking at the query where the error was thrown, SOME_COLUMN was not present in the query at all. This happened a whole bunch of times in different places for different columns. It seemed like queries being run in one goroutine were having the results returned to a different goroutine that was executing a different query concurrently perhaps?
Finally we had this error a bunch as well TTC error: received code 16 during response reading (as this wasn't a panic we don't have stack trace information of where it was thrown inside go-ora driver, but it was a returned err from the sql package during a query).
Until now, go-ora has been pretty stable so I'm not sure what triggered this all of a sudden. After 25 minutes of weirdness in the logs it seemed to fix itself (we have a maximum connection lifetime specified in the database/sql package, so I wonder if once those connections were aged out the issue fixed itself). There were some ORA-01013: user requested cancel of current operation appearing in the logs as well which isn't too surprising (if a client goes away the context will get cancelled by the http server) but perhaps this was the trigger that caused the internal state to get unhappy in the first place?

On closer inspection, we were running go-ora v2.6.1 until only a few days ago, so it's possible this is a regression between v2.6.1 and v2.7.6 which would explain why we haven't run into it before.

Same Here. Went back to 2.6.17.

I will add some fix in v2.7.8 that will stop divide by zero panic

so no fix for "ORA-01013: user requested cancel of current operation"? this occurs randomly with 2.7.6 on long running queries (1 minute for example) without canceling the ctx.

I also moved back to version v2.6.17.
Version 2.7.7 gives on frequent base the "ORA-01013: user requested cancel of current operation" error.
With v2.6.17 the bulk/stream loading is stable, loading 7.7 million records into a 4 node Oracle ExaCC production cluster.

I was hit by the "ORA-01013: user requested cancel of current operation" error too . I found this workaround which allows me to stick with 2.7.7. I just append the Offset/Fetch next statements at the end with a value of 100 000 (one hundred thousand), but in my case I am sure that I always get less then 10 000 (ten thousand) resulting rows.  If this applies the workaround should be applicable:
 OFFSET          0 ROWS
FETCH NEXT 100000 ROWS ONLY --make sure you get less than 100 000 rows

default global timeout is 30 seconds so increase the value will give more time for longer query
urlOptions := map[string]string {
    "TIMEOUT": "120",  //  2 minutes
}
databaseURL := go_ora.BuildUrl(server, port, service, username, password, urlOptions)

you can disable global timeout option by set its value to 0


[CI] Reënable iOS and tvOS tests

Although the test suites have a handful of failing tests, the jobs themselves do not fail.
Let's get these tests back into the fold so that we may track our progress getting these back to a good state.
cc @dlowder-salesforce
Test Plan
Run tests on Circle, and confirm everything is green: https://circleci.com/workflow-run/4dd1a84b-502d-4ad6-aa41-64c768392a6b
If you go into the test iOS and test tvOS jobs, you will see that we are collecting test results at the top. These results show the failing individual tests.

Looks like the tests are failing again -- hold on on merging.

The latest run, https://circleci.com/workflow-run/48d55d11-1666-4a5c-a070-c4837c8883bd, is all green.

@facebook-github-bot shipit


Let station builder check if block is breakable when building

So I have some techguns ore clusters generated in the world that is unbreakable, but the station builder is able to remove them from the world.
Could you check the materials before building?

Is this still a issue? Please comment if it is and i will reopen if if you are unable? We are closing old issues to see what is still relevant and needs to be fixed.

:thinking:


[vcpkg toolchain] Add help information after find port failed

We have received multiple feedbacks about the failure of using find_package, maybe we can fuzzy find the required port:triplet after the cmake configuration fails to return help information.

No stale


角色管理模块权限功能

Bug Report or Feature Request (mark with an x)

[ ] Bug report -> please search issues before submitting
[X] Feature request
[ ] Documentation issue or request

What is expected?

点击权限按钮， 弹出授权页面，进行权限点选择性授权，点击保存后完成授权过程
What is actually happening?

References

done .


Expose pool size & idle connections number

This is useful for monitoring.

I merged @jyn514's. But thank you for the contribution. Sorry for the delay.


fix(legacy): add missing legacy urls

Fix #118

Merged via https://github.com/mix-it/mixit/commit/f410045f64fbbdb49f083344791def42ad655a26 thanks.


Error in log every time I hit a redirect

This is in a clean instance of Sitecore 8.1 U1 with URL Rewrite 1.8 installed. I copied the sample set into my home directory, then set the website dropdown to my website. I then tried to hit "external1" from the simple redirect, but every time, I get the error below. Locally, it's also like everything just stopped working, so I'm trying to figure out why this might be. Thanks.
7204 21:00:20 ERROR UrlRewrite[web]::Exception occured
Exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
Source: Hi.UrlRewrite
at Hi.UrlRewrite.Processing.RewriteHelper.ReplaceBackReferences(Match match, String input, String backReferenceVariable) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\RewriteHelper.cs:line 30
at Hi.UrlRewrite.Processing.RewriteHelper.ReplaceConditionBackReferences(Match conditionMatch, String input) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\RewriteHelper.cs:line 19
at Hi.UrlRewrite.Processing.InboundRewriter.ProcessRedirectAction(InboundRule inboundRule, Uri uri, Match inboundRuleMatch, Match lastConditionMatch, InboundRuleResult ruleResult) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriter.cs:line 417
at Hi.UrlRewrite.Processing.InboundRewriter.ProcessRegularExpressionInboundRule(Uri originalUri, InboundRule inboundRule) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriter.cs:line 270
at Hi.UrlRewrite.Processing.InboundRewriter.ProcessInboundRule(Uri originalUri, InboundRule inboundRule) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriter.cs:line 204
at Hi.UrlRewrite.Processing.InboundRewriter.ProcessRequestUrl(Uri requestUri, List`1 inboundRules) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriter.cs:line 59
at Hi.UrlRewrite.Processing.InboundRewriteProcessor.ProcessUri(Uri requestUri, Database db, InboundRewriter urlRewriter) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriteProcessor.cs:line 76
at Hi.UrlRewrite.Processing.InboundRewriteProcessor.Process(HttpRequestArgs args) in c:\git\UrlRewrite\Hi.UrlRewrite\Processing\InboundRewriteProcessor.cs:line 36

Looks like it was because I hadn't published everything to web, actually. I'm going to reinstall my local Sitecore to see if that solves things on that side. Thanks.


bedtools intersect -sorted in chrome vs firefox

It's not behaving the same way in each browser with sorted files. firefox works whereas chrome errors out with:
chr13	70139383	70139429
Error: Sorted input specified, but the file a.bed has the following out of order record
chr14	92071009	92071010

I'm using the attached file as -a and https://bedqc.s3.amazonaws.com/hg38_ensembl_gene_intron.bed.gz as -b
bedtools intersect -sorted -u -a <file> -b <file>

test_file.bed.gz

Hey Joe,
That's odd, I seem to get the same output in both Firefox 95 and Chrome 96, and with no errors. Which version of Chrome are you seeing this issue with?
This is the script I tried:
<input id="myfile" type="file" multiple>

<script src="https://cdn.biowasm.com/v2/aioli/latest/aioli.js"></script>
<script type="module">
const CLI = await new Aioli("bedtools/2.29.2", { printInterleaved: false});
const output = await CLI.exec("bedtools --version");
console.log(`Loaded ${output.stdout}`);

async function run(event) {
    // Mount files
    const files = event.target.files;
    const paths = await CLI.mount(files);
    console.log("ls:", await CLI.ls("."), paths);

    // Run bedtools
    const output = await CLI.exec("bedtools intersect -sorted -u -a test_file.bed.gz -b hg38_ensembl_gene_intron.bed.gz");
    console.log(output.stdout);  // chr1	57367043	57367044....
    console.warn(output.stderr);  // empty
}

document.getElementById("myfile").addEventListener("change", run, false);
</script>

Oddities in Array.sort() between Firefox and Chrome were the culprit here. Sorry to have bothered, but thought I tried everything earlier to create the same toy page. Solved on my end and thanks for your time.
https://quinlan-lab.github.io/bedqc/

https://quinlan-lab.github.io/bedqc/

Looks awesome!


Interceptors cannot be shared between different sessions

Related to https://github.com/pion/webrtc/issues/1749

Fixed with fd0ded94670dacb67c583023b2c6ad073880a0fa
We now use a factory pattern. State can be re-used inside the factories if needed.


Loosen up depends on yum cookbook

Description
Loosen up depends on yum cookbook
Issues Resolved
Allows yum 4.x to be used as well
Check List

[x] All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
[ ] New functionality includes testing.
[ ] New functionality has been documented in the README if applicable
[x] All commits have been signed for the Developer Certificate of Origin. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

Travis failures are unrelated and are cookstyle linting issues


refactor: implement capacity functionality in ct_basic_string

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.528%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
9900

Relevant Lines:
1874258

💛  - Coveralls

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.01 :tada:

Comparison is base (4b8d4d0) 98.64% compared to head (ac4ee6f) 98.65%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #19      +/-   ##
==========================================
+ Coverage   98.64%   98.65%   +0.01%
==========================================
  Files          33       33
  Lines        2801     2822      +21
==========================================
+ Hits         2763     2784      +21
  Misses         38       38

Impacted Files
Coverage Δ

include/emio/detail/basic_string.hpp
100.00% <100.00%> (ø)

test/unit_test/detail/test_ct_basic_string.cpp
100.00% <100.00%> (ø)

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 in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Performance Comparison between Tape and Caliper

My Config
Fabric version: v2.2 (I am using 22393b this commit as in caliper v0.4.2 tutorial)
Caliper Version: v0.4.2
Tape Version: v0.1.2
CPU: i5-7300HQ
Memory: 16 GB

Note: I also read Christoper's post on performance and scale, I think my settings are similar to the first one on the post (2 peers, 1 orderer, 4vCPU with SSDs) but I am not able to reach the similar tps neither.
Describe the bug

I read a lot of comments that tape reaches higher TPS than caliper under the same config, but I am not able to achieve the same, so I am wondering if it was caused by my config or some internal issues. The results didn't change even I increased the num_of_conn & client_per_conn to 20 as suggested by the maintainer @SamYuan1990
The only difference between the two frameworks is that caliper using ReadAsset chaincode function while tape using GetAllAssets chaincode function, but from my understanding, there should be no difference as both are query functions.

I uploaded the log file there for reference.
caliper.log

Finally I decided to close this ticket.
As I don't want to officially say some tool is better than others or not.

changed the order of execution (tape first caliper next)

yuanyi@192 Probe % ./tape -c config.yaml -n 5000
Time     0.44s  Block   1026    Tx     10
Time     0.80s  Block   1027    Tx     10
Time     1.10s  Block   1028    Tx     10
Time     1.46s  Block   1029    Tx     10
Time     2.01s  Block   1030    Tx     10
Time     2.39s  Block   1031    Tx     10
Time     2.67s  Block   1032    Tx     10
Time     3.05s  Block   1033    Tx     10
Time     3.41s  Block   1034    Tx     10
Time     3.75s  Block   1035    Tx     10
Time     4.05s  Block   1036    Tx     10
Time     4.36s  Block   1037    Tx     10
Time     4.45s  Block   1038    Tx     10
Time     4.48s  Block   1039    Tx     10
Time     4.51s  Block   1040    Tx     10
Time     4.55s  Block   1041    Tx     10
Time     4.57s  Block   1042    Tx     10
Time     4.61s  Block   1043    Tx     10
Time     4.66s  Block   1044    Tx     10
Time     4.68s  Block   1045    Tx     10
Time     4.71s  Block   1046    Tx     10
Time     4.75s  Block   1047    Tx     10
Time     4.77s  Block   1048    Tx     10
Time     4.78s  Block   1049    Tx     10
Time     4.80s  Block   1050    Tx     10
Time     4.82s  Block   1051    Tx     10
Time     4.84s  Block   1052    Tx     10
Time     4.87s  Block   1053    Tx     10
Time     4.88s  Block   1054    Tx     10
Time     4.90s  Block   1055    Tx     10
Time     4.92s  Block   1056    Tx     10
Time     4.95s  Block   1057    Tx     10
Time     4.98s  Block   1058    Tx     10
Time     5.00s  Block   1059    Tx     10
Time     5.02s  Block   1060    Tx     10
Time     5.04s  Block   1061    Tx     10
Time     5.05s  Block   1062    Tx     10
Time     5.07s  Block   1063    Tx     10
Time     5.08s  Block   1064    Tx     10
Time     5.10s  Block   1065    Tx     10
Time     5.12s  Block   1066    Tx     10
Time     5.14s  Block   1067    Tx     10
Time     5.16s  Block   1068    Tx     10
Time     5.17s  Block   1069    Tx     10
Time     5.19s  Block   1070    Tx     10
Time     5.22s  Block   1071    Tx     10
Time     5.24s  Block   1072    Tx     10
Time     5.26s  Block   1073    Tx     10
Time     5.27s  Block   1074    Tx     10
Time     5.30s  Block   1075    Tx     10
Time     5.32s  Block   1076    Tx     10
Time     5.35s  Block   1077    Tx     10
Time     5.37s  Block   1078    Tx     10
Time     5.40s  Block   1079    Tx     10
Time     5.41s  Block   1080    Tx     10
Time     5.43s  Block   1081    Tx     10
Time     5.45s  Block   1082    Tx     10
Time     5.47s  Block   1083    Tx     10
Time     5.49s  Block   1084    Tx     10
Time     5.51s  Block   1085    Tx     10
Time     5.53s  Block   1086    Tx     10
Time     5.55s  Block   1087    Tx     10
Time     5.57s  Block   1088    Tx     10
Time     5.59s  Block   1089    Tx     10
Time     5.62s  Block   1090    Tx     10
Time     5.64s  Block   1091    Tx     10
Time     5.67s  Block   1092    Tx     10
Time     5.70s  Block   1093    Tx     10
Time     5.71s  Block   1094    Tx     10
Time     5.73s  Block   1095    Tx     10
Time     5.75s  Block   1096    Tx     10
Time     5.77s  Block   1097    Tx     10
Time     5.79s  Block   1098    Tx     10
Time     5.80s  Block   1099    Tx     10
Time     5.83s  Block   1100    Tx     10
Time     5.84s  Block   1101    Tx     10
Time     5.86s  Block   1102    Tx     10
Time     5.88s  Block   1103    Tx     10
Time     5.89s  Block   1104    Tx     10
Time     5.92s  Block   1105    Tx     10
Time     5.93s  Block   1106    Tx     10
Time     5.95s  Block   1107    Tx     10
Time     5.97s  Block   1108    Tx     10
Time     5.99s  Block   1109    Tx     10
Time     6.01s  Block   1110    Tx     10
Time     6.03s  Block   1111    Tx     10
Time     6.05s  Block   1112    Tx     10
Time     6.07s  Block   1113    Tx     10
Time     6.09s  Block   1114    Tx     10
Time     6.11s  Block   1115    Tx     10
Time     6.13s  Block   1116    Tx     10
Time     6.15s  Block   1117    Tx     10
Time     6.16s  Block   1118    Tx     10
Time     6.17s  Block   1119    Tx     10
Time     6.18s  Block   1120    Tx     10
Time     6.19s  Block   1121    Tx     10
Time     6.20s  Block   1122    Tx     10
Time     6.21s  Block   1123    Tx     10
Time     6.22s  Block   1124    Tx     10
Time     6.23s  Block   1125    Tx     10
Time     6.24s  Block   1126    Tx     10
Time     6.25s  Block   1127    Tx     10
Time     6.26s  Block   1128    Tx     10
Time     6.27s  Block   1129    Tx     10
Time     6.28s  Block   1130    Tx     10
Time     6.29s  Block   1131    Tx     10
Time     6.30s  Block   1132    Tx     10
Time     6.31s  Block   1133    Tx     10
Time     6.32s  Block   1134    Tx     10
Time     6.33s  Block   1135    Tx     10
Time     6.34s  Block   1136    Tx     10
Time     6.35s  Block   1137    Tx     10
Time     6.36s  Block   1138    Tx     10
Time     6.37s  Block   1139    Tx     10
Time     6.38s  Block   1140    Tx     10
Time     6.39s  Block   1141    Tx     10
Time     6.40s  Block   1142    Tx     10
Time     6.41s  Block   1143    Tx     10
Time     6.42s  Block   1144    Tx     10
Time     6.44s  Block   1145    Tx     10
Time     6.46s  Block   1146    Tx     10
Time     6.47s  Block   1147    Tx     10
Time     6.48s  Block   1148    Tx     10
Time     6.49s  Block   1149    Tx     10
Time     6.50s  Block   1150    Tx     10
Time     6.50s  Block   1151    Tx     10
Time     6.51s  Block   1152    Tx     10
Time     6.52s  Block   1153    Tx     10
Time     6.53s  Block   1154    Tx     10
Time     6.54s  Block   1155    Tx     10
Time     6.56s  Block   1156    Tx     10
Time     6.57s  Block   1157    Tx     10
Time     6.59s  Block   1158    Tx     10
Time     6.61s  Block   1159    Tx     10
Time     6.62s  Block   1160    Tx     10
Time     6.64s  Block   1161    Tx     10
Time     6.65s  Block   1162    Tx     10
Time     6.66s  Block   1163    Tx     10
Time     6.68s  Block   1164    Tx     10
Time     6.69s  Block   1165    Tx     10
Time     6.70s  Block   1166    Tx     10
Time     6.72s  Block   1167    Tx     10
Time     6.73s  Block   1168    Tx     10
Time     6.74s  Block   1169    Tx     10
Time     6.75s  Block   1170    Tx     10
Time     6.76s  Block   1171    Tx     10
Time     6.78s  Block   1172    Tx     10
Time     6.79s  Block   1173    Tx     10
Time     6.80s  Block   1174    Tx     10
Time     6.81s  Block   1175    Tx     10
Time     6.82s  Block   1176    Tx     10
Time     6.84s  Block   1177    Tx     10
Time     6.85s  Block   1178    Tx     10
Time     6.86s  Block   1179    Tx     10
Time     6.88s  Block   1180    Tx     10
Time     6.89s  Block   1181    Tx     10
Time     6.90s  Block   1182    Tx     10
Time     6.92s  Block   1183    Tx     10
Time     6.93s  Block   1184    Tx     10
Time     6.94s  Block   1185    Tx     10
Time     6.95s  Block   1186    Tx     10
Time     6.96s  Block   1187    Tx     10
Time     6.98s  Block   1188    Tx     10
Time     7.00s  Block   1189    Tx     10
Time     7.01s  Block   1190    Tx     10
Time     7.03s  Block   1191    Tx     10
Time     7.04s  Block   1192    Tx     10
Time     7.05s  Block   1193    Tx     10
Time     7.07s  Block   1194    Tx     10
Time     7.08s  Block   1195    Tx     10
Time     7.09s  Block   1196    Tx     10
Time     7.10s  Block   1197    Tx     10
Time     7.11s  Block   1198    Tx     10
Time     7.12s  Block   1199    Tx     10
Time     7.14s  Block   1200    Tx     10
Time     7.14s  Block   1201    Tx     10
Time     7.16s  Block   1202    Tx     10
Time     7.18s  Block   1203    Tx     10
Time     7.19s  Block   1204    Tx     10
Time     7.20s  Block   1205    Tx     10
Time     7.21s  Block   1206    Tx     10
Time     7.22s  Block   1207    Tx     10
Time     7.23s  Block   1208    Tx     10
Time     7.24s  Block   1209    Tx     10
Time     7.25s  Block   1210    Tx     10
Time     7.26s  Block   1211    Tx     10
Time     7.27s  Block   1212    Tx     10
Time     7.28s  Block   1213    Tx     10
Time     7.29s  Block   1214    Tx     10
Time     7.30s  Block   1215    Tx     10
Time     7.31s  Block   1216    Tx     10
Time     7.32s  Block   1217    Tx     10
Time     7.33s  Block   1218    Tx     10
Time     7.35s  Block   1219    Tx     10
Time     7.36s  Block   1220    Tx     10
Time     7.37s  Block   1221    Tx     10
Time     7.38s  Block   1222    Tx     10
Time     7.40s  Block   1223    Tx     10
Time     7.41s  Block   1224    Tx     10
Time     7.42s  Block   1225    Tx     10
Time     7.43s  Block   1226    Tx     10
Time     7.44s  Block   1227    Tx     10
Time     7.45s  Block   1228    Tx     10
Time     7.46s  Block   1229    Tx     10
Time     7.47s  Block   1230    Tx     10
Time     7.48s  Block   1231    Tx     10
Time     7.49s  Block   1232    Tx     10
Time     7.50s  Block   1233    Tx     10
Time     7.52s  Block   1234    Tx     10
Time     7.53s  Block   1235    Tx     10
Time     7.54s  Block   1236    Tx     10
Time     7.55s  Block   1237    Tx     10
Time     7.56s  Block   1238    Tx     10
Time     7.57s  Block   1239    Tx     10
Time     7.59s  Block   1240    Tx     10
Time     7.60s  Block   1241    Tx     10
Time     7.61s  Block   1242    Tx     10
Time     7.62s  Block   1243    Tx     10
Time     7.64s  Block   1244    Tx     10
Time     7.66s  Block   1245    Tx     10
Time     7.67s  Block   1246    Tx     10
Time     7.68s  Block   1247    Tx     10
Time     7.69s  Block   1248    Tx     10
Time     7.70s  Block   1249    Tx     10
Time     7.71s  Block   1250    Tx     10
Time     7.72s  Block   1251    Tx     10
Time     7.74s  Block   1252    Tx     10
Time     7.75s  Block   1253    Tx     10
Time     7.76s  Block   1254    Tx     10
Time     7.77s  Block   1255    Tx     10
Time     7.78s  Block   1256    Tx     10
Time     7.79s  Block   1257    Tx     10
Time     7.80s  Block   1258    Tx     10
Time     7.82s  Block   1259    Tx     10
Time     7.83s  Block   1260    Tx     10
Time     7.84s  Block   1261    Tx     10
Time     7.85s  Block   1262    Tx     10
Time     7.87s  Block   1263    Tx     10
Time     7.88s  Block   1264    Tx     10
Time     7.90s  Block   1265    Tx     10
Time     7.91s  Block   1266    Tx     10
Time     7.92s  Block   1267    Tx     10
Time     7.93s  Block   1268    Tx     10
Time     7.94s  Block   1269    Tx     10
Time     7.95s  Block   1270    Tx     10
Time     7.96s  Block   1271    Tx     10
Time     7.97s  Block   1272    Tx     10
Time     7.98s  Block   1273    Tx     10
Time     7.99s  Block   1274    Tx     10
Time     8.00s  Block   1275    Tx     10
Time     8.02s  Block   1276    Tx     10
Time     8.03s  Block   1277    Tx     10
Time     8.03s  Block   1278    Tx     10
Time     8.04s  Block   1279    Tx     10
Time     8.05s  Block   1280    Tx     10
Time     8.07s  Block   1281    Tx     10
Time     8.07s  Block   1282    Tx     10
Time     8.09s  Block   1283    Tx     10
Time     8.10s  Block   1284    Tx     10
Time     8.11s  Block   1285    Tx     10
Time     8.13s  Block   1286    Tx     10
Time     8.14s  Block   1287    Tx     10
Time     8.15s  Block   1288    Tx     10
Time     8.16s  Block   1289    Tx     10
Time     8.18s  Block   1290    Tx     10
Time     8.19s  Block   1291    Tx     10
Time     8.19s  Block   1292    Tx     10
Time     8.20s  Block   1293    Tx     10
Time     8.21s  Block   1294    Tx     10
Time     8.22s  Block   1295    Tx     10
Time     8.24s  Block   1296    Tx     10
Time     8.25s  Block   1297    Tx     10
Time     8.26s  Block   1298    Tx     10
Time     8.27s  Block   1299    Tx     10
Time     8.28s  Block   1300    Tx     10
Time     8.29s  Block   1301    Tx     10
Time     8.30s  Block   1302    Tx     10
Time     8.31s  Block   1303    Tx     10
Time     8.32s  Block   1304    Tx     10
Time     8.33s  Block   1305    Tx     10
Time     8.34s  Block   1306    Tx     10
Time     8.35s  Block   1307    Tx     10
Time     8.36s  Block   1308    Tx     10
Time     8.37s  Block   1309    Tx     10
Time     8.38s  Block   1310    Tx     10
Time     8.39s  Block   1311    Tx     10
Time     8.40s  Block   1312    Tx     10
Time     8.41s  Block   1313    Tx     10
Time     8.42s  Block   1314    Tx     10
Time     8.43s  Block   1315    Tx     10
Time     8.44s  Block   1316    Tx     10
Time     8.46s  Block   1317    Tx     10
Time     8.47s  Block   1318    Tx     10
Time     8.48s  Block   1319    Tx     10
Time     8.49s  Block   1320    Tx     10
Time     8.50s  Block   1321    Tx     10
Time     8.51s  Block   1322    Tx     10
Time     8.52s  Block   1323    Tx     10
Time     8.53s  Block   1324    Tx     10
Time     8.54s  Block   1325    Tx     10
Time     8.55s  Block   1326    Tx     10
Time     8.56s  Block   1327    Tx     10
Time     8.57s  Block   1328    Tx     10
Time     8.58s  Block   1329    Tx     10
Time     8.59s  Block   1330    Tx     10
Time     8.61s  Block   1331    Tx     10
Time     8.62s  Block   1332    Tx     10
Time     8.63s  Block   1333    Tx     10
Time     8.65s  Block   1334    Tx     10
Time     8.66s  Block   1335    Tx     10
Time     8.67s  Block   1336    Tx     10
Time     8.68s  Block   1337    Tx     10
Time     8.69s  Block   1338    Tx     10
Time     8.70s  Block   1339    Tx     10
Time     8.71s  Block   1340    Tx     10
Time     8.72s  Block   1341    Tx     10
Time     8.73s  Block   1342    Tx     10
Time     8.74s  Block   1343    Tx     10
Time     8.75s  Block   1344    Tx     10
Time     8.76s  Block   1345    Tx     10
Time     8.77s  Block   1346    Tx     10
Time     8.78s  Block   1347    Tx     10
Time     8.79s  Block   1348    Tx     10
Time     8.80s  Block   1349    Tx     10
Time     8.82s  Block   1350    Tx     10
Time     8.83s  Block   1351    Tx     10
Time     8.84s  Block   1352    Tx     10
Time     8.86s  Block   1353    Tx     10
Time     8.86s  Block   1354    Tx     10
Time     8.87s  Block   1355    Tx     10
Time     8.88s  Block   1356    Tx     10
Time     8.89s  Block   1357    Tx     10
Time     8.90s  Block   1358    Tx     10
Time     8.91s  Block   1359    Tx     10
Time     8.92s  Block   1360    Tx     10
Time     8.93s  Block   1361    Tx     10
Time     8.94s  Block   1362    Tx     10
Time     8.95s  Block   1363    Tx     10
Time     8.96s  Block   1364    Tx     10
Time     8.97s  Block   1365    Tx     10
Time     8.98s  Block   1366    Tx     10
Time     8.99s  Block   1367    Tx     10
Time     9.00s  Block   1368    Tx     10
Time     9.02s  Block   1369    Tx     10
Time     9.03s  Block   1370    Tx     10
Time     9.04s  Block   1371    Tx     10
Time     9.05s  Block   1372    Tx     10
Time     9.06s  Block   1373    Tx     10
Time     9.07s  Block   1374    Tx     10
Time     9.08s  Block   1375    Tx     10
Time     9.09s  Block   1376    Tx     10
Time     9.10s  Block   1377    Tx     10
Time     9.11s  Block   1378    Tx     10
Time     9.12s  Block   1379    Tx     10
Time     9.12s  Block   1380    Tx     10
Time     9.13s  Block   1381    Tx     10
Time     9.14s  Block   1382    Tx     10
Time     9.15s  Block   1383    Tx     10
Time     9.16s  Block   1384    Tx     10
Time     9.17s  Block   1385    Tx     10
Time     9.18s  Block   1386    Tx     10
Time     9.20s  Block   1387    Tx     10
Time     9.21s  Block   1388    Tx     10
Time     9.22s  Block   1389    Tx     10
Time     9.23s  Block   1390    Tx     10
Time     9.24s  Block   1391    Tx     10
Time     9.25s  Block   1392    Tx     10
Time     9.26s  Block   1393    Tx     10
Time     9.27s  Block   1394    Tx     10
Time     9.28s  Block   1395    Tx     10
Time     9.29s  Block   1396    Tx     10
Time     9.30s  Block   1397    Tx     10
Time     9.31s  Block   1398    Tx     10
Time     9.32s  Block   1399    Tx     10
Time     9.33s  Block   1400    Tx     10
Time     9.34s  Block   1401    Tx     10
Time     9.35s  Block   1402    Tx     10
Time     9.36s  Block   1403    Tx     10
Time     9.37s  Block   1404    Tx     10
Time     9.38s  Block   1405    Tx     10
Time     9.39s  Block   1406    Tx     10
Time     9.40s  Block   1407    Tx     10
Time     9.41s  Block   1408    Tx     10
Time     9.42s  Block   1409    Tx     10
Time     9.43s  Block   1410    Tx     10
Time     9.44s  Block   1411    Tx     10
Time     9.46s  Block   1412    Tx     10
Time     9.47s  Block   1413    Tx     10
Time     9.48s  Block   1414    Tx     10
Time     9.49s  Block   1415    Tx     10
Time     9.50s  Block   1416    Tx     10
Time     9.51s  Block   1417    Tx     10
Time     9.52s  Block   1418    Tx     10
Time     9.53s  Block   1419    Tx     10
Time     9.54s  Block   1420    Tx     10
Time     9.55s  Block   1421    Tx     10
Time     9.56s  Block   1422    Tx     10
Time     9.57s  Block   1423    Tx     10
Time     9.58s  Block   1424    Tx     10
Time     9.60s  Block   1425    Tx     10
Time     9.61s  Block   1426    Tx     10
Time     9.62s  Block   1427    Tx     10
Time     9.63s  Block   1428    Tx     10
Time     9.64s  Block   1429    Tx     10
Time     9.65s  Block   1430    Tx     10
Time     9.66s  Block   1431    Tx     10
Time     9.67s  Block   1432    Tx     10
Time     9.68s  Block   1433    Tx     10
Time     9.69s  Block   1434    Tx     10
Time     9.70s  Block   1435    Tx     10
Time     9.71s  Block   1436    Tx     10
Time     9.72s  Block   1437    Tx     10
Time     9.73s  Block   1438    Tx     10
Time     9.74s  Block   1439    Tx     10
Time     9.75s  Block   1440    Tx     10
Time     9.76s  Block   1441    Tx     10
Time     9.77s  Block   1442    Tx     10
Time     9.78s  Block   1443    Tx     10
Time     9.79s  Block   1444    Tx     10
Time     9.80s  Block   1445    Tx     10
Time     9.81s  Block   1446    Tx     10
Time     9.82s  Block   1447    Tx     10
Time     9.83s  Block   1448    Tx     10
Time     9.84s  Block   1449    Tx     10
Time     9.85s  Block   1450    Tx     10
Time     9.86s  Block   1451    Tx     10
Time     9.87s  Block   1452    Tx     10
Time     9.88s  Block   1453    Tx     10
Time     9.89s  Block   1454    Tx     10
Time     9.90s  Block   1455    Tx     10
Time     9.91s  Block   1456    Tx     10
Time     9.92s  Block   1457    Tx     10
Time     9.93s  Block   1458    Tx     10
Time     9.94s  Block   1459    Tx     10
Time     9.95s  Block   1460    Tx     10
Time     9.96s  Block   1461    Tx     10
Time     9.97s  Block   1462    Tx     10
Time     9.98s  Block   1463    Tx     10
Time     9.99s  Block   1464    Tx     10
Time    10.01s  Block   1465    Tx     10
Time    10.01s  Block   1466    Tx     10
Time    10.02s  Block   1467    Tx     10
Time    10.03s  Block   1468    Tx     10
Time    10.04s  Block   1469    Tx     10
Time    10.05s  Block   1470    Tx     10
Time    10.06s  Block   1471    Tx     10
Time    10.07s  Block   1472    Tx     10
Time    10.07s  Block   1473    Tx     10
Time    10.08s  Block   1474    Tx     10
Time    10.09s  Block   1475    Tx     10
Time    10.10s  Block   1476    Tx     10
Time    10.11s  Block   1477    Tx     10
Time    10.12s  Block   1478    Tx     10
Time    10.13s  Block   1479    Tx     10
Time    10.14s  Block   1480    Tx     10
Time    10.15s  Block   1481    Tx     10
Time    10.16s  Block   1482    Tx     10
Time    10.17s  Block   1483    Tx     10
Time    10.18s  Block   1484    Tx     10
Time    10.19s  Block   1485    Tx     10
Time    10.20s  Block   1486    Tx     10
Time    10.21s  Block   1487    Tx     10
Time    10.21s  Block   1488    Tx     10
Time    10.22s  Block   1489    Tx     10
Time    10.23s  Block   1490    Tx     10
Time    10.24s  Block   1491    Tx     10
Time    10.25s  Block   1492    Tx     10
Time    10.25s  Block   1493    Tx     10
Time    10.26s  Block   1494    Tx     10
Time    10.27s  Block   1495    Tx     10
Time    10.28s  Block   1496    Tx     10
Time    10.29s  Block   1497    Tx     10
Time    10.30s  Block   1498    Tx     10
Time    10.31s  Block   1499    Tx     10
Time    10.31s  Block   1500    Tx     10
Time    10.32s  Block   1501    Tx     10
Time    10.33s  Block   1502    Tx     10
Time    10.34s  Block   1503    Tx     10
Time    10.35s  Block   1504    Tx     10
Time    10.36s  Block   1505    Tx     10
Time    10.37s  Block   1506    Tx     10
Time    10.37s  Block   1507    Tx     10
Time    10.38s  Block   1508    Tx     10
Time    10.39s  Block   1509    Tx     10
Time    10.40s  Block   1510    Tx     10
Time    10.41s  Block   1511    Tx     10
Time    10.41s  Block   1512    Tx     10
Time    10.42s  Block   1513    Tx     10
Time    10.43s  Block   1514    Tx     10
Time    10.44s  Block   1515    Tx     10
Time    10.44s  Block   1516    Tx     10
Time    10.45s  Block   1517    Tx     10
Time    10.46s  Block   1518    Tx     10
Time    10.47s  Block   1519    Tx     10
Time    10.48s  Block   1520    Tx     10
Time    10.49s  Block   1521    Tx     10
Time    10.49s  Block   1522    Tx     10
Time    10.50s  Block   1523    Tx     10
Time    10.51s  Block   1524    Tx     10
Time    10.52s  Block   1525    Tx     10
tx: 5000, duration: 10.517015595s, tps: 475.420042

2021.07.08-21:58:52.309 info  [caliper] [report-builder]        ### Test result ###
2021.07.08-21:58:52.314 info  [caliper] [report-builder]
+-----------+-------+------+-----------------+-----------------+-----------------+-----------------+------------------+
| Name      | Succ  | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|-----------|-------|------|-----------------|-----------------|-----------------|-----------------|------------------|
| readAsset | 11656 | 0    | 393.8           | 0.03            | 0.00            | 0.01            | 393.8            |
+-----------+-------+------+-----------------+-----------------+-----------------+-----------------+------------------+

2021.07.08-21:58:52.315 info  [caliper] [round-orchestrator]    Finished round 1 (readAsset) in 30.106 seconds
2021.07.08-21:58:52.315 info  [caliper] [monitor.js]    Stopping all monitors
2021.07.08-21:58:52.315 info  [caliper] [report-builder]        ### All test results ###
2021.07.08-21:58:52.316 info  [caliper] [report-builder]
+-----------+-------+------+-----------------+-----------------+-----------------+-----------------+------------------+
| Name      | Succ  | Fail | Send Rate (TPS) | Max Latency (s) | Min Latency (s) | Avg Latency (s) | Throughput (TPS) |
|-----------|-------|------|-----------------|-----------------|-----------------|-----------------|------------------|
| readAsset | 11656 | 0    | 393.8           | 0.03            | 0.00            | 0.01            | 393.8            |
+-----------+-------+------+-----------------+-----------------+-----------------+-----------------+------------------+

2021.07.08-21:58:52.325 info  [caliper] [report-builder]        Generated report with path /Users/yuanyi/OpenSource/probe/Probe/caliper-workspace/report.html
2021.07.08-21:58:52.325 info  [caliper] [monitor.js]    Stopping all monitors
2021.07.08-21:58:52.325 info  [caliper] [worker-orchestrator]   Sending exit message to connected workers
2021.07.08-21:58:52.325 info  [caliper] [round-orchestrator]    Benchmark finished in 57.02 seconds. Total rounds: 1. Successful rounds: 1. Failed rounds: 0.
2021.07.08-21:58:52.326 info  [caliper] [caliper-engine]        Skipping end command due to benchmark flow conditioning
2021.07.08-21:58:52.326 info  [caliper] [cli-launch-manager]    Benchmark successfully finished
2021.07.08-21:58:52.326 info  [caliper] [worker-message-handler]        Worker#1 is exiting
2021.07.08-21:58:52.326 info  [caliper] [worker-message-handler]        Worker#0 is exiting

base on my laptop, @dexhunter, welcome for any kind of further investigate and hope you can find root cause.


[CI] Add utility to run same matmul test on an array of shapes

Tangential thoughts:

Let's try for fewer i32 and more i8 / bf16 tests where possible
I/we should profile the time it takes to run the script, see if there are any easy pickings to make it faster

Tangential thoughts:

Let's try for fewer i32 and more i8 / bf16 tests where possible
I/we should profile the time it takes to run the script, see if there are any easy pickings to make it faster

I  think more tests is better right now (we don't really have a lot of tests yet anyway). I32 has a reasonable coverage right now with different sizes and 50% or so of those tests have failed at some point, demonstrating that they are edge cases, so they are good to keep. Overall, I don't think we should be optimizing profile times too much right now as we're trying to get things functional and I don't think the current CI time is a real bottleneck for development. Also, some of these tests are quite slow for  now, but will become a lot faster over time with control code reduction, ukernels etc.


feat: add ok property to response and to_tuple func

Following https://developer.mozilla.org/en-US/docs/Web/API/Response/ok
And for the tuple response, I keep copy-pasting that function in every package or project I use req. Ideally, for data pipelining that relies on the tuple response.

I can't run the unit tests, it keeps failing due to
clang brotli_nif.o common/constants.o common/context.o common/dictionary.o common/platform.o common/transform.o dec/bit_reader.o dec/decode.o dec/huffman.o dec/state.o enc/backward_references.o enc/backward_references_hq.o enc/bit_cost.o enc/block_splitter.o enc/brotli_bit_stream.o enc/cluster.o enc/command.o enc/compress_fragment.o enc/compress_fragment_two_pass.o enc/dictionary_hash.o enc/encode.o enc/encoder_dict.o enc/entropy_encode.o enc/fast_log.o enc/histogram.o enc/literal_cost.o enc/memory.o enc/metablock.o enc/static_dict.o enc/utf8_util.o -L/usr/local/opt/libxml2/lib -shared -rdynamic  -o /Users/ubi/Developer/wojtekmach/req/deps/brotli/priv/brotli.so
Undefined symbols for architecture x86_64:
  "_enif_alloc", referenced from:
      _brotli_alloc in brotli_nif.o
  "_enif_alloc_binary", referenced from:
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_take_output in brotli_nif.o
  "_enif_alloc_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
  "_enif_compare", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
  "_enif_free", referenced from:
      _brotli_free in brotli_nif.o
  "_enif_get_resource", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_has_more_output in brotli_nif.o
      _brotli_encoder_is_finished in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_has_more_output in brotli_nif.o
      _brotli_decoder_is_finished in brotli_nif.o
      ...
  "_enif_get_uint", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
  "_enif_get_ulong", referenced from:
      _brotli_max_compressed_size in brotli_nif.o
  "_enif_inspect_iolist_as_binary", referenced from:
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_decoder_decompress_stream in brotli_nif.o
  "_enif_make_atom", referenced from:
      _brotli_init in brotli_nif.o
  "_enif_make_badarg", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_has_more_output in brotli_nif.o
      _brotli_encoder_is_finished in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
      ...
  "_enif_make_binary", referenced from:
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_take_output in brotli_nif.o
  "_enif_make_int", referenced from:
      _brotli_version in brotli_nif.o
  "_enif_make_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
  "_enif_make_string", referenced from:
      _brotli_decoder_error_description in brotli_nif.o
  "_enif_make_tuple", referenced from:
      _brotli_version in brotli_nif.o
  "_enif_make_ulong", referenced from:
      _brotli_max_compressed_size in brotli_nif.o
  "_enif_open_resource_type", referenced from:
      _brotli_init in brotli_nif.o
  "_enif_release_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/ubi/Developer/wojtekmach/req/deps/brotli/priv/brotli.so] Error 1
===> Hook for compile failed!

** (Mix) Could not compile dependency :brotli, "/Users/ubi/.asdf/installs/elixir/1.14.4/.mix/elixir/1-14/rebar3 bare compile --paths /Users/ubi/Developer/wojtekmach/req/_build/test/lib/*/ebin" command failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile brotli", update it with "mix deps.update brotli" or clean it with "mix deps.clean brotli"

I can't run the tests, if you have any idea of how to fix this in MacOS
ProductName:	macOS
ProductVersion:	12.4

clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c brotli_nif.c -o brotli_nif.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c common/constants.c -o common/constants.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c common/context.c -o common/context.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c common/dictionary.c -o common/dictionary.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c common/platform.c -o common/platform.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c common/transform.c -o common/transform.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c dec/bit_reader.c -o dec/bit_reader.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c dec/decode.c -o dec/decode.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c dec/huffman.c -o dec/huffman.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c dec/state.c -o dec/state.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/backward_references.c -o enc/backward_references.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/backward_references_hq.c -o enc/backward_references_hq.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/bit_cost.c -o enc/bit_cost.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/block_splitter.c -o enc/block_splitter.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/brotli_bit_stream.c -o enc/brotli_bit_stream.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/cluster.c -o enc/cluster.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/command.c -o enc/command.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/compress_fragment.c -o enc/compress_fragment.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/compress_fragment_two_pass.c -o enc/compress_fragment_two_pass.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/dictionary_hash.c -o enc/dictionary_hash.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/encode.c -o enc/encode.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/encoder_dict.c -o enc/encoder_dict.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/entropy_encode.c -o enc/entropy_encode.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/fast_log.c -o enc/fast_log.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/histogram.c -o enc/histogram.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/literal_cost.c -o enc/literal_cost.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/memory.c -o enc/memory.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/metablock.c -o enc/metablock.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/static_dict.c -o enc/static_dict.o
clang -O3 -std=c99 -finline-functions -Wall -fPIC -I /Users/ubi/.asdf/installs/erlang/25.2/erts-13.1.3/include/ -I ./include/ -I/usr/local/opt/libxml2/include -c enc/utf8_util.c -o enc/utf8_util.o
clang brotli_nif.o common/constants.o common/context.o common/dictionary.o common/platform.o common/transform.o dec/bit_reader.o dec/decode.o dec/huffman.o dec/state.o enc/backward_references.o enc/backward_references_hq.o enc/bit_cost.o enc/block_splitter.o enc/brotli_bit_stream.o enc/cluster.o enc/command.o enc/compress_fragment.o enc/compress_fragment_two_pass.o enc/dictionary_hash.o enc/encode.o enc/encoder_dict.o enc/entropy_encode.o enc/fast_log.o enc/histogram.o enc/literal_cost.o enc/memory.o enc/metablock.o enc/static_dict.o enc/utf8_util.o -L/usr/local/opt/libxml2/lib -shared -rdynamic  -o /Users/ubi/Developer/wojtekmach/req/deps/brotli/priv/brotli.so
Undefined symbols for architecture x86_64:
  "_enif_alloc", referenced from:
      _brotli_alloc in brotli_nif.o
  "_enif_alloc_binary", referenced from:
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_take_output in brotli_nif.o
  "_enif_alloc_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
  "_enif_compare", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
  "_enif_free", referenced from:
      _brotli_free in brotli_nif.o
  "_enif_get_resource", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_has_more_output in brotli_nif.o
      _brotli_encoder_is_finished in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_has_more_output in brotli_nif.o
      _brotli_decoder_is_finished in brotli_nif.o
      ...
  "_enif_get_uint", referenced from:
      _brotli_encoder_set_parameter in brotli_nif.o
  "_enif_get_ulong", referenced from:
      _brotli_max_compressed_size in brotli_nif.o
  "_enif_inspect_iolist_as_binary", referenced from:
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_decoder_decompress_stream in brotli_nif.o
  "_enif_make_atom", referenced from:
      _brotli_init in brotli_nif.o
  "_enif_make_badarg", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_encoder_set_parameter in brotli_nif.o
      _brotli_encoder_has_more_output in brotli_nif.o
      _brotli_encoder_is_finished in brotli_nif.o
      _brotli_encoder_compress_stream in brotli_nif.o
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
      ...
  "_enif_make_binary", referenced from:
      _brotli_encoder_take_output in brotli_nif.o
      _brotli_decoder_take_output in brotli_nif.o
  "_enif_make_int", referenced from:
      _brotli_version in brotli_nif.o
  "_enif_make_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
  "_enif_make_string", referenced from:
      _brotli_decoder_error_description in brotli_nif.o
  "_enif_make_tuple", referenced from:
      _brotli_version in brotli_nif.o
  "_enif_make_ulong", referenced from:
      _brotli_max_compressed_size in brotli_nif.o
  "_enif_open_resource_type", referenced from:
      _brotli_init in brotli_nif.o
  "_enif_release_resource", referenced from:
      _brotli_encoder_create in brotli_nif.o
      _brotli_decoder_create in brotli_nif.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/ubi/Developer/wojtekmach/req/deps/brotli/priv/brotli.so] Error 1
===> Hook for compile failed!

** (Mix) Could not compile dependency :brotli, "/Users/ubi/.asdf/installs/elixir/1.14.4/.mix/elixir/1-14/rebar3 bare compile --paths /Users/ubi/Developer/wojtekmach/req/_build/test/lib/*/ebin" command failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile brotli", update it with "mix deps.update brotli" or clean it with "mix deps.clean brotli"

Thank you for the PR. response.ok field is an interesting approach and I definitely want to make it easier to solve such common use case, but tbh I'm not a fan of such, to use an OOP lingo, "computed properties".
Regarding to_tuple, we have http_errors: :raise and I'd like to find a solution more along those lines.
Could you share some real world snippets where response.ok and to_tuple are an improvement?

Regarding NIF errors, sorry, no idea. I'm on a Mac too. If iex> Mix.install([:brotli]) fails, I'd try to investigate that.

Let me start with the intent: the code-gen tools to generate an output to be as clean, predictable, familiar, and user-friendly as possible.
This means pushing some of these repeatable functions will lead to a skinny layer in the code-gen where they are doing elementary composition in the generated parts.
I am personally and financially invested in it!

The ok-error tuple situation is for use cases where you are doing pipelining to control the flow of information, using packages like OnePiece.Result or custom-made.
Different style from the with statement; the ok-error tuple allows you to do with, you can't do without it for functions like those.
At least personally, this is all over the place from my experience (this is just one SDK Plaid Elixir but also take a look to the GitHub Search, it is all over the place. Granted, I am not saying it is Req per see. I am more focus on the intent and prefer if Req does it to avoid trivial mistakes.
  defp exchange_public_token(public_token) do
    %{public_token: public_token}
    |> Umbrella.plaid().item_public_token_exchange()
    |> Umbrella.Plaid.Response.to_tuple() # THIS
    |> OnePiece.Result.map_err(&Graphql.to_plaid_error/1)
  end

Same with copying the ok (maybe ok? would be a better name), almost copy-pasta among either Tesla-driven packages or Req in code-gens.
Based on my experience and contributed to multiple HTTP SDK libs, when using an SDK the users care less about the status but understand when it supposes to be a success or a failure to do branching. Rarely (although it sometimes happens, it is not 100% either), caring about HTTP status is a thing.
Related to this, https://github.com/elixir-tesla/tesla/discussions/571

I think response.ok or response.ok? is interesting and while we could have Response.ok?/1 and/or Response.is_ok/1 they would not be quite as ergonomic as pattern matching on that field.
I'm less convinced of Response.to_tuple, since Req.request already returns ok/error tuple, I'd like to solve the problem there.
As I mentioned before we have http_errors: :return (default) | :raise. Perhaps we change it to http_errors: :response (default) | :exception. That is:
Req.get("https://httpbin.org/status/400")
#=> {:ok, %Req.Response{}}

Req.get("https://httpbin.org/status/400", http_errors: :exception)
#=> {:error, %Req.Error{}}

Would this help?
This glosses over 3xx status codes but treating them as basically errors is debatable.

I'm less convinced of Response.to_tuple, since Req.request already returns ok/error tuple, I'd like to solve the problem there.

 I missed that completely, ignore me then!

Thanks for feedback. Better naming ideas always appreciated!

Yeah http_ prefix was there to help distinguishing it from transport errors which this feature does not cover.

Thanks @yordis, this has been extremely helpful. I'm gonna close this in favour of https://github.com/wojtekmach/req/issues/193 though it's still up in the air how exactly this is going to work and be named.

What about the :ok (better name here) field? Or is that covered by the http_error thingy (meaning it would check for 200...299)

There's no direct equivalent for response.ok but it will be mostly covered by existing features. Most of 3xx codes by follow_redirects step and 4xx/5xx by upcoming changes to http_errors.

hhhhmm would it be safe to use http_errors as a replacement for the intent? https://github.com/search?q=200..299+language%3AElixir&type=code&l=Elixir
It sounds like, for the most part. I guess.

yeah not 100% equivalent but for most common scenarios it should be.


nixos/mastodon: Add cleanupMediaCache option

Description of changes
Adds a cleanupMediaCache cron to the mastodon service.
This adds a cron to periodically clean up the mastodon media cache, in order to keep disk usage down. Documentation is taken from the official mastodon documentation.
https://docs.joinmastodon.org/admin/tootctl/#media
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Sorry that this didn't receive the attention it deserved. I believe your functionality is implemented in https://github.com/NixOS/nixpkgs/pull/199040?

By the way, for more visibility, feel free to ping the maintainers of the service :)


Clear forms after submit

This won't stop bot spam but it at least stops people from sitting on the form and resubmitting over and over with 2 clicks each time.

https://app.shortcut.com/larder/story/6785/prevent-rapid-form-submissions


memberOf roles look like Apps, not roles

Page: /setup/security/authorization/service-accounts/
Feedback:
Call out explicitly that those values are roles, not application names.

You mean specifically in this:
..."memberOf": ["myApp-prod","myApp-qa"]  ?

Yep, that's it.
On Mon, Jun 4, 2018 at 2:42 PM Dave Dorbin<EMAIL_ADDRESS>wrote:

You mean specifically in this:
..."memberOf": ["myApp-prod","myApp-qa"] ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spinnaker/spinnaker.github.io/issues/823#issuecomment-394457098,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMiGLgOmnqg_HejjsvF-fG82gLc-dzULks5t5X-pgaJpZM4UXSV-
.

--
Travis Tomsu | Software Engineer |<EMAIL_ADDRESS>|<PHONE_NUMBER>

#930


Request For Comment - Solder API v0.8

Documentation: http://docs.technicsolder.apiary.io
Implementation: indemnity83/technicsolder
Issues: indemnity83/technicsolder#issues
Proposals: indemnity83/technicsolder#pull-requests
Abstract
The current API has worked really well for its purpose, which is to have users create client modpacks in a web browser, and let the launcher know what needs to be pulled together to deploy that configuration.
However, it is NOT very good at allowing third party tools to facilitate the process for a user. The endpoints are all read only, and their return datasets are inconsistant from endpoint to endpoint.
I propose developing a compete JSON API v1.0 implementation of the TechnicSolder platform. In order to modernize the API, I've also re-built the core of the application using Laravel 5.3 and that implementation too is up for comment. I have done a lot of conceptual, and early implementation work toward that goal and would like to get feedback (particuarly from @genpage) before going on any further.
Backward Compatability
Existing api endpoints use singular nouns (mod, modpack) and the proposed v0.8 endpoints MUST use plural nouns (mods, modpacks, builds, etc.), which will ensure FULL BACKWARD COMPATABILITY. This is critical to the success of the update, as the Technic system is widly distributed and there are many components that rely on the v0.7 API.
The v0.7 API would be deprecated, but would likely be maintained until at least the TechnicLauncher and TechnicPack.net consumers were updated, and significantly adopted.
API Documentation
The living API Documentation can be found at http://docs.technicsolder.apiary.io, the raw version of the document is pulled from the apiary.apib file in the root of the development branch.
Contributing
Please make specific comments/suggestions as issues in the forked repository. Similarly if you'd like to suggest a change to the documentation please submit it as a pull request against the forked repository.
Notes on Proof of Concept Stability
The Apiary API documentation, as well as the Application impementation are ovbiously subject to significant change as this proposal is discussed, and if/until they are pulled into the master of the technicpack/technicsolder repository they should be considered unstable, and subject to breaking changes (for example, changes to the database structure WILL be made to the existing migrations files).
Breaking changes will be noted where known in commit messages, but no garentee is made and the application in its current form should not be considered fit for production use.

Hey @Indemnity83!
Thank you for the contribution here and I'm sorry I haven't gotten back sooner. My first thoughts is that it touches on the main concerns I have while moving forward,
The main holdup for the Technic team is the lack of a launcher developer at this time to implement the new API changes. I'm glad to see backwards compatibility talked and addressed as that would be the main concern/block.
I will be reviewing this more deeply in the coming weeks. My main focus/time has been addressing the TechnicPack move to DO infra, and subsequent changes to improve performance and reliability for the entire platform.

No problem @GenPage; I realize this is a lot to digest.
I'm excited to push some significant progress into the project, but at the same time I'm only one person working in a vacuum. So take some time, see how this fits in the road-map of the TechnicPack team as well as the desires of the community as a whole.

Wow @Indemnity83 first let me say thank you for taking the time to put together something like this. When Solder was created it was always supposed to be a community project of sorts but we really never got any sort of contribution on this level. So thank you for spending your valuable time to help Solder become.. whatever's next!
Your Apiary docs are interesting, because a year ago we started laying the groundwork for what would be the new Technic Solder. Unfortunately our plans came to a screeching halt when we lost our primary launcher dev. Our plans for the new Solder would require a significant launcher overhaul and it just wasn't possible at the time to continue development on the private, experimental Solder branch. You can see some of our own work at this Apiary. http://docs.solder.apiary.io/
You may or may not have seen that yet. If you have you may notice some glaring similarities in the design between your concept and ours. I do like that you are following the JSON spec and to be clear our API blueprint was very rough and in early stages. Although I did technically have a somewhat functioning version of the API running in Node.
We have always wanted to abstract Solder's API out another level. That was the plan of the new API. We wanted to handle mods as "resources" instead of just always being mods. For example I am pretty sure in our docs we even treat mods as just "files." You specify the resource as the file type, and in the options parameter you can assign the directory it gets dropped. And of course, the classic "zip" type which just extracts over the base directory.
Unfortunately this type of implementation can't really go anywhere without the launcher being rewritten. But this is why I like your idea! We can begin to work towards this goal while still maintaining  backwards compatibility with 0.7. As you mentioned in #356, a worker that could package up mods into the classic zip form for compatibility would be great in this sort of situation. Then, when we can eventually progress launcher development, we can work towards full 0.8+ support.
I really like where you are going with this and like @GenPage said I will have to take some time to actually play with your fork and dig into it a little bit. As of now I have only looked through your API docs. I like what I am seeing though.
Let's keep in touch and keep pushing this forward. If you have any questions or ideas feel free to run them by Genpage or me in Discord (if you are on there) or just in here.

@sct I had not known about the API you had going on apiary already; it is funny how similar we ended up 👍
I do use Discord (although not often). If you want to discuss there feel free to send me a message (@indemnity83 there too); I added you as a fried so we could so PMs for some of this, might be faster.
I totally hear you on the lack of a launcher developer being an issue; but I don't think it should slow down the development of an API; ultimately the API is the common ground that both development teams work toward so these are good discussions to have.
Looking through your API blueprint vs Mine there are a bunch of minor differences that are mostly semantics and a couple more significant architecture decisions we should chat about.
Semantics
Mods vs Resources
I concede that mod isn't appropriate for the direction we're all headed in, but resource might be confusing with Minecraft Resource Packs. I'll update my document to resource for now though.
Release vs Versions
I had modeled this as release just because I felt version was somewhat ambiguous, but since I can't make any better argument than that, again I'll update my documentation and implementation back to version.
Architecture Differences
Resource Versions have ONE file vs Resource Versions have MULTIPLE files
This one is more significant; your spec has a single file per resource version, and that resource version has a type as well as an ability to set a path for the file on the client end. In my implementation proposal in #356 I assumed that a resource version could have multiple files (assets), each with their own location attribute (again semantics, path vs location). My thoughts were a mod and its related config file in a single "package".
The single file per resource version certainly simplifies things; but I don't think it would scale well. I could be convinced otherwise though.
Self Defined API vs JSON API Standard
Not much to say here; just need to choose a direction. the JSON API is a little more work to implement but is very well thought out and allows developers for clients to use pre built tools to consume the API instead of having to write from scratch each time. My recommendation is to use the standard solution so we can focus on the application, not how the JSON is formatted.
Password token Auth vs OAuth2
Similar to above; choice is between coming up with something and making sure its well defined, or implementing a standard. Again, I recommend sticking with standards based solutions to common problems.
Not addressed
Users endpoints
You have included some user management endpoints in your API, I left them out of mine assuming that user management would be done through the web interface. They're easily added though so I can do that for completeness.

I spent some time this afternoon and evening doing an opinionated merge of the two API specs; I also put a little work into making the document a little more prescriptive in areas since when its done, it should in fact be a specification.

Phew okay a lot to talk about here huh. Okay so for the similarities with "Resource Packs" I think people will just need to deal with that 😄
Our Resource object took only file, you're right. I like your idea better. No reason it can't do multiple files.
I also agree on the JSON Standard.
For Auth, it's been awhile so I don't remember all the details exactly but I am pretty sure we were using JWT standard for Auth. OAuth2 seemed like it was a little overkill at the time during design. Either way it doesn't matter. They both accomplish the same thing I am okay with OAuth2.
We had a User endpoint because the new Solder was going to be JUST the API. The frontend being basically just an interface to control everything. The API was standalone. Then the frontend was written in React to plug into the API. But auth, users, modpacks, resources and anything else Solder may have come to do would have been done through API calls. Which would allow anyone to build their own tool for Solder in any language they wish.
Either way haven't taken a look at your merge yet. Let me do that now 👍

For Auth, it's been awhile so I don't remember all the details exactly but I am pretty sure we were using JWT standard for Auth. OAuth2 seemed like it was a little overkill at the time during design. Either way it doesn't matter. They both accomplish the same thing I am okay with OAuth2.

Perfect, the Laravel Passport component I pulled in for Auth supports JWT too.


Add WebSocket connected() function

This is a helper function for determining if the underlying WebSocket has not yet closed. Needing to know this was the main reason I requested #608 to make the socket public. If you think it'd be okay, we could probably revert that change with this. The issue is that some people may be relying on the socket being public now.
Also, I wasn't sure what your preference would be a connected() function or a getter property. I can change if you prefer that.

Codecov Report

Merging #656 (51ff268) into main (6c79874) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #656   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           19        19
  Lines          509       531   +22
  Branches        39        39
=========================================
+ Hits           509       531   +22

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

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

Impacted Files
Coverage Δ

src/client/WebSocketClient.ts
100.00% <ø> (ø)

Hi @hjoelr, let's make it a getter function. The socket can stay public because otherwise we would break the API contract. :)

Thanks again @hjoelr. 🙏 All your changes are now live with v3.1.0 -> https://www.npmjs.com/package/coinbase-pro-node/v/3.1.0

@bennycode You're welcome. My next contribution will hopefully be based off the idea in #421.


Fibonacci series generator added.

Related Issue

Fibonacci Series generator

Closes: #1505
Checklist:

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] New and existing unit tests pass locally with my changes.

Screenshots

@ridsuteri Please review it and let me know if there are any conflicts .


Label width not adjusted to the message window's width

The issue
The proportional text sections are adjusted to the message window's width - which beforehand had been determined by (in the sequence)

the default or specified message window width
the title width
the width of the displayed reply buttons
the width of the monospaced text sections.

The section label's width however is not adjusted correspondingly.
The required solution
Like the proportional text sections also the labels should be adjusted even when there are just labels for monospaced text sections and no proportional at all.
determined by the title, the displayed buttons and the minimum window width specified, the section labels aren't.

Solved


Added perPixelTolerance and overallTolerance to SnapshotVerifyAccessibility()

Thanks for opening this @bonkey! I'm gonna close it in favor of #144, for the reasons described in the PR.


Add simple CI Support

This adds a simple CI which should check on PRs if the altered extension code break or works as expected.
Disclaimer: I am a newbie in terms of GitHub actions so any feedback is welcome. Most important to me though is to keep the CI as simple as possible as this repository is a template for other extensions and I don't want to overcomplicate everything

All this does is see if it builds, you should create checks for if it is working as intended, eg test it in use in the game, that way you know if its actually working.

All this does is see if it builds, you should create checks for if it is working as intended, eg test it in use in the game, that way you know if its actually working.

Thanks for the feedback! Should I create a new job for this then or do it right after inside the same job?

Same.