Bush growth / block family issue seen with fruit bushes in JS in multiplayer

Converted this to a full issue while doing follow-up testing for #3886 which fixed some block id issues / invisible blocks in certain cases (#2516) - but not everything, so we still have excitingly quirky bugs to hunt down!
The issue: When planting a seed in plain JoshariasSurvival (get with give joshaberryseed) multiplayer as a connected client the small bush starts out invisible (lower right window) yet a host player (upper left) can see the bush fine. After one growth stage passes both players can see the fully grown block-bush.

I am wondering if #3491 is related (plenty of good notes in there at least!). The BushAuthoritySystem in SimpleFarming is responsible for the logic and is set to RegisterMode.AUTHORITY which is as it should be. Works fine on a host/client session - which might also make sense. But something is failing to get back to a pure client. Even a 2nd pure client can't see the half-block bush as it exists right after being planted by another player.
If you try to plant then walk over the half-block as a pure client it feels like the client and server are disagreeing about what's there: the client attempts to simply walk through the block as if nothing is there, but then gets corrected by the server which knows there's a half-block in the space and moves the client's proper location up by a half-block.
Being that only the first growth stage is using a half-block maybe that's why? That's a different shape than the rest of the stages. So maybe that state is an issue, which could be more linked to #3491. In fact I can trigger the same behavior by simply doing give stone 15 halfblock from a client (given cheat rights) then attempt to place that block. In the world the block is invisible to the client (still fine for host) yet oddly in the inventory and hand it is fine.

Actually, yes, there's even logging to go with this! This snippet is from the client that attempted the above screenie. Maybe I shouldn't have started writing this issue until I was done researching, but I kept thinking up new things to try 😛
11:37:11.822 [main] ERROR o.t.w.b.internal.BlockManagerImpl - Missing id for block CoreBlocks:Stone:engine:halfBlock in registered family CoreBlocks:Stone:engine:HalfBlock
11:37:11.822 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,CoreBlocks:Stone:engine:halfBlock]
11:37:11.822 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Failed to register block CoreBlocks:Stone:engine:halfBlock - no id
11:37:11.822 [main] INFO  o.t.logic.console.ConsoleImpl - [CONSOLE] You received 15 blocks of Stone

Hello @Cervator  I believe I've tracked down the source of the issue.
When the Joshaberryseed is placed on right click, the block family at that point hasn't been loaded so it gets loaded by the block manager, and is then sent to the client (via NetworkSystemImpl.update line 319) for it to register the block family. Logs from the server:
18:46:07.756 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,JoshariasSurvival:BerryBush:engine:HalfBlock]
18:46:07.756 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered Block JoshariasSurvival:BerryBush:engine:HalfBlock with id 191
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.entitySystem.entity.internal.EntityInfoComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.world.block.typeEntity.BlockTypeComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}
18:46:07.757 [main] INFO  o.t.n.internal.NetworkSystemImpl - Component class org.terasology.network.NetworkComponent added to EntityRef{id = 13613, netId = 775, prefab = 'engine:blockType'}

When the he ServerImpl on the client side receives this it builds a map of BlockFamilys to register (a map with the uri as the key and the Integer id to register as the value) and sends that to the BlockManager (in BlockManagerImpl.processBlockRegistrations starting at line 344).
In BlockManagerImpl.receiveFamilyRegistration (starting around line 160) the client side manager first loads the blockFamily via it's own AssessManager. It then loops over the blocks in the loaded family and retrieves the corresponding id to register from the map using the uri of the loaded block.
The problem appears to be that the uri string don't match exactly. Here is the log output from the client after I added some log statements:
19:13:58.787 [main] INFO  o.t.network.internal.ServerImpl - BlockFamily from the server 'JoshariasSurvival:BerryBush:engine:HalfBlock'
19:13:58.791 [main] INFO  o.t.network.internal.ServerImpl - Constructed family-to-id map {JoshariasSurvival:BerryBush:engine:HalfBlock=191}
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - ShapeUrn engine:HalfBlock
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - shape engine:halfBlock Half Block
19:13:58.793 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Loaded family uri JoshariasSurvival:BerryBush:engine:halfBlock
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Checking map for blockUri 'JoshariasSurvival:BerryBush:engine:halfBlock'
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Retrieved id 'null'
19:13:58.794 [main] ERROR o.t.w.b.internal.BlockManagerImpl - Missing id for block JoshariasSurvival:BerryBush:engine:halfBlock in registered family JoshariasSurvival:BerryBush:engine:HalfBlock
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Registered BlockFamily[freeform,JoshariasSurvival:BerryBush:engine:halfBlock]
19:13:58.794 [main] INFO  o.t.w.b.internal.BlockManagerImpl - Failed to register block JoshariasSurvival:BerryBush:engine:halfBlock - no id
19:13:58.795 [main] INFO  o.t.network.internal.ServerImpl - Destroying entity: EntityRef{id = 3252, netId = 774, prefab = 'JoshariasSurvival:JoshaberrySeed'}

You may notice that the Constructed family-to-id map has JoshariasSurvival:BerryBush:engine:HalfBlock but the Checking map for blockUri checks for key JoshariasSurvival:BerryBush:engine:halfBlock, the h in halfBlock is a different case.
To confirm that this was the problem (or a sympton) I changed the map to use a lower case key

and that seems to have worked (left is server, right is client).

I know that's treating the symptom and not the problem, but I tried to figure out why the letter cases differed and unfortunately I haven't had much luck figuring that out. I thought I'd document what I've found so that someone with better knowledge in this area might be able to help. Hope this info is helpful.

@askneller wow that is pretty bad. we should probably just treat these as id's and any modifications to the string in the code-base should be avoided. might be worthwhile to check where else we do this and remove it.

Suspect code like this predates the existence of Name, incidentally.


Fix crash when generating thumbnails for certain texture types

Fixes #70974.
This is unlikely to be an acceptable fix for this, but I figured this could maybe start a conversation about what else can be done.
I'm able to reproduce the above linked issue in a fairly big project, even on latest master, which is c4279fe3e as of writing this. The repro is unfortunately not consistent at all. Sometimes I can start the editor dozens of time without any issue, with or without an existing thumbnail cache, whereas other times the crash can happen several times in a row. Everything seems to point towards a multi-threaded race condition of some sort.
The symptoms seem pretty straight-forward to me. The queued update of these texture types (although there may be more resource types like this) are sometimes called after the instance has been deallocated. I can say with 100% certainty that the instance has indeed been deallocated at that point, but I can't say exactly what allocated it, nor what deallocated it. Any attempts at logging stuff seems to add enough stalls that the race condition doesn't manifest itself anymore.
Seeing as how the ObjectID check in CallableCustomMethodPointer::call (seen here) should prohibit this from ever happening as long as everything's done on a single thread, it stands to reason that this is happening because another thread (like EditorResourcePreviewGenerator) is allocating these resources, thus scheduling the deferred call, and then happens to deallocate them right as CallableCustomMethodPointer::call is being invoked, after the above mentioned ObjectID check. The fact that this issue can also be reproduced by hovering over an editor tab seems to imply that EditorResourcePreviewGenerator is indeed the culprit, presumably EditorResourcePreviewGenerator::generate_from_path.
This PR fixes this in a somewhat brute-force manner, by simply allowing the resource instances to always outlive their deferred call, by bumping their reference counter for the duration of it. I have been unable to reproduce the crash with this PR applied.
If my diagnosis seems incorrect, or if there's a better fix, I'd love to know.
(I suppose it's also possible that this fix instead leads to memory leaks at shutdown if for some reason the message queue isn't flushed after one of these texture updates is queued up.)

I'm not sure about the safety of doing forced reference, it seems like a hack

It's most definitely a hack. I was hoping somebody could chime in with a better solution.

I suspect this is caused by the generation not doing proper thread safety, the freeing of the texture shouldn't happen on a thread, so something should be done about that side instead I'd say

As far as I can tell the allocation/deallocation is likely happening here:
https://github.com/godotengine/godot/blob/c4279fe3e0b27d0f40857c00eece7324a967285f/editor/editor_resource_preview.cpp#L62-L73
When that res reaches end-of-scope it prompts the deallocation, resulting in the potential race condition with CallableCustomMethodPointer::call.

Then that should probably be called on the main thread

If my diagnosis is correct then I'd assume that this has the ability to manifest itself in the actual running game/application as well, when doing something like background loading using ResourceLoader.load_threaded_request, so I'm not sure purely addressing EditorResourcePreviewGenerator is the right move.
But again, this hinges on me not having misunderstood the actual cause for this crash.

Although, I suppose ResourceLoader.load_threaded_request wouldn't ever cause a deallocation, because ResourceLoader would hang on to the resource until you call ResourceLoader.load_threaded_get. So the issue is less about the threaded loading and more about doing the deallocation on the thread I guess.

Using load directly on a thread isn't supported afaik, you need to use the threaded versions, hence them being there, can you see if it works if the operation itself is not done on a thread to to make sure it doesn't load on a thread

Using load directly on a thread isn't supported afaik, you need to use the threaded versions, hence them being there, can you see if it works if the operation itself is not done on a thread to to make sure it doesn't load on a thread

Currently, ResourceLoader doesn't care if the thread performing the load is the main thread, an arbitrary user thread or any thread spawned by itself.

A simpler fix for now would be to the resource previewer wait untill the main call queue is flushed before going on with the generation of the preview.

What would this look like exactly? I'm assuming you would need to block in EditorResourcePreviewGenerator::generate_from_path until some call_deferred flips some synchronization variable?

There's also potentially the issue that you can register your own custom preview generators in "user space", using EditorResourcePreview.add_preview_generator, which will similarly run on this dedicated generation thread, and which presumably can do the exact same thing of ad-hoc loading a resource and discard it immediately.

Something I stated here (or in private discussion) was inaccurate: #91630 will also affect these resources because the resource loader from now on will flush its own call queue in-thread instead of transferring to the main one. That means that the procedural textures will be generated as part of loading them, which should avoid the race condition.
@mihe Can you test if the issue is still a thing in current master, now #91630 has been merged?

@RandomShaper Does this apply even though EditorResourcePreview uses ResourceLoader::load rather than ResourceLoader::load_threaded_request? If I'm reading the code right your change would only apply to threads with MessageQueue::set_thread_singleton_override, which only seems to apply to the resource loader threads.
Maybe setting an override like that for the EditorResourcePreview thread would be an appropriate follow-up PR if that's the case, or perhaps switching over to ResourceLoader::load_threaded_request?

Ah, nevermind, I misread the code it seems. I see now that it calls set_thread_singleton_override for any non-main thread doing resource loading. That should indeed resolve the race condition. I'm clearly seeing it running the deferred call on the EditorResourcePreview thread as part of the loading, and I can't seem to reproduce the crash when trying out your PR.
I'll go ahead and close this then. Thank you!


Request to Package and Publish on PyPI

Hello,
First of all, thank you for your work on this project. I find it extremely useful, I was looking forward to an RNA secondary structure prediction program in Python!
Would it be possible for this program to be packaged and made available on the PyPI (Python Package Index)? This would make it extremely easily accessible, so it can be installed and used via pip. I'm asking this because I'd like to import SQUARNA into Python scripts and insert it into my workflow!
Packaging and publishing on PyPI would involve:

Creating a setup.py or pyproject.toml file to define the package metadata.
Ensuring all dependencies are listed in the appropriate configuration file.
Registering on PyPI and uploading the package.

Here are some resources that might help with this process:

Packaging Python Projects
PyPI User Guide

I would be more than happy to help you!
Please let me know if there is anything specific you need help with or if there are any steps you would like me to take.
I could also fork the repository, package it and upload it to Pypi or submit a pull request.
Thank you for considering this request. Please let me know if there is any way I can help in this process.
Best regards,
Luca Monari

Hi Luca!
Thank you for your request!
Yes, I was going to make SQUARNA installable with pip sooner or later. Now I will do it sooner, hopefully tomorrow :)
I'll let you know if I need any help, thanks again!

Hi Luca!
Done!
You can now install SQUARNA with pip, import, and run as a Python function, see:
https://github.com/febos/SQUARNA/blob/main/demo.ipynb
Currently, the Predict function does the same thing as the command-line SQUARNA.
Please let us know if it suits you.
Any other requests are welcome!

Thank you so much, I'll try it for sure!


Error logging during password reset

At line https://github.com/sahat/hackathon-starter/blob/master/controllers/user.js#L265 if the user.save failes, it doesn't look like if it gets exposed that the specific user.save is the cause of the failur, is it?  Should that line get broken up so errors from user.save can get logged in that spot?  Let me know if I am missing something.
Same with https://github.com/sahat/hackathon-starter/blob/master/controllers/user.js#L341

I would assume that the error would be passed into the promise chain and resolved when rejected, though I cannot be 100% certain. Perhaps kill your Mongo instance and trigger this function to test what happens, I'm curious to know too.

Tried it and got a 500 error in the browser:
**Connect**
500 MongoError: failed to reconnect after 30 attempts with interval 1000 ms
   at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
   at emitTwo (events.js:126:13)
   at Connection.emit (events.js:214:7)
   at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
   at Object.onceWrapper (events.js:315:30)
   at emitOne (events.js:116:13)
   at Socket.emit (events.js:211:7)
   at emitErrorNT (internal/streams/destroy.js:64:8)
   at _combinedTickCallback (internal/process/next_tick.js:138:11)
   at process._tickCallback (internal/process/next_tick.js:180:9)

And an error in the console:
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
MongoError: failed to reconnect after 30 attempts with interval 1000 ms
    at Connection.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/pool.js:318:15)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/mnt/c/temp/hackathon-starter/node_modules/mongodb-core/lib/connection/connection.js:189:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)
POST /forgot 500 31365.644 ms - -

Wow, that's interesting. Once we move to async/await the code here will be much cleaner and we can catch errors much cleaner. Do you think we should implement a fix in the meantime?

It might be duplicate effort, I looking to see if there are other places.

It looks like that all errors in the user controller are handled that way.  But  in the contact controller, if there is an error with sendMail it will flash the error message: https://github.com/sahat/hackathon-starter/blob/master/controllers/contact.js#L46
I would opt for closing this ticket in favor of better/more error handling when moving to move to async/await


Change of export of promiseMiddleware function to non default.

This is not a bug but a query
I notice you changed the export the function from the module.
Is there some reason to move away from the export default ? back to directly on exports ?
Change to exports instead of default export in v3.3.2
I am working in typescript, I created a minimal type definition to use redux-promise-middleware and it was exported with export default in 3.3.0 and worked fine.
I happened to update to 3.3.2 this morning and it caused errors, this happened because my typescript definition still said default export so dumbly pulls in the wrong thing and runs with no compile errors because my type definition is lying.
Just thought I would mention it, changing isn't a big deal, but mentioning the change in comments would be very useful to me.

Is there some reason to move away from the export default ? back to directly on exports ?

I've added release notes for version 3.3.2. This should clarify any questions you have.
I apologize for not posting the release notes easier. I published the release while at work and didn't have time to post these notes as well.
I'm going to close this issue. Please let me know if you have any other comments. 😄

Thanks for the clarification

@rluiten, would you mind posting the working type definition? I'm working with the DefinitatelyTyped version dated 2016-01-08T03:25:28.000Z (below). I'm getting an error at runtime, but I'm not experienced enough with TypeScript to fix it myself.
// Generated by typings
// Source: https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/e7df72296ea2a55f57ece35e28bb930ae93b19b5/redux-promise-middleware/redux-promise-middleware.d.ts
declare module "redux-promise-middleware" {
    function promiseMiddleware(config?: { promiseTypeSuffixes: string[] }): Redux.Middleware;

    export default promiseMiddleware;
}

This is whats working for me now.
declare module "redux-promise-middleware" {
    import { Dispatch } from 'redux';
    function createMiddleware(): Dispatch<any>;
    export = createMiddleware;
}

The change that matters is the export = line
So just change export default promiseMiddleware; to export = createMiddleware; in yours


Code Quality: Rename "Files.App (Package)" to "Files.Package" in the directory tree

Description
It's unnecessary and somewhat confusing to have the name "Files.App (Package)" in the directory tree (src). It should better be named Files.Package to match the configuration manager.
Concerned code
N/A
Gains

Better understanding of folder structure
Developer will understand the link between "Files.App (Package)" and "Files.Package" as it appears in the editor.

Requirements

Rename directory "Files.App (Package)" to "Files.Package"

Comments
No response

moving appxmanifest to another place would break the auto update

To rename, Files.App.Package makes more sense but we'd not rename or move until msixbundle is supported in the single packing project.

To rename, Files.App.Package makes more sense but we'd not rename or move until msixbundle is supported in the single packing project.

Yes you're right, like in FluentHub. However, that's how it currently is (Files.Package in Configuration Manager)

https://github.com/files-community/Files/pull/12475#issuecomment-1566150396

It's possible to publish a package from a single package project though, right?

Bundles aren't supported yet


Add outputs of comparison Retro vs JupyterLab to a11y repo

Summary

@gabalafou  already completed a nice comparison (see #68) this should be added to https://github.com/jupyter/accessibility to make it visible to the wider community and start building our docs
Acceptance Criteria

Merged into https://github.com/jupyter/accessibility

Started PR: https://github.com/jupyter/accessibility/pull/66

Merged so closing


Proposed code to create metadata files

When I use private data to train the mosquito task. My goal is to both show pictures of mosquitoes and if only use one important part to classify a certain type of mosquito. However, I find it difficult to code the metadata file myself. Do you recommend a solution to manually create the metadata file for custom data?

I have completed and perfected the custom training data as well as edited some information for image prediction and confusion matrix. Follow my github: https://github.com/GLOMQuyet/Mosquito_Classification/


Indexes

I'd like to add indexes to the forem tables. It also has the minor topics_helper change. Thanks!

Which version of bundler are you using?

bundler (1.0.21)


Interoperate with "pyenv global" Python version by default

Describe the bug
I would like to use pyenv global with pipx to install dbt-core==0.18.1b1 using py38, like so —
brew install pyenv pipx
eval "$(pyenv init -)
pyenv install 3.8.8
pyenv global 3.8.8
pipx install dbt-core==0.18.1b1

this does not work, perhaps because the python that pyenv uses is a shell script —
~ % which python
/Users/afedorov/.pyenv/shims/python
~ % cat `which python`
#!/usr/bin/env bash
set -e
[ -n "$PYENV_DEBUG" ] && set -x

program="${0##*/}"

export PYENV_ROOT="/Users/afedorov/.pyenv"
exec "/usr/local/Cellar/pyenv/<IP_ADDRESS>/libexec/pyenv" exec "$program" "$@"

instead we need to do —
pipx install dbt-core==0.18.1b1 --python 'python'

Which works, but can be confusing to folks on our team. This is not an enormous problem, but consideration and explanation of this functionality would be greatly appreciated.

Yes, we have been hoping to come up with a better solution for detecting the global default python automatically, but so far we don't have a great method. (See discussion in #638.)
One workaround that might be a little easier than using the --python switch for each install, would be to use the PIPX_DEFAULT_PYTHON environment variable.  If that's in your shell environment, pipx will use that python for all commands.
It is interesting that all you need to pass to the --python switch is the string 'python'.  I would've thought you'd need a full path.

I'm also using PIPX_DEFAULT_PYTHON without any issues. In the future another alternative will / might be providing a self contained pipx


k8s configuration wizard

Note that this adds a few configuration variables that are not yet actually used by the K8S plugin.
metaflow configure aws logic is unchanged, but the code is refactored a bit since I needed to reuse parts of that flow in metaflow configure eks

@oavdeev What is the expected user workflow with this change?


Integrate webhook server to api server

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:

Integrate webhook server to API server.
Solution:

Introduce oneblock-ai/webhook repo into API server.
Related Issue: https://github.com/oneblock-ai/oneblock/issues/8
Dependency PR: https://github.com/oneblock-ai/webhook/pull/1
Test plan:

The PR includes the webhook validator and mutator for the resource user as the example.
Apply the below YAML.
apiVersion: management.oneblock.ai/v1
displayName: test
isAdmin: true
kind: User
metadata:
  name: test1
password: test1
username: test1
---
apiVersion: management.oneblock.ai/v1
displayName: test
isAdmin: true
kind: User
metadata:
  name: test2
password: test2
username: test2

The user test1 will be created successfully and the webhook mutator will add the lable oneblock.ai/creator: oneblock into it.
The creation of the user test2 is rejected by the webhook validator because it has the same display name as the user test1.

[ ] correct go.mod after the dependency PR merged.


add number of reversions option

Ref: https://github.com/sindresorhus/vinyl-paths/issues/2
Only thing is its probably not the best use-case to demonstrate in the README.md. However I can't use double dest because the base would change in after the first dest(). https://github.com/wearefractal/vinyl-fs/pull/77

wearefractal/vinyl-fs#77 is merged and the added tests https://github.com/wearefractal/vinyl-fs/pull/79 passed. We could use double dest in the example (which makes more sense than the current one.).

We could use double dest in the example (which makes more sense than the current one.).

:+1:

double dest example needs to wait until vinyl-fs is released.

Looks good. Thanks :)


subsetting by multiple columns in pandas

Add the subsetting by multiple columns in pandas

[ x] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Closed and Reopened this PR to attempt to resolve a specific Travis build failure.


Transform certain POST endpoints to PATCH

Sticking to the guideline here, it's best to review the existing endpoints to see if PATCH is a better candidate for a method.

Possible candidates:

/projects/{project_id}/publish
/account/{email}/balance, that one's tricky. while it technically creates a new transaction, the name suggests that it edits the balance of the user.
/products/{product_id}/varieties/{variety_id}/purchase. also not sure. it's name doesn't implying creating anything, but it's also not editing anything

I'd say change the first two and keep the last one

I agree

Additionally, I think it will be better if the updated object is returned instead of NO_PAYLOAD

Disagree here. I mean, we've gone this far with returning the updated object on other modifications, though I felt from the start that this was redundant. The reason why I wouldn't want it here is because the modification done by those methods is so small and defined that it just isn't worth the bandwith and memory spent on it

I know it is small, but it is still useful for the frontend to ensure that the change took place, and to just take the new object from the response and put it entirely in place of the old one.

The frontend ensures that the change took place by observing the status code, which is 204, which is a success) as for the new object from the response, that's what I'm talking about. This kinda seems to me like frontend laziness, because I would update the object myself if I was to be writing the frontend. So I see no real use apart from letting the frontend slip one more time


[SSR] Toast: document is not defined

Describe the bug
next 中使用Toast动态更新方法提示
document is not defined
To Reproduce
Steps to reproduce the behavior:
git clone https://github.com/TinsFox/next-reavt-vant.git
cd next-reavt-vant
yarn && yarn run dev

访问http://localhost:7000/toast
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots

ssr场景下，动态更新失效


The VBO or VAO is support?

Hi,
I found this control that can't write .SwapBuffers();
Have a method to draw the mesh from buffer?

This is a general GL question; rendering/buffer swapping is controlled by WPF, rather than in the standard windowing-style approach.
You don't need to call that, it's done for you by the platform.


Article needs a major update

The Portal experience changed substantially, so this article would benefit from a top-to-bottom review and update. Some examples:

Networking tab is no longer present
Gen1 performance options are removed, at least in some/most regions
Sample data option removed
Restore Point data option added

etc.

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

ID: 90467e66-9062-01e3-6d40-fce8625d005b
Version Independent ID: 8db6b4e9-fd3a-8b45-1283-7f7144772a88
Content: Quickstart: Create and query a dedicated SQL pool (formerly SQL DW) (Azure portal) - Azure Synapse Analytics
Content Source: articles/synapse-analytics/sql-data-warehouse/create-data-warehouse-portal.md
Service: synapse-analytics
Sub-service: sql-dw
GitHub Login: @pimorano
Microsoft Alias: pimorano

@VitalyMCT Thank you for sharing feedback. We are actively validating it. We will share updates soon.

Hi @VitalyMCT ,
Thankyou for the ask. While creating dedicated sql pool directly from Azure Portal , I can still see :

Networking tab
Sample data inside Additional setting tab

When you try creating the dedicated sql pool from Azure Synapse workspace , the options are bit different which includes restore point . Please revert if you think the issue can be closed.

Hi @VitalyMCT ,
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


pep8_fixes

I was originally looking at issue #10 , porting scripts to support Python 2. When I loaded the project into PyCharm there were hundreds of PEP8 warnings so I thought I would jump on those first.
After running an inspection report, I used a mixture of PyCharm's automatic file reformatting and manual updates to get rid of a lot of the PEP8 issues.
Although there are some more issues that the inspection report raised (not only PEP8), I didn't want to do too much for this initial PR.

PR is good but number of commits are very high. Send another PR with no more than 2 or 3 commits. We appreciate your valuable contributions


show efcore method

Hi
I find this method in docs of efcore  but any where of this page dont show can do use efcore in xamarin
I think add link of ef core in xamarin to "Recommended content" or add note to show
Thanks
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bdcea465-138a-d586-5297-dc93370826b3
Version Independent ID: a41a6f67-0675-036f-0781-13b9165d3848
Content: Xamarin.Forms Local Databases - Xamarin
Content Source: docs/xamarin-forms/data-cloud/data/databases.md
Product: xamarin
Technology: xamarin-forms
GitHub Login: @profexorgeek
Microsoft Alias: jusjohns

Microsoft support for Xamarin will end on May 1, 2024 for all Xamarin SDKs including Xamarin.Forms. In preparation for this, all issues and PRs in this repository are being closed.
.NET MAUI is the replacement for Xamarin.Forms, and it's documentation can be found here.


Prepare for Kabanero Operator submission to community operators

Get the Kabanero operator into a state where we can decide to push to community_operators when necessary.
All of the dependent operators may not be available in community_operators, therefore testing should be done by building a private registry using operator_registry, which contains the versions of the operators we use:

openshift-pipelines
knative-eventing
knative-serving
knative-contrib (TBD)
appsody

Submission to community_operators requires testing on OpenShift 4.x.  Kabanero will not support 4.x but we can still test that the operator starts up OK there and that a Kabanero and associated Collection objects are created.  Our private registry may conflict with some of what is already available in the catalog, so some hand-tending may be necessary.  If we are using operators from the catalog, we should be sure that the version is appropriate.  (for example tekton-0.4 and tekton-0.5 have different CRDs)
We should ensure that the Kabanero description displayed in the OpenShift console makes it clear that Istio is required and must be configured manually.  We can link to those instructions.

Appsody operator Epic needed by Aug 16.

Note that the Knative Serving and Knative Eventing operators will be moving out of community operators into redhat-operators as well as a repackaging of those operators in the near future.
Also, everything in the community operators repo is expected to work on OpenShift 4 and will show up in every OpenShift 4 console. If Kabanero does not support OpenShift 4 then expect the submission to get rejected. From reading your docs it's not clear that Kabanero is tested on OpenShift 4.

As per discussion with Diana and Tim, this work was moved out from the Oct-7 release

We've decided not to publish this operator at community-operators.


Fix workflow HTML email

Closes #9932
I've enabled HTML emails by default for testing - otherwise quite a few templates are missed out during CI.
To test:

Set WAGTAILADMIN_NOTIFICATION_USE_HTML = True in your settings file
With one user, submit a page for review
With another user, approve the page
Check your terminal output - the approval email should have HTML

@tomkins should we find a way to run email tests as html and text for all of them?
Thanks for this fix though

Flagging as 4.2 milestone - code change is good - I just want another one of the core team to confirm the test settings change.

Was a little unsure on changing the setting, as it's the opposite of the default. Although the HTML sending is always just an additional bit of code for email, rather than an entirely different path.
I've tweaked a test and added a test for HTML emails on/off - as there were none before. Maybe that might help a little bit as well.

Cherry-picked to 4.2 in d36a6f4575450d764b9ad45dede53e277ad8f9b5.

Thanks @tomkins - really appreciate the solution here.
Thanks Sage for refining and getting this into 4.2


Asynchronous Reset?

Is there a methodology to support asynchronous reset? Just got feedback that companies doing ASICs only use asynchronous resets for power on resets of control logic state machines. I'd also really like to be able to use it for some more mixed-signal-y things.

In rocket-chip we've created a black box for asynchronous reset flops. Looking forward to parameterized black boxes so we can at least not have to wrap every single one...
Agree that we need this. I think there were already some open threads on it. My preference is to be able to state the reset methodology on hierarchical basis, not (just) per-register.

Agreed with @mwachs5 -- which suggests that it should be part of the solution to #205.

Is this not something that can be added as a FIRRTL pass right before Verilog emission? You'd be able to do it maybe @ the per-register level or module, etc. level (Transform granularity). Seems like doing it as a parameterized black box is a little overkill...

The parameterized black box is definitely a temporary workaround and not at all the desired solution.

Actually, what's the reason we can't just use something like asyncinit in Chisel? You just need to bring it down to the template for registering stuff and add an if before the posedge clk stuff...
Doesn't work with C++ testing, but should be perfectly acceptable with Verilator?

@aswaterman does that construct exist in Chisel3 now? I actually use enables a lot in my code... never bothered to formalize it.

Not yet... as with async reset, the main problem is finding the best API.  The nuts and bolts are easy.

I'm not sure what #205 has to do with this... is that what you really meant?

Typo, I meant #206

I revived parameterized blackbox support, it's in Firrtl now so is about ready for Chisel primetime

So, how's this coming along...?

It's the next item on @jackkoenig's docket!
On Thursday, December 15, 2016, Richard Lin<EMAIL_ADDRESS>wrote:

So, how's this coming along...?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ucb-bar/chisel3/issues/343#issuecomment-267438779,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7wv0zoNE9zl_MIu-2bPw7MpuSENuxks5rIaaIgaJpZM4KioUd
.

poke

Resolution: make any API-level changes in 3.0.0 (like using a reset type), the actual implementation can be delayed until later.

Hi, does it mean with Chisel, we cannot have asynchronous reset FlipFlop at this moment?

Async reset isn't available as a Chisel construct (yet).
A workaround is to black box it: wrap an async reset flip flop in a Verilog module, and instantiate that module in your Chisel code.

We discussed this at the dev meeting two weeks back.
The resolution was to add reset types (with an async reset type) to FIRRTL, where defregs would emit different based on the reset type. Casts could convert between relevant types.
Detailed discussion notes:

Asynchronous assert, synchronous deassert reset: a deassert synchronizer could be built on top of an asynchronous reset register primitive.

note that some synthesis tools only recognize the synchronous deassert type (posedge rst)

Chisel frontend options:

async reset type as a Reset subclass. All registers in its reset scope would be async registers. This lets the top-level control generation of all registers downstream, which is a common design style. However, it would be difficult if not impossible to determine the reset type in Chisel, since the reset object is not propagated through the module hierarchy, only connections are.
async reset register, where a new AsyncReg(...) (or something) would declare an async reset reg similar to how a Reg(...) declares a sync reset reg. Addresses some use cases, but does not allow top-level configuration of the global reset type.

FIRRTL implementation options: either the reset or registers could be annotated to be async. However, there may be dedup implications with a Reset type, since a module could generate differently based on whether it is in a sync or async reset scope. Other options include an async reset reg primitive.

Next action items: someone needs to write an RFC. @jackkoenig @azidar ?

If someone's putting together a Reset RFC could #938 be considered in it as well?

Front-end wise we could/should do both - for most flip-flops the reset might not explicitly matter, while certain circuits (e.g. async FIFO) may require AsyncReset registers.

For anyone reaching this page on Google, this has been supported since Chisel 3.2.


Configuration policy

The various KUKSA.val components as of today (Broker, Server, Kuksa-client, dbcfeeder, ...) today use quite different approaches to configuration. They typically support a combination of config-file, command line arguments and env-variables, but it is not consistently implemented and precedence is not always well defined and may differ. Supporting all 3 options (cli-argument, env-variable, config file) makes code somehwat complex as we then need to consider order of precedence
Would it be an idea to try agree on a general concept? And in the long run - or at least for new components - try to use the same principle for all.
Some ideas:
Config file "only"
No env-variables, as few cli-arguments as possible, typically only help, version and --config. Use a config file for the rest

Having a unified concept would be good.
Normally I am not a fan of environment variables, but those are a pretty common concept in the container landscape. Although a pattern might be, that the containers have some extra scripting to inject those into config files.

Supporting all 3 options (cli-argument, env-variable, config file) makes code somehwat complex as we then need to consider order of precedence

This might be true, but I think the more important question to ask is whether using our applications would get easier by any proposed change.
We implement the configuration handling once (and maybe we should look into more reuse between different applications), but users of our applications will configure them countless of times.

Some ideas:
Config file "only"
No env-variables, as few cli-arguments as possible, typically only help, version and --config. >Use a config file for the rest

Removing support for both environment variables and command line arguments would definitely make our applications harder to configure in a lot of use cases.

Although a pattern might be, that the containers have some extra scripting to inject those into config files.

Yeah, definitely not easier than the current situation. Editing a file is a lot more effort than either supplying a command line argument or an environment variable (and more permanent). And as Sebastian also points out, it's pretty much standard practice to inject configuration using environment variables in container environments.
However, config files are a great way to be able to configure default values. But it's only great if it's also easy to also override them.
Regarding priority, I think it's pretty well defined what every "posix sysadmin" would expect.
From highest to lowest:

command line arguments (overrides everything else)
environment variables
local config file
system config file (i.e. in /etc/)
default values

I have no problem with the "triple" approach. But do we want it for all possible configurations, or do we consider it OK to have cli-argument + env-variable only for configs we see as likely that someone wants to change or for all.

The problem is determining what a user wants to be able to change easily. But sure, that's a possibility.
Another way to look at it, is that if we make it easy (in our code) to support arg+env+config for an option, it would not be any harder to support all three.

I agree with the priority shared by John. That should also hold true if we decide to skip any of those options
I am not so sure, which options we should support to what degree especially around config/environment/commandline arguments.
Pretty clear to me

default values (as in compiled in code and used, if nothing else is found).
config file: We should have this. I don't think it is crucial at this point to have local/system config where the former extends/overrides the latter. Especially since a lot of our deployments are in containers anyway.

For command line arguments, there seem to be different patterns. You could - of course - enable everything in commandline, but I guess at one point it is hard to handle also for users (e.g. don't we all love thise programs where -h gives three screens full of text). I did look into how other "server-like" things are doing it, e.g.

dovecot: https://linux.die.net/man/1/dovecot that has basically only config file, a bit like Erik lined out above
nginx: https://linux.die.net/man/8/nginx  seems to be able to do anything, buy basically just putting snippets of config in the command line. That is surely "easy", and likely easy to implement, but not very "discoverable" and personally I don't like the optics of it

Definitely there are other examples, I dod not find a good example of something that has "real" commandline arguments for everything.
For environments variables, as I said, I am not sure, IF we have them, should effort be spent to "parse them in main code", also keeping in mind afair there are maybe not as good libs for parsing/type checking as you get when parsing "real" command line arguments or a config file.
An extreme example of the "Use environment variables to control a container environment" is docker-mailserver. This is the .env file example https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env (So basically everything you could "by hand" give via -e in docker). Obviously Postfix, Dovecot, ClamAV etc.are not all controlled directly by this, instead this contains a lot of scripting converting those env variables to whatever config (file) a given component uses.
Of course whether supporting ENV directly or "wrapping" them via scripts, it needs to be coded anyway if desired.
If you ask me right now (but I will read more comments :) ) it feels to me one would want

commandline arguments for a FEW common things
config files
(default values)

And maybe add env support for some things in containers, although question would be how far to go here. ("scope of cmd lne args? scope of config? in-between? Is that maybe confusing?)
My view is a bit split between a user (who would like ALL THE THINGS) and dev (how much can/do we want to implement/test) )
Also, while I think our providers for example should "feel" largely the same, I could see us making a different decision for databroker.

If you ask me right now (but I will read more comments :) ) it feels to me one would want

commandline arguments for a FEW common things
config files
(default values)

sounds reasonable to me.

We are about to archive this repo soon. If you consider this issue as important please file a new issue at one of the new Kuksa repos at https://github.com/eclipse-kuksa


#884 Add firewall, router, switch, hub to endpoint types.

Related Issue: #884
Description of changes: Adds firewall, router, switch, hub to endpoint types. We want to get this in before 1.1.

Should we have descriptions for Firewall, Switch, and Hub?

Should we have descriptions for Firewall, Switch, and Hub?

Good thinking. I added descriptions with links.

I removed UTM - per Cisco, a UTM is a specific type of firewall (along with 6 or 7 others). I think we should keep it to firewall, and talk to @pladam about maybe adding a way to specify the firewall type in the profile he is working.

We should add the different firewall types (e.g. NGFW, UTM) to the Security Control profile, we merged in the Firewall profile into that profile, adding the firewall_rule object, so it makes most sense there.

Looks great! I like how you added the links for further detail on each device type!


Fix typo in comment

There was a typo in the fix also, so I fixed it while doing other stuff.

doh! thanks for fixing :-)


Remove deprecated properties, networkChanged event, and send() net_version support

This PR removes properties that are not officially documented and should not have been exposed in the first place. It also removes support for the networkChange event and offline net_version resolution which will allow us to remove the last remaining chunk of networkId usage in Extension. These have all been properly deprecated, the most recent deprecations being 180 days old now.
Removes the following:

window.ethereum.chainId
window.ethereum.networkVersion
window.ethereum.selectedAddress
networkChanged event
net_version support in window.ethereum.send()

See: https://github.com/MetaMask/MetaMask-planning/issues/2195
See: https://github.com/MetaMask/metamask-improvement-proposals/discussions/23
See: https://github.com/MetaMask/MetaMask-planning/issues/2176

Total sidebar here but

null {id: undefined, jsonrpe: '2.0', result: '100'}

Wow looks like send doesnt generate an ID. I do like that its leaving it up to the client to deal with that.


Error in Prod only - PrismaClientInitializationError2 [PrismaClientInitializationError]: Timed out fetching a new connection from the pool. Please consider reducing the number of requests or increasing the connection_limit parameter (https://www.prisma.io/docs/concepts/components/prisma-client/connection-management#connection-pool). Current limit: 9

Bug description
Can't connect to an RDS instance with Prisma in prod
Note this I tried:
Prisma can connect to Heroku postgres
Connecting to pgbouncer, didn't work.
I tried upping the connection_limit query param to 25, 50, 10000, didn't work.
I tried increasing the heroku dyno to a [2x] 1gb size, didn't work.
I tried created a new pg RDS server on a different version of pg(10.16). Didn't work.
I tried running it on a Vercel serverless instance, didn't work.
How to reproduce

Create an RDS postgres db v12.1
Enable public connections on RDS
Attempt to connect via URL locally in dev, should work
Setup Env in heroku with exact same database url
Deploy heroku (also had this problem on Vercel)
Load page and it logs the info below in logs section

Expected behavior
Should work in prod as it does in dev. Not have an error. Maybe that error is incorrect?
Prisma information

package.json:
    "@apollo/client": "^3.3.9",
    "@prisma/client": "^2.17.0",

SCHEMA:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
    provider        = "prisma-client-js"
}

Environment & setup

MacOS (dev)
Heroku (prod)
Database on AWS RDS

Logs

021-02-19T21:18:45.134Z prisma:engine { cwd: '/app/prisma' }
2021-02-19T21:18:45.135197+00:00 app[web.1]: 2021-02-19T21:18:45.135Z prisma:engine Search for Query Engine in /app/node_modules/.prisma/client
2021-02-19T21:18:45.136250+00:00 app[web.1]: 2021-02-19T21:18:45.136Z plusX Execution permissions of /app/node_modules/.prisma/client/query-engine-debian-openssl-1.1.x are fine
2021-02-19T21:18:45.139105+00:00 app[web.1]: 2021-02-19T21:18:45.138Z prisma:engine { flags: [ '--enable-raw-queries', '--port', '39892' ] }
2021-02-19T21:18:45.163934+00:00 app[web.1]: 2021-02-19T21:18:45.163Z prisma:engine stdout Starting a postgresql pool with 9 connections.
2021-02-19T21:18:50.174574+00:00 app[web.1]: 2021-02-19T21:18:50.174Z prisma:engine stdout Encountered error during initialization:
2021-02-19T21:18:50.175349+00:00 app[web.1]: 2021-02-19T21:18:50.175Z prisma:engine stderr {"is_panic":false,"message":"Timed out fetching a new connection from the pool. Please consider reducing the number of requests or increasing the `connection_limit` parameter (https://www.prisma.io/docs/concepts/components/prisma-client/connection-management#connection-pool). Current limit: 9.","meta":{"connection_limit":9},"error_code":"P2024"}
2021-02-19T21:18:50.176172+00:00 app[web.1]: 2021-02-19T21:18:50.176Z prisma:engine {
2021-02-19T21:18:50.176173+00:00 app[web.1]: is_panic: false,
2021-02-19T21:18:50.176179+00:00 app[web.1]: message: 'Timed out fetching a new connection from the pool. Please consider reducing the number of requests or increasing the `connection_limit` parameter (https://www.prisma.io/docs/concepts/components/prisma-client/connection-management#connection-pool). Current limit: 9.',
2021-02-19T21:18:50.176179+00:00 app[web.1]: meta: { connection_limit: 9 },
2021-02-19T21:18:50.176180+00:00 app[web.1]: error_code: 'P2024'
2021-02-19T21:18:50.176180+00:00 app[web.1]: }
2021-02-19T21:18:50.178119+00:00 app[web.1]: 2021-02-19T21:18:50.178Z prisma:client Error: Timed out fetching a new connection from the pool. Please consider reducing the number of requests or increasing the `connection_limit` parameter (https://www.prisma.io/docs/concepts/components/prisma-client/connection-management#connection-pool). Current limit: 9.

@inlineblock did you close this because you resolved the issue? If so, how did you - seeing this myself now.

@inlineblock did you close this because you resolved the issue? If so, how did you - seeing this myself now.

I did resolve it for my case @dylan-gregory. AWS's default/new VPC security group in RDS allows for external access if 'Public accessibility' is turned on, however it doesn't allow connections from servers inside AWS, which both Vercel and Heroku use AWS in the US and most of the world. You can click on the VPC security group, edit the inbound traffic to <IP_ADDRESS>/0 and then it works.
Prisma on the other hand is displaying an error that is not correct. Leading me to thinking it was something else.


Use GIT_EDITOR for editing and approving with cargo vet certify

This is an alternative approach to the vet certify UX which uses the GIT_EDITOR in order to prompt and ask the user to input notes, and accept a statement while also showing the criteria descriptions.
In order to function more reliably on Windows, this code attempts to locate the git-for-windows install on the user's machine, and invokes the user's GIT_EDITOR through the git-for-windows' shell environment.
This does not attempt to replace the interactive prompt for selecting which criteria to certify for.
Fixes #165

Example text file for `cargo vet certify indexmap 1.8.1` in the test project:
# Please read the following criteria and uncomment the statement below:

# === BEGIN CRITERIA "safe-to-deploy" ===
#
# This crate will not introduce a serious security vulnerability to production
# software exposed to untrusted input.
#
# Auditors are not required to perform a full logic review of the entire crate.
# Rather, they must review enough to fully reason about the behavior of all unsafe
# blocks and usage of powerful imports. For any reasonable usage of the crate in
# real-world software, an attacker must not be able to manipulate the runtime
# behavior of these sections in an exploitable or surprising way.
#
# Ideally, all unsafe code is fully sound, and ambient capabilities (e.g.
# filesystem access) are hardened against manipulation and consistent with the
# advertised behavior of the crate. However, some discretion is permitted. In such
# cases, the nature of the discretion should be recorded in the `notes` field of
# the audit record.
#
# For crates which generate deployed code (e.g. build dependencies or procedural
# macros), reasonable usage of the crate should output code which meets the above
# criteria.
#
# === END CRITERIA ===
#
# STATEMENT:

# I, Nika Layzell, certify that I have audited version 1.8.1 of indexmap in accordance with the above criteria.

# NOTES:


is it possible to directly load a torch tensor?

Hi,
Thanks for your great work! I am wondering if there is a way to directly load the input image from torch tensor?
I saw in jeston-utils you can convert cuda image to pytorch tensor. Is there a way to convert pytorch tensor to cuda image?

I haven't entirely been able to figure that out yet but have some ideas based on torch.tensor.data_ptr() , or torch's implementation of cuda_array_interface
For the time being, I would continue using the numpy/ndarray route.

From: Yiming Zhou @.>
Sent: Friday, April 7, 2023 5:51:31 PM
To: dusty-nv/jetson-inference @.>
Cc: Subscribed @.***>
Subject: [dusty-nv/jetson-inference] is it possible to directly load a torch tensor? (Issue #1597)
Hi,
Thanks for your great work! I am wondering if there is a way to directly load the input image from torch tensor?
I saw in jeston-utils you can convert cuda image to pytorch tensor. Is there a way to convert pytorch tensor to cuda image?
—
Reply to this email directly, view it on GitHubhttps://github.com/dusty-nv/jetson-inference/issues/1597, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADVEGK5GI4SS6QMOIRTW6CDXACD6HANCNFSM6AAAAAAWW6SOTM.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@Yiming0416 support for this has been added in https://github.com/dusty-nv/jetson-utils/commit/c692b89f5716e01823ff177e286eba6986bc4c6a


Show progress of symbolic execution

Hello, I am trying to run symbolic execution on a program, but it seems that it takes forever. Is there a way to show the progress of symbolic execution? Like show the # of paths K is going to explore right now or something similar?
My command is krun --verbose -cPC="true" -cIN="ListItem(#symString(x))" --search example.php
Thanks a lot.

Using the Haskell or Java backends (Haskell recommended), you can pass --debugger option to have it start the proof repl instead of just attempting the proof. To use this with krun --search, you may need ot instead do --haskell-backend-command kore-repl.
Re-open if this does not work.


chore(main): release 1.1.0

:robot: I have created a release beep boop
1.1.0 (2022-05-20)
Features

memcached: install memcached with extra configuration (b19fd66)

Bug Fixes

refactoring comments (00b8d2a)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/furkanural/asdf-memcached/releases/tag/v1.1.0 :sunflower:


[SC] Dynamic swagger contract API

Adds a dynamically generated swagger API page per contract.

Adds a path per method to broadcast a call transaction.
Adds a path per property to run a local calls to query property values.

This will not go into master as the query for historical contract addresses takes some time on longer chains. Also means that Stratis.Bitcoin.Features.API will have a dependency on smart contracts.
Do not merge until <IP_ADDRESS> is released.

I like the general approach which will be sufficient for our current requirements.
We need to make sure that this solution will scale before we merge to official release.


Unable to ingest SAPIL/A/9/4 through Archivematica (prod)

It has a large AVI file which causes an OOM issue; see https://github.com/wellcomecollection/platform/issues/4757
We should fix the replicator so it can be ingested, and make sure this package gets ingested successfully.

Sorted.


ARTEMIS-4910 fix divert config encoding

This commit fixes 4 distinct issues with divert configuration encoding:

The encoding size was calculated incorrectly in three ways:

Using 0 instead of DataConstants.SIZE_NULL when no transformer is defined resulting in a calculated size discrepancy of -1.
Using DataConstants.INT instead of DataConstants.SIZE_INT for the number of transformer properties resulting in a calculated size discrepancy of +2 when using a configuration with a transformer.
Using BufferHelper.sizeOfNullableBoolean instead of DataConstants.SIZE_BOOLEAN for the exclusive property resulting in a calculated discrepancy of +1.

Encoding was using writeString instead of writeNullableString for the name of the transformer class resulting in an actual buffer size discrepancy of -1.

Are there any compatibility implications to consider and either handle or document?
The JIRA looks to cover to an over-the-wire issue...any issues if e.g a rolling upgrade is tried with the different encoding behaviours? Should a particular rollout order be used?
Also, are these values persisted anywhere? If so is there any issue when an updated broker starts with an existing stored configuration value from an older version?

I don't believe there will be any compatibility issues. To be clear, the changes only impact how a divert configuration is encoded. Nothing is changing with how it is decoded. This will mainly impact new brokers encoding new configurations. Any old configuration being read from disk or from the wire by a new broker will continue to work as it always had. Furthermore, a new broker sending a config over the wire to an old broker will also work properly not least because now since it's being encoded correctly.

I find it awkward to reconcile the encoding having changed, with there being no consideration needed at all in terms of upgrade behaviour. Either during decoding of old persisted data, or data generated afresh by an old broker.  By 'continue to work as it always had', do you for example mean 'continue to behave incorrectly, until only data generated by new brokers exists'? If so, that would still seems worth documenting somewhere, e.g jsut the Jira.
E.g if the calculated size has changed, which apparently is enough to fix a bug over the wire for live brokers, couldnt that have similar effect during the access of old persisted data with the wrong encoded size by a newer broker? Or does it somehow not use that incorrect size of persisted data to decode it correctly, or refreshes it so it has the correct encoded size persisted, when it is a new broker reading it?

I find it awkward to reconcile the encoding having changed, with there being no consideration needed at all in terms of upgrade behaviour.

The main thing that changed here is the calculation of the encoding size, a calculation which isn't performed during the decoding process.
The only actual encoding change was to fix a bug where encoding & decoding were using mismatched methods. Encoding was using writeString and decoding was using readNullableString. Technically speaking, this could have been fixed by changing the decoding to using readString, but that would have had implications for compatibility. Instead I changed the encoding to use writeNullableString which means that the data in the buffer is correct now and there should be no compatibility issues.

By 'continue to work as it always had', do you for example mean 'continue to behave incorrectly, until only data generated by new brokers exists'?

If you have an old broker sending broken data to a new broker the new broker will choke on it. I don't see a reasonable way to avoid that. To clarify, are you saying that this fact needs to be documented?

...if the calculated size has changed...couldnt that have similar effect during the access of old persisted data with the wrong encoded size by a newer broker?

The encoding size is calculated and written to disk (or wire) along with the record. The new calculation won't come into play when reading this old data. The new broker will read the data from disk just like the old broker did since there's been no changes to decoding.

I find it awkward to reconcile the encoding having changed, with there being no consideration needed at all in terms of upgrade behaviour.

The main thing that changed here is the calculation of the encoding size, a calculation which isn't performed during the decoding process.
The only actual encoding change was to fix a bug where encoding & decoding were using mismatched methods. Encoding was using writeString and decoding was using readNullableString. Technically speaking, this could have been fixed by changing the decoding to using readString, but that would have had implications for compatibility. Instead I changed the encoding to use writeNullableString which means that the data in the buffer is correct now and there should be no compatibility issues.

By 'continue to work as it always had', do you for example mean 'continue to behave incorrectly, until only data generated by new brokers exists'?

If you have an old broker sending broken data to a new broker the new broker will choke on it. I don't see a reasonable way to avoid that. To clarify, are you saying that this fact needs to be documented?

...if the calculated size has changed...couldnt that have similar effect during the access of old persisted data with the wrong encoded size by a newer broker?

The encoding size is calculated and written to disk (or wire) along with the record. The new calculation won't come into play when reading this old data. The new broker will read the data from disk just like the old broker did since there's been no changes to decoding.

Ok, so you have confirmed everything I thought would be the case. So yes, I think it is reasonable that is at least noted somewhere, even if just the JIRA. Someone who has hit this, upgrades their broker and has now a 'bug fixed' version, is likely to expect that completely resolves their issue. If it actually wont change anything until only data generated by new brokers is in play, it feels like that should be stated so the user can figure that out and learn what to do about it. E.g is it a case of deleting their store to remove the old persisted thing? Removing a specific config and recreating it? Other? I really dont know, hence the suggestion we should perhaps have a few word covering the scenario for anyone else that wouldnt immediately know.


added more socket listeners so for console.log

added more listeners so I can relay console messages from my web site to show in the log, particularly for mobile devices where it's not easy to access the output of console.log

Like it :) Thanks


Enable --nullability by default (can be disabled with --no-nullability).

Enable --nullability by default (can be disabled with --no-nullability).

Dropped because several projects reported build failures due to nullability warnings combined with -Werror.


Mute logging in tests

When running tests in verbose mode, the webserver logs are printed to the screen. Replacing the logger with a nop one removes the noise.

@adambkaplan - can we merge https://github.com/redhat-appstudio/sprayproxy/pull/22 (and iterate on it later if need be) see we can see @enarha new unit tests run in this PR?

Rebased.

unit tests passed
didn't see @adambkaplan explicitly say this looked good ... will defer to him for merge


Regression on JsonPlatform

I could reproduce the results and isolate it to these commits:
https://github.com/dotnet/coreclr/compare/f360bbc0cf893bcd612516563145729743d3af2b...df2f4c4feb273545e91fd8d7d170dc424b741f19
As I still have the patched version that @janvorli gave me with this changes:
https://github.com/dotnet/coreclr/pull/24045 which fixed a perf regression for Json, I can confirm that these changes introduced the new one on JsonPlatform.

ResponseCachingResponseNoCache and ResponseCachingRequestNoCache have also regressed (10%) at the same time, so probably related too.

@janvorli any chance you could take a look at this or assign it to someone who could understand the changes? It's one of the most visible scenarios in the TE benchmarks.

As I still have the patched version that @janvorli gave me with this changes:
dotnet/coreclr#24045 which fixed a perf regression for Json, I can confirm that these changes introduced the new one on JsonPlatform.

To make sure I understand - do you mean that my fix to the previous regression has introduced the other regression?

Exactly

Ok, since the only thing the change did was to fix setting the affinity and the respective function is used only for GC threads, it seems that that benchmark dislikes affinitized GC threads for some reason.
Can you please try to run the test with COMPlus_GCNoAffinitize set to 1?

I tried with this value and even though it's better (+5%) it's still not up to the results we had before the change (1M RPS).
|              Description |     RPS | CPU (%) | Memory (MB) | Avg. Latency (ms) | Startup (ms) | First Request (ms) | Latency (ms) | Errors | Ratio |
| ------------------------ | ------- | ------- | ----------- | ----------------- | ------------ | ------------------ | ------------ | ------ | ----- |
| COMPlus_GCNoAffinitize=0 | 909,239 |      96 |         475 |              0.96 |          232 |              52.85 |         0.15 |      0 |  1.00 |
| COMPlus_GCNoAffinitize=1 | 953,860 |      99 |         507 |              0.88 |          232 |              53.34 |         0.15 |      0 |  1.05 |

I also tried on the ConnectionClose scenario which saw a regression as the exact same time, and the results are similar, with some good improvement, but not as much as before the change.

Description
RPS
CPU (%)
Memory (MB)
Avg. Latency (ms)
Startup (ms)
First Request (ms)
Latency (ms)
Errors
Ratio

COMPlus_GCNoAffinitize=0
23,688
78
506
16.79
276
51.04
0.48
1
1.00

COMPlus_GCNoAffinitize=1
27,018
92
503
9.2
276
50.78
0.42
0
1.14

It seems the regression is likely due to a bug that we've discovered today: https://github.com/dotnet/coreclr/pull/24706

Would you mind giving me some binaries so I can test this change in isolation?

Sure. Would build of coreclr from master work for you or would you prefer if I built it from an older commit and applied my fix to that? It would be easy to do both ways.

Any baseline is fine as long as you give me both versions, before and after the change. With only the files that actually changed.

Fixed


[HUM-77] implement loading state on resign btn for a specific job

Issue tracking

HUM-77
Context behind the change

How has this been tested?

Release plan

Potential risks; What to monitor; Rollback plan

 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.adrian-ol seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Build modals for feedback submit, back and close buttons

Acceptance Criteria

[x] Add "Submit" button to service detail page (mock).
[x] Click submit button brings up modal (mock)
[x] Modal has checkbox for SPO staff and optional additional fields for SPO staff (mock)
[x] Modal has button (mocks without email and with email) to submit suggested updates and user info to an airtable base. The button doesn't do anything yet, see #985.
[x] Also make the back button and close button open a modal to let the user confirm that they intend to leave the page and discard any information they have entered (mock).
[ ] Back button navigates to this screen
[ ] Close brings you back to the regular read-only service detail page.

Issue considered complete after discussion with @tomy-pg.


Exception was thrown but resources were created.

Following exception thrown by illegal naming:

java.lang.IllegalArgumentException: EventHub names must conform to the following rules to be able to use it with EventProcessorHost: Must start with a letter or number, and can contain only letters, numbers, and the dash (-) character. Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names. All letters in a container name must be lowercase. Must be from 3 to 63 characters long.

But the event hub instances can still be created.

Could you put full details of stacktrace here? And as I remember, this is not only for event hub. List all related resource.

I can repro the problem:
Caused by: java.lang.IllegalArgumentException: EventHub names must conform to the following rules to be able to use it with EventProcessorHost: Must start with a letter or number, and can contain only letters, numbers, and the dash (-) character. Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names. All letters in a container name must be lowercase. Must be from 3 to 63 characters long.
at com.microsoft.azure.eventprocessorhost.AzureStorageCheckpointLeaseManager.initialize(AzureStorageCheckpointLeaseManager.java:112)
at com.microsoft.azure.eventprocessorhost.EventProcessorHost.registerEventProcessorFactory(EventProcessorHost.java:464)
at com.microsoft.azure.eventprocessorhost.EventProcessorHost.registerEventProcessorFactory(EventProcessorHost.java:424)
at com.microsoft.azure.spring.integration.eventhub.EventHubTemplate.lambda$subscribe$1(EventHubTemplate.java:100)
at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at com.microsoft.azure.spring.integration.eventhub.EventHubTemplate.subscribe(EventHubTemplate.java:97)
at com.microsoft.azure.spring.integration.core.AbstractInboundChannelAdapter.doStart(AbstractInboundChannelAdapter.java:47)
at org.springframework.integration.endpoint.AbstractEndpoint.start(AbstractEndpoint.java:162)
at org.springframework.cloud.stream.binder.AbstractMessageChannelBinder.doBindConsumer(AbstractMessageChannelBinder.java:285)
Looks like a bug with event hub sdk. As a workaround, we need to do some validation before this:
return azure.eventHubs().define(namespaceAndName.getSecond()).withExistingNamespace(eventHubNamespace).create();

Just FYI, I also notice that not all azure resource name allows dash(-).

What we can do this is validate name before sending the request.


Another approach for windows shell support.

Passed 🚀.
This makes easier to support windows at CI.

Graal v 22.1.0 broke windows build


Black cannot format a markdown file with a html  tag

I am trying to format a README.md file. The first line of the README contains an html img tag so that we can have our company logo on the top right of every README.
When running black README.md, I receive the following error:
error: cannot format README.md: Cannot parse: 1:0: <img align="right" height="50" src="https://s3.amazonaws.com/path/to/logo.png">
All done! 💥 💔 💥
1 file failed to reformat.

Operating system:
Python version: 3.6.8
Black version: 18.9b0
Does also happen on master: Yes (tested by cloning and installing master locally)
By the way, the online formatter gave me a type object 'FileMode' has no attribute 'from_configuration' (for any code, not just my example)
Thanks for your help!

Black doesn't support markdown files, sorry.


PlatformIO Library Registry manifest file

This library in Web Registry: http://platformio.org/#!/lib/show/128/Adafruit-LED-Backpack
Specification: PlatformIO Library Manager
Integration: IDE Integration

library.json is a library manifest file which can be used by the different tools/managers to organise embedded libraries. How does this look from CLI:
$ platformio lib search "Adafruit LED"
# Found ... libraries:
#
# [ ID  ] Name             Compatibility         "Authors": Description
# -------------------------------------------------------------------------------------
# [ 128  ] Adafruit-LED-Backpack         arduino, atmelavr     "Adafruit Industries": Adafruit LED Backpack Library for our 8x8 matrix and 7-segment LED backpacks

$ platformio lib install 128
# Installing [ 128 ]  library:
# Downloading  [####################################]  100%
# Unpacking  [####################################]  100%
# The library  [ 128  ] ‘Adafruit-LED-Backpack' has been successfully installed!

$ platformio lib show 128
# Adafruit-LED-Backpack
# -------------
# Author: Adafruit Industries
# Keywords: ***
# Frameworks: arduino
# Platforms: atmelavr
# Version: ***
#
# Adafruit LED Backpack Library for our 8x8 matrix and 7-segment LED backpacks

$ platformio lib update
# Updating Adafruit-LED-Backpack  library:
# Versions: Current=***, Latest=***       [Up-to-date]


Migration guide initial commit

Let's take this as a starting point and see how much we have to add later

This is a really good starting point @wouterwln ! Thanks a lot! I will merge it and we can refine later!


Refactor first boot setup

Using cloud-init to finish first boot commands has some issues. Instead let's move this to a self-destructing systemd unit file and script.
This also fixes an issue with the apt-daily-upgrade.timer not working properly by ensuring we unmask the apt-daily.service and apt-daily-upgrade.service units.

!bump patch

Jenkins has merged this PR into main and has automatically performed a patch-level version bump to v2.2.1.  Have a nice day!


StyleCop checks

there is C# StyleCop analyzer which may find some errors in our code, so it would be nice to set up it at some point and ensure complains are fixed

I don’t object, but seems a low priority for such a small project.

actually, StyleCop was abandoned some time ago and was replaced by FxCop, then it was integrated into RoslynAnalyzers, and finally it was integrated into the VisualStudio CodeAnalysis

3 main analysers we may apply (just install into project via NuGet Package Manager):

Microsoft.CodeAnalyzers.FxCopAnalyzers - security, performance and design issues
StyleCop.Analyzers - code style
Microsoft.VisualStudio.SDK.Analyzers - specific for VSIX and Visual Studio interfaces
there are many other analyzers available on NuGet, but let's start with these 3


allow additional properties in wallet address response

Changes proposed in this pull request

Context

LGTM, just update the type (see PR checks).
Also, we should close Don's PR with this one.

He was away and I wanted to try get this in quicker. Will update the types now


vote: tag v1.2.0-rc.1

Release
This would mean tagging e90546bd90a8074357dba2cbf19f2e755bd4be2a as v1.2.0-rc.1 to release.
Vote
We need at least 4 approvals from 6 maintainers to release v1.2.0-rc.1.

[ ] Pritesh Bandi (@priteshbandi)
[ ] Rakesh Gariganti (@rgnote)
[ ] Milind Gokarn (@gokarnm)
[x] Yi Zha (@yizha1)
[ ] Shiwei Zhang (@shizhMSFT)
[x] Patrick Zheng (@Two-Hearts)

Changes

feat: CRL by @JeyJeyGao in https://github.com/notaryproject/notation-core-go/pull/214
feat: CRL cache by @JeyJeyGao in https://github.com/notaryproject/notation-core-go/pull/216
build(deps): bump golang.org/x/crypto from 0.26.0 to 0.27.0 by @dependabot in https://github.com/notaryproject/notation-core-go/pull/226
test(signature): add two fuzz tests by @AdamKorcz in https://github.com/notaryproject/notation-core-go/pull/229

Full Changelog:
https://github.com/notaryproject/notation-core-go/compare/v1.1.0...e90546bd90a8074357dba2cbf19f2e755bd4be2a
Action Requested
Please respond LGTM or REJECT (with reasoning).

LGTM

LGTM

LGTM

LGTM

LGTM

Closing as released.


Fix docker image check script for images outside the usual set

When I run make -C install/kubernetes check-docker-images in the v1.10 branch, I see:
$ make -C install/kubernetes/ check-docker-images
docker.io/envoyproxy/envoy:v1.18.2@sha256:e8b37c1d75787dd1e712ff389b0d37337dc8a174a63bed9c34ba73359dc67da7 does not exist!
docker.io/cilium/hubble-ui:v0.7.7@sha256:f20b6b3074a431ecd2730cf19afad2562664cf98baecf32b4cbe2a09f04ad8fa does not exist!
quay.io/cilium/hubble-ui:v0.7.7@sha256:f20b6b3074a431ecd2730cf19afad2562664cf98baecf32b4cbe2a09f04ad8fa does not exist!
docker.io/cilium/hubble-ui-backend:v0.7.7@sha256:11d06121c86549c0c8684571ffed4ff3d4c4417f551728f4fad6d05525c47e9d does not exist!
quay.io/cilium/hubble-ui-backend:v0.7.7@sha256:11d06121c86549c0c8684571ffed4ff3d4c4417f551728f4fad6d05525c47e9d does not exist!
make: *** [Makefile:106: check-docker-images] Error 1

However, several of these images exist (I tried the envoy one and the quay versions of the hubble ones). We should fix up the script to properly locate these images.

These might just be breaking due to a poor assumption around how you can split image names based on the : character position, which is a common way to break when the sha256 digests are specified.

This issue is no longer valid. I believe it might be fixed by 3ec10e7081724f76bf577c40e6f3aa62079dd8d2
Shall we close it @joestringer

Yep, thanks for confirming.


Make sure buffer is loaded before handling results

Loading and unloading a buffer before documentHighlight results are returned causes vim.lsp.util.buf_clear_references to throw an error. This PR adds an additional check to make sure the buffer is loaded before attempting to handle results.

Thanks, I made a small styling change, included you in the commit for credit.


Monitor webview pixels when renderer crashes

Task/Issue URL: https://app.asana.com/0/488551667048375/1204513195956995/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #3118   👈

This comment was auto-generated by Graphite.


Profile page updated

You can now update your profile data.

The Profile Details will now be updated/edited by Identity Service now. Therefore no need of updating the profile data from my-site. Hence closing the PR


can we only show markers when we zoom in? we do not want to mix clsuters and markers

Wouldn't that mean you'd have a bunch of clusters with just one marker in it?
Not sure I see the purpose of this, but if you feel there's a need for it, please explain it further in a new issue in our new fork, this repository isn't maintained anymore: https://github.com/gmaps-marker-clusterer/gmaps-marker-clusterer

It seems like a simple solution could be to use no cluster image at all.


feat(update-server): make openembedded work with update-server (RET-109) (RET-112) (RET-113) (RET-131)

OE update server RET-109
API update server for updating OT3s (running  openembedded)

chunking this into something manageable


python3Packages.mitogen: 0.3.0rc1 -> 0.3.0

Motivation for this change
Update to latest upstream release 0.3.0
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 143733 run on x86_64-linux 1

7 packages built:

home-assistant
python38Packages.aiodiscover
python38Packages.mitogen
python38Packages.pyroute2
python39Packages.aiodiscover
python39Packages.mitogen
python39Packages.pyroute2


Fix locations

Pull Request
Description
Keep forecast as sql object, so that locations dont get repeated
How Has This Been Tested?
normal unittests + run skipped tests

[ ] Yes

Checklist:

[ ] My code follows OCF's coding style guidelines
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have checked my code and corrected any misspellings

Codecov Report

Merging #33 (15e3222) into main (e9cee75) will increase coverage by 0.23%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #33      +/-   ##
==========================================
+ Coverage   93.31%   93.54%   +0.23%
==========================================
  Files          13       13
  Lines         374      372       -2
==========================================
- Hits          349      348       -1
+ Misses         25       24       -1

Impacted Files
Coverage Δ

nowcasting_forecast/database/national.py
89.65% <100.00%> (ø)

nowcasting_forecast/models/nwp_solar_simple.py
90.76% <100.00%> (-0.28%)
:arrow_down:

nowcasting_forecast/database/read.py
100.00% <0.00%> (+1.96%)
:arrow_up:

Continue to review full report at Codecov.

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


Add Snyk badge

Codecov Report

Merging #394 (8502a9f) into master (b23d0c3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #394   +/-   ##
=======================================
  Coverage   62.84%   62.84%
=======================================
  Files          38       38
  Lines        1281     1281
  Branches        8        8
=======================================
  Hits          805      805
  Misses        476      476

Continue to review full report at Codecov.

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


"changed.bs.select" event not working as expected

Currently the documentation states that "changed.bs.select" does the following:

This event fires after the select's value has been changed. It passes through event, clickedIndex, newValue, oldValue.

But that's not the case, right now it just outputs the event, selected index and two boolean values that are always, true and false, in that order.
I made a jsfiddle: https://jsfiddle.net/SrGoodbar/9xotvca2/

Getting the same issue, you figure it out yet?

Yeah, just listen to the 'change' event on the  instead of using Bootstrap's events, worked on my case, using KnockoutJS.

Yea, the current implementation doesn't make a lot of sense. See https://github.com/silviomoreto/bootstrap-select/issues/1378#issuecomment-216393099

newValue and oldValue refer to the value of the changed option - either true or false - to see whether the option was changed to be selected or unselected, not the value of the select itself. However, oldValue is a bit redundant, as it's obviously always the opposite of newValue. It would also make more sense to refer to newValue as selected and oldValue as unselected to improve clarity. It would make more sense to also pass in the select's previous value. Passing in the select's current value is unnecessary, as it can easily be retrieved with $(this).val().

I'd like to replace oldValue with the actual previous value of the select.

Ok, thanks for the clarification!

Released in v1.13.0! @angelpcadena Please feel free to close this issue.


Full Dom Rendering .is() doesn't work if dom children has parsing error

See screenshot below, notice the 2 watch expressions are conflicting to each other. The dom has a parsing error. If I mount a simple div such as
    const wrapper = mount(<div className='sp-main-container' />)

It works.
I am using React@16, enzyme@3.

Try wrapper.children().is('div')?

Works!


Size: support regex exclusions

Signed-off-by: Galo Navarro<EMAIL_ADDRESS>

Thanks @srvaroa , looks perfect! @dilyar85, thoughts? Since you implemented the labeler, do you think this will work for us to exclude the generated assets?

Thanks @srvaroa , looks perfect! @dilyar85, thoughts? Since you implemented the labeler, do you think this will work for us to exclude the generated assets?

Looks good to me too. Thanks @srvaroa for adding this support :)

Thanks @dilyar85 & @akutz, I'll get this released then

Done in v1.10.0


The plugin native_pdf_view doesn't have a main class defined

Right after installing:
The plugin `native_pdf_view` doesn't have a main class defined in /home/JohnDoe/.pub-cache/hosted/pub.dev/native_pdf_view-1.0.3/android/src/main/java/io/scer/native_pdf_view/NativePDFViewPlugin.java or
/home/sudbury/.pub-cache/hosted/pub.dev/native_pdf_view-1.0.3/android/src/main/kotlin/io/scer/native_pdf_view/NativePDFViewPlugin.kt. This is likely to due to an incorrect `androidPackage:
io.scer.native_pdf_view` or `mainClass` entry in the plugin's pubspec.yaml.

Use pdfx package instead https://pub.dev/packages/pdfx


Fix sorting of hashtables

Summary of the new feature/enhancement

In order to sort dictionary (hashtable) an explicit GetEnumerator is required. For example:
> $a = @{a=1;b=2;c=3;d=4}
> $a|sort Name
Name                           Value
----                           -----
c                              3
d                              4
b                              2
a                              1

(doesn't work)
> $a.GetEnumerator()|sort Name
Name                           Value
----                           -----
a                              1
b                              2
c                              3
d                              4

(works fine)
Proposed technical implementation details (optional)
Make a change so that
> $a|sort Name

works as expected. Current behavior benefits nobody.

While it may be surprising, [hashtable] instances have always been treated as a single object in the pipeline, and changing that now would be a massively breaking change.
Think of [hashtable] instances as single objects, whose properties (hashtable entries) you wouldn't expect to be enumerated in the pipeline either.

At first it's really surprising and confusing. Then it starts to make sense. However maybe there should be friendlier way than using a method which is very rarely used even by .NET developers.

I agree that it's not obvious, but the need for it is too rare to warrant a dedicated operator for it in PowerShell, I think.
Note that your specific scenario is at least explicitly documented in the conceptual about_Hash_Tables topic.
Also note that, as stated in the linked topic, you're not sorting the hashtable itself (which is impossible); instead, you're outputting a sorted array of key-value pairs.

P.S.: A simple alternative is to cast to System.Collections.SortedList:
PS> $ht = @{ zz = 1; gg = 2; aa = 3 }; [System.Collections.SortedList] $ht

Name                           Value
----                           -----
aa                             3
gg                             2
zz                             1


[BUG] TS error when rendering <FronteggAppProvider />, missing env... props

Describe the bug
The Next.js Frontegg documentation here advises creating an ./app/layout.tsx file to render <FronteggAppProvider /> like so:
{/* @ts-expect-error Server Component for more details visit: https://github.com/vercel/next.js/issues/42292 */}
<FronteggAppProvider authOptions={authOptions} hostedLoginBox={true}>
  {children}
</FronteggAppProvider>

Having done this, I believe the @ts-expect-error comment is masking an issue with the typings of the component, where it requires envAppUrl, envBaseUrl, and envClientId to be provided as props (though these are inferred from my .env.local file otherwise).
The TS error is as follows:
Type '{ children: ReactNode; authOptions: { keepSessionAlive: boolean; }; hostedLoginBox: true; }' is missing the following properties from type 'Omit<ClientFronteggProviderProps, "contextOptions">': envAppUrl, envBaseUrl, envClientId ts(2739)

I believe this could be two separate bugs:

The @ts-expect-error comment from your docs isn't actually required (at least not in the latest version of Next.js for me, where async server components are now supported)
The props type for FronteggAppProvider is slightly wrong or the usage documentation needs to be updated (either the env... props are optional, or the docs should cover passing them)

To Reproduce
Steps to reproduce the behaviour:

Follow the setup guide up to this point
Remove the @ts-expect-error comment preceding the rendering of <FronteggAppProvider />

Expected behaviour
No TS error, or expect error comment

@chrishutchinson  Thank you for letting us know about this issue.
The types have been fixed since version 8.0.10.
Therefore, I'm closing this issue.


[Edge] support edge

If no client_id is found in the data, publish it to all connected clients.
Add NNS_EDGE_FLAG_PUBSUB.

Signed-off-by: Yechan Choi<EMAIL_ADDRESS>

:memo: TAOS-CI Version: 1.5.20200925. Thank you for submitting PR #60. Please a submit 1commit/1PR (one commit per one PR) policy to get comments quickly from reviewers. Your PR must pass all verificiation processes of cibot before starting a review process from reviewers. If you are new member to join this project, please read manuals in documentation folder and wiki page. In order to monitor a progress status of your PR in more detail, visit http://ci.nnstreamer.ai/.

:octocat: cibot: @anychhoice, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/60-202208261916060.78097200393677-4fe14e9746100b5927fbf44e5a4408abc4f5852c/.

:octocat: cibot: @anychhoice, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/60-202209012252430.42168402671814-ca05c5561a4735d6f8aaa143f7222ffda48cbd95/.

:octocat: cibot: @anychhoice, A builder checker could not be completed because one of the checkers is not completed. In order to find out a reason, please go to http://ci.nnstreamer.ai/nnstreamer-edge/ci/repo-workers/pr-checker/60-202209061658210.66092395782471-ff4b377005990382c217394f95f719fab6785c76/.


Add cosmic and disco to metadata

Closes #8

Good addition! Perhaps also add tests for these series? See #6 from @barryprice


management/invoke_script Clarification

I'm building a script to get screenshots and log keystrokes. Then have it autorun upon Initial agent becoming active.

To clarify, do i just  copy the scripts that i need and pasting it below each other into one allscripts.ps file? Like this: http://pastebin.com/j2pm7Wvn ?
What should the options be of  ScriptCmd (of management/invoke_script module)

The Description says: Script command (Invoke-X) from file to  run,
But I dont quite understand, perhaps an example please?

I have tried the following values for ScripCmd:
Invoke-Command
Invoke-Expression
Invoke-Item
But it does not work. The .ps1 script is a screenshot script but I dont get a screenshot.
Here is a log of what I am doing:
http://pastebin.com/iXiQjQiX

invoke_script just takes a script block and pastes the specified ScriptCmd at the end. An example of a simple module would be https://github.com/PowerShellEmpire/Empire/blob/dev/data/module_source/management/Invoke-RunAs.ps1 , and the ScriptCmd would be something like 'Invoke-RunAs -username john...'.
If you have additional questions on PowerShell development I would recommend asking in the #psempire channel on Freenode.


Don't reformat unmodified lines in IDEA 15

plugin is forcing style rules of javadoc (adding empty lines) and line break when overflowing specified Right margin
this happens in IDEA 15, in IDEA 14.1.5 plugin works fine

I have the problem too, I think 15 is now enforcing javadoc style rules that 14 didn't (it might be normal behavior). I'll check it out.

As a workaround, you can configure the formatting with CTRL+ALT+SHIFT+L and change the scope. It seems to be kept for later calls performed by the plugin.

will not fix