clojure: <IP_ADDRESS>7 -> <IP_ADDRESS>3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for clojure is: "A Lisp dialect for the JVM"
meta.homepage for clojure is: "https://clojure.org/"
meta.changelog for clojure is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found <IP_ADDRESS>3 with grep in /nix/store/25igbwns7ab35x44gpr0l3ix395jq399-clojure-<IP_ADDRESS>3
found <IP_ADDRESS>3 in filename of file in /nix/store/25igbwns7ab35x44gpr0l3ix395jq399-clojure-<IP_ADDRESS>3

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

3 package rebuild(s)

2 x86_64-linux rebuild(s)
3 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
clojure
lumo
obb

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/25igbwns7ab35x44gpr0l3ix395jq399-clojure-<IP_ADDRESS>3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A clojure https://github.com/r-ryantm/nixpkgs/archive/4bcda364c3ceab680f00ca5f5360066f98d3a70a.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/25igbwns7ab35x44gpr0l3ix395jq399-clojure-<IP_ADDRESS>3
ls -la /nix/store/25igbwns7ab35x44gpr0l3ix395jq399-clojure-<IP_ADDRESS>3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

clojure
lumo

Maintainer pings
cc @jlesquembre @thiagokokada for testing.

Result of nixpkgs-review pr 169884 run on x86_64-linux 1

2 packages built:

clojure
lumo


Drop-seq, DroNc-seq, Fluidigm C1 Comparison

Dataset/group this task is for:

Drop-seq, DroNc-seq, Fluidigm C1 Comparison - a9c022b4-c771-4468-b769-cabcf9738de3
https://data.humancellatlas.org/explore/projects/a9c022b4-c771-4468-b769-cabcf9738de3?catalog=dcp1
https://contribute.data.humancellatlas.org/projects/detail?uuid=a9c022b4-c771-4468-b769-cabcf9738de3
Description of the task:

Update the bioarxiv publication to the scientific reports publication
https://www.nature.com/articles/s41598-020-58327-6
Acceptance criteria for the task:

[x] project updated in ingest
[ ] project metadata exported to DCP

We need one of @ebi-ait/ait-dev to switch the status from Complete to Valid to be able to re-submit the updated metadata only.

@yusra-haider and this one please?

@ami-day if I got it right Yusra has already done this and the only thing left is to complete the import form. Is that correct?

Yes, done now


release ODB v0.6.0

We have released a new version of ODB, and need our header to list all versions.
This depends on https://github.com/pivotal-cf/docs-book-pcfservices/pull/17
Cheers!
cc @avade

Thanks, @craigfurman !


Black screen while play on Android hardware device

I am trying to draw a video into a sprite, but after starting to play the video, I see one frame from the video for a split second and then just a black screen
And at the same time on AVD everything work fine
I tried different options and the result is the same, tried draw video to mash and replace MediaPlayer to ExoPlayer, but nothing

New snapshot with the fix should be available

Checked and everything works well 👍


Can't properly set position of modal

Describe the bug
It seem that it is not possible to set the X and Y position of a modal. Trying with an event handler sometimes (!?) moves the modal but its not reliable.
To Reproduce

Create modal

  //

    @OnInit
    public void init() {
        modalStage.setX(someXPosition);
        modalStage.setY(someYPosition);
    }

  //

init and show it using modals.show()

modals
             .modal(componentProviderget())
             .show();

See that it did not move to the set position

Expected behavior
It should move to the set position
Desktop (please complete the following information):

OS: Linux (Arch)
Using Hyprland for wayland

fulibFx doesn't modify the position of the modal stage at all, so this is probably JavaFX related.
When using the new modal builder, show() returns the modal stage object.
Could you try using this instance to set the position, after show() has been called?

What also just came to my mind is that when I wrote a JavaFX application a while ago, we had some problems with centering the modal on linux (Ubuntu), so this could also be an OS problem, even though this is less likely.

I will try using the instance to set the position after calling show().
I also considered if it was an OS problem, but since other participants of stp, who are using windows, encountered similar problems it seems not to be the case.

Closing this, since it isn't a fulibFx issue.


Mapping modification help

Can someone kindly explain how to modify the mapping text files such that Snare "1" can be played by BOTH midi notes 38 and 40?
I am fairly well versed in the 'SFZ' file format (groups, regions, etc.) but don't quite follow the TXT file format here with 'define' variable substitutions...
If 'macro.txt' is modified such that
$KEY_SNR1 38
becomes
$KEY_SNR1 40
then Snare1 only plays on midi note 40.
Is there a workaround?

Was able to answer my own question after a little more digging.
I'll share my solution here for anyone else looking to make a similar modification:
I. To play "SNR1" on both midi notes 38 and 40:
Modify the 7 "data\group\snare*.txt" files as follows
1. Comment ("//") all lines after 'key=$KEY_SNR2'
2. Copy the 4 lines after 'key=$KEY_SNR1' and paste after the 'key=$KEY_SNR2' line
II. To play the "KICK" drum on both midi notes 35 and 36:
A. Modify "data\keymap.txt", "User\Naked Drums TD-12 keymap.txt" and "User\Naked Drums GM keymap.txt" as follows:
Replace '#define $KEY_KICK 36' line with two lines:
     #define $LKEY_KICK 35
     #define $HKEY_KICK 36

B. Modify the 6 "data\group\kick*.txt" files as follows:
Replace 'key=$KEY_KICK' line with the following four lines:
     lokey=$LKEY_KICK
     hikey=$HKEY_KICK
     pitch_keycenter=$HKEY_KICK
     pitch_keytrack=0

Was able to answer my own question after a little more digging.
I'll share my solution here for anyone else looking to make a similar modification:
I. To play "SNR1" on both midi notes 38 and 40:
Modify the 7 "data\group\snare*.txt" files as follows
1. Comment ("//") all lines after 'key=$KEY_SNR2'
2. Copy the 4 lines after 'key=$KEY_SNR1' and paste after the 'key=$KEY_SNR2' line
II. To play the "KICK" drum on both midi notes 35 and 36:
A. Modify "data\keymap.txt", "User\Naked Drums TD-12 keymap.txt" and "User\Naked Drums GM keymap.txt" as follows:
Replace '#define $KEY_KICK 36' line with two lines:
     #define $LKEY_KICK 35
     #define $HKEY_KICK 36

B. Modify the 6 "data\group\kick*.txt" files as follows:
Replace 'key=$KEY_KICK' line with the following four lines:
     lokey=$LKEY_KICK
     hikey=$HKEY_KICK
     pitch_keycenter=$HKEY_KICK
     pitch_keytrack=0

Hi, just saw this closed issue. its a good workaround!
I just add an information, when using pitch_keytrack=0, then you no more need to put pitch_keycenter=N.
Just a bit cleaner :)


feat(java): introduce spotless-maven-plugin

In Java CI, when running mvn clean install, it will automatically invoke spotless-check phase.
If there is any code style issue, it will break the mvn command. The CI will fail.
Users or developers can use mvn spotless:apply to format code automatically based on Google Java Code style with a unified Spec.
In addition, we could also introduce git pre-commit-hook to make developers run this command before submitting a PR.
I believe, by introducing this plugin, the community will have a pleasing codebase. However, yes, it's unfortunately we need a one-shot reformat to initialize it.
cc @LuQQiu


rotatingsquare.py

Hi,
I have added rotatingsquare.py to the hooman/demos folder.

Hey, looks good, but it runs really fast on my machine that everything is a blur, could you limit the fps, you can do this by using hapi.clock.tick(fps) in the game loop

@TheBigKahuna353 Thanks for your feedback and merging the pull request.


Create Game is spammable and confusing

When "Create Game" is clicked on the front page, a new game is immediately created. This is before the "Join Game" button is pressed in the popup menu, which is in turn before the second "Join Game" button below the username entry on the next screen, which is in turn before the "Start Game" button that appears once cards have been selected.
From the user perspective "game creation" (i.e. the ability for other players to join the game) should only happen once "Start Game" has been pressed: the game ID should not be shown (other than in the URL) before "Start Game". This will prevent accidental creation of a bunch of games by spamming the "Create Game" button, and avoid possible confusion: it looks like right now another player can come along and join the game before the creator finishes and hijack it.

You are correct. A user who is NOT the original creator of the game can join the game first and select the cards instead. We can eliminate the showing of the gameID on the splash page no problem. We can try to eliminate the option of allowing a different user to create the deck than the original creator. We will have to figure it out though. It might entail having to use cookies. How do you feel about cookies being used?

I'm fine with cookies if necessary. It would be better without, but sessions may be necessary here.

What we've figured out so far is to eliminate the drop down box on the create game button and just have that button immediately take the creator to the game page to pick cards. Also, we will not show the game ID on the page until after the cards have been picked. Kind of a withholding information approach to not allowing other users to join until it is time. Does this sound good? Or do. you think we need a more robust way of preventing non-creators from joining too soon?

Sounds good. I'm not sure I'd even have that card pick page have the game id in the URL; just literally don't create the game until the creator is done picking cards and hits Start Game. Then take them to the game play page with the game id in the URL and show the game ID on that page as you do now.

Okay, let me see if we can get that to work. I have to do other homework today, so I should be able to tackle it this weekend. I can't make any promises, but we'll see what we can do.


Fiji device not detected, machine hangs with ROCm 1.4

System Ubuntu 16.04
Hardware: CPU AMD FX-8350, GPU: Fiji (Fury Nano)
Installed:  rocm opencl-rocm opencl-rocm-dev
Rebooted with the new kernel, after which I can't get any devices detected nor run any HIP, hsa, or OpenCL code.

bit_extract HIP sample gives:

### HCC STATUS_CHECK Error: HSA_STATUS_ERROR_OUT_OF_RESOURCES (0x1008) at file:/home/scchan/code/github/hcc-roc-1.4.x/hcc/lib/hsa/mcwamp_hsa.cpp line:2728
Aborted (core dumped)

stadard clinfo hangs, the one provided by rocm outputs this:

Number of platforms:				 1
  Platform Profile:				 FULL_PROFILE
  Platform Version:				 OpenCL 2.0 AMD-APP (2300.5)
  Platform Name:				 AMD Accelerated Parallel Processing
  Platform Vendor:				 Advanced Micro Devices, Inc.
  Platform Extensions:				 cl_khr_icd cl_amd_event_callback cl_amd_offline_devices

  Platform Name:				 AMD Accelerated Parallel Processing
ERROR: clGetDeviceIDs(-1)

kern.log contains the following (after running clinfo)

kfd: qcm fence wait loop timeout expired
kfd: unmapping queues failed.
kfd: the cp might be in an unrecoverable state due to an unsuccessful queues preemption<4>[ 3721.447737] amdkfd: Resetting wave fronts on dev ffff8800bf91bc00

This is often preceded by some NetworkManager stats printout. (Occasionally the machine hangs or does not respond over the network -- maybe related, maybe not.)

We do not support the AMD FX 8350 with GFX8 or newer GPU FIJI.  FIJI  use PCIe Atomics which are only in PCIe Gen3 CPU,  Intel Haswell, or newer and AMD new Rysen Processor.
We never tested it but W9100 or  Radeon 290 should work since they do not support PCIe atomics.
Greg
On Feb 23, 2017, at 5:51 PM, Szilárd Páll <notifications<EMAIL_ADDRESS>wrote:
System Ubuntu 16.04
Hardware: CPU AMD FX-8350, GPU: Fiji (Fury Nano)
Installed: rocm opencl-rocm opencl-rocm-dev
Rebooted with the new kernel, after which I can't get any devices detected nor run any HIP, hsa, or OpenCL code.

bit_extract HIP sample gives:

HCC STATUS_CHECK Error: HSA_STATUS_ERROR_OUT_OF_RESOURCES (0x1008) at file:/home/scchan/code/github/hcc-roc-1.4.x/hcc/lib/hsa/mcwamp_hsa.cpp line:2728
Aborted (core dumped)

stadard clinfo hangs, the one provided by rocm outputs this:

Number of platforms:                             1
Platform Profile:                              FULL_PROFILE
Platform Version:                              OpenCL 2.0 AMD-APP (2300.5)
Platform Name:                                 AMD Accelerated Parallel Processing
Platform Vendor:                               Advanced Micro Devices, Inc.
Platform Extensions:                           cl_khr_icd cl_amd_event_callback cl_amd_offline_devices
Platform Name:                                 AMD Accelerated Parallel Processing
ERROR: clGetDeviceIDs(-1)

kern.log contains the following (after running clinfo)

kfd: qcm fence wait loop timeout expired
kfd: unmapping queues failed.
kfd: the cp might be in an unrecoverable state due to an unsuccessful queues preemption<4>[ 3721.447737] amdkfd: Resetting wave fronts on dev ffff8800bf91bc00
This is preceded by the NetworkManager stats. (Occasionally the machine hangs or does not respond over the network -- maybe related, maybe not.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/RadeonOpenCompute/ROCm/issues/89, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8DuR3AJbPWpEaN4plPjETa0V0az7Wbks5rfhuagaJpZM4MKp4W.

Thanks for the quick reply! It would be nice if the runtime somehow warned me about this rather than behaving all weird.
I've now plugged the card into a HSW-E machine and will try again later.

We are working on tool to look and see if you support  PCIe atomics and warn you,  We also see you have to put in on the right slot on Intel systems.
Greg
On Feb 23, 2017, at 6:32 PM, Szilárd Páll <notifications<EMAIL_ADDRESS>wrote:
Thanks for the quick reply! It would be nice if the runtime somehow warned me about this rather than behaving all weird.
I've now plugged the card into a HSW-E machine and will try again later.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/RadeonOpenCompute/ROCm/issues/89#issuecomment-282167124, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8DuYucRM3P2SM3aU2wTjiuNZszg0t-ks5rfiUJgaJpZM4MKp4W.

What does "right slot" mean? I'm using an Intel X99 motherboard now.
Do you have some documentation on what exactly is required and why? I can't imagine such limitations are beneficial without a reasonable fallback, but I might be wrong and I'm all for it if it e.g. allows leaner and faster driver implementation.

Seems to "work" -- sortof, so I'll close this and open new ones.


GPL-nnn Update jsonapi-resource or investigate alternatives

User story
We have been stuck on version 0.9.0 of jsonapi-resources for a while, this is mostly as upgrades are causing test failures.
Contributing factors:

Monkey patches to handle eager loading of necessary records in Api::V2::BaseResource app/resources/api/v2/base_resource.rb
Monkey patches to handle polymorphic relationships in config/initializers/patch_json_api_resource.rb

More information on previous depfu attempts to update resources:
https://github.com/sanger/sequencescape/pull/2149
https://github.com/sanger/sequencescape/pull/2035
Attempts to fix earlier 0.9.1 branches (With some success, although the build now appears broken)
https://github.com/JamesGlover/sequencescape/tree/depfu/update/jsonapi-resources-0.9.5
(Inclusions weren't working quite right for relationships, but didn't have a proper chance to investigate more fully.)
Version 0.10 makes some nice improvements, but seems to break has_many 'polymorphic' associations. In particular I was seeing issues with plate relationships. This appears to be because its assuming your polymorphism relates to joins onto different tables, rather than sti. As a result its expecting an association_type column somewhere for building up the relationship data (a combination of type and id). It also seems to expect to see this on labware, which is a little odd. I've made a little progress into fixing some aspects of this, but it does raise questions if this is the right gem. (I had thought it was abandoned, but instead it seems to just get updates somewhat sporadically)
Unfortunately heavy use of sti and polymorphic associations do limit our options a little.
Who are the primary contacts for this story
e.g. John S (don't include surnames in public repos)
Acceptance criteria
To be considered successful the solution must allow:

[ ] add a list of acceptance criteria here
[ ] ...

Dependencies
This story is blocked by the following dependencies:

#<issue_no.>
sanger/#<issue_no.>

Additional context
Add any other context or screenshots about the feature request here.

I'll push up the 0.10 experimental branch once I've finished running down my current avenue of investigation.

https://github.com/stas/jsonapi.rb

Hmm, looks like the performance issues I refer to in https://github.com/sanger/sequencescape/pull/2149 might exist anyway. Briefly:

We patched in the ability to supply default_includes to automatically load associated records that appear inline (eg. uuid)

This works when retrieving a record directly

However something about loading associations seems to nuke this.

As best I can tell, is we do load the associated record, and their resources from the database

However when JSON-API resource attempts to render the associated objects, it does its own fetching from the database, and these records don't have the associations pre-loaded, so we fetch them all again.

Had another crack with json-api-resources 0.10.5. Almost got there with a couple of monkey patches, but running into some major issues with relationships and STI. This branch has the work, along with a couple of added tests to catch edge cases:
https://github.com/sanger/sequencescape/tree/json_api_update_v2
Things that didn't work:

Making the relationships polymorphic resulted in an undefined method polymorphic_type' for #<JSONAPI::Relationship::ToMany:0x00007fe0b7a23ab0` which suggests that polymoprhic has_many realtionships are a little broken. But a glance at the code indicates that this probably isn't what we want anyway, and is more geared up to handle database level polymorprhism rather than STI.
Removing class name and defining abstract resources tends to result in a cascade of a few minor issued, but essentially results in relationships names 'parents' rather than 'labware' which is probably even worse.

I think the trick will be to pull back the sti_type columns, in the pluck for STI relationships and use them,. but that's getting a little larger than I'd like for a monkey pathc.
Related issues:
= Monkey patched
https://github.com/cerebris/jsonapi-resources/issues/1371
https://github.com/cerebris/jsonapi-resources/issues/1369
= Outstanding
https://github.com/cerebris/jsonapi-resources/issues/1369 # Although we're more concerned with the relation objects than the endpoints, I supsect any fix will cover both
This PR might help?
https://github.com/cerebris/jsonapi-resources/issues/1369

Looked at https://github.com/stas/jsonapi.rb in context of unified Warehouse:

It is mostly just serialization, deserialization with a few helpers to handle parsing json api arguments
There doesn't seem to be any handling of eager-loading off the shelf, so we'd have to roll our own
Fewer overall users based on stars and forks
Last major change was 6 months ago, with minor readme updates 2 months ago. Slightly less active then json-api resources
https://github.com/jsonapi-serializer/jsonapi-serializer which it is based on is more active, but still overall less so than json-api resources

So not sure I'd suggest a switch, although the simplicity and lack of magic is nice. Also haven't really battle tested it yet against more complicated setup, so its possible that it will run into the same kinds of issues with STI/polymorphisms
Had a bit of a poke around at other alternatives, but nothing appears to be in great health.

This is blocking Rails 6.1 release, so increases in importance

Looked into this a bit more, and it turns out there is an official fix underway, although it hasn't move much for a while:
https://github.com/cerebris/jsonapi-resources/commits/sti_v0-10
There's a minor issue with the approach I can see here in that it uses a hard-coded type column, whereas we have overridden the rails defaults (for reasons I was told once about 10 years ago, and have since forgotten). I've popped a comment to that effect on the PR, but I think if there was movement on this (without a fix) it would be worth renaming our columns to the Rails defaults. (Assuming the 10 year old reasons aren't still valid)


Codegen for Processor interface

Parse file descriptor set proto file into a Model and then use text/template to create processor.go files.
The tool takes one input (FDS) and emits out one output file(processor.go). The FDS needs to have exactly one file that has template definition (two well known options and Type and Constructor messages).
Below is the description on how the code is structured.
Code has 3 components:

Data : text/template to emit out. tools/codegen/proc_interface_gen/template/*

Model Generator that parses the FDS into a Model object. (tools/codegen/model_generator/*)
Which has two phases, parsing and model generation.

Parsing is done by the tools/codegen/model_generator/parser.go. Code is this file is 90% + stolen from protoc-gen-go, it does the work of parsing the FDS into a simple cross referable items tree.
model generation is done by tools/codegen/model_generator/mode.go. It loads the intermediate model created by parser.go and simply populates the fields inside Model Struct.

Proc Interface Generator. This is done by tools/codegen/proc_interface_gen/*.go
This uses the model generator to create a Model struct and then runs the go template engine on a specific template file.

Really sorry for the large PR.
Side notes:

Tests are baseline based tests. Input is a proto file and output is compared with the checked in baseline file.
Test inside tools/codegen/proc_interface_gen/ verifies the generated code is correct and also compiles it with *.pb.go file to ensure that it compiles fine.
As mentioned, model_generator/parser.go file is mostly a copy from protoc-gen-go tool, I have not directly tested it. It is indirectly tested when testing model_test.go and generator_test.go.

There are many todos:

Does not work with Bazel. Mainly because the tests are doing crazy thing of running protoc process to generate the input FIle Desc Set for the code. This fall apart with Bazel. Talked to Doug and discussed that it can be handled later.
Some things are not supported in the mytemplate.proto. Comprehensive TODO's list mentioned inside tools/codegen/model_generator/parser.go.

This change is

@geeknoid : Sorry, not sure how I missed your comment about tests for parser.go. I have already emailed the folks in google who have contributed to protoc-gen-go to find out the tests. I don't see any obvious test files that directory. Also inquired if there is a clearer way to reuse their code base, since what we are doing is not ideal and possibly fragile. Will need to wait for their reply, until then we will have to stick with the parser.go without direct unit tests.

@douglas-reid @mandarjog @ZackButcher
Everybody happy with this? If so, let's get it approved and checked in.

Yeah, right now there are several presubmit errors according to Jenkins.
On Thu, Jun 15, 2017 at 9:22 AM, Douglas Reid<EMAIL_ADDRESS>wrote:

@douglas-reid commented on this pull request.
In tools/codegen/pkg/proc_interface_gen/generator.go
https://github.com/istio/mixer/pull/808#discussion_r122247879:

+import (

"io/ioutil"
"os"
"text/template"

"fmt"

"github.com/golang/protobuf/proto"
"github.com/golang/protobuf/protoc-gen-go/descriptor"
"istio.io/mixer/tools/codegen/pkg/modelgen"
"errors"
"bytes"
+)

+type Generator struct {
are we missing comments on the exported types and methods (and at the
package level) ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/mixer/pull/808#pullrequestreview-44348314, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVucHQZut6p9V1R3StqoCGJzi1e27lB4ks5sEVpdgaJpZM4N00Aw
.

@ZackButcher @mandarjog @douglas-reid @geeknoid Any idea why jenkin is failing for this PR, seems like everything has passed successfully
https://testing.istio.io/job/mixer/job/presubmit/1067/console

@sebastienvas That's puzzling. The word "error" only shows up once in the log, when the script fails right at the end. Everything seems to have been going great until the script stopped.

Jenkins job mixer/presubmit passed

Thanks to @sebastienvas for helping point out the issue. The codecov script was not able to run the codegen test (unable to find protoc). I added a an exclusion for the test in the codecov script and a TODO to remove the exclusion once the tests are able to run via bazel.

Jenkins job mixer/pilot-regression passed

Jenkins job mixer/presubmit passed

Jenkins job mixer/e2e-smoketest passed

Jenkins job mixer/pilot-regression passed

Jenkins job mixer/e2e-smoketest passed


Create a notification if the template does not exist

If the template does not exist in the configured template directory then no alert is raised when you push to JIRA.

Are these the templates you are referring to?
https://github.com/DefectDojo/django-DefectDojo/tree/master/dojo/templates/issue-trackers

Yes @Maffooch  - the error came about because we created a folder but didn't realise the name of the file is hard-coded in DefectDojo. We saw an error in the logs but no notification...


pivotvtab fails on M1 Pro MacBook

The pivotvtab extenstion fails on M1 Pro MacBook.

The macos version fails on M1 Pro MacBook with the error (exact copy and paste below)
Error: dlopen(../../bin/sqlite-exts/pivotvtab.dylib, 0x000A): tried: '../../bin/sqlite-exts/pivotvtab.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS../../bin/sqlite-exts/pivotvtab.dylib' (no such file), '/usr/lib/../../bin/sqlite-exts/pivotvtab.dylib' (no

Yeah, it wasn't compiled for M1. You can re-download it now, and it will work (after you overcome the macOS refusal to launch it due to security reasons).
Be aware, though, that this extension is buggy and may fail with 'segmentation fault' errors.

yes, you are correct. Sadly I got the segmentation fault :(

If the number of years in your table is limited (say, five years like in your example)

Unfortunately no :(. As I mentioned in  my message on the SQLite forums, I have 173 years, and over time this will only grow. I have to be able to do this programmatically.

Then I'd construct the query dynamically and use Python or another language to execute it.

You even can construct the query from SQL like this:
with years as (
  select distinct(y) as year
  from t
),
lines as (
  select 'select j' as cond
  union all
  select ',count(y) filter (where y = ' || year || ') as "' || year || '" '
  from years
  union all
  select 'from t group by j;'
)
select group_concat(cond, '') as v
from lines;

Result:
select j,count(y) filter (where y = 1990) as "1990" ,count(y) filter (where y = 1991) as "1991" ,count(y) filter (where y = 1992) as "1992" ,count(y) filter (where y = 1994) as "1994" ,count(y) filter (where y = 1993) as "1993" from t group by j;

But then you'd have to execute this constructed query, and SQLite can't do that, to my knowledge.

yea, I will try to do it programmatically as you suggested (I use nodejs and it is easy for me to construct the query there). Not really what I desired as I wanted a db-solution (rather than a program solution) that would update the count frequency table via triggers, but hey, as long as it works :)
Thanks for your help.
By the way, thanks also for all these wonderful extensions.

ha ha, I spoke too soon. I built the query but got the following error
SqliteError: too many columns in result set

I guess I just have to look at some other way of solving this.

too many columns in result set

That's strange, I was pretty sure that max column limit is 2000 by default.

It was my error, I made a mistake. Fixed that and it is working now. Now I have to figure out how to automate this, but this is a great help. Many thanks.

Ah! I've figured it out. We can execute a dynamic query using the eval function from the define extension.
For example, we can create a view (or table) named vt, which will return the required pivoted data:
with years as (
  select distinct(y) as year
  from t
),
lines as (
  select 'create view vt as ' as part
  union all
  select 'select j '
  union all
  select ',count(y) filter (where y = ' || year || ') as "' || year || '" '
  from years
  union all
  select 'from t group by j;'
)
select eval(group_concat(part, ''))
from lines;

And work with it afterwards:
select * from vt;

┌─────┬──────┬──────┬──────┬──────┬──────┐
│  j  │ 1990 │ 1991 │ 1992 │ 1994 │ 1993 │
├─────┼──────┼──────┼──────┼──────┼──────┤
│ bar │ 2    │ 0    │ 0    │ 0    │ 1    │
│ baz │ 1    │ 1    │ 1    │ 0    │ 0    │
│ foo │ 1    │ 3    │ 1    │ 1    │ 0    │
└─────┴──────┴──────┴──────┴──────┴──────┘


IgnoreAuthenticationIfAllowAnonymous in HandleAuthenticateAsync specifically doesn't ignore

Code in question:
https://github.com/mihirdilip/aspnetcore-authentication-basic/blob/ce690a6c2c349b680de7364fda52b616a0951fc7/src/AspNetCore.Authentication.Basic/BasicHandler.cs#L54-L58
Problem:
The log statement at line 56 breaks the promise to ignore authentication if the endpoint is annotated with [AllowAnonymous].
Expected behavior:
When querying an endpoint annotated with [AllowAnonymous], authentication logic should be ignored.
Actual behavior:
When querying an endpoint annotated with [AllowAnonymous], two lines of log output are produced, stating that nothing is going on. (logspam)
Example:

info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.
info: AspNetCore.Authentication.Basic.BasicHandler[0]
No 'Authorization' header found in the request.

Pull request:
#8

Hi @hcshmk, your request is updated with 6.0.1 release just published. Sorry it took a while as I was waiting for .net6.0 release and then got busy with other stuff.


A new repo for style.scss

Create a repo for style.scss so it can be properly versioned.

Closing this as it won't be needed when #8 is done.


Improve Prost performance

Prost support will land in https://github.com/tikv/tikv/pull/5379. Currently, performance is a little worse with Prost than rust-protobuf. From profiling, there is no obvious cause for this. I suspect there are indirect effects (for example, Prost always stores message fields inline, whereas rust-protobuf uses indirection, therefore Prost objects are larger and might be causing poor cache behaviour or simply take more time to copy). Some ideas I've already tried (and might be worth pushing on) are using Bytes and de-prioritising 32bit processors.
Some notes:

make sure to use master, not 0.5 for testing - there are some significant optimisations in the master branch
make sure to use jemalloc if profiling/benching - the allocator used makes a huge difference
In terms of direct costs, only decoding is significant (you can ignore encoding).
rust-proto computes sizes ahead of time, caches them and reuses them. Prost recalculates sizes as needed. I haven't seen this having an effect in profiles, but theoretically could cause a difference with deeply nested messages.
It would be nice to know the common message sizes and structures we're dealing with, since different messages have very different performance characteristics.
Message objects are used throughout TiKV, so I'm not sure how to even start investigating indirect effects.

make sure to use jemalloc if profiling/benching - the allocator used makes a huge difference

How about mimalloc and tcmalloc? do they provide a better result than jemalloc?

How about mimalloc and tcmalloc? do they provide a better result than jemalloc?

I haven't tried mimalloc (but I think others have and it wasn't better than jemalloc). tcmalloc was worse than jemalloc, but is useful for the tools (leak detection, etc.).


Trick to skip chunk revalidation on restart?

I saw somewhere that there is a way to get Cardano Node to skip revalidation on restart..
2024-03-17 19:47:18 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:18.36 UTC] Validating chunk no. 2995 out of 5514. Progress: 54.31%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.21 UTC] Validated chunk no. 2995 out of 5514. Progress: 54.32%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.21 UTC] Validating chunk no. 2996 out of 5514. Progress: 54.32%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.73 UTC] Validated chunk no. 2996 out of 5514. Progress: 54.34%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.73 UTC] Validating chunk no. 2997 out of 5514. Progress: 54.34%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.10 UTC] Validated chunk no. 2997 out of 5514. Progress: 54.36%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.10 UTC] Validating chunk no. 2998 out of 5514. Progress: 54.36%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.63 UTC] Validated chunk no. 2998 out of 5514. Progress: 54.38%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.63 UTC] Validating chunk no. 2999 out of 5514. Progress: 54.38%
2024-03-17 19:47:21 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:21.28 UTC] Validated chunk no. 2999 out of 5514. Progress: 54.40%
2024-03-17 19:47:21 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:21.28 UTC] Validating chunk no. 3000 out of 5514. Progress: 54.40%

This stuff ^
I can't for the life of me find that original article/documentation however. Does anyone know how to do it? I'm running Cardano Node in Docker and it's super annoying to have to wait for it to finish before the node finishes.
Thank you!

That's not a good idea for integrity.
What's possibly happening (especially on mainnet) is the application isn't shutting down in the default 30s that Docker gives as a grace period. Increasing this timeout will allow the node to shutdown cleanly.

I saw somewhere that there is a way to get Cardano Node to skip revalidation on restart..
2024-03-17 19:47:18 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:18.36 UTC] Validating chunk no. 2995 out of 5514. Progress: 54.31%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.21 UTC] Validated chunk no. 2995 out of 5514. Progress: 54.32%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.21 UTC] Validating chunk no. 2996 out of 5514. Progress: 54.32%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.73 UTC] Validated chunk no. 2996 out of 5514. Progress: 54.34%
2024-03-17 19:47:19 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:19.73 UTC] Validating chunk no. 2997 out of 5514. Progress: 54.34%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.10 UTC] Validated chunk no. 2997 out of 5514. Progress: 54.36%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.10 UTC] Validating chunk no. 2998 out of 5514. Progress: 54.36%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.63 UTC] Validated chunk no. 2998 out of 5514. Progress: 54.38%
2024-03-17 19:47:20 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:20.63 UTC] Validating chunk no. 2999 out of 5514. Progress: 54.38%
2024-03-17 19:47:21 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:21.28 UTC] Validated chunk no. 2999 out of 5514. Progress: 54.40%
2024-03-17 19:47:21 [7d750c31:cardano.node.ChainDB:Info:5] [2024-03-17 23:47:21.28 UTC] Validating chunk no. 3000 out of 5514. Progress: 54.40%

This stuff ^
I can't for the life of me find that original article/documentation however. Does anyone know how to do it? I'm running Cardano Node in Docker and it's super annoying to have to wait for it to finish before the node finishes.
Thank you!

u8ohبرگشت jó Kom
Dyi8D$th@gh

cirji9@3


Custom ImageView displaying incorrectly

I've made a custom imageView and set it's frame to 0,0,150,150 since you require that the frame be set with the Custom enum tag. However, when the overlay view pops up, doesn't display correctly at all, and I'm not sure where in the documentation there is information on how to display custom images in the OverlayView. How can I display a custom image with a title using MRProgressOverlayView?

It should keep the width and height of the custom view. As seen in #103, there is a bug in the layout code which causes that a custom mode view's height is enforced to be the same as it's height. But this shouldn't have mattered for your concrete case, you described here.


Add UI support for displaying cluster badges next to cluster name

#4934
This PR adds ui/ux functionality in support of PR #4933

@neillsom Merging on your behalf


Timestamp field

from datetime import datetime

from odmantic import Model
from pydantic import EmailStr

class Subscriber(Model):
    email: EmailStr
    subscribed_at: date = datetime.utcnow()

Trying to make a timestamp field, but I get the error: Value not declarable with JSON Schema

You’ve defined subscribe_at as a “date” field, and then are setting its default value to datetime.
Try subscribed_at: datetime = datetime.utcnow()
On 3 Nov 2020, at 02:12, Alejandro Valdevila Pérez<EMAIL_ADDRESS>wrote:

from datetime import datetime
from odmantic import Model
from pydantic import EmailStr
class Subscriber(Model):
email: EmailStr
subscribed_at: date = datetime.utcnow()
Trying to make a timestamp field, but I get the error: Value not declarable with JSON Schema
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/art049/odmantic/issues/36, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM5JK3MTXGQIYPE4ULQAY23SN5RG5ANCNFSM4TIF2LQA.

Sorry my bad, I actually defined it as a datetime 😅


Helper macro for writing concrete effect signatures

One of the syntactic compromises of fused-effects compared to @joshvera/effects is that details about the carriers leak into concrete Eff types:
type Something
   = Eff (StateC [Foo]
   ( Eff (ErrorC SomeException
   ( Eff VoidC))))

We could make a Template Haskell splice that could generate the above from some shorthand notation like this:
type Something = [effects | [State [Foo], Error SomeException] |]

I think you don't need Template Haskell for this but the same can be accomplished by using type families and data kinds:
type family StackEff (members :: [(* -> *) -> * -> *]) where
  StackEff '[] = Eff VoidC
  StackEff (m ': ms) = Eff (m (StackEff ms))

type family StackEffM (members :: [(* -> *) -> * -> *]) m where
  StackEffM '[] m' = Eff (LiftC m')
  StackEffM (m ': ms) m' = Eff (m (StackEffM ms m'))

-- 'Something' from @patrickt above
type Something = StackEff [StateC [Foo], ErrorC SomeException]

I’d argue that this isn’t an inappropriate leak of details. Your selection of a handler nails the computation down to a specific carrier, and thence semantics; that’s something consumers need to know about.
Further, this sort of specification is only necessary when you’re actually handling effects. In all other cases you can use Member constraints to abstract a computation over the carrier.
Finally, there isn’t in general a strong match between an effect and one specifically “blessed” carrier. Take Trace, for example.
If we want to be able to change the definitions or names of carriers without affecting consumers, we can always define type synonyms for them. But newtypes are cheap, so we won’t gain much by doing so in my opinion.

@patrickt: I’m going to close this out given the above, but feel free to reopen if necessary.

@robrix Very fair! And @JaSpa’s example of how to infer it is lovely. Let’s keep this closed.


Some detail of RTL8372 firmware & Any progress on reverse engineering the UID algorithm?

Hi.
A week ago, @FanFansfan and I started some exploration on some RTL8372 firmware, and I found your repo yesterday. See our discussion (mainly) here and here (a little bit) (sry for zh-cn, pls use translate).
In short:

@FanFansfan used his logic analyzer, captured the SPI flash's signals in both normal boot and UID check fail boot
The RTL8372 has a DW8051 core running at 125MHz, uses code banking to support SPI flash, the bank size is 48K
The "serial number" is stored in the flash's OTP area, a 64bit code, in the formation of 16 bytes hex string
The UID algorithm can be written as: F(<First 32bit of Flash UID>, <String "59494F4754fff00" (0x0DD55F @SWTG124AS-v2.bin)>, <String "59494F4754fff01" (0x0DD57F @SWTG124AS-v2.bin)>) = the OTP content
We didn't figure out the actual algorithm of the "serial number", but found the JZ instruction (yes, it's what you think) of comparing the output of the algorithm and the OTP content
That algorithm should be the same in different brand switches -- the flash contents and the strings are the same, as it should be part of the Realtek SDK
We also found the checksum comparison JZ instruction (could bypass the firmware integrity check)
We got stuck on the "reset button" issue -- because of different hardware variations, the "reset factory default" pin is pulled down in some hardware and will cause reset loop then; We could find the pin theoretically but in exchange we could possibly lose some function, e.g. one of the 10G port
The RTL8372N chip boots the firmware also
There are four testpoints in one group on one board but it seems not the JTAG. The DW8051 manual also claims it not supporting JTAG
Reverse engineering an 8051 with code banking and without JTAG is f**king traumatic

I don't know if it's worth spending time on reverse engineering the algorithm. Making an FPGA MITM module on the SPI bus may better than that.
Any suggestions? And, is there someone experienced on 8051 RE watching here?

Any suggestions? And, is there someone experienced on 8051 RE watching here?

Sorry for this late reply. Oddly, rather than github informing me of pending open issues, it was a reply on servethehome.com that got my attention. Anyway, I will allocate time this weekend to take a look at these developments and try to gather any new insight.

Before I delve into the code, I can confirm that same reset button boot loop is experienced with the SWTG118AS v1.0 and I wrote a little explanation at https://forums.servethehome.com/index.php?threads/horaco-2-5gbe-managed-switch-8-x-2-5gbe-1-10gb-sfp.41571/post-428606

@libc0607 @FanFansfan It's AES encryption.
The sbox in bytes is at 0xDD433..0xDD532 and the rcon in dwords is at 0xDD534..0xDD55C.
I haven't dug into it just yet but my assumption is 59494F4754fff00\0 and 59494F4754fff01\0 are the 128bit keys.

Went through the updates in the forum thread, cool. Just found an encryption 101 lecture to follow up 😂
You can use FanFansfan's capture as a reference too. I've exported the logic analyzer capture in a more readable format, in the attachment. The parser had been patched to support CMD 4B, so just search for RDUID.
The flash's UID in these captures is what he said in the Yakigani issue, 10 09 3F 30 D4 50 84 22 (64-bit), and the OTP content is 57 2d ad 0d 4f f6 c7 45 (hex char). Maybe that helps.
rst_auth_failed_full.zip
10s_auth_success_full.zip
hasivo-v1.9.zip
And I've noticed that it actually reads 33 bytes when reading the 59494F4754fff00.., not sure if it's a 256-bit key or something the xip cache did.
6467719,6144606428.00,00,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD55F, 33 bytes): 35 39 34 39 34 46 34 37 35 34 66 66 66 30 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 35
6467720,6144606556.00,00,,0D,,,Address: 0DD55F,

The flash's UID in these captures is what he said in the Yakigani issue, 10 09 3F 30 D4 50 84 22 (64-bit), and the OTP content is 57 2d ad 0d 4f f6 c7 45 (hex char). Maybe that helps.

I can confirm that on the two operational managed switches the UID starts with: 10 09 3F 30 D4 xx xx xx. The OTP value is the same (57 2D AD 0D 4F F6 C7 45). I wonder why the OTP has a size of 4096 (libc0607/Yakigani#1 (comment)) maybe further down is the rest of the data?

Maybe he had set the wrong size in the reading script?

Did some timing analysis on the LA captured data, @up-n-atom you're right it's AES-128. It reads the sbox data 10 rounds.
// Step 0.

// ~60us/read, 4 reads/grp, 10 grps

// 0.0

6479313,6146693036.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD463, 3 bytes): 04 c7 23

6479374,6146701452.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD463, 3 bytes): 04 c7 23

6479441,6146710828.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77

6479508,6146720076.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD499, 3 bytes): 33 85 45

// 0.1

6482303,6147321502.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B2, 3 bytes): d2 cd 0c

6482364,6147329918.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD468, 3 bytes): 96 05 9a

6482431,6147339294.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD48E, 2 bytes): 39 4a

6482497,6147348412.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD48A, 3 bytes): 5b 6a cb

// 0.2

6485291,6147949838.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD513, 3 bytes): e1 f8 98

6485352,6147958254.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD470, 3 bytes): 27 b2 75

6485419,6147967630.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD49F, 1 bytes): 50

6485484,6147976622.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B5, 3 bytes): 13 ec 5f

// 0.3

6488277,6148578688.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD456, 3 bytes): 26 36 3f

6488338,6148587104.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD439, 3 bytes): 6f c5 30

6488405,6148596480.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A8, 3 bytes): 9d 38 f5

6488472,6148605728.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E9, 3 bytes): 4e a9 6c

// 0.4

6491267,6149207282.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD492, 3 bytes): cf d0 ef

6491328,6149215698.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E0, 3 bytes): 95 e4 79

6491395,6149225072.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD481, 3 bytes): 2f 84 53

6491462,6149234320.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD47B, 3 bytes): 52 3b d6

// 0.5

6494257,6149836770.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD51D, 3 bytes): 87 e9 ce

6494318,6149845186.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD44D, 3 bytes): a2 af 9c

6494385,6149854562.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43C, 3 bytes): 01 67 2b

6494452,6149863810.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BB, 3 bytes): c4 a7 7e

// 0.6

6497246,6150471540.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD475, 3 bytes): 2c 1a 1b

6497307,6150479956.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD46F, 1 bytes): eb

6497372,6150489076.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4DB, 3 bytes): c2 d3 ac

6497439,6150498324.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD458, 3 bytes): 3f f7 cc

// 0.7

6500232,6151101286.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4FB, 3 bytes): e8 dd 74

6500293,6151109700.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F7, 3 bytes): 1c a6 b4

6500360,6151119076.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD47D, 3 bytes): d6 b3 29

6500427,6151128324.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD50D, 3 bytes): 57 b9 86

// 0.8

6503222,6151729878.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD476, 3 bytes): 1a 1b 6e

6503283,6151738294.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4AE, 2 bytes): 21 10

6503349,6151747542.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD44C, 3 bytes): d4 a2 af

6503416,6151756790.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD453, 3 bytes): b7 fd 93

// 0.9

6506211,6152359240.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4FE, 2 bytes): 1f 4b

6506271,6152367528.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD501, 3 bytes): 8b 8a 70

6506338,6152376904.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F1, 3 bytes): ae 08 ba

6506405,6152386150.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BC, 3 bytes): a7 7e 3d

// Step 1.

// ~200us/read, 16 reads

// 1.0

6516094,6154390040.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD437, 3 bytes): f2 6b 6f

6516299,6154420216.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43A, 3 bytes): c5 30 01

6516504,6154450390.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD437, 3 bytes): f2 6b 6f

6516709,6154480566.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD488, 3 bytes): fc b1 5b

6517029,6154529396.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43C, 3 bytes): 01 67 2b

6517234,6154559572.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD453, 3 bytes): b7 fd 93

6517439,6154589748.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD437, 3 bytes): f2 6b 6f

6517644,6154619922.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD489, 3 bytes): b1 5b 6a

6517964,6154668754.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD437, 3 bytes): f2 6b 6f

6518169,6154698928.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43A, 3 bytes): c5 30 01

6518374,6154729104.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD489, 3 bytes): b1 5b 6a

6518579,6154759280.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD436, 3 bytes): 7b f2 6b

6518899,6154808110.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77

6519104,6154838286.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43A, 3 bytes): c5 30 01

6519309,6154868460.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD492, 3 bytes): cf d0 ef

6519514,6154898636.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD463, 3 bytes): 04 c7 23

// 1.1

6536972,6157755018.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4EB, 3 bytes): 6c 56 f4

6537177,6157785192.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B3, 3 bytes): cd 0c 13

6537382,6157815368.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD464, 3 bytes): c7 23 c3

6537587,6157845544.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F0, 3 bytes): 7a ae 08

6537907,6157894374.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A9, 3 bytes): 38 f5 bc

6538112,6157924550.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E2, 3 bytes): 79 e7 c8

6538317,6157954724.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43F, 1 bytes): fe

6538520,6157984644.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD44D, 3 bytes): a2 af 9c

6538840,6158033474.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD49A, 3 bytes): 85 45 f9

6539045,6158063650.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43A, 3 bytes): c5 30 01

6539250,6158093826.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD520, 3 bytes): 55 28 df

6539455,6158124000.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD446, 3 bytes): 7d fa 59

6539775,6158172832.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43C, 3 bytes): 01 67 2b

6539980,6158203006.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD459, 3 bytes): f7 cc 34

6540185,6158233182.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B7, 3 bytes): 5f 97 44

6540390,6158263358.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD438, 3 bytes): 6b 6f c5

// 1.2

6557722,6161103002.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4C0, 3 bytes): 5d 19 73

6557927,6161133178.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77

6558132,6161163354.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD502, 3 bytes): 8a 70 3e

6558337,6161193528.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D7, 3 bytes): 49 06 24

6558657,6161242360.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D4, 3 bytes): 32 3a 0a

6558862,6161272534.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4AF, 1 bytes): 10

6559065,6161302454.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD497, 3 bytes): 43 4d 33

6559270,6161332630.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD514, 3 bytes): f8 98 11

6559590,6161381460.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD49F, 1 bytes): 50

6559793,6161411380.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4FA, 3 bytes): c6 e8 dd

6559998,6161441556.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B1, 3 bytes): f3 d2 cd

6560203,6161471730.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD442, 3 bytes): 76 ca 82

6560523,6161520562.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD452, 3 bytes): c0 b7 fd

6560728,6161550736.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D4, 3 bytes): 32 3a 0a

6560933,6161580912.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4EA, 3 bytes): a9 6c 56

6561138,6161611088.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D4, 3 bytes): 32 3a 0a

// 1.3

6578470,6164446124.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD481, 3 bytes): 2f 84 53

6578675,6164476300.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD487, 3 bytes): 20 fc b1

6578880,6164506476.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD47D, 3 bytes): d6 b3 29

6579085,6164536650.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD450, 3 bytes): a4 72 c0

6579405,6164585482.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD500, 3 bytes): bd 8b 8a

6579610,6164615656.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD516, 3 bytes): 11 69 d9

6579815,6164645832.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD493, 3 bytes): d0 ef aa

6580020,6164676008.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD529, 3 bytes): 42 68 41

6580340,6164724838.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD50B, 3 bytes): 61 35 57

6580545,6164755014.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D7, 3 bytes): 49 06 24

6580750,6164785188.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F2, 3 bytes): 08 ba 78

6580955,6164815364.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43D, 3 bytes): 67 2b fe

6581275,6164864194.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD455, 3 bytes): 93 26 36

6581480,6164894370.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD458, 3 bytes): 3f f7 cc

6581685,6164924546.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD483, 3 bytes): 53 d1 00

6581890,6164954720.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD446, 3 bytes): 7d fa 59

// 1.4

6599180,6167789054.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD466, 3 bytes): c3 18 96

6599385,6167819230.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD448, 3 bytes): 59 47 f0

6599590,6167849406.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD504, 3 bytes): 3e b5 66

6599795,6167879580.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD510, 3 bytes): c1 1d 9e

6600115,6167928412.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BE, 2 bytes): 3d 64

6600319,6167958458.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD451, 3 bytes): 72 c0 b7

6600524,6167988634.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E5, 3 bytes): 37 6d 8d

6600729,6168018810.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD445, 3 bytes): c9 7d fa

6601049,6168067640.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43D, 3 bytes): 67 2b fe

6601254,6168097816.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77

6601459,6168127990.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4EF, 1 bytes): 65

6601662,6168157910.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD506, 3 bytes): 66 48 03

6601982,6168206740.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D1, 3 bytes): 0b db e0

6602187,6168236916.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4FB, 3 bytes): e8 dd 74

6602392,6168267092.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43A, 3 bytes): c5 30 01

6602597,6168297266.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD51E, 2 bytes): e9 ce

// 1.5

6619949,6171140912.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A6, 3 bytes): 8f 92 9d

6620154,6171171088.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4EB, 3 bytes): 6c 56 f4

6620359,6171201262.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A6, 3 bytes): 8f 92 9d

6620564,6171231438.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD523, 3 bytes): 8c a1 89

6620884,6171280268.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD44A, 3 bytes): f0 ad d4

6621089,6171310444.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD492, 3 bytes): cf d0 ef

6621294,6171340620.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD476, 3 bytes): 1a 1b 6e

6621499,6171370794.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD464, 3 bytes): c7 23 c3

6621819,6171419626.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD50A, 3 bytes): 0e 61 35

6622024,6171449800.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D6, 3 bytes): 0a 49 06

6622229,6171479976.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E0, 3 bytes): 95 e4 79

6622434,6171510152.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A7, 3 bytes): 92 9d 38

6622754,6171558982.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD511, 3 bytes): 1d 9e e1

6622959,6171589158.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD503, 3 bytes): 70 3e b5

6623164,6171619332.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD493, 3 bytes): d0 ef aa

6623369,6171649508.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4D1, 3 bytes): 0b db e0

// 1.6

6640743,6174488898.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B5, 3 bytes): 13 ec 5f

6640948,6174519074.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD447, 3 bytes): fa 59 47

6641153,6174549248.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B7, 3 bytes): 5f 97 44

6641358,6174579424.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD52A, 3 bytes): 68 41 99

6641678,6174628254.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A4, 3 bytes): a3 40 8f

6641883,6174658430.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD528, 3 bytes): e6 42 68

6642088,6174688604.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD503, 3 bytes): 70 3e b5

6642293,6174718780.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD52E, 2 bytes): 0f b0

6642612,6174767484.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD514, 3 bytes): f8 98 11

6642817,6174797658.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD532, 3 bytes): 16 00 00

6643022,6174827834.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD515, 3 bytes): 98 11 69

6643227,6174858010.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD472, 3 bytes): 75 09 83

6643547,6174906840.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD48F, 1 bytes): 4a

6643750,6174936760.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD513, 3 bytes): e1 f8 98

6643955,6174966934.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD435, 3 bytes): 77 7b f2

6644160,6174997110.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD499, 3 bytes): 33 85 45

// 1.7

6661471,6177833812.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B6, 3 bytes): ec 5f 97

6661676,6177863986.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD445, 3 bytes): c9 7d fa

6661881,6177894162.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD47C, 3 bytes): 3b d6 b3

6662086,6177924338.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4C8, 3 bytes): 2a 90 88

6662406,6177973168.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4AE, 2 bytes): 21 10

6662610,6178003216.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD520, 3 bytes): 55 28 df

6662815,6178033390.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD46C, 3 bytes): 12 80 e2

6663020,6178063566.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E3, 3 bytes): e7 c8 37

6663340,6178112396.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F7, 3 bytes): 1c a6 b4

6663545,6178142572.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD493, 3 bytes): d0 ef aa

6663750,6178172748.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4AE, 2 bytes): 21 10

6663954,6178202794.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4ED, 3 bytes): f4 ea 65

6664274,6178251626.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BB, 3 bytes): c4 a7 7e

6664479,6178281800.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4FA, 3 bytes): c6 e8 dd

6664684,6178311976.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD460, 3 bytes): d8 31 15

6664889,6178342152.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4DC, 3 bytes): d3 ac 62

// 1.8

6682326,6181197252.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4CC, 3 bytes): ee b8 14

6682531,6181227428.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BD, 3 bytes): 7e 3d 64

6682736,6181257604.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD497, 3 bytes): 43 4d 33

6682941,6181287778.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD452, 3 bytes): c0 b7 fd

6683261,6181336610.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD508, 3 bytes): 03 f6 0e

6683466,6181366784.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD462, 3 bytes): 15 04 c7

6683671,6181396960.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4BA, 3 bytes): 17 c4 a7

6683876,6181427136.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4CB, 3 bytes): 46 ee b8

6684196,6181475966.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43F, 1 bytes): fe

6684399,6181505886.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD46B, 3 bytes): 07 12 80

6684604,6181536060.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD43D, 3 bytes): 67 2b fe

6684809,6181566236.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4EB, 3 bytes): 6c 56 f4

6685129,6181615066.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD447, 3 bytes): fa 59 47

6685334,6181645242.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4B7, 3 bytes): 5f 97 44

6685539,6181675418.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4A5, 3 bytes): 40 8f 92

6685744,6181705592.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD470, 3 bytes): 27 b2 75

// 1.9

6703021,6184533046.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD521, 3 bytes): 28 df 8c

6703226,6184563222.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77

6703431,6184593398.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD477, 3 bytes): 1b 6e 5a

6703636,6184623572.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD483, 3 bytes): 53 d1 00

6703956,6184672404.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD47B, 3 bytes): 52 3b d6

6704161,6184702578.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD450, 3 bytes): a4 72 c0

6704366,6184732754.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD434, 3 bytes): 7c 77 7b

6704571,6184762930.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD477, 3 bytes): 1b 6e 5a

6704891,6184811760.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD444, 3 bytes): 82 c9 7d

6705096,6184841936.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E1, 3 bytes): e4 79 e7

6705301,6184872110.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4E9, 3 bytes): 4e a9 6c

6705506,6184902286.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD4F6, 3 bytes): 2e 1c a6

6705826,6184951116.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD483, 3 bytes): 53 d1 00

6706031,6184981292.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD515, 3 bytes): 98 11 69

6706236,6185011468.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD497, 3 bytes): 43 4d 33

6706441,6185041642.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD494, 3 bytes): ef aa FB

Maybe he had set the wrong size in the reading script? @FanFansfan
You are right. The log (10s_auth_success_full) only reads 16B (4 x 4Bytes), so there is no more OTP data.

Thank you for the flash information.
No problem.

Doing some calculations.
Let's assume that the available byte in each flash read is only the first byte. I think the hardware is doing some "pre-fetch" job for 8051 so every read command reads 3 bytes, which is the longest possible instruction length of 8051.
// 0.0
6479313,6146693036.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD463, 3 bytes): 04 c7 23
6479374,6146701452.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD463, 3 bytes): 04 c7 23
6479441,6146710828.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD433, 3 bytes): 63 7c 77
6479508,6146720076.00,FF,,0B,,,Command: Fast read data (FAST/READ),Fast read data (addr 0DD499, 3 bytes): 33 85 45

From that we can calculate that the last 4 bytes of the 16-byte key is 66 30 30 00.
Assume the key is 59494F4754fff00\0.

Early lazy assessment by utilizing the key expansion code from https://goggleheadedhacker.com/blog/post/reversing-crypto-functions-aes#key-expansion and proxing the self.RCON and self.SBOX access to print offsets and the value.
Passing in 59494F4754fff00\0 as the 128-bit key produced the same results as your SPI log.
SBOX[ DD463 ] = 04
SBOX[ DD463 ] = 04
SBOX[ DD433 ] = 63
SBOX[ DD499 ] = 33

SBOX[ DD4B2 ] = d2
SBOX[ DD468 ] = 96
SBOX[ DD48E ] = 39
SBOX[ DD48A ] = 5b

SBOX[ DD513 ] = e1
SBOX[ DD470 ] = 27
SBOX[ DD49F ] = 50
SBOX[ DD4B5 ] = 13

SBOX[ DD456 ] = 26
SBOX[ DD439 ] = 6f
SBOX[ DD4A8 ] = 9d
SBOX[ DD4E9 ] = 4e

SBOX[ DD492 ] = cf
SBOX[ DD4E0 ] = 95
SBOX[ DD481 ] = 2f
SBOX[ DD47B ] = 52

SBOX[ DD51D ] = 87
SBOX[ DD44D ] = a2
SBOX[ DD43C ] = 01
SBOX[ DD4BB ] = c4

SBOX[ DD475 ] = 2c
SBOX[ DD46F ] = eb
SBOX[ DD4DB ] = c2
SBOX[ DD458 ] = 3f

SBOX[ DD4FB ] = e8
SBOX[ DD4F7 ] = 1c
SBOX[ DD47D ] = d6
SBOX[ DD50D ] = 57

SBOX[ DD476 ] = 1a
SBOX[ DD4AE ] = 21
SBOX[ DD44C ] = d4
SBOX[ DD453 ] = b7

SBOX[ DD4FE ] = 1f
SBOX[ DD501 ] = 8b
SBOX[ DD4F1 ] = ae
SBOX[ DD4BC ] = a7

I will do the same for the cipher later.

@libc0607
to produce the 1st half of the otp the plain text is the unique id in lower duplicated to produce 16 bytes ie. 10093f3010093f30
it will return the 16 byte encrypted result 574f9e5f 2df6199b adc7de76 0d45294c
every 4th byte is taken or column order to produce the 1st half of the OTP ie. 572dad0d

@libc0607
let me reword that because it was an implementation error
from Cryptodome.Cipher import AES

key = b'59494F4754fff00\0'
uid = b'10093f3010093f30'

cipher = AES.new(key, AES.MODE_ECB)

opt = cipher.encrypt(uid)

print(opt[:8].hex())

Good work

Amazing, now we know all the details of the crab firmware! Thanks for your great work!

concat it to itself

Ahh that's the combination I never wanted to try 😂I'd rather consider it a bug by Realtek 😂😂

I generated my own (for a different UID) OTG and uploaded it to the flash drive.
The switch works -)


Change Child Ordering

I'm not sure that's the right issue name.
I have a class with two static class members and I want to be able to swap their order in the source file.  I've poked around a bit and can't find a way to do so (I can identify when they're out of order, but can't change the fact).

Yes, that would be good. Basically a .setOrder(2) method.

This will be available in 0.95.0 (doing the release right now) for non-comma separated nodes. I will add support for comma separated nodes in the future. If you find something that doesn't have the ability to change order, please let me know and I will work on it. There's some custom scenarios that need to be handled sometimes.
Reasoning for setOrder instead of setChildIndex
I decided to go with .setOrder(...) over .setChildIndex(...) so that this feature is not a pain to use with comma separated nodes in the future. I'm thinking of the following:
// file.ts
function myFunc(p1: string, p2: string) {
}

// otherFile.ts (.getOrder() currently does not exist... same with setOrder on comma separated nodes)
const sourceFile = ast.getSourceFileOrThrow("file.ts");
const func = sourceFile.getFunctionOrThrow("myFunc");
const firstParam = func.getParameters()[0];
const secondParam = func.getParameters()[0];

firstParam.getChildIndex(); // 0
firstParam.getOrder(); // 0
secondParam.getChildIndex(); // 2, because of the comma
secondParam.getOrder(); // 1

firstParam.setOrder(secondParam.getOrder()); // will set the order of the first to 1


Kernel build issue

I'm running into an issue building my own kernel.  I'm on 26d6ba2a91e6384252bfea5e94c3364e7f8879f2 (latest master at time of writing).  The patches don't appear to be applying due to conflicts.
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/hdh0igwg2rj6zk6xmf8kdn7kzrv9i91h-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
applying patch /nix/store/mnlqwys9dxznjcvq4w3s0435s9ql8qv8-bridge-stp-helper.patch
patching file net/bridge/br_private.h
Hunk #1 succeeded at 51 with fuzz 2 (offset 12 lines).
applying patch /nix/store/mbz5gln1q4swlzmqs2399br98qjif9kn-request-key-helper.patch
patching file security/keys/request_key.c
Hunk #1 succeeded at 117 (offset 3 lines).
applying patch /nix/store/831w9jjwfspn3wc2h3mlks980v3zm2qz-6de0bb51929cd3ad4fa27b2a421a2af12e6468f5.patch
patching file drivers/gpu/drm/rp1/rp1-dpi/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-dpi/Kconfig.rej
patching file drivers/gpu/drm/rp1/rp1-dsi/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-dsi/Kconfig.rej
patching file drivers/gpu/drm/rp1/rp1-vec/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file drivers/gpu/drm/rp1/rp1-vec/Kconfig.rej

I've tried moving back some commits and trying out the cachix substituter.  When moving back I get an error with a missing nixpkgs (which I can see is later corrected), and the substituter doesn't seem to be picking anything up.  I think that might be due to the substituter only containing an older kernel?
So I'm thinking some potential avenues to try out:

Try an older commit but fix branch + fix the nixpkgs issue separately from kernel upgrades, then use the older kernel (I can do this, just haven't gotten to it yet).
We get a working, patched kernel uploaded.  I can supply my exact nix.conf when I'm back on my home network later this evening so we know I'm actually using the substituter.  Near as I can tell nix build will not just tell me.
See what's up with getting the kernel built at its current version.  I am building it from x86-linux but I would think this would make no difference when applying patches.
We reveal some idiocy on my part.  If history is an indicator of future behavior, this is the most likely of these :)

Thanks for your work on this!  I came across this wanting to build a completely ready Pi image (which was working back on the Pi 3s) and couldn't figure out how to do it via modern nixpkgs et. al.

Hey @LoganBarnett -- I'm happy to try to help. I would guess your kernel derivation is different for some reason. Can you share the output of:nix derivation show .#nixosConfigurations.<your config key>.config.boot.kernelPackages.kernel?

Thanks for getting back to me so quickly!  I'm having trouble reproducing it now.  I've made some adjustments to my follows for my inputs (I have a lot of inputs now), so I'm thinking maybe that's the cause.  My build hasn't completed but I believe it's getting well past the patching phase.
Let's close this for now and I can reopen (or ask to reopen) if I run into something I can minimally reproduce.  Thanks again!


Format the README

This PR fixes some README table formatting and prevents the code snippets from overflowing horizontally.

this one is still overflowing, the rest looks good.

@brayanjuls - addressed your comment.  Going to merge this one.  Thanks for taking a look.


remove quark limestone as create one looks better

https://github.com/PandaBoy444/Create.run/blob/fa294f42d956d02a4977b3437627496c640a917a/Client/scripts/crafting.zs#L7-L7

removed


MINOR: move connectorConfig to AbstractHerder

StandaloneHerder and DistributedHerder have identical implementations of
connectorConfig (apart from one line of logging). This commit moves the
common implementation of connectorConfig to AbstractHerder.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@ivanyu nice catching. Could you fix those conflicting files? I'd like to commit it :)

@chia7712 Thank you for your attention! Updated

retest this please


[ORA-1468] Refactor Stress-Test

Refactors the stress-test code.
While debugging #299 I found that the initializeNewWorkerAccount code was written in such a way that the outer for loop iterates through all workers that need initialization and the for loop returns when getting the account from the registry fails. That would be fine, except the stress testing code that prints errors can't distinguish between a failure case that is genuine and a failure case that is being used to end the loop, which causes the report at the end to report false positives. This led me to try to refactor that code, which snowballed into a PR that refactors the entire stress-test.
Things this code does:

Puts line breaks in on long lines, especially function declarations
Moves functions into their own files so not all of the code is in one humongous n_stress_blah.go file
Attempts to add meaningful comments to every function declaration
For the two important functions, workerReputerLoop and workerReputerCoordinationLoop, go through the function line by line and add comments at every concrete step taken with what that step is.
For the two important functions, take large swaths of related code and factor them into their own functions
Remove all anonymous function usage. The use of anonymous functions that were mutating the state of the surrounding code made understanding where variable values change VERY difficult.
Related to anonymous functions, refactor mappings of the workers / reputers inside a topic so that it is not necessary to re-get/query for cosmosaccounts more than once - just store them in a map at the beginning of the workerReputerLoop and use it later
Renames environment variables that were describing untrue things such as "perEpoch" when in fact "iterations" and "epochs" are separate concepts

Future work for the stress test could include getting rid of all the timing and duration code and simply using Client.WaitForNBlocks though if we want to accurately simulate erratic network behavior perhaps using duration code is better.

added a commit that renames the names of the accounts so accounts aren't reused across stress test runs, you can now run the stress test multiple times by changing the SEED environment variable or try to reuse the same accounts and see if it breaks by leaving SEED alone. SEED is initialized to 0

Ill run another round of the topics test

@br4e I'd like to wait to get another set of eyes on this since it's such a big PR, @xmariachi or @guilherme-brandao would be helpful, but you should run another round of tests with this branch in the meantime, just not to lose time

I'm concerned that I'm seeing no valid bundles found on this branch - is that normal to see, or did I mess up the bundle generation code somehow? @xmariachi

Cool yeah sounds good, I was doing a faster approve because I assumed that this was blocking me being able to test the https://github.com/allora-network/allora-chain/pull/299 on major-upgrade, but since that isn't the case I'm all for deeper consideration!

Ah I didn't realize that https://github.com/allora-network/allora-chain/pull/299 is now a part of this pr. Yeah there is a lot going on here and we should take time to review. I can do a thorough high topic test run later.

Yeah @relyt29 next time you do this please make a cascading PR so others can more easily ascertain and critique the unique changes your proposing.

I did make it a cascading PR, #299 is the cascade. I could have merged 299 in, as i had two approvals but I was hoping for more eyes before merging both 299 and this

I'm concerned that I'm seeing no valid bundles found on this branch - is that normal to see, or did I mess up the bundle generation code somehow? @xmariachi
I think this code likely has a bug but my brain is too fried right now to figure it out

You should not see that... so maybe something has been messed up there. Do you see it on every iteration?

You should not see that... so maybe something has been messed up there. Do you see it on every iteration?

I think yes, I will have to dig into it


Kerberos key not found

Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: storageaccount.
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in
this location (eastus)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fba964be-3f77-d80c-f1a5-35bb1430bb8f
Version Independent ID: fe70b11e-10fe-5a8c-1fad-b22a83693503
Content: Enable Active Directory authentication over SMB for Azure Files
Content Source: articles/storage/files/storage-files-active-directory-domain-services-enable.md
Service: storage
GitHub Login: @roygara
Microsoft Alias: rogarana

@skadeb87 Thanks for your question. We are checking on this and will respond to you soon.

@skadeb87 Correct. Feel free to try out in a region where Preview is supported.

Is there any info, when it will be available in West US 2 region? Thanks.

I've the same issue in West Europe, but also tried Easu US and
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account:

@Pawel1985 and @alexsys14 Here is a list of regions where Azure Files AD Authentication is supported. Please consider to try in these regions.

I know, I'm trying west europe,
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: plwaw1fs01sa01.
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in this location (westeurope).

Hi,
I have the same issue. I noticed that there was an error on line 2126 where the if condition was typed backwards. It was typed as "if ($null -eq $kerb1Key)" instead of the other way around.
Also on line 2119 and 2120 the KeyNames are being returned as key1 and key2 when Get-AzStorageAccountKey is run instead of kerb1 and kerb2 as expected in the script.
I manged to makes some changes the the powershell module from the private preview and got to near the end of the script but it ended with and error:
Set-AzStorageAccount : A feature was requested which is not yet available in this location.
Below is the original error:
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: [removed name].
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in this
location (northeurope).
At C:\Users\username\Documents\WindowsPowerShell\Modules\AzFilesHybrid\<IP_ADDRESS>\AzFilesHybrid.psm1:3286 char:13

        Ensure-KerbKeyExists -ResourceGroupName $ResourceGroupNam ...

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Ensure-KerbKeyExists

I hope this helps

@skadeb87 Correct. Feel free to try out in a region where Preview is supported.

@yuemlu  East US is listed in the supported region list and that is where I am trying and receiving the error message.

@skadeb87 I made the same mistake as you. The list provided is the list of regions where the service is NOT available 🤦♂

@SumanthMarigowda-MSFT  can we close this?

Ive just tried to set this up in region (australiaeast) and having the same issue? Yet the link of available regions has this location as an Available Region? Am i missing something here?

I'm also having the same issue in Australia East, although it is not in the "not available" list.
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: <ACCOUNT NAME>.
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in this location (australiaeast)

Hi guys,
west europe location is still not supported. Kindly make it available because we have a lot of new deployment comings next weeks. I want to leverage user profiles on Azure files with on-premises Active directory.

Hi guys,
Would be great if can include error 1396 troubleshooting guide. I encountered this error while trying to map the files share to AD joined machines.
System error 1396 has occurred.
The target account name is incorrect.
"Join-AzStorageAccountForAuth" ran successfully with Provisioning State shown as Succeeded.
The Computer Account in local AD was already created successfully.
"Get-AzStorageAccountKey -ListKerbKey | ft KeyName" also returned 2 kerb keys.
The RBAC Storage permissions were also assigned to the corresponding Azure AD accounts to access the File Share.

I am also receiving the error
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: abtesting2.
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in this location (centralus).

The documentation linked to by @yuemlu (https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable#regional-availability) shows:
Regional availability
Azure Files authentication with AD DS (preview) is available in all Public regions and Azure Gov regions.
But the post made more recently (March 12) by @SumanthMarigowda-MSFT (https://github.com/MicrosoftDocs/azure-docs/issues/49931#issuecomment-598144351) indicates that it is only available in
West US
West US 2
East US
East US 2
West Europe
North Europe
Can someone please update the documentation to correctly indicate the supported regions instead of incorrectly stating it is available in all regions?

@wmgries I'm trying to following along with your video but I am getting
Ensure-KerbKeyExists : Unable to generate a Kerberos key for storage account: abtesting2.
This might be because the 'Azure Files Authentication with Active Directory' feature is not yet available in this location (centralus).

The documentation states this feature is available in all regions:
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-directory-enable#regional-availability
Any ideas?

Same issue here in usgovarizona , despite previous success in uscentral.  Ticket #<PHONE_NUMBER>01372 opened with Microsoft Partner Support regarding...

Since this feature is available in every region, the original issue was over regional availability, and subsequent responses are for product support (GitHub issues are strictly for documentation, not support) we'll close this issue out. For product support, please use either the Q&A, UserVoice, or open a support ticket.
#please-close


ci: run tests in other platforms (windows, wasm)

Change Summary
This adds to the CI, a worker to run the tests with Windows and also using wasm-pack for WASM.
PR Checklist

[x] I have read and signed the Contributor License Agreement.

Fine! Can we merge this now?

Sure


Ontology neo4j

Updates to PGFrame:

added rename_node_properties and rename_edge_properties
added docstrings
added from_ontology classmethod for importing (e.g. Webprotege) ontologies as property graphs

Fixes to pgframe_to_neo4j:

Edges with multiple types result in multiple Neo4j relations with respective types

Added more tests

Codecov Report

Merging #73 (39464fe) into master (25b9299) will increase coverage by 0.51%.
The diff coverage is 92.85%.

@@            Coverage Diff             @@
##           master      #73      +/-   ##
==========================================
+ Coverage   80.37%   80.88%   +0.51%
==========================================
  Files          41       41
  Lines        3414     3506      +92
==========================================
+ Hits         2744     2836      +92
  Misses        670      670

Impacted Files
Coverage Δ

bluegraph/backends/neo4j/io.py
92.05% <90.00%> (+2.66%)
:arrow_up:

bluegraph/core/io.py
66.34% <94.11%> (+2.92%)
:arrow_up:

bluegraph/downstream/data_structures.py
80.74% <0.00%> (-3.26%)
:arrow_down:

bluegraph/downstream/similarity.py
80.16% <0.00%> (-1.04%)
:arrow_down:

bluegraph/core/utils.py
88.88% <0.00%> (+4.44%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25b9299...39464fe. Read the comment docs.


Introduce atomic closures implemented using flat-combining

This is a second stab at flat-combine. This time, the construct is intended for end-user use. The easiest way to use it is with the atomically! macro, which lets you wrap a closure to indicate that it should execute atomically:
let mut set = HashSet::new();
some_vec
    .par_iter()
    .for_each(atomically!(|x| { set.insert(x); }));

But more generally you can create an atomic closure like:
let x = Atomic::new(|foo| process(foo));

and then call it with x.invoke(data).
The current code is intended for use with Rayon; it won't really provide a benefit outside of Rayon, just acts more-or-less like a regular lock. It is also not intended to be super long-lived, so e.g. we never prune the lists of registries that touch it and so forth, which could lead to a (very minor) memory leak if you had a long-lived atomic and created a lot of thread pools that used it independently. But both of those things are anti-patterns, so I'm not worried about that.
Some things remain not done:

[ ] needs some docs
[ ] needs some testing of the panic pathways

cc @aturon -- I'd love a detailed look at the acquire/release orderings. I think they're correct. =)

It may of course make sense to factor this outside of rayon altogether; the main difference would be that we would have to assign each thread that touches it an index, instead of being able to leverage rayon's pre-existing indices. You might also want to revisit the "won't be used by an open-ended set of threads over a long period of time" assumption in that case, which would in general make the management of the active thread list more complicated. (The flat-combining paper talks about ways to manage it.)

Did some measurements on my linux box with this branch:
lunch-box. cargo-benchcmp map_collect::i_to_i::with_mutex map_collect::i_to_i::with_atomic killme.atomic
 name  map_collect::i_to_i::with_mutex ns/iter  map_collect::i_to_i::with_atomic ns/iter  diff ns/iter   diff %
       135,382,261                              93,304,115                                 -42,078,146  -31.08%
 _vec  85,193,005                               45,689,313                                 -39,503,692  -46.37%
lunch-box. cargo-benchcmp map_collect::i_mod_10_to_i::with_mutex map_collect::i_mod_10_to_i::with_atomic killme.atomic
 name  map_collect::i_mod_10_to_i::with_mutex ns/iter  map_collect::i_mod_10_to_i::with_atomic ns/iter  diff ns/iter   diff %
       73,926,743                                      42,409,191                                        -31,517,552  -42.63%
 _vec  13,173,497                                      8,222,546                                          -4,950,951  -37.58%

I encountered an interesting problem trying to port the TSP solver to use this (actually, I encountered it when doing filtering too). The current Atomic wants to take a FnMut(A) -> B, but sometimes you would want FnMut(&A) -> B (i.e., with a higher-ranked lifetime). I think we can make it accept both but it'll require some juggling, and might mean that you wind up with invoke() and invoke_ref() (and hence that the macro atomically! probably needs two variants). Have to ponder.

Rebased. This is working now, but I was trying to integrate it into the TSP benchmark and I found one problem with the API: it assumes you want to own the argument, but this isn't always true, sometimes you'd prefer a closure of type Fn(&T) and not Fn(U) -- these look equivalent but they are not, because the former is known to always borrow its argument, whereas the latter takes ownership of it. Even if U = &'x T, that still requires us to supply references with a known lifetime 'x. I was going to experiment with trying to support both patterns, but haven't gotten around to it yet. It'll probably make the API mildly more complex, which is unfortunate.

Where do you stand on this?  It will at least have to be updated for the rayon-core split.

I think I'll probably wind up closing this, at least for now, but I'm going to keep it open until I have time to read @stjepang's comments and give them some thought! @stjepang, I would encourage you to take a look at the orderings in the sleep module and give me your feedback on that as well! There is some subtle logic there and I suspect there are better ways of doing things. (The README for that module contains a lot of details.)

Gonna close this for now.