Easy way of handling disconnects

In case of a single (predefined) connection I want to be able to handle connection state changes such as:

successfully established connection
cannot establish connection
connection established but dropped for some reason
re-established connection after disconnect

I figured cases 1 and 4 could be handled by listening to the 'created-connection'-event of the first pool (r.getPoolMaster().getPools()[0].on('created-connection', function(pool) {...});
For cases 2 and 3 the following error is logged: 'Failed to create a new connection for the connection pool' (pool.js:290). For the time being I added another event listener self.emit('connection-error', self); to pool.js right after the error msg to be able to handle both scenarios and inform the user accordingly.
Is there any better, recommended way to handle these four cases?

Hum, I'm not sure to understand what you are trying to do. You talk about a single predefined connection but mentions the pool.
For a single connection
r.connect(...).then(function(conn) {
  // conn opened
  conn.on('error', function(err) {
    // conn dropped
  })
}).error(function(err) {
  // failed to open a new connection
})

I realize that my description might have been a little ambiguous....Basically I want to be able to tell if the status of a RethinkDB server is 'unreachable', 'just disconnected', 'just reconnected' or 'connected' and want to inform the user accordingly. Now in case of a single server instance (ie. one host:port entry) a disconnect affects all pooled connections simultaneously, hence my simplification to 'single' connection.
My current solution picks the first connection and reacts on the emission of the 'connection-created' event in case of  'connected' and 'reconnected' and on a customized 'connection-error' event in case of 'disconnected' or 'unreachable' - which I then map to the info strings 'RethinkDB up/down'. But I am sure there must be a more elegant solution which I am hoping you can help me with.
In the end I would like to be able to handle multiple RethinkDB server instances and get real-time updates on their status changes. Thanks

Why do you want to access this information?
Why not just pull the data from server_status?

The reason why I'm asking is that things are actually a bit tricky.
Typically in discovery mode, if a pool doesn't have connections and cannot open a new one, it's just removed.
In non discovery mode, I believe the pool is just removed from the healthy pools.
But then a healthy pool may not have a connection (just after its creation)

I see. Well, thx for your replies - I'll just stick with my workaround for the time being and might in addition use the server_status table. Great tool!


Documentation for extended projects

Add links and documentation for some of the extended projects being worked on by me (eg. matlab code for visualization of DG), Brad (matlab code for laplace-constrained DWI modelling), Uzair (python code for tractography in unfolded space), Mohamed snakemake visualizations, or other projects.
Some relevant repos:
https://github.com/jordandekraker/Hippocampal_AutoTop/tree/master/tools
<Brad doesn't seem to have a repo yet but i expect he will>
https://github.com/uhussai7/Unfolding
https://github.com/myousif9/Hippocampal-Autotop-vis

Just sifting through the issues to remove stale ones.. I think having a section for papers and for links to other relevant projects would good in the README? That way it ends up on the github front page and the docs?


Add SemanticHighlight Endpoint

Implementation of a semantic highlight endpoint. The data that will eventually be returned is different enough from the Highlight endpoint that I thought a new one was justified. This is a simple implementation that does not return modifiers for each classified token.
As requested in https://github.com/OmniSharp/omnisharp-vscode/issues/3565

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: JoeRobich sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

looks good, thanks for adding this 👍
I just left some small comments

@ryanbrandenburg since you own our semantic classification you should take a look at this as well. It will also enable us to call through to Roslyn for semantic colorization as well 😄


[component,core] more detailed caching information

This introduces the CacheInfo object as a part of the QueryMetricsResponse.
This tells us:

What the cache key used was.
What the ttl of the cached item was.
If a cached result was used, or not.

Codecov Report

Merging #320 into master will decrease coverage by <.01%.
The diff coverage is 34.78%.

@@             Coverage Diff              @@
##             master     #320      +/-   ##
============================================
- Coverage      46.3%   46.29%   -0.01%
- Complexity     2574     2577       +3
============================================
  Files           625      626       +1
  Lines         16499    16509      +10
  Branches       1205     1204       -1
============================================
+ Hits           7640     7643       +3
- Misses         8409     8415       +6
- Partials        450      451       +1

Impacted Files
Coverage Δ
Complexity Δ

...a/com/spotify/heroic/http/query/QueryResource.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...fy/heroic/cache/memcached/MemcachedQueryCache.java
0% <0%> (ø)
0 <0> (ø)
:arrow_down:

...in/java/com/spotify/heroic/metric/QueryResult.java
77.14% <20%> (-4.68%)
10 <0> (ø)

...main/java/com/spotify/heroic/metric/CacheInfo.java
75% <75%> (ø)
4 <4> (?)

...om/spotify/heroic/metric/QueryMetricsResponse.java
60.16% <80%> (+0.68%)
10 <1> (ø)
:arrow_down:

...om/spotify/heroic/metric/memory/MemoryBackend.java
80.59% <0%> (-2.99%)
13% <0%> (-1%)

.../spotify/heroic/consumer/kafka/ConsumerThread.java
63.49% <0%> (-1.59%)
20% <0%> (-1%)

...m/spotify/heroic/aggregation/simple/MaxBucket.java
52.38% <0%> (+9.52%)
5% <0%> (+1%)
: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 ad45e78...cbf00ad. Read the comment docs.


Adding support for user-defined cookies to the cookie manager.

See README.md for further information.

Great, even has specs!

Pushed ruby-jmeter 3.1.07 to rubygems.org.


Remove basic auth from REST API doc

Removing basic auth section of the Auth part of the REST API doc. Added a note telling people it's no longer available.

Let's bump it together with the change 🙌


grey_activeRunLoopMode unrecognized selector

Hi,
I'm facing some issues in connecting earlgray2 to my Swift application.
I followed the instruction from earlgrey2 with manual setup, but tests are crashing with the simplest example.
Here you can find the error:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIApplication grey_activeRunLoopMode]: unrecognized selector sent to instance 0x7fb041404860'
Additionally, I've tried to run tests in the provided test app, but it ended the same way.
I see that the header with the missing symbol exists, it can be added to the bridging header and even call manually from the test, but the error is the same.

Do you have any ideas how to fix it?

Artur, are you using the EarlGrey.xcodeproj in your setup?


Decouple graw's internal packages.

Coverage increased (+11.6%) to 90.341% when pulling c843f8d8c9242e787b9214bc76e9eb7bde3d63e9 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.

Coverage decreased (-17.9%) to 60.855% when pulling c843f8d8c9242e787b9214bc76e9eb7bde3d63e9 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.

Coverage decreased (-17.5%) to 61.238% when pulling 38327c518fb3b0047fafafd992c5c91aa56d0e86 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.

Coverage decreased (-17.5%) to 61.238% when pulling 100d0c0c44a07f0bf20cdc74f03646590432c5c7 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.

Coverage decreased (-17.5%) to 61.238% when pulling d4e72309c45c232ca57451edc8a846cad0077df1 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.

Coverage decreased (-18.5%) to 60.191% when pulling d3c284640165cb08b13de272b7e02a215768ee27 on decouple into e03d5a552425d9233607e153c04aa6a9fe549913 on master.


Add auto scoring of autonomous flight.

For #218

As we're nearing the milestone date, I'm going to submit this tomorrow morning sans-comments.


sfml-audio dylib built from source depends on Vorbisenc

This might be a problem with my build, if I figure it out I will close this. If not, I'll edit with as much info as I can

I could be doing things totally wrong and still have no clue how to do them right 🥲
Mac support was always just barely working because it keeps changing and I don't use Mac myself

You’re not! It works.
On Tue, Jul 2, 2024 at 3:25 PM Oleh Prypin @.***> wrote:

I could be doing things totally wrong and still have no clue how to do
them right 🥲
Mac support was always just barely working because it keeps changing and I
don't use Mac myself
—
Reply to this email directly, view it on GitHub
https://github.com/oprypin/install-sfml/issues/2#issuecomment-2204472636,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AATXBKPPH2UCBAI5FB352R3ZKMLEZAVCNFSM6AAAAABKIEOB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBUGQ3TENRTGY
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Try to eliminate concurrencty in various libraries where possible - EXCLUDING NOTIFICATIONS

Try to eliminate concurrencty in various libraries where possible - EXCLUDING NOTIFICATIONS.  notifications is a whole other beast, and will be handled in a separate issue.

Done.


[CODE] Create and publish a personal portfolio website

For this week's coding challenge, you will create and publish a personal portfolio website using the instructions in the textbook
This video will take you through the process step by step

/teamassign @earthlab-education/ea-students

/assign @JulesMRuef

/assign @megan8617

/assign @Klydascope

/assign @kdwalker24

/assign @nbol48

/assign @jsmi374

/assign @lucap1211

/assign @annieM459

/assign @NobodyLivesHere

/assign @millie-spencer

/assign @taylor-obrien

/assign @pth6570

/assign @agneslh

/assign @ellenalamont17

/assign @thku8507

Finished creating my personal portfolio wesbite!


How does this plugin handles object store variables?

I am using vuex-persistedstate in my Nuxt.js projects. I am wondering how this Vuex plugin handles object variables inside my store? I am seeing strange behaviours.
Every time I hard-refresh my app [Command-R] my array inside store duplicates elements. Does this plugin adds values to store arrays?
My store is initialised like this:
import UsersTable from '@/assets/tables/users'

export const state = () => ({
  usersTable: UsersTable
})

So UsersTable  is object like this:
export default {
  columns: [
    {
      name: 'profile.lastname',
      title: 'USER.LBL_LASTNAME',
      sortField: 'profile.lastname'
    },
    {
      name: 'email',
      title: 'USER.LBL_EMAIL',
      sortField: 'email'
    },
    {
      name: 'address.city',
      title: 'USER.LBL_CITY',
      sortField: 'address[0].city'
    }
  ]
}

Now after each refresh my store.usersTable.columns double... I am not sure what is happening here but I suspect that vuex-persistedstate plugin pushes values from local storage after the store get's initialised. Is this true?
If yes then this is questionable behaviour...? Anyone else having these problems?

I have checked the source and seen that you somehow merge if saved state is object? This happens here.
Why is store variable not simply replaced from the saved state?
return function(store) {
    var savedState = shvl.get(options, 'getState', getState)(key, storage);

    if (typeof savedState === 'object' && savedState !== null) {
      store.replaceState(merge(store.state, savedState, {
        arrayMerge: function (store, saved) { return saved }
      }));
    }

    (options.subscriber || subscriber)(store)(function(mutation, state) {
      if ((options.filter || filter)(mutation)) {
        (options.setState || setState)(
          key,
          (options.reducer || reducer)(state, options.paths || []),
          storage
        );
      }
    });
  };

@PrimozRome thanks for reporting the issue! Please see PR #89, that will probably fix your issue. For now I would recommend to use version 2.1.2.

@robinvdvleuten ah I see.
What was the reason to use array merge instead of overwrite?

@PrimozRome there was no reason behind it. I was looking for a replacement for lodash and thought that deepmerge mimicked the functionality. Apparently the state merging wasn't correctly covered by testcases and is popping up as an issue now. The PR fixes it and I will try to harden the plugin even more this week so hopefully issue #86 is fixed as well.

@robinvdvleuten excellent! Looking forward on the upgrade and thanks for explanations.

 Please open a new issue if you stumble upon something else.


chore(Deps) stefanzweifel/git-auto-commit-action action to v5

This PR contains the following updates:

Package
Type
Update
Change

stefanzweifel/git-auto-commit-action
action
major
v4 -> v5

Release Notes

stefanzweifel/git-auto-commit-action (stefanzweifel/git-auto-commit-action)
v5
Compare Source
New major release that bumps the default runtime to Node 20. There are no other breaking changes.
Changed

Update node version to node20 (#300) @ryudaitakai
Add _log and _set_github_output functions (#273) @stefanzweifel

Fixed

Seems like there is an extra space (#288) @pedroamador
Fix git-auto-commit.yml (#277) @zcong1993

Dependency Updates

Bump actions/checkout from 3 to 4 (#302) @dependabot
Bump bats from 1.9.0 to 1.10.0 (#293) @dependabot
Bump github/super-linter from 4 to 5 (#289) @dependabot
Bump bats from 1.8.2 to 1.9.0 (#282) @dependabot

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

🦙 MegaLinter status: ✅ SUCCESS

Descriptor
Linter
Files
Fixed
Errors
Elapsed time

✅ COPYPASTE
jscpd
yes

no
1.14s

✅ CSS
stylelint
1
0
0
1.37s

✅ JAVASCRIPT
standard
1
0
0
1.6s

✅ JSON
eslint-plugin-jsonc
3
0
0
3.5s

✅ JSON
npm-package-json-lint
yes

no
0.67s

✅ JSON
prettier
3
0
0
0.35s

✅ JSON
v8r
3

0
10.59s

✅ MARKDOWN
markdownlint
8
0
0
0.61s

✅ MARKDOWN
markdown-link-check
8

0
1.35s

✅ MARKDOWN
markdown-table-formatter
8
0
0
0.31s

✅ REPOSITORY
gitleaks
yes

no
0.24s

✅ REPOSITORY
git_diff
yes

no
0.01s

✅ REPOSITORY
grype
yes

no
11.29s

✅ REPOSITORY
secretlint
yes

no
1.56s

✅ REPOSITORY
trivy
yes

no
6.41s

✅ REPOSITORY
trivy-sbom
yes

no
1.75s

✅ YAML
prettier
2
0
0
0.61s

✅ YAML
v8r
2

0
4.98s

See detailed report in MegaLinter reports
MegaLinter is graciously provided by


[WIP] Add E2E test using Broker, Trigger, and KafkaSink

Fixes #164
Test Plan
+---------+     +--------+     +---------+   +---------------------------+
|  Broker +---->+ Trigger+---->+KafkaSink+-->+kafka consumer (test image)|
+----+----+     +--------+     +----+----+   +---------------------------+
     |                              ^
     |          +--------+          |
     +--------->+ Trigger+----------+
                +--------+

Proposed Changes

Add E2E test using Broker, Trigger, and KafkaSink

[ERROR] Failed to execute goal on project receiver: Could not resolve dependencies for project dev.knative.eventing.kafka.broker:receiver:jar:1.0-SNAPSHOT: Could not transfer artifact com.github.luben:zstd-jni:jar:1.4.4-7 from/to central (https://repo.maven.apache.org/maven2): Transfer failed for https://repo.maven.apache.org/maven2/com/github/luben/zstd-jni/1.4.4-7/zstd-jni-1.4.4-7.jar: Connection reset -> [Help 1]

Maven central
/retest

This test worked, flaky not
/retest

Flaky...
/retest

/assign @slinkydeveloper

/lgtm
/approve


Use codecs

WIP. I still need to add tests here. Fixes #3 . It's now in a structure that is amenable to testing however.

@ph would you be able to take a look at this? This includes a full test suite. It can be manually tested with a logstash config like:
input {
  generator {
    lines => [
      "Hello 100",
      "test 24.8ms"
    ]
    count => 1
  }
}

filter {
  grok {
    match => [ "message", "test (N/A|%{BASE10NUM:duration:float}ms)" ]
  }
}

output {
  sns {
    arn => "arn:aws:sns:us-east-1:773216979769:logstash-test-topic"
    access_key_id => "AKIAJVZBBFPGVM7KYTAQ"
    secret_access_key => "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"
    codec => rubydebug
    region => "us-east-1"
  }
}

or
input {
  generator {
    lines => [
      "Hello 100",
      "test 24.8ms"
    ]
    count => 1
  }
}

filter {
  mutate {
    add_field => { "sns_message" => "Hey dude!" }
  }
}

output {
  stdout { codec => rubydebug}

  sns {
    arn => "arn:aws:sns:us-east-1:773216979769:logstash-test-topic"
    access_key_id => "AKIAJVZBBFPGVM7KYTAQ"
    secret_access_key => "dVnL20rTHbCrGtZqbuFCj+3L2Wu/40GUwP6QpBSe"
    codec => rubydebug
    region => "us-east-1"
  }
}

@andrewvc I have edited your comment to remove your credentials, please invalid them!

Good work @andrewvc ! I added a few comments and I didn't not run the test since some of the changes will probably break them :(

Thanks for all the great feedback @ph  and @suyograo I've made the requested changes and improved the docs to boot. I also covered a corner case that had been overlooked (no subject AND no host). More specs are now in place as well.

@andrewvc @suyograo I would be inclined to use version 2.0 for this plugin instead of marking it as 1.0 because we have decided that plugins shipped are already marked as 1.0.
And the 1.0 is using v1, so 2.0.0 would make sense to me for a v2. API.
Other than this minor comment code LGTM, Tests are an awesome improvement +1.
I manually tested this plugin also.
We could probably try https://github.com/logstash-plugins/logstash-output-sns/issues/4 in another PR.


Redqueen question

Hi!
I noticed problems getting full coverage on test Windows driver. It looked like Redqueen was not working sometimes, and kAFL was not finding full coverage test set even after tens of millions of attempts. Initially I suspected a race condition occurring somewhere between kAFL Redqueen and QEMU Redqueen, but after reading the code found this line. After removing it, Redqueen started to work perfectly, full coverage test set was found in seconds using Redqueen and not deterministic or havoc approaches.
My question is: looks like you added this line, I don't see it in original RUB-SysSec/redqueen, so what's its purpose? Is it somehow beneficial on large targets?

Hi,
The line is not in original redqueen but in the later grimoire code base which our python frontend is based on: https://github.com/RUB-SysSec/grimoire/blob/fae90ee436fe626f54ec2421269de8340cf06bf9/fuzzer/technique/redqueen/cmp.py#L65
It looks like this code is trying to reduce the search space of redqueen by ignoring things that are surely found by AFL later on. I guess only @eqv can say which is supposed to work better.
Could you try without effector maps (-d) and see if that fixes things?

Yeah that's pretty much it. No point in trying mutations that would be done by normal mutators anyway. I don't think there will be any serious side effects if you remove that condition. In long (24h or so) fuzzing campaigns it will probably not matter much either way. For short campaigns that can probably increase the performance significantly.

Mentioned line deleted (better say, is_simple_mutation function changed to return lhs == rhs), effector maps on, 3 runs: full coverage (59 edges) found in ~30 seconds.
Line not deleted, effector maps off, 3 runs: 2/3 attempts failed to produce full coverage in 5 minutes, both found only 36/59 edges. 1/3 attempt found full coverage in 30 seconds.
The time here (30 seconds) may be not representative since I'm using sleep fix mentioned in https://github.com/IntelLabs/kAFL/issues/10#issuecomment-663480222. ~8 seconds are spent on QEMU restart, which happens two times in full coverage cases (initial start + 1 crash found). Performance is ~3000 execs/s.

In long (24h or so) fuzzing campaigns it will probably not matter much either way

So, the effect was not measured. I think of the opposite argument here: using Redqueen no matters what helps us to get easily achievable coverage fast. Maybe it does not matter in the long run but it gives us a nice opportunity to find something interesting right from the start so we can triage it while fuzzing continues. The question here is, how costly Redqueen becomes on large targets? Is it possible that your change in Grimoire may be seen as increasing performance?

I am performing a long run with your patch and with effector maps disabled. This time, by the power of random, it found 29/59 edges in first 15 seconds. No new coverage was found in 15 minutes (in 3 million execs), I am continuing fuzzing.

We did experiments with this. The main issue was that the Redqueen stage is performed as one large atomic chunk of work. With large inputs that contain many candidate positions this can delay the havoc stage and scheduling of newly found inputs. In some of our cases this drastically delayed the fuzzing process. The better option would be to make the redqueen stage interruptible so that other inputs and havoc can be scheduled in the mean time.

Line not deleted, effector maps off, 3 runs: 2/3 attempts failed to produce full coverage
in 5 minutes, both found only 36/59 edges. 1/3 attempt found full coverage in 30 seconds.

Thanks. That excludes a recent extension I did to the deterministic stages from possible source of errors. I will try to reproduce this for a different target.

I see your point.
Also, I've only now noticed that I was running with -D option... Turning deterministic mode back on indeed produces nice results with your patch.
While the original issue is a false alarm, it may be beneficial to make is_simple_mutation check in Redqueen dependent on the deterministic mode availability. Other way may be to show a warning when -redqueen is supplied in the same time as -D.
Another thing to note, Redqueen check is performed against helper.AFL_ARITH_MAX while config.config_values["ARITHMETIC_MAX"] is used in state logic processing.

Last question: why this check is used? Processing zeroes produces too much tests as well?

FYI: In my experience RQ is a lot more effective that deterministic or havoc stages, i.e. it typically finds much more in significantly less time. I noticed this so strongly that I changed the scheduler.py and queue.py to focus on Redqueen and also schedule new inputs much earlier. Instead of linearly iterating through a queue and spending some time on each item, our queue is frequently re-sorted to put "promising" items and items that are still in early stages toward the top. Weights are balanced so that we (approximately) solve the init/redqueen/grimoire stages for all fav nodes first, then continue with deterministic stages for highest-fav nodes, and then also start processing non-favorite nodes. Havoc is last, although you will see very highly scored items (lots of new bytes) to enter havoc a little earlier.
I also added a time limit + resume to the deterministic stages since we can be stuck there for a long time, when time may be better spend pushing any newly discovered item though RQ again.
I did not do a full-fledged benchmark series for this but for for any non-trivial sample I have this seems to work a lot better than the previous strawman scheduler. Based on that experience I would also say finding nodes earlier is exponentially better than waiting for AFL arithmetic phase. But I suppose it depends on the performance impact on RQ phase..

Also, I've only now noticed that I was running with -D option... Turning deterministic mode
back on indeed produces nice results with your patch.

Ah, great. But what patch do you mean, this kAFL repo here?

While the original issue is a false alarm, it may be beneficial to make is_simple_mutation check in
Redqueen dependent on the deterministic mode availability. Other way may be to show a warning
when -redqueen is supplied at the same time as -D.
Another thing to note, Redqueen check is performed against helper.AFL_ARITH_MAX while
config.config_values["ARITHMETIC_MAX"] is used in state logic processing.

Agreed. If RQ performance is still good with this change, I would simply make this the new default and only add an option to "ignore simple mutations found by deterministic stage". I will look at it over the next days, or feel free to post the patch yourself.
BTW are there any numbers to show the yield per time/execs on havoc vs deterministic? I agree that it makes things feel slow, but looking at algorithms I cannot imagine that disabling the deterministic stage gives a tangible advantage in the average case.

what patch do you mean

is_simple_mutation one, which was introduced, as you said, in Grimoire...

If RQ performance is still good with this change, I would simply make this the new default and only add an option to "ignore simple mutations found by deterministic stage".

...so you don't need to do anything.

BTW are there any numbers to show the yield per time/execs on havoc vs deterministic?

My small attempt:
ordinary mode
fuzzer works at around 3450 exec/s
stopped after no new test was found for 30m, 31/59 edges
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=0.09, t=325.21)
00:00:11: Found   2 from   1 using calibrate    [\xd3.\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\] (favs=3, stage=final, exit=R, lvl=1, perf=0.00, score=0.29, t=59.14)
00:00:12: Found   3 from   1 using afl_havoc    [wdE.\xbe....\xff.\xbe\xbe\xb3\xbe\xbe\xaa\] (favs=4, stage=final, exit=R, lvl=1, perf=0.00, score=0.29, t=64.58)
00:00:12: Found   4 from   1 using afl_havoc    [PPPP\x80.\xba*K4PP\xba\xba*K4PPPj]\xd6P1\x] (favs=2, stage=final, exit=R, lvl=1, perf=0.00, score=0.43, t=34.54)
00:01:35: Found   5 from   3 using afl_splice   [Pw\x80\x80\x80\x80\x80\x80\x9dVp.\x97Npp\x] (favs=2, stage=final, exit=R, lvl=2, perf=0.00, score=0.45, t=33.65)
00:01:38: Found   6 from   5 using afl_arith_1  [Pwn\x80\x80\x80\x80\x80\x9dVp.\x97Npp\x9d\] (favs=2, stage=final, exit=R, lvl=3, perf=0.00, score=0.42, t=35.74)
00:06:05: Found   7 from   5 using afl_splice   [w0,---\x80--v\x8f\x8fwww                  ] (favs=4, stage=final, exit=R, lvl=3, perf=0.00, score=0.15, t=129.47)
00:06:09: Found   8 from   7 using afl_arith_1  [w00---\x80--v\x8f\x8fwww                  ] (favs=4, stage=final, exit=R, lvl=4, perf=0.00, score=0.15, t=130.10)

no deterministic
stopped after no new test was found for 30m, 27/59 edges
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=0.06, t=464.91)
00:00:11: Found   2 from   1 using calibrate    [\xd3.\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\] (favs=2, stage=final, exit=R, lvl=1, perf=0.00, score=0.50, t=33.94)
00:00:11: Found   3 from   1 using afl_havoc    [wdE.\xbe....\xff.\xbe\xbe\xb3\xbe\xbe\xaa\] (favs=4, stage=final, exit=R, lvl=1, perf=0.00, score=0.15, t=129.86)
00:00:12: Found   4 from   1 using afl_havoc    [PPPP\x80.\xba*K4PP\xba\xba*K4PPPj]\xd6P1\x] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.41, t=32.00)
00:01:31: Found   5 from   1 using afl_havoc    [Pw\x80\x80\x80\x80\x80\x80\x9dVp.\x97Npp\x] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.36, t=35.85)
00:05:55: Found   6 from   1 using afl_havoc    [w0,---\x80--v\x8f\x8fwww                  ] (favs=4, stage=final, exit=R, lvl=1, perf=0.00, score=0.10, t=204.11)
00:12:44: Found   7 from   5 using afl_splice   [PwnnYnp.....nnnnnnnn\x80\xff\xff\xffdHQ\xb] (favs=5, stage=final, exit=R, lvl=2, perf=0.00, score=0.08, t=259.26)

ordinary mode, for j in range(1 << (1 + stacking)) changed to for j in range(1 << stacking) here
fuzzer works at around 3750 exec/s
full coverage found in 17:05, big part of it was found by deterministic after a lucky splice
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=0.18, t=159.71)
00:00:11: Found   2 from   1 using calibrate    [\xe4\xe4\xfa...\xd3\xd3.\xd3\xd3\xd3\xd3\x] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.49, t=32.76)
00:00:12: Found   3 from   1 using afl_havoc    [ww\xff\x98\x98\x98wwwwwwwww\x98\x98\x98\x9] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.54, t=35.14)
00:00:13: Found   4 from   1 using afl_havoc    [PPPPPPPPPPPPFPKKKK>KKKKKKKKKKKK           ] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.93, t=16.07)
00:01:31: Found   5 from   2 using afl_splice   [w0yw0y\x90z\x90\x90\x90\x90\x84\x90.\xff\x] (favs=1, stage=final, exit=R, lvl=2, perf=0.00, score=0.42, t=44.72)
00:08:16: Found   6 from   5 using afl_splice   [w00d.\xc0w0..\xc0\xc0\xc0\xc0\xc0^\xc0d\xa] (favs=12, stage=final, exit=R, lvl=3, perf=0.00, score=0.28, t=119.75)
00:08:18: Found   7 from   6 using afl_flip_1/1 [w00t.\xc0w0..\xc0\xc0\xc0\xc0\xc0^\xc0d\xa] (favs=3, stage=final, exit=R, lvl=4, perf=0.00, score=0.86, t=19.74)
00:15:58: Found   8 from   6 using afl_splice   [Pwmmmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=3, stage=final, exit=R, lvl=4, perf=0.00, score=3.83, t=4.18)
00:16:08: Found   9 from   8 using afl_flip_2/1 [Pwnmmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=5, perf=0.00, score=3.64, t=4.40)
00:16:23: Found  10 from   9 using afl_arith_1  [PwnTmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=6, perf=0.00, score=3.71, t=4.32)
00:16:36: Found  11 from  10 using afl_flip_1/1 [PwnTommm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=7, perf=0.00, score=4.25, t=3.77)
00:16:51: Found  12 from  11 using afl_arith_1  [PwnTowmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=8, perf=0.00, score=4.07, t=3.93)
00:17:05: Found  13 from  12 using afl_flip_2/1 [PwnTownm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=6, stage=initial, exit=C, lvl=9, perf=0.00, score=0.00, t=0.00)

another try, stopped after no new test was found for 30m, 56/59 edges
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=0.03, t=1025.01)
00:00:11: Found   2 from   1 using calibrate    [\xe4\xe4\xfa...\xd3\xd3.\xd3\xd3\xd3\xd3\x] (favs=2, stage=final, exit=R, lvl=1, perf=0.00, score=0.27, t=64.14)
00:00:12: Found   3 from   1 using afl_havoc    [ww\xff\x98\x98\x98wwwwwwwww\x98\x98\x98\x9] (favs=4, stage=final, exit=R, lvl=1, perf=0.00, score=0.17, t=112.28)
00:00:13: Found   4 from   1 using afl_havoc    [PPPPPPPPPPPPFPKKKK>KKKKKKKKKKKK           ] (favs=1, stage=final, exit=R, lvl=1, perf=0.00, score=0.45, t=33.65)
00:14:02: Found   5 from   3 using afl_havoc    [w0...\x80:0..\xff.40:.\x98x\xd5:00 ...    ] (favs=4, stage=final, exit=R, lvl=2, perf=0.00, score=0.30, t=64.14)
00:14:11: Found   6 from   5 using afl_flip_2/1 [w00..\x80:0..\xff.40:.\x98x\xd5:00 ...    ] (favs=4, stage=final, exit=R, lvl=3, perf=0.00, score=0.21, t=91.32)
00:15:54: Found   7 from   5 using afl_splice   [Pwmmmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=4, stage=final, exit=R, lvl=3, perf=0.00, score=0.27, t=67.82)
00:15:56: Found   8 from   7 using afl_flip_2/1 [Pwnmmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=4, perf=0.00, score=0.43, t=34.54)
00:16:08: Found   9 from   8 using afl_arith_1  [PwnTmmmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=5, perf=0.00, score=0.46, t=35.09)
00:16:22: Found  10 from   9 using afl_flip_1/1 [PwnTommm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=6, perf=0.00, score=0.45, t=35.22)
00:16:35: Found  11 from  10 using afl_arith_1  [PwnTowmm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=2, stage=final, exit=R, lvl=7, perf=0.00, score=0.49, t=32.38)
00:16:48: Found  12 from  11 using afl_flip_2/1 [PwnTownm{m\xff\xffmmmm`mmomm\xfa.mm\xfa..\] (favs=6, stage=initial, exit=C, lvl=8, perf=0.00, score=0.00, t=0.00)

no deterministic, for j in range(1 << (1 + stacking)) changed to for j in range(1 << stacking) here
stopped after no new test was found for 30m, 31/59 edges (only run that lasted more than an hour)
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=0.04, t=777.22)
00:00:11: Found   2 from   1 using calibrate    [\xe4\xe4\xfa...\xd3\xd3.\xd3\xd3\xd3\xd3\x] (favs=3, stage=final, exit=R, lvl=1, perf=0.00, score=0.13, t=128.93)
00:00:11: Found   3 from   1 using afl_havoc    [ww\xff\x98\x98\x98wwwwwwwww\x98\x98\x98\x9] (favs=4, stage=final, exit=R, lvl=1, perf=0.00, score=0.10, t=192.66)
00:00:12: Found   4 from   1 using afl_havoc    [PPPPPPPPPPPPFPKKKK>KKKKKKKKKKKK           ] (favs=2, stage=final, exit=R, lvl=1, perf=0.00, score=0.23, t=64.16)
00:00:47: Found   5 from   4 using afl_splice   [Pw\xff\x98\x98\x98wwwwwwwww\x98\x98\x98\x9] (favs=2, stage=final, exit=R, lvl=2, perf=0.00, score=0.22, t=67.71)
00:14:00: Found   6 from   3 using afl_splice   [w0...\x80:0..\xff.40:.\x98x\xd5:00 ...    ] (favs=4, stage=final, exit=R, lvl=2, perf=0.00, score=0.07, t=258.08)
00:15:38: Found   7 from   6 using afl_splice   [w00..\xff.40:.\x98x\xd5:00KKKKKKKKK       ] (favs=4, stage=final, exit=R, lvl=3, perf=0.00, score=0.07, t=256.11)
00:34:20: Found   8 from   5 using afl_splice   [Pwn\x98\x98\x98\x98\x98\x98\x98\x98\x98\x9] (favs=2, stage=final, exit=R, lvl=3, perf=0.00, score=0.23, t=64.63)

BONUS: ordinary mode, ARITH_MAX=128
full coverage found in 00:45
00:00:11: Found   1 from   0 using import       [a.                                        ] (favs=10, stage=final, exit=R, lvl=0, perf=0.01, score=11.41, t=2.63)
00:00:11: Found   2 from   1 using calibrate    [\xd3.\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\] (favs=3, stage=havoc, exit=R, lvl=1, perf=0.00, score=17.00, t=0.00)
00:00:12: Found   3 from   2 using afl_arith_1  [w.\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\x95] (favs=1, stage=havoc, exit=R, lvl=2, perf=0.00, score=20.00, t=0.00)
00:00:12: Found   4 from   2 using afl_arith_1  [P.\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\x95] (favs=1, stage=havoc, exit=R, lvl=2, perf=0.00, score=16.00, t=0.00)
00:00:13: Found   5 from   3 using afl_flip_2/1 [w0\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\x95] (favs=1, stage=havoc, exit=R, lvl=3, perf=0.00, score=20.00, t=0.00)
00:00:16: Found   6 from   4 using afl_arith_1  [Pw\xd3.\x84\x84\x84l\x84\x84\x84.\xedx\x95] (favs=1, stage=havoc, exit=R, lvl=3, perf=0.00, score=16.00, t=0.00)
00:00:18: Found   7 from   5 using afl_arith_1  [w00.\x84\x84\x84l\x84\x84\x84.\xedx\x95#. ] (favs=1, stage=havoc, exit=R, lvl=4, perf=0.00, score=20.00, t=0.00)
00:00:20: Found   8 from   6 using afl_arith_1  [Pwn.\x84\x84\x84l\x84\x84\x84.\xedx\x95#. ] (favs=1, stage=havoc, exit=R, lvl=4, perf=0.00, score=16.00, t=0.00)
00:00:22: Found   9 from   7 using afl_arith_1  [w00t\x84\x84\x84l\x84\x84\x84.\xedx\x95#. ] (favs=12, stage=final, exit=R, lvl=5, perf=0.00, score=7.96, t=4.52)
00:00:24: Found  10 from   8 using afl_arith_1  [PwnT\x84\x84\x84l\x84\x84\x84.\xedx\x95#. ] (favs=1, stage=havoc, exit=R, lvl=5, perf=0.00, score=17.00, t=0.00)
00:00:27: Found  11 from  10 using afl_arith_1  [PwnTo\x84\x84l\x84\x84\x84.\xedx\x95#.    ] (favs=6, stage=final, exit=R, lvl=6, perf=0.00, score=5.74, t=4.18)
00:00:29: Found  12 from  11 using afl_arith_1  [PwnTow\x84l\x84\x84\x84.\xedx\x95#.       ] (favs=2, stage=final, exit=R, lvl=7, perf=0.00, score=4.19, t=4.06)
00:00:45: Found  13 from  12 using afl_arith_1  [PwnTownl\x84\x84\x84.\xedx\x95#.          ] (favs=6, stage=initial, exit=C, lvl=8, perf=0.00, score=0.00, t=0.00)

Btw, as you can see, kAFL was obsessed with initial test case, a\x0A here. I don't know yet kAFL scheduling model but it looks complicated. For example, from the first run in this list
00:01:38: Found   6 from   5 using afl_arith_1  [Pwn\x80\x80\x80\x80\x80\x9dVp.\x97Npp\x9d\] (favs=2, stage=final, exit=R, lvl=3, perf=0.00, score=0.42, t=35.74)
00:06:05: Found   7 from   5 using afl_splice   [w0,---\x80--v\x8f\x8fwww                  ] (favs=4, stage=final, exit=R, lvl=3, perf=0.00, score=0.15, t=129.47)

Why was second test prioritized over the first one? They are both on the same level 3. I see that they have different amount of favs, what does it mean? Looks like fuzzer may need more than a half hour to even out test priority.
I am a bit concerned about afl_havoc performance in these tests, afl_splice did good though.

The fav count is the number of new bytes (edges) that this input triggers on top of other/prior inputs. More specifically, there may be other inputs that also hit one of those edges but they have lower speed/score or similar. I think that logic is similar as in AFL queue culling (although probably not exactly the same and perhaps buggy). I use this as one of the strongest factors in the sorting function. The score + speed of the kafl_plot tool are supposed to match the corresponding values from the sorting function but I think they may be outdated.
Even this toy example seems to confirm that -D will significantly impact the achieved coverage/time. Only in the first 2 tests the results are, I would say, inconclusive (need more runs over longer time?). AFAIK, havoc is doing the same basic mutations but they are applied randomly and stacked, so you have an additional level of noise and collision to content with. My understanding is that this stage really only makes sense if the basic deterministic mutations have all been tried once, especially since they are finite and only need to be done once. If you have any other insight to this, I'm happy to learn.
You are saying havoc should be better - but compared to what, and how can we fix it? I reviewed the deterministic stages and havoc in kAFL against vanilla AFL a while back and they all seem to be equivalent. The major difference seems to be in the number of time/rounds invested in havoc, and that auto-dict is missing in our deterministic stage.
I agree that we spend too much time doing havoc on the initial/seed input. I suppose this is because the initial input is fast and short and gets all the fav bytes assigned that execute regardless of the input. The current scheduler already uses the time spent in havoc to reduce the overall score. We can use a stronger factor there to reduce the bias or remove it completely: scheduler.py:98
I'm happy to adjust or completely replace this scheduler but I think we need a more representative target and measure multiple runs over several hours. ARITH_MAX=128 looks interesting for example, but I would only make it default if it shows good results across multiple targets. Makes sense?
If you look at tests/user_bench/, there are some relatively simple scripts to get typical userspace targets like objdump and nasm working in a Linux busybox/initramfs environment. I think this can be a good starting point for a regular performance/regression test. Perhaps we can also get the magma benchmark working to get some more recent results to compare against.

You are saying havoc should be better - but compared to what, and how can we fix it?

Well, I don't really know. What can you say about these tweets? https://twitter.com/gamozolabs/status/1284854239232053248 and https://twitter.com/gamozolabs/status/1284854896483659776.
I can also say that I have a feeling more time was spent in afl_splice than in afl_havoc on this target.

ARITH_MAX=128 looks interesting for example, but I would only make it default if it shows good results across multiple targets. Makes sense?

Since it's deterministic stage, it surely won't make things worse. I think the question is, is it beneficial in the terms of edges per second to make deterministic stage 4 times longer? At least it can be said that that way we fully bruteforce each byte in the test before moving to havoc stage — a nice property.

I think this can be a good starting point for a regular performance/regression test.

Yeah, I think I can start testing with some Linux programs. Do you consider Objdump and NASM to be the best two examples from user_bench? I don't have computing resource to run extensive tests on all programs there but may run one or two.

I would strongly advise caution when changing large parts of the mutator on experiments with one or two targets. It's VERY easy to  overfit to one individual target, and similarly be fooled by randomness (even with up to 20 runs per target). We have seen multiple changes that seemed very helpful on 20 vs 20 runs in a given target that turned out to be not helpful at all.

TDB:

make is_simple_mutation check in Redqueen dependent on the deterministic mode availability.
Other way may be to show a warning when -redqueen is supplied at the same time as -D.

Another thing to note, Redqueen check is performed against helper.AFL_ARITH_MAX while
config.config_values["ARITHMETIC_MAX"] is used in state logic processing.

Lets discuss benchmarking/optimizations separately.

Commit 4559817 fixes these.

Greetings!
I reach some troubles with redqueen feature: it doesn't handle strcmp() calls on linux userspace target.
Launch command:
kafl fuzz \
        --kernel /boot/vmlinuz-$(uname -r) \
        --initrd forkserver.cpio.gz \
        --memory 512 \
        --sharedir $PWD \
        --purge -t 2 -ts 1 --log-hprintf --log-crashes \
        --append "nokaslr oops=panic nopti mitigations=off console=ttyS0 hprintf=7" \
        -ip0 0x401000-0x4af000 \
        --redqueen --redqueen-hammer --redqueen-simple --redqueen-hashes --grimoire --radamsa \
        -p 1 --qemu-path /usr/src/QEMU-Nyx/x86_64-softmmu/qemu-system-x86_64

Some debugging of qemu-nyx approve, that redqueen strcmp() hooks are reached and works as expected, or, at least, see strcmp() calls is target and could access guest args.
The target, as always, is simple, statically built, small harness with several branches to test integers and strings extractions.
In file: /usr/src/QEMU-Nyx/nyx/redqueen.c
   948 static void format_strcmp(uint8_t *buf1, uint8_t *buf2)
   949 {
   950     char  out_buf[REDQUEEN_MAX_STRCMP_LEN * 4 + 2];
   951     char *tmp_hex_buf = &out_buf[0];
   952     for (int i = 0; i < REDQUEEN_MAX_STRCMP_LEN; i++) {
 ► 953         tmp_hex_buf += sprintf(tmp_hex_buf, "%02X", (uint8_t)buf1[i]);
   954     }
   955     *tmp_hex_buf++ = '-';
   956     for (int i = 0; i < REDQUEEN_MAX_STRCMP_LEN; i++) {
   957         tmp_hex_buf += sprintf(tmp_hex_buf, "%02X", (uint8_t)buf2[i]);
   958     }

pwndbg> p tmp_hex_buf
$5 = 0x7fffeb000310 "C9"
pwndbg> p buf2
$6 = (uint8_t *) 0x7fffeb0004a0 "PWNED!!!"
pwndbg> p buf1
$7 = (uint8_t *) 0x7fffeb000460 "ɵ\032<\237b22\032\062\062\016\020g\022UUU"

full backtrace:
pwndbg> bt full
#0  0x0000555555c0f3a4 in format_strcmp (buf1=buf1@entry=0x7fffeb000460 "ɵ\032<\237b22\032\062\062\016\020g\022UUU", buf2=buf2@entry=0x7fffeb0004a0 "PWNED!!!") at /usr/src/QEMU-Nyx/nyx/redqueen.c:953
        i = <optimized out>
        out_buf = "C9\000\000\000\000\000\000 p\034\334\377\177\000\000\000\000\000\000\000\000\000\000@\244\210\004\000\000\000\000@s\311VUU\000\000\000\003홨\"\261\065`\003\000\353\377\177\000\000\b\000\000\000\000\000\000\000@\244\210\004\000\000\000\000\360\003\000\353\377\177\000\000h\376\377\377\377\377\377\377 p\034\334\377\177\000\000\016p\375\367\377\177\000\000S+\254UUU\000\000\b\000\000\000\000\000\000\000\260\"\265VUU\000\000\340\353\377\377\377\177\000\000\b\000\000\000\000\000\000\000@\244\210\004\000\000\000\000\000\003홨\"\261\065\357\200H", '\000' <repeats 13 times>, "\360\003\000\353\377\177\000\000\000\360\377\377\377\377\017\000\357\200H\000\000\000\000\000\210K\300UUU"...
        tmp_hex_buf = 0x7fffeb000310 "C9"
        res = 0x555555ac21c7 <flatview_read_continue+119> "L\001\365M\001\364L)\363\017\204Q\001"
        env = <optimized out>
        __func__ = "format_strcmp"
        rip = <optimized out>
        __PRETTY_FUNCTION__ = "format_strcmp"
#1  0x0000555555c0f948 in test_strcmp (arg1=140737136034976, arg1@entry=140737353969678, arg2=arg2@entry=4751599) at /usr/src/QEMU-Nyx/nyx/redqueen.c:1002
        cpu = 0x555556c97340
        buf1 = "ɵ\032<\237b22\032\062\062\016\020g\022UUU\000YXﾭ\300\000\000\000\357\276ޭ\276", '\363' <repeats 23 times>, "\255\336쭾\357\256", <incomplete sequence \374>
        buf2 = "PWNED!!!\000Something went wrong\n\000This should never happen :)\n\000xeon"
        __PRETTY_FUNCTION__ = "test_strcmp"
#2  0x0000555555c10024 in test_strcmp_sys_v () at /usr/src/QEMU-Nyx/nyx/redqueen.c:1035
        env = <optimized out>
        arg1 =<PHONE_NUMBER>69678
        arg2 = 4751599
        __func__ = "test_strcmp_sys_v"
        mode = 1
        cpu = <optimized out>
        env = <optimized out>
        insn = 0x7fffdc1e3d00
        ins_size = 5 '\005'
        ip = <optimized out>
        code = 4202854
        failed_page =<PHONE_NUMBER>3709551615
        __func__ = "handle_hook_breakpoint"
        __PRETTY_FUNCTION__ = "handle_hook_breakpoint"
#3  extract_call_params () at /usr/src/QEMU-Nyx/nyx/redqueen.c:1043
        mode = 1
        cpu = <optimized out>
        env = <optimized out>
        insn = 0x7fffdc1e3d00
        ins_size = 5 '\005'
        ip = <optimized out>
        code = 4202854
        failed_page =<PHONE_NUMBER>3709551615
        __func__ = "handle_hook_breakpoint"
        __PRETTY_FUNCTION__ = "handle_hook_breakpoint"
#4  handle_hook_redqueen_light (self=<optimized out>, ip=<optimized out>, insn=0x7fffdc1e3d00) at /usr/src/QEMU-Nyx/nyx/redqueen.c:1058
        mode = 1
        cpu = <optimized out>
        env = <optimized out>
        insn = 0x7fffdc1e3d00
        ins_size = 5 '\005'
        ip = <optimized out>
        code = 4202854
        failed_page =<PHONE_NUMBER>3709551615
        __func__ = "handle_hook_breakpoint"
        __PRETTY_FUNCTION__ = "handle_hook_breakpoint"
#5  handle_hook_breakpoint (self=<optimized out>, write_data=true) at /usr/src/QEMU-Nyx/nyx/redqueen.c:1105
        mode = 1
        cpu = <optimized out>
        env = <optimized out>
        insn = 0x7fffdc1e3d00
        ins_size = 5 '\005'
        ip = <optimized out>
        code = 4202854
        failed_page =<PHONE_NUMBER>3709551615
        __func__ = "handle_hook_breakpoint"
        __PRETTY_FUNCTION__ = "handle_hook_breakpoint"
#6  0x0000555555c1203c in handle_hook (self=0x555557a6a790) at /usr/src/QEMU-Nyx/nyx/redqueen.c:1142
        cpu = <optimized out>
        __func__ = "handle_hook"
        env = <optimized out>
#7  0x0000555555c1cef4 in handle_hypercall_kafl_hook (run=run@entry=0x7ffff7fc9000, cpu=cpu@entry=0x555556c97340, hypercall_arg=<optimized out>) at /usr/src/QEMU-Nyx/nyx/hypercall/hypercall.c:664
        i = <optimized out>
        cpux86 = <optimized out>
        __func__ = "handle_hypercall_kafl_hook"
        env = <optimized out>
#8  0x0000555555b3c737 in kvm_cpu_exec (cpu=cpu@entry=0x555556c97340) at /usr/src/QEMU-Nyx/accel/kvm/kvm-all.c:2682
        attrs = {
          unspecified = <optimized out>,
          secure = <optimized out>,
          user = <optimized out>,
          requester_id = <optimized out>,
          byte_swap = <optimized out>,
          target_tlb_bit0 = <optimized out>,
          target_tlb_bit1 = <optimized out>,
          target_tlb_bit2 = <optimized out>
        }
        run = <optimized out>
        ret = <optimized out>
        run_ret = <optimized out>
        timeout_reload_pending = false
        __PRETTY_FUNCTION__ = "kvm_cpu_exec"
        __func__ = "kvm_cpu_exec"
#9  0x0000555555b14b0c in qemu_kvm_cpu_thread_fn (arg=0x555556c97340) at /usr/src/QEMU-Nyx/cpus.c:1318
        r = <optimized out>
        cpu = 0x555556c97340
        r = <optimized out>
#10 qemu_kvm_cpu_thread_fn (arg=arg@entry=0x555556c97340) at /usr/src/QEMU-Nyx/cpus.c:1290
        cpu = 0x555556c97340
        r = <optimized out>
#11 0x0000555556054a73 in qemu_thread_start (args=0x7fffeb0006b0) at util/qemu-thread-posix.c:519
        __cancel_buf = {
          __cancel_jmp_buf = {{
              __cancel_jmp_buf = {0, -6175150794332906818,<PHONE_NUMBER>43454,<PHONE_NUMBER>43455,<PHONE_NUMBER>35840, 8396800, -65286209092396354, -6175151406121821506},
              __mask_was_saved = 0
            }},
          __pad = {0x7fffeb000750, 0x0, 0x0, 0x0}
        }
        __cancel_routine = 0x555556054ad0 <qemu_thread_atexit_notify>
        __not_first_call = <optimized out>
        start_routine = 0x555555b14a10 <qemu_kvm_cpu_thread_fn>
        arg = 0x555556c97340
        r = <optimized out>
#12 0x00007ffff6a24ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = {
          cancel_jmp_buf = {{
              jmp_buf = {140737136056064,<PHONE_NUMBER>5213630,<PHONE_NUMBER>43454,<PHONE_NUMBER>43455,<PHONE_NUMBER>35840, 8396800, -65286209098687810, -65243037933315394},
              mask_was_saved = 0
            }},
          priv = {
            pad = {0x0, 0x0, 0x0, 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = 0
#13 0x00007ffff6944a2f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
pwndbg>

But kafl doesn't insert findings to corpus.
Any advices?
Thanks.


React-native link does not work with v2.0.0

Doing the install process with version 2.0.0 the link with the libBugsnagReactNative.a stops working. With v1.2.2 works perfectly

Thanks for the report, @iuraya. v2.0.0 has a peer dependency on React Native 0.40 and above. Can you provide the React Native version to ensure the project is compatible? Otherwise there should be a warning indicating that the peer dependency is unmet when the bugsnag package is installed.

My react native version is 0.33.0

Thanks! Downgrading to 1.2.3 should fix your issue.


Update kubernetes-mixin to remove KubeAPILatencyHigh & KubeAPIErrorsHigh

Both alerts have since been superseded by the KubeAPIErrorBudgetBurn alert. Check upstream discussions for more details.

Could you link to upstream discussions? That would be much appreciated! :bowtie:

https://github.com/kubernetes-monitoring/kubernetes-mixin/pull/451 &
https://github.com/kubernetes-monitoring/kubernetes-mixin/pull/382


Debug is broken when use CRLF line break

Reproduce:

yarn create vite with React and Typescript

edit App.tsx like this:

/*

these empty lines in the comment block will break debugging

*/

export default function App() {
	console.log('App');  // breakpoint here
	return (
		<div>
			test
		</div>
	)
}

Change App.tsx line break to CRLF
Set breakpoint at line console.log('App');
Start debug, but breakpoint hit at a weird place:

If set breakpoint at devtool, it get misplaced.

I have tested // comment and function to consume top lines, but seems only /* */ break debug.
If change line break to LF, everything is fine.
vite-plugin-react has no such problem.

Here is my launch.json:
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Launch Chrome against localhost",
      "url": "http://localhost:5173",
      "webRoot": "${workspaceFolder}/src" // This works, but i still don't know why after a lot of search. CRA and esbuild+liveserver also only works with this path.
    }
  ]
}

vite.config.ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react-swc'
export default defineConfig({
  plugins: [react()],
  server: {
    host: '<IP_ADDRESS>' // the default 'localhost' makes browser and vscode fails to fetch sourcemap, due to some CORS error, idk why.
  }
})

Sysinfo:

Click to expand!
  System:
    OS: Windows 10 10.0.22623
    CPU: (16) x64 AMD Ryzen 7 4800H with Radeon Graphics
    Memory: 10.07 GB / 31.87 GB
  Binaries:
    Node: 18.12.1 - ~\AppData\Local\Temp\xfs-dce58dc0\node.CMD
    Yarn: 3.3.0 - ~\AppData\Local\Temp\xfs-dce58dc0\yarn.CMD
    npm: 7.24.1 - D:\Documents\_JavaScript\node_global\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.1037.0), Chromium (108.0.1462.54)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @vitejs/plugin-react-swc: ^3.0.0 => 3.0.1
    vite: ^4.0.0 => 4.0.2

Blocked by upstream: https://github.com/swc-project/swc/issues/6694
kdy1 assigned recently so maybe this can be fixed quickly.
Keeping open, but I would advice using linux line break everywhere anyway. I think this can be enforced by Prettier or git.

Fixed upstream


Bug

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

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

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

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

Additional context
Add any other context about the problem here.
Wallet address
ERC20 wallet for POZ rewards

There is no information here

There is no information here


brew update fails to find git

Bug reports:
I'm attempting to "brew update" on my macOS 10.11.5 machine, with a fully-functional git-2.9.1 installed (via homebrew.)  I get warning about git-2.9.1 already being installed, followed by an error that git must be installed.

; brew update
Warning: git-2.9.1 already installed
Error: Git must be installed and in your PATH!
Exit 1

This continues if I remove git (I had several bottled versions lying around) and reinstall, and if I uninstall git and leave it for `brew update':

; brew update
==> Downloading https://homebrew.bintray.com/bottles/git-2.9.1.el_capitan.bottle.tar.gz
Already downloaded: /Users/yandros/Library/Caches/Homebrew/git-2.9.1.el_capitan.bottle.tar.gz
==> Pouring git-2.9.1.el_capitan.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
zsh completion has been installed to:
/usr/local/share/zsh/site-functions
Emacs Lisp files have been installed to:
/usr/local/share/emacs/site-lisp/git
==> Summary
🍺  /usr/local/Cellar/git/2.9.1: 1,427 files, 31.3M
Error: Git must be installed and in your PATH!
Exit 1

brew doctor' reports nothing other than the warning that I haven't run brew update' in a long time.

cd $(brew --prefix) && git fetch && git reset --hard origin/master

Will only need to execute that once & you'll be okay afterwards. You can also brew rm git if you're happy with the system git; was never intentionally made mandatory.

Worked like a charm; thanks!


Implement nullish coalescing operator in parser

Q
A

Bug fix?
no

Breaking change?
no

New feature?
yes

Deprecations?
no

Spec compliancy?
yes

Tests added/pass?
yes

Fixed tickets

License
MIT

Adding the parser for the nullish coalescing operator, a ?? b, currently at stage 1.
In the AST it isn an operator under BinaryExpression. Should it move to LogicalExpression?
Picked the plugin name: "nullishCoalescingOperator". It's a bit of a mouthful, and may well change.
Ref: https://github.com/babel/proposals/issues/14
Proposal: https://github.com/gisenberg/proposal-null-coalescing
Proposal will likely be renamed from nullary to nullish, see https://github.com/gisenberg/proposal-null-coalescing/issues/3.
I feel like I haven't added enough tests, but I'm not too sure of the edge cases I should test, let me know if you know of any!

For the tests, I would check https://github.com/babel/babylon/pull/742/files which is similar
Could do chained so a ?? b ?? c or multiline, or precedence check

cc @littledan

Fine with merging now if we can get a PR for tests next, (logic shouldn't be any different)

new PR https://github.com/babel/babylon/pull/762, should probably be LogicalExpression instead of BinaryExpression


ai_simulator_remote

can't find the  folder ai_simulator_remote, so i can't finish the step of "Please put the license.dat under the folder:hok_env_gamecore/gamecore/core_assets and add the path of the folder ai_simulator_remote to the system environment variables."
Does anyone know how to fix this problem? Thanks.

ai_simulator_remote  has been removed.
https://github.com/tencent-ailab/hok_env/issues/17#issuecomment-1407932876
https://github.com/tencent-ailab/hok_env/issues/26#issuecomment-1438337267


One-shot tool prompting

Recently I moved to newer version of openai-scala-client and after some time of ridding of deprecated declarations, discovered that my code does not work any more. Later I found that the problem is with AssistantToolMessage class which makes this code snipped not working (respond is never received). But when I use deprecated AssistantFunMessage, everything works fine. Could someone make a guess why this is going on, please?
  def completeFunctionTask() = {
    val funcSchema = FunctionSpec(
      "result",
      parameters = Map(
        "type" -> "object",
        "properties" -> Map(
          "words" -> Map(
            "type" -> "array",
            "description" -> "words with emotional connotations",
            "items" -> Map(
              "type" -> "object",
              "description" -> "word",
              "properties" -> Map(
                "word" -> Map("type" -> "string", "description" -> "word text"),
              ),
              "required" -> Seq("word")
            )
          )
        )
      )
    )
    val answer = "{\"words\":[{\"word\":\"grateful\"},{\"word\":\"joy\"},{\"word\":\"happiness\"}]}"
    val messages: Seq[BaseMessage] = Seq(
      SystemMessage("You get a text in the form of a word list. Pick words with emotional connotations."),
      UserMessage("[\"We\",\"are\",\"grateful\",\"even\",\"before\",\"we\",\"have\",\"something.\",\"Flowers\",\"always\",\"bring\",\"joy\",\"and\",\"happiness.\"]"),
      AssistantToolMessage(Option.empty, Option.empty, Seq(("call_1", FunctionCallSpec(funcSchema.name, answer)))), // doesn't work with this line
//      AssistantFunMessage(Option.empty, Option.empty, Option(FunctionCallSpec(funcSchema.name, answer))), // works fine with this line
      UserMessage("[\"I'm\",\"lucky\",\"to\",\"be\",\"here\",\"with\",\"you.\"]")
    )

    val createChatCompletionSettings = CreateChatCompletionSettings(model = "gpt-3.5-turbo")
    service.createChatToolCompletion(messages, Seq(funcSchema), Option.apply(funcSchema.name), createChatCompletionSettings).map(resp => {
      println(resp.choices(0).message) // {"words":[{"word":"lucky"}]}
    })

  }

Hey @0sten , I would rename call_1 to result_1 since the name of your function is result. If it doesn't work will take a look.

@peterbanda thank you for the answer. Unfortunately renaming call_1 to result_1 didn't help.

ok, will check briefly

Hi @0sten,
thank you for reporting your issues.
By any chance, did you have any exceptions in your console?
For your example, I'm getting this one:
io.cequence.openaiscala.OpenAIScalaClientException: Code 400 : {
  "error": {
    "message": "An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: call_1",
    "type": "invalid_request_error",
    "param": "messages",
    "code": null
  }
}

you can resolve it by providing a tool message:
  ...
  AssistantToolMessage(
     Option.empty,
     Option.empty,
     Seq(("call_1", FunctionCallSpec(funcSchema.name, answer)))
   ), // doesn't work with this line
   ToolMessage(
     tool_call_id = "call_1",
     name = funcSchema.name,
     content = Some(answer)
   ),
   UserMessage("[\"I'm\",\"lucky\",\"to\",\"be\",\"here\",\"with\",\"you.\"]")
   ...

Does this resolve your issue?
For further details about tool calling, have a look at our example CreateChatToolCompletionWithFeedback.

Considered resolved. Closing


how to retry the request when timeout

retrywhen operator? or other simple ways?

Let's handle this back where you started, in #1404


Integration Test - Release - 2020/09/25 17:38:14

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@lamebrain : Thanks for your contribution! The author(s) have been notified to review your proposed change.


UI Indicators

Add badge indicators when we fall back to non-lsif code intel.

@ryan-blunden I'm updating the PR description to show a gif of it in-action. See also https://github.com/sourcegraph/sourcegraph/pull/7261.
As for the exact text, icon, and icon color, that's all up to the (this) extension and can be updated very easily between sourcegraph versions.

cc @christinaforney
Here's the current styles. There's only one badge that happens regardless if LSIF is available or not (for now). I plan on making different badges/text for different conditions (no LSIF on symbol, no LSIF for repository, diff on symbols, etc).
Is this an acceptable first-step? Once merged, the dot-com UI will display these tooltips immediately as that code has already made it in.

@christinaforney Feature flags are in master. Is this good to go?


Update scala3-library to 3.1.0 in series/0.22

Updates org.scala-lang:scala3-library from 3.0.2 to 3.1.0.
GitHub Release Notes - Version Diff - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala3-library" } ]

labels: library-update, semver-minor

Alternative is #5389.


pythonPackages.osmnx: init at 0.8.2

Motivation for this change
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@grahamcofborg build pythonPackages.osmnx

Success on x86_64-linux (full log)
Attempted: pythonPackages.osmnx
Partial log (click to expand)
Installing collected packages: osmnx
Successfully installed osmnx-0.8.1
/build/source
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/05az4wkq4abksmbjc7rgdy66qzb0h42d-python2.7-osmnx-0.8.1
strip is /nix/store/dxf1m7dhc4qb655bdljc1fsd74v1nag3-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/05az4wkq4abksmbjc7rgdy66qzb0h42d-python2.7-osmnx-0.8.1/lib
patching script interpreter paths in /nix/store/05az4wkq4abksmbjc7rgdy66qzb0h42d-python2.7-osmnx-0.8.1
checking for references to /build in /nix/store/05az4wkq4abksmbjc7rgdy66qzb0h42d-python2.7-osmnx-0.8.1...
/nix/store/05az4wkq4abksmbjc7rgdy66qzb0h42d-python2.7-osmnx-0.8.1

Failure on aarch64-linux (full log)
Attempted: pythonPackages.osmnx
Partial log (click to expand)
    return self.values[slicer]
  /nix/store/dsl1zn5j39iwc1dgmkndazn48mcyps0y-python2.7-pandas-0.23.4/lib/python2.7/site-packages/pandas/core/indexes/datetimelike.py:428: FutureWarning: Using a non-tuple sequence for multidimensional indexing is deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be interpreted as an array index, `arr[np.array(seq)]`, which will result either in an error or a different result.
    result = getitem(key)

-- Docs: https://docs.pytest.org/en/latest/warnings.html
 5 failed, 16896 passed, 1030 skipped, 11887 deselected, 37 xfailed, 2 xpassed, 6 warnings in 592.54 seconds
builder for '/nix/store/khzgx4hmpgl197sbxbygwmn9kxpnmyf0-python2.7-pandas-0.23.4.drv' failed with exit code 1
cannot build derivation '/nix/store/kdzdr4dikzd5410aqqzf44favy8rq7q3-python2.7-geopandas-0.4.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/bswrmii4vz8al73gnw0haxx5lnzccdb0-python2.7-osmnx-0.8.1.drv': 2 dependencies couldn't be built
error: build of '/nix/store/bswrmii4vz8al73gnw0haxx5lnzccdb0-python2.7-osmnx-0.8.1.drv' failed

Failure on x86_64-darwin (full log)
Attempted: pythonPackages.osmnx
Partial log (click to expand)
/nix/store/bqivpznjpsl273sxhhlnqn6qhsihd4nb-python2.7-Fiona-1.7.13/lib/python2.7/site-packages/fiona/__init__.py:69: in <module>
    from fiona.collection import Collection, BytesCollection, vsi_path
/nix/store/bqivpznjpsl273sxhhlnqn6qhsihd4nb-python2.7-Fiona-1.7.13/lib/python2.7/site-packages/fiona/collection.py:8: in <module>
    from fiona import compat
E   ImportError: cannot import name compat
!!!!!!!!!!!!!!!!!!! Interrupted: 16 errors during collection !!!!!!!!!!!!!!!!!!!
=========================== 16 error in 1.16 seconds ===========================
builder for '/nix/store/vplg8rj4z1ynmdaalwhwsln18pskcx4r-python2.7-geopandas-0.4.0.drv' failed with exit code 2
cannot build derivation '/nix/store/4lr1dmslzyl6hcqb6filx9nq4j91lkc6-python2.7-osmnx-0.8.1.drv': 1 dependencies couldn't be built
error: build of '/nix/store/4lr1dmslzyl6hcqb6filx9nq4j91lkc6-python2.7-osmnx-0.8.1.drv' failed

@matthewbauer The failure in Darwin is due to geopandas and not to osmnx


Overhaul rootPath support

Motivation

There are a couple problems:

Sorbet somewhat artificially only supports a single input directory in LSP
mode. There's no good reason why that needs to be the case, and people
frequently complain about it.
Sorbet doesn't actually work in LSP mode if the --dir is not .. Certain
things like errors will show up, but other things like go to definition will
go to the wrong places, because those errors and jump to definition targets
will be missing the subdir/ prefix in their relative path.
This lets us delete other code, like the various hacks we have to
retroactively hide all the ./ prefixes that we forcibly prefix all paths
with.

This fixes all of them.
Test plan

I have been testing this manually as I've gone along, but it needs more testing.

@jez, would you mind explaining why this PR was closed? It looks like there might be some unanswered questions surrounding watchman. Is that the main hurdle to clear?

It didn’t work and I don’t remember why, sorry :/


OSCI: Adds new author rahulsiddharth

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

Looks good!

Also, you may need to sign each commit - see https://github.com/opensearch-project/project-website/pull/2118/checks?check_run_id=17025364656 for instructions to fix.

@908rahul can you do the following to fix DCO?

In your local branch, run: git rebase HEAD~2 --signoff
Force push your changes to overwrite the branch: git push --force-with-lease origin chore/add-author-908rahul

@908rahul can you do the following to fix DCO?

In your local branch, run: git rebase HEAD~2 --signoff
Force push your changes to overwrite the branch: git push --force-with-lease origin chore/add-author-908rahul

Sounds good, but I wanted to confirm which local branch I should perform this command on, so that I don't mess anything more up. I have two branches. The one "chore/add-author-908rahul" is my original branch, but I decided to move away from it because I had entered a git rabbit hole which I did not know how to get out of. This is where the merge and weird commits come from because I created them from looking at stack overflow.  I created a new branch called "rahulBranch2" which all my commits come from now.

Closing as resolved in another branch


Set log.Default's output to io.Discard

Description of your changes

Fixes #974
Fixes #854
This PR sets a default io.Discard logger for the controller-runtime if debug logging is not enabled. If debug logging is enabled, then the controller-runtime uses a debug mode zap logger as usual.
It also sets the log.Default's output to io.Discard. According to our experiments with a VPC.ec2 and a Cluster.eks, this prevents the noisy logs from the underlying Terraform provider. We still need to check for direct log messages via the fmt variants, such as fmt.Println.
In a further iteration, we will also consider making the underlying provider's logs available in a structured format.
This PR also switches to the standard-runners branch of upbound/uptest because the larger runners are not available in the crossplane-contrib organization.
I have:

[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Tested manually with VPC.ec2 & Cluster.eks example manifests. The Cluster.eks has dependencies from the ec2 & iam API groups.

/test-examples="examples/ec2/vpc.yaml"

The linter job is expected to fail on this branch. And @turkenf has successfully ran make lint on his local machine for this PR.
The failure of the publish-artifacts is also expected on the standard hosted runners. That job has been covered by running a successful uptest here.


Label Prefix / Top Margin

We use Demco Label A-22 with 98 labels per sheet.
While the labels are meant to be 3/4" tall and 1" wide, we use them as though they are 1" tall and 3/4" wide, giving us 14 columns and 7 rows.
Here are my template settings:

Here is my layout. Note that I am using portrait in the layout. This seems to be crucial for getting the labels to run top to bottom as desired.

Then when I send the labels to a printer, I select landscape:

With those settings, I am able to get labels that print almost correctly; however, the printed text starts too low in the label and I probably need to do some more work on the left margin. As far as the top margin, it is almost as if adding the Label Prefix to the mix includes a break or paragraph before the label prefix. Is that possible? If so, can it be removed (or controlled by the end user)? Any other suggestions for how I might manipulate the settings to get the desirable outcome?

In the desktop Spine-o-Matic App, these settings work beautifully:

Hi @SWITCHconsortium - thank for your question. Based on feedback, you need to try to set your printer margins to 0. Each OS/Browser handles it differently. Here is how it looks on Chrome:

Perhaps it's in the "Advanced" section of the "Printing Preferences" screen you showed?
Let us know how it goes.

I'm looking online for Demco A-11 or A-22 labels, but I can't find a template for this description. Is there another number that they go by?

'Colored Processing Labels 1-1/2" x 1" Square Corners"' works for me.
Update: After some adjusting, it looks like Firefox and my printer give a .25" margin by default. So for the left and right, I had to set the margin to zero and make sure that it stayed at 0 when I went to the print dialog.
Top padding remains an issue.

I downloaded the MS Word template, then used this layout.

It seemed to work ok.

I set Chrome to print 100% with no margins.

Hi @jmcleod-mu - thanks for the additional information. I think you're right- the p does have some styling associated with it. We released a new version which removes the top margin from p. (I hope this doesn't mess up others templates)
I'm printing on A4 paper set to Letter, hence the big margin at the bottom. I’ve only tested on Chrome but I assume/hope it would work similarly on Firefox. Unfortunately this all takes a bit of trial and error so give it a try on Chrome as well and let us know how it goes.

Closing this issue due to lack of activity. If the problem still exists, please open a new issue.


Translate publish mail according to the laguages of the speakerin

Now the speakerin gets the publish mail in english and german, it would be good to have that sorted out.

done


[Crash]  2.0.1 not working with 1.20.1 ~ Fabric

I tried to run Armorful 2.0.1 on 1.20.1 but it doesnt load
( On Modrinth its tagged with 1.20.1 )
latest.log

Modify the fabric.mod.json, ill release a hotfix later.

When does the hotfix come?


Removed the -ForceRefresh switch that's no longer supported in v2

Fixes #365.

@peombwa - please review this.

@timayabi2020 - please merge this.


Add SSH connect

Hello there:
I am a loyal fan of sftp, I think it is great, but there are some requirements that can't satisfy me, that is, without the ssh function. When I work, I often use ssh, but it doesn't. I need ssh ”root@domain 22” to link ssh. Can you add this feature? For example: ctrl+shift+p --> SSH-TO-SERVER?
My English is very poor, please forgive me, thank you!
Hypdncy

Duplicate of #341.


doesn't work with Java 1.8.0u60+

Error. The file that failed to upload was: myfile.zip: com.amazonaws.services.s3.model.AmazonS3Exception: AWS authentication requires a valid Date or x-amz-date header (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 57AA61B01343B3F5), S3 Extended Request ID: yVPcAUGXiavNSweucDwg5LW0oxGXsuD7M+h/amOFPagsg6qlxjDmLRkBfjIqYGnR2IWM7n8qf7k=

The same build with the same keys works on Java 1.7

seems to be the same issue: https://stackoverflow.com/questions/32058431/aws-java-sdk-aws-authentication-requires-a-valid-date-or-x-amz-date-header/37694343
This library embeds the aws sdk version 1.9.24 which no longer works with the latest java.
Apparently v 1.11.52+ is required.

https://github.com/aws/aws-sdk-java/issues/484


element.screenshot() captures wrong area in non-headless mode

Steps to reproduce
When using element.screenshot() Puppeteer produces different results in headless/non-headless mode. The headless screenshot is correct, the non-headless image captures the wrong screen region.

Puppeteer version: 10.2.0
Platform / OS version: MacOS BigSur (11.5.2)
URLs (if applicable): -
Node.js version: v14.15.4

What steps will reproduce the problem?
Use the following test script to generate two screenshots:
const puppeteer = require('puppeteer');

async function test_screenshot(browser, name) {
  const page = await browser.newPage();
  await page.goto('https://google.com');

  await page.waitForSelector('.W2aPtb');
  const logo = await page.$('.W2aPtb');
  await logo.screenshot({path: name});
  await browser.close();
}

// Testcase 1: Screenshot in headless mode.
(async () => {
  const browser = await puppeteer.launch({ headless: true });
  await test_screenshot(browser, 'image-headless.png');
})();

// Testcase 2: Screenshot in non-headless mode.
(async () => {
  const browser = await puppeteer.launch({ headless: false });
  await test_screenshot(browser, 'image-not-headless.png');
})();

Result
The above snippet should result in identical two images, but the result is the following:

image-headless.png (correct)

image-non-headless.png (wrong)

Image dimensions are correct, but the snap-region is too far down/right

Comparison:

I also encountered this issue. The offset appears to be equal to the displacement of the viewport from the top-left corner of the physical display. (Or, at least that's how it appears when using a single-monitor X11 setup). If I move the window to align the viewport with the screen's corner, the screenshot captures the correct region.
I believe it has been broken since puppeteer v10.2.0, due to the following change:
https://github.com/puppeteer/puppeteer/pull/7390/files#diff-3c9735f4a6d946de9c02aef89aa2feb6d3dfd8c7f524aeaffed3967e52a85560L426
Prior to this, puppeteer used the similar layoutViewport property, which (as far as I've tested) produced pageX and pageY values of 0 (in the absence of scrolling). This change switched to using cssLayoutViewport, which (as far as I've tested) sets pageX and pageY to the displacement of the viewport from the corner of the screen (in the absence of scrolling). When scrolling is involved, these values both seem to increase by the scrolled amount (though, the intended and actual metric is unclear to me).
These pageX and pageY values are subsequently added to the clipping position (clip.x, clip.y), hence why the screenshot region is misaligned.
When running in a headless environment, this displacement from the corner of the screen appears irrelevant, with pageX and pageY equal to 0 (in the absence of scrolling), hence why it works fine in a headless setup.
I'm not familiar with the intended semantics of layoutViewport and cssLayoutViewport. Their documentation is slightly confusing:
https://chromedevtools.github.io/devtools-protocol/1-3/Page/#method-getLayoutMetrics
https://chromedevtools.github.io/devtools-protocol/1-3/Page/#type-LayoutViewport

offset relative to the document (CSS pixels)

I would have assumed that should mean zero when there is no scrolling involved, as the document would be placed exactly where the physical viewport is. It's very unclear to me how scrolling when zoomed should affect this value.
I'm not certain as to whether this is a bug originating from puppeteer, the dev tools protocol, or chromium.

I'm using version 19.1.1
only when headless is false, I get the correct screenshot.
(Wrong [headles => true] : What I get)

(Correct [headles => false] : What I want )

I'm using v22.2.0 and solve by using boundingBox function. See https://pptr.dev/api/puppeteer.elementhandle.boundingbox
The boundingBox is return { x: positionX, y: positionY, width: widthOfElement, height: heightOfElement }. It can use for the clip option for the screenshot function
const element = await mainFrame.$("element-selector");
const boundingBox = await element.boundingBox();

if (boundingBox) {
  const clip = {
    x: boundingBox.x,
    y: boundingBox.y,
    width: boundingBox.width,
    height: boundingBox.height,
  };
  await page.screenshot({ path: "image.png", clip: clip });
}


@responseFile generates weird example response

I love the new features in v3 - thanks everyone. I'm having a bit of trouble, however, with the new @responseFile tag.
Here's my docblock:
/**
 * @responseFile responses/register.json
 * @responseFile 400 responses/register.400.json
 * @responseFile 422 responses/register.422.json
 */
and here's what it generates:

Any idea what I'm doing wrong?
Thanks!

Hmmm. Can you share the contents of those files?

Sure - forgot that part, sorry. I've changed the names since, so for this new codeblock:
/**
* @responseFile responses/subscriber.json
* @responseFile 400 responses/register.400.json
* @responseFile 422 responses/validation.failed.json
*/
I use these files:
Sample-Responses.zip
Thanks!


Add literary awards entity 15

Summary of change
Added awards entity with awardName as an enum.
Added a query to get all books that have won a certain award
Added mutations to add or delete awards
DB migration:
Added 2 books through INSERT_BOOKS.sql to showcase the books-awards link
Related issue
Closes #15
Pull request checklist
Please keep this checklist in & ensure you have done the following:

[x] Read, understood and adhered to our contributing document.

[x] Ensure that you were first assigned to a relevant issue before creating this pull request
[x] Ensure code changes pass all tests

[x] Read, understood and adhered to our style guide. A lot of our code reviews are spent on ensuring compliance with our style guide, so it would save a lot of time if this was adhered to from the outset.

[x] Filled in the summary, context (if applicable) and related issue section. Replace the square brackets and its placeholder content with your contents. For an example, see any merged in pull request

[x] Created a branch that has a descriptive name (what your branch is for in a few words and includes the issue number at the end, e.g. test-reading-goal-123

[x] Set this pull request to 'draft' if you are still working on it

[x] Resolved any merge conflicts

For any of the optional checkboxes (e.g. the screenshots one), still check it if it does not apply.
If in doubt, get in touch with us via our Slack workspace or by creating a new Q&A discussion on GitHub

@hpa16 Could you also please resolve the merge conflicts? Thanks!

@knjk04 I'm having some problems merging it into this branch. Let me close this and create a new PR with the latest code.

Opened a new PR: #142


Fix #6: Verbose mode

Implements #6.

It's not 100% complete though. I'll feel better when we have tests for the headers and body json cases. In fact, those currently only respond with { key }, I didn't even try to parse path or versions.


security: Limit ability of synthetic nodes to spread throughout network. Credit: Ziggurat Team

Motivation
"RT-S1 f1" from "Red Team report on Zcash testnet"

Zebra accepts peers from its peers much more easily when compared with the zcashd node. This behavior allows synthetic nodes (which do not do much in the network) to spread quite fast throughout the testnet network.
But at least Zebra doesn’t share all peers in the Addr message. It always shares a portion of its peers.

And
"RT-S1 f2" from "Red Team report on Zcash testnet"

Bad behavior
Zcashd also spreads synthetic nodes, but more slowly.
The node will always share all IPs to which it has connections.
Good behavior
Time to accept new peers is much slower because:

a zcashd node randomly processes a single node per Addr message.
A zcashd node spreads peers more carefully - it will never share more nodes from the same IP. Once it decides which node (identified by IP and port) will be shared, it always shares that same node. Even if zcashd has more connections to nodes from the same IP, it will only share a single node in the peer list.

Specifications
No response
Complex Code or Requirements
No response
Potential Fixes
Before starting work, discuss the impact of each potential fix on this vulnerability with the team, and decide on 1-3 fixes that have the greatest impact:

[ ] Limit the number of addresses taken from any one peer to less than half the outbound connection limit
[ ] Keep the un-taken addresses from that peer in case we need more, always keep the latest N unique addresses from each connected peer
[ ] When a peer is disconnected, send its addresses as NeverAttemptedAlternate (or a new status that is a lower priority than failed, or move NeverAttemptedAlternate to a lower priority than failed)
[ ] #7823
[ ] TODO: add more fixes?

Testing
No response
Related Work
No response

A good first step would be listing our existing defences against this attack. Note that some of Zebra's behaviour in the report is outdated.
@mpguerra who would you like to do that work?

Our previous analysis of this issue is in ticket #1869, where we listed our defences at the time, and decided they were good enough.

I think this was closed by mistake

Hey team! Please add your planning poker estimate with Zenhub @arya2 @oxarbitrage @teor2345 @upbqdn

I estimated this ticket assuming that we'd choose 1-3 potential fixes from the list of suggested fixes, and not do all of them.

Limit the number of addresses taken from any one peer to less than half the outbound connection limit
Keep the un-taken addresses from that peer in case we need more, always keep the latest N unique addresses from each connected peer

Could we re-open #1869 for these fixes and convert this one to a tracking issue?

When a peer is disconnected, send its addresses as NeverAttemptedAlternate (or a new status that is a lower priority than failed, or move NeverAttemptedAlternate to a lower priority than failed)

It could also send any excess addresses as NeverAttemptedAlternate when they're received, but ignore them in the outbound connector until there haven't been any other candidates for a few minutes.

When a peer is disconnected, send its addresses as NeverAttemptedAlternate (or a new status that is a lower priority than failed, or move NeverAttemptedAlternate to a lower priority than failed)

It could also send any excess addresses as NeverAttemptedAlternate when they're received, but ignore them in the outbound connector until there haven't been any other candidates for a few minutes.

If the goal is to delay connecting to these peers until we've tried other more reliable/secure peers, then marking them as alternate already does that. So I'm not sure I want to add more code that introduces similar behaviour using a different mechanism. That seems like it would make any bugs harder to diagnose.
https://github.com/ZcashFoundation/zebra/blob/f2b1737edd7dc4395de12fd4adf1de45dd409355/zebra-network/src/meta_addr.rs#L125-L152
I'm also cautious about adding more state to a system that's already complex. This part of the code has a history of hangs, so I'm particularly cautious of adding further delays.
We already use the version message and remote IP address of inbound connections to create alternate peers. So this change would also change the behaviour of those addresses.

Could we do just these fixes here, or re-open #1869 for these fixes and convert this one to a tracking issue if we want to do more?

I've re-opened and updated #1869, some of the designs in it actually made this problem worse. (So I'm glad we waited this long to implement it.)
Before we start work or open tickets, let's:

add any other suggested fixes to the list
discuss the impact of each potential fix on this vulnerability with the team, and decide on 1-3 fixes that have the greatest impact

I've added your suggestion to the list, and added some benefits and drawbacks.

What do you think of this suggestion?

Limit the number of addresses taken from any one peer to less than half the outbound connection limit

I can't see anywhere we limit the number of peers, so the current limit is the 1000 peer protocol limit.

What do you think of this suggestion?

Limit the number of addresses taken from any one peer to less than half the outbound connection limit

I can't see anywhere we limit the number of peers, so the current limit is the 1000 peer protocol limit.

It looks like the only strictly-required fix for this issue and it's important that addresses be selected at random.

Ok, I've marked that as a required change, and added some benefits and drawbacks.
These changes seem similar, so let's discuss them together. What do you think their benefits and drawbacks are?

Keep the un-taken addresses from that peer in case we need more
Always keep the latest N unique addresses from each connected peer

These changes seem similar, so let's discuss them together. What do you think their benefits and drawbacks are?

Keep the un-taken addresses from that peer in case we need more

Zebra will find peers faster if we keep all of the addresses, and will drop the NeverAttemptedAlternate addresses first when the address book is full.
May use more memory if stored per connection.

Always keep the latest N unique addresses from each connected peer

I'm not sure what this means.

When a peer is disconnected, send its addresses as NeverAttemptedAlternate (or a new status that is a lower priority than failed, or move NeverAttemptedAlternate to a lower priority than failed)

Why send the addresses when a peer is disconnected rather than when the addresses are received?

These changes seem similar, so let's discuss them together. What do you think their benefits and drawbacks are?

Keep the un-taken addresses from that peer in case we need more

Zebra will find peers faster if we keep all of the addresses, and will drop the NeverAttemptedAlternate addresses first when the address book is full.

Can you add this advantage to the ticket?
Are there any disadvantages?

May use more memory if stored per connection.

50 bytes for 1000 addresses for 200 connections is still only 10MB, so I think we're fine here.

Always keep the latest N unique addresses from each connected peer

I'm not sure what this means.

At the moment, we keep the last unsolicited address message from each peer, ignoring messages with only one address. (Unless we have no addresses at all.) We drop previously stored addresses when we get a new message.
Then if we query that peer, we take the entire message and add it to our address book.
But in this new design we're taking some addresses and leaving some behind. So we might want to add extra unsolicited addresses to the start of our stored addresses (like an OrderedMap), rather than replacing all the unused addresses. We'd need to limit the number of addresses though.

When a peer is disconnected, send its addresses as NeverAttemptedAlternate (or a new status that is a lower priority than failed, or move NeverAttemptedAlternate to a lower priority than failed)

Why send the addresses when a peer is disconnected rather than when the addresses are received?

Because our goal was to only put messages in our address book if we requested them from a peer, rather than letting peers add to our address book on their schedule. If peers can modify our internal address book by sending unsolicited address messages, that makes it harder to implement securely.
But sending addresses when the peer is disconnected also has this issue, so maybe we shouldn't do this at all. Because a peer could connect, send addresses, and disconnect to get them in our address book.

So I think that just leaves these proposed changes for discussion:

#7823
any other ideas you have

I think we agree the address book query limit is an essential part of this ticket. Did you want to add advantages and disadvantages in the ticket?
Also, should it be per-connection or an overall limit?

Can you add this advantage to the ticket?

Yep, added.

Are there any disadvantages?

Nothing noteworthy, a little complexity.

But in this new design we're taking some addresses and leaving some behind. So we might want to add extra unsolicited addresses to the start of our stored addresses (like an OrderedMap), rather than replacing all the unused addresses. We'd need to limit the number of addresses though.

Ohh.
Advantages:

obstructs a straightforward path for an adversary to fill the address book? (do other constraints that prevent this?)
occasionally avoids starving outbound connector of address candidates

Both of those seem crucial. I think this is also a required a change, but perhaps for another high-priority issue.
Disadvantages:

Nothing noteworthy, a little bit more complexity

Because our goal was to only put messages in our address book if we requested them from a peer, rather than letting peers add to our address book on their schedule. If peers can modify our internal address book by sending unsolicited address messages, that makes it harder to implement securely.
But sending addresses when the peer is disconnected also has this issue, so maybe we shouldn't do this at all. Because a peer could connect, send addresses, and disconnect to get them in our address book.

Ah, good idea.
I think it would be okay to send them immediately if the address book, when sent a new NeverAttemptedAlternate address, will only insert the new address if there is another address of the same PeerAddrState to remove. I think it should drop the new address when the address book is full and there are no other addresses with the same PeerAddrState.

I think we agree the address book query limit is an essential part of this ticket.

Yes, I think so.

Did you want to add advantages and disadvantages in the ticket?

I can't seem to think of any disadvantages, but I added the advantages.

Also, should it be per-connection or an overall limit?

I think it should be per-connection, I don't think the default values should be a problem for systems that are already able to run Zebra., and it's a relatively trivial amount of memory that I don't think will surprise users providing their own peerset_initial_target_size.

Edit: or both?

Or both, but as a separate issue, per-connection is enough for now.

But in this new design we're taking some addresses and leaving some behind. So we might want to add extra unsolicited addresses to the start of our stored addresses (like an OrderedMap), rather than replacing all the unused addresses. We'd need to limit the number of addresses though.

obstructs a straightforward path for an adversary to fill the address book? (do other constraints that prevent this?)

The current defence against an adversary filling the address book is:

We only use addresses from a peer if we randomly choose that peer for an address request (we cache previous addresses but don't use them until requested)
We rate-limit how often we request new addresses
We only request new addresses on demand if we need more peers

These defences are already implemented.
And let's assume that we implement taking only a few addresses separately. So that advantage has already been assigned to that change.
So I think that the remaining advantage for storing a list of recent addresses is improved connectivity. Because we're keeping more addresses available if we need them and decide to query for them.

Also, should it be per-connection or an overall limit?
I think it should be per-connection, I don't think the default values should be a problem for systems that are already able to run Zebra., and it's a relatively trivial amount of memory that I don't think will surprise users providing their own peerset_initial_target_size.

Edit: or both?
Or both, but as a separate issue, per-connection is enough for now.

I'm not sure it is, there are easy to implement attacks that evade a per-connection limit. Can you think of one?

and will drop the NeverAttemptedAlternate addresses first when the address book is full.

I removed this part because it doesn't match Zebra's current behaviour. It is based on an idea from the ticket that we decided not to do. Currently these addresses are kept in the per-connection cache.

I added a new potential fix:

Put addresses from the peer's version message and remote IP in the connection cache, don't send them directly to the address book

Currently a peer can fill Zebra's address book by repeatedly connecting and sending a different IP in each version message. This seems like a trivial attack that's worth preventing.
It also removes the NeverAttemptedAlternate status (because we're not sending any peers with that status any more, we're just treating them as if they were gossiped) which simplifies the code a lot.
And we can remove the Option on the last seen time, because we'll have to fake a time for these IPs (gossiped peers always have times), and the current time is reasonable for a current connection.

@arya2 let's schedule a meeting to make the final decisions on what we're doing for this ticket? I think we have enough information and analysis now.

Hmm, I think we might be talking about different changes here. #7823 is about rate-limiting how often peers can request addresses from Zebra.
It's good to have a strict per-connection limit before the request is sent to the inbound service, because that stops a single connection overloading the node. But reconnecting will reset that limit, so we also need a less strict overall limit in the inbound service.
Or we could rate-limit getaddr requests per connection, with a constant timer starting when the connection is successfully negotiated? That way we wouldn't need a global rate-limit, because reconnecting would still encounter the same time limit. Hmm, but then you could still do it in parallel across multiple peers.
Maybe we do need a global limit.

Put addresses from the peer's version message and remote IP in the connection cache, don't send them directly to the address book

Currently a peer can fill Zebra's address book by repeatedly connecting and sending a different IP in each version message. This seems like a trivial attack that's worth preventing.

A similar reconnection attack can be used to fill the address book via version messages or remote IPs, and NeverAttemptedAlternate.

Hmm, I think we might be talking about different changes here. #7823 is about rate-limiting how often peers can request addresses from Zebra.
It's good to have a strict per-connection limit before the request is sent to the inbound service, because that stops a single connection overloading the node. But reconnecting will reset that limit, so we also need a less strict overall limit in the inbound service.
Or we could rate-limit getaddr requests per connection, with a constant timer starting when the connection is successfully negotiated? That way we wouldn't need a global rate-limit, because reconnecting would still encounter the same time limit. Hmm, but then you could still do it in parallel across multiple peers.
Maybe we do need a global limit.

Here's a much simpler design that still meets the goal of limiting how many of its addresses Zebra gives out:

In the inbound service, generate a random getaddr response once, and return it to every peer that makes a request
When the rate-limit time is reached, generate a new random response and return it to every peer

This means it doesn't matter how many connections or how many reconnections an adversary makes, they will still get the same set of addresses until we decide to change them. A similar design is used by DNS seeders to avoid revealing all their addresses.

I updated "Always keep the latest unique addresses from each connected peer, regardless of which address message they were sent in" with:

- required analysis: before making this change, check how often the cache is truncated. If it is only rarely truncated, this  change isn't needed.

If we're not dropping a lot of addresses from the cache, there's no point switching to unique addresses, because the address book makes addresses unique anyway.

un-scheduling, tracking issues should not be scheduled in a sprint, the issues that they are tracking should be scheduled instead.

I think this change is also more complicated than discussed, because there is still some code using None for these fields:

Remove Option from MetaAddr.{services,untrusted_last_seen}

required analysis: before making this change, list every MetaAddrChange that uses None for either of these fields, and decide on acceptable defaults

I've moved these both to a "more analysis needed" section. If we think they're worth doing, let's make optional tickets with needs-investigation tags?

I think we can close this as sufficiently complete.