[Request] Lint Testing Folder

Would it make sense to add an experimentals folder for lints such as this one that are suggested but need additional testing and comment? I guess by default, these should be excluded in the API, but can be included for CA and auditor development environments. It gives internal devs an easier to way to test it and possibly provide feedback.
If you did this however, you would need to think about how experimental lints are stored. If you had 100 suggested lints for testing, not everyone would want to download them in a production environment, so some thought would need to go into handling that.
I still think it's a good idea to consider. It gives a specific folder for certificate testers, CAs and potential lint writers to play in without messing with the official folders.  Maybe add a switch for the command to include lints in the experimentals folder during check.
(Also, thanks to @cpu for the response in pull 336 - Didn't want to update that pull for the thanks!)

Setting aside the implementation for a second, what's the workflow you're thinking for how ZLint users will use this?
That is, it seems like as a production CA, you'd want to make sure you enable lints you're confident in: no false negatives and no false positives, ideally. You would not want to enable additional lints that had false positives (those could cause issuance rejection), and you wouldn't want to rely on lints that have false negatives (allowing misissued certificates)
So when would they enable these lints? When would they review these lints?
Figuring out how the ZLint user would use these, and what they would do in response, seems important to figuring out what/how to accomplish this.
For example, it might be that CAs enable the lints but suppress certain errors from certain lints from being blocking. But that assumes that every CA who does so will both contribute back (so that there are no more errors) and remember to disable the suppression. If, for example, two CAs both suppress the error, one sets a reminder to contribute in a month, the other sets a reminder to contribute in a year, then when the first CA contributes back and fixes whatever underlying issue in the lint, the second CA will be unprotected for 11 months because they've suppressed the lint.
Similarly, another idea might be for CAs to opt-in  to certain lints. Yet that seems unlikely, in practice, and unless the CAs that opt-in to a given lint issue certificates that are tested by that given lint, it doesn't seem likely to help. For example, a US CA that doesn't issue Qualified Certificates would never end up exercising the PSD2-related lints.
That's why it might be useful to work backwards, from trying to figure out how folks use a thing in practice :)

So, here's where the idea stemmed from.  The PSD2 new CABF OIDs don't have to be in place until the end of this month (don't quote me on that... but I believe that's the deadline). When new fields are implemented, we perform a ton of testing of the new fields in a non-trusted development environment.  When I send a certificate through ZLint (pre-certificate or otherwise), I get the results back and put them through my personal script which cleans it up, color codes, etc.
This isn't limited to PSD2, but it's the perfect example.  I would love to test these against our test implementations and certificates and make a judgement on whether the lint is sound, whether our changes are sound, etc.  It's an easier way of doing this (in my eyes).  There are also non-trusted CAs that although don't need to conform to the many various rules that trusted CAs need to, it's nice to be able to write custom lints and easily implement them for personal and private needs.  ZLint is a great tool to assist with conforming with rules and in conjunction with a CA.
Does that all make sense?

If this is the use case, then I think there are better solutions in typical development/release lifecycles. We can (and likely should) move to a solution where a RC is released ahead of time for something like that. Folks can run the RC in their development/testing environment and then we can release the major version after folks have had a chance to test. The proposed solutions mixes provenance and release cycle to me, which is awkward when we need to later go back and move the lints around.

Yeah! That's an acceptable approach and solves my issue.  I think that there needs to be a defined time between RC and release.  Compliance teams often ask when a certain lint is to be released and it's nice to have an answer (either based on date or time lapse of RC to R).

We can (and likely should) move to a solution where a RC is released ahead of time for something like that.

I'm open to that :+1:

I know for our DEV systems, we automate some of the builds and upgrades (and keep a copy of existing versions and lints for backup purposes).  Would being able to obtain a copy of this RC be a trivial task through a Github command?  I apologize if this is a simple question. I'm fairly new to github and it pull procedures.

Would being able to obtain a copy of this RC be a trivial task through a Github command?

It should be possible. There is a way to work with "releases" through the Github API. One of the fields specified for releases is a prerelease bool. Likely we will publish RC releases to Github with this bool set to true.

I opened an issue to track the discussion on providing RCs: https://github.com/zmap/zlint/issues/351
@weddi-eddy If you agree that would meet the needs expressed in this issue I'd appreciate if you could close it out so we can keep things tidy. Thanks!

Thanks @cpu! You guys rock!


feat(auction): Add auction events

The type of this PR is: feature
Description
This PR adds tracking events for the new /auction/id page
PR Checklist (tick all before merging)

[x] If I've added a new file to the tree I've exported it from the common index.ts
[ ] I've added comments with examples for any new interfaces and ensured that they're in the docs
[ ] No platform-specific terminology has been used outside of click and tap (platform is inferred by the DB storing events)

Skipping the docs for now as we need to launch tomorrow. Will loop back around

:rocket: PR was released in v4.36.0 :rocket:


Trying to refresh access token

I am working on a Salesforce OAuth app, where I have some user's SalesForce account's

accessToken
refreshToken
instanceUrl

and the I do this and query for some data in his account.
var conn = new jsforce.Connection({
  instanceUrl : '<your Salesforce server URL (e.g. https://na1.salesforce.com) is here>',
  accessToken : '<your Salesforrce OAuth2 access token is here>'
});

But it only works till the access_token is valid.
I want that if it expires then it will get refreshed automatically or some event will trigger which will return the refreshed accessToken.
So, I tried this.
var conn = new jsforce.Connection({
  instanceUrl : '<your Salesforce server URL (e.g. https://na1.salesforce.com) is here>',
  accessToken : '<your Salesforrce OAuth2 access token is here>',
  refreshToken : '<your Salesforce OAuth2 refresh token is here>'
});
conn.on("refresh", function(accessToken, res) {
  // Refresh event will be fired when renewed access token
  // to store it in your storage for next request
});

But this is giving me this error:
Error: Refresh token is specified without oauth2 client information or refresh function

I checked the source code and from that I can say I need some delegateRefreshFunction but I'm not sure what it is.
So, my question is, how can I refresh the token when it expires?
Thanks!

you have to pass the oauth2 parameters to the connection constructor.
https://jsforce.github.io/document/#access-token-with-refresh-token has an example.
var conn = new jsforce.Connection({
  oauth2 : {
    clientId : '<your Salesforce OAuth2 client ID is here>',
    clientSecret : '<your Salesforce OAuth2 client secret is here>',
    redirectUri : '<your Salesforce OAuth2 redirect URI is here>'
  },
  instanceUrl : '<your Salesforce server URL (e.g. https://na1.salesforce.com) is here>',
  accessToken : '<your Salesforrce OAuth2 access token is here>',
  refreshToken : '<your Salesforce OAuth2 refresh token is here>'
});

I ran into this too, and this worked, thanks for the answer @siddharatha

Yes, this works @siddharatha :+1:

I seem to be getting inconsistent results with this...sometimes my subsequent requests return undefined for no reason (no error in the callback, just fails silently) after calling the oauth2.refreshToken function. So my code looks like something like this:
return new Promise((resolve) => {
   // Before each request, I call the refreshToken function to make sure y accessToken is current
    conn.oauth2.refreshToken(conn.refreshToken, (refreshErr, refreshResult) => {
      if (refreshErr) {
        D.error = refreshErr;
        resolve(D);
      } else {
       D.accessToken = refreshResult.accessToken; // I get the new access token
       D.instanceUrl = refreshResult.instanceUrl;

        // Create a new conn object with the new access token
        const conn2 = new jsforce.Connection({
          oauth2,
          accessToken: D.accessToken,
          instanceUrl: D.instanceUrl,
          refreshToken: conn.refreshToken,
        });

       // Great, now I can use the new conn object to do things, right?
        conn2.describeGlobal((globalErr, globalMeta) => {
          if (globalErr) {
            D.error = globalErr;
            resolve(D);
          } else {
             // Do things with globalMeta, but sometimes it is undefined...
          }
        })
    }
  })
})
  ...

Is there any reason not to create a new conn object with the renewed access token before proceeding with the subsequent salesforce api requests (such as describeGlobal, sobjects, etc.)? I could use the conn.on('refresh') callback, but I can't depend on that callback completing before other important things happen.


⚠ Bofrost.at has degraded performance

In 9a6a10f, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1504 ms

Resolved: Bofrost.at performance has improved in 28bcf38 after 6 minutes.


refactor: reuse AssetConditions for banner plugin

Summary

Checklist

[x] Tests updated (or not required).
[x] Documentation updated (or not required).

Can you complete the PR summary to explain the changes 😄

I was a bit busy today and forgot to add the summary. I'll add it later. 😄


Implement CLA

CLA implementation for Mendix Documentation

CLA implemented through CLAHub, need to add it to the contribution guide. Preview: https://www.clahub.com/agreements/mendix/docs


txproposal ID should be the same

When you create a tx proposal it returns

Tx created: ID<PHONE_NUMBER>4953079daf0f-00b9-49af-bbb8-63490bfdc453 [pending] RequiredSignatures: 1

But when you list the tx proposals it returns

TX Proposals:
c453 [ by user3] 5,000 bit => 2N1fgfx4y8FaZKpLJL2qXw2DLQzDsf2pzXr
Missing signatures: 1

I think I should be always c453

I agree that was confusing for about 5 seconds.
but it makes sense for its use. The first one is the real ID, and the lower one is shorthand for typing commands without requiring inputting the full ID.


docs(Dropdown): fix searchQuery example

It's strange, but the change of example wasn't included in #2109. This PR fixes it.

Codecov Report

Merging #2110 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2110   +/-   ##
=======================================
  Coverage   99.76%   99.76%
=======================================
  Files         149      149
  Lines        2606     2606
=======================================
  Hits         2600     2600
  Misses          6        6

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 e056cd6...5532f46. Read the comment docs.

Released in<EMAIL_ADDRESS>

Hi,
This also means that https://github.com/Semantic-Org/Semantic-UI-React/blob/master/docs/app/Examples/modules/Dropdown/Usage/DropdownExampleRemote.js#L24
needs updating.


Custom Fields

Is one able to update custom fields using client.contacts.sync? Do you have any examples?

Is one able to update custom fields using client.contacts.sync? Do you have any examples?

Yes! But...
You need to know the field ID in question and then make sure to include in a double splat prefaced dictionary.
If you're syncing<EMAIL_ADDRESS>you can do it like so:
<EMAIL_ADDRESS>first_name="Jim")

But if you want to sync a custom field, you need to provide the field ID. And that needs to be in the format of field[ID,0], e.g. field[345,0]. The 0 you have to leave in place

Custom field values. Example: field[345,0] = 'value'. In this example, "345" is the field ID. Leave 0 as is.

client.contacts.sync(**{"email"<EMAIL_ADDRESS>"first_name": "Jim", "field[2,0]": "January"})

And that'll sync the value January to the custom field on their profile with ID 2.
How do you find the ID of a custom field? I don't know any way of doing this other than using the browser's network inspector to check the JSON request in the ActiveCampaign dashboard, but that does work.

The latest API might make this simpler, I'm not sure, but this package still uses version 1.

Thank you so much for the clear documentation, this works great!
Appreciate your efforts on this, keep up the great work!!

Hi @bennylope , I knew the version 3 using json with format
{
"contact": {
"email"<EMAIL_ADDRESS>"firstName": "John",
"lastName": "Doe",
"fieldValues": [{
"field": "1", => field ID
"value": "The Value for First Field"
},
{
"field": "6", => fieldID
"value": "2008-01-20"
}
]
}
}

About check field Id some is difficult to know field ID because we have many, I checked Version 1 https://www.activecampaign.com/api/overview.php, it allows us can update by Personalization Tag : EX %FIRSTNAME%> I would like to ask V3 of API can update contact info by Personalization Tag or it's only support fieldID.
Thank you


fix: Hide deprecated "custom runtime" related features for adaptive rutime

Description
Since new Adaptive Runtime comes pre-ejected, we no longer support the ability to eject, nor do we support the ability to toggle this feature off.    All that remains in the runtime control section is the customizable start command that is used when the bot is started.  It is very useful for this to remain available as it allows the developer to pass additional options along to the runtime.

Removes "Use custom runtime" option from settings for new-style Adaptive runtime bots
Removes ability to eject for new-style Adaptive runtime bots
Removes ability to change the path to the runtime

Task Item
Fixes #6321
Screenshots
For "old" bots, no change:

For "new" bots, removed features:

Coverage decreased (-0.01%) to 52.761% when pulling 37777b6197e1058c6dcd6e872d20d2f6e4450036 on benbrown/runtimeopts into 3afb128f84fd29fc7a07e6b798c9fc47e00af6f8 on main.


Add Smilies when logging

The gc.com logs are supporting various smilies with codes like [:)]; [:D]  Full list on gc.com logpage "Insert Smilies".
It would be a nice feature if c:geo would support these smilies as well via menu.
This could be located in the menu of the logging-view  "Insert"/"Smilies" / Scrollist of smilies.
I dont know, if the icons used on gc.com are under some copyright, if not they could be used in that menu to visualize the smiley.

I think they are protected, but we show them also in logs.

But we do not include them in our code. They are downloaded from the webpage like everything else.

There are free smilie libraries we could use here (e.g. http://www.greensmilies.com/)

Not greensmilies. :D Maybe it's enough to show the smiley-codes.


Max Recursion error when stepping through Pydantic with pycharm debugger.

Bug
When stepping through a Pydantic Model in the Pycharm debugger to find out why a number of validations are not working, I've encountered a Max Recursion error. Below you see a simplified version of the model that also hits the max recursion error.
For bugs/questions:

OS: MacOS 10.14.6 (18G84)
Python and Pydantic info

Python 3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; print(sys.version)
3.7.3 (default, Mar 27 2019, 16:54:48)
[Clang 4.0.1 (tags/RELEASE_401/final)]
>>> import pydantic; print(pydantic.VERSION)
0.30.1
>>> import pydantic; print(pydantic.compiled)
False
>>>

Pycharm build:

PyCharm 2019.1.3 (Professional Edition)
Build #PY-191.7479.30, built on May 29, 2019
JRE: 11.0.2+9-b159.60 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.6

Code Snippet
from pydantic import BaseModel

class TestModel(BaseModel):
    str_uuid: int

print(TestModel(str_uuid="string"))

Stack Trace
Connected to pydev debugger (build 191.7479.30)
RecursionError: maximum recursion depth exceeded while calling a Python object
Exception ignored in: '_pydevd_frame_eval.pydevd_frame_evaluator_darwin_37_64.get_bytecode_while_frame_eval'
RecursionError: maximum recursion depth exceeded while calling a Python object
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x0000700009776000 (most recent call first):
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/threading.py", line 1222 in current_thread
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/site-packages/pydantic/main.py", line 278 in __getattr__
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/site-packages/pydantic/main.py", line 278 in __getattr__
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/site-packages/pydantic/main.py", line 278 in __getattr__
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/site-packages/pydantic/main.py", line 278 in __getattr__
  File "/Users/pboers/anaconda3/envs/workflows/lib/python3.7/site-packages/pydantic/main.py", line 278 in __getattr__

Best to create a ticket on pycharm and link to it here, hopefully they can be more helpful.
If there's something to do in pydantic to help this I'll happily look into it.

The max recursion will not occur while stepping through the test in plain pdb. But a call to self within the __init__ will cause a max recursion. Example:
> /Users/paul/src/pydantic/tests/test_infinite_recursion.py(1)<module>()
-> from pydantic import BaseModel
(Pdb) n
> /Users/paul/src/pydantic/tests/test_infinite_recursion.py(4)<module>()
-> class TestModel(BaseModel):
(Pdb) n
> /Users/paul/src/pydantic/tests/test_infinite_recursion.py(8)<module>()
-> print(TestModel(str_uuid="string"))
(Pdb) s
--Call--
> /Users/paul/anaconda3/envs/pydantic37/lib/python3.7/site-packages/pydantic/main.py(242)__init__()
-> def __init__(self, **data: Any) -> None:
(Pdb) self
*** RecursionError: maximum recursion depth exceeded while calling a Python object
(Pdb)

Our current theory is that this occurs when attributes are read from the Basemodel by any smart debugger before values is set. The self.getattr methods calls self.values which if it is not present will in turn call self.getattr to get self.values etc.

(useful if you can use backticks when referencing code so we see self.__getattr__ not self.getattr)
That makes sense.
Perhaps we could do a hasattr() check in __getattr__?

fixed by #712.


Documentation: Add explanation of experimental label to running-lkvm doc

Explain why rkt LKVM stage1 has the "experimental" label.
Fixes #2163. Fixes coreos/docs#746.

(Added milestone based on milestone of the targeted #2163)

LGTM.
Can you rebase the patch?

Why rebasing? It is still mergeable.

@krnowak I wanted to make the history easier to understand than this. But the branch is actually not so far... you can merge it :)


Executable not ready

time=2023-12-13T08:21:58.750Z level=DEBUG msg="Executable not ready" component=discover.Watcher pid=21118
configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: beyla-config
data:
beyla-config.yml: |
print_traces: true
log_level: debug
open_port: 80-8999
otel_traces_export:
endpoint: http://tempo-distributor.tracing:4317
prometheus_export:
port: 8999
path: /metrics
report_target: false # disabled by default to avoid cardinality explosion in paths.
report_peer: false   # disabled by default to avoid cardinality explosion in paths.
internal_metrics:
prometheus:
port: 8990
path: /metrics
routes:
ignored_patterns:
- /metrics
- /health
unmatched: heuristic
daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: beyla
labels:
app: beyla
instrumentation: beyla
spec:
selector:
matchLabels:
instrumentation: beyla
template:
metadata:
labels:
instrumentation: beyla
spec:
serviceAccountName: default
hostPID: true # important!
# mount the ConfigMap as a folder
volumes:
- name: beyla-config
configMap:
name: beyla-config
containers:
- name: beyla
image: grafana/beyla:latest
imagePullPolicy: IfNotPresent
securityContext:
privileged: true # important!
command: ["/beyla", "--config=/config/beyla-config.yml"]
ports:
# expose the metrics ports
- containerPort: 8999
name: metrics
- containerPort: 8990
name: internal
volumeMounts:
- mountPath: /config
name: beyla-config

Hi @Jich1123,
Can you give us a bit more detail on what's the issue you are experiencing? Is the process you are trying to instrument reported as not ready? Was it PID 21118 that should've been instrumented?
Can you please tell us which programming language is the process written in (if you know) and what's the port it has opened?

Also, if you can please attach here the full debug output from Beyla.

I'm going to close this issue because we now have an example available for Kubernetes where we have a recipe with reduced permissions. https://github.com/grafana/beyla/blob/main/examples/k8s/unprivileged.yaml


Mobile menu does not open.

Demo mobile menu does not open on click

You are right, thank you for reporting this!

@alexanderfountain we've now fixed the bug you've reported. Thank you very much for this!


lib/cmsis_rtos_v1: Fix boundary conditions in the signals module

Fixed the boundary conditions around osFeature_Signals.
Fixes #9857.
Signed-off-by: Rajavardhan Gundi<EMAIL_ADDRESS>

Codecov Report

Merging #9858 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #9858      +/-   ##
==========================================
- Coverage   52.27%   52.26%   -0.01%
==========================================
  Files         213      213
  Lines       25962    25964       +2
  Branches     5596     5598       +2
==========================================
  Hits        13571    13571
  Misses      10154    10154
- Partials     2237     2239       +2

Impacted Files
Coverage Δ

lib/cmsis_rtos_v1/cmsis_signal.c
64.17% <0%> (-1.98%)
:arrow_down:

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 cdc7395...321304f. Read the comment docs.


Closes #20: Updating Registration Example Notebook for Gen Attach and register GroupBy

This PR (closes #20):
Draft until main repo PRs #1327 and #1391 are merged.
This is the initial commit with updates for the generic attach method as well as GroupBy and SegArrays register functionality being included. Once the mentioned PRs are merged, I will rerun the notebook to verify it's correct, but until they're merged the unregister piece will fail to unregister Categorical and GroupBy cannot be registered/attached.

I tested the notebook to ensure functionality now that the two required PRs have been merged. Notebook ran with expected results. Ready for review.


Clean up contract overview code

This was hard for me to understand because it was a big rat's nest of "if it's contract type X, show Y", so I cleaned it up by factoring out the stuff that was the same between different kinds of contracts and making separate contract type overview components for the stuff that was different.
Basically no user-visible changes (I moved some of the pixels around a tiny bit.)

we should default to using the useUser() hook everywhere it's needed now?

Yes, since it'll just get the value cached by react query. Unless you do it in a component that has 100 instances like contact card - ime it might choke in those cases

I agree that I don't think there's any important difference between passing down the user or using the useUser one so I just do whatever seems more convenient.

Yes, since it'll just get the value cached by react query.

No, useUser doesn't have anything to do with react-query. The current user is stored in the AuthContext object at the root of the app.

Unless you do it in a component that has 100 instances like contact card - ime it might choke in those cases

I would be interested to see this because it doesn't match my understanding of how it should work.


Doesn't seem to work with IE 11 and Edge 40

It would be great if someone could explain me why the lazyload doesn't seem to work with IE 11 and Edge.

I just discovered this library, and shortly later this issue (regrettably!).
The MS browsers don't support the ES5 forEach method. I tried using the ES5 shim library, with no luck,

See this super-helpful reply.


Wrong state of the app

This is duplicate, please have a look here: #741

That’s a duplicate don’t solve the problem. I think the repo and managing the repo is more important than fixing the app. It only worked properly 4 days since it was released.


[HUDI-1446] Support skip bootstrapIndex's init in abstract fs view init

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
Support skip bootstrapIndex's init in abstract fs view init
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@vinothchandar @bvaradar : wanted to clarify with you folks. Looks like as of now, bootstrap index is always initialized in AbstractTableFileSystemView.
Author's purpose of creating this PR is this:
When write data into hoodie table using operation api, shouldn't init a bootstrap index.
so, this patch introduces a DefaultBootstrapIndex which will be used if config does not set bootstrap path.
Interested to hear, why we did not have a default no op bootstrap index (which will return false for useIndex()) ?

Codecov Report

Merging #2520 (ef091c8) into master (0d8a4d0) will decrease coverage by 40.90%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master   #2520       +/-   ##
============================================
- Coverage     50.52%   9.61%   -40.91%
+ Complexity     3122      48     -3074
============================================
  Files           430      53      -377
  Lines         19597    1944    -17653
  Branches       2008     235     -1773
============================================
- Hits           9902     187     -9715
+ Misses         8886    1744     -7142
+ Partials        809      13      -796

Flag
Coverage Δ
Complexity Δ

hudicli
?
?

hudiclient
?
?

hudicommon
?
?

hudiflink
?
?

hudihadoopmr
?
?

hudisparkdatasource
?
?

hudisync
?
?

huditimelineservice
?
?

hudiutilities
9.61% <ø> (-59.82%)
0.00 <ø> (ø)

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

@Xoln : when do you think you can address the feedback. Do ping me here once its ready to be reviewed again.

@Xoln : gentle ping.

Codecov Report

Merging #2520 (8b74eb7) into master (1db904a) will decrease coverage by 44.88%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master   #2520       +/-   ##
============================================
- Coverage     54.22%   9.34%   -44.89%
+ Complexity     3809      48     -3761
============================================
  Files           488      54      -434
  Lines         23574    2002    -21572
  Branches       2510     237     -2273
============================================
- Hits          12783     187    -12596
+ Misses         9637    1802     -7835
+ Partials       1154      13     -1141

Flag
Coverage Δ
Complexity Δ

hudicli
?
?

hudiclient
?
?

hudicommon
?
?

hudiflink
?
?

hudihadoopmr
?
?

hudisparkdatasource
?
?

hudisync
?
?

huditimelineservice
?
?

hudiutilities
9.34% <ø> (-60.19%)
48.00 <ø> (-326.00)

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


I'm in conversation with the owner of the API and will likely have to submit a hotfix shortly, but prior to the next change of the API.

@geoffstowe, looks like the keepa API was modified (and reverted).
I'm in conversation with the owner of the API and will likely have to submit a hotfix shortly, but prior to the next change of the API.

Thank you Alex!


Omniparser crashes after processing 7 images.

2024-12-04 23:44:04 finish processing
2024-12-04 23:44:04
2024-12-04 23:44:04 image 1/1 /usr/src/app/imgs/saved_image_demo.png: 384x640 122 0s, 31.8ms
2024-12-04 23:44:04 Speed: 3.9ms preprocess, 31.8ms inference, 2.3ms postprocess per image at shape (1, 3, 384, 640)
2024-12-04 23:44:33 finish processing
2024-12-04 23:44:33
2024-12-04 23:44:33 image 1/1 /usr/src/app/imgs/saved_image_demo.png: 384x640 119 0s, 31.7ms
2024-12-04 23:44:33 Speed: 4.1ms preprocess, 31.7ms inference, 2.1ms postprocess per image at shape (1, 3, 384, 640)
2024-12-04 23:45:10 /usr/src/app/entrypoint.sh: line 8:     7 Killed                  python ./gradio_demo.py
Why does this occur. I am running omniparser locally via docker.

What do i do?? Is there anyway to control this?

@abrichr
Sir, I would greatly appreciate your assistance with this issue. I have been stuck on it for quite some time now. Despite carefully following all the instructions in #52 , my setup continues to run out of memory (OOM) after processing 3-4 images, even on a g4dn.xl EC2 instance.
I also tried enabling swap, but after doing so, the instance stopped sending or receiving requests. Any guidance on how to resolve this would be immensely helpful. Thank you in advance.

@techsparkling from your screenshot it appears you are running multiple containers. Can you please clarify exactly the steps you took to arrive in this situation? As it stands you haven't provided enough information to resolve your issue. Please be as detailed as possible, otherwise it will be impossible for others to help you.

@abrichr No, sir, there is only one container running.
I followed the steps mentioned in #52:

Cloned the GitHub repository from here.
Created a .env file and added the required variables.
Executed deploy.py start.
I verified that the GitHub Actions ran successfully.

After that, I used client.py to send images. However, after sending 5 images, the model crashes due to an out-of-memory (OOM) issue.

I also had the same issue it was running fine once I upgraded from 32 to 128gb ram server then it was stable at 90gb ram utilisation


kdePackages.ghostwriter: add missing dependencies

Description of changes

Format with nixfmt-rfc-style
Add pandoc, multimarkdown and cmark to ghostwriter PATH

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Can you please separate the formatting and the semantics changes into separate commits? Or maybe just drop the formatting.

Can you please separate the formatting and the semantics changes into separate commits? Or maybe just drop the formatting.

Done.

Thanks.


adding people to teams requires them to be members of ResBazAZ

Hello,
We would like to add some regular attendees to the C&C team, but they need to members of ResBazAZ. This adds an additional layer of administration. How do we add people, or make the teams more accessible?

I didn't think this was necessary. I thought you could add people to a team without adding them to the overall organization. Maybe we should do a screen share so I can see what you're seeing @val-pf.

When is good? @julianpistorius

Met, shared screen, and @val-pf is indeed correct.
See About teams - GitHub Docs:

Teams can only be made up of members of your organization, outside collaborators are unable to be on a team.

This brought up a number of questions that @val-pf & I think should be discussed by the community. I've created a discussion: #36 Regular event attendees, "Who We Are", and organization


Removing unconditional setUnfixed() call

The setUnfixed call in the scroll trigger was introduced in this commit.
At the time it was probably required for some cases, but in the current code checkScroll calls setUnfixed internally in all the cases where it's required. The problem with the extra unconditional setUnfixed call I'm removing is that it's messing with the position variable when the status is already "unfixed" and the consequence is the risk of spurious scrolling of the display, for example when a fixed div is redrawn (similar to #230).

@IlyaDiallo I am having problems with the scrolling but this change did not fix that for me.


Added re-base to Libraries

Re-base its librarie inspired in Relay to use Firebase with React

Thanks =D


VSCode dev container, .devcontainer.json

Possible to publish  a devcontainer.json file?

Apologies for late reply. I have pushed a big updated. Let see if I can add support for .Devcontainer.


[mac] add mIsHeaderUpdated frame flag

When a platform provides OT_RADIO_CAPS_TRANSMIT_SEC capability,
it updates the frame header with the dynamic data (frame counter,
key id...) and returns it back to MAC together with the transmission
result.
So far the mIsARetx flag was being used to instruct the radio
whether to update the header or not, but there was no mean to know
if the radio was able to do so.
This commit introduces the mIsHeaderUpdated flag with is used in
both directions, so the MAC layer can react to cases in which the
frame header was not properly updated by the radio plaform.
The usage of mIsARetx remains restricted now to the case when a
SSED decides to re-synchronize CSL parameters after a retransmission.

So far the mIsARetx flag was being used to instruct the radio
whether to update the header or not, but there was no mean to know
if the radio was able to do so.
This commit introduces the mIsHeaderUpdated flag with is used in
both directions, so the MAC layer can react to cases in which the
frame header was not properly updated by the radio plaform.

Thanks @edmont . I have couple of questions/suggestions on this:

In what situation the radio platform may not being able to update the header?
Can we try to address this in radio platform layer (i.e., ensuring even if tx is being aborted, the frame header is updated before invoking callback)?

I think the change from this PR would require all platform implementations to be updated.
In general, I think it'd be good to minimize/avoid changes to radio platform layer definitions and behaviors as much as we can. And try to only add new behaviors (in order to keep things backward compatible if/when we can).

In what situation the radio platform may not be able to update the header?

As an example, let's suppose that a transmission of a frame with CSL IE is requested while the channel is busy. The CSL Phase field requires accuracy of 10 symbols, which is quite tight. As a result, the radio platform must wait with updating that field at least until it's certain that the transmission can be carried out, or possibly even when the transmission is already ongoing. If the channel is busy and all CSMA/CA backoffs end with a failed CCA, the CSL Phase might never be updated by the radio platform. That information can be used when a retransmission is requested.

Thanks @jciupis

As an example, let's suppose that a transmission of a frame with CSL IE is requested while the channel is busy. The CSL Phase field requires accuracy of 10 symbols, which is quite tight. As a result, the radio platform must wait with updating that field at least until it's certain that the transmission can be carried out, or possibly even when the transmission is already ongoing. If the channel is busy and all CSMA/CA backoffs end with a failed CCA, the CSL Phase might never be updated by the radio platform. That information can be used when a retransmission is requested.

Two questions:

Would it matter to OT core whether the phase is set on a failed frame tx or not?
If it does, can we address it in radio platform layer, i.e. in case of such failure, we still set the fields in frame header to some reasonable values before invoking the txdone callback.

I think it'd be good to avid the need for a behavior change in radio platform layer (if/when we can) which can require all platform implementations to be updated.

Would it matter to OT core whether the phase is set on a failed frame tx or not? If it does, can we [...] still set the fields in frame header to some reasonable values before invoking the txdone callback

Suppose that instead of providing the mIsHeaderUpdated flag, the radio platform always updates the header with "best effort" values available before passing the notification to the upper layer. To avoid security breaches caused by using the same nonce to encrypt a different plain text, CSL phase cannot be updated once Frame Counter was set by the radio platform. Even with this reasonable, "best effort" CSL phase value written before invoking the callback, CSL synchronization will be lost for all scenarios that could otherwise not modify the header at all and set mIsHeaderUpdated to false. An example of such scenario is the busy channel case mentioned earlier.
I can't tell if it's worth breaking the backwards compatibility though.

I think it'd be good to avid the need for a behavior change in radio platform layer

I don't think this patch requires changes in any other platform layer than Nordic. It seems Nordic radio is the only one available in OpenThread that supports encryption in radio platform layer (OT_RADIO_CAPS_TRANSMIT_SEC). If given platform layer does not support frame encryption, mIsHeaderUpdated is set by OpenThread MAC layer during processing outgoing frame security procedure. Only if OpenThread MAC skips security processing (because given radio platform runs encryption instead), the radio platform is responsible to mark if frame counter was set on given frame or not.
Moreover, now looking at this PR I'm thinking if platforms without encryption support in radio platforms support frame encryption correctly with CSL.
Each transmission operation starts with otPlatRadioTransmit() and ends with otPlatRadioTxDone(). Meantime there may or may not be an event that frame transmission actually started like nrf_802154_tx_started(). This event is omitted if transmission was aborted before complete preamble was transmitted. This event is used to update CSL IE and encrypt outgoing frame. It is possible that when otPlatRadioTxDone() is called, the frame was encrypted (if nrf_802154_tx_started() occurred, or not (if nrf_802154_tx_started()  was not called). However, otPlatRadioTxDone() assumes that frame is already encrypted (setting IsARetransmission flag). This patch should fix described issue, by calling SetIsHeaderUpdated() only after security is processed. Not unconditionally in otPlatRadioTxDone().

Hi @abtink, I do agree with @hubertmis observations. Are you aware of any other platform implementing OT_RADIO_CAPS_TRANSMIT_SEC at the moment?

Moreover, now looking at this PR I'm thinking if platforms without encryption support in radio platforms support frame encryption correctly with CSL.
Each transmission operation starts with otPlatRadioTransmit() and ends with otPlatRadioTxDone(). Meantime there may or may not be an event that frame transmission actually started like nrf_802154_tx_started(). This event is omitted if transmission was aborted before complete preamble was transmitted. This event is used to update CSL IE and encrypt outgoing frame. It is possible that when otPlatRadioTxDone() is called, the frame was encrypted (if nrf_802154_tx_started() occurred, or not (if nrf_802154_tx_started() was not called). However, otPlatRadioTxDone() assumes that frame is already encrypted (setting IsARetransmission flag). This patch should fix described issue, by calling SetIsHeaderUpdated() only after security is processed. Not unconditionally in otPlatRadioTxDone().

We do have a flag bool mIsSecurityProcessed : 1; in the otRadioFrame which indicates whether the tx security is processed or not. It is set by OT stack when it processes the tx security. I think the same flag can be used by the radio platform to indicate whether it did perform sec processing or not (from TxDone() when frame is given back to OT stack).
The mIsRetx and mIsSecurityProcessed are not directly related. We can have frame marked as mIsRetx  independent of mIsSecurityProcessed.

I still think it'd be better to not add mIsHeaderUpdated flag and instead ensure that platform layer always update the header.

This makes it behave similar to how OT SubMac behaves and keep the code simpler.
OT stack only cares that frame counter and key id and seq number are properly set on the frame (from TxDone() indicating tx failure). Whether the frame security is actually processed does not matter.
The counter, key id, seq number info is only used  for indirect frame retx:

OT saves the the info for the failed indirect tx (stored in the related Child entry in ChildTable)
In the next retx attempt of this frame (which can be much later, i.e. after rx of next data poll or next CSL sample window of the child), the frame is reconstructed.
In this case, the same counter, key id, seq number are used in the prepared frame and the frame aIsRetx is marked (which inform SubMac and/or radio platform to not update these fields).

If we add mIsHeaderUpdated and allow radio platform to not set the header fields on certain failures, then we need to add code in the OT stack to handle this case which I don't think we have currently in this PR.

For example, we need to change the DataPollHandler::HandleSentFrame() where we save the info to check whether the fields are set in frame header.
But we should still remember that we need to retx the frame and that we don't have frame counter, key id for it.
Then in DataPollHandler::HandleFrameRequest() we need to handle all such cases, i.e. it is retx and we do have frame counter, key id saved for it, or it is retx and we don't have info.
I think it adds unnecessary complexity in the code (and potential for bugs).

I think it would much simpler to have the radio platform layer set the frame counter, key id and seq number header fields when it invokes TxDone() (even when tx fails and if the radio platform did not perform security processing) and avoid changing the core implementation.
Regarding CSL Phase I don't think OT stack will use it from TxDone() callback so whether it is set of not should not matter.
Thoughts?

Are you aware of any other platform implementing OT_RADIO_CAPS_TRANSMIT_SEC at the moment?

Probably Nordic is the main public one. But there may be private platform implementations. For example, we used to have some internal projects with private/custom platform implementations.
But independent of this I think we want to make sure we have a good/simple radio API model. I think the radio.h platform APIs has been slowly becoming more and more complex (many capabilities and APIs). It's a good idea to avoid adding more complexity in radio APIs. Even simple changes can have unexpected consequences. As an example we recently debugged and fixed a tricky and unfortunate bug  from https://github.com/openthread/openthread/pull/6837 which was triggered by a seemingly unrelated and innocent looking change from https://github.com/openthread/openthread/pull/4697 adding "Sleep to Tx" capability.

I still think it'd be better to not add mIsHeaderUpdated flag and instead ensure that platform layer always update the header.

I'm afraid we cannot force each radio platform to always update the header. If given radio does not update frame counter value if CCA resulted in busy channel, we cannot work around it in radio.c maintaining monotonically incrementing frame counter value.

Regarding CSL Phase I don't think OT stack will use it from TxDone() callback so whether it is set of not should not matter.

If we maintain FrameCounter value for retransmission, we must maintain also CSL Phase value. OT should preserve it, if it can retransmit frames including CSL Phase.

For example, we need to change the DataPollHandler::HandleSentFrame() where we save the info to check whether the fields are set in frame header.

Is something missing in DataPollHandler::HandleSentFrame() patch in this PR?

But independent of this I think we want to make sure we have a good/simple radio API model.

I agree. However, to support MAC layer features efficiently, we need to add more features to radio platform (like injecting CSL Phase, outgoing security procedure) and align OT implementation with new hardware and drivers.
I think mIsHeaderUpdated is simplifying code in OpenThread. Without this flag, one needed to guess if header included correct values or empty placeholders by looking at mIsRetx and FSM's states. This guessing could easily lead to errors. New flag introduced in this patch allows the code to rely on information if dynamic data in MAC header is correct. Regardless it is set by OT MAC, or by the radio platform.

Is something missing in DataPollHandler::HandleSentFrame() patch in this PR?

Yes. I think the PR as is may not work. Currently the only change I see in this PR in DataPollHandler::HandleSentFrame() is skipping over incrementing the counter and logging (and only in the case of kErrorNoAck and not other errors kErrorChannelAccessFailure and kErrorAbort). The existing code in this method (within the same switch) will still read the frame counter and key id from frame and save it in Child for retx (which in the case where we have mIsHeaderUpdated == false won't be set and will be random/incorrect values in the frame header).
I think we need the following changes to be added in OT core (copying from comment above) - these are immediate things I could think of (there may be more changes which we need to think of).

If we add mIsHeaderUpdated and allow radio platform to not set the header fields on certain failures, then we need to add code in the OT stack to handle this case which I don't think we have currently in this PR.

For example, we need to change the DataPollHandler::HandleSentFrame() where we save the info to check whether the fields are set in frame header.
But we should still remember that we need to retx the frame and that we don't have frame counter, key id for it.
Then in DataPollHandler::HandleFrameRequest() we need to handle all such cases, i.e. it is retx and we do have frame counter, key id saved for it, or it is retx and we don't have info.
I think it adds unnecessary complexity in the code (and potential for bugs).

I think mIsHeaderUpdated is simplifying code in OpenThread. Without this flag, one needed to guess if header included correct values or empty placeholders by looking at mIsRetx and FSM's states. This guessing could easily lead to errors. New flag introduced in this patch allows the code to rely on information if dynamic data in MAC header is correct. Regardless it is set by OT MAC, or by the radio platform.

I don't think it's helping make it simpler. It's actually pushing the handling of this situation up the stack rather than handling at lower layers (at SubMac or radio platform layer). It's simpler (and I would say safer assumption for future) to require that frames passed back from Mac in HandeSentFrame()/TxDone() callbacks to the next layers (e.g., to MeshForwarder, DataPollHandler, etc) are properly formed and have all the fields set in the header.

I'm afraid we cannot force each radio platform to always update the header. If given radio does not update frame counter value if CCA resulted in busy channel, we cannot work around it in radio.c maintaining monotonically incrementing frame counter value.

I think this can be implemented in the radio platform.

Radio platform can track with an internal boolean flag whether it has updated the header or not (e.g., set frame counter)
Before calling TxDone() to pass the frame back to OT stack, it can check this flag and if it the header needs to be updated, then we allocate a new frame counter and populate the frame header.

I think we can require this behavior from radio platform (same way that we expect it from SubMac). Any reason/situation why this may not be possible?

Any reason/situation why this may not be possible?

If given radio hardware sets frame counter in outgoing frames, radio.c implementation cannot set frame counter value in a way that makes reusing frame counter value impossible. If we implemented setting frame counter in TxDone in radio.c, during execution of such function hardware could transmit Enh-Ack with the same frame counter value.
We should have a single entity in the system setting frame counter to avoid races leading to reusing the same frame counter value. If hardware sets frame counter in outgoing frames, we should not implement setting frame counter value anywhere in the software.
The real device that works like I described above is nRF53. One core is running OpenThread (including radio.c), while the other one is responsible for radio operations, including sending Enh-Ack and setting frame counter in outgoing frames.

The real device that works like I described above is nRF53. One core is running OpenThread (including radio.c), while the other one is responsible for radio operations, including sending Enh-Ack and setting frame counter in outgoing frames.

I agree that one entity should be in charge of assigning frame counter.
Is there no API or mechanism to request for a frame counter from the entity (whether it is hardware or software (or another core))?  Basically is the only way to get a frame counter is for the frame to be sent over the air?

Here is my view on this:
I still prefer if we avoid the adding of mIsHeaderUpdated flags due to all reasons above (mainly the complexity it adds).
But at the end you guys know the hardware and radio driver and if you say, there is no solution that can be done at radio driver level to address this, then I guess we need mIsHeaderUpdated to notify the OT stack and handle it in next layer.
If we go for this, then we need more changes in this PR:

Changes in DataPollHandler and CslHandler to handle this flag (mentioned some in above comments).
We need to address the changes related to this flag in RCP/host code (from comments above)

Also since this would break backward compatibility between RCP and host, we need to decide how to handle it (i.e. require both host and RCP to be updated and run new model, or add code on host to handle both new and old formats).

I would also recommend testing this change on hw (may be stress testing in real deployment) since I don't think our CI tests will cover this.

Is there no API or mechanism to request for a frame counter from the entity (whether it is hardware or software (or another core))?

For nRF53 it would be possible to create such API, because there is software running in the radio core. However, such API would be prone to race conditions:

radio.c requests a frame counter value
radio core returns frame counter (value 100) and sends Enh-Ack just after (fc = 101)
radio.c requests transmission of a frame with fc=100
radio core sends a frame with fc=100 after Enh-Ack with fc=101

If radio.c did not set frame counter in the frame that was not yet transmitted, frame counter would keep incrementing monotonically.
We are aware there is an exception in Thread Spec to allow data or command frames with fc lower than previously transmitted Enh-Ack, but this race condition would also affect other scenarios like responding to Data Poll request frame received during CSMA-CA backoff, where frame counter is expected to keep monotonically incrementing.
Also, for other devices with hardware encryption it might not be possible to retrieve next frame counter value from the hardware.
The rationale I described above was the reason we tried to handle frames after TX attempt that did not set frame counter yet. First attempt with using mIsARetx ended with failure (hard to track race conditions). Creating mIsHeaderUpdated simplified the code with clear indication if frame counter (and CSL Phase) is set in given frame, or should it be set during next TX attempt.

Thanks for your review @abtink, I added your proposed changes.

For nRF53 it would be possible to create such API, because there is software running in the radio core. However, such API would be prone to race conditions:

radio.c requests a frame counter value
radio core returns frame counter (value 100) and sends Enh-Ack just after (fc = 101)
radio.c requests transmission of a frame with fc=100
radio core sends a frame with fc=100 after Enh-Ack with fc=101

If radio.c did not set frame counter in the frame that was not yet transmitted, frame counter would keep incrementing monotonically.

@hubertmis , the race (counter mismatch between data and enh-ack frames) may happen in different situations and independent of having or not having an API to allocate a frame counter on "TxDone". For example, during retx of a frame

Frame is about to be sent (first time), we assign fc=100, encrypt it, and then send it.
We get no ack, so need to retx the frame so we start the next attempt.
While performing CSMA-CA for the next tx attempt, we happen to receive a frame (from same neighbor) and then prepare and send an enh-ack using fc=101.
Now we are sending a data frame with fc=100 after and enh-ack frame of fc=101 (and we cannot re-assign/change fc on a retx frame).

I think the above situation is what you meant by this. Is this correct?

this race condition would also affect other scenarios like responding to Data Poll request frame received during CSMA-CA backoff, where frame counter is expected to keep monotonically incrementing.

As you mentioned, this is already addressed in a Thread spec change on how the enh-ack frame counter is managed on receiver side by allowing enh-ack frame counter on receiver to be ahead of the "data" frame counter (basically we try to track an mLinkAckFrameCounter separately from mLinkFrameCounters per Neighbor).

I think it was added in OT from https://github.com/openthread/openthread/pull/5583.

So we only require that the frame counters are monotonically increasing for "data" frame tx per neighbor (and separately for "enh-ack" frames).
Since the data frames are always prepared and given to radio platform by the OT stack, we should be fine to allocate and assign a frame counter to a frame even in the case where it was never sent (basically use such an API to request a frame counter to be allocated before TxDone).

Then OT stack will either try to re-send the same frame again, e.g. if it is indirect frame tx (where we do want to use the same frame counter for retx)
Or ignore/drop this data frame (the assigned frame counter is wasted but that's ok). Any future data frame will get a new counter.

@abtink I agree. I was thinking about more generic usage of 802.15.4. It seems that Thread specification, and especially OpenThread implementation prevents decrementing frame counter value per link (with the exception of Enh-Ack discussed above). It does not prevent decrementing frame counter between two links (I think it would be possible to send CSL transmission to peer A, followed by direct retransmission with lower frame counter value to peer B). But it's fine, because in Thread we always maintain single link per peer.
I'm investigating alternative solution to handle setting MAC header data in radio.c when radio driver or hardware skipped setting it. But I see a few problems:
I'm looking at 802.15.4 specification to find a way to abstract "atomically get and increment frame counter" operation in systems like Zephyr RTOS. I see an obstacle here, because according to spec we can use separated MLME-GET.request and MLME-SET.request, what is not atomic. If OpenThread required radio platform to always update frame counter value, even if given radio driver did not do that, given platform would need to be extended with proprietary frame_counter_get_and_increment() feature. Alternatively, we could disable transceiver while radio.c calls MLME-GET - MLME-SET sequence, but it would degrade the performance of the radio.
Also, if radio.c were to set frame counter in the frame, radio.c would need to set CSL IE as well (or we would need to handle cases where MAC header is partially updated, what would be even more complicated). I'm afraid radio.c does not have enough information to set correct CSL values. It would need to extract CSL Period from radio driver (or hardware) and estimate Phase. To estimate Phase value, radio.c would need to depend on a timer what would be one more complication.
I enjoy this discussion, looking at the problem and solutions from multiple angles. I hope the patch proposed in this PR is an acceptable solution.

Failing CI tests are passing locally for me.

Thanks @edmont for update.
I went through the whole code in detail. I think there are some situations and code paths that may not covered and need to be updated to use the new IsHeaderUpdated flag properly.
As I said adding a new flag sounds simple, but it can be very tricky and we need to be super careful of all the different situations.  I will try my best to help with this  😃 ... But to be honest, I am still afraid that this change will break some functionality.

Some general observations (which help with the analysis below):

Before sending or preparing a new frame to tx, we always Clear() the frame which init the flags (it sets mIsRetx and mIsHeaderUpdated to false). This is happening from Mac::BeginTransmit() and call to txFrames.Clear().
We can have OT handle tx security (done at SubMac) or be delegated to radio platform
We can have OT handle retx of frame (again done at SubMac) or handled by radio platform layer.
Indirect frame retx preparation (data poll or CSL based) are handled by the DataPollHandler and CslTxScheduler.

They save the seq num, key id and frame counter on failed tx attempts, and ensure to set the same values when preparing the frame again for retx (which can happen much later on fresh new frame instance).

Here are some cases that I found so far that the current code in this PR may not function properly:
1: Indirect retx of a secure frame

When we prepare an indirect tx frame for a second (or next) tx attempt (from DataPollHandler::HandleFrameRequest() we set the seq-num, frame counter and key id but do not mark mIsHeaderUpdated.
Then the SubMac or radio platform will overwrite the values in the header which would be incorrect
How does it work in main: We set frame->SetIsARetransmission(true) in the DataPollHandler::HandleFrameRequest()
Fix: We need to do the same for mIsHeaderUpdated in DataPollHandler::HandleFrameRequest()

2: Indirect retx of a secure CSL frame

The same situation as above can happen with CSL retx
Fix: We need to update mIsHeaderUpdated in CslTxScheduler::HandleFrameRequest() if frame is a retx.

3: Indirect re-tx (CSL or data poll) of secure frame due to "NoAck" error when SubMac handles the security

New frame is prepared and mFrameIsUpdated starts as false
SubMac handles security, it will actually set frame counter and key id, but I don't see any place in the code where we would set the mFrameIsUpdated on the frame.
So mFrameIsUpdated remains false.
We send the frame and happen to get no ack error.
The error is propagated through all "TxDone()" callbacks till we get to DataPollHandler::HandleSentFrame().
Now under case kErrorNoAck we have OT_ASSERT(aFrame.IsHeaderUpdated()); which would assert.
Same situation can happen with CSL and from CslTxScheduler::HandleSentFrame()
Fix: we need to make sure SubMac/Mac set the mIsHeaderUpdated when they do set the frame counter on frame.

4: Indirect re-tx (CSL or data poll based) of non-secure frame with "NoAck" error

Frame does not use link layer security (example of this is an MLE message)
So there is no need to add frame counter, key id.
New frame is prepared and mFrameIsUpdated starts as false

If SubMac handles security, I don't see any place where we set it to true
But even if radio platform handles security, it may not  mark the flag, since it won't need to add frame counter, key id (these fields are not even used or present in the frame).

We send the frame, happen to get no ack error
The error is propgated through all "TxDone()" callbacks, till we get to ``DataPollHandler::HandleFrameRequest()`
Now again under case kErrorNoAck we have OT_ASSERT(aFrame.IsHeaderUpdated()); which would assert.
-Same situation under CSL from ``CslTxScheduler::HandleSentFrame()`
Fix: We need to relax the assert check here and check this only when aFrame.GetSecurityEnabled()

5: Direct frame retx when SubMac takes care of re-tx and security

The frame starts mIsHeaderUpdated as false.
The frame will be prepared and then SubMac will notice see the mIsHeaderUpdated is false and sets the frame counter and key id, but the mIsHeaderUpdated remains false
If the frame tx fails, SubMac will retry the frame but the mIsHeaderUpdated remains false
I don't see any immediate place this can cause issue, but not good idea to keep it like this.
How does it work in main: In SubMac::HandleTransmitDone() when we decide to retx the frame we do aFrame.SetIsARetransmission(true).
Fix: Better set the mIsHeaderUpdated when SubMac/Mac set the frame counter and key id. Same fix as in 3.

6: Indirect retx of non-secure frame

In this case we still need to save seq-num from first attempt to reuse same seq-num when preparing same frame for retx
But there is no frame counter or key id (since no link layer security)
The Mac::BeginTransmit() in this PR is changed to use frame->IsHeaderUpdated() to determine whether to set the sequence number or not frame->SetSequence(mDataSequence++);
Fix: So this means when we prepare the frame for retx from DataPollHandler::HandleFrameRequest() or CslTxScheuler::HandleFrameRequest()we need to set themIsHeaderUpdated even when the frame does not use security.
Now what if the frame is secure and the radio platform is handling the security processing.
On the first tx attempt we can have the following situation: Mac will always set the seq number on frame, but now suppose the frame tx is aborted and radio platform does not update the header.
In the DataPollHandler::HandleSentFrame() we will save the seq-number but since mIsHeaderUpdated remains false we don't save the frame counter and or key id (nothing to save)
However, I think this situation works ok:

In this situation the aChild.IncrementIndirectTxAttempts() won't be called and we remain at attempt counter of zero,
So the next time we want to re-send the frame, we don't treat as a retx and will keep mIsHeaderUpdated as false
This means Mac will re-assign a new seq number to the frame but that should be fine (we just waste one seq number)
This is fine for now, but we need to be aware of this behavior for any future changes (I know there are some discussions in Thread TC about using seq number for some situations).

@abtink thanks for the thoughtful re-review :)
1, 2, 3, 5
I believe you missed that this PR updates Frame::SetFrameCounter() to also set the mIsHeaderUpdated to true. It's done like that for code optimization reasons, but let me know if you'd prefer to move this setting to all the places you described.
4
Agree, done.
6
Actually relying on frame->IsHeaderUpdated() for learning about the sequence number status doesn't seem consistent with the flags documentation. Changed back to check frame->IsARetransmission().

Thanks @edmont.
I did indeed miss the change in SetFrameCounter(). It does address 1, 2, 3, 5 above, and I think it is fine to set the flag from this method.
I actually did checkout this branch and did a git grep SetIsHeaderUpdated to find all places from which the flag is set (but did not think that the mIsHeaderUpdated may be being set directly so did not search for it 😃). May be better to update  the SetFrameCounter() method to use the SetIsHeaderUpdated() as well?
For 6, I think going back to using IsARetransmission() should work fine and I agree is a better model.


Add analytics and send to Grafana

Add support for sending analytics data externally, and configure it to send to Kubernetes-deployed Grafana.

Pushing this effort to another project - this cluster should be ephemeral and probably not contain long-term data (like monitoring systems)


⚠ Bofrost.lu has degraded performance

In 658cf74, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1982 ms

Resolved: Bofrost.lu performance has improved in 4ee72dc after 22 minutes.


Build applicant email confirmation system

This task is part of #296 and follows the design of #268.
After prospective users have applied for an account but before they are considered a "real" applicant that an admin should evaluate, they must confirm their email address. We'll do that by sending them a confirmation email using our chosen transactional email platform (#281) and either our own email-confirmation library or, if possible, using Devise:Confirmable. (The sticky wicket is that these aren't actual "users" yet.)
Prerequisites:

#281
#303

As a note to self, we considered whether to send mail through SMTP or using Mailgun's API via their mailgun-ruby gem. We decided to use the API for its substantially-better security over SMTP.
The only downside is adding a dependency and slightly increasing the friction of migrating from Mailgun to another platform. but that's not terribly hard:

Switching from Mailgun SMTP → [Another Platform] SMTP would just mean changing env vars, no code.
Switching from Mailgun API → [Any SMTP would mean changing a few config settings (remove action_mailer.mailgun_settings, add action_mailer.smtp_settings) and env vars.
Switching from Mailgun API → [Another Platform] API is an unknown amount of work and depends on if that other API offers a good Ruby gem with Action Mailer integration.

Delivered by #337 (and #336)! There are some improvements to be made, e.g. improving templates and such, but those can wait for when we're implementing the real design (#267 and beyond).


spring-commands-rspec don't work

Hi!
I've installed both spring (1.3.5) and spring-commands-rspec (1.0.4)
And it seems I've met the troubles with run spring server for rspec. Please review the log
sergey@Pisuk:~/projects/fasteria$ time bin/rake db:migrate

real	0m2.013s
user	0m0.092s
sys	0m0.008s
sergey@Pisuk:~/projects/fasteria$ time bin/rake db:migrate

real	0m0.304s
user	0m0.087s
sys	0m0.008s

# it's worked

sergey@Pisuk:~/projects/fasteria$ time bin/rspec spec/models/user_spec.rb
...

Finished in 1.1 seconds (files took 3 seconds to load)
3 examples, 0 failures

real	0m4.274s
user	0m0.087s
sys	0m0.008s
sergey@Pisuk:~/projects/fasteria$ time bin/rspec spec/models/user_spec.rb
...

Finished in 1.12 seconds (files took 2.98 seconds to load)
3 examples, 0 failures

real	0m4.261s
user	0m0.088s
sys	0m0.008s
# doesn't work

Here is my Gemfile:
group :development do
  ...
  gem 'spring-commands-rspec'
  gem 'spring'
end

I use rvm -v 1.26.11, ruby -v 2.2.1p85, rails -v 4.2.0, ubuntu 14.04.
Here is output of sprng status command:
Spring is running:

20677 spring server | fasteria | started 7 mins ago
20685 spring app    | fasteria | started 7 mins ago | development mode
21872 spring app    | fasteria | started 6 mins ago | test mode

What's going wrong? P.S I have ran spring stop a lot of times

duplicated here: https://stackoverflow.com/questions/30069885/gem-spring-commands-rspec-dont-work

LOG
rake -T
[2015-05-06 11:00:02 +0300] [22694] [server] accepted client
[2015-05-06 11:00:02 +0300] [22694] [server] running command rake
[2015-05-06 11:00:02 +0300] [22965] [client] sending command
[2015-05-06 11:00:02 +0300] [22697] [application:development] got client
[2015-05-06 11:00:02 +0300] [22697] [application:development] forked 22967
[2015-05-06 11:00:02 +0300] [22694] [application_manager:development] got worker pid 22967
[2015-05-06 11:00:02 +0300] [22965] [client] got pid: 22967
[2015-05-06 11:00:02 +0300] [22697] [application:development] 22967 exited with 0
[2015-05-06 11:00:02 +0300] [22965] [client] got exit status 0

Rspec log
[2015-05-06 10:57:56 +0300] [22694] [server] accepted client
[2015-05-06 10:57:56 +0300] [22694] [server] running command rspec
[2015-05-06 10:57:56 +0300] [22814] [client] sending command
[2015-05-06 10:57:56 +0300] [22756] [application:test] got client
[2015-05-06 10:57:56 +0300] [22756] [application:test] forked 22816
[2015-05-06 10:57:56 +0300] [22694] [application_manager:test] got worker pid 22816
[2015-05-06 10:57:56 +0300] [22814] [client] got pid: 22816
[2015-05-06 10:57:56 +0300] [22694] [server] accepted client
[2015-05-06 10:57:56 +0300] [22694] [server] running command rake
[2015-05-06 10:57:56 +0300] [22821] [client] sending command
[2015-05-06 10:57:56 +0300] [22756] [application:test] got client
[2015-05-06 10:57:56 +0300] [22756] [application:test] forked 22823
[2015-05-06 10:57:56 +0300] [22694] [application_manager:test] got worker pid 22823
[2015-05-06 10:57:56 +0300] [22821] [client] got pid: 22823
[2015-05-06 10:57:58 +0300] [22756] [application:test] 22823 exited with 0
[2015-05-06 10:57:58 +0300] [22821] [client] got exit status 0
[2015-05-06 10:58:00 +0300] [22756] [application:test] 22816 exited with 0
[2015-05-06 10:58:00 +0300] [22814] [client] got exit status 0

Is there anybody?
P.S. My RSpec version is 3.1.7

I had the same issue, but after I've create a first migration, spring starts to work

Same, using Rails 4.2.3 and rspec-core 3.3.2 and spring + spring-commands-rspec doesn't work.  @jonleighton any insight?

I have the same issue on :

Ruby: 2.2.3p173
Rails: 4.2.4
Spring: 1.6.2
Spring-commands-rspec: 1.0.4
Rspec-rails: 3.4.2
Rspec-core 3.4.2

Spring & Spring-commands-rspec does not work with Rspec:

Spring seems to work fine
Spring-commands-rspec does not work (works only after migration)

This issue is opened from 5 May 2015, is it planned to solve it ?
Spring works with @aglushkov tricks (from ~30s to 5s)

Spring works with rake (from 6s to 2s)

Spring & spring-commands-rspec needs to be in the TEST environment

I solved this for me. The problem was that I started tested before creating any database table, so you just need one migration with one table and spring miraculously start to work.


Log the query?

Hey, is there a way to log the generated query?
I tried this but it did not printed out the queries.
export const db = new Kysely<ModelTypeMap>({
  dialect: new PostgresDialect({
    host: "localhost",
    database: "postgres",
    password: "postgres",
    user: "postgres",
    log: (message) => {
      console.info(message);
    },
  }),
});

// Output

/*
checking client timeout
connecting new client
new client connected
pulse queue
no queued requests
[
  {
    id: 2,
    slug: 'a',
    name: 'a',
    last_updated: 2021-11-29T11:51:27.581Z,
    thumbnail_url: 'aa',
    default_source: 'a',
    status: 'ENABLED'
  }
]
remove idle client
*/

There's currently no built-in way to log queries in Kysely. The parameters the PostgresDialect takes are passed directly to the pg module. The only your code works is if pg supports that log. And if it doesn't, it's a bug in pg.
You can get the compiled sql like this for any query:
const sql = db
  .selectFrom('foo')
  .where(...)
  .orderBy(...)
  .selectAll()
  .compile()

console.log(sql)

I'll probably add some way to debug queries soon.

What's the ideal API for logging queries in your opinion? Should it log the query outputs too? Do you want a global debug setting as well as a way to log individual queries?

Have you seen how Prisma does it, that looks pretty good, also i dont think there is any need for logging the output, only having a query logger is good enough, global setting should be good enough, individual query logging isnt worth it imo.

Prisma logging has a bunch of features. It would be overkill to copy all of that. What in particular do you need?

Logging all queries, slow queries, failed queries maybe would be a good start :)

I released a new version 0.9.4 with very minimal query logging.
You can now give the log: ['query'] option for the Kysely constructor and it will log all queries and their durations.

An option to log request param could be useful for debug

@AzSiAz 0.11.3 now supports a custom logger function:
const db = new Kysely<Database>({
  dialect: new PostgresDialect(postgresConfig),
  log(event): void {
    if (event.level === 'query') {
      console.log(event.query.sql)
      console.log(event.query.parameters)
    }
  }
})

I'll consider this implemented for now. Feel free to open issues if you want me to extend the logging somehow.

This was very helpful! However I had a very hard time finding any info on logging in the docs. Would be awesome if some of this info were mapped there

@JS-GitRepo You're more than welcome to create a PR with docs update.

I'm trying to get a request id in the logging statements. Any thoughts on how to accomplish this without using AsyncLocalStorage/async_hooks (perf hit too great)? I could initialize the Kysely object on every request and put it in context but that also increases memory pressure. Any guidance would be awesome, thanks!

I'm facing the issue of using Sentry with Kysely.
Sentry's API allows for this:
const result = Sentry.startSpan({ name: "Important Function" }, () => {
  return expensiveFunction();
});

or
const span1 = Sentry.startInactiveSpan({ name: "span1" });
someWork();
span1.end();

Now, I want to log every query. I tried these approaches:
1. Using the log() function
const db = new Kysely<Database>({
  dialect: ...,
  log: (event) => {
    if (event.level === "query") {
	  const startTime = Date.now() - event.queryDurationMillis;
      Sentry.startInactiveSpan({ name: event.query.sql, op: "db.query", startTime }).end();
    }
  },
});

This approach seems hacky, since the queryDurationMillis might not be that accurate when computing the startTime manually.
1. Using a plugin
export default class SentryLogPlugin implements KyselyPlugin {
  spans = new Map<PluginTransformQueryArgs["queryId"], Span>();

  transformQuery(args: PluginTransformQueryArgs) {
    const span = startInactiveSpan({ name: "db-query", op: "db.query" });
    this.spans.set(args.queryId, span);
    return args.node;
  }

  async transformResult(args: PluginTransformResultArgs) {
    const span = this.spans.get(args.queryId);
    if (span) {
      this.spans.delete(args.queryId);
      span.end();
    }
    return args.result;
  }
}

While this works, it doesn't have the ability to log the query without the values (event.query.sql). It also seems hacky because the plugins are made for data transformation and not for logging.
What is the correct way of approaching this?

@nikeee did you find a solution for it?

@alonroth i used the first hack mentioned in my response:
startInactiveSpan({
    name: e.query.sql,
    op: "db.query",
    startTime: new Date(Date.now() - info.duration),
    onlyIfParent: true,
}).end();


Conversation update sample not working

Ran the conversation update sample (https://github.com/Microsoft/botbuilder-js/tree/master/samples/conversation-update-es6) and it gave this error:
C:\Users\michhar.REDMOND\Documents\bin\github\botbuilder-js\samples\conversation-update-es6\app.js:24
await context.sendActivity(Hello "${context.activity.membersAdded[0].name}"!);
^^^^^
Seems it needs the 'async' specification for this function.
adapter.processActivity(req, res, async (context) => {

Thanks.


Sonoff Mini R2 always blinking once a second

A have tried to ota-flash Tasmota firmware on a SOnoff Mini R2, with no success (can't fetch data). Now the device is always blinking once a second and it is no more connected to the wireless network.
I can't find any way to get it off from this status (pressing 5 seconds, pressing long, resetting power). It looks like frozen.
What can I do to factory reset the Sonoff or - at least - to have it back on the network?

In which step of the flashing did you lose connection? If all went well your wifi will disconnected and a new accesspoin “tasmota***” will be available. You need to connect that one te recondite the network.
If this isn’t available. You could try the reset button for 40seconds. Or flash using the Uart. But I’m guessing you try to avoid that.


AoC: Leaderboard per star

We currently show two types of statistics for the participants of Advent of Code:

The leaderboard; a cumulative rundown of each players' progress
The number and percentage of users who has completed each star

Some more granular statistics would be cool to see. I suggest an alternative leaderboard, which shows scores for a specific star only, and times instead of score (like the daily breakdown of the global leaderboard).
For example, .aoc leaderboard 2-1 to get a top-10 (or optionally a different length) list for the 2nd day's 1st star:

Top 5 solvers for star 1, day 2:
06:02 Ikusaba-san
07:44 WillDaSilva
08:46 smartspot2
09:50 Sedsarq
10:11 salt-die

The timestamps per user and star is stored in the JSON we grab from the site, but it looks like we're currently not using them.
I'll refrain from providing implementation details, being the rookie that I am - don't want to make bad suggestions!

@Skaft Hey, are you still working on this? It's a great idea and I'd love to have it for AoC this year.

Apologies for abandoning this, after missing the first deadline of having it included in the 2019 event I kinda lost interest =/ I've since lost my progress on it, so I'd be happy for someone else to pick it up.

I'd like to grab this issue!


sinuous immediately closes upon running

I installed sinuous via the AUR and was excited to give it a try. Unfortunately when I try to run it, it sort of flashes my terminal blank for a split second and then returns back to my prompt.
I tried running with $ RUST_LOG="sinuous=debug" sinuous, and the following gets outputted to the log file:
2022-04-25T23:08:34.933016Z DEBUG sinuous::sonos: Connecting to provided speakers...
2022-04-25T23:08:34.933201Z DEBUG sinuous::sonos: Discovering speakers...
2022-04-25T23:08:35.282712Z  INFO sinuous::sonos: Found 2 speakers
2022-04-25T23:08:35.282745Z DEBUG sinuous::sonos: Starting sonos loop

It looks like it properly discovered my speakers (I have two), but then I guess it just crashes. I don't see any other log or terminal output. Any ideas where to look for what's going wrong?

Hi, thanks for the bug report!
It is hard indeed to know what caused the crash as I think at the moment if the main loop fails it prints something to the terminal, which is then immediately cleared and reset...
I have pushed a small change to send that error to the log file instead. Is there any chance you would be able to compile and try the latest main version? If not, I might release a new version as there is a small feature in the pipeline anyway.

Ok, I cloned the project down and ran via cargo run and got the following:
2022-04-26T02:56:46.376689Z DEBUG sinuous::sonos: Connecting to provided speakers...
2022-04-26T02:56:46.376829Z DEBUG sinuous::sonos: Discovering speakers...
2022-04-26T02:56:46.988723Z  INFO sinuous::sonos: Found 2 speakers
2022-04-26T02:56:47.036405Z DEBUG sinuous::sonos: Found 2 groups
2022-04-26T02:56:47.042870Z DEBUG sinuous::sonos: Starting sonos loop
2022-04-26T02:56:47.130400Z  WARN sinuous::sonos: Command channel was closed: exiting...

So given the lack of helpful message in the logs, it looks like it's not an "expected" error, but something that panics somewhere in the main loop. But of course whatever panic info that's printed gets lost when we reset the terminal 🙄
I've just pushed some changes to fix that so if you don't mind pulling the latest main branch and running RUST_LOG="sinuous=debug" cargo run --release, that would be helpful. It should print something in the terminal now if it panics, and generate a report file in /tmp that should contain some helpful information 🤞🏻

(@jat255 just realized you might not have seen my previous message since I didn't mention you)

Ah, yes I had missed this. Apologies. I'm away from home for a few days, but I'll try again over this weekend and try to report back

Ok, apologies once again, but I just tried running the latest code and got the following in the error log:
 ❯ cat /tmp/report-afa2db0f-7b57-4faf-a034-6d002adbae86.toml
name = 'sinuous'
operating_system = 'unix:Arch'
crate_version = '0.1.2'
explanation = '''
Panic occurred in file '/home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.18.0/src/widgets/gauge.rs' at line 62
'''
cause = 'Ratio should be between 0 and 1 inclusively.'
method = 'Panic'
backtrace = '''

   0: 0x5587ad4e6cc9 - <unresolved>
   1: 0x5587ad48577e - <unresolved>
   2: 0x5587ad3f952f - <unresolved>
   3: 0x5587ad45776e - <unresolved>
   4: 0x5587ad4289b8 - <unresolved>
   5: 0x5587ad43aee7 - <unresolved>
   6: 0x5587ad41178a - <unresolved>
   7: 0x5587ad47cf43 - <unresolved>
   8: 0x5587ad43a3b9 - <unresolved>
   9: 0x5587ad6936c1 - <unresolved>
  10: 0x5587ad415432 - <unresolved>
  11: 0x7f3fb5332310 - __libc_start_call_main
  12: 0x7f3fb53323c1 -<EMAIL_ADDRESS>  13: 0x5587ad3f2085 - <unresolved>
  14:        0x0 - <unresolved>'''

On the off chance this was a system package version issue, I did a full system upgrade and tried again. The error text changed slightly, but the general idea is the same:
 ❯ cat /tmp/report-52355b6a-58ed-4161-b842-585726ce15db.toml
name = 'sinuous'
operating_system = 'unix:Arch'
crate_version = '0.1.2'
explanation = '''
Panic occurred in file '/home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.18.0/src/widgets/gauge.rs' at line 62
'''
cause = 'Ratio should be between 0 and 1 inclusively.'
method = 'Panic'
backtrace = '''

   0: 0x55cc11b6dcc9 - <unresolved>
   1: 0x55cc11b0c77e - <unresolved>
   2: 0x55cc11a8052f - <unresolved>
   3: 0x55cc11ade76e - <unresolved>
   4: 0x55cc11aaf9b8 - <unresolved>
   5: 0x55cc11ac1ee7 - <unresolved>
   6: 0x55cc11a9878a - <unresolved>
   7: 0x55cc11b03f43 - <unresolved>
   8: 0x55cc11ac13b9 - <unresolved>
   9: 0x55cc11d1a6c1 - <unresolved>
  10: 0x55cc11a9c432 - <unresolved>
  11: 0x7f8628510290 - <unresolved>
  12: 0x7f862851034a - __libc_start_main
  13: 0x55cc11a79085 - <unresolved>
  14:        0x0 - <unresolved>'''

@jat255 Thanks, this is useful!
The ratio of (elapsed time / track duration), which I assumed should always be between 0 and 1, somehow isn't (not sure why). I've added some code to guard against that, so hopefully that'll fix things for you. Let me know how it goes.

Would you look at that, it's working! I think the issue is that I often listen to TuneIn stations and the like, which according to the TUI I'm seeing now, don't have any sort of length defined, so my guess is the ratio was going over 1:

Thanks again for your help debugging.

Glad it worked! I've just cut a release and updated the AUR package.


New version: ovital.OmapRevitPlugin version 1.1.1

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

This is getting blocked by anti-malware:

If it was blocked by Anti-Malware it would be red, this is Edge SmartScreen which does this to most new version releases, also it passed the anti-virus test in this PR

/azp run


Automatically publish minor version changes

Closes https://github.com/datadryad/dryad-product-roadmap/issues/2754
Also (hopefully) closes https://github.com/datadryad/dryad-product-roadmap/issues/3324

Oooh, yay, this is great!


#918 Fix Hard coded by Http Status code judgment.

Checklist

[x] Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests.
[x] If this PR comes from a fork, please Allow edits from maintainers
[x] Set a speaking title. Format: {task_name} (closes #{issue_number}). For example: Use logger (closes # 41)
[x] Link your Pull Request to an issue - Pull Requests that are not linked to an issue with you as an assignee will be closed, except for minor fixes for typos or grammar mistakes in documentation or code comments.
[x] Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.
[x] Make sure that your PR is not introducing unnecessary reformatting (e.g., introduced by on-save hooks in your IDE)
[x] Make sure that your PR does not contain changes in text files, therefore the PR must not contain changes in values/strings/* and / or assets/* (see issue #332 for further information)
[x] Make sure that your PR does not contain compiled sources (already set by the default .gitignore) and / or binary files

Description
Fix Hard coded by Http Status code judgment.

@pwoessner
please review this PR.

Dear @LeoAndo thank you for your contribution. Please let me quickly remind you of the issue template, though:

Pull Requests that are not linked to an issue with you as an assignee will be closed, except for minor fixes for typos or grammar mistakes in documentation or code comments.

We'll discuss with the team whether they can review the PR, but next time, please wait for a response in the corresponding issue.

@tkowark
yes, understood. I'll be careful in next time.


Unsupported '+' char for kafka topic?

Versions
Please specify real version numbers or git SHAs, not just "Latest" since that changes fairly regularly.
Sarama Version:  1416bd78f804d523005322194994f08c2a0ad797
Kafka Version:  kafka_2.11-<IP_ADDRESS>
Go Version:  go version go1.8 linux/amd64
Configuration
What configuration values are you using for Sarama and Kafka?
just see my program
Logs
./kafak-client -t '-test-.+'
[srama]2017/03/28 14:41:57 Initializing new client
[srama]2017/03/28 14:41:57 client/metadata fetching metadata for all topics from broker localhost:9092
[srama]2017/03/28 14:41:57 Connected to broker at localhost:9092 (unregistered)
[srama]2017/03/28 14:41:57 client/brokers registered new broker #0 at <IP_ADDRESS>:9092
[srama]2017/03/28 14:41:57 Successfully initialized new client
[srama]2017/03/28 14:41:57 client/metadata fetching metadata for [-test-.+] from broker localhost:9092
[srama]2017/03/28 14:41:57 client/metadata fetching metadata for [-test-.+] from broker localhost:9092
2017/03/28 14:41:57 kafka server: The request attempted to perform an operation on an invalid topic.

When filing an issue please provide logs from Sarama and Kafka if at all
possible. You can set sarama.Logger to a log.Logger to capture Sarama debug
output.
Problem Description
When I use bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic -test-.+ is ok . But when I use my program ./kafak-client -t '-test-.+' consume this topic got an error.
my program
package main

import (
	"fmt"
	"log"
	"os"
	"strings"
	"sync"

	"flag"

	"github.com/Shopify/sarama"
)

var (
	wg     sync.WaitGroup
	logger = log.New(os.Stderr, "[srama]", log.LstdFlags)
	topic  = flag.String("t", "hello", "topic")
)

func main() {
	flag.Parse()
	sarama.Logger = logger

	consumer, err := sarama.NewConsumer(strings.Split("localhost:9092", ","), nil)
	if err != nil {
		logger.Println("Failed to start consumer: %s", err)
	}

	partitionList, err := consumer.Partitions(*topic)
	if err != nil {
		logger.Println("Failed to get the list of partitions: ", err)
	}

	for partition := range partitionList {
		pc, err := consumer.ConsumePartition(*topic, int32(partition), sarama.OffsetNewest)
		if err != nil {
			logger.Printf("Failed to start consumer for partition %d: %s\n", partition, err)
		}
		defer pc.AsyncClose()

		wg.Add(1)

		go func(sarama.PartitionConsumer) {
			defer wg.Done()
			for msg := range pc.Messages() {
				fmt.Printf("Partition:%d, Offset:%d, Key:%s, Value:%s", msg.Partition, msg.Offset, string(msg.Key), string(msg.Value))
				fmt.Println()
			}
		}(pc)
	}

	wg.Wait()

	logger.Println("Done consuming topic")
	consumer.Close()
}

+ is not a valid character in a kafka topic name (https://github.com/apache/kafka/blob/f3f9a9eafb9aee9d87dd188521a4fd72466abfeb/core/src/main/scala/kafka/common/Topic.scala#L29). I don't know why kafka-console-consumer.sh is working, but it shouldn't be.


Route parameters not propagating correctly

When I try to use a route parameter in the QL for a container, it seems to be doing the wrong thing. I'm not sure if the issue is with this library, so sorry if it's not :)
I have the following:
var HomeQueries = {
    store: (Component) => Relay.QL`
    query {
      store {
         ${Component.getFragment('store')},
      },
    }
};

/* ...... */

<RelayRouter>
    <Route name="home" path="/:tenant" component={AppView} queries={HomeQueries}/>
</RelayRouter>,

/* ....... */

AppView = Relay.createContainer(AppView, {
    initialVariables: {
        tenant: 'hk'
    },

    prepareVariables: (args) => {
        console.log('prep tenant: ' + args.tenant);
        return {
            tenant: args.tenant
        };
    },

    fragments: {
        store: () => Relay.QL`
            fragment on Store {
                tenant(id: $tenant) {
                    id, name
                }
            }
        `
    }
});

When I go to this route: /vds
I see that prepareVariables is firing twice; the first time with tenant='hk', and the second time with tenant='vds'. But only one graphql request is being made, with tenant(id: "hk"). If I set tenant to null in initialVariables, then I just get a 400 error as it tries to make a graphql request with no id. My expectation would be that there would be one graphql call with tenant(id: "vds").
Bug or ID-10-T user error?

You're passing down params wrong. Check the other issues.

@geraldfvds did you figure this out? I'm having the same problem, and I'm haven't found an answer in the other issues.

@defrex  - I found a way that works, though I'm not sure it's "the" way. But essentially this is what I ended up using for HomeQueries:
var HomeQueries = {
    tenant: (Component) => {

        return Relay.QL`
            query {
                tenant(id: $tenantId) {
                    ${Component.getFragment('tenant')}
                }
            }
            `;
    }
};

And then my container:
AppView = Relay.createContainer(AppView, {

    initialVariables: {
        id: null
    },

    fragments: {
        tenant: () => Relay.QL`
            fragment on Tenant {
                id, name
            }
        `
    }
});

Hope this helps.

Thanks for getting back to me. I had just figured out a different solution. I'll add it here for the next person that comes along.
When I had the error, I was doing this:
Relay.createContainer(Dashboard, {
  prepareVariables: (variables)=> {
    return { date: `${variables.year}/${variables.month}` };
  },
  fragments: {
    viewer: ()=> Relay.QL`
      fragment on Viewer {
        summary(month: $date) {
          income
          allocated
          spent
          net
        }
      }
    `,
  },
});

prepareVariables would be called twice, once with year and month set correctly (they are from the route), and once with them undefined. The second call would be used for the query, resulting in "undefined/undefined" as my arg.
I changed it to this:
Relay.createContainer(Dashboard, {
  prepareVariables: (variables)=> {
    if (variables.year && variables.month)
      return { ...variables, date: `${variables.year}/${variables.month}` };
    else
      return variables;
  },
  fragments: {
    viewer: ()=> Relay.QL`
      fragment on Viewer {
        summary(month: $date) {
          income
          allocated
          spent
          net
        }
      }
    `,
  },
});

It turns out the second call to prepareVariables passes in the returned variables from the first call. I guess because I have nested routes with queries. That means the problem can be solved by not squashing anything, and not making any assumptions.

I am having exactly the same problem as @defrex, but his solution doesn't work for me. How come prepareVariables is being called twice, and why is it empty the second time around?
My component is on an IndexRoute, nested four levels deep into the router. There are no other Relay containers above it, so I'm not composing fragments anywhere. How can I make sure all route params are passed in correctly?
<Router
    history={browserHistory}
    render={applyRouterMiddleware(useRelay)}
    environment={Relay.Store}>
      <Route path="/" component={TabBarLayout} params={{nav: navTabs}}> // not a Relay container
        ...
        <Route path="/:year" >                  // <--- I need the :year
          <IndexRoute component={Overview} />
          ...
          <Route path="emails">
            <IndexRoute  component={EmailsList} queries={ViewerQuery} /> // <--- not working
            ...
          </Route>
          ...

used with
fragments: {
    viewer: () => Relay.QL`fragment on Viewer {
      year: yearByYear(year: $year) {   // <--- $year is undefined on second pass
        emails(first: 100) {
          ...

(That being said, everything is working wonderfully otherwise. Thanks a ton for providing this tool @taion!)

Aha! The problem goes away as soon as I add an initialVariables section. As far as I can tell, the need for this isn't documented in the README file. Could anyone confirm?

You probably need initialVariables, but I don't think that's a react-router-relay thing.

Ah, I see. It's challenging keeping track of which ones of the many moving pieces belong to which project. Thanks for the quick response!

What I mean is – when working with Relay, containers that need variables need to declare them in initialVariables, else things won't work.

Had the same issue.
Due to https://github.com/facebook/relay/issues/112 I had to nest everything under a viewer for those >1 arg queries.
What was missing on this thread for me was explicitly passing vars to the fragment. Here's what I did:
// routes
<Route path=":productId" queries={ViewerQuery} component={ProductPage} />

// queries
const ViewerQuery = {
  viewer: (Component, vars) => Relay.QL`
    query {
      viewer {
        ${Component.getFragment('viewer', vars)} # <-- this
      }
    }
  `
}

// container
ProductPage = Relay.createContainer(ProductPage, {
  initialVariables: {
    productId: ''
  },

  fragments: {
    viewer: () => Relay.QL`
      fragment on Viewer {
        product(id: $productId) {
          id
          name
        }
      }
    `,
  },
})

Without explicitly passing vars, this is the error I got:
Warning: RelayContainer: component `ProductPage` was rendered with variables
that differ from the variables used to fetch fragment `viewer`. The fragment was
fetched with variables `{"productId":""}`, but rendered with variables
`{"productId":"abc"}`. This can indicate one of two possibilities:
 - The parent set the correct variables in the query -
 `ProductPage.getFragment('viewer', {...})` - but did not pass the same
 variables when rendering the component. Be sure to tell the component what
 variables to use by passing them as props: `<ProductPage ... productId={...}
 />`.
 - You are intentionally passing fake data to this component, in which case
 ignore this warning.

@elado  Yes, that's the right way to do it anytime a parent component needs to pass down Relay variables to a child component so it has them available when generating its query. You also have to pass the prop itself in the React component, but here react-router-relay is handling that for you.


pkg/redirectpolicy: Delete unused variable in getAndUpsertPolicySvcCo…

In the handler of case svcFrontendNamedPorts, the "ports" is allocated and assigned with values, but never used. Thus, delete the related code.
Fixes: e7bb8a7eadb5 ("k8s/cilium Event handlers and processing logic for LRPs")

@aditighag I don't have to proper context on this specific bit of code. The unused variable seems to be there since the file was first created. Is this really dead code or is it a bug that we are not doing anything with the configured port names?

/test

/test


operator yugabyte-platform-operator-bundle-rhmp (2.14.2-1)

New operator bundle
Name: yugabyte-platform-operator-bundle-rhmp
Version: 2.14.2-1
Certification project: 5ffc47caf17d11e9ec9e2c87
Test result URL: https://catalog.redhat.com/api/containers/v1/projects/certification/test-results/id/633e45de44d0e37d64eb7477
Test logs URL: https://catalog.redhat.com/api/containers/v1/projects/certification/artifacts/id/633e45d944d0e37d64eb7472

@baba230896 This won't publish because you have the latest release of the stable channel as 2.14.2.
Semantic versioning dictates that hyphenated build tags denote pre-release versions, and so the OLM code treats it accordingly. 2.14.2-1 comes before 2.14.2 in this case.
You need to bump the version of the bundle to 2.14.3 in order to get around this. Also be aware that 2.14.2-1 actually got published to OpenShift 4.9 and 4.10 (I suppose because 2.14.2 didn't already exist there).


MTDSA-225 - Monitor API response times

Aware and working on that

Closing this PR as the changes are now in the mtdsa-662-new-resource-model branch