azure.mgmt.web AppServicePlan has useless variables

The variables resource_group and subscription are redundant in this structure, since they are inherently part of the identity of the object which is well-formed and easily parsed.

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

ID: 9fe5c45d-f7fe-2095-876b-14e97203a44f
Version Independent ID: dfc68a8f-7e74-da6a-460c-7b0d1109b9a7
Content: azure.mgmt.web.v2019_08_01.models.AppServicePlan class
Content Source: docs-ref-autogen/azure-mgmt-web/azure.mgmt.web.v2019_08_01.models.AppServicePlan.yml
GitHub Login: @lmazuel
Microsoft Alias: lmazuel

It looks like resource_group is a required parameter... since this is not a terribly important issue I'm going to close it out.

It looks like resource_group is a required parameter... since this is not a terribly important issue I'm going to close it out.

I had thought resource group was required and closed this, but I was looking at the wrong thing, so I reopened it; this issue is still valid but low priority.  Do with it what you feel is appropriate.

I had thought resource group was required and closed this, but I was looking at the wrong thing, so I reopened it; this issue is still valid but low priority.  Do with it what you feel is appropriate.


Windows makefile generator: Don't delete long lists of files in one go

The Windows command line has its limits, and we're hitting it hard.
We therefore generate one 'del' command for each explicit file for the
'clean' target.
Fixes #11163

Currently in WIP because I haven't tested it yet.
Shouldn't we have an Appveyor job trying nmake clean?  (or Travis trying make clean, for that matter?)

Couldn't we try to use wildcard deletes as much as possible? Deleting every single file separately is so painfully slooow on windows...

No.  We do too much of that already.  People who build in the source tree run too much risk of losing their work.  We have already had that issue

I have also tried to solve that long line issue: #10895

This issue is in a state where it requires action by @openssl/committers but the last update was 30 days ago

@iamamoose Hmm, maybe reminding for PRs that still have a [WIP] tag is overzealous...

I wonder why my #10895 is being ignored, that is not WIP,
but I have not been testing that since weeks because I don't like to waste my time.

@iamamoose Hmm, maybe reminding for PRs that still have a [WIP] tag is overzealous...

It could certainly ignore things with WIP in the title, but would be better if the labels held the state, perhaps a WIP label?

The labels are not visible in the notification area, but the WIP prefix is.

And non-members can set the title, but they cannot set labels.

There's no reason for it to be WIP any more

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

Have you also fixed the nmake distclean ?

And, why is everyone force-pushing after the approval ?
That means nobody can ever do
git fetch git://github.com/openssl/openssl.git refs/pull/11171/head:pr-11171-as-approved
to get the version as it was approved.
I know I can trust you, but you know it quite well, "Vertrauen ist gut, Kontrolle ist besser."

Its normally because a rebase is needed.

Yes, but then the rebase should be done, and a new approval requested.
But recently everybody started to rebase without any need, just to get the
gitbub icon that shows a merge. Everytime I merge one of my commits,
github says "unmerged commits" but I comment, that I merged the code
and close the PR.  Even if my branch is deleted later what I dont do,
the pull request stays to be retrievable with above work flow.

And, why is everyone force-pushing after the approval ?

Everyone?  I think that I've only seen me and @DDvO do this so far.  Basically, it allows github to notice and to make that "Merged" status and notification for us.

I already asked @DDvO to stop doing that.  Now I ask you.
We do not need to make github happy, github is optional.

It made me happy too, FYI.  Also, it does make it clearer what PRs are closed because they were abandoned, which does happen for various reasons.

Okay, I made my point, just do what you want then.

When I merge a PR I always close with a comment that I merged it.
And due to the (Merged from https://github.com/openssl/openssl/pull/11425)
The merge commit appears in the history of the PR
(I only broke it once, when I had a typo in the addrev command,
and did not notice before pushing).  I took precautions in my workflow
to make sure that cannot happen again.

When I merge a PR I always close with a comment that I merged it.

I also do this to make clear that I did not close the PR for other reasons.

And due to the (Merged from https://github.com/openssl/openssl/pull/11425)
The merge commit appears in the history of the PR

Well, the PR appears in the history of the master branch due to the Merged from ... line,
but the approved commits of the PR do not show show identically in the master
because the commit messages have been amended by reviewer and PR number info
and typically the commits have been rebased immediately before merging.


updated requirements.txt to work with Python 3.12

App will not be runnable on Python 3.12 and above. Made changes so that it will be runnable.
From Python 3.12 disutils was removed (here) disutils was used for install requirements. From python 3.12 they started using setuptools.
All I did was replace the requirements.txt and bumped up the versions.

Thank you!


[release-1.13] Create SinkBindings token-secret only if sink has an audience set

Cherry-pick of https://github.com/knative/eventing/commit/c818a3aa817aa0a9b2dd17563ff0eda938a96c6d

/test 414-test-conformance-aws-414

FAIL: TestApiServerSourceDataPlaneTLS/Send_events_to_TLS_sink_-_trust_bundle/Assert/ApiServerSource_as_event_source_delivers_events_on_sink_with_ref

need #538 first


Importer user extension

Some POC about importer user extension.
Still need some work:

probably need some polish / fixes
all hook calls need to be implemented

Hi @julienduroure. Would it be possible to add a hook to add an extension to extensions_managed in addons/io_scene_gltf2/io/imp/gltf2_io_gltf.py, as well as other hooks relating to custom extensions in the imported file?

@pepperoni505 Sure, this is currently only some POC/Draft code.
All hooks still need to be added

Hey @julienduroure do you have any updates on the status of this PR?

No update on it for now, I didn't work more than you can see in this branch.
Still WIP

If you want, I can try finishing this PR

Of course, any help is always welcome :)
Feel free to fix what is already done, enhance it, and to add all required hooks!

By any chance would you have a list of hooks to add?

No, I don't have it. But a good start is to create a hook before and after each create method of each class

Alright. I've created a PR with my current progress: #1523

Deleting this PR, as this PR is the start work of #1523, that is now ready to merge


[ClickAwayListener] Update test case to reflect expected vs. actual

A follow-up on #25903 to adjust what we expect vs. what's we have.
The "why" on the expected behavior is based on a simple UX hypothesis: In the worse case (unexpected behavior), it's better to have users perform two inputs (two clicks) to trigger two actions (open + clickaway) than one input that triggers two actions. In the former case, the interface feels slow, in the latter, the interface feels broken.
As far as I know, no arguments have been made so far to defend that the current behavior is expected. @m4theushw's exploration, feedback from the community, and my exploration seem to support the direction taken in this PR: the current behavior is KO.

Closing since this is expected and intended behavior. The changes should be made at the platform level.


Fix app crash on Properties window closing

Fixes #659, fixes #1076
This PR  fixes the annoying issue of the app closing when a Properties window is closed.
It involves switching from AppWindow to ApplicationView... let me know if this is ok for you :)

from my side, in dark mode it looks like this:

@XPoppyX thanks for the feedback. I'm not experiencing this, I'll see if I can reproduce it.

@gave92

does this happen if you open the Property window with the dark theme already selected?

happens when changing from light to dark and then opening the properties window and having dark mode already selected

Does this happen if you switch theme after the Property window is open?

before

@XPoppyX so if you open the properties window and then switch theme than it works correctly?

@gave92

so if you open the properties window with the light theme selected and then switch to dark mode than it works correct?

no
Test 1:
1 - open properties window in light mode and then close
2 - Switch to dark mode
3 - open properties window, looks incorrectly

Test 2:
1 - open properties window in light mode
2 - switch to dark mode with the properties window open
3 - looks incorrectly

@XPoppyX aah you are using the in-app switch! I was using the system-wide switch in Settings and it was working fine.

@XPoppyX the issue should be fixed in the latest commit 👍

@gave92  Did you change the background color for dark mode? because it is too dark with the acrylic effect
Before:

After:

@XPoppyX thanks that was not intentional, should be fixed now

the previous problem came back I think when switching theme with property window open :/

yes, I was going to tell you about it

@XPoppyX should be fixed with this commit f57a33d

need to mention #973 too


Feature : Single Chart Argument on View Timelines

Closes : https://github.com/macrosynergy/macrosynergy/issues/659

Codecov Report
Base: 58.86% // Head: 61.33% // Increases project coverage by +2.46% :tada:

Coverage data is based on head (110d776) compared to base (dbb1bc5).
Patch coverage: 80.19% of modified lines in pull request are covered.

:exclamation: Current head 110d776 differs from pull request most recent head 4a1c984. Consider uploading reports for the commit 4a1c984 to get more accurate results

: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
Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #671      +/-   ##
===========================================
+ Coverage    58.86%   61.33%   +2.46%
===========================================
  Files           29       29
  Lines         3068     3132      +64
===========================================
+ Hits          1806     1921     +115
+ Misses        1262     1211      -51

Impacted Files
Coverage Δ

macrosynergy/panel/category_relations.py
34.43% <0.00%> (+0.79%)
:arrow_up:

macrosynergy/panel/view_timelines.py
81.31% <65.00%> (+70.35%)
:arrow_up:

macrosynergy/panel/historic_vol.py
95.45% <93.22%> (+0.85%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add missing references for VectorExtensions.cs

Just pulled and was unable to compile because of missing references

Ha I was just submitting this as well! You beat me to it.

We should be pulling these requests first before we merge them.

@HodgsonSDAS Yep, that's my bad.


Homeassistant with python 3.7 not working with wemo (pywemo 0.4.34)

Home Assistant release with the issue: 0.102.3

Last working Home Assistant release (if known): -
Operating environment (Hass.io/Docker/Windows/etc.): ubuntu server

Integration: https://www.home-assistant.io/integrations/wemo/

Description of problem:
Actually still using Python 3.6
Notification tells to update to Python 3.7
So doing a clean new install of homeassistant in venv with Python 3.7.
After install calling /hass --script check_config -c /home/homeassistant/.homeassistant/ exists with the following error
ERROR:homeassistant.util.package:Unable to install package pywemo==0.4.34: Command "/srv/homeassistant_0.102.3_pip3.7/bin/python3.7 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-sgb4n_ro/netifaces/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-t6i_in_8-record/install-record.txt --single-version-externally-managed --compile --install-headers /srv/homeassistant_0.102.3_pip3.7/include/site/python3.7/netifaces" failed with error code 1 in /tmp/pip-build-sgb4n_ro/netifaces/
Failed config
  General Errors:
    - Component error: wemo - Requirements for wemo not found: ['pywemo==0.4.34'].

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
wemo:
  discovery: true
  static:
    - <IP_ADDRESS>:80

Traceback (if applicable):

**Additional information:**Everything is working fine with Python 3.6
Doing a clean new install of homeassistant in venv with Python 3.7 means:
sudo mkdir /srv/homeassistant_0.102.3_pip3.7
sudo chown homeassistant:homeassistant /srv/homeassistant_0.102.3_pip3.7
cd /srv/homeassistant_0.102.3_pip3.7
sudo su homeassistant
python3.7 -m venv ./
source bin/activate
python3.7 -m pip install homeassistant

This is an ubunutu issue, see this community post.
Please close this issue if that solves your problem :)

This is an ubunutu issue, see this community post.
Please close this issue if that solves your problem :)

Don`t think so because I explicitly used python3.7-commands as you can see above. Additionally the installer package for wemo used the python3.7 command as you can see in the logs above.
Any other ideas?

Have you updated pip3 to the newest version?

Have you installed python3-dev? It looks like this is a failure during installing netifaces (a prerequisite package for this version of pywemo), and some googling makes this seem like there are missing headers that would normally come with python3-dev that are causing this error.

Yes, it was up-to-date.
Issue solved. I installed python3.7-dev with apt-get (additional packages installed: libpython3.7 libpython3.7-dev zlib1g-dev). Seems like dependency to python3.7 is not enough and dependency to python3.7-dev is needed in addition.
Thank you though!

Have you installed python3-dev? It looks like this is a failure during installing netifaces (a prerequisite package for this version of pywemo), and some googling makes this seem like there are missing headers that would normally come with python3-dev that are causing this error.

That solved the issue, I was already trying as you asked. Thanks!

Glad to hear that it's fixed. :-)

Solved by installing python3.7-dev not python3-dev. python3-dev was already installed.


Inputs other than the coordinates

In 4.2.1 Types, only the coordinate inputs are mentioned.
However 4.2.7 Input Data Constraints lists an entirely different set of input.
I assume the idea of this software is to take the datasets mentioned in 4.1.3 and use the models listed in 4.2 to build a chloride exposure map over time. Then the user would input coordinate to query the chloride exposure. Am I understanding it correctly?
If so this should be conveyed more clearly: each model uses which value coming from which dataset.
Also, is the dataset part of the software (maintained by the developer) or must be provided by the users before querying the coordinates? I assume it's the first case.

You are right, the dataset input is maintained by the developer. I added the dataset input in the system context and types correspondingly to talk about this in 10a2cf4.


Better logic for determining Beat Saber installation directory

This PR uses the following steps:

Finds out the Steam installation directory from registry (32/64bit)
Goes through all the defined library folders
Finds the library folder containing Beat Saber and uses it

Hey, thank you. I'll try to look into this in a bit

@kinsi55 Thank you :) Haven't done any C# in a long while, so even any nitpicks on the code are appreciated!

Since you asked for it, I nitpicked :P
LGTM tho, I'll include it in the next update whenever that will be!

Np, thanks for the nitpicking too :)
Mostly code style stuff, except for using LINQ - haven't done any C# in looong while, so I totally forgot how to LINQ ;)


Importing Age model kills the running script - Raspberry Pi

Hello everyone, I hope someone can help me with this issue.
I'm currently working with a Raspberry Pi 4 Model B and I want to use DeepFace for a project I have in mind.
I was running a script calling the DeepFace.stream() function, but as the library was loading the Age models, the program is killed. As I was trying to do some manual debug with a few print lines in /deepface/extendedmodels/Age.py , I noticed that it crashes after age_model.load_weights(home+'/.deepface/weights/age_model_weights.h5') is being called at line 51 of the aforementioned file. I notice a spike of CPU usage to 99% before the program is killed. I suppose it's a problem due to the dimensions of the models. I also notice that the model weights for facial expression analysis is loaded without any error (I suppose it loads because it's the lighter of the files, and I therefore suppose that Gender model too kills the execution).
Following, some additional info. Hope you can help me with this problem, thank you for your time reading about my ordeal and for any support.
PM
Current Python version:Python 3.7.3
Some info from neofetch:
OS: Raspbian GNU/Linux 10 (buster) armv7l
Host: Raspberry Pi 4 Model B Rev 1.5
Kernel: 5.10.103-v7l+
CPU: BCM2711 (4) @ 1.500GHz
Memory: 578MiB / 1820MiB

Output of "pip3 freeze":
pi@raspberrypi:~ $ pip3 freeze
absl-py==0.15.0
albumentations==1.1.0
appdirs==1.4.3
asn1crypto==0.24.0
astor==0.8.1
astroid==2.1.0
asttokens==1.1.13
astunparse==1.6.3
automationhat==0.2.0
beautifulsoup4==4.7.1
blinker==1.4
blinkt==0.1.2
buttonshim==0.0.2
cached-property==1.5.2
cachetools==4.2.4
Cap1xxx==0.1.3
certifi==2018.8.24
chardet==3.0.4
click==8.1.3
cmake==3.22.4
colorama==0.3.7
colorzero==1.1
cookies==2.2.1
cryptography==2.6.1
cupshelpers==1.0
cycler==0.10.0
Cython==0.29.28
decorator==4.3.0
deepface==0.0.74
dlib==19.23.99
docutils==0.14
drumhat==0.1.0
entrypoints==0.3
envirophat==1.0.0
ExplorerHAT==0.4.2
filelock==3.6.0
Flask==2.1.2
flatbuffers==1.12
fourletterphat==0.1.0
gast==0.3.3
gdown==4.4.0
google-auth==1.35.0
google-auth-oauthlib==0.4.6
google-pasta==0.2.0
gpiozero==1.6.2
grpcio==1.32.0
guizero==0.6.0
h5py==2.10.0
html5lib==1.0.1
idna==2.6
imageio==2.19.0
importlib-metadata==4.11.3
ipykernel==4.9.0
ipython==5.8.0
ipython_genutils==0.2.0
isort==4.3.4
itsdangerous==2.1.2
jedi==0.13.2
Jinja2==3.1.2
joblib==1.1.0
jupyter-client==5.2.3
jupyter-core==4.4.0
Keras==2.4.0
Keras-Applications==1.0.8
Keras-Preprocessing==1.1.2
keyring==17.1.1
keyrings.alt==3.1.1
kiwisolver==1.0.1
lazy-object-proxy==1.3.1
libutils==0.0.1
logilab-common==1.4.2
lxml==4.3.2
Markdown==3.3.6
MarkupSafe==2.1.1
matplotlib==3.0.2
mccabe==0.6.1
microdotphat==0.2.1
mote==0.0.4
motephat==0.0.3
mtcnn==0.1.1
mypy==0.670
mypy-extensions==0.4.1
networkx==2.6.3
nudatus==0.0.4
numpy==1.21.6
oauthlib==2.1.0
olefile==0.46
opencv-python==<IP_ADDRESS>
opencv-python-headless==<IP_ADDRESS>
opt-einsum==3.3.0
packaging==21.3
pandas==1.3.5
pantilthat==0.0.7
parso==0.3.1
pexpect==4.6.0
pgzero==1.2
phatbeat==0.1.1
pianohat==0.1.0
picamera==1.13
pickleshare==0.7.5
picraft==1.0
piglow==1.2.5
pigpio==1.78
Pillow==9.1.0
pipdeptree==2.2.1
prettytable==3.2.0
prompt-toolkit==1.0.15
protobuf==3.13.0
psutil==5.5.1
pyasn1==0.4.8
pyasn1-modules==0.2.8
pycairo==1.16.2
pycodestyle==2.4.0
pycrypto==2.6.1
pycups==1.9.73
pyflakes==2.0.0
pygame==1.9.4.post1
Pygments==2.3.1
PyGObject==3.30.4
pyinotify==0.9.6
PyJWT==1.7.0
pylint==2.2.2
pyOpenSSL==19.0.0
pyparsing==2.2.0
pyserial==3.4
pysmbc==<IP_ADDRESS>
PySocks==1.7.1
python-apt==<IP_ADDRESS>
python-dateutil==2.7.3
pytz==2022.1
PyWavelets==1.3.0
pyxdg==0.25
PyYAML==6.0
pyzmq==17.1.2
qtconsole==4.3.1
qudida==0.0.4
rainbowhat==0.1.0
reportlab==3.5.13
requests==2.21.0
requests-oauthlib==1.0.0
responses==0.9.0
retina-face==0.0.10
roman==2.0.0
RPi.GPIO==0.7.0
rsa==4.8
RTIMULib==7.2.1
scikit-image==0.19.2
scikit-learn==1.0.2
scipy==1.7.3
scrollphat==0.0.7
scrollphathd==1.2.1
SecretStorage==2.3.1
semver==2.0.1
Send2Trash==1.5.0
sense-emu==1.2
sense-hat==2.2.0
simplegeneric==0.8.1
simplejson==3.16.0
six==1.15.0
skywriter==0.0.7
sn3218==1.2.7
soupsieve==1.8
spidev==3.5
ssh-import-id==5.7
tensorboard==2.9.0
tensorboard-data-server==0.6.1
tensorboard-plugin-wit==1.8.1
tensorflow @ https://github.com/bitsy-ai/tensorflow-arm-bin/releases/download/v2.4.0/tensorflow-2.4.0-cp37-none-linux_armv7l.whl
tensorflow-estimator==2.4.0
termcolor==1.1.0
thonny==3.3.10
threadpoolctl==3.1.0
tifffile==2021.11.2
tornado==5.1.1
touchphat==0.0.1
tqdm==4.64.0
traitlets==4.3.2
twython==3.7.0
typed-ast==1.3.1
typing-extensions==<IP_ADDRESS>
uflash==1.2.4
unicornhathd==0.0.4
urllib3==1.24.1
wcwidth==0.1.7
webencodings==0.5.1
Werkzeug==2.1.2
wrapt==1.12.1
zipp==3.8.0

The script I'm currently trying to run (I know it's a single line, but just to be sure I'm doing anything correctly):
from deepface import DeepFace

DeepFace.stream()

The terminal output as I try to run my code:
Detector backend is  opencv
WARNING: There is no image in this path (   ) . Face recognition will not be performed.
Emotion model loaded
Killed

your memory device seems not enough to run this model obviously.


Normal comments are not showing up anymore

Hello,
If Semantic-Linkbacks is activated on WordPress, "normal" comments are not shown anymore below each article.
Sorry but this is a very annoying bug. I don't know when and what changed, but I hope you can fix it soon! :)

https://github.com/pfefferle/wordpress-semantic-linkbacks/issues/140

thanks for reporting! fixed in version 3.7.2.

Sorry didn't see #140 😅 Thanks for the fix, you ROCK!

No problem, I closed a way too early :)


Regular Sync: not enough connected peers

Describe the bug
This happens with my libp2p branch. I notice during initial sync, I can see ~20 connected peers but at regular sync, it reduced gradually (mostly with 129 goodbye code) and in worse case, we have no sync peers.
Expected behavior
Should maintain ~20 connected peers like in initial sync

close in favor of #1637

This still happens even after the removeIncluded fix in my local branch. The profiler shows that we don't have any long running functions (2.5s for runStateTransition), however number of peers still reduced gradually from the regular sync time (I was able to sync for 1h and connected peers reduced too).

So I below is the reasons why our peers are disconnected:

129: too many peers. Note that lighthouse sorts peers by score, it means our peers don't have a good score
250: bad score
251: banned. There is a discussion to follow up here https://discordapp.com/channels/605577013327167508/618981555985186827/763040947164282921

So we have to improve our performance/score first. Currently from regular sync, it takes 1.5s - 2s to process a block/slot and even 4s-5s to process an epoch in my environment, this is due to the performance of bls as it takes only 15ms-20ms in the case of initial sync.
We have to stay with this for a while (~3 sync peers in my case) until we optimize our bls.

we are subscribe to gossip during our regular sync? Maybe we have bad gossip score since we are basically censoring messages?
Might be also because of our old gossip?

Today it happened with initial sync too and I had 0 peers.So maybe it's not related to gossip.
I noticed that discv5 still sent "peer" event to libp2p frequently so there's something inside libp2p to debug.

hmm you could try deleting peerstore, and see if you will get some peers

yeah that would help before we start the node but during the sync we don't want to have only 0-5 peers

is you isp blocking your traffic? lol
you have a lot of disconnection.

Error occurred during XX handshake: Error occurred while verifying signed payload: Peer ID doesn't match libp2p public key.

Could be because of incomplete public key protobuf, not sure.
https://github.com/NodeFactoryIo/js-libp2p-noise/blob/f9d56d8c87635ec03b6d7aa50e594b57923f41df/src/utils.ts#L72

I think this is the root cause: right now when we process a range of blocks without allowing anything in the middle:
2020-10-15 11:09:20 [SYNC]             ^[[32minfo^[[39m: Imported blocks for slots: 499649,499650,499651,499653,499654,499655,499659,499660,499661,499664,499665,499666,499668,499669,499671,499673,499674,499676,499678,499679,499680,499681,499682,499684,499685,499688,499690,499691,499693,499695,499696,499701,499703,499705,499706,499708,499709,499710
2020-10-15 11:09:23 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499649, root=0xfecc488ced9363529cefbb987d2f350161b01f0f90f914aab41980e4e12fb6a2
2020-10-15 11:09:25 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499650, root=0xda714c761377c88a49a0dedbe68f022a9c29f294c0b5ca26c2cbb8a6d0dbbb20
2020-10-15 11:09:28 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499651, root=0x01c27d976796bd5d32ad82ba644dafbc2a75aab2454ac524841129b62e144653
2020-10-15 11:09:30 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499653, root=0x5a0704b0f6f5aba42daf28c0cb031091f8a3bb9b70e5438379eaf3d7d0c549c9
2020-10-15 11:09:32 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499654, root=0x9cad9e48a33c157eaf9cea230da269eea23c5f6e89cbec0f4162c6d625b8ddb3
...
2020-10-15 11:10:44 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499709, root=0x1fc4da0e195ecae29bc6c15da83d8e7c92a61220fc009722d708a2c06091906c
2020-10-15 11:10:47 [CHAIN]           ^[[34mdebug^[[39m: Block processed slot=499710, root=0xd87ede970eff574ace1d86907e2d4d1de444720b32e9331480b899fcb198723b
2020-10-15 11:10:47 [SYNC]             ^[[32minfo^[[39m: Regular Sync: Requesting blocks from slot 499711 to slot 499774
2020-10-15 11:10:47 [SYNC]             ^[[32minfo^[[39m: Regular Sync: Synced up to slot 499710  currentSlot=515753, gossipParentBlockRoot=undefined

the log above shows that there is nothing happened in the middle, and it took 1m27s to process a block range, we should do some tricks to allow other events to be executed in the nodejs event loop.
In initial sync, we do everything so fast so we didn't see the issue.

Dunno, maybe try putting await sleep(1) after block is processed? :smile:

I did await sleep(0);. It works just fine :D


registered logging issue

love CocoaLumberjack - thank you.
just tried to use registered logging, but I get errors with classes that don't implement the methods for isRegisteredClass
e.g.:
*** NSForwarding: warning: object 0x3aae0f1c of class '__NSMessageBuilder' does not implement doesNotRecognizeSelector: -- abort
and on the simulator:
checking class: NSXPCDecoder
2013-03-23 17:09:54.629 VLCStreamer[88695:c07] *** NSForwarding: warning: object 0x2530b48 of class 'Object' does not implement methodSignatureForSelector: -- trouble ahead
2013-03-23 17:09:54.629 VLCStreamer[88695:c07] *** NSForwarding: warning: object 0x2530b48 of class 'Object' does not implement doesNotRecognizeSelector: -- abort
Am I missing something?
thanks.

I have this issue after I updated to the latest version (2.0.0) from cocoapod (0.36.3). Previously it was working fine (ver 2.0.0-beta4 pod 'CocoaLumberjack', :git => "https://github.com/ValCapri/CocoaLumberjack.git").
My class is implementing the DDAbstractLogger.
I tried to import NSObject, but it is already imported by DDAbstractLogger, I tried to use protocol DDLogger, but no success.
I'm using swift
NSForwarding: warning: object 0x10013b0a0 of class does not implement methodSignatureForSelector: -- did you forget to declare the superclass of ?
NSForwarding: warning: object 0x10013b0a0 of class does not implement doesNotRecognizeSelector: -- abort

Closing due to lack of new info.


redundant job entries returned by /api/sessions/{session_id}/jobs?join=gears

This is happening for new jobs related to analysis gears. Doesn't seem to impact utility gears.

Debugging information: afq-demo appears to trigger this behavior.


Ability for globally accessible bookmarks

Currently, saved bookmarks are only accessible on a per-dashboard level. However, certain customers and end users want globally accessible bookmarks that can be accessed from other dashboards (mostly for interactive analysis).
Slack context: https://rilldata.slack.com/archives/C05693FLY7Q/p1711403421506239

We will not be making bookmarks global or globally accessible due to cluttered dialogs.
However introducing a global asset search is something we are considering that would allow you to search across assets within the entire deployment. Together with the ability to pin/favourite results for easy access.

Global asset search and the ability to pin results should be sufficient. Anywhere that we can track that work / link it to the support ticket for better visibility?


Page Title: Unable to set to static, removing data-title causes an 'undefined'

Operating system: Any
Last upstream commit (run git log --author="Robert Lord" | head -n 1): commit cf29f6786c288b6111239b8e8b211f8ae2fbc4c3
Browser version(s): Any
Ruby version (run ruby -v):  ruby 2.3.3p222 (2016-11-21 revision 56859) [x64-mingw32]

We started seeing either an 'undefined' or a blank space in our page titles, as some of the headers have nested html, and the Slate code is apparently having difficulty reading the text out of the embedded code.

We figured we would hard code the page title, and remove the data-title attributes. This results in an 'undefined' in the title:

We then reset our title in the html.md.erb to the full static title we wish to see, and the result is then an 'undefined' followed by a hyphen followed by that full title.
We got around this finally by setting the data-title in the layout.erb to the static text we wanted, but this seems like a lot of overhead for a simple static title. Much simpler to have just removed the code out of the title tag in the layout.erb, or enabled a switch somewhere to use a static title defined in the html.md.erb.
I dug into the javascript to track it down. In javascripts/app/_toc.js line 88 the document.title is set to the $best object's title attribute, with a hardcoded hyphen, then the original title.
// TODO remove classnames
document.title = $best.data("title") + " – " + originalTitle;

There's no null/empty functionality here, which explains the issue. Normally, I'd expect to see a case for an undefined property and handle it, and that's missing here. Something to the effect of:
document.title = ( typeof $best.data("title") !== 'undefined' || $best.data("title") !== '' ) ? $best.data("title") + "-" + originalTitle : originalTitle;

Something would still need to be done with the  tag in the layout.erb, though, as I still see an undefined even with the above code. I am probably missing something later, and I don't have the time to track this down at the moment, unfortunately--  my work around works for us and we're moving on.
Basically, there's no way to set a static title without going through  if we remove the data-title attribute in the layout.erb, and it would be great if there was, as well as null/empty error handling.

Actually going to reopen this — we've fixed the undefined problem (hopefully) but still would be nice to have some predictable way to disable dynamic titling.


Deployment docs v2 android missing somethings

I was following the instructions on this page.
Some items missing from the Android section

JDK is required
ionic platform add android is required
Current version of android sdk is not compatible with ionic 2, see:
http://stackoverflow.com/questions/42668185/could-not-find-gradle-wrapper-within-android-sdk-might-need-to-update-your-andr

Other than that it installed well. Apologies for no pull request but the last item should be explored a bit by someone that knows what they are doing before being documented.

We do have this page here
http://ionicframework.com/docs/v2/resources/platform-setup/mac-setup.html
Which covers a lot more of the requirements needed.
Does this help?

Can you close it @gatapia?
I edited the Android setup guide and added the JDK and some build/sign steps.


feat: Add Roche Cedex HiRes Adapter

Add adapter for the Roche Cedex HiRes instrument. The adapter handles both XLSX and CSV exports of the instrument data.
The adapter uses cell counter schema of allotropy.

@poojabalaji05 looks like there are some typing issues, with current version, you can view these by running hatch run lint:typing or just hatch run lint. Will approve once passing!

@nathan-stender
Fixed the linting issues. Once the Qubit4 PR is approved and the code is merged, the test scripts for Roche Cedex HiRes should function correctly upon syncing the forks. This is because we've added the functionality to remove custom fields if their values are None in the Qubit4 PR.

@poojabalaji05 still have a test failure here 👀

@poojabalaji05 if you pull past this PR: https://github.com/Benchling-Open-Source/allotropy/pull/507, you can run hatch run scripts:update-readme to update the README file!

@nathan-stender
I have updated the README.md file by adding the parser and also included the vendor in the NON_READY_PARSERS dictionary to avoid test failure in test_vendor_release_state function.
I noticed that the test script structure has been modified, so I have made the necessary adjustments from my end as well.
Additionally, the Roche Cedex HiRes test is failing due to null values being added to the custom information document dictionary. This issue will be resolved once we sync the fork after merging Qubit 4 PR, which removes the null keys.

@nathan-stender
I've pulled the latest changes from the main branch, and all checks are passing. Could you merge this fork for Roche Cedex Hires adapter into the main repository?


Storage non-resumable uploads fail

Storage non-resumable uploads fail when used with @google-cloud/common 0.12.1. The error message is:
UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Sorry, we cannot connect to Cloud Services without a project ID. You may specify one with an environment variable named "GCLOUD_PROJECT". See https://googlecloudplatform.github.io/google-cloud-node/#/docs/guides/authentication for a detailed guide on creating an authenticated connection.

The error message is misleading. The code mistakenly assumes any error thrown util.makeAuthenticatedRequestFactory -> makeAuthenticatedRequest -> onAuthenticated is because of a missing project ID.
The bug that causes the error was introduced by #1990. hasOwnProperty is called on an object that does not have that function. An alternative implementation would be to call Object.hasOwnProperty.call(value, opt) instead of value.hasOwnProperty(opt).
Environment details

OS: macOS, Linux
Node.js version: 6.x
npm version: 3.x
google-cloud-node version: 0.47.0

Steps to reproduce

require google-cloud
storage.bucket('my-bucket').upload('file.txt', { resumable: false })

Thank you for catching this and debugging it! I just put through a fix: https://github.com/GoogleCloudPlatform/google-cloud-node/commit/a1edaab91a646b47dc4596b38c76c7beb1e510a9 -- does this look good?

This bug is still active. google-cloud-node version:"0.7.0", default storage.bucket('my-bucket').upload('file.txt') does not upload .Must explicitly add resumable flag for upload  storage.bucket('my-bucket').upload('file.txt', { resumable: true }) .

This code works for me with<EMAIL_ADDRESS>var storage = require('@google-cloud/storage')()
var bucket = storage.bucket('stephen-has-a-new-bucket')

bucket.upload('package.json', console.log) // no error

Can you make sure you rm -rf node_modules && npm install --save<EMAIL_ADDRESS>and let me know if it persists? If you can, a reproducible test gist that I can clone, install, and run to see the crash would help.


Experiment: Metadata using Zod prototypes

According to the Zod author's PR, it's kinda OK to alter Zod's prototypes:
https://github.com/colinhacks/zod/pull/3445/files#diff-d8a41ab20c64f92092513f153b78e7bbf5dc929c92909fad25e03d53c7f15bb7R21-R37
I tried to avoid that when I created withMeta(), but since Colin is doing it themselves, this approach could be beneficial for consumers.

this won't work by altering prototypes of ZodType, because it's not enough for .example() to return this for being a particular class instance.

my bad, there is probably a way...

The approach on altering prototypes of ZodType is confirmed by Colin:
https://github.com/colinhacks/zod/pull/3445#issuecomment-2091463120
The final plugin implementation is here (slightly changed):
https://github.com/colinhacks/zod/blob/90efe7fa6135119224412c7081bd12ef0bccef26/plugin/effect/src/index.ts#L21-L51

✅ QA passed


Add the ability for modlogs to send to a channel

Change the config format from .json to .ts (allowing easier typing & doc)
Update templates.ActionCommand.ts to new configs
Finish updating utils to new configs
Fix rule numbering
Make logging work
Make logging correctly specify the moderator
Previously a command would let you send a notification to someone
higher than you saying that you had moderated them before failing to
take the action for kicks and bans. This has been fixed
Prevent pinging in the moderation log message to stop multiple pings
for multi-channel logs and 'at everyone in reason' vulnerabilities

Undefined behavior:

If the message is too long, this doesn't paginate it, and if the
message fails to send the moderation action will ignore it and run
anyway. This means that it may be possible to run a moderation action
without logging it in the channels

Deployment caveats:

As the rules format changes in this PR, data migration will be
required
As the config format changes in this PR, config migration will be
required

All changes look good :+1:
("Reviewed" for @Minion3665 )

All changes look good +1 ("Reviewed" for @Minion3665 )

Sounds good, thank you Ash
@Cleover do you want to take another look on call w/ me before I merge or no?


Add Swahili Locale

Pull Request Checklist
Thank you for taking the time to improve Arrow! Before submitting your pull request, please check all appropriate boxes:

[x] 🧪 Added tests for changed code.
[x] 🛠 All tests pass when run locally (run tox or make test to find out!).
[x] 🧹 All linting checks pass when run locally (run tox -e lint or make lint to find out!).
[ ] 📚 Updated documentation for changed code.
[x] ⏩ Code is up-to-date with the master branch.

If you have any questions about your code changes or any of the points above, please submit your questions along with the pull request and we will try our best to help!
Description of Changes
These changes add support for Swahili locale.

Codecov Report

Merging #797 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #797   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        10
  Lines         1713      1724   +11
  Branches       295       295
=========================================
+ Hits          1713      1724   +11

Impacted Files
Coverage Δ

arrow/locales.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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

@krisfremen sure can! I have updated with more tests.
Cheers!


Bug: -G doesn't do anything -t & -2 don't do what I say, and -G doesn't flip drives as docs say it does

I have 3 NVME's I know which one I want for -t, and -2; but your software flips the drives, u have switch called '-G' that is suppose to flip, but nothing changes, why in  the hell do u do this?
NVME /dev/nvme0 & /dev/nvme1
chia_plot -t /dev/nvme0 -2 /dev/nvme1 -d /dev/hdd0 ... ( NOTE -t is zero, -2 is one )
Yet, every time I run the plotter, it is dolng -t as /dev/nvme1 and -2 as /dev/nvme0 ( note -t is now one, -2 is zero )
The -G doesn't work and the -t & -2 dont'  do as I say, can u justify why u think your smarter than the user? What's the point of even having switches if they don't do what I say????
When I run the 'chia plots create -t -2' is does exactly what I say, why can't you???
...
Ok, other than above It's a fine program, I will not be making new geriatric Portable Plots for Cohen&Hoffman, so I'm running a two week old version that's fine with me, I see about 20min/plot, and I'm doing 72 plots per day "Classic Plots", no NFT plots allowed in my house. :)
I run the cmd with 'nice -n 5' so it doesn't hog the cpu, I run the chia_plot with "sudo ionice -p PID -c 3", which tells YOUR plotter to only hog the system-IO in idle, if I don't do this the system is unusable, the difference with &without the limiting is like 1-2 minutes longer.

NVME /dev/nvme0 & /dev/nvme1
chia_plot -t /dev/nvme0 -2 /dev/nvme1 -d /dev/hdd0 ... ( NOTE -t is zero, -2 is one )
Yet, every time I run the plotter, it is dolng -t as /dev/nvme1 and -2 as /dev/nvme0 ( note -t is now one, -2 is zero )
The -G doesn't work and the -t & -2 dont' do as I say, can u justify why u think your smarter than the user? What's the point of even having switches if they don't do what I say????
When I run the 'chia plots create -t -2' is does exactly what I say, why can't you???
...
Ok, other than above It's a fine program, I will not be making new geriatric Portable Plots for Cohen&Hoffman, so I'm running a two week old version that's fine with me, I see about 20min/plot, and I'm doing 72 plots per day "Classic Plots", no NFT plots allowed in my house. :)
I run the cmd with 'nice -n 5' so it doesn't hog the cpu, I run the chia_plot with "sudo ionice -p PID -c 3", which tells YOUR plotter to only hog the system-IO in idle, if I don't do this the system is unusable, the difference with &without the limiting is like 1-2 minutes longer.

-G only flips the drives every second plot... have you actually waited for more than one plot to complete? You need to do -n -1 or -n [something greater than 1] and then just wait - it should work as expected.

Did you used "-G true" or just "-G"?

The same problem,
So to work it as I want, need to pu tempdir1 (-2) and tempdir2 (-t) ??
And then it uses 110Gb for tempdir2 (-t) or for -2?
And kinda strange that tempdir2 hold most writes 75% as I was testing even with  old HDD putting it on temp2 no big time loss
But if I put temp1 on HDD it slows and plots for day.
Very strange only 25% writes takes more time 600% than 75% writes???
Mistakes on mistakes


4d8fdf4e31b3d18aba064e138ace17f91bede916 broke aarch64 build

Description
4d8fdf4e31b3d18aba064e138ace17f91bede916 unconditionally uses x86-64 asm.
It's invalid on arm:
/tmp/cc9ekx10.s:2282: Error: unknown mnemonic `int' -- `int $0x03'

Hi there, your issue has been closed due to not correctly following the issue template. Please read the documentation about filing issues and open a new issue which does follow the issue template. Do not reply to this issue with more information or with a correctly formatted issue, as that will only lead to confusion.
I try to address all github issues and fix bugs quickly, but badly formatted issues or poorly described bug reports especially are a significant drain on project resources. Taking a few minutes to file a good issue makes a huge difference and will get it addressed faster - everybody wins!
In github when you first create a new issue the form is pre-populated with a template which you should read over and follow. As linked above there is documentation going into more detail about what makes a good issue.


Time changes by itselt weeks after it has been stopped

User reporting this happening on linux app
More data in case 215081

Have not been able to reproduce. Might be some strange syncing issue.


add schedule parameter to cost data collection lab

Issue #, if available:
Description of changes:
add schedule parameter to cost data collection lab
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Fixes this issue -> https://github.com/awslabs/aws-well-architected-labs/issues/539

@awssteph what do you think about that?


unwatch when exit because resource release could break the system

Codecov Report

Merging #25 (dee20f3) into master (59bc71d) will decrease coverage by 2.02%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##            master      #25      +/-   ##
===========================================
- Coverage   100.00%   97.97%   -2.03%
===========================================
  Files            6        6
  Lines          343      345       +2
===========================================
- Hits           343      338       -5
- Misses           0        7       +7

Impacted Files
Coverage Δ

src/watchpoints/__init__.py
100.00% <100.00%> (ø)

src/watchpoints/watch.py
100.00% <100.00%> (ø)

src/watchpoints/util.py
86.66% <0.00%> (-13.34%)
:arrow_down:

src/watchpoints/ast_monkey.py
94.73% <0.00%> (-5.27%)
:arrow_down:

Continue to review full report at Codecov.

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


diatypst:0.3.0

I am submitting

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

Version 0.3.0 of diatypst

added new styling options
added new options from a pull request

Thanks :)


Status of Project

@tarruda @justinmk
I ran into some issues building the lua bindings and sent in a pr which should resolve them. I noticed there hasn't been any activity since around march and as I understand things @tarruda has had less time for neovim and related projects. I don't really know much in the way of C but I'm down to help out with the build-system issues and/or project management stuff if you guys are good with that. Also sorry if this is coming off as pushy or anything, just looking to help.

For some reason I was not watching libmpack-lua repository and didn't receive email notifications, so I'm sorry for the delay.


cue fmt corruption

Commit b0d1a07d3dcd9e12dabd71c56e37530474f30ed3
Running this cue code through cue fmt results in corrupt output:
{
  "type": "record",
  "name": "LongList",
  "aliases": ["LinkedLongs"],                      // old name for this
  "fields" : [
    {"name": "value", "type": "long"},             // each element has a long
    {"name": "next", "type": ["null", "LongList"]} // optional next element
  ]
}

The output is:
{
	"type": "record"
	"name": "LongList"
	"aliases": ["LinkedLongs"] // old name for this
	"fields" : [
		{// each element has a long"name": "value", "type": "long"},
		{// optional next element"name":   "next", "type": ["null", "LongList"]},
	]
}

This issue has been migrated to https://github.com/cue-lang/cue/issues/155.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


App Center API Swagger (In Preview)

I'm looking specifically at the "PUSH" section of the API for push notifications.  Most of these API endpoints are returning...
{"message":"Forbidden","code":"Forbidden"}
...after authenticating myself at the top.  Are these working yet and just turned off or am I missing something in utilizing this swagger doc?
DEVELOPER COMMAND PROMPT OUTPUT
C:\WINDOWS\system32>curl -X POST "https://api.appcenter.ms/v0.1/apps/itzzi-18ep-39/Axos_Agent_IOSMobileUI/push/notifications" -H "accept: application/json" -H "X-API-Token: {MY API TOKEN WAS PLACED HERE, EXCLUDING BRACES}" -H "Content-Type: application/json" -d "{ "notification_target": { "type": "string" }, "notification_content": { "name": "Testing 1 2 3", "title": "Hello There", "body": "I'm hungry now.", "custom_data": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" } }}"
{"message":"Forbidden","code":"Forbidden"}
C:\WINDOWS\system32>

@anitconsultantllc Sorry about that - the Swagger isn't properly showing the options you need to use. We're working on an update to fix this. this is where it's likely failing: "notification_target": { "type": "string" } you must provide an actual type there. here's an example: https://docs.microsoft.com/en-us/appcenter/push/rest-api#send-notifications-to-device-ids.

Try sending a push via the AppCenter portal with Developer Tools enabled (F12). The portal calls the same API. This way you will be able to see the exact payload, check the app URL, and verify that your user has access to perform this operation.

@anitconsultantllc We're doing an update to fix this.

Hi
I'm trying to delete all notification config in appcenter, but i get 403 Frorbiden
What I do wrong?
(I got 202, when I using POST push/notification with same token; I have full acces)
https://ibb.co/Dt0DfqF

@MatsyshynAnton The comments feature of our documentation is intended to enable customers to suggest changes to the docs or ask clarifying questions about the docs.
App Center support is provided directly from within the App Center portal. Any time you need help, just click the blue chat button in the lower-right corner of any page and our dedicated support team will respond. For additional information, see the App Center Help Center.


USB 3.0 devices with PHYWhisperer

Hello,
I'm attempting to sniff basic USB traffic with the PHYWhisperer, however I get this error when starting ViewSB
viewsb phywhisperer --pattern 45 --mask 255
ddaly@OPERATOR:~$ viewsb phywhisperer --pattern 45 --mask 255
Process TUIFrontend process:
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/ipc.py", line 124, in _subordinate_process_entry
    task.run()
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 307, in run
    self.loop.run()
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 287, in run
    self._run()
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 385, in _run
    self.event_loop.run()
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 790, in run
    self._loop()
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 823, in _loop
    alarm_callback()
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 173, in cb
    callback(self, user_data)
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 270, in <lambda>
    self.loop.set_alarm_in(self.BACKGROUND_REFRESH_INTERVAL, lambda _, __ : self.handle_communications())
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 262, in handle_communications
    super().handle_communications()
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontend.py", line 218, in handle_communications
    self.handle_incoming_packet(packet)
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 284, in handle_incoming_packet
    self.loop.process_input(['end', 'a'])
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/main_loop.py", line 513, in process_input
    k = self._topmost_widget.keypress(self.screen_size, k)
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/container.py", line 1135, in keypress
    return self.body.keypress( (maxcol, remaining), key )
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/container.py", line 2316, in keypress
    key = w.keypress((mc,) + size[1:], key)
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 376, in keypress
    self.focus_changed()
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 338, in focus_changed
    self.focus_changed_callback(focused_node, focused_node.get_value())
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 118, in packet_focus_changed
    self.populate_decoder_view(packet)
  File "/usr/local/lib/python3.6/dist-packages/viewsb-0.0.1-py3.6.egg/viewsb/frontends/tui.py", line 193, in populate_decoder_view
    self.decoder_rows.append(urwid.Text(('header', table_name)))
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/widget.py", line 834, in __init__
    self.set_text(markup)
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/widget.py", line 877, in set_text
    self._text, self._attrib = decompose_tagmarkup(markup)
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/util.py", line 380, in decompose_tagmarkup
    tl, al = _tagmarkup_recurse(tm, None)
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/util.py", line 418, in _tagmarkup_recurse
    return _tagmarkup_recurse( element, attr )
  File "/usr/local/lib/python3.6/dist-packages/urwid-2.1.1.dev0-py3.6-linux-x86_64.egg/urwid/util.py", line 421, in _tagmarkup_recurse
    raise TagMarkupException("Invalid markup element: %r" % tm)
urwid.util.TagMarkupException: Invalid markup element: None

I think this has something to do with the device being a USB 3.0 device, even using the usbmon backend, I get the same error.
I suspected the PHYWhisperer would automatically drop the 3.0 target to 2.0, if this is not the case I may just need to pick up a USB 2.0 hub.
Any help is appreciated, cheers!

Some comments from the PhyWhisperer side of things: the USB PHY on the PhyWhisperer doesn't support USB 3.0. It's a passive PHY that only listens, which means that it doesn't participate in the USB speed negotiation; it's not able to drop the target to 2.0. So, if your target and host computer decide on USB 3.0, PW won't work for you.  (This was a conscious design choice: for its intended application in side-channel attacks, we wanted the PW to be completely transparent to the target).
An alternative to using a hub would be to set your host's USB port to 2.0 operation.
If you're still having trouble, I recommend you start by making sure that you can talk to PW directly, without the ViewSB layer (i.e. try our example notebooks).
Hope this helps clarify what the PW can and can't do.

Thank you very much, I suspected this would be the issue, Lenovo seem to have removed the UEFI option to force my USB Controllers into 2.0, I think Dell's have this ability, I'll just pickup a cheap USB 2.0 hub to step it down for me.
Thank you very much!


Not work Samsung C34J79

Checklist

[x] I have searched for existing issues
[x] I have looked through the Monitor Troubleshooting wiki
[x] I have updated MonitorControl to the latest version

Describe the issue
A clear and concise description of the problem.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Environment Information (please complete the following information):

macOS version: BigSur 11.2.3
MonitorControl version: 2.1.0 release 721
Monitor(s): Samsung C34J79
Mac model: MBP 2020 m1
Monitor Cable(s)/Connection(s): (e.g. DisplayPort) thunderbolt 3

See #323


pkg/asset: bump flannel to v0.7.1

fixes https://github.com/kubernetes-incubator/bootkube/issues/454

tests likely won't pass because https://github.com/kubernetes-incubator/bootkube/pull/457 hadn't merged yet. But I'll rerun if they fail

rktbot run tests


C API return values are not type-safe

For example, if the expectation defines a float return value, and the actual call uses mock_c()->intReturnValue() to retrieve it, it causes undefined behaviour (typically resulting in the bit-pattern-equivalent int being returned, but that's compiler-specific).
This is because the various returnValue_c implementations call getMockValueCFromNamedValue, which does check the type defined on the C++ side and populates the appropriate field of a union, but they then return one field of the union without guaranteeing that this was the field just written to.
This also fails to invoke the type conversions implemented by the C++ MockNamedValue, eg. between signed and unsigned values.  (Although those aren't entirely consistent either.)
Suggested fix is to replace code such as this:
int intReturnValue_c()
{
    return getMockValueCFromNamedValue(actualCall->returnValue()).value.intValue;
}

With code more like this:
int intReturnValue_c()
{
    return actualCall->returnValue().getIntValue();
}

Or, of course, just:
int intReturnValue_c()
{
    return actualCall->returnIntValue();
}

Is the first version still around? I thought I had cleaned them out?
Whether the second or the third option is correct, depends on the context (same as in C++). The first snipped would suggest that, in this context, the third snippet would be called for.

As far as I can see, this code is only used for testing.
What is the use case for problems showing?
I have run into that sort of problem only for one reason: When a MockNamedValue is undefined, it actually defaults to int, leading to problems like the one you mention. I have been wondering about this before. Could we make MockNamedValues type default to "undefined" in that case, perhaps? How would that have to be handled (presumably fail the test)?

I haven't encountered a problem "in the wild", this was just something I noticed while reading the code.  So yes, it's still there (unless it was changed in the past couple days, maybe).
The code is not just used for testing.  This is the C API.  It will be encountered if anyone makes an expectation with a return value whose type differs from the type used to retrieve the return value in the actual call.
Note that most of the time it will work anyway by coincidence -- eg. mixing up integer types will usually be invisible, because on many platforms int and long are the same size, and signed and unsigned ints can be mixed if you're not using a value in the top bit range.  But relying on different union members to have the same offset in the storage is technically undefined behaviour, even though most implementations will do this.
Both the second and third snippets are equivalent; neither is more "correct" than the other.  The third is merely more concise.

These shouldn't be there; apperently I overlooked them when adding the new functions. Calling the returnValue on actualCall vs. MockSupport is subtly different (see the C++ interface) as far as I remember. When I worked on this a while ago, I thought the returnValue calls on MockSupport were redundant - but not so! I should think the C interface should follow the C++ code.

Actually, to be honest, without looking more closely, I am not sure right now where these functions belong but I think it's MockActualCall_c so the actual call version would be appropriate..... :-/

Arggh. both interfaces use the same functions.... This isn't good. It must be possible to come up with a test case that exposes a bug here. There should be two sets of functions, the one wrapping MockSupport, the other one wrapping MockActualCall, and they are not (quite) the same.
Will give it some thought later this week. This should definitely be fixed.

Also, yes, your 2. and 3. are of course equivalent and 3. would be preferred. The one I had in mind is like
void* returnPointerValueOrDefault_c(void * defaultValue)
{
    if (!hasReturnValue_c()) {
        return defaultValue;
    }
    return pointerReturnValue_c();
}

and that should wrap MockSupport ( and not MockActualCall).......

Does the distinction matter?  mock().intReturnValue() == mock().returnValue().intReturnValue() == (last result of mock().actualCall(...)).intReturnValue() etc, and it's the same on the C side.
This is required by the split call case, although TBH I think the API would be cleaner if these were removed from MockSupport entirely (perhaps replaced with a lastActualCall() method).

About removing it entirely - maybe @basvodde would care to comment? My memory is a bit foggy now, but at some point I was like, hey, let's remove this redundancy (on the C++ side), and then realized that things weren't quite so simple and it's actually needed.
As long as it is there on the C++ side, I think it would be better to implement the C side to match.
Either way, there is no reason any more to access the fields of the MockValue directly, so that code should definitely go. I'll take a closer look at it as soon as I can take the time.

I'm not quite sure what is proposed to be removed?

This is kinda off-topic (probably discussion of removing things should be a separate issue) -- originally this was just about the C API type safety.
But regarding removing things, basically everything in MockSupport (both C and C++) dealing with return values seems almost redundant, and it would declutter and simplify the code if they were all removed.
However, there are two caveats:

Just removing them is unacceptable as it breaks required functionality of splitting actualCall usage in two parts (as shown in some of the examples).  However this can be resolved by adding one method to replace all of the existing ones: mock().lastActualCall(), which returns a MockActualCall& that can then be called through to get at the return value APIs that were removed from the top level.

Removing APIs is obviously a breaking change for any test code that currently calls them.  This may be undesirable.

I'm happy to make this into a PR if there's a chance that the second caveat won't torpedo the whole thing (making it a waste of time).
But remember that this is a side-track and is completely unrelated to this current Github issue, which is about the dangers of accessing the wrong union members.

Uhm, I added the code in MockSupport. The reason is, it causes code like:
mock().actualCall( .... )
if (mock().hasReturnValue())
do something
And, I've written a lot of code like that. Having mock().returnValue have been very valuable shortcuts in practice (for me) and I'm hesitant of removing methods like these. What problem do they cause?

They caused @arstrube to get confused when the C API has the same implementation for both MockSupport_c and MockActualCall_c when looking at this actual issue.  Other than that, there's no problem, just a little clutter (and more duplication of interfaces, larger coverage surface, etc).
Still, what's wrong with replacing that code with this:
mock().actualCall(...);
...
if (mock().lastActualCall().hasReturnValue())
    do something

?  That's what I was suggesting, and I think it reads better, even if it is marginally more typing.

ie. yes, it would break existing tests that used those APIs, but the fix is just to find anything that calls
mock().**something return value-ish**

and replace it with
mock().lastActualCall().**something return value-ish**

Which is of course an inconvenience, but a pretty trivial one to recover from.

@uecasm confused, huh. Well, maybe. I'm okay with both API's being implemented with the same method, IF it is actually the same. I am opposed to breaking an exiting API (such as removing mock().returnIntValue()) which I found I, too, use a lot. IF it is really okay to implemnt both APIs by calling the same functions in C, then that is fine with me.
As for the code you pointed out above, I will change it. I must have overlooked it last time.

I refactored the code, which now produces exactly the same failure that we started with.
This is where actually the **orDefaultValue()-versions need to be called, but the plain version is also called int the test, without an actualcall, which is an error.

I'm not quite sure what you mean.

Have a look at the changed I made to the tests in my latest PR.

@uecasm is original problem still around with the Head revision? If so, could you post a minimal example exposing it? Or has it been solved?

Current HEAD looks fine.  I still think it would be cleaner to remove the duplicated APIs, but I guess that ship has sailed.


Wemod Installation

Thanks for this great launcher! Can you include Wemod in your list? Thanks!

@dickyocean it's possible, I got rid of the mod section of the code recently because I didn't like how it was implemented I won't be adding any mod programs for the time being because I'm focused on the decky plugin at the moment.


max_completion_tokens

The user needs to control how long the generated response can be. By specifying max_completion_tokens, one can set the maximum number of tokens in the generated completion, ensuring that the output does not exceed a desired length. For instance, if the user wants a concise summary rather than a long essay, setting a lower max_completion_tokens helps maintain brevity.
OpenAI API Reference:
OpenAI Completion Docs - max_tokens
Detailed Description of Parameters:
•	Type: integer
•	Range: 1 to any upper limit defined by the model’s context window
•	Default Value: Depending on the implementation, if not specified, it could default to the model’s maximum context window size minus the prompt tokens (e.g., max_completion_tokens = 256), or a sensible default like 256 tokens.
Description:
Defines the upper bound on the length of the generated response in tokens. Once the model has generated max_completion_tokens tokens, it will stop producing further output, even if no stop sequence is encountered.
Behavior:
•	If max_completion_tokens is set too low, the model may produce only very short answers.
•	If set very high, the model may produce unnecessarily long responses, potentially increasing costs and processing time.
•	Combined with stop sequences and other parameters (temperature, top_p), it ensures that the generation remains under user control in terms of length, style, and content.
Examples:
•	max_completion_tokens: 50: Limits the response to at most 50 tokens, useful for brief summaries.
•	max_completion_tokens: 1000: Allows for more extended answers, potentially longer stories or detailed explanations.

Some notes for the record (to be used in docs?):

If max_completion_tokens together with prompt tokens exceeds context window size, max_completion_tokens will be automatically truncated. There is no need be be careful about maximum value and count prompt tokens (not trivial with arbitrary models) or interrogate the model about it's context window.
Default value is "infinite", i.e. no limit on token count. Completion will stop either when the context window is full or some other condition (eg. stop) is satisfied.


Custom Exceptions

Begins custom exceptions as discussed in #66. This is going to be a somewhat rough process I believe as we have many different categories here and integrating into our current ValueErrors will be interesting. In addition we try to split this into two types of errors:

Unknown python exceptions which are handled as we currently have them (traceback + unknown_error type in the JSON return)
Known python exceptions where the traceback is omitted and only the known error message is returned.

We also get to simplify the executors somewhat as we can localize issues.
This needs a deep review from @loriab, I am anticipating many small issues/questions here.

@loriab can this get a final review?


ADDON-35090: Added toast message when enable/disable/delete/update/cl…

ADDON-35090

Added Toast Messages on Delete/Update/Create in table
Added Toast Messages on Enable/Disable any input
Updated generateToast function

:tada: This PR is included in version 5.0.0-develop.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

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


Disable parallel build (again) and keep TerminalApp PCHs

The build now builds every project multiple times, so I figure, why not
try to fix it.

@msftbot wait 1 minute


feat: add/remove instantiated scenes from the engine

Addresses #182

@DnMllr @alexanderGugel

lgtm :+1:

What is the use case for having Scene created in space?

@michaelobriena Are you referring to https://github.com/Famous/engine/pull/202/files#diff-1de37d20f8b6890668f053904aaf54d8R389 ?
We allow detached nodes, so I think having detached scenes makes sense.
Further there might be scenarios in which the global updater itself should not be updated using FRAME commands, but should run its own rAF loop. E.g. AFAIR W3C had the discussion of allowing rAF in Workers.
In general there is no use in decoupling Scene and FamousEngine is we don't account for this scenario IMO.

landed as e176693


Fix perf tab missing key warnings

#6862

@facebook-github-bot shipit

Thanks for the PR, your first to react-native and hopefully not the last ;)


Added support for servicemonitor

What this PR does / why we need it:
Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @gsemet

/lgtm
/ok-to-test

Great thank you for your contribution


Background option in Graph canvas isn't applied as intended

问题描述
On applying the backgorund option while initialising the Graph, it gets applied to both .x6-graph-scroller-background as well as .x6-graph-background
So the problem here is the grid (spots) in the graph are hidden when the background color style is applied to .x6-graph-background

重现链接
NA
重现步骤
Initialise a Graph object with any background color. You'll be able to see a visible difference
预期行为
Ideally, the background property should not be applied to .x6-graph-background, and that will make sure grid is visible throughout along with the expected color
平台

操作系统: [macOS, Windows, Linux, React Native ...]
网页浏览器: [Google Chrome, Safari, Firefox]
X6 版本: [1.28.2 ... ]

屏幕截图或视频（可选）
No response
补充说明（可选）
No response

The grid is at a higher level than background, so theoretically your question should not arise. Can you provide a reproducible demo？

This problem occurs when Scroller is enabled

@NewByVector https://codesandbox.io/s/damp-frog-f1kowr

/cib


Data mismatch when retrieving IEEE standards by xml2rfc paths

Current bibxml reference: https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.11_2012.xml
New bibxml legacy reference: http://<IP_ADDRESS>:8000/public/rfc/bibxml6/reference.IEEE_802-11.2012.xml
Note that,
The file name is different:
reference.IEEE.802.11_2012 vs reference.IEEE_802-11.2012.
The reference anchor attribute data is different:
anchor="IEEE.802.11_2012" vs anchor="IEEE.IEEE 802-11.2012"
The organization data is different:
<organization>IEEE</organization> vs <organization abbrev="IEEE">Institute of Electrical and Electronics Engineers</organization>
These should match the existing bibxml service references.

Thank you for the review!

Current bibxml reference: https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.11_2012.xml
New bibxml legacy reference: http://<IP_ADDRESS>:8000/public/rfc/bibxml6/reference.IEEE_802-11.2012.xml
Note that, The file name is different: reference.IEEE.802.11_2012 vs reference.IEEE_802-11.2012.

This is an issue with legacy path handling for IEEE. The anchor might not wish to see changes because the anchors are used in existing documents. We will fix this in #18 (this could be slightly tricky, though).

The reference anchor attribute data is different: anchor="IEEE.802.11_2012" vs anchor="IEEE.IEEE 802-11.2012"

The duplicated "IEEE" is an error. Will be fixed here: relaton/relaton-ieee#11

The organization data is different: <organization>IEEE</organization> vs <organization abbrev="IEEE">Institute of Electrical and Electronics Engineers</organization>

As discussed with @rjsparks in https://github.com/ietf-ribose/bibxml-service/issues/18#issuecomment-982077903 , the new service does not necessarily guarantee identical content being served at the legacy path.
In this particular case, RFC 7991, 2.35 (<organization>) and 2.35.1 ("abbrev" attribute) state:
2.35.  <organization>

   Specifies the affiliation [RFC7322] of an author.

   This information appears both in the "Author's Address" section and
   on the front page (see [RFC7322] for more information).  If the value
   is long, an abbreviated variant can be specified in the "abbrev"
   attribute.

   This element appears as a child element of <author> (Section 2.7).

   Content model: only text content.

2.35.1.  "abbrev" Attribute

   Abbreviated variant.

Technically I would think that the following demonstrates correct usage of the RFC 7991 intent:
<organization abbrev="IEEE">Institute of Electrical and Electronics Engineers</organization>

Of course, if IETF wishes to only use the "IEEE" abbreviation instead of its full name "Institute of Electrical and Electronics Engineers", and thus omit the usage of the abbrev attribute, it is totally doable.
@rjsparks can we confirm this particular usage? Thanks.

I would like to further explain about the data differences between bibxml6 and the new IEEE bibliographic content from the IEEE database provided by @rjsparks .
In the two paths provided above, there are also other differences (old => new):

Link: <reference target=...> http://ieeexplore.ieee.org/servlet/opac?punumber=6178209 => https://ieeexplore.ieee.org/document/6178212
DOI value: 10.1109/ieeestd.2012.6178212 => 10.1109/IEEESTD.2012.6178212
Publication date: <date day="5" month="April" year="2012"/> => <date year="2012" month="June" day="26"/>
Keywords: the legacy content has no keywords but the new one contains multiple.

In addition, the new dataset contains ~9,900 items while the legacy dataset only contains 253.

I suspect that we could inform the IEEE about the inconsistency, and they would fix it.

@russhousley thanks for the suggestion.
In this particular case, the official IEEE data set is correct. The error was only from the legacy data set that will be replaced.
That said, there are many more errors in the official IEEE data set that we should report. We'll maintain that list as we go on (at least in the dozens if not hundreds).

From the RFC Production Center:

RPC prefers simply "IEEE" for the organization. (Rationale: commonly known by "IEEE".)
e.g. preference for output such as
[IEEE802.1Q-2011]
          IEEE, "Local and Metropolitan Area Networks -- Media
          Access Control (MAC) Bridges and Virtual Bridged Local
          Area Networks", IEEE Std 802.1Q-2011, August 2011.

Similarly, preference for "W3C" over "World Wide Web Consortium" in references to W3C documents.
Example of output from the existing citation library:
  [W3C.REC-xml11-20060816]
          Paoli, J., Sperberg-McQueen, C., Yergeau, F., Cowan, J.,
          Maler, E., and T. Bray, "Extensible Markup Language (XML)
          1.1 (Second Edition)", World Wide Web Consortium
          Recommendation REC-xml11-20060816, August 2006,
          <http://www.w3.org/TR/2006/REC-xml11-20060816>.

Better as:
  [W3C.REC-xml11-20060816]
          Paoli, J., Sperberg-McQueen, C., Yergeau, F., Cowan, J.,
          Maler, E., and T. Bray, "Extensible Markup Language (XML)
          1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816,
          August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.

Thanks @rjsparks for the clarification. In this case, should we still fill in the abbrev value? Or just leave it unset?

Yes, please go ahead and set it.

Thanks @rjsparks , the abbreviation issue is filed here: https://github.com/relaton/relaton-ietf/issues/48

As an update on this issue.
Current outputs are as follows, in red is https://xml2rfc.tools.ietf.org/public/rfc/bibxml6/reference.IEEE.802.11_2012.xml, in green is https://dev.bibxml.org/public/rfc/bibxml6/reference.IEEE.802.11_2012.xml, without whitespace and punctuation differences:
-<reference anchor="IEEE.802.11_2012" target="http://ieeexplore.ieee.org/servlet/opac?punumber=6178209">
+<reference target="https://ieeexplore.ieee.org/document/6171799" anchor="IEEE_802-11.2012">
  <front>
-  <title>IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications</title>
-  <author>
-   <organization>IEEE</organization>
-  </author>
-  <date day="5" month="April" year="2012" />
-  <abstract><t>This revision specifies technical corrections and clarifications to IEEE Std 802.11 for wireless local area networks (WLANS) as well as enhancements to the existing medium access control (MAC) and physical layer (PHY) functions. It also incorporates Amendments 1 to 10 published in 2008 to 2011.</t>
+  <title>IEEE Draft Standard for Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band</title>
+  <abstract><t>This amendment defines modifications to both the 802.11 physical layers (PHY) and the 802.11 Medium Access Control Layer (MAC) to enable operation in the 60 GHz frequency band capable of very high throughput.</t>
    </abstract>
  </front>
- <seriesInfo name="IEEE" value="802.11-2012" />
- <seriesInfo name="DOI" value="10.1109/ieeestd.2012.6178212" />
+ <seriesInfo name="IEEE" value="p802.11ad/d.6-0"/>
 </reference>

Basically, IETF BibXML service returns a different standard. It tries to retrieve most relevant document from our sources, given “802-11.2012” from filename. It uses a rough query probably similar to this, matching a few of similar standards, and guesses one of them. It is unclear to me which of the above standards is the one used on xml2rfc server.
To me it seems there are two separate issues:

Our our best-effort approach tries to return an up-to-date equivalent from our sources it returns a different standard than what xml2rfc path expected.
This has issues with complex standard identifiers and/or XML filenames. I don’t know how to address it except by abandoning fuzzy matching within bibxml6 directory and relying on manual mapping.

We might not have the requisite standard at all:

None of the standards we have use the same “punumber” as the one in xml2rfc response. Relevant query returns nothing.
Query by publication date, 5 April 2012 does not return any 802-11 standard.
I filed this in https://github.com/ietf-ribose/relaton-data-ieee/issues/8

@strogonoff - as Ron noted earlier in the thread, the right one to return the one with this in the footer in the results of your query results:
[IEEE 802-11.2012](https://dev.bibxml.org/get-one/by-docid/?doctype=IEEE&docid=IEEE%20802-11.2012&query=%24.docid%5B%2A%5D.id%20like_regex%20%22IEEE.%2A802-11%22%20%26%26%20%24.date%5B%2A%5D.value%20like_regex%20%222012-.%2A%22&query_format=json_path&page=1) 978-0-7381-7211-8 10.1109/IEEESTD.2012.6178212
Note that if you follow target="http://ieeexplore.ieee.org/servlet/opac?punumber=6178209" through the first http to https redirect, you get:
% curl -I "https://ieeexplore.ieee.org/servlet/opac?punumber=6178209" HTTP/1.1 302 Moved Temporarily Location: https://ieeexplore.ieee.org/document/6178212
The name of that document seems the closest in the set returned by your example query?

@rjsparks
Indeed, my bad… Yes, https://ieeexplore.ieee.org/document/6178212 is the one featured in https://dev.bibxml.org/get-one/by-docid/?doctype=IEEE&docid=IEEE 802-11.2012. I’ll look into adjusting fetching logic to match it more precisely.
Once BibXML service returns the correct document, the following issues will still remain to be dealt with:

Date mismatch. The document on xml2rfc specifies 2012-04-05 as publication date, but we don’t have that one. I’ll file that in
Author mismatch. I guess this answers my question in #100, according to xml2rfc output publishers should be serialized as authors.

This (https://ieeexplore.ieee.org/document/6171799) seems to be pointing to the Draft 6.0 of the document during balloting, not the final standard.  I hope that the standard (https://ieeexplore.ieee.org/document/6178212) is actually referenced.  Note that "IEEE Std 802.11-2012" is what actually shows on the cover of the document.

The latest update provides a management utility for checking xml2rfc path resolution:

It does not show an error because the automated resolver function doesn’t know the document is wrong. However, it allows to inspect the XML response and manually map the path to desired document ID (which in this case would be IEEE 802-11.2012).

Having done some extensive comparison of IEEE references, bibxml6 will require a manual mapping. Many of the previous references are incomplete or conflate draft documents with published documents, and vice versa. Whoever is doing the mapping will be required to compare titles and publication dates.

For the source for bibxml6/bib-ieee are you using just the dump from xml2rfc.tools.ietf.org? As the RFP noted, we had started building a newer resource based on a feed IEEE had provided us, and that should likely have been the basis for comparison. @russhousley @TonyLHansen  - would you spot check what you see at dev.bibxml.org to see if we should take the results of the alternate official feed from IEEE in lieu of previous work? Would it be ok for some older references to fail here, and have to be manually fixed up?

I put "802.11i" into the search box, and I got two hits. Not sure how that is possible. One includes an ISBN and DOI, but the other does not.

FWIW, one comes from bibxml2 (bibxml-misc) dataset, and the other from a Relaton repository (which is compiled from authoritative source and should be more complete and up-to-date).
The new service supports multiple bibliographic data sources, and sometimes it happens that more than one source provides a bibliographic item for the same document.
By design, items known to represent the same document are meant to be collapsed into a single item in search results (and once you open the page, you’ll still see both citation variants). In this particular case our data sources seem to not facilitate this behavior, which is probably an error.
cc @ronaldtse. If our Relaton sources provided identical primary identifier in both instances, they would show as a single document in the search results. However, we have case and possibly punctuation differences, so they display as multiple items in search.

I have just completed a mapping of the old bibxml6 dataset to the official IEEE dataset ("new" dataset), and also an investigation into the data of the bibxml2 dataset.

The IEEE entries in the bibxml2 dataset are a strict subset of those in bibxml6, so we should remove all IEEE references from bibxml2 to prevent duplication.
In the bibxml6 dataset, some documents cannot be mapped to the official IEEE dataset. This is for two reasons.

the official IEEE dataset, while containing nearly 10,000 entries, is incomplete and misses some data compared to the official IEEE website/webstore. There are a few documents of this type here.
the official IETF dataset comes with publicly published drafts. This means that a single document can appear in its different stages within the same query. As @strogonoff mentioned, the service attempts to link them into a single item whenever possible. However, there are two data quality issues: (1) the IEEE dataset is manually curated by IEEE and does not enforce these document relationships, a number of those drafts don't link properly. (2) the IEEE does not use a documented/defined convention for identifying drafts and draft stages, so there are many outliers.

Can we omit IEEE drafts? Probably not desired for legacy paths: in the mappings we have done, somehow, quite a few items in bibxml2 and bibxml6 point to drafts -- not published IEEE standards.

@russhousley has already mentioned that it's probably fine not to point to IEEE drafts, it I understood him correctly.

Yes, that is my view.

@russhousley @rjsparks yes I understand.
There are a few options for existing bibxml2 and bibxml6 entries:

The bibxml2 and bibxml6 entries that point to drafts should no longer resolve.
The bibxml2 and bibxml6 entries that point to drafts will point to the published versions.
Serve old bibxml2 and bibxml6 entries for the drafts, but this is inconsistent with desired practice, i.e. we serve broken entries.

Which is the desired behavior?

A few notes:

everything in bibxml-misc (nee bibxml2) was created by hand based on need. If something needed to be referenced that didn't fall into one of the other bibxml repos, it would get added to bibxml-misc.
the intent of bibxml-ieee, bibxml-nist, bibxml-w3c, bibxml-3gpp, were all supposed to provide something that could be totally data driven AND based on official sources.

If bibxml-misc points to drafts for IEEE documents, that means that in the past someone needed to make such a reference in their document.
The real question is: Should that past need drive future abilities of bibxml-ieee?
A separate question: If IEEE were to remove a standard from their list, should we similarly remove our bibxml pointer for it? Or would it be better to keep a bibxml reference, but mark it somehow as withdrawn?

@TonyLHansen.  Good points.
Maybe the drafts in bibxml-misc should stay so the old documents will still work properly, and no new drafts will be added.
I think that an entry in bibxml-ieee, once populated, should remain.  That is, if IEEE deletes it from their files, we keep it as it was last seen.

That is, if IEEE deletes it from their files, we keep it as it was last seen.

The IEEE does specially mark a "deleted entry" so nothing is really deleted from the source dataset.
Instead of keeping the drafts in bibxml-misc, it might be wise to just map them to the authoritative "draft" entries in the authoritative dataset.
While the IEEE dataset does differentiate against "draft", "withdrawn", "approved", "reserved" statuses. However, IEEE standards are fast moving and they often go into "withdrawn" status, and as a result a document that cites it can go out of date fast, so we should not filter out the "withdrawn" ones. So I'm also averse from filtering away "draft" as it makes life a bit more unpredictable.

But I do understand that there are potential benefits of keeping only "approved" IEEE standards. However, this will also affect the other data sources. For example, citations to W3C standards are often to drafts. The NIST database will also be providing drafts.

Yes, IEEE has a 5-year review policy, and they often roll specifications into a "maintenance release" that obsoletes the full-approved standards that get merged.

As an update, problems in original issue description were addressed:

xml2rfc anchor formatting rules were updated to match legacy behavior more strictly (now we use docid with scope=anchor in Relaton data for formatting anchors, if available; falling back on first available docid if not, which if causes issues later can be reopened)
filenames are formatted as xml2rfc anchor
it was agreed that fine details in data can differ if Relaton source in question contains more complete data (e.g., organization abbreviation)

Additionally, some issues with data mismatch are supposed to be resolved by manually mapping Relaton docids to xml2rfc paths and/or updating auto-mapping logic in xml2rfc_compat.fetchers (see also https://dev.bibxml.org/static/docs/howto/adjust-xml2rfc-paths.html).

Data mismatch should be eliminated.

Many of XML files are now mapped to authoritative identifiers.
However, for most such identifiers bibliographic items are missing in bibliographic sources (e.g., relaton-data-ieee), meaning the service falls back to xml2rfc archive XML data verbatim.
As bibliographic items with mapped identifiers appear in sources, the service will return those bibliographic items serialized to bibxml instead.

See https://github.com/ietf-ribose/bibxml-service/issues/18#issuecomment-1166246395 for an HTML report on all bibxml6 paths with diffs.


Feature request: Reusable Linkit config options defined in files

I'm not sure if this feature request has been submitted already, but it would be incredibly useful to be able to define Linkit field configs in a file. And then be able to "assign" that config set when configuring a field. Having these centrally maintained configs would save a lot of time configuring things like available Section Sources, Asset Volume Sources, and supported link types.
This would be comparable to predefined Rich Text config sets, for example (minus the JSON), and would be stored in a linkit.php config file. Possibly as a multidimensional array of config sets that would define the available options to choose from when configuring a Linkit field.
I wouldn't want this to replace the manual config per field, but would be really nice to be able to define commonly reused configurations globally via a file.

I think this might be the old linkit repo!
I see an existing feature request here: https://github.com/presseddigital/linkit/issues/80


[Languages] How Function Components Differ from Classes in React

Proposed title of article
A practical guide on how react functional components differ from class components.
Proposed article introduction
While writing a React component we can either use a class or a function. By the use of sample code, I intend to lay out the differences between class and functional components.
As a kick starter, a functional component is essentially a JavaScript function which can accept props as an argument and return a React element. On the other hand, a class component would require you to perform an extension from React. It can therefore create a render function which can return a React element.
While evaluating performance, choosing whether to work with a class or a function does not matter or act as a measure, but rather what the entire code is aimed at achieving.
Key takeaways
-Differentiate between functional components and class components, syntax-wise.
-Observe and notice the differences while;
(i)Rendering functional and class components
(ii)Handling states in functional and class components
(iii)Implementing life cycle methods
-Understand how to choose between functional or class component.
Article quality
This tutorial will include code samples to ensure the differences are well illustrated.
References
Hooks at a Glance – React. (2021). Reactjs.org. https://reactjs.org/docs/hooks-overview.html
Tutorial: Intro to React – React. (2021). Reactjs.org. https://reactjs.org/tutorial/tutorial.html#making-an-interactive-component
The React Hooks Guide - Tutorials and Examples | KendoReact. (2021). Telerik.com. https://www.telerik.com/kendo-react-ui/react-hooks-guide/

Based on this search, this topic appears a bit over-saturated. Feel free to suggest another topic. Thanks


Exceptions: Take the ExceptionStackFrame per reference

This PR changes the type of exception handler functions. Instead of a *const ExceptionStackFrame, they now take a &ExceptionStackFrame as argument. The reason is that they require the pointer to be valid (they used to blindly derefence the raw pointer). So the old implementation was unsound, since the functions used to violate memory safety when an invalid pointer is passed.
A consequence of this change is that we should no longer modify the exception stack frame (since we have an immutable reference to it). And transmuting a & to a &mut is undefined behavior. So the last section of Returning from Exceptions (“Page Faults as Breakpoints”) becomes even more hacky. Therefore, this PR removes that section. Instead, we now test the iretq logic by entering an endless loop between the exception handler and the instruction accessing 0xdeadbeaf.

Cherry picked to better_exception_messages and returning_from_exceptions


fix: stop check canary

I don't know why but from today I receive the following errors in dev environment that did 500.
I comment the lines in diff and now work!
@fabiocicerchia PTAL
badge-poser-nginx   | <IP_ADDRESS> - - [03/Jan/2022:09:43:47 +0000] "GET /phpunit/phpunit/composerlock HTTP/1.1" 500 572 "http://poser.local:8001/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "-" CACHE[GET@@poser.local@@/phpunit/phpunit/composerlock]:1:-
badge-poser-nginx   | <IP_ADDRESS> - - [03/Jan/2022:09:43:47 +0000] "GET /phpunit/phpunit/d/daily HTTP/1.1" 500 572 "http://poser.local:8001/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "-" CACHE[GET@@poser.local@@/phpunit/phpunit/d/daily]:1:-
badge-poser-nginx   | <IP_ADDRESS> - - [03/Jan/2022:09:43:47 +0000] "GET /phpunit/phpunit/version HTTP/1.1" 500 572 "http://poser.local:8001/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "-" CACHE[GET@@poser.local@@/phpunit/phpunit/version]:1:-
badge-poser-nginx   | 2022/01/03 09:43:47 [error] 29#29: *74 lua entry thread aborted: runtime error: /etc/nginx/conf.d/lua/hook.lua:26: attempt to compare number with nil
badge-poser-nginx   | stack traceback:
badge-poser-nginx   | coroutine 0:
badge-poser-nginx   | 	/etc/nginx/conf.d/lua/hook.lua: in main chunk, client: <IP_ADDRESS>, server: poser.pugx.org, request: "GET /phpunit/phpunit/d/daily HTTP/1.1", host: "poser.local:8001", referrer: "http://poser.local:8001/"
badge-poser-nginx   | 2022/01/03 09:43:47 [error] 29#29: *73 lua entry thread aborted: runtime error: /etc/nginx/conf.d/lua/hook.lua:26: attempt to compare number with nil
badge-poser-nginx   | stack traceback:
badge-poser-nginx   | coroutine 0:
badge-poser-nginx   | 	/etc/nginx/conf.d/lua/hook.lua: in main chunk, client: <IP_ADDRESS>, server: poser.pugx.org, request: "GET /phpunit/phpunit/version HTTP/1.1", host: "poser.local:8001", referrer: "http://poser.local:8001/"
badge-poser-nginx   | <IP_ADDRESS> - - [03/Jan/2022:09:43:47 +0000] "GET /phpunit/phpunit/dependents HTTP/1.1" 500 572 "http://poser.local:8001/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36" "-" CACHE[GET@@poser.local@@/phpunit/phpunit/dependents]:1:-
badge-poser-nginx   | 2022/01/03 09:43:47 [error] 29#29: *80 lua entry thread aborted: runtime error: /etc/nginx/conf.d/lua/hook.lua:26: attempt to compare number with nil
badge-poser-nginx   | stack traceback:
badge-poser-nginx   | coroutine 0:
badge-poser-nginx   | 	/etc/nginx/conf.d/lua/hook.lua: in main chunk, client: <IP_ADDRESS>, server: poser.pugx.org, request: "GET /phpunit/phpunit/dependents HTTP/1.1", host: "poser.local:8001", referrer: "http://poser.local:8001/"

We can remove the dark canary logic right?

@fabiocicerchia PTAL


Add Datadog/swift-jsonapi to the implementations section

Add Datadog/swift-jsonapi to the implementations section.

@gonzalezreal thanks very much!