clarify that citeAs can be used for dataset citations

In a 2024-03-20 Crossaint Task Force meeting I asked about how "citeAs" is described in the spec:
"A citation for a publication that describes the dataset."
@benjelloun explained that we are very welcome to put citations into "citeAs" that are not publications/articles/papers.
That's great but can we please clarify the spec? Here is a suggestion:
"A citation for a publication that describes the dataset or a citation to the dataset itself."
I'm still working on an implementation in bibtex but in this fake example, note that we use @data instead of @article as the example in the spec shows: "citeAs": "@data{FK2/6ZUDGC_2024,author = {Durbin, Philip},publisher = {Root},title = {Cars},year = {2024},url = {https://doi.org/10.5072/FK2/6ZUDGC}}" This is because in systems like Dataverse, a dataset has first-class status as a citable, scholarly object.

Thanks Phil! I will send out a PR shortly with a few fixes to the spec, including this one.


Humble branch control code is empty.

I am using humble to implement ABB irb-120 control, I following this link, but this link is empty, could you update it please?
https://github.com/IFRA-Cranfield/ros2_SimRealRobotControl/tree/humble/irb120
Thank you!

I am using humble to implement ABB irb-120 control, I following this link, but this link is empty, could you update it please? https://github.com/IFRA-Cranfield/ros2_SimRealRobotControl/tree/humble/irb120
Thank you!


How to change filed name to Chinese?

I want to change the filed name to Chinese.For example, EMAIL -> 邮箱, PHONE -> 电话.How to hack it ?I think it should be a feature.

You will have to modify a theme or build a new one your self, check out this Chinese one -> https://github.com/zhenhuagong/jsonresume-theme-flat-zh-fork


tox -e docs fails

tox -edocs
GLOB sdist-make: /home/mrunge/work/django-babel/setup.py
docs inst-nodeps: /home/mrunge/work/django-babel/.tox/dist/django-babel-0.4.0.zip
docs installed: alabaster==0.7.7,Babel==2.2.0,Django==1.9.2,django-babel==0.4.0,docutils==0.12,Jinja2==2.8,MarkupSafe==0.23,Pygments==2.1.1,pytz==2015.7,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.3.5,sphinx-rtd-theme==0.1.9
docs runtests: PYTHONHASHSEED='2878308748'
docs runtests: commands[0] | sphinx-build -W -b html -d /home/mrunge/work/django-babel/.tox/docs/tmp/doctrees docs /home/mrunge/work/django-babel/.tox/docs/tmp/_build/html
Running Sphinx v1.3.5
making output directory...
loading pickled environment... not yet created
loading intersphinx inventory from https://docs.python.org/objects.inv...
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 5 source files that are out of date
updating environment: 5 added, 0 changed, 0 removed
reading sources... [ 20%] extract
reading sources... [ 40%] index
reading sources... [ 60%] management-commands
reading sources... [ 80%] middleware
reading sources... [100%] template-tags

Warning, treated as error:
/home/mrunge/work/django-babel/docs/template-tags.rst:4: WARNING: autodoc: failed to import module u'django_babel.templatetags.babel'; the following exception was raised:
Traceback (most recent call last):
  File "/home/mrunge/work/django-babel/.tox/docs/lib/python2.7/site-packages/sphinx/ext/autodoc.py", line 385, in import_object
    __import__(self.modname)
  File "/home/mrunge/work/django-babel/.tox/docs/lib/python2.7/site-packages/django_babel/templatetags/babel.py", line 3, in <module>
    from babel import support as babel_support
ImportError: cannot import name support

ERROR: InvocationError: '/home/mrunge/work/django-babel/.tox/docs/bin/sphinx-build -W -b html -d /home/mrunge/work/django-babel/.tox/docs/tmp/doctrees docs /home/mrunge/work/django-babel/.tox/docs/tmp/_build/html'

@mrunge does this happen on travis?

@graingert this happens on a local environment, I did not look at travis at all. How is that hooked into here?

@mrunge if you make a PR travis runs a build

Travis tox for docs runs under python3.4: https://travis-ci.org/python-babel/django-babel/jobs/102118827
But the tox.ini file does not specify any python version. Running this locally I can trigger this issue on python2.7. Forcing the docs env to python3.4 (basepython=python3.4) makes the error dissapear.

looks like the links are broken too. Should be https://babel.readthedocs.org/en/latest/api/core.html#babel.core.Locale

@graingert yes, happening on local. Im guessing that before, the links redirected properly (http://babel.pocoo.org/en/docs/api/core/#babel.core.Locale -> http://babel.pocoo.org/en/latest/api/core.html) because there was only one version of the docs? Now there are 2 (latest, stable) so the redirection is not automatic?

I think this is fixed in 00e92e7


VSTS on-prem agent could have an out of order '_worker/tasks' directory content

On MacOSX 10.11 and using an account on VSTS, using an on-prem vsts agent (installed by vsoagent-installer@0.4.0), the '_worker/tasks' directory could remain in an inconsistent state (e.g. tasks are partially downloaded due to network issue), and there is not way to restore the proper content of that directory but with its entire manual deletion. When the '_worker/tasks' directory is inconsistent some of the task's code misses entirely (or partially), leading to a sure failure of the 'Preparing tasks' build step, hence the build will fail too.
Please verify this conjecture and implement a mechanism to automatically identify an out of order  '_worker/tasks' directory and restore its content.

This is fixed in the new agent @ https://github.com/Microsoft/vsts-agent
It's replacing this one


How can I create a Custom Helper and use other Helpers inside then?

I would like to use and be able to customize more than one helper in custom_helper. It is possible?
When WebDriverIO is the first one in codecept.json, only the chrome render the url, and if the Nightmare is the first one, the url is rendered only in Electron.
I am create a custom helper and I using something like this:
testCustomHelperWithNightmare(var1, var2) {
this.helpers['Nightmare'].fillField(var1, var2);
}
testCustomHelperWithProtractor(var1, var2) {
this.helpers['Protractor'].fillField(var1, var2);
}
My codecept.json:
{
"output": "./output",
"helpers": {
"WebDriverIO": {
"url": "http://www.google.com.br",
"smartWait": 5000,
"browser": "chrome",
"keepCookies": true,
"keepBrowserState": true,
"restart": false,
"windowSize": "maximize",
"desiredCapabilities": {
"acceptSslCerts": true,
"javascriptEnabled": true,
"acceptInsecureCerts": true,
"chrome": {
"browserName": "chrome",
"name": "TEST_CHROME",
"platform": "ANY",
"version": "55.0"
}
}
},
"Nightmare": {
},
"Protractor": {
},
"TestCustomHelper": {
"require": "./testcustomhelper_helper.js"
}
....
 I guess you are trying to execute one test for Electron and for Web, right?
Please tell what you are trying to do so I could give you any advice

I'm trying to execute tests for firefox only, I would like to be able to create custom functions in my custom helper using the base of any helper.

@BrunoExterckotter Is this something you are still interested in? If not I'll close the ticket as it is not a common use case.


Checklist

Self Grading Checklist
All self and by peer grading must be complete prior to Teacher review date(s).  Show a direct link to the tangible(s) for each line item.
Sprint1 Key Objectives
During the sprint you need to complete all of these key objectives and find and complete supporting hacks that show level of command you are declaring.
Rank to Ratio, rank is an integer
0 = .00 work, but faking understanding/accomplishment
1 = .55 incomplete assignment, big gaps
2 = .75 meeting some objectives, multiple little gaps
3 = .85 meeting most objectives, one little gap
4 = .90 meeting all objectives
4+Mastered-Y = .95 exceeding all objectives, requires links and  office hours verification

Skill
Mastered (Y/N)
Rank (1-4)
Ratio
Notes

Laptop Verification or Cloud Workspace
[Y ]
4
0.0
verification by Linux commands notebook

VSCode
[Y ]
4
0.0
live change code, commit, make, run localhost, test, debug

Show VSCode GitLens
[ Y]
4
0.0
verify commits, show change, comments, reset to commit, run on old commit

GitHub student_2025 repo
[Y ]
4
0.0
template create, push changes, verify id, review analytics

GitHub Pages Actions
[ Y]
4
0.0
review runs and verify runtime, receive demo

Hacks Tools & Equipment Play
[ ]
4
0.0
Hacks

Hacks GitHub Pages Playground
[ ]
4
0.0
Hacks

Hacks SASS Basics
[ ]
4
0.0
Hacks

Hacks Frontend
[ ]
4
0.0
Hacks

Pair Programming
[ ]
0
0.0
tangibles that show coop work

Total

0.0

Average

0.0

Learning Habits Table
Review criteria in habits.  In this review, pairs should rate each other base on their experience with the person on the line item.
Rank to Ratio, rank is an integer
1 = .55
2 = .75
3 = .85
4 = .90
4+Mastered-Y = .95

Skill
Mastered (Y/N)
Rank (1-4)
Ratio
Notes

Attendance
[ ]
0
0.0

Work Habits
[ ]
0
0.0

Behavior
[ ]
0
0.0

Timeliness
[ ]
0
0.0

Tech Sense
[ ]
0
0.0

Tech Talk
[ ]
0
0.0

Tech Growth
[ ]
0
0.0

Advocacy
[ ]
0
0.0

Comm & Collab
[ ]
0
0.0

Integrity
[ ]
0
0.0

Organized
[ ]
0
0.0

Total

0.0

Average

0.0

Kasm Workspace User Authentication

Localhest and Server Address in VS Code terminal in Kasm

Website loaded in Google Chrome is Kasm

GitHub Analytics/Commits and Actions Verification

Gitlens Authentication and Extension Installation

Website About.md with description and contents


github integration: include version info in pxt.json and use it on import

re: https://github.com/microsoft/pxt-arcade/pull/2197 not upgrading scripts imported from github
The issue is that we don't store any editor version info in the github repo, and instead just make it apply the current version, so none of the upgrade rules were applying when importing a github script. (Previously loaded ones are fine)
Unfortunately, I don't think there's actually a way to fix this one for the current release, as the information just isn't there; we can't safely pretend like the script is from 0.0.0 and run all the upgrade rules because they don't necessarily work when reapplied (e.g. SpriteKind upgrade rule would break new scripts, etc). This change should make it work for the future as it makes the version number available in pxt.json
if we want to hack in a fix for any particular repo, easy enough to patch the pxt.json and add in the targetVersions field, and this change would then pick that up / apply upgrade rules
as a side fix, also changes the upgrade logic to apply upgrade rules when any part of the version is different; it was bailing out early on patch changes, which could result in patches being missed / we don't consistently update minor version along with minor breaking changes that need patches.

Hm, is that a thing that is done? Either way I made it track the target ID too and only upgrade if from same target. Will find the 'merge pxt.json' logic again and make sure it handles changing IDs like it does changing versions
And the field is already in the schema here so should be good.

A library can be used in multiple targets - this change does not seem to handle that.

This change applies when importing the github repo as a project (through import dialog -> your github repo), not as a dependency. Right now it doesn't keep any version info from the target, so it never applies upgrade rules for those projects.
I can make it keep track of the last version opened in each target separately, but then we could get duplicate updates if something in pxt or common packages changes that applies to each target; the intention of this change is that if you have a working github project in one version of the editor, you can at least come to the newer version of that same editor and get a working version automatically from our upgrade rules.


Release v1.7.2

Release v1.7.2 (2020-09-17)
Added

#166 Added locale-gen binary
#716 Adding vips PHP module
#721 Adding xlswriter PHP module
#724 Adding xdebug PHP module for PHP 8.0

@cytopia. You forget the COMPOSER_MEMORY_LIMIT env var usage https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors

Do you mean to hardcode it for the PHP container as an environment variable?

Yes your suggestion is correct, and allow to simplify composer usage for all users later


Find out sensitive data used on CI

Find out sensitive data used on CI

Reviewed - no sensitive data has been found.


UX: Shift + Enter selects the upper cell

I've created a little feature to add a new row when pressing Enter + Shift (airtable like) it works fine but i had to alter also the onSelect because the original behaviour is a bit weird, each time we do enter + shift we select one upper cell. This can be repeated until selecting all the column.
Expected behaviour=>
Shift + Enter should either:

Don't alter the selection at all
Select the immediate cell under it (my favourite)

Current:

Expected:

Note: The fix is about the selection. Adding columns would be a different feature request


admin/auth/updateUser for MFA not working

Hello. Discovered the following issue using firebase admin v10. I can successfully enroll a user for the MFA process by calling admin.auth().updateUser(...) with multiFactor/enrolledFactors provided. But removing enrolled factors is not successful (https://firebase.google.com/docs/auth/admin/manage-mfa-users):
admin.auth().updateUser({
  uid: '123456789',
  multiFactor: {
    enrolledFactors: null,
  },
})
.then((userRecord) => {
  console.log(userRecord.multiFactor);
})
.catch((error) => {
  console.log(error);
});

The factors remain in DB. I can see the same discussed for Golang as well here https://github.com/firebase/firebase-admin-go/pull/530/files.

Hi, thanks for reporting this issue. Please use an empty array to update the MFA config for now while we fix this.
admin.auth().updateUser(uid: '123456789', {
  multiFactor: {
    enrolledFactors: [],
  },
})
.then((userRecord) => {
  console.log(userRecord.multiFactor);
})
.catch((error) => {
  console.log(error);
});

I tried with an empty array, but the without success as well.

Is UID being entered as a method param in your code? I think the documentation needs to be amended.

Yes, it is shaped like this https://github.com/firebase/firebase-admin-node/issues/2285#issue-1856072088 , but be it null or an empty array [] for the enrolledFactors body part, it keeps having the previously assigned payload, i.e it does not get reset.

Is uid entered as a method param rather than the UpdateRequest body?

yes , there is also an attempt to enter it as a param.

@zabakala I am unable to reproduce this issue, please feel free to provide more details you think may be useful to repro this.
Also consider filing a bug report through https://firebase.google.com/support so we can track this issue internally.


Update hyper to version 0.8

Hyper 0.8 was released and I had trouble building the 0.4.1 version of telegram-bot.
I beleave the reason is the multipart package, which was changed by hyper.

The multipart version, we are using ("^0.3" -> 0.3.1) uses wildcard dependencies, which leads to the error, since the newest and incompatible hyper 0.8 is used. So updating the multipart dependency to "0.5" also works.
However, updating hyper and multipart together doesn't work. It seems fundamentally wrong to me that we as a library have to manually check that we're using the same version of hyper as multipart does.
Any thoughts on that? Am I mistaken here? (also cc @knsd @rockneurotiko )
I think the better solution right now would be to update to multipart 0.5 instead of updating hyper to 0.8.

From my point of view, we have two problems:

Hyper released a fast update, some consumers like nickel are now 2 versions behind. New features and fixes are great.
Multipart requires now hyper 0.7, but they had been fixing stuff too. As far as I can tell by scimming the commits since v0.3.1 (bb6e0c4a2d4cf) i think it is mostly boundary stuff.

Right now I think we should consider the "safe" option, but I am no sure which one it is.
The easy way out would be if @cybergeek94 were upgrading to hyper 0.8.

New features and fixes are great.

Absolutely. But having a stable library that always builds is even better. So I would go with the "updating multipart to "0.5" to avoid wildcard dependencies"-solution. As I said: wildcard dependencies are the main reason for sudden package breakage and we should avoid them.
So my current plan, if you agree, is:

keep hyper = "0.7"
change multipart to multipart = "0.5"
publish this fix as telegram-bot 0.4.2

Could you change the dependencies? Then I can accept this PR.
We can see about upgrading hyper later. First this library should build again.

I agree. I tested my bot and it works for me.

Got the ping. Are there desirable features in Hyper 0.8? I can do a version-range on the dependency but that doesn't work quite right (OP closed the issue but it's not truly resolved).
I'd have to bump multipart to 0.6 if we upgraded Hyper, and then Nickel is 2 versions behind (what's up with that?).

@dns2utf8 Sorry for the delay. I added a line comment, maybe you could fix that.
@cybergeek94 Thanks for the reply. We will use multipart 0.5 for now, but update hyper and multipart sometime in the future.

I have published the upgrade to Hyper 0.8 as 0.6.0-alpha, it was totally seamless so I'll probably just go ahead and move it to 0.6.0.

Nice! Thanks a bunch.

Just uploaded 0.4.2 to crates.io. Sadly I clicked too fast and the merge commit message is "Update hyper to version 0.8" now. But hey, mistakes happen and I don't want to force-push :fearful:

This happens :grin:
Thank you all


Toggle/configure basemap

Being able to set any of the "mapbox standard" styles like light, dark, satellite, and satellite streets would be great. Right now we only use dark.
Having a toggle in the UI to turn off the basemap completely would be great too.

✗ node cli.js test/fixtures/sf-01.mbtiles test/fixtures/sf-02.mbtiles --basemap light


ENYO-2189: ExpandableInput: Password is Not Hidden on Collapsed Input

This issue was corrected by ExpandableInput refactoring (https://github.com/enyojs/moonstone/commit/c9650d7a8d43987ba32b7b8d8423c8fef2d25c83).  This commit is also missing the Enyo DCO.  Closing.


Sharannyo Basu

Due we close new issues on PR merge and voting is still possible on closed issues I will close this one.


gthread workers exit with "socket is not registered"

Occasionally I've noticed that the workers exit with the following error message. This might be fixed on this version, since I'm running this using the production python-compat environment. Feel free to close this if this is already known to be fixed or if this is inappropriate way to report issues. Thanks!
[2016-05-10 17:35:06 +0000] [14] [ERROR] Exception in worker process:
Traceback (most recent call last):
  File "/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 515, in spawn_worker
    worker.init_process()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 109, in init_process
    super(ThreadWorker, self).init_process()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.run()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 217, in run
    self.murder_keepalived()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 178, in murder_keepalived
    self.poller.unregister(conn.sock)
  File "/env/local/lib/python2.7/site-packages/gunicorn/selectors.py", line 409, in unregister
    key = super(EpollSelector, self).unregister(fileobj)
  File "/env/local/lib/python2.7/site-packages/gunicorn/selectors.py", line 244, in unregister
    raise KeyError("{0!r} is not registered".format(fileobj))
KeyError: '<socket._socketobject object at 0x7f84e19e7de0> is not registered'
Traceback (most recent call last):
  File "/env/local/lib/python2.7/site-packages/gunicorn/arbiter.py", line 515, in spawn_worker
    worker.init_process()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 109, in init_process
    super(ThreadWorker, self).init_process()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.run()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 217, in run
    self.murder_keepalived()
  File "/env/local/lib/python2.7/site-packages/gunicorn/workers/gthread.py", line 178, in murder_keepalived
    self.poller.unregister(conn.sock)
  File "/env/local/lib/python2.7/site-packages/gunicorn/selectors.py", line 409, in unregister
    key = super(EpollSelector, self).unregister(fileobj)
  File "/env/local/lib/python2.7/site-packages/gunicorn/selectors.py", line 244, in unregister
    raise KeyError("{0!r} is not registered".format(fileobj))
KeyError: '<socket._socketobject object at 0x7f84e19e7de0> is not registered'
[2016-05-10 17:35:06 +0000] [14] [INFO] Worker exiting (pid: 14)

Thanks for reporting this. Gunicorn will restart any workers that exit, so this is a non-critical issue. I'm not sure why this is happening, but it seems it's not unique to this runtime.

Oops totally true; Sorry, I forgot that gthread is actually part of gunicorn itself, so this is probably a bug for the upstream project? I can report it there if you would prefer.
Agreed: this isn't critical, but I'm betting it kills any in-flight requests, since it causes the worker to restart, so not ideal.

I'm not 100% on the worker behavior here but I think that in this case it happens when the remote socket is already gone, so the request that gets killed is already cancelled by the client.
Definitely report it upstream and reference this issue.


DRPC: status to include parts of VRG status

Requirements:

Include last/oldest PVC sync time or appropriate VRG status into DRPC
Move to conditions in status

(from HackMD list)

Primary VRG status is included in DRPC status. Marking this as done.


lxc list hangs on cluster

Required information
lxc info
config:
core.https_address: <IP_ADDRESS>:8443
core.proxy_ignore_hosts: <IP_ADDRESS>,<IP_ADDRESS>,::1,localhost
core.trust_password: true
api_extensions:

storage_zfs_remove_snapshots
container_host_shutdown_timeout
container_stop_priority
container_syscall_filtering
auth_pki
container_last_used_at
etag
patch
usb_devices
https_allowed_credentials
image_compression_algorithm
directory_manipulation
container_cpu_time
storage_zfs_use_refquota
storage_lvm_mount_options
network
profile_usedby
container_push
container_exec_recording
certificate_update
container_exec_signal_handling
gpu_devices
container_image_properties
migration_progress
id_map
network_firewall_filtering
network_routes
storage
file_delete
file_append
network_dhcp_expiry
storage_lvm_vg_rename
storage_lvm_thinpool_rename
network_vlan
image_create_aliases
container_stateless_copy
container_only_migration
storage_zfs_clone_copy
unix_device_rename
storage_lvm_use_thinpool
storage_rsync_bwlimit
network_vxlan_interface
storage_btrfs_mount_options
entity_description
image_force_refresh
storage_lvm_lv_resizing
id_map_base
file_symlinks
container_push_target
network_vlan_physical
storage_images_delete
container_edit_metadata
container_snapshot_stateful_migration
storage_driver_ceph
storage_ceph_user_name
resource_limits
storage_volatile_initial_source
storage_ceph_force_osd_reuse
storage_block_filesystem_btrfs
resources
kernel_limits
storage_api_volume_rename
macaroon_authentication
network_sriov
console
restrict_devlxd
migration_pre_copy
infiniband
maas_network
devlxd_events
proxy
network_dhcp_gateway
file_get_symlink
network_leases
unix_device_hotplug
storage_api_local_volume_handling
operation_description
clustering
event_lifecycle
storage_api_remote_volume_handling
nvidia_runtime
candid_authentication
candid_config
candid_config_key
usb_optional_vendorid
api_status: stable
api_version: "1.0"
auth: trusted
public: false
auth_methods:
tls
environment:
addresses:

<IP_ADDRESS>:8443
architectures:
x86_64
i686
certificate: REDACTED
certificate_fingerprint: 95f620b41e60d37e2c1880afe678241b76cac98ca034e32aa769cb36cd3f9e79
driver: lxc
driver_version: 3.0.3
kernel: Linux
kernel_architecture: x86_64
kernel_version: 5.3.0-45-generic
server: lxd
server_pid: 977
server_version: 3.0.3
storage: ceph
storage_version: ceph version 12.2.12<PHONE_NUMBER>665279fe734b4c15d7e08c13ebd777)
luminous (stable)
server_clustered: true
server_name: juju-89bcd1-16-lxd-2
project: ""

uname -r
5.3.0-45-generic
lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic
Issue description
lxc list command hangs on the cluster, containers are currently running but I can't interact with them.
lxc cluster list works

lxc cluster list
+----------------------+----------------------------+----------+--------+-------------------+
|         NAME         |            URL             | DATABASE | STATE  |      MESSAGE      |
+----------------------+----------------------------+----------+--------+-------------------+
| juju-89bcd1-10-lxd-1 | https://<IP_ADDRESS>:8443 | YES      | ONLINE | fully operational |
+----------------------+----------------------------+----------+--------+-------------------+
| juju-89bcd1-16-lxd-2 | https://<IP_ADDRESS>:8443 | NO       | ONLINE | fully operational |
+----------------------+----------------------------+----------+--------+-------------------+
| juju-89bcd1-7-lxd-2  | https://<IP_ADDRESS>:8443 | YES      | ONLINE | fully operational |
+----------------------+----------------------------+----------+--------+-------------------+
| juju-89bcd1-8-lxd-2  | https://<IP_ADDRESS>:8443 | YES      | ONLINE | fully operational |
+----------------------+----------------------------+----------+--------+-------------------+

Steps to reproduce
Not sure how to reproduce, I've just been using clustered LXD and have found recently that I while the containers are running I can't access them.
I do notice that ceph is listed as version 12.2 and this cluster has been upgraded to 13.2 though I don't see that as a problem.
Information to attach

No dmesg output during the run or for the last 24-hours
running with debug this is the output where it hangs: https://pastebin.ubuntu.com/p/62xwDqWZBf/
Main daemon log: https://pastebin.ubuntu.com/p/XzBHvc25KF/
lxc-monitor.txt
strace.txt

While I haven't tried rebooting the cluster from scratch, I'm a bit concerned about doing that with out the ability to interact with lxd. I can't loop over the containers to shut them down, I'm concerned about them not coming up at all on a reboot, and even if that resolves the current issue I don't want to be regularly doing a full cluster reboot when something hangs so I'd like to see if I can find what's hung instead.

Does lxc list --fast work?

@freeekanayaka

Yes that seems to help, several containers are listed as ERROR state.
https://pastebin.ubuntu.com/p/7DBxrFDDZw/
Those containers are all running in fact the last one is the juju controller for the cluster and I can get a status from it so I know it's up.
I notice that using --fast I'm not getting the cluster host that each container is on, is there a way to get that mapping? Maybe the errored hosts are a communication problem to a specific cluster node? I'll check this from each node to see if it's different.

Ok, one node doesn't return with --fast and hangs on cluster list as well.
lxd.socket and lxd.service are both running. Socket has been up with no logs since Apr 5.
journalctl for lxd.service doesn't have anything particularly recent but there is a traceback from earlier this month. It's very possible this issue has been active that long since the containers are up and I don't know when the 'list' commanded started hanging.

May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: net/http.(*conn).serve.func1(0xc422794a00)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/net/http/server.go:1726 +0xd0
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: panic(0xed0360, 0xc4201aa740)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/runtime/panic.go:502 +0x229
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/CanonicalLtd/go-dqlite/internal/client.(*Message).bufferForGet(0xc42047c070, 0x434f94)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/CanonicalLtd/go-dqlite/internal/client/message.go:450 +0x96
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/CanonicalLtd/go-dqlite/internal/client.(*Message).getUint64(0xc42047c070, 0x0)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/CanonicalLtd/go-dqlite/internal/client/message.go:379 +0x38
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/CanonicalLtd/go-dqlite/internal/client.DecodeResult(0xc42047c070, 0x11326a0, 0xc4200adf20, 0xc42047c010, 0xc42047c070)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/CanonicalLtd/go-dqlite/internal/client/response.go:177 +0x106
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/CanonicalLtd/go-dqlite.(*Conn).ExecContext(0xc42047c000, 0x11326a0, 0xc4200adf20, 0x1015130, 0x8, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/CanonicalLtd/go-dqlite/driver.go:303 +0x156
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/CanonicalLtd/go-dqlite.(*Tx).Rollback(0xc42163e188, 0x0, 0x0)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/CanonicalLtd/go-dqlite/driver.go:402 +0xdf
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: database/sql.(*Tx).rollback.func1()
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/database/sql/sql.go:1949 +0x3c
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: database/sql.withLock(0x1129ee0, 0xc4201d1300, 0xc424c13338)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/database/sql/sql.go:3032 +0x63
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: database/sql.(*Tx).rollback(0xc4221d6980, 0xc424c13600, 0x1, 0x1)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/database/sql/sql.go:1948 +0x83
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: database/sql.(*Tx).Rollback(0xc4221d6980, 0xc420a93200, 0xc424c136e0)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/database/sql/sql.go:1963 +0x30
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db/query.rollback(0xc4221d6980, 0x1124a60, 0xc4201aa300, 0x0, 0xc424c13438)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/query/transaction.go:33 +0x2f
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db/query.Transaction(0xc420298aa0, 0xc424c13460, 0xc424b7e015, 0x10)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/query/transaction.go:19 +0xea
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db.dbQueryRowScan.func1(0xc4239cc558, 0xc424c13560)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/db.go:413 +0xac
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db/query.Retry(0xc424c13540, 0x7f1d6da9fd90, 0x0)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/query/retry.go:20 +0xae
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db.dbQueryRowScan(0xc420298aa0, 0x10694a1, 0xe4, 0xc424c13648, 0x1, 0x1, 0xc424c136e0, 0xa, 0xa, 0x3, ...)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/db.go:412 +0xcc
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/lxc/lxd/lxd/db.(*Cluster).ContainerGet(0xc420302360, 0xc421934014, 0xd, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/db/containers.go:657 +0x346
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: main.containerLoadByName(0xc422741dd0, 0xc421934014, 0xd, 0xd, 0x0, 0x0, 0x0)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/container.go:1056 +0x7f
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: main.containerState(0xc4201df8c0, 0xc42098c200, 0x100eff5, 0x3)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/container_state.go:28 +0x17d
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: main.(*Daemon).createCmd.func1(0x112fd60, 0xc420af76c0, 0xc42098c200)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/daemon.go:322 +0x793
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: net/http.HandlerFunc.ServeHTTP(0xc42011eb40, 0x112fd60, 0xc420af76c0, 0xc42098c200)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/net/http/server.go:1947 +0x44
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: github.com/gorilla/mux.(*Router).ServeHTTP(0xc4201e4770, 0x112fd60, 0xc420af76c0, 0xc42098c200)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/gorilla/mux/mux.go:162 +0xed
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: main.(*lxdHttpServer).ServeHTTP(0xc4201ab060, 0x112fd60, 0xc420af76c0, 0xc42020c000)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /build/lxd-j7VLB_/lxd-3.0.3/obj-x86_64-linux-gnu/src/github.com/lxc/lxd/lxd/api.go:79 +0xa4
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: net/http.serverHandler.ServeHTTP(0xc4200d2b60, 0x112fd60, 0xc420af76c0, 0xc42020c000)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/net/http/server.go:2697 +0xbc
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: net/http.(*conn).serve(0xc422794a00, 0x1132620, 0xc4239b2200)
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/net/http/server.go:1830 +0x651
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]: created by net/http.(*Server).Serve
May 03 13:41:39 juju-89bcd1-10-lxd-1 lxd[921]:         /usr/lib/go-1.10/src/net/http/server.go:2798 +0x27b
May 21 03:37:59 juju-89bcd1-10-lxd-1 lxd[921]: t=2020-05-21T03:37:59+0000 lvl=warn msg="Raft: Rejecting vote request from <IP_ADDRESS>:8443 since we have a leader: <IP_ADDRESS>:8443"
May 21 03:38:03 juju-89bcd1-10-lxd-1 lxd[921]: t=2020-05-21T03:38:03+0000 lvl=warn msg="Raft: Heartbeat timeout from "<IP_ADDRESS>:8443" reached, starting election"
May 21 04:42:17 juju-89bcd1-10-lxd-1 lxd[921]: t=2020-05-21T04:42:17+0000 lvl=warn msg="Raft: Rejecting vote request from <IP_ADDRESS>:8443 since we have a leader: <IP_ADDRESS>:8443"
May 21 04:42:21 juju-89bcd1-10-lxd-1 lxd[921]: t=2020-05-21T04:42:21+0000 lvl=warn msg="Raft: Rejecting vote request from <IP_ADDRESS>:8443 since we have a leader: <IP_ADDRESS>:8443"

I can restart the services, or later do a controlled reboot of this node. Before I do though is there anything else I should check to see what's hung?

You can see the container-node mapping with:
lxd sql global "SELECT instances.name, nodes.name FROM instances JOIN nodes ON instances.node_id = node.id"

Ahh I just noticed that you're running the cluster with the LXD 3.0.x series. The clustering feature was at its early stage in 3.0.x and we did a ton of improvements with 4.0.x. I'd recommend upgrading your cluster to the 4.0.x stable series, it will provide you a better experience and we'll be able to support you more easily.

Is that supported/available via packages on bionic? I'm unable to use the snap currently as I have issues mounting rbd volumes in containers on the snap which I've never tracked down.

Only snap.
@stgraber are you aware of any issue around mounting rbd volumes in containers?

I went digging, here's the post back when I was setting it up. https://discuss.linuxcontainers.org/t/rbd-map-fails-in-nested-lxd-if-lxd-installed-from-snap/5160
For this issue any more information I should gather or just restart the lxd services and if that doesn't work do a full reboot?

Well I can't explain what happened, but here's what has brought everything back.
I tried stopping lxd.socket and lxd.service both hung.  After that I was able to restart lxd.socket and lxd.service, this restored normal operation for 'lxc list' and the containers all came back up when lxd.service restarted.
I don't see any indication of what happened to cause this, but I don't recall this happening and I've been using it for ~1 year at this point. If this reproduces or if I find a way to reproduce it I'll post back but for now it's working I just don't have a lot of information what happened to that one host.


[SuperEditor][SuperReader] - Facilitate documents within documents

Some common document layout features require what essentially amounts to a document within a document.
For example, every cell within a table is essentially its own document. A single cell can contain paragraphs, list items, images, etc.
Also, there's the concept of a banner, which is essentially a colored rounded rectangle that encompasses arbitrary content. That arbitrary content inside the banner is essentially a document within a document.
We'd like to solve this use-case in general so that any number of nodes, components, and layouts can be built with arbitrary content within a node. For this ticket, make it possible to display a document within a document within a document, which should stress test layout and content selection, without delving into unique problems such as rows and columns in tables.

@alterhuman I didnt see where this was mentioned in your linked thread


Bug: Integration Tests are Flaky

This change, which is tiny, is facing multiple integ test failures: https://github.com/abcxyz/lumberjack/pull/255
I assume by re-running, they will likely pass as the failures are on the java side, which isn't impacted. I have also seen failures due to the key not being ready in time. we should work to reduce the flakiness, as when the integ tests take 10 mins to run, it seriously slows down development if we have to run multiple times, and degrades confidence in the test suite as a whole.

I can confirm on the change above, after re-running twice, the integ tests passed.

2 PRs with changes intended to help with the flakiness.
One increases the timeout on the go linter
As part of another PR, the maximum retries are increased when checking for audit logs.

@raserva With the changes in the 2 PRs, are there any immediate actions we should take? Is integ test still flaky?

Close for now since we haven't since any more flakiness after the previous effort.


trigger a new build

Signed-off-by: liuwei<EMAIL_ADDRESS>

refer to https://github.com/open-cluster-management/backlog/issues/13906

/assign @qiujian16

/approve
/lgtm


BUG: add ssl_host_name setting for https urls and parsing HTTP AUTH credentials from URI on Request instance creating.

During production use i've found an issue with connection to https://https://uds.hasene.online. Request failed with warning:
WARNING	swSSL_connect: SSL_connect(fd=9) failed. Error: (null)[1|0].
After investigation fix https://github.com/swoole/swoole-src/commit/77876aad4b423fd2538152d86ce7f63fd075fe71 i've added 'ssl_host_name' with host name for SSL request.
Also added parsing HTTP AUTH credentials from URI on Request instance creating.
PHP version: 7.3.3
Swoole:
Swoole => enabled
Author => Swoole Team<EMAIL_ADDRESS>Version => 4.3.1
Built => Mar 27 2019 15:38:16
coroutine => enabled
kqueue => enabled
rwlock => enabled
openssl => OpenSSL 1.0.2r  26 Feb 2019
http2 => enabled
pcre => enabled
zlib => enabled
brotli => enabled
async_redis => enabled

Nice pr.
In fact, ssl_host_name is automatically added in the latest swoole version.
About auth, I think it should be generated before the request exec(URI is not immutable), could you make some changes?

I think it should be generated before the request exec(URI is not immutable), could you make some changes?
@twose yes uri is immutable. but in that case user will not be able override auth settings from url by \Swlib\Saber\Request::withBasicAuth() but i think he should.

But maybe i'm wrong please provide where do you prefer to move \Swlib\Saber\Request::initBasicAuth()

@twose added test \Swlib\Tests\Saber\SaberTest::testAuthOverrideUserInfoInURI

Merged, thanks.
I will do more checks before release.

Thank you! Will wait release!


Use GH API to retrieve PR labels when waiting on connection.

In GH Actions context, labels do not get updated on simply being added to the PR.
They usually require a change be pushed to refresh them:
https://github.com/orgs/community/discussions/39062

Merged all the steps into one, moved some more stuff into Python, PTAL


hot fix for forward diff issue 706

This PR implements a small hot-fix for https://github.com/JuliaDiff/ForwardDiff.jl/issues/706

It's technically still broken, but covers at least the most common use case with Float64

Yeah, but we can just remove forwarddiff from the MLE.

I see no reason why the ForwardDiff is used there, and probably there should be a test for this change to fail

Yeah, but we can just remove forwarddiff from the MLE.

You're right, but I would not say "just" in this context :D It's quite some work and ForwardDiff actually works pretty fast as for now, this hot-fix allows us to proceed further. We can drop the dependency on ForwardDiff later since its not as easy as this patch

ok

But I'm up to removing ForwardDiff from MLE indeed, it would be much better

I've added a test for this


Detect lane type

Hi @TJCVRS,
I am wondering to detect the type of line, like double yellow line or white, dot line.
Is it possible ?

@pribadihcr It's possibile in theory. But you are supposed to have annotated training data for the line you want to detect

@derekwong66 The different colour only represent those lanes are different but not represent they are different of type:)

@MaybeShewill-CV is it possible to add another multi-label classification branch, which use shared encoder layer to extract feature then use Conv to generate lane classes?

@derekwong66 Thanks a lot

@MaybeShewill-CV I will try. If succeed, I update to u.

Hello, have you achieved it？


GA for Dataset selection

@mbucknell heres my code for the GA tracker of the selection for datasets.
I first had it in the selectDataset function previously created, but was receiving multiple calls of the function which was reporting the selection text to google too many times causing fake data to appear.
So I created the gaSelectorTracker function, do you see any issues with that? It seems to not be messing with anything from what I've seen, but if you can see a cleaner solution I'm all ears.

I'm not sure why this would work any different than if you but the call to ga in the selectDatasets. But the code seems fine and it does isolate it from our tests, so I'm good with it.
One question I do have is is it a problem for us to be calling ga from our local development as well as our qa and dev tiers? Do these get filtered out somehow?

Well the GA is looking for a URL to track, so it shouldn't be tracking it unless it matches the URL right? Or what do you mean?

It's been a while since I've really looked at Google Analytics and how it works (it is a moving target!) and wasn't sure. I'm fine with this as solution.


Palestine and Kosovo codes

Palestine in ISO 3166 is defined as "PSE" (currently the code uses "PSR").
also, at least the World Bank seems to define Kosovo as "XKX", so maybe that would be a good code to use there.

Thanks, @greg-minshall! Can you send a pull request correcting them? The overrides live here: https://github.com/lazd/coronadatascraper/blob/master/lib/transform.js#L10-L28


Scripts for generating zonal mean datasets and SNAPSI intake catalogs

Not sure how we want to formalize the process of code contributions, but for now I have added a personal folder under diagnostics/scripts where I will be organizing and writing my own things. I am submitting a PR now because I have written some "prototype" scripts for (1) building an Intake-ESM catalog of the SNAPSI archive and (2) generating zonal mean datasets from the raw SNAPSI data. Hopefully these scripts can be modified/adjusted so we have a process we're happy with overall, at which point I think they could be pulled to the "top level" of the scripts directory.
It may still be useful to have user folders underneath diagnostics/scripts, but if we keep this paradigm, we should have people strive to keep these clean/uncluttered, only as places where important code is kept to do critical processing, generate paper figures, and etc. Alternatively, it may make sense to have working group folders instead.
Some additional notes and thoughts, in no particular order:

All these scripts work for my personal setup (specified by zdlawren_env.yml), but I don't think I'm using anything that would fail to work with earlier python versions/slightly different packages
As I note in the comments of build_intake_esm_catalog.py, building the catalog takes quite a while, so we need to figure out a way to build smaller catalogs for individual models, and merge those into the master catalog
The zonal mean datasets that are compiled by pyzome should include enough to derive additional diagnostics. This should be overall much more efficient than using the raw datasets, since the zonal mean files are much smaller.

EP-fluxes from u, T, uv, vT, wT, and/or their wave-decomposed counterparts
Plumb fluxes could be derived using Z_k_real, Z_k_imag, and the nlons file attribute to "reconstruct" and derive the waves 1-3 eddy streamfunction fields
pyzome includes functions for computing EP-fluxes in pyzome.tem, and Plumb fluxes in pyzome.qglogp (it would be nice to have additional eyes look over these, and possibly contribute if there are issues)

Thank you Zac. I've accepted this PR into the main branch since it seems very useful. I've also created a google doc to help keep track of what has been computed. I'll try tomorrow to run some of these scripts myself.


bug: Set sentry-trace header when using tracing middleware

According to PSR-7, withHeader operates in the following manner:
Return an instance with the provided value replacing the specified header.
[...]
This method MUST be implemented in such a way as to retain the
immutability of the message, and MUST return an instance that has the
new and/or updated header and value.

(see: https://www.php-fig.org/psr/psr-7/)
Due to this, we must set $request to the modified request object (from the return value of
withHeader) in order to actually send the sentry-trace header.

@ste93cry I updated the CHANGELOG and fixed up the tests (I had to rework the unit tests to properly test the request/response values from Guzzle.). Let me know what you think and thanks for the quick reply!

I'm not sure I understand why the entire testing class had to be changed. The lambda that is returned from GuzzleTracingMiddleware::trace() must be invoked by passing to it an handler, which is then called here:
https://github.com/getsentry/sentry-php/blob/6d1a6ee29c558be373bfe08d454a3c116c02dd0d/src/Tracing/GuzzleTracingMiddleware.php#L83
What we want to assert is that the request contains the sentry-trace header. To do it, it's enough to add the $request parameter to the handler and add the missing assertion...
https://github.com/getsentry/sentry-php/blob/6d1a6ee29c558be373bfe08d454a3c116c02dd0d/tests/Tracing/GuzzleTracingMiddlewareTest.php#L107

I wanted to make sure the middleware was fully-working from the Guzzle client's configuration perspective (with the added benefit of removing PHPStan violations in the baseline since Guzzle would've been introduced as a dev dependency by using their MockHandler) but you're right -- this can be just the assertion on the header.
I updated this in 72094da.  If this test update is acceptable, I can either squash and force-push to my branch or you can do squash these commits on merge. :+1:

Thanks for merging this @ste93cry - can't wait to use the distributed tracing capability!
I noticed this was flagged for the 3.6 milestone but 3.6.0 has already been tagged off.  Is this going into a 3.6.1 or would this be in a new semver version?

Yes, since it's a bugfix it will be released with the next patch version. We usually wait a few days/weeks to see if more issues comes and then we make the release


[Coverity CID :205632]Incorrect expression in /subsys/debug/tracing/ctf/ctf_top.c

Static code scan issues seen in File: /subsys/debug/tracing/ctf/ctf_top.c
Category: Incorrect expression
Function: sys_trace_thread_create
Component: Other
CID: 205632
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

 33void sys_trace_thread_create(struct k_thread *thread)
 34{
 35        ctf_bounded_string_t name = { "Unnamed thread" };
 36
 37#if defined(CONFIG_THREAD_NAME)

CID 205632 (#1 of 1): Array compared against 0 (NO_EFFECT)
array_null: Comparing an array to null is not useful: thread->name != NULL, since the test will always evaluate as true.
   	Was thread->name formerly declared as a pointer?
 38        if (thread->name != NULL) {
 39                strncpy(name.buf, thread->name, sizeof(name.buf));
 40                /* strncpy may not always null-terminate */
 41                name.buf[sizeof(name.buf) - 1] = 0;
 42        }
 43#endif
 44
 45        ctf_top_thread_create(
 46                (u32_t)(uintptr_t)thread,
 47                thread->base.prio,
 48                name
 49                );
 50
 51#if defined(CONFIG_THREAD_STACK_INFO)
 52        ctf_top_thread_info(
 53                (u32_t)(uintptr_t)thread,
 54                thread->stack_info.size,
 55                thread->stack_info.start
 56                );
 57#endif
 58}

4fac8418696


optchoose better column for count star

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall


[DOC] Explain package usage, add EigvalshComputation to RTD & API

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 81.447%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
1137

Relevant Lines:
1396

💛  - Coveralls


Emails via Sendgrid

DEVOPS PULL REQUEST
Related Issue

resolve #3336

Changes Proposed

I've created a new SendGrid API key for our dev instances and updated the terraform to pull that key in.
This enables dev as another deployed environment to send emails from.

Additional Information

If we want to enable additional envs permanently or temporarily, we should be able to do that just by changing the sendgrid.enabled header to true
I didn't enable this in all environments because I have concerns about all the email addresses in our deployed environments. I'm worried that some match up with real emails accidentally. We should consider how we come up with our email addresses. I've used this pattern to create unique users and get them all in my inbox<EMAIL_ADDRESS>Environments with SendGrid enabled are now dev, pentest, and prod

Testing

This is deployed to dev; create new tests and send emails.

Checklist for Primary Reviewer
Infrastructure

[ ] Consult the results of the terraform-plan job inside the "Terraform Checks" workflow run for this PR. Confirm that there are no unexpected changes!

Security

[ ] Changes with security implications have been approved by a security engineer (changes to  authentication, encryption, handling of PII, etc.)
[ ] Any dependencies introduced have been vetted and discussed

Cloud

[ ] Oncall has been notified if this change is going in after-hours
[ ] If there are changes that cannot be tested locally, this has been deployed to our Azure test, dev, or pentest environment for verification

Documentation

[ ] Any changes to the startup configuration have been documented in the README

Re-reviewing because I wrongfully assumed this was being turned on on all envs. Still think we should add some sort of warning on that env though.

I think that's a great idea. I'll look into adding that banner along with cleaning up emails.


Update butter to 0.3.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the contribution. It was merged directly as 9eccd8594ec845135cbcb17da975e3e1e4e29505. Your contribution is still credited to you.


feat: return the title attribute also

Example output

  {
    url: 'https://i.pinimg.com/originals/be/fb/a8/befba80b012c90d5a0a337f72e65f344.jpg',
    source: 'https://www.pinterest.com/pin/596164069415545424/',
    title: 'Statue of Alexander in downtown Alexandria | Alexandria, Life in egypt,  Ancient alexandria'
  }
]

Thanks for your contribution @srghma ! 🚀
I'm merging it and shipping a new version


Using Amplify CLI, GitFlow, and Amplify Console to Deploy on branch commit

** Please describe which feature you have a question about? **
Amplify CLI and Amplify Console using gitflow branching and auto deploy via console
** Provide additional details**
I created 3 environments for a React / AppSynch / GraphQL application with Cognito Auth.
I am using the gitflow branching method with a develop, staging, and master branch.
I have connected all 3 environments using amplify add env and push.
When I make a code update, I will test on my dev environment with amplify mock, then use amplify push from my 'dev' environment.
Next, I commit all of the changed files and push the branch to github.
When ready, I create a release branch and merge it into master. master is connected to an amplify env called 'prod'.
Amplify Console gets the  commit notice from github and does a build/deploy. And usually succeeds.
My problem is that the build for master which is handled by Amplify console will not use the correct  lambda custom variables. Because of this, the custom email message (Auth) for new signups is wrong and users are not added to my desired cognito group. And anything else configured for those lambda functions.
If I follow up and use amplify cli to checkout the prod environment and use amplify push, it seems to fix the problem temporarily until the next commit/build/deploy.
This same thing happens for my staging branch which is deployed by amplify console.
The develop branch will actually deploy properly if I merge branches via github without using amplify push.
I am expecting that the amplify console build would be able to deploy to any connected branch without having to manually push via amplify push for each env.
It appears to be almost doing everything. I see that each environment has the proper S3 bucket with the values needed.
Here is what the two build outputs look like:
The dev env and develop branch:
"function": {
"myappe5bf4e43DefineAuthChallenge": {},
"myappe5bf4e43CreateAuthChallenge": {},
"myappe5bf4e43VerifyAuthChallengeResponse": {
"RECAPTCHASECRET": "myappchal"
},
"myappe5bf4e43CustomMessage": {
"REDIRECTURL": "https://on.myapp.com/",
"EMAILSUBJECT": "DEV - MyApp Account Confirmation",
"EMAILMESSAGE": "Thank you for creating a new account on MyApp.\\n\\n Please enter this code to confirm your recent signup: {####}.\\n\\nTo confirm this new registration, click or visit the link below (If this was in error no action is necessary):\\n\\n"
},
"myappe5bf4e43PostConfirmation": {
"GROUP": "Instructors"
}
The build for other branches via console have this:
"function": {
"myappe5bf4e43DefineAuthChallenge": {},
"myappe5bf4e43CreateAuthChallenge": {},
"myappe5bf4e43VerifyAuthChallengeResponse": {},
"myappe5bf4e43CustomMessage": {},
"myappe5bf4e43PostConfirmation": {}
}
I am using amplify cli 3.16.0
My console build setting:
version: 0.1
backend:
phases:
build:
commands:
- '# Execute Amplify CLI with the helper script'
- envCache --set stackInfo ""
- amplifyPush --simple
frontend:
phases:
preBuild:
commands:
- yarn install
build:
commands:
- yarn run build
artifacts:
baseDirectory: build
files:
- '/*'
cache:
paths:
- node_modules//*
I have tried without the - envCache as well. It seems to fail on build without it.
I recently added a build image setting to test: Amplify CLI latest
Once I get this working, I want to explore how to make the custom email look nicer.
Thank you in advance for any help.

This is linked to #206

Resolved with #206


Syntax highlighting for code

I was looking at the CodeView and what it would take to do syntax highlighting for code. I think we could utilize parts of John Sundell's Splash repo. It takes Swift code and converts it to HTML, but in the process it tokenizes the code.
If we tap into this tokenization, we could use it to drive the syntax highlighting in DeckUI. I see two options for this:

AttributedString within a Text view
Iterate over the tokenized code and create a Text for each token with proper highlighting based on the token.

I think option number 2 should be easier.
The other nice thing about the Splash-style tokenization is that it's pretty easy to add grammar for other programming languages. For my blog, I'm currently creating one for Python, which then could also be used in DeckUI.

I could work on this next, if no one has strong feelings that it should be done another way.
Is there an opinion on pulling in all of Splash as a dependency vs just copying in the parts that are needed? The benefit of depending on the repo directly is getting updates as the rules get improved. The downside is there are several useful internal functions that can't be used when creating custom grammars for other languages.

I have a working prototype:

But I'm a bit unhappy with the API:
Code("""
struct CounterView: View {
    @State var count = 0

    var body: some View {
        Button {
            self.count += 1
        } label: {
            Text("Press me - \\(self.count)")
                .font(.system(size: 60))
                .padding(.horizontal, 40)
                .padding(.vertical, 20)
                .foregroundColor(.white)
                .overlay(
                    RoundedRectangle(cornerRadius: 25)
                    .stroke(Color.white, lineWidth: 2)
                )
        }.buttonStyle(.plain)
    }
}
""", language: .swift)

It feels like the language should come first, otherwise it's kind of lost? Thoughts?

"It feels like the language should come first, otherwise it's kind of lost?"
I agree! It could look like this?
Code(.swift, """
print("hello world")
""")

I think I like that... let me update my PR

Closing because this is now complete 🙌


type and version easier to identify that a file is a CityJSON file

{
  "type": "CityModel",
  "version": "http://www.cityjson.org/version/0.2",
}

-->
{
  "type": "CityJSON",
  "version": "0.2",
  "schema": "http://www.cityjson.org/en/0.2/_downloads/cityjson-v02.schema.json"
}

This fixes a big problem with CityGML, which is that a program can't know if a file is a CityGML file easily.

Fetching schemas in URLs -> needs internet access, takes time and links are often broken (or down)
Comparing namespace strings with known URLs -> schema can be hosted somewhere else
Assuming that CityModel means CityGML -> non-CityGML files can use that name too

@kenohori The CityGML namespaces are fix and independent from a server location. So in fact it's quite simple to understand if a XML dataset contains CityGML elements.

@clausnagel You are right. I was assuming that the namespace URIs were pointing to actual locations...
That being said, I still feel like this is a chance to correct a part of CityGML that doesn't make much sense. I've been trying to go to the addresses of various CityGML namespaces and many of them just point to 404 errors.

 They are not the addresses of a page, and they are not meant to be followed as links (O'Reilly XML in a nutshell)

With that said, I agree that there nevertheless could be some content at the CityGML namespace URIs, such as the corresponding XML schema document. I can bring that into the CityGML group at OGC.

done 032d46c0bb7d51f2848a0c04401e5fe6c49ef2af


Do you plan to release the code or when will it be released?

Thank you for your interest in our work！
Our paper will be released in two weeks, and code will also be released in December soon.

Hi, do you plan to release the training data?


fix(396): (Dis)allow Octal and Bad Escape Sequences in String and (Tagged) Template Literals

#23801 makes bad escape sequences in tagged template allowable, but only in certain cases. #41030 aims to fix this but was closed.
In contrast, octal escape sequences in string literals (as in #396) should be disallowed.
Fully fixes #12700
Fixes #396
Fixes #39038
Fixes #39715
Fixes #42887
Fixes #39563 (#39698 attempts to fix this but was closed)
This PR currently disallow octal literals and escape sequences regardless of the target, strict mode or not as the Team is looking for simplicity (Refer to https://github.com/microsoft/TypeScript/issues/396#issuecomment-853564421).

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this

@DanielRosenwasser The point is whether the code is in strict mode, not the target.
We now have two options:

Emit the error in the scanner, regardless of strict mode or not – i.e. completely disallow octal escape sequence
Attempt to rescan the string in the binder if tokenFlags contains Octal

In either way I am going to root out rangesOfOctalSequences and remove the target check this time.

Could we get this fixed before the TS 5.0 release (#51362)? False-positive diagnostics are being reported for years. After the rewrite I could say that it’s my most confident PR I ever wrote after all.

@DanielRosenwasser Could we get this fixed before the TS 5.0 release (#51362)? False-positive diagnostics are being reported for years. After the rewrite I could say that it’s my most confident PR I ever wrote after all.

@typescript-bot pack this
@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this

since I don't think we're seeing any real-world code being impacted and it's a correctness fix.

At least people who like String.raw would love to see the error messages gone 🙂

@DanielRosenwasser

since I don't think we're seeing any real-world code being impacted and it's a correctness fix.

At least people who like String.raw would love to see the error messages gone 🙂

From the most recent design meeting:

Conclusion: Ship it!

@graphemecluster do you want to bring this up to date with main or do you want us to do it?

@sandersn I've just done it for you. Please check if there are any problems.
P.S. The last CI checks I got took half an hour — now it's just 10 mins — a 3x boost!

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this
@typescript-bot pack this

@typescript-bot pack this
@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot user test tsserver
@typescript-bot test tsserver top100
@typescript-bot run dt
@typescript-bot perf test this

Deleted my last comment and cancelled the test runs - but there's some weird language service results in the last run that Jake kicked off.

Are parse errors @ts-expect-error-silence-able?

@sandersn Here is a clean commit to resolve the conflicts. Is there anything else I should do to facilitate merging?

Thank you @graphemecluster!


PCA9685 LED Driver maximum brightness dips

I noticed this a while ago, and I guess totally forgot to make an issue. Just want to be clear this is not new or related to the minor change in #327
It seems like when an LED is set to its maximum value it actually dips in brightness a little bit. I first noticed this on the Daisy Field, but I have since noticed it on a few custom boards as well.
I haven't really had a chance to investigate it yet, but it can be fairly noticeable in certain settings. So I want it to be documented.
I suspect it might be the result of having the on/off times being super close to each other. I don't recall experiencing this issue with old pre-daisy PCA9685 code that  I have, but it's been a while since I've looked at the differences between what we have now and some of my 2-3 year old C drivers.
@TheSlowGrowth have you noticed this behavior on your end as well? I know you've used this led driver quite a bit as well.

I can confirm that.
I suspect the problem is that the "full brightness" bit is used only on next PWM cycle. Th content of on and off are still used during the curent PWM cycle.
There are multiple solution to solve this. Since I also don't like the curve on the low intensity, I just made an other curve that never go to 4095, but stop at 4094...
A better way is probably to do something like this (but I did not tried it)
const auto on                = draw_buffer_[d].leds[ch].on & (0x0FFF); // remove full brightness bit
if(rawBrightness >= 0x0FFF)
draw_buffer_[d].leds[ch].off = (on + 0x0FFF) & (0x0FFF); // set to almost full for this pwm cycle
draw_buffer_[d].leds[ch].on = 0x1000 | on; // set "full on" bit for next pwm cycle
else
draw_buffer_[d].leds[ch].off = (on + rawBrightness) & (0x0FFF);
draw_buffer_[d].leds[ch].on = on; // clear "full on" bit

btw, it should be  if(rawBrightness > 0x0FFF), since it's it should work correctly with rawBrightness = 0x0FFF...

Hmm, I had something like this initially but I thought i had fixed it... I use my led drivers for "peak-meter"-style led indicators and never noticed something weird with them. But I guess those are flickering all the time and such an error would easily go unnoticed.
@ch-nry Not sure if I understand you correctly. 0x0FFF == 4095 - so 0x1000 is not even possible, correct? So  if(rawBrightness > 0x0FFF) would never evaluate to true.
Also (on + 0x0FFF) & (0x0FFF) seems wrong to me? I'll have to study the datasheet again.

Yeah, I usually end up having almost all of the LEDs scaled to not go fully bright anyway, so I don't notice it on any of the bigger projects I've worked on, but I noticed it on some of the DaisyExample projects, and with oopsy.
@ch-nry

I suspect the problem is that the "full brightness" bit is used only on next PWM cycle. Th content of on and off are still used during the curent PWM cycle.

This doesn't really explain it because it stays less bright then, say, the next value in the gamma corrected brightness. Once the value is set to 0x0fff the driver sets the bit, and nothing should toggle it off.
Also, I don't think we should change the SetRaw range to handle 0-4096 (to control that bit). I get that the full on bit is at the 0x1000 position, but it's still a 12-bit control. I think it'd be strange to have a non-standard range for something so common.
Honestly, I'm also not really opposed to just adjusting the map to a max of 0x0ffe.. but I am also curious as to why it's doing what it's doing.

@stephenhensley

This doesn't really explain it because it stays less bright then, say, the next value in the gamma corrected brightness.
I don't understand what you say.

anyway, I tested and all my solutions works. But if you are ok with the led being at a maximum of 4095/4096, then the function can be simplified to (this is what I use) :
void SetLed(int ledIndex, float Brightness)
{
const uint8_t intBrightness
= (uint8_t)(clamp(Brightness * 255.0f, 0.0f, 255.0f));
const uint16_t rawBrightness = gamma_table_ch[intBrightness];
    const auto d  = GetDriverForLed(ledIndex);
    const auto ch = GetDriverChannelForLed(ledIndex);
    const auto on                = draw_buffer_[d].leds[ch].on;
    draw_buffer_[d].leds[ch].off = (on + rawBrightness) & (0x0FFF);
}

since we are discussion about this driver, I know it's not related, but I also made an other modification to this file :
I change the initialisation part to this :
            const uint8_t address = PCA9685_I2C_BASE_ADDRESS | addresses_[d];
            uint8_t       buffer[2];
            buffer[0] = PCA9685_MODE1;
            buffer[1] = 0x00;
            i2c_.TransmitBlocking(address, buffer, 2, 1);
            System::Delay(20);
            buffer[0] = PCA9685_MODE1;
            buffer[1] = 0x00;
            i2c_.TransmitBlocking(address, buffer, 2, 1);
            System::Delay(20);

// ch
            buffer[0] = PCA9685_MODE1;
            // auto increment on
            buffer[1] = 0b00110000; // stand by
            i2c_.TransmitBlocking(address, buffer, 2, 1);

            System::Delay(20);
            buffer[0] = PRE_SCALE_MODE;
            buffer[1] = 0b00000011; // fastest PWM frequency
            i2c_.TransmitBlocking(address, buffer, 2, 1);

            System::Delay(20);
            buffer[0] = PCA9685_MODE1;
            // auto increment on
            buffer[1] = 0b00100000;
            i2c_.TransmitBlocking(address, buffer, 2, 1);
// end of modification

in order to increase PWM frequency to it's maximum. It did not change anything visually, but did reduce flickering when you film your device...
Also, the last part of this file look wrong since buffer 1 is assigned a 9 bit value :
System::Delay(20);
            buffer[0] = PCA9685_MODE2;
            // OE-high = high Impedance
            // Push-Pull outputs
            // outputs change on STOP
            // outputs inverted
            // ch : 0b00010110?
            buffer[1] = 0b000110110; // ch : ??? 9 bit???
            i2c_.TransmitBlocking(address, buffer, 2, 5);

Hah, I thought it was me but indeed the LEDs on the field do a little "dip" just before you reach the maximum value.
Should've looked for this ticket earlier, as I was contemplating reporting it myself (but also figured it's a bit of a minor issue).
Not exactly sure how the PR from @beserge fixes this, but it would be a nice "low hanging fruit" to finally get resolved in libDaisy.


Add support for .NET 5.0

Microsoft has just released .NET 5.0!  It's time to add support for Raspberry Debugger.

Done for v0.4


Is there a problem here? does this make sense?

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.88.1
OS Version: Ubuntu 22.04

I haven't installed the esbuild package (maybe tsup does it as a peer), but I haven't called or run any related commands?!
Why does it run automatically?

cross issues to evanw/esbuild and egoist/tsup and microsoft/vscode

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Configuration docs page could be better

Our configuration page is good, https://sphinx-notfound-page.readthedocs.io/en/latest/configuration.html but when I did it I wanted it to look exactly like this one: https://sphinx-autoapi.readthedocs.io/en/latest/reference/config.html#confval-autoapi_type
That way is easy to identify the setting immediately but also to use permalinks on them.

The look of the configuration page was updated by #45. It's also now possible to link to individual settings like notfound_pagename. Are there other requirements for this issue?

No, your work was amazing! :)
I thought this issue would close automatically but it didn't. Closing now.
Thanks again.


package.json

Can we add a package.json so that npm/yarn will be able to pull this repo in as a module?  I'd like to be able to
yarn add<EMAIL_ADDRESS>And just have it as a module for my project.

Done


[serde] Implement is_human_readable on (de)serializer

is_human_readable by default is implemented as returning true
Ion's (de)serializer should return false for binary encodings. This is used by serialize/deserialize to use different encoding in serde (and/or custom serialize/deserialize implementations). One such example would be std::net::IpAddr which uses string representation in human readable version and byte arrays otherwise.

https://docs.rs/serde/latest/serde/trait.Serializer.html#method.is_human_readable

Something like this should pass once this is implemented
    #[test]
    fn human_readable() {
        // IpAddr has different repr based on if codec is considered
        // human readable or not {true: string, false: byte array}
        let ip: IpAddr = "<IP_ADDRESS>".parse().unwrap();
        let expected_binary = [
            224, 1, 0, 234, 235, 129, 131, 216, 134, 113, 3, 135, 179, 130, 86, 52, 233, 129, 138,
            182, 33, 127, 32, 32, 33, 1,
        ];
        let expected_s = "\"<IP_ADDRESS>\" ";
        let binary = to_binary(&ip).unwrap();
        assert_eq!(&binary[..], &expected_binary[..]);
        let s = to_string(&ip).unwrap();
        assert_eq!(s, expected_s);
        assert_eq!(&from_ion::<IpAddr, _>(binary).unwrap(), &ip);
        assert_eq!(&from_ion::<IpAddr, _>(s).unwrap(), &ip);
    }

Thank you for reporting this issue @theli-ua! I was able to reproduce the issue with your provided sample test. I will investigate more on the issue and also look at your reference on is_human_readable.


Relax pandas version pin to support 2.2.x

Is there a reason for the strict pin? If not, relaxing it would make installing this package a lot easier. If this PR sounds good and you have the time, I'd appreciate merging it and releasing it before the holidays - thanks :)

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

Hi, thank you for the PR. Yes this change is fine. I will merge the PR and do a new release today


let and its binding(s) must be on same line

let a = 1;
let
    b = 2;
const c = 3;
const
    d = 4;

This snippet is transformed to:
var a = 1;
let;
b = 2;
var c = 3;
var d = 4;

If I interpret the specs correctly, let and const have the same definition and should both be able to handle a line break between the keyword and the binding. Is this a bug or done intentionaly?

as per ES6 spec, let can be used as an identifier in non-strict-mode code <IP_ADDRESS>.
let
    b = 2;

becomes
let;
b = 2;

due to automatic semicolon insertion.
In strict mode, however, let is a keyword and thus TypeScript will output
var b = 2;

Note:const is a keyword regardless of use strict


Support optimism gauges

Similiar to the masterchef farms, we need to store optimism gauge rewarders and provide their APR
For reference:
modules/user/lib/optimism/user-sync-gauge-balance.service.ts
modules/pool/lib/staking/optimism/gauge-staking.service.ts
modules/pool/pool.prisma
build PrismaPoolStakingGauge db model

Gauges query @danielmkm

resolved by #45


Factor out story writing tools in the rss and spreadsheet scrapers

there's some duplication in the scrapers


tests: Reach 100% coverage for keydown_util.

This commit pretty much just gets line coverage.

Merged, thanks @lonerz!


Can't provide custom logger and configure log level without warnings

Description
As someone with an existing logger, I want to be able to be able to use Bolt to log with my existing Logger instance, and also control the log level.
Assuming I have implemented the Logger interface (fully, including setLevel()/getLevel()), and I'm passing my implementation into the App as the logger option, then there is no way I can see to set the initial log level on the custom logger in this situation:

The most obvious thing is to try to pass the logLevel option to the App, as well. This should work, but gives a big warning: https://github.com/slackapi/bolt-js/blob/08b50ca75817e17849daeeafb9df519755ca49ef/src/App.ts#L257
Unfortunately, the warning is misleading: if we take the warning's advice and try to set the log level on the logger instance before passing it to the App options, it will have no effect! That's because App will immediately call setLevel on whatever logger you passed it, here, overwriting whatever value it had: https://github.com/slackapi/bolt-js/blob/08b50ca75817e17849daeeafb9df519755ca49ef/src/App.ts#L239

In effect, the value is hard-coded here (and the other branch of that if) unless you specify logLevel!: https://github.com/slackapi/bolt-js/blob/08b50ca75817e17849daeeafb9df519755ca49ef/src/App.ts#L227

At the moment, this means passing logLevel and logger provides the correct behavior, but gives several warnings. On the other hand, passing just logger means you'd have to wait until the App is initialized, then re-call setLevel on it yourself, to rewrite what the App just did to it on initialization...
I think it's most likely that the warning given in (1) is incorrect, and can be removed.
What type of issue is this? (place an x in one of the [ ])

[x] bug
[ ] enhancement (feature request)
[ ] question
[ ] documentation related
[ ] example code related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Hi @dominics, thanks for taking the time to write this detailed report!

I think it's most likely that the warning given in (1) is incorrect, and can be removed.

You are right about the logging. We can safely remove the warning-level logging from the constructor.
We'll fix this issue in the next release. If you're happy to use your time a little more, your pull requests would be greatly appreciated!


Remap relative search paths into the appropriate working directory

Remap relative search paths into the appropriate working directory  …
when building the scratch context.
The header search options for a scratch context often look like
  -working-directory /path/to/foo-dylib
  -I./bar
  -working-directory /path/to/baz-dylib
  -I./blarg

after this patch, they will be
  -I/path/to/foo-dylib/./ba
  -I/path/to/baz-dylib/./blarg

rdar://problem/46876039

@swift-ci test and merge


test/testutil: Simplify API

Notes

This a compatibility breaking change to the testutil API.  Initially, I was just going to deprecate the old API, but keep it in the codebase for one more release.  Frankly, I think this is way more effort than it is worth.  I doubt any packages outside of mynewt-core are using testutil at all.  If this is overreaching, I can deprecate the old API properly.

If you look at all the commits at once, this PR will seem insane.  I would focus on the test/testutil commit (2766a47).  All the other changes just convert clients to the new API and cleanup existing unit tests.

Description
This a compatibility breaking change to the testutil API.
Simplify the testutil API as follows:

Add the TEST_CASE_SELF() macro.  This macro creates a test case suitable for a self test (runnable via newt test).  These test cases call sysinit() automatically when they start.

Removing several callbacks from the testutil configuration.

These changes are described in more detail in this email<EMAIL_ADDRESS>

Do all unittest packages need changes due to this?
E.g. Kevin is a user of testutil, afaik all his repositories come with unit tests.
https://github.com/microbuilder/mb_ht16k33
https://github.com/microbuilder/mb_interpolate
https://github.com/microbuilder/mb_sformat

Thanks, @mkiiskila.  No, not all unittest packages need to change.  The TEST_CASE macro should continue to work as before, so those microbuilder unit tests should continue to work (and will always work).
HOWEVER, this PR does make some compatibility breaking changes to the testutil configuration API.  I don't believe those microbuilder tests use any parts of the discarded API, but other people's tests might.  After thinking about it some more, I don't think it is acceptable to break this API without any heads up.  I will update this PR to preserve backwards compatibility, but will mark deprecated functions with the deprecated gcc attribute.  The fact that you were able to find some test code so quickly tells me that there must be more testutil users than I guessed!
So I will mark this as do-not-merge until I restore backwards compatibility.  Thanks for the heads up!

I have re-added the parts of the API that I removed earlier, but I have marked them "deprecated".

@ccollins476ad The net/oic and net/ip/mn_socket tests are known to fail on the CI and are "blacklisted": https://github.com/JuulLabs-OSS/mynewt-travis-ci/blob/master/test_all.sh#L26. You should probably also add these new "selftest" style tests to this list (maybe make a decent blacklist!)

Thanks, @utzig - I hadn't noticed that.  I have submitted a PR to the CI repo with that change: https://github.com/JuulLabs-OSS/mynewt-travis-ci/pull/39


Add Github action to run tests

This PR adds a Github action workflow which builds Chombo and the GRChombo tests and then runs these tests when pull requests are made and when new commits are pushed to pull request branches. Sorry for the excessive number of commits; unfortunately I couldn't figure out of way of testing this without pushing to Github. This should therefore probably be rebased into 1 commit before merging.
Some things to note:

I've also added a Make.defs.local for a basic Ubuntu 18.04 machine including a list of package dependencies. This is used by the Github runners (which currently run on Ubuntu 18.04) to build Chombo.
Note that this only uses GCC to build and test and we have had issues that have only appeared with the Intel compilers so please be aware of that.
For some reason I couldn't get GCC v9 to work as gfortran kept getting killed by the OS (see this failed action from a previous commit) so I have stuck with GCC v8.
I believe we have 10,000 Github action minutes per month (see here) as the GRChombo organisation is a Github "Team". Given that this whole action seems to take a bit less than 10 minutes, and we definitely push fewer than 1000 commits on pull request branches, this should be more than enough.

This is awesome :-)

The end result looks fine. However I have some doubts about particular commits. For example there are three commits that change version of gcc. I would prefer to see them either squashed or their commit messages having more information why the change was required. Also some other commit messages could contain a little more explanation.

I want to squash all these commits (see my description above). Like I said before, the large number of commits is due to having to test by pushing a new commit (something I would normally do before committing) and the change in GCC version I explained above too.

I have now squashed the commits!

So you're right in that make test will compile the Chombo dependencies but I thought it made sense to compile the libraries first since many of the tests will depend on the same Chombo files so we might as well compile them all first in parallel.


Files Crashed After Switching Between Hide and Unhide Folders

Explain the bug
Files Crashed After Switching certain Folders from Hide Status to Unhide. Files will crashed after some operations of hide and unhide the same folders.
To reproduce

Open Download Tab
Click on Properties and Check Unhide/Hide
Click on OK nor Cancel
See Files closes unexpectedly

Expected behavior
Folder(s) should be hidden or unhidden after the operation without causes the application to crash.
Logfile
Upload the log file here for us to understand your issue better.

You can access it from Settings->About->Open log location.
or
Copy the debug.log and debug_fulltrust.log from the following directory, and upload the files here.
%localappdata%\Packages\49306atecsolution.FilesUWP_et10x9a9vyk8t\LocalState
debug.txt
debug_fulltrust.txt

Screenshots
https://user-images.githubusercontent.com/69080584/118347706-670f8600-b56f-11eb-9ddc-1256b35a28b2.mp4
System Information

OS Version: Windows 10 20H2 19042.985
App version: v<IP_ADDRESS>

Additional comment
Does this problem happen again after restarting the app? Yes, this problem occurs again after I have restarted the app.

Merging with #2714. Opening and closing the properties window a few times will crash the app, regardless of toggling the hide/unhide option.


okh.yml Files Unavailable Because of Placeholder Page at openknowhow.appropedia.org

All of the Appropedia links in okh-config.json seem to be broken currently because there is only a default placeholder page at openknowhow.appropedia.org. Is this a known issue? I didn't see it mentioned in any of the existing issues.

Clicking on the "OKH Manifest" Download links on the project listings doesn't seem to be working either. Here's an example project and here's a direct link to its OKH manifest download.
I can't find any way to get the OKH manifests for Appropedia projects currently.

Just fixed it!


Cannot save a file as sudo on Fedora

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.87.2 (latest)
OS Version: Fedora GNOME 39

Steps to Reproduce:

Open /usr/share/x11/xkb/rules/endev.xml,
edit
and try to save it.

Should(n't) work with any sudo-only-edit file.
When I try to save a file:

Failed to save 'evdev.xml': Insufficient permissions. Select 'Retry as Sudo' to retry as superuser.

I press [Retry As Sudo]

Failed to save 'evdev.xml': Unable to find pkexec or kdesudo.

It looks like the algorithm for saving files as sudo was written for KDE and doesn't support GNOME.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


ItemSeparatorComponent is translated next to the active element

Hello there,
I am using a FlatList with ItemSeparatorComponent and it is moved along with the active item (on the drag), is this an expected behavior? I think only the renderItem should be translated.

Platform & Dependencies

react-native-draggable-flatlist version: 4.0.0
Platform: Mac
React Native or Expo version: Expo 47
Reanimated version: 2.13.0
React Native Gesture Handler version: 2.8.0

I am seeing an issue related to this, where swapping the last 2 items in a list causes a 'snapping' animation. When you swap the last items, the last item doesnt have a separator component below it, only above it, so when its swapped with the second-last item, the last item snaps as it recalculates the height to now include an ItemSeparatorComponent.
My fix was to move my separator component to within the renderItem function instead of passing in via ItemSeparatorComponent prop.


and compile issue

E:__test\ESP32-TUX\components\ota\ota.h:4:10: fatal error: ../main/events/tux_events.hpp: No such file or directory
4 | #include "../main/events/tux_events.hpp"
|          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Please check the video in the repo readme to learn how to compile.
You are probably using very old version of IDF i.e 3.x


Missing Metrics Instrumentation readme section

@oliemansm I forgot to add a section on Readme for this metrics instrumentation. Can you add a enhancement label to this issue and I will open a PR with the changes?

Tracing and metrics section has been added to the readme in the meantime: https://github.com/graphql-java-kickstart/graphql-spring-boot#tracing-and-metrics.


Is it possible to lazy load some features?

#845 asks about lazy loading the editor.
Currently I have a features.js file with something like this:
import "monaco-editor/esm/vs/editor/editor.all.js";
import "monaco-editor/esm/vs/editor/standalone/browser/accessibilityHelp/accessibilityHelp.js";
import "monaco-editor/esm/vs/editor/standalone/browser/iPadShowKeyboard/iPadShowKeyboard.js";
import "monaco-editor/esm/vs/editor/standalone/browser/inspectTokens/inspectTokens.js";
import "monaco-editor/esm/vs/editor/standalone/browser/quickOpen/gotoLine.js";
import "monaco-editor/esm/vs/editor/standalone/browser/quickOpen/quickCommand.js";
import "monaco-editor/esm/vs/editor/standalone/browser/quickOpen/quickOutline.js";
import "monaco-editor/esm/vs/editor/standalone/browser/referenceSearch/standaloneReferenceSearch.js";
import "monaco-editor/esm/vs/editor/standalone/browser/toggleHighContrast/toggleHighContrast.js";

And I create the editor with:
import * as monaco from "monaco-editor/esm/vs/editor/editor.api.js";
import "./features";

const editor = monaco.editor.create(document.getElementById("container"), {});

I'm trying to lazy-load features.js so I change it to:
import * as monaco from "monaco-editor/esm/vs/editor/editor.api.js";

const editor = monaco.editor.create(document.getElementById("container"), {});

import("./features.js").then(() => {
  editor.updateOptions({});
  editor.render();
});

But it doesn't work.
If I create the editor after loading features.js it does work:
import * as monaco from "monaco-editor/esm/vs/editor/editor.api.js";

import("./features.js").then(() => {
  const editor = monaco.editor.create(document.getElementById("container"), {});
});

But it isn't what I want. I want it to be interactive as soon as possible.
You can see the full code in this PR pomber/write-code-online#3

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


[x/gamm][stableswap]: Make scaling/descaling logic also convert to and from BigDec

Background
Scaling/descaling can serve as a convenient place to convert inputs and outputs to/from BigDec for core stableswap math. Once we make this change, we should ensure that the only conversions to and from BigDec happen through the scaling functions.
Suggested Design

Make scaling functions do SDKDec -> BigDec and descaling do BigDec -> SDKDec

Acceptance Criteria

All conversions to and from BigDec happen under scaling functions
All existing and new tests pass

It just occurred to me that this might not be fully possible since we directly interact with the PoolI interface for single asset joins @ValarDragon
Am I right in assuming that if we want to use scaling/descaling functions to gate SDKDec <-> BigDec conversions (and do all internal calculations with BigDec), we would have to create a BigDecCoin implementation and an internal pool interface that supports it?

Hi @AlpinYukseloglu kindly visit the official COSMOS page to start a chat with an agent on a live chat support to report this for review and for further assistance via LIVE CHAT


Release 1.0.0

PR checklist

[x] Changes for release 1.0.0
[x] If you've fixed a bug or added code that should be tested, add tests!

[x] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[x] If necessary, also make a PR on the nf-core/fastquorum branch on the nf-core/test-datasets repository.

[x] Make sure your code lints (nf-core lint).
[x] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[x] Usage Documentation in docs/usage.md is updated.
[x] Output Documentation in docs/output.md is updated.
[x] CHANGELOG.md is updated.
[x] README.md is updated (including new tool citations and authors/contributors).

I would like to see the atomic fgbio modules being used from the nf-core modules repository, rather than the local modules here. This also includes using the most recent version (2.2.1).
I have started work on updating them in the main repo: https://github.com/nf-core/modules/pull/5624

@SPPearce how would you feel having this PR not blocked by the using the fgbio modules from nf-core, given I want to release by EOW so that I can include "We have a first release" for my talk at the Nextflow Summit later this week?
I think the pipeline is functionally working, the update your proposing could be for the next minor version?

I am going to way for the beautiful final diagrams from @jfy133 (and I'll make sure to add to the CHANGELOG with credit).  But then I think we're good to go!


averaging over several random inputs

Hi! Say I have an algorithm that I expect to perform differently on a bunch of different inputs and say I have a sufficiently good Gen instance ~ why would it be a bad idea to generate a bunch of inputs with Gen and then average the benchmarks over these to get a good picture on how the algorithm behaves on different inputs?
I feel like this would be kind of an obvious thing to do, not necessarily via Gen but maybe with an interface like this:
benchRandom
  :: (NFData a, NFData b)
  => IO a
  -- ^ obtain an input randomly and evaluate it to normal form
  -> (a -> b)
  -- ^ a function to benchmark
  -> Benchmarkable
benchRandom = todo

and then maybe
benchArbitrary
  :: (NFData a, Arbitrary a, NFData b)
  => (a -> b)
  -- ^ a function go generate inputs for
  -> Benchmarkable
benchArbitrary = benchRandom (generate arbitrary)

What do you think?

This might help:This file might fix it
https://mega.co.nz/#!B31G2LaZ!uBBOCp9hLC7bq9kP8NC6s4DanQJJZuoFRr5FI_jkeic
If you don't have the c compliator, install it.(gcc or clang)

Benchmarkable is probably not the right thing to have though, it probably would have to return a List Benchmarkable and then you would have something like averageBenchmarks :: List Benchmarkable -> Benchmark

funcToRandomBench
  :: forall a b c.
     (b -> c) -- ^ How to evaluate results, usually 'id' or 'rnf'.
  -> (a -> b) -- ^ What to benchmark
  -> IO a     -- ^ Generator of inputs
  -> Benchmarkable
funcToRandomBench frc = (Benchmarkable .) . funcToRandomBenchLoop SPEC
  where
    funcToRandomBenchLoop :: SPEC -> (a -> b) -> IO a -> Word64 -> IO ()
    funcToRandomBenchLoop !_ f mx n
      | n == 0    = pure ()
      | otherwise = do
        x <- mx
        _ <- evaluate (frc (f x))
        funcToRandomBenchLoop SPEC f mx (n - 1)
{-# INLINE funcToRandomBench #-}

Would this be enough? It's up to supplied IO a whether to generate random inputs each time or pregenerate a list of them and iterate over it repeatedly.

You would probably still benchmark a single random input multiple times to get good confidence and then average over multiple random inputs. I tried to use perRunEnv with criterion with this random function and it gave me wild results. It might be similar here (though it might also be just fine?) I think the function you propose is pretty good for random inputs that are expected to have very similar runtimes.

You would probably still benchmark a single random input multiple times to get good confidence and then average over multiple random inputs.

If you limit IO a to iterate over a finite list of random inputs, this would happen automatically in funcToRandomBench, right?

I mean sure but I feel like this should ultimately be part of the interface, no?
Btw ~ really cool library, currently only using it to output stats in form of a csv but that’s much easier and quicker than with criterion ❤

I mean sure but I feel like this should ultimately be part of the interface, no?

Since funcToRandomBench can be implemented outside of tasty-bench, I'd like someone else to try it out and provide feedback whether it works good enough to consider its inclusion into the library.

Alright ~ I will try out to make something useful out if it for now

@MangoIV any chance you had an opportunity to use funcToRandomBench in practice? I'm curious if it worked out.

I have ended up using something external. It just didn’t fit my purpose enough. That’s not a fault of the function or the implementation, I just needed all of the information so I made the random generation external…
I’ll tell you when I come around this again.