Uncaught SyntaxError: Unexpected token u

Trying to tweet and getting this error:

btw, testing this in Firefox.

Weird I can't replicate this error. Did you install the native modules by doing ./node_modules/.bin/electron-rebuild ? Go in the "Resources" tab in the bottom console and click on the left "Local storage" and then "file://". Can you tell me which keys you have? (don't paste the values as I currently store your secret key in plain text :smile:

I have this same issue, fresh install on macOSX El Capitan, node v5.6.0

Damn, please let me know. Do you mind pasting your localstorage? Just avoid pasting your secretKey value.

The keys I have:
key: 252bf9a5b26be7cc250b701300632fb63c5ee84e
value
{"v":{"t":":base64:Zm9v","d":":base64:AXJSDQ==","next":":base64:"}}

key: 77043241cc962bb5de9fda3db826cd6da7c8bde1
value
{"v":{"t":":base64:Zm9v","d":":base64:AXJSAA==","next":":base64:"}}

key: 7e511a162cfb8c2818636de2ca182ede4fc7a63a
value
{"v":{"n":"fczuardi","a":"https://pbs.twimg.com/profile_images/459016604047523842/1OFI8uiv.jpeg","i":""}}

key: d90524eed7410f1b30e7f7227dbfa8a590f08701
value
{"v":{"t":":base64:dGVzdGluZyBQZWVyVHdlZXQ=","d":":base64:AXJSAg==","next":":base64:"}}

key: dht-nodes
value
[{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":8196},{"host":"<IP_ADDRESS>","port":50321},{"host":"<IP_ADDRESS>","port":59169},{"host":"<IP_ADDRESS>","port":6998},{"host":"<IP_ADDRESS>","port":10120},{"host":"<IP_ADDRESS>","port":6889},{"host":"<IP_ADDRESS>","port":52564},{"host":"<IP_ADDRESS>","port":49001},{"host":"<IP_ADDRESS>","port":51539},{"host":"<IP_ADDRESS>","port":58977},{"host":"<IP_ADDRESS>","port":48379},{"host":"<IP_ADDRESS>","port":11411},{"host":"<IP_ADDRESS>","port":19881},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":11101},{"host":"<IP_ADDRESS>","port":32756},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":34954},{"host":"<IP_ADDRESS>","port":56606},{"host":"<IP_ADDRESS>","port":28701},{"host":"<IP_ADDRESS>","port":40562},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":6889},{"host":"<IP_ADDRESS>","port":56164},{"host":"<IP_ADDRESS>","port":20836},{"host":"<IP_ADDRESS>","port":56131},{"host":"<IP_ADDRESS>","port":8999},{"host":"<IP_ADDRESS>","port":8621},{"host":"<IP_ADDRESS>","port":45655},{"host":"<IP_ADDRESS>","port":31721},{"host":"<IP_ADDRESS>","port":43293},{"host":"<IP_ADDRESS>","port":18342},{"host":"<IP_ADDRESS>","port":8999},{"host":"<IP_ADDRESS>","port":25115},{"host":"<IP_ADDRESS>","port":28159},{"host":"<IP_ADDRESS>","port":56761},{"host":"<IP_ADDRESS>","port":34693},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":26416},{"host":"<IP_ADDRESS>","port":56038},{"host":"<IP_ADDRESS>","port":56697},{"host":"<IP_ADDRESS>","port":31526},{"host":"<IP_ADDRESS>","port":61504},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":33785},{"host":"<IP_ADDRESS>","port":14907},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":54354},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":30089},{"host":"<IP_ADDRESS>","port":35708},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":54109},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":25565},{"host":"<IP_ADDRESS>","port":59346},{"host":"<IP_ADDRESS>","port":28091},{"host":"<IP_ADDRESS>","port":23467},{"host":"<IP_ADDRESS>","port":26552},{"host":"<IP_ADDRESS>","port":11101},{"host":"<IP_ADDRESS>","port":52606},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":31465},{"host":"<IP_ADDRESS>","port":51413},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":64270},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":63313},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":63183},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":19103},{"host":"<IP_ADDRESS>","port":30101},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":7401},{"host":"<IP_ADDRESS>","port":29985},{"host":"<IP_ADDRESS>","port":27139},{"host":"<IP_ADDRESS>","port":50321},{"host":"<IP_ADDRESS>","port":6881},{"host":"<IP_ADDRESS>","port":29531},{"host":"<IP_ADDRESS>","port":43709}]

key: fd0c373efdac348d5ae23c4e677abd3522d1ffd6
value
{"v":{"t":":base64:dGVzdGluZyBwZWVydHdlZXQ=","d":":base64:AXJR/w==","next":":base64:"}}

I think I found the issue. You guys updated your avatar/name before posting the first tweet, right? Will fix asap.

correct!

Ok can you guys try git pull and test if it works?

after deleting all keys except the secret key and tweeting before changing avatar the error didnt occur and I can no longer reproduce, so I will be unable to test the fix :(

Ok anyway should work. Don't delete the pub key field!

I'll reopen to see if @stratospark can test.


Update nodejs runtime to move away from alpine

Issue Ref: [Issue number related to this PR or None]
Description:
Update the nodejs images to debian and move away from Alpine
TODOs:

[X] Ready to review
[ ] Automated Tests
[ ] Docs

follow on to https://github.com/kubeless/kubeless/pull/515

@ngtuna what's happening with the travis build ?


Adding in a semi-colon

Well, that is embarrassing.
I totally forgot to put a semi-colon on this last time.

thanks


(fix) A hiring school user can sign out…

… if they have not accepted the ToCs

 Sign out cannot be clicked if the user doesn't accept the terms and conditions page

@tahb I've removed the commits


add a script to update the changelog for new release

Add an entry to the debian/changelog for new release.

@panpan0000 @changev @yyscamper

@changev
Yes. I also considered to support a repo list at first.
But I'm not sure whether we will use the same version (i,e. 1.2.3) for all the repositories in the future.


date-picker  With shortcut options

This function solves the problem (这个功能解决的问题)
Shortcut options missing
Expected API (期望的 API)
date-picker  With shortcut options
For example, the latest day, the latest week, the latest month

Planned

@07akioni  Currently the first day of the week is Sunday, is it planned to set it to Monday?

@07akioni Currently the first day of the week is Sunday, is it planned to configure it to Monday?

It's related to locale.You want monday first in English?

No, for the English language, everything works fine. It would be for the French language. I was also thinking of adding in parallel the configuration for this one, as it is the case for the other languages:
https://github.com/TuSimple/naive-ui/tree/75fc48e31f3d7f49baebde31769dbbd141cde374/src/locales/date

https://github.com/TuSimple/naive-ui/tree/75fc48e31f3d7f49baebde31769dbbd141cde374/src/locales/date

There is a french PR.
https://github.com/TuSimple/naive-ui/pull/895

No, for the English language, everything works fine. It would be for the French language. I was also thinking of adding in parallel the configuration for this one, as it is the case for the other languages:
https://github.com/TuSimple/naive-ui/tree/75fc48e31f3d7f49baebde31769dbbd141cde374/src/locales/date

Or you can create a PR for French it there's no progress in that PR.


Update/go 1.20

move to testing with go 1.20
update dependencies to see if tests pass

Codecov Report

Merging #56 (306200f) into master (56e7cc0) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##           master      #56   +/-   ##
=======================================
  Coverage   59.36%   59.36%
=======================================
  Files           6        6
  Lines        1105     1105
=======================================
  Hits          656      656
  Misses        321      321
  Partials      128      128

Flag
Coverage Δ

unittests
59.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

changes required for go 1.20 related to https://github.com/golang/go/issues/56088

Could you mention what breaks older go versions?

Could you mention what breaks older go versions?

ecdh is not in 1.18 and 1.19


Loosing Gromacs atom name details when using an OpenMM topology

When I create an interchange using from_openmm and I provide an OpenMM topology for the topology= option, and then write out the Gromacs .top and .gro file, the atom names of protein atoms are, e.g. C and not CA. When I instead provide an OpenFF topology in the from_openmm call, the protein atom names have the same names as in the .pdb file used, e.g. CA. Is this information lost in the OpenMM topology or would it be possible to also transfer the atom names through that one?

This is legit and just an oversight; most of my testing has ensured that energy evaluations are reproduced in these code paths and atom names aren't needed for that.
The short of it, I think is -

The toolkit has Topology.from_openmm / Topology.from_pdb that Jeff and others have invested a lot of effort into and probably does what users expect w/r/t atom names, so if you used the toolkit to load a PDB file the atom names are probably accurately defined
Interchange has a thinner function that does the same thing when an OpenMM topology is passed to from_openmm, but does not route through the toolkit's solution and probably failed to process atom names from OpenMM for no reason other than oversight

I think I'm able to isolate what you're running into:
"""
$ INTERCHANGE_EXPERIMENTAL=1 python issue_1031.py
"""

import openmm.app
from openff.toolkit import Topology
from openff.interchange import Interchange

def get_atom_names(topology: Topology) -> set[str]:
    return {atom.name for atom in topology.atoms}

pdb_file = openmm.app.PDBFile("protein.pdb")

interchange = Interchange.from_openmm(
    system=openmm.app.ForceField(
        "amber99sb.xml",
        "tip3p.xml",
    ).createSystem(
        pdb_file.topology,
        nonbondedMethod=openmm.app.PME,
    ),
    topology=pdb_file.topology,
)

# These are more likely to accurately represent the intended data in the PDB;
# JW/JM and friends put a lot of work into this
toolkit_topology = Topology.from_pdb("protein.pdb")

print(get_atom_names(toolkit_topology))
# {'HD13', 'NZ', 'CG1', 'HD21', 'HG21', 'HB1', 'HG2', 'HG23', 'HD12', 'HE2', 'OH', 'HA', 'H1', 'HA3', 'H3', 'HD11',
# 'ND2', 'CZ', 'HZ', 'HD23', 'HH12', 'OG', 'HH21', 'CH2', 'C', 'OE1', 'H2', 'O', 'CD1', 'CE3', 'HB3', 'HE1', 'HB2',
# 'HE3', 'NH1', 'CG2', 'CA', 'OE2', 'HZ2', 'SD', 'HH11', 'SG', 'HG1', 'H', 'CE2', 'HZ3', 'HG13', 'HD22', 'HH', 'HH22',
# 'CZ2', 'HH2', 'CG', 'NH2', 'CE', 'N', 'CB', 'HD3', 'HE22', 'CD', 'HE', 'OD1', 'HD1', 'ND1', 'HA2', 'NE', 'NE1',
# 'CH3', 'HG11', 'HG22', 'HD2', 'HB', 'NE2', 'HG12', 'OG1', 'HE21', 'CE1', 'CD2', 'HG3', 'CZ3', 'HG', 'HZ1', 'OD2'}

# These match what OpenMM reports, so probably correct?
assert get_atom_names(toolkit_topology) == {atom.name for atom in pdb_file.topology.atoms()}

# Interchange's representation doesn't ingest these atom names
print(get_atom_names(interchange.topology))
# {''}

Does this accurately capture your expectations, and how Interchange loses the atom name information?
Would simply setting atom names from the openmm_topology.atoms() iterator suffice here, or are there other complications? (Stuff like this scares me, but I think atom names are simpler than residue/chain/insertion code spookiness.)
Are there other related bits of information or metadata that are missed that you'd expect not to be missed?

Thank you @mattwthompson for looking into this!

Yes, that is exactly what I observed!
Yes, I think that sounds like a good idea!
I can't think of other things!

Perfect, thanks. I'll work on the patch soon - hopefully it shakes out to be as simple as it seems to be right now

The fix is simple (one short line of code in the right place) but not so simple to rollout because it's actually in the toolkit (https://github.com/openforcefield/openff-toolkit/pull/1927). I have a fix in place (https://github.com/openforcefield/openff-toolkit/pull/1928) which should fix this - I'll run a few tests before making the release, but I don't expect any further hiccups.
As a matter of safety I don't make releases on Fridays, but this is looking good to launch early next week. Anticipate needing to upgrade to toolkit 0.16.4 and not needing to upgrade Interchange.

I think this is fixed with openff-toolkit =0.16.4
In [2]: print(get_atom_names(toolkit_topology))
{'NE', 'HD22', 'HA3', 'HD3', 'HZ1', 'CE3', 'HH21', 'HG12', 'CE', 'OE2', 'HG21', 'OD1', 'HA', 'HZ3', 'HZ', 'CB', 'NH2', 'ND2', 'HD12', 'CG', 'CD1', 'OH', 'CZ', 'HB3', 'HG23', 'HG', 'HE2', 'HD21', 'OD2', 'HD11', 'H2', 'O', 'OE1', 'HH12', 'HE3', 'HG13', 'HD13', 'HD1', 'HH', 'NE1', 'H3', 'HE1', 'SD', 'H', 'HE22', 'HG2', 'CE1', 'OG1', 'HH2', 'CH3', 'NE2', 'NZ', 'CZ2', 'CZ3', 'ND1', 'CA', 'N', 'CG1', 'SG', 'HA2', 'HB2', 'CD', 'CD2', 'HB', 'HG1', 'HG11', 'HB1', 'C', 'HH22', 'CG2', 'CH2', 'H1', 'HD2', 'HG22', 'HE', 'HZ2', 'HE21', 'HD23', 'HH11', 'HG3', 'NH1', 'CE2', 'OG'}

In [3]: print(get_atom_names(interchange.topology))
   ...:
{'NE', 'HD22', 'HA3', 'HD3', 'HZ1', 'CE3', 'HH21', 'HG12', 'CE', 'OE2', 'HG21', 'OD1', 'HA', 'HZ3', 'HZ', 'CB', 'NH2', 'ND2', 'HD12', 'CG', 'CD1', 'OH', 'CZ', 'HB3', 'HG23', 'HG', 'HE2', 'HD21', 'OD2', 'HD11', 'H2', 'O', 'OE1', 'HH12', 'HE3', 'HG13', 'HD13', 'HD1', 'HH', 'NE1', 'H3', 'HE1', 'SD', 'H', 'HE22', 'HG2', 'CE1', 'OG1', 'HH2', 'CH3', 'NE2', 'NZ', 'CZ2', 'CZ3', 'ND1', 'CA', 'N', 'CG1', 'SG', 'HA2', 'HB2', 'CD', 'CD2', 'HB', 'HG1', 'HG11', 'HB1', 'C', 'HH22', 'CG2', 'CH2', 'H1', 'HD2', 'HG22', 'HE', 'HZ2', 'HE21', 'HD23', 'HH11', 'HG3', 'NH1', 'CE2', 'OG'}


[BUG] Unknown XML-RPC tag

Describe the bug
Throws an error when trying to run the bot. Previously the fix was to set the img string to null in GroupChat.JS
https://github.com/redrobotsl/discord-sl-chat-relay/blob/204a7d6ef97795d2c2043fefdccc24c0edaa0384/SLevents/GroupChat.js#L33-L34
This not longer works, as it throws the following error:
[2023-07-29 23:10:50]: READY xxxxx#xxxx, ready to serve 179 users in 1 servers.
Error: Unknown XML-RPC tag 'H1'
    at Deserializer.onError (/root/discord-sl-chat-relay/node_modules/xmlrpc/lib/deserializer.js:115:20)
    at Deserializer.onClosetag (/root/discord-sl-chat-relay/node_modules/xmlrpc/lib/deserializer.js:208:14)
    at SAXStream.emit (node:events:514:28)
    at me._parser.<computed> [as onclosetag] (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:258:17)
    at emit (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:624:35)
    at emitNode (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:629:5)
    at closeTag (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:889:7)
    at SAXParser.write (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:1436:13)
    at SAXStream.write (/root/discord-sl-chat-relay/node_modules/sax/lib/sax.js:239:18)
    at IncomingMessage.ondata (node:internal/streams/readable:766:22)

Expected behavior
The relay will run
Desktop (please complete the following information):

OS: ANY

Additional context
Package List:
<EMAIL_ADDRESS>/root/discord-sl-chat-relay
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>
Node Version: v18.17.0
NPM Version: 9.6.7

Bug confirmed and acknowledged. Working on a fix

Issue: Unable to retrieve Profile Picture UUID as Second Life is weird.
Resolution:

Need to Change the HTML Tag that we are looking for to looking for a  tag with class "avatar"

Fixed in Commit #3d37ca6cbe00


Tracked bugs with P3, P4 or P5 priority

Should not happen.
https://bugzilla.mozilla.org/buglist.cgi?priority=P3&priority=P4&priority=P5&f1=cf_tracking_firefox66&o3=anyexact&list_id=14467509&v3=%2B%2Cblocking&o1=anyexact&resolution=---&o2=anyexact&query_format=advanced&f3=cf_tracking_firefox64&f2=cf_tracking_firefox65&v1=%2B%2Cblocking&v2=%2B%2Cblocking

done


Add sphinx copy button to conf.py

The sphinx copy button is now added to the setup.py and to the sphinx
conf.py, so it is not necessary to have its source code in our files.

Close for now. Will migrate to readthedocs first.


AbstractFunctionRestrictionsSniff::is_targetted_token() incorrectly treats first class callable as a function call

Bug Description
The method AbstractFunctionRestrictionsSniff::is_targetted_token() is used to determine if a given token is a function call or not. It does not handle first class callables properly and identifies them as function calls, which is incorrect.
I found this while using AbstractFunctionParameterSniff::process_no_parameters() to create the sniff for #2473. AbstractFunctionParameterSniff is affected by this bug and sees first class callables as a function call without parameters.
Loosely related to this PHPCSUtils PR: https://github.com/PHPCSStandards/PHPCSUtils/pull/362
Minimal Code Snippet
The issue happens when running this command:
phpcs --standard=WordPress --sniffs=WordPress.Utils.I18nTextDomainFixer test.php

Over a file containing this code:
<?php
// phpcs:set WordPress.Utils.I18nTextDomainFixer old_text_domain[] text-domain
// phpcs:set WordPress.Utils.I18nTextDomainFixer new_text_domain something-else

$callable = __(...);

Error Code
FILE: test.php
---------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------------------
 5 | WARNING | Missing $domain arg and preceding argument(s) (WordPress.Utils.I18nTextDomainFixer.MissingArgs)
---------------------------------------------------------------------------------------------------------------

Environment

Question
Answer

PHP version
8.3

PHP_CodeSniffer version
3.10.1

WordPressCS version
develop branch

PHPCSUtils version
1.0.12

PHPCSExtra version
1.2.1

WordPressCS install type
git clone

Additional Context (optional)
I can try to create a PR to fix this problem, but it seems there are no tests for the AbstractFunctionRestrictionsSniff::is_targetted_token() and for the rest of the AbstractFunctionRestrictionsSniff. I believe it would be important to start by creating tests first.
Tested Against develop Branch?

[x] I have verified the issue still exists in the develop branch of WordPressCS.

The method AbstractFunctionRestrictionsSniff::is_targetted_token() is used to determine if a given token is a function call or not. It does not handle first class callables properly and identifies them as function calls, which is incorrect.

@rodrigoprimo Well, no. The abstract tries to determine whether a function is being used, not whether it is called. That includes recognizing use function... statements and first class callables.

I found this while using AbstractFunctionParameterSniff::process_no_parameters() [snip]. AbstractFunctionParameterSniff is affected by this bug and sees first class callables as a function call without parameters.

That's something to think about. Should the sniffs using that method handle this potential situation ? Should the AbstractFunctionParameterSniff ignore first class callables ? or should the abstract get a new processFirstClassCallable() method ?
Also note that the WPCS native abstracts will be phased out once the planned (and fully tested) abstracts in PHPCSUtils will be available.

I can try to create a PR to fix this problem, but it seems there are no tests for the AbstractFunctionRestrictionsSniff::is_targetted_token() and for the rest of the AbstractFunctionRestrictionsSniff. I believe it would be important to start by creating tests first.

At this time, the abstracts are tested via the sniffs, in particular via the DB\RestrictedFunctions and PHP\StrictInArray sniffs. Considering the abstracts will be deprecated and removed in the foreseeable future, I don't think adding dedicated tests is the way to go. Enhancing the tests in the aforementioned sniffs, is, of course, welcome.

@rodrigoprimo Well, no. The abstract tries to determine whether a function is being used, not whether it is called. That includes recognizing use function... statements and first class callable.

@jrfnl, maybe then the short description of the DocBlock for AbstractFunctionRestrictionsSniff::is_targetted_token() should be updated? It directly says that the method verifies if the current token is a function call and not whether a function is being used:
https://github.com/WordPress/WordPress-Coding-Standards/blob/dfd6c3a8ee61eed6af15bda09f4a33d79eb2b86b/WordPress/AbstractFunctionRestrictionsSniff.php#L217

That's something to think about. Should the sniffs using that method handle this potential situation ? Should the AbstractFunctionParameterSniff ignore first class callables ? or should the abstract get a new processFirstClassCallable() method ?

My understanding is that the AbstractFunctionParameterSniff is an abstract to be used by sniffs that deal with function parameters when a given list of functions is called. First class callables and use function are not function calls, and parameters are not passed to the functions when they are used in these two contexts, so I'm inclined to think that we should modify AbstractFunctionParameterSniff to bail in those cases.
That being said, I also see some reasons that make me wonder if it is worth doing this change at this point:

The abstract is going to be replaced.
This would be a breaking change so we would need to check all the sniffs that are currently using the abstract to see if they are affected or not.
To the best of my knowledge, this issue was not reported before, which indicates that it is not a high priority fix.

What do you think?

At this time, the abstracts are tested via the sniffs, in particular via the DB\RestrictedFunctions and PHP\StrictInArray sniffs. Considering the abstracts will be deprecated and removed in the foreseeable future, I don't think adding dedicated tests is the way to go. Enhancing the tests in the aforementioned sniffs, is, of course, welcome.

Thanks for the additional context. I agree that it doesn't make sense to add dedicated tests as those abstracts will be replaced.


Intercommunication between multiple TSERS applications

I have a fairly large module that I want to break into smaller independent micro-services that can communicate with each other. Each service would have its own transformations and executors and eventually communicate via signals.
I think TSERS would make a lot of sense in this particular case, except that the TSERS function returns a disposable instead of a stream. I am not sure how it should be designed and what stream should it exactly be returning.

Did my gitter answer solve this question?

@milankinen Yes, I think it is a decent approach to solve the problem.


Add sample links

Adding more samples to README, with some creation details

Thanks, @will-moore. Getting this merged before there are too many more changes. We can always look at extracting it to a separate repo like https://ome.github.io/ome-ngff-tools/ later


feat: Add tap-db2 variant description

I have created an SDK-based variant of the tap-db2 extractor over on https://github.com/danielptv/tap-db2.
The plugin offers encrypted connections to the DB2 via server certificate.
Additionally, the default variant does not work on the z/OS version of DB2 due to it executing SQL statements on tables that are not present on the z/OS variant. This new variant has been explicitly tested against a DB2 running on z/OS.

@danielptv this is awesome, thanks for the PR! I added a few minor comments but looks great.

@pnadolny13 thank you for the review. I have now applied all of your suggestions.


Publications page implementation

Gradual additions to the new publications page, inspired by the OKFN publications page layout and features, adapted for Jekyll.

Two previews of the list and single page layouts.

https://github.com/okfde/buendnis-f5/assets/25004151/98b49579-b1a5-4ec1-a9f6-c22acd573b54
@elioqoshi @Henriette129 this is a preview of the filtering function, where multi-filtering is possible at the same time.


master branch fails: stringify should serialize proxied functions FAILED

Expected behaviour
git pull master ...
npm test
pass
Actual behaviour
Chrome 66.0.3355 (Mac OS X 10.13.3) stringify should serialize proxied functions FAILED
AssertionError: 'function () { ... }' deepEqual 'Proxy(function abc(...) { ... })'
at Context. (absolute/var/folders/00/137s0000h01000cxqpysvccm004cz4/T/b709b7186f05f556af69d7c1a8666b16.browserify?2f2568776166a6bb8470c50f8d0112fb2cb53645:20463:14)
........
Chrome 66.0.3355 (Mac OS X 10.13.3): Executed 36 of 36 (1 FAILED) (0.12 secs / 0.031 secs)
Error
at callDone (/work/karma/node_modules/grunt/node_modules/grunt-legacy-util/index.js:159:52)
at ChildProcess. (/work/karma/node_modules/grunt/node_modules/grunt-legacy-util/index.js:198:5)
at emitTwo (events.js:126:13)
at ChildProcess.emit (events.js:214:7)
at maybeClose (internal/child_process.js:925:16)
at Socket.stream.socket.on (internal/child_process.js:346:11)
at emitOne (events.js:116:13)
at Socket.emit (events.js:211:7)
at Pipe._handle.close [as _onclose] (net.js:554:12)
Fatal error: Client unit tests failed.
npm ERR! Test failed.  See above for more details.
Environment Details

Karma version (output of karma --version):
Relevant part of your karma.config.js file

Steps to reproduce the behaviour

npm test

Maybe related:
https://www.chromestatus.com/feature/5666372071718912
Function.prototype.toString revision


support empty case

At current moment it's not possible to add empty case, e.g.
[ "\"", "'", ""]

https://github.com/BriteSnow/vscode-toggle-quotes/pull/40


Syntastic integration

I currently use these settings:
let g:elm_jump_to_error = 0
let g:elm_make_show_warnings = 1
let g:elm_make_output_file = '/dev/null'

let g:syntastic_elm_checkers = [ 'elm_make' ]

...in combination with this wrapper in ~/.vim/syntax_checkers/elm/elm_make.vim:
if exists('g:loaded_syntastic_elm_elm_make_checker')
    finish
endif
let g:loaded_syntastic_elm_elm_make_checker = 1

let s:save_cpo = &cpo
set cpo&vim

function! SyntaxCheckers_elm_elm_make_GetLocList() dict
    call elm#Make()
    let fixes = getqflist()
    call setqflist([])
    cclose

    return fixes
endfunction

call g:SyntasticRegistry.CreateAndRegisterChecker({
    \ 'filetype': 'elm',
    \ 'name': 'elm_make',
    \ 'exec': 'elm-make'})

let &cpo = s:save_cpo
unlet s:save_cpo

Which seems to work fine so far, but it would be cleaner if I could get the list of fixes directly from either elm#Make(), or maybe a new function elm#Compile() which extracts the common parts. What do you think?

I completely agree. Let me see what I can come up with.

I have restructured how elm#Make works and added support for syntastic out of the box. I would suggest using the following settings:
let g:syntastic_always_populate_loc_list = 1
let g:syntastic_auto_loc_list = 1

let g:elm_syntastic_show_warnings = 1

You should be able to remove your custom code. Let me know if you run into any issues. Thanks for getting me started in the right directions!

Thanks, works great!


 The code is as follows.

MINICPMV_PATH = "local_path/MiniCPM-V-2"

llm = LLM(model=MINICPMV_PATH,
                  tensor_parallel_size=1,
                  gpu_memory_utilization=0.95,
                  trust_remote_code=True,
                  max_model_len=4096)

The following is detail logs:
File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/infer_codes/miniCpmV_infer_vllm.py", line 37, in _build_vllm_and_tokenzier
[rank0]:     llm = LLM(model=MINICPMV_PATH,
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/entrypoints/llm.py", line 155, in __init__
[rank0]:     self.llm_engine = LLMEngine.from_engine_args(
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/engine/llm_engine.py", line 447, in from_engine_args
[rank0]:     engine = cls(
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/engine/llm_engine.py", line 265, in __init__
[rank0]:     self._initialize_kv_caches()
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/engine/llm_engine.py", line 364, in _initialize_kv_caches
[rank0]:     self.model_executor.determine_num_available_blocks())
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/executor/gpu_executor.py", line 94, in determine_num_available_blocks
[rank0]:     return self.driver_worker.determine_num_available_blocks()
[rank0]:   File "/mllm/yangjirui03/envs/miniCpmV_vllm2/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/worker.py", line 179, in determine_num_available_blocks
[rank0]:     self.model_runner.profile_run()
[rank0]:   File "/mllm/yangjirui03/envs/miniCpmV_vllm2/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/model_runner.py", line 927, in profile_run
[rank0]:     model_input = self.prepare_model_input(
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/model_runner.py", line 1265, in prepare_model_input
[rank0]:     model_input = self._prepare_model_input_tensors(
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/model_runner.py", line 839, in _prepare_model_input_tensors
[rank0]:     builder.add_seq_group(seq_group_metadata)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/model_runner.py", line 493, in add_seq_group
[rank0]:     per_seq_group_fn(inter_data, seq_group_metadata)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/worker/model_runner.py", line 468, in _compute_multi_modal_input
[rank0]:     mm_kwargs = self.multi_modal_input_mapper(mm_data)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/multimodal/registry.py", line 93, in map_input
[rank0]:     .map_input(model_config, data_value)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/multimodal/base.py", line 228, in map_input
[rank0]:     return mapper(InputContext(model_config), data)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/multimodal/image.py", line 117, in _default_input_mapper
[rank0]:     image_processor = self._get_hf_image_processor(model_config)
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/multimodal/image.py", line 109, in _get_hf_image_processor
[rank0]:     return cached_get_image_processor(
[rank0]:   File "/mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/offical_vllm_for_miniCPM/vllm/vllm/transformers_utils/image_processor.py", line 17, in get_image_processor
[rank0]:     processor = AutoImageProcessor.from_pretrained(
[rank0]:   File "/mllm/yangjirui03/envs/miniCpmV_vllm2/lib/python3.10/site-packages/transformers/models/auto/image_processing_auto.py", line 410, in from_pretrained
[rank0]:     config_dict, _ = ImageProcessingMixin.get_image_processor_dict(pretrained_model_name_or_path, **kwargs)
[rank0]:   File "/mllm/yangjirui03/envs/miniCpmV_vllm2/lib/python3.10/site-packages/transformers/image_processing_base.py", line 335, in get_image_processor_dict
[rank0]:     resolved_image_processor_file = cached_file(
[rank0]:   File "/mllm/yangjirui03/envs/miniCpmV_vllm2/lib/python3.10/site-packages/transformers/utils/hub.py", line 373, in cached_file
[rank0]:     raise EnvironmentError(
[rank0]: OSError: /mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/MiniCPM-V-2 does not appear to have a file named preprocessor_config.json. Checkout 'https://huggingface.co//mllm/yangjirui03/workspace/ThirdPartyMLLM/MiniCPM_V/MiniCPM-V-2/tree/None' for available files.

Please refer to the note:
https://github.com/vllm-project/vllm/blob/main/examples/offline_inference_vision_language.py#L85-L88
Sorry for the confusion! We'll update the "Supported Models" page to reflect this.


Users/nigurr/fix vs test dll input

if full paths of 2 DLLs separated by semicolon are passed through Test Assembly field - the task fails.

looks fine

Let us at least document that we will not support semicolon in path names, otherwise looks fine.


DevelopHappy New Year! update copyright year to 2015

Happy New Year! update copyright year to 2015

PR is incorrectly rebased, closing.

PR is incorrectly rebased, closing.


browser drop down menus look jarring on Windows (WSL), should replace with our nice custom dropdowns

There are a handful of browser native drop down menus in our app, and they don't look very good on Windows (WSL).
https://user-images.githubusercontent.com/2380975/198413225-ed63c7ac-cf0f-427b-8a9f-fe85fe3ae447.mp4
We have the much nicer looking dropdown components that we use for time selection in the leaderboards and that are styled to match the rest of the app. Those look also look fine on windows -- we should use them rather than native dropdowns throughout the app.

Let's figure out whether we want to recommend this path before we prioritize work to make it look nice.
https://github.com/rilldata/rill-developer/issues/1143


Add support for ZIP 313

ZIP 313 changes the default/conventional fee for shielded transactions from 10,000 zats to 1,000 zats
https://github.com/zcash/zips/pull/408
To implement this change, clients are recommended to change the default fee from 10,000 to 1,000 zats for shielded transactions.
Activation:

The new default fee of 0.00001 or 1000 zats must start activation at block 1,080,000
With a grace period of ~4 weeks (block 1,120,000) to upgrade to the reduced default transaction fee for zcashd and core clients used by exchanges & service providers.

The implementation to activate the new fee can start anytime from the start to the end of the 4 week transition period outside which the shielded transaction fees will stand out from the updated light client fees of 1000 zats.

This is supported in milestone 3! https://github.com/Zondax/ledger-zcash/blob/master/app/src/crypto.c#L313-L316


Fix JSON encoding of non-standard dict keys

Fixes #982 (any my own problem)
Enables defaultdict instances to be passed
reason this occurred was that the crash occurred
before default was actually called, so the
BetterJSONEncoder was not able to catch this.
Added plenty of tests for those and similar cases.

How is a defaultdict getting all the way to the JSON serializer? These should get caught by the other serializer code I thought.

@dcramer By passing it e.g. via logger.warn("Foo", extra=locals()). I remembered I had an issue with defaultdict before, can't remember if it was passed directly or via locals() though.

I'm not opposed to this, but if thats the case, it seems like we'd be better off trying to correct whatever broke within logger (could have been something like tags or similar). There's an expectation that things passed to our JSON serializer are already JSON-compatible types.

Does this mean that it's the developers problem if she uses logger.error("Foo", extra=locals()) and having a dict with a non-serializable key somewhere in there or that there is something wrong with other parts of Raven having it propagate this far in the first place? If so can you please point me to the relevant part of the code so I can have a look at that?

@smokey42 I think my preferred approach would be that in our logging handler we ensure that data passed from extra to whatever is not an invalid type. I'm imagining this is a specific attribute that isnt coerced correctly (e.g. tags or something).

@dcramer So if you imagine never passing invalid stuff to the JSON encoder, would you like the BetterJSONEncoder being removed as well and have some coercion function used instead on all call sites? A quick grep only shows Client.encode. As the coercion should be done as late as possible (but not in BetterJSONEncoder which is the latest possible) it imho should be done in Client.encode.


CSL sampling window for CSL Receiver (SSED) is too tight

Describe the bug A clear and concise description of what the bug is.
The start of the CSL sampling window is very tightly calculated based on the CSL Accuracy reported parameters by the Parent. This may lead to interoperability issues, especially if the device (CSL Transmitter) sending the CSL Accuracy TLV takes the description in the spec (4.4.33) rather literally.  The description (for CslAccuracy and CslUncertainty, at the bottom) in the spec does not mention these values must be worst-case which could lead to a device sending its typical CSL clock uncertainty, not the worst-case one.
Another issue is that the exact interpretation of what happens at the end of CSL Phase may differ among implementers per SPEC-1154.  This may cause a Parent CSL Transmitter to be 192 us early w.r.t. to the OpenThread receiver.
Consequence: the CSL transmission is not received as it could arrive too early at the CSL Receiver.
To Reproduce Information to reproduce the behavior, including:
See Thread CSL test captures.
Expected behavior A clear and concise description of what you expected to happen.
CSL transmission is received, even if reported CSL Accuracy values are slightly off or vendor of Parent uses a slightly different interpretation of CSL Phase.
The proposal is to add some additional "slack" time that allows for the variation. E.g.  SubMac::GetCslWindowEdges() starts receiving window a fixed 256 us earlier. This is defined separate from the vendor's RF RX ramp up time.
That is, it is insufficient to just adapt the value kCslReceiveTimeAhead to be higher. In the call Get<Radio>().ReceiveAt() in sub_mac.cpp the time kCslReceiveTimeAhead is not included in determining the start of Rx time. So it needs to be a separate constant that's also applied in the ReceiveAt() call start time.
Background:
static constexpr uint32_t kCslReceiveTimeAhead = OPENTHREAD_CONFIG_CSL_RECEIVE_TIME_AHEAD;

Console/log output If applicable, add console/log output to help explain your problem.
N/A
Additional context Add any other context about the problem here.
SPEC-1154

I submitted a PR. I'm doing some testing and will then ask for reviews.

Hi, still investigating on the Nordic's side, but the proposed solution doesn't seem optimal:

It increases receive window duration (more power consumption).
Need to verify that the CSL Phase value injected in the CSL IE is matching the expected timing.

I'll keep you updated with our findings.

Please check this alternative: https://github.com/openthread/openthread/pull/8743
Main differences are:

Preamble is considered for the transmission as well.
Receive window duration is not extended.
Local radio uncertainty is taken into account for receive window duration.

@edmont I see you want to re-use the existing CSL uncertainty value (GetCslUncertainty() / otPlatRadioGetCslUncertainty()) for both CSL Transmitter and CSL receiver to express the uncertainty. That avoids having to add more functions for Tx vs Rx uncertainty separately.  But it does force this internal quantity to be defined in "multiples of 10 us" which would in principle not be needed. It could be defined as a value in units of 1 us, as it's just an internal compilation constant that's not sent over the wire.
In case we go for the "single value" approach I think the OT platform developers have to pay attention in case their platform supports compilation to both CSL Transmitter (FTD REED) and Receiver (MTD SSED) that for respective cases the right number is chosen. E.g. using preprocessor directives or by having multiple platform configurations.
Since it may differ what the CSL Tx scheduling uncertainty is, vs the Rx uncertainty.
So if I'm correct a CSL Receiver may have some uncertainty in the timestamp of the received CSL IE frame, e.g. the reception time may only be available in multiples of 16 us. In that case the CSL Rx Uncertainty value is at least 16 us. If defined in units of 1 us then the Rx Uncertainty constant would be 16.  Using the current definition it has to be 2.
This seems close enough to not matter much.

Receive window duration is not extended

Sounds ok, if I read the code correctly the Get<Radio>().Sleep() is not called if the radio is still in the process of receiving some frame , right?

@edmont I see you want to re-use the existing CSL uncertainty value (GetCslUncertainty() / otPlatRadioGetCslUncertainty()) for both CSL Transmitter and CSL receiver to express the uncertainty.

The general idea is that the radio would have about the same uncertainty when scheduling reception or transmission operations. A granularity of 10 us is good enough in terms or energy consumption. And, likewise the parent uncertainty case, the API leaves the option open for more complex platform implementations which take into account current conditions to calculate varying with time values.
Ideally a separate API should be used for RX or TX uncertainty, but I'd say this is a fair optimization.

Sounds ok, if I read the code correctly the Get<Radio>().Sleep() is not called if the radio is still in the process of receiving some frame , right?

Exactly.

One further thing to note on the CSL receiver uncertainty in the @edmont  PR is that it should be rounded "upwards". So say the receiver has a 1, 2 or 4, or 5 us uncertainty then its reported CSL uncertainty value must be 1 for 10 us. And if it has 11, 12, 14, 16 then the reported value becomes 2 for 20 us. Maybe we could/should adjust the calculation so that more intuitive rounding can take place (1, 2, 3, 4 -> 0  and 5, 6, 7 -- 14 -> 1, etc.)   This is easy to do by just adding +5 us to the calculation of CSLuncertainty value -> us.
Also in the PR the receiver still has zero "slack" time, that is, if Parent reports its inaccuracy/uncertainty perfectly and Child knows its inaccurayc/uncertainty perfectly then it may occur that the transmission starts exactly at the time the reception is ready.  A slight imperfection here in the estimate of the parameters may cause the frame transmission to fail.
Maybe it should have either a "slack" time or "precaution" time in the receiver of say 4, 8 or 16 us, or else the transmitter or the receiver needs to add +1 to their CSL uncertainty value.  A transmitter currently may report '0' if it's timer has 1 us or 2 us resolution. The receiver should take this into account but currently it doesn't as there is zero slack.

So say the receiver has a 1, 2 or 4, or 5 us uncertainty then its reported CSL uncertainty value must be 1 for 10 us.

I don't consider this a big deal. In the worst case, assuming that someone would be able to make so accurate measurements that is certain to confirm that the receiver uncertainty is ±1 us, it would need to use the 10 us value which means the receive window duration is extended by "unneeded" 18 us extra. I'd say this is negligible in the total power consumption.

A slight imperfection here in the estimate of the parameters may cause the frame transmission to fail.

Wouldn't this mean some of the sides didn't report their real uncertainty?

or the receiver needs to add +1 to their CSL uncertainty value

I'd say this would be a good practice to cover for this "slack" time.

A transmitter currently may report '0' if it's timer has 1 us or 2 us resolution.

I would expect this transmitter to report the minimum uncertainty value covering this case, as allowed by Thread Specification, which would be 10 us.

Wouldn't this mean some of the sides didn't report their real uncertainty?
True, but reporting your uncertainty as '10 us' 1 when your real uncertainty is say 2 us is counter-intuitive for some. Reporting '0 us' 0 would be closer to the truth in fact. So what exactly is the real uncertainty vs what to report is the question here.

But agree here with you that letting both transmitter and receiver "round up" their CSL uncertainty is an easy solution and works. The spec would then also need to clarify this a bit.
Also the PR assumes that the first symbol of the MAC-header will occur at the time "T_phase", the time that can be calculated by (CSL-phase * 160) us. Just wanted to check that this is correct and intended.

Question on the current code and the PR: We discussed that a CSL receiver wouldn't stop receiving (i.e. go to sleep) when it was still busy receiving a frame.  If so then the kMinCslWindow can be made much shorter -- only long enough to receive the PHY header in principle so that the receiver can detect a frame Rx is ongoing and can report this state to OpenThread.
That would dramatically improve the energy efficiency. Or, is it the idea that OpenThread provides a default value -- e.g. for radios that don't detect that they are receiving something - or a default value that's only meant to be adapted by the platform implementers?

@EskoDijk

Sounds ok, if I read the code correctly the Get().Sleep() is not called if the radio is still in the process of receiving some frame , right?

As I understand, Get().Sleep() will still be called if the radio is receiving. But the Nordic platform will allow the receiving complete before turning to sleep. I think maybe we can configure the window based on platform. Currently OT provides a default value OPENTHREAD_CONFIG_CSL_MIN_RECEIVE_ON. That can be overriden by upper level parameters.

Resolved by #8743


Update limitlessled requirement to v1.0.8

Description:
Fixes connection problem with older bridges.
Related issue (if applicable): fixes #7599
Checklist:
If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable ([example][ex-requir]).
[x] New dependencies are only imported inside functions that use them ([example][ex-import]).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

Hello @corneyl,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

1a0ce6c22700817ab2324ef6350cd815562213a4 - This commit has something that looks like an email address (cj@e-marine.nl). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Is there still a CLA error? I added the correct author info to the commit, and the bot added the cla-signed label afterwards, but didn't remove the cla-error label.

It's all good 👍  🐬


Is it still maintained ?

Hey guys, i like what you have done in this project and i actively use it, but i would like to ask if it is still maintained or is it a dead project :) If not i would like to make some contributions, which would also help me a lot. Thanks in advance

Hey, as we can see this project is dead but if you really want to contribute, you can create a fork and make your changes.
Good luck🍀


fix #268: install mongo first so mongod user is available

merged to keep moving but please review.


Publish 02/03/2022 3:30 PM PT

Docs Build status updates of commit db5f258:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docset/winserver2012r2-ps/smbshare/Grant-SmbShareAccess.md
:white_check_mark:Succeeded
View (winserver2012r2-ps)

docset/winserver2016-ps/smbshare/Grant-SmbShareAccess.md
:white_check_mark:Succeeded
View (WindowsServer2016-ps)

docset/winserver2019-ps/smbshare/Grant-SmbShareAccess.md
:white_check_mark:Succeeded
View (WindowsServer2019-ps)

docset/winserver2022-ps/smbshare/Grant-SmbShareAccess.md
:white_check_mark:Succeeded
View (WindowsServer2022-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Clarify logging

print() are not shown in stdout
logging.info() are shown to stdout

This likely stems from the s6 logging configuration.

I'll probably no longer use s6. Also we started to use ELK to centralize the logs so there is no need to setup an advanced strategy to organize rotating log files in the container.


how can i get the cstddef

In file included from C:\Users\dream\AppData\Local\Temp.arduinoIDE-unsaved2023217-8988-1vhfcel.y73jj\i2c\i2c.ino:26:0:
C:\Users\dream\Documents\Arduino\libraries\Bolder_Flight_Systems_MPU9250\src/mpu9250.h:36:10: fatal error: cstddef: No such file or directory
#include
^~~~~~~~~
compilation terminated.
exit status 1
Compilation error: exit status 1

Please try downloading and using the latest version from GitHub.

may you tell me how to install it from github  ?  i downloaded the files

Please try downloading and using the latest version from GitHub.

thanks


fix: Close OkHTTP response when done

See: https://github.com/relaycorp/relaynet-gateway-android/pull/182#issuecomment-726665089

Closing because the original issue is actually caused by something else


dbt: final clean up of int models feeding code & onchain metrics marts

What is it?
Each metric feeding the consolidated project metrics marts should be available as a standalone query, ie,

int_code_metric__X
int_onchain_metric__Y

Then int_code_metrics_by_project should import all relevant queries in one big union statement and join on project data
The final code_metrics_by_project_v1 should simply import int_code_metrics_by_project

The models should be good to go, however, I haven't been able to fully simulate everything in oso_playground. Copying a thread from Discord:

Something weird has been happening over the weekend. My attempts at dbt run have been hanging and I need to cancel them. The weird thing is that if I try to run the last model that was attempted before the hang, it goes through quickly without any issue. And then if I try dbt run again it hangs somewhere else in the sequence. I'm curious if you've encountered this or if there are any changes that could explain why this might be happening.

For example, right now it is hanging here:

40 of 122 OK created sql incremental model oso_playground.int_optimism_traces .. [SCRIPT (552.6 MiB processed) in 342.38s]

If I check the log, it says:

09:16:18.702344 [info ] [Thread-32 ]: 40 of 122 OK created sql incremental model oso_playground.int_optimism_traces .. [SCRIPT (552.6 MiB processed) in 342.38s]
09:16:18.703801 [debug] [Thread-32 ]: Finished running node model.opensource_observer.int_optimism_traces

And if I check the job in the BQ console, I see:

9:16 AM [11:46]
SELECT STRUCT<STRUCT<ARRAY<TIMESTAMP>>>((
          select as struct
              -- IGNORE NULLS: this needs to be aligned to _dbt_max_partition, which ignores null
              array_agg(distinct timestamp_trunc(block_timestamp, day) IGNORE NULLS)
          from `opensource-observer`.`oso_playground`.`int_optimism_traces__dbt_tmp`
      )).*;
3    2.49 MB
9:16 AM [21:5]
merge into `opensource-observer`.`oso_playground`.`int_optimism_traces` as DBT_INTERNAL_DEST
        using (
        select
        * from `opensource-observer`.`oso_playground`.`int_optimism_traces__dbt_tmp`
      ) as DBT_INTERNAL_SOURCE
        on FALSE

    when not matched by source
         and timestamp_trunc(DBT_INTERNAL_DEST.block_timestamp, day) in unnest(dbt_partitions_for_replacement)
        then delete

    when not matched then insert
        (`block_timestamp`, `id`, `block_number`, `block_hash`, `transaction_hash`, `transaction_index`, `from_address`, `to_address`, `value`, `input`, `output`, `trace_type`, `call_type`, `reward_type`, `gas`, `gas_used`, `subtraces`, `trace_address`, `error`, `status`, `trace_id`, `ingestion_time`, `address`)
    values
        (`block_timestamp`, `id`, `block_number`, `block_hash`, `transaction_hash`, `transaction_index`, `from_address`, `to_address`, `value`, `input`, `output`, `trace_type`, `call_type`, `reward_type`, `gas`, `gas_used`, `subtraces`, `trace_address`, `error`, `status`, `trace_id`, `ingestion_time`, `address`)
4    550.1 MB
9:16 AM [40:7]
drop table if exists `opensource-observer`.`oso_playground`.`int_optimism_traces__dbt_tmp`

(and all three queries succeeding)

Also need to resolve this first: https://github.com/opensource-observer/oso/issues/1442


backport: bitcoin#15202, #15768, #16432, #17597 (Qt dash core wallet improvements)

What was done?
qt-related backports from bitcoin with new features:

Close all wallets
Indiscreet (privacy) Overview page
Send QR code improvements
Close Window by hotkey (Ctrl + W)

Backports:

bitcoin/bitcoin#17597
bitcoin/bitcoin#15768
bitcoin/bitcoin#16432
bitcoin/bitcoin#15202

How Has This Been Tested?
Run unit/functional tests
To test these functionality just open qt-dash and check it out!

enable/disable privacy mode
click "receive coins" and test functionality of dialog
click Close-All to be sure that wallets are indeed close.
open "console window" and press Ctrl + W (linux) - console would be closed

Breaking Changes
N/A
Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation
[x] I have assigned this pull request to a milestone

Trezor and Ledger both call it "discreet mode" in their wallets


addPolygon3 fails in webmercator projection

Hi,
in webmercator projection config as reference frame, proj becomes undefined and causes exception here:
https://github.com/melowntech/vts-browser-js/blob/9749b5d58da63bdedc77a0784ef82514bbbde833/src/core/map/geodata-builder.js#L1124

Hi, thanks for contributing. Fix will be merged to the master branch.


Clarify ELEN >= 8

ELEN < 8 implies a trivial VPU that cannot execute any instructions.

This was motivated by the conversation over at #464 .

The vtype.vsew specification has 8 as minimum SEW value.
The commentary says that platforms can put different constraints on supported ELEN.
The base application processor spec for "V" requires ELEN>=max(XLEN,FLEN), but other profiles will have different constraints on ELEN, and someone could build restricted subset for a profile with only ELEN=8 (e.g., "Zvbytesonly").


[Create news] User can't publish the news after drag & drop inappropriate file in 'Image' field and filling in all mandatory field

Environment: OS: Windows 11 Pro; Browser: Google Chrome 113.0.5672.127.
Reproducible: always
Build found: 12.06.2023
Preconditions

The user must be authorized on the Green City (https://www.greencity.social/#/greenCity);
The 'Eco news' page is opened.

Steps to reproduce

Click on 'Create news' button;
Drag & drop any inappropriate file in 'Image' field (e.g. PPT);
Fill in all mandatory fields with valid data and select tags (from 1 to 3);
Press the 'Publish' button.

Actual result
The 'Publish' button is disabled.
Expected result
The 'Publish' button is enable and news is published with default image on 'Eco news' page.
User story and test case links
"User story #537
Labels to be added
"Bug", Priority ("Medium"), Severity ("Minor"), Type ("Functional")

After trying to upload picture more than 10MB (32MB) and clicking the button "Опублікувати" The new page with message "Please wait while loading...
Your news is loading to website. Please wait until page refreshes." is openning.  The wait is very long. The page must be reloaded. The news is not published. In devtools response 413.
https://github.com/ita-social-projects/GreenCity/assets/128155213/62c77d32-f37b-41af-944e-133b0e765830

Bug does not reproduce.


Add manpages.

Please describe the problem you're trying to solve
They can only have a link to documentation if proper manpages are too much. It is unpractical to open a web wiki for all the stuff we use. And the scope of this tool is too small to have a dedicated web wiki.
Would you be willing to contribute this feature?

[X] Yes, I'll give it a shot

Describe the solution you'd like
Proper manpages or just a link to wiki so that new users won't get lost.
Additional context
No response

I don't have enough time to maintain another manpage besides the current web document. I've tried using pandoc to convert the web document into a manpage, but the result was not satisfactory because they are not specifically formatted for a manpage and a lot of information (anchors, images, videos) would be lost.
However, I don't mind accepting a PR that simply adds a link as a manpage, so that at least users can more easily find the documentation URL for Yazi.
Closing as not in the plan.


Delete Routes

The delete user route seems to work but throws a 500 status. Looks like Ln 46 of the userController.

Issue fixed with compliments to TA Nathan.


Create class methods to use flip, rotate, scale and change_hue in place

As title. Since we got the Image class ready it is as simple as adding wrapper class methods pointing to the functions.
Also, need to add tests for the Image class.

For the record, this addresses feedback from Charles.


use ArrayHelper::remove() for the html helper methods

@SilverFire I noticed that checkBoxList() has an special option named 'separator' to be used on the implode() at the end but radioList() doesn't have the same feature. Should I add it?

@Faryshta sure

I'd measure performance after applying the change.

I think its ready. And I don't see how this should impact too much in performance.
Plus the advantage of this PR is that the code looks much cleaner now.

Thank you!


Umbrella issue: replace deprecated fullversion shortcode for all localized documents

Problem:
We've deprecated the fullversion param ({{< param "fullversion" >}}) and now English documents are using {{< skew currentPatchVersion >}} instead. (by #40692)
All the other documents need to change {{< param "fullversion" >}} into {{< skew currentPatchVersion >}}.
Since several languages are involved, I'd like to share this issue to check all localizations complete the task.
Proposed Solution:
For each localization team, search fullversion and change appropriately. (See the reference, https://github.com/kubernetes/website/pull/40692/files)
Please check the following task box if the localization task is complete.
Page to Update:

[ ] es

[ ] fr

[ ] hi

[ ] id

[ ] ja

[ ] ko

[ ] pt-br

[ ] ru

[ ] vi

[ ] zh-ch

Once all localizations have switched over, we can remove the fullversion parameter from the site.

/assign @seokho-son
for the Korean contents.

PR: [ko] Replace deprecated fullversion shortcode for Korean #41008 :)
The task for Korean can be completed after dev-1.26-ko.1 is merged into the main branch.

/triage accepted

/assign
For Hindi changes

The Brazilian Portuguese localization has replaced all occurrences via #41027/#41028.

/assign
for french content

/remove-help

Really done!
Thanks folks.
/close


Files changed by tasks stared by watch with nospawn on do not trigger new events

If we take this example from the docs, which runs fine:
grunt.initConfig({
  sass: {
    dev: {
      src: ['src/sass/*.sass'],
      dest: 'dest/css/index.css',
    },
  },
  watch: {
    sass: {
      // We watch and compile sass files as normal but don't live reload here
      files: ['src/sass/*.sass'],
      tasks: ['sass'],
    },
    livereload: {
      // Here we watch the files the sass task will compile to
      // These files are sent to the live reload server after sass compiles to them
      options: { livereload: true },
      files: ['dest/**/*'],
    },
  },
});

and add the nospawn: true option, the livereload target will never be called even though sass changes files.
Any thoughts on this?

@princed :+1: for your solution. But this does not work when there are multiple watch tasks to be run in parallel along with some other blocking tasks like compass:watch using grunt-concurrent. After trying for a while, I could figure out a way, that might come helpful to others, who are trying to achieve the same I wanted. Below is a sample working configuration:
var compassConfig = {
    options: {
        config: 'config.rb',
        bundleExec: true
    },
    compile: {
        options: {
            force: true
        }
    },
    watch: {
        options: {
            watch: true,
            force: true
        }
    }
};

var copyConfig = {
    src: {
        cwd: './',
        src: ['src/**/*', '!src/sass/**/*'],
        dest: 'dist/',
        expand: true
    }
}

var watchConfig = {
    options: {
        livereload: false,
        spawn: false
    },
    livereload: {
        files: ['dist/**/*'],
        options: {
            livereload: true,
            spawn: false
        }
    },
    src: {
        files: ['src/**/*', '!src/sass/**/*'],
        tasks: ['copy:src'],
    }
};

var connectConfig = {
    options: {
        base: 'dist/',
        middleware: function(connect, options, middlewares) {
            options.base = String(options.base);
            var express = require('express');
            var app = express();
            var directory = require('serve-index');
            app.use(express.static(options.base));
            app.get('/', function(req, res) {
                return res.render("" + options.base + "/index.html");
            });
            app.use(directory(options.base));
            middlewares.unshift(app);
            return middlewares;
        },
        port: 3333
      },
      dev: {
          options: {
              open: true,
              livereload: true,
          }
      }
    }
};

var concurrentConfig = {
    watch: {
        tasks: ['compass:watch', 'connect_watch', 'watch:src'],
        options: {
            logConcurrentOutput: true
        }
    }
};

grunt.initConfig({
    compass: compassConfig,
    concurrent: concurrentConfig,
    connect: connectConfig,
    copy: copyConfig,
    watch: watchConfig
});

grunt.registerTask('connect_watch', ['connect:dev', 'watch:livereload']);

grunt.registerTask('default', ['compass:compile', 'concurrent:watch']);

Note: There may be typo and the above code might not be directly copy-pasted as I've extracted the configuration from a much complex & large grunt configuration and simplified for brevity. Still, it should cover the usage pattern to solve this particular use case.


When selecting terminal tab, set focus to the terminal input

When I select a terminal tab to switch between terminals, I start typing immediately expecting the focus to already be in the terminal. However, it is not and I have to click into the terminal to get focus into it.
When a terminal tab is clicked, change the focus to the terminal so I can immediately begin typing my command.

Nevermind. This is a setting. 😊


[CPU] Improve getMaxTileSizes

WIP

I didn't quite understand the logic completely. It seems you are introducing two strategies for tiling for vectorization alone (not for distribution): (a) divisor of number of iterations, and (b) nearest (ceiling) power of two. Why can't the same strategy be used for distribution and vectorization? And the strategy seems to vary based on the workgroup one is operating in - why?

Sorry for the lack of context. I'm trying a few things and wanted to make sure you are aware of it but note it's still a Draft. I'm trying to address the problem with VF=7 in tosa.resize while also trying to pave the way to simplify and decouple tile size computation for vectorization from distribution. Let me answer your questions once I finish the experiments.

Closing stale PR.


Wrong RTL alignment and click actions switch

When using right-to-left lenguages (e.g. Hebrew), the widget won't align to the right as in the preview. Also, clicking the weather opens calendar and vice versa.

Fixed in version 2.0.2.


Don't remove power operations in consoles

Depends on rancher/os#1409
These commands will be removed by ros entrypoint before power commands are symlinked to ros. It doesn't hurt to be removing these ahead of time, but it's no longer necessary.

LGTM


Allow loading of cache file without vasprun.xml file

sometimes it is very convenient to delete the vasprun.xml, but allow using of the cache file
The cache file might be in a structured format so it works with python version changes

We already have a way to read cache data:
https://gemdat.readthedocs.io/en/latest/api/gemdat_trajectory/#gemdat.trajectory.Trajectory.from_cache
The cache is stored in pickle format, so not guaranteed to be readable on different systems/python versions.

Seems like the main issue is that the xml is too large, and it would be nice to extract the useful bits and save those in a more efficient file format.
Options:

Go through Trajectory.to_json() / Trajectory.from_dict(). This is pretty slow for a cache as text are serialized to ascii text, but is it supported by pymatgen and requires no effort on  our side. Might be worth to implement for archiving and space saving.
Write a custom data format, probably using np.save in combination with a json/yaml file to store metadata.
Don't do anything and close this issue. A cache is not an archiving format.

to_json() needs a custom as_dict() function to make sure we save gemdat specific attributes.

I'm going to close this issue (option 3.), because it's not clear to me which problem we are solving. Pickle is the best way to go for caches, and I want to avoid building a custom data format for archiving. Trajectory.to_json() is the pymatgen supported function for that.


Split actinia-gdi

Into

this actinia-metadata-plugin
actinia-module-plugin (see mundialis/actinia-module-plugin#1)
actinia-gdi (see https://github.com/mundialis/actinia-gdi/pull/45)

Nice work!
Would you mind to fix some PEP8 errors with autopep8 or mega-linter?

As this PR is already super large, I would prefer to do this in a separate PR.

Thx for review, I will merge now.


FR: panic button to disconnect all audio (and midi?)

in case things go wild

you can clear the set


Setup ecosystem CI

This PR sets up an "ecosystem" check as an optional part of the CI step for pull requests. The primary piece of this is a new script in scripts/check_ecosystem.py which takes two ruff binaries as input and compares their outputs against a corpus of open-source code in parallel. I used ruff's text reporting format and stdlib's difflib (rather than JSON output and jsondiffs) to avoid adding another dependency. There is a new ecosystem-comment workflow to add a comment to the PR (see this link which explains why it needs to be done as a new workflow for security reasons).
Here's what the comment looks like when there are changes:

And here's what the comment looks like with no changes:

I'm open to improvements to make this report more useful; linking to the actual versions of the respective repos might be helpful, for example.
A few points:

This runs on every PR, but not on main and not as a nightly task as suggested in the linked issue. I think running on every PR is correct because it gives direct feedback on any potential problems before merging. However, a possible later improvement would be to also run on main and compare against the latest released version. (This is what black diff-shades does).
The "ecosystem" right now consists of zulip and bokeh (latest version of each), and uses their ruff configs. However, the most valuable way of setting this up is actually to test messy codebases that fail many checks, not ones that already use ruff, because that would be the only way to catch PRs introducing false negatives. @charliermarsh any suggestions on what to use for this purpose? Unlike other tools, ruff is fast enough that adding a few large codebases here won't make much of a difference in testing time.
The base version of ruff used as a comparison is pulled from the latest artifact on the PR merge base ref (i.e. PRs to main will compare the latest version on main to the PR head after the merge commit). For PRs that don't merge cleanly, the results might be inconsistent (I haven't tested this).

Closes charliermarsh/ruff#2677.

Dang, this is so cool, thank you! I'll review tomorrow and respond to the questions in the PR summary.

If I open a PR, and ecosystem job completes, then I update the PR, and the ecosystem job runs again, does it appear as two separate comments? Or does it "update" the comment?

The workflow will update an existing comment if it finds one.

How much more difficult would it to be have this run on explicit PR comment (e.g., reviewer adds +ecosystem, and the job kicks off)? I'm mostly thinking here about the noise involved in having the bot comment on every PR. I'm not fully decided on what's "better" here, but I thought I'd ask.

I think this would be fairly easy, although I haven't looked into what would be needed to do it. If this is merged and it feels like the comment is too noisy on every PR, I could look at doing a followup to make it run only when pinged. It could also be changed to not post a comment at all if there are no changes, although then it might be harder to know if that workflow has broken.

I assume it'd be possible for me to run this locally prior to cutting a release, by comparing against the binary from the previous release. Any reason that wouldn't be possible with the current configuration?

Yes, definitely. The script requires Python 3.11 (for asyncio.TaskGroup) but otherwise has no dependencies, and clones repos to temporary directories that are cleaned up automatically so it's fairly self-contained.
On a separate note, I'm not sure why the ecosystem check is failing on this PR with the message API rate limit exceeded for installation ID 22967278, but likely it's because the base branch for this PR doesn't have a built artifact that it can use for the test.

Out of curiosity I ran check_ecosystem.py with the latest main vs the latest PyPI version (0.0.254). Ignoring the new rule PLC1901 and the changes to RET504 and the inclusion of .pyi files, here are the changes detected:
zulip

+ zerver/lib/ccache.py:81:14: PLR2004 Magic value used in comparison, consider replacing -2147483648 with a constant variable

bokeh

+ tests/unit/bokeh/models/test_ranges.py:160:37: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/models/test_ranges.py:71:33: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/integration/tools/test_range_tool.py:272:36: PLR2004 Magic value used in comparison, consider replacing -0.1 with a constant variable
+ tests/unit/bokeh/test_events.py:286:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:533:26: PLR2004 Magic value used in comparison, consider replacing -0.5 with a constant variable
+ tests/unit/bokeh/test_events.py:304:28: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/core/test_serialization.py:795:23: PLR2004 Magic value used in comparison, consider replacing -684115200000 with a constant variable
+ tests/unit/bokeh/test_events.py:139:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/integration/models/test_plot.py:161:31: PLR2004 Magic value used in comparison, consider replacing -2.3 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:532:26: PLR2004 Magic value used in comparison, consider replacing -1.5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:531:25: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/test_events.py:180:27: PLR2004 Magic value used in comparison, consider replacing -0.1 with a constant variable
+ tests/unit/bokeh/test_events.py:182:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:527:28: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/core/test_validation.py:100:23: PLR2004 Magic value used in comparison, consider replacing -5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:529:29: PLR2004 Magic value used in comparison, consider replacing -0.5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:528:29: PLR2004 Magic value used in comparison, consider replacing -1.5 with a constant variable
+ tests/unit/bokeh/test_events.py:209:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/integration/tools/test_range_tool.py:166:36: PLR2004 Magic value used in comparison, consider replacing -0.2 with a constant variable
+ tests/unit/bokeh/util/test_util__serialization.py:125:69: PLR2004 Magic value used in comparison, consider replacing -2208988800000.0 with a constant variable
+ tests/unit/bokeh/test_events.py:110:28: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable

scikit-build

airflow

- tests/system/providers/amazon/aws/utils/__init__.py:256:12: PIE802 [*] Unnecessary list comprehension.
- dev/breeze/src/airflow_breeze/utils/selective_checks.py:270:55: PIE802 [*] Unnecessary list comprehension.
- tests/models/test_taskinstance.py:1859:16: PIE802 [*] Unnecessary list comprehension.
+ airflow/task/task_runner/standard_task_runner.py:168:24: PLR2004 Magic value used in comparison, consider replacing -9 with a constant variable
+ tests/providers/google/cloud/hooks/test_bigquery.py:1296:16: SIM300 [*] Yoda conditions are discouraged, use `result == -1` instead
+ tests/system/providers/amazon/aws/utils/__init__.py:256:16: PIE802 [*] Unnecessary list comprehension.
+ dev/breeze/src/airflow_breeze/utils/selective_checks.py:271:13: PIE802 [*] Unnecessary list comprehension.
+ tests/task/task_runner/test_standard_task_runner.py:287:40: PLR2004 Magic value used in comparison, consider replacing -9 with a constant variable
+ tests/triggers/test_temporal.py:61:12: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/models/test_taskinstance.py:1859:20: PIE802 [*] Unnecessary list comprehension.

It seems like PLR2004 is now catching more cases than before (maybe when there's more than one case on a line?)

It also seems like some of the position reporting might have changed. I think the diff printing is a bit broken however, I'll look into that.

Here's the fixed summary of the current diff:
zulip

+ zerver/lib/ccache.py:81:14: PLR2004 Magic value used in comparison, consider replacing -2147483648 with a constant variable

bokeh

+ tests/integration/models/test_plot.py:161:31: PLR2004 Magic value used in comparison, consider replacing -2.3 with a constant variable
+ tests/integration/tools/test_range_tool.py:166:36: PLR2004 Magic value used in comparison, consider replacing -0.2 with a constant variable
+ tests/integration/tools/test_range_tool.py:272:36: PLR2004 Magic value used in comparison, consider replacing -0.1 with a constant variable
+ tests/unit/bokeh/core/test_serialization.py:795:23: PLR2004 Magic value used in comparison, consider replacing -684115200000 with a constant variable
+ tests/unit/bokeh/core/test_validation.py:100:23: PLR2004 Magic value used in comparison, consider replacing -5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:527:28: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:528:29: PLR2004 Magic value used in comparison, consider replacing -1.5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:529:29: PLR2004 Magic value used in comparison, consider replacing -0.5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:531:25: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:532:26: PLR2004 Magic value used in comparison, consider replacing -1.5 with a constant variable
+ tests/unit/bokeh/models/test_annotations.py:533:26: PLR2004 Magic value used in comparison, consider replacing -0.5 with a constant variable
+ tests/unit/bokeh/models/test_ranges.py:160:37: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/models/test_ranges.py:71:33: PLR2004 Magic value used in comparison, consider replacing -1.0 with a constant variable
+ tests/unit/bokeh/test_events.py:110:28: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/test_events.py:139:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/test_events.py:180:27: PLR2004 Magic value used in comparison, consider replacing -0.1 with a constant variable
+ tests/unit/bokeh/test_events.py:182:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/test_events.py:209:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/test_events.py:286:24: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/test_events.py:304:28: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable
+ tests/unit/bokeh/util/test_util__serialization.py:125:69: PLR2004 Magic value used in comparison, consider replacing -2208988800000.0 with a constant variable

scikit-build

airflow

+ airflow/task/task_runner/standard_task_runner.py:168:24: PLR2004 Magic value used in comparison, consider replacing -9 with a constant variable
- dev/breeze/src/airflow_breeze/utils/selective_checks.py:270:55: PIE802 [*] Unnecessary list comprehension.
+ dev/breeze/src/airflow_breeze/utils/selective_checks.py:271:13: PIE802 [*] Unnecessary list comprehension.
- tests/models/test_taskinstance.py:1859:16: PIE802 [*] Unnecessary list comprehension.
+ tests/models/test_taskinstance.py:1859:20: PIE802 [*] Unnecessary list comprehension.
+ tests/providers/google/cloud/hooks/test_bigquery.py:1296:16: SIM300 [*] Yoda conditions are discouraged, use `result == -1` instead
- tests/system/providers/amazon/aws/utils/__init__.py:256:12: PIE802 [*] Unnecessary list comprehension.
+ tests/system/providers/amazon/aws/utils/__init__.py:256:16: PIE802 [*] Unnecessary list comprehension.
+ tests/task/task_runner/test_standard_task_runner.py:287:40: PLR2004 Magic value used in comparison, consider replacing -9 with a constant variable
+ tests/triggers/test_temporal.py:61:12: PLR2004 Magic value used in comparison, consider replacing -2 with a constant variable

These diffs are insanely useful.

It seems like PLR2004 is now catching more cases than before (maybe when there's more than one case on a line?)

I fixed a bug that was ignoring negated constants (like -1, which is a UnaryOp, not a Constant).

Ha, wow, I was just thinking this would be a good idea (working in typeshed and enjoying mypy_primer), and thought I'd suggest it, and here it is, already in!

Let us know if there are projects that you think could be good candidate to include here :)
(We added typeshed recently :))

Not sure if DisnakeDev/disnake is a good candidate but given we've found 3-4 bugs now it might be worth it (but I'll leave that up to you).
We're still in the process of adding more ruff rules, if that makes a difference.

I'm guessing most of the cost will be in cloning... But I could be wrong purely a guess. I think we should add more repos, but run them without --select ALL IMO. E.g., run a subset with --select ALL so that we can see the "impact" of a new rule, but run a wider range with their own Ruff settings.

I'm guessing most of the cost will be in cloning... But I could be wrong purely a guess.

I'm pretty sure a shallow clone would make it checkout quite fast. I think that what diff shades (for black) does but I don't remember.

This is a shallow clone. My guess is most of the total time is compiling Ruff, and the per-repo part is quick.


[Serialization] Add some asserts to catch giant method lists.

This would have allowed us to triage rdar://problem/28305755 much sooner. The actual problem is pretty bad: if you have too many methods with the same selector, serialization just falls over.  "Too many" is in the thousands, which seems unlikely, but 'dealloc' can actually get there if there are a lot of little classes, and 'init' might as well, so we really should do better here.

@swift-ci Please test and merge


Set up master/slave database structure on AWS and in Django

I'd love to set up a master/slave database setup, and get your help specifying within Django/WeVoteServer whether to hit a read/write or read-only database instance with each query. Once I have an example pattern, I can start migrating read-only API calls to use a slave db.
https://docs.djangoproject.com/en/1.11/topics/db/multi-db/
We might want to think about migrating our master read/write WeVoteServer database to the middle of the US, and then have read instances in the middle of the country and on both coasts.

Setting up the read-only replicant in RDS is generally a one-click affair, so we could go ahead and do that if you want to get into the DB routing in Django.

@josephevans set up a read replica already.

@DaleMcGrew I've added the read-only info to the Google Doc and mentioned you there.

Thank you Matt! I will open another issue to get help setting up a read only database connection in Django.


Path enrichment in gadgets

Current situation
The current situation is that in some gadgets (e.g exec) we get the path to the file of the process but in most gadgets we don't.
Impact
We need the path for many use cases in our system and in general I think it's a nice enrichment to show/have.
Ideal future situation
Adding this code in the gadget will give the path to the file.
struct file *exe_file = BPF_CORE_READ(current_task, mm, exe_file);
char *exepath;
exepath = get_path_str(&exe_file->f_path);
bpf_probe_read_kernel_str(event->exepath, MAX_STRING_SIZE, exepath);

An example can be taken from here
Something to note is that it can have performance impact so we might want to add a flag in the config before enabling it by default, the same way it exists today in the exec gadget.
Additional information
Slack discussion
CC: @alban

For me I would love to have it in the following gadgets:
dns,network,open,seccomp

Thanks for filing this issue. For me, I'd like to have it in the following gadgets: trace-exec (already there) and dns (#2684).
For the networking gadgets (dns, sni, network), it's going to be implemented in the socket enricher because we don't have current_task in that context.

struct file *exe_file = BPF_CORE_READ(current_task, mm, exe_file);
char *exepath;
exepath = get_path_str(&exe_file->f_path);
bpf_probe_read_kernel_str(event->exepath, MAX_STRING_SIZE, exepath);

It is not always safe to pick up current->mm->exe_file. Consider a multi-threaded process where one thread is calling
prctl(PR_SET_MM, PR_SET_MM_EXE_FILE, ...) to replace exe_file. This could have two problems:

If security policies depends on exe_file, this could be problematic since unprivileged processes can change their exe_file. (it might not matter if the gadget is not used with this goal)
If a multi-threaded process changes exe_file in one thread while it is being read in the ebpf program by another thread, this could lead to reading a bad memory address and undefined behaviour.

Reading exe_file in the context of execve does not have this problem because it is locked. But extending exepath to other gadgets than trace-exec needs careful consideration.
One way to solve this would be to cache the exepath at execve-time in a hash map, so it could be read later outside of the context of execve.
Related discussions<EMAIL_ADDRESS>

struct file *exe_file = BPF_CORE_READ(current_task, mm, exe_file);
char *exepath;
exepath = get_path_str(&exe_file->f_path);
bpf_probe_read_kernel_str(event->exepath, MAX_STRING_SIZE, exepath);

It is not always safe to pick up current->mm->exe_file. Consider a multi-threaded process where one thread is calling prctl(PR_SET_MM, PR_SET_MM_EXE_FILE, ...) to replace exe_file. This could have two problems:

If security policies depends on exe_file, this could be problematic since unprivileged processes can change their exe_file. (it might not matter if the gadget is not used with this goal)
If a multi-threaded process changes exe_file in one thread while it is being read in the ebpf program by another thread, this could lead to reading a bad memory address and undefined behaviour.

Reading exe_file in the context of execve does not have this problem because it is locked. But extending exepath to other gadgets than trace-exec needs careful consideration.
One way to solve this would be to cache the exepath at execve-time in a hash map, so it could be read later outside of the context of execve.
Related discussions<EMAIL_ADDRESS>
That's a good point! Thanks for pointing this out.
Maybe we can resolve that hard link in some way as an alternative to holding a cache? because we would need to implement a way to track when processes dies and remove them from the cache as well.
@alban


ilm:1.2.0

I am submitting

[ ] a new package
[x] an update for a package

Changelog

Added  external-link-circle option for disabling circle next to external links (https://github.com/talal/ilm/commit/3687f6bf0a84c63d104f3e80bba2cc9615d7779d).

[x] ensured that my package is licensed such that users can use and distribute the contents of its template directory without restriction, after modifying them through normal use.

Thank you!


throw error on json shcema anyOf

{"description": "Microsoft OneDrive reader.\n\nInitializes a new instance of the OneDriveReader.\n\n:param client_id: The Application (client) ID for the app registered in the Azure Entra (formerly Azure Active directory) portal with MS Graph permission \"Files.Read.All\".\n:param tenant_id: The Directory (tenant) ID of the Azure Active Directory (AAD) tenant the app is registered with.\n                  Defaults to \"consumers\" for multi-tenant applications and OneDrive personal.\n:param client_secret: The Application Secret for the app registered in the Azure portal.\n                      If provided, the MSAL client credential flow will be used for authentication (ConfidentialClientApplication).\n                      If not provided, interactive authentication will be used (Not recommended for CI/CD or scenarios where manual interaction for authentication is not feasible).\n                      Required for App authentication.\n:param userprinciplename: The user principal name (normally organization provided email) whose OneDrive will be accessed. Required for App authentication. Will be used if the\n                          parameter is not provided when calling load_data().\n:param folder_id: The folder ID of the folder to fetch from OneDrive. Will be used if the parameter is not provided when calling load_data().\n:param file_ids: A list of file IDs of files to fetch from OneDrive. Will be used if the parameter is not provided when calling load_data().\n:param folder_path (str, optional): The relative path of the OneDrive folder to download. If provided, files within the folder are downloaded.  Will be used if the parameter is\n                                    not provided when calling load_data().\n:param file_paths (List[str], optional): List of specific file paths to download. Will be used if the parameter is not provided when calling load_data().\n:param file_extractor (Optional[Dict[str, BaseReader]]): A mapping of file extension to a BaseReader class that specifies how to convert that file to text.\n                                                         See `SimpleDirectoryReader` for more details.\n\n\nFor interactive authentication to work, a browser is used to authenticate, hence the registered application should have a redirect URI set to 'https://localhost'\nfor mobile and native applications.", "properties": {"is_remote": {"default": false, "description": "Whether the data is loaded from a remote API or a local file.", "title": "Is Remote", "type": "boolean"}, "client_id": {"title": "Client Id", "type": "string"}, "client_secret": {"anyOf": [{"type": "string"}, {"type": "null"}], "default": null, "title": "Client Secret"}, "tenant_id": {"anyOf": [{"type": "string"}, {"type": "null"}], "default": null, "title": "Tenant Id"}, "userprincipalname": {"anyOf": [{"type": "string"}, {"type": "null"}], "default": null, "title": "Userprincipalname"}, "folder_id": {"anyOf": [{"type": "string"}, {"type": "null"}], "default": null, "title": "Folder Id"}, "file_ids": {"anyOf": [{"items": {"type": "string"}, "type": "array"}, {"type": "null"}], "default": null, "title": "File Ids"}, "folder_path": {"anyOf": [{"type": "string"}, {"type": "null"}], "default": null, "title": "Folder Path"}, "file_paths": {"anyOf": [{"items": {"type": "string"}, "type": "array"}, {"type": "null"}], "default": null, "title": "File Paths"}, "file_extractor": {"anyOf": [{"additionalProperties": {"type": "string"}, "type": "object"}, {"type": "null"}], "default": null, "title": "File Extractor"}, "class_name": {"default": "base_component", "title": "Class Name", "type": "string"}}, "required": ["client_id"], "title": "OneDriveReader", "type": "object"}

Can you provide more information?

Yeah, I coy the schema to playground and most of inputs get error

Can you share the schema?

It's already in the description!

Okay so regarding the anyOf issue: since my focus with this package is to make an extensible and un-opinionated form generator, the built-in template renderer really only looks at types and let's the type-specific template components handle all additional schema metatada.
Since JSON Schema is pretty open-ended, I decided against having the built-in renderer do any type inferences, so every level of your schema will need to be typed appropriately, which from what I can see is not the case.
Regarding anyOf: schema composition in general has way too many potential use cases, so to keep in line with the un-opinionated philosophy, I decided against implementing any specific approach within the package itself, so you're free to implement them how you see fit.
You can provide the <Form> with your own RenderTemplate if you have your own ideas of how you'd like to handle schemas in general (meaning, if you don't want to use my "type"-based approach and have your own implementation in mind) or you can add the types to your schema and handle the anyOfs how you see fit in the type-based templates.
Take a look at the example: https://github.com/m6io/react-formgen/blob/main/website/src/examples/JsonSchema.tsx#L119. It's not comprehensive, but it should give you an idea.
Alternatively, you can tyr this modified version of your schema
{
  "description": "Microsoft OneDrive reader.\n\nInitializes a new instance of the OneDriveReader.\n\n:param client_id: The Application (client) ID for the app registered in the Azure Entra (formerly Azure Active directory) portal with MS Graph permission \"Files.Read.All\".\n:param tenant_id: The Directory (tenant) ID of the Azure Active Directory (AAD) tenant the app is registered with.\n                  Defaults to \"consumers\" for multi-tenant applications and OneDrive personal.\n:param client_secret: The Application Secret for the app registered in the Azure portal.\n                      If provided, the MSAL client credential flow will be used for authentication (ConfidentialClientApplication).\n                      If not provided, interactive authentication will be used (Not recommended for CI/CD or scenarios where manual interaction for authentication is not feasible).\n                      Required for App authentication.\n:param userprinciplename: The user principal name (normally organization provided email) whose OneDrive will be accessed. Required for App authentication. Will be used if the\n                          parameter is not provided when calling load_data().\n:param folder_id: The folder ID of the folder to fetch from OneDrive. Will be used if the parameter is not provided when calling load_data().\n:param file_ids: A list of file IDs of files to fetch from OneDrive. Will be used if the parameter is not provided when calling load_data().\n:param folder_path (str, optional): The relative path of the OneDrive folder to download. If provided, files within the folder are downloaded.  Will be used if the parameter is\n                                    not provided when calling load_data().\n:param file_paths (List[str], optional): List of specific file paths to download. Will be used if the parameter is not provided when calling load_data().\n:param file_extractor (Optional[Dict[str, BaseReader]]): A mapping of file extension to a BaseReader class that specifies how to convert that file to text.\n                                                         See `SimpleDirectoryReader` for more details.\n\n\nFor interactive authentication to work, a browser is used to authenticate, hence the registered application should have a redirect URI set to 'https://localhost'\nfor mobile and native applications.",
  "properties": {
    "is_remote": {
      "default": false,
      "description": "Whether the data is loaded from a remote API or a local file.",
      "title": "Is Remote",
      "type": "boolean"
    },
    "client_id": {"title": "Client Id", "type": "string"},
    "client_secret": {
      "type": "string",
      "default": "",
      "description": "The Application Secret for the app. Empty string if not provided."
    },
    "tenant_id": {
      "type": "string",
      "default": "",
      "description": "The Directory (tenant) ID. Defaults to empty string if not provided."
    },
    "userprincipalname": {
      "type": "string",
      "default": "",
      "description": "The user principal name whose OneDrive will be accessed. Defaults to empty string if not provided."
    },
    "folder_id": {
      "type": "string",
      "default": "",
      "description": "The folder ID of the folder to fetch from OneDrive. Defaults to empty string if not provided."
    },
    "file_ids": {
      "type": "array",
      "items": {"type": "string"},
      "default": [],
      "description": "A list of file IDs to fetch from OneDrive. Defaults to an empty list if not provided."
    },
    "folder_path": {
      "type": "string",
      "default": "",
      "description": "The relative path of the OneDrive folder to download. Defaults to empty string if not provided."
    },
    "file_paths": {
      "type": "array",
      "items": {"type": "string"},
      "default": [],
      "description": "List of specific file paths to download. Defaults to an empty list if not provided."
    },
    "file_extractor": {
      "type": "object",
      "additionalProperties": {"type": "string"},
      "default": {},
      "description": "A mapping of file extension to a BaseReader class. Defaults to an empty object if not provided."
    },
    "class_name": {
      "default": "base_component",
      "title"  : "Class Name"    ,
      "type"   : "string"
    }
  },
  "required": ["client_id"],
  "title": "OneDriveReader",
  "type": "object"
}

Here's a little playpen if you want to test it out. Just dump the schema in the "JSON Schema" editor and hit the refresh icon to see how it renders https://formgen-testing.vercel.app/


Birdhouse wait time has increased to two hours?

🐛 Bug Report

Started happening around 8pm GMT yesterday (20/09), not sure if its related but it coincidentally coincided with the Bot returning .jpg files after finishing a trip or running a command.

it just shows the wrong ready in X hours. still 50 min as far as the actual time says when it's supposed to be done.