Cannot use 'DEL' with redis-cluster.

Describe the bug
Expected: Clearing the cache across the packages of Laravel (Symfony) and Predis should work with AWS Redis Cluster.

Eloquent Query
Please provide the complete eloquent query that caused the bug, for example:
$model->with('otherModel')->get();

Stack Trace
The full stack trace from your log file.
Environment

PHP: >=7.2.5
OS: Windows 10 + Docker -> Debian / AWS Latest PHP Elastic Beanstalk
Laravel: 7.22.4
Model Caching: 0.9.0

Additional context
have the same issue local and on AWS.
Config database.php

'redis' => [
        'client' => 'predis',
        'cluster' => env('REDIS_CLUSTER', false),
        'options' => [
            'cluster' => 'redis',
            'parameters' => [
                'password' => env('REDIS_PASSWORD', null),
                'scheme' => env('REDIS_SCHEME', 'tcp'),
                ],
            'ssl' => ['verify_peer' => false]
        ],
        'clusters' => [
            'default' => [
                [
                    'scheme'   => env('REDIS_SCHEME', 'tcp'),
                    'host' => env('REDIS_HOST', 'localhost'),
                    'password' => env('REDIS_PASSWORD', null),
                    'port' => env('REDIS_PORT', 6379),
                    'database' => env('REDIS_DATABASE', 0),
                ],
                'options' => [
                    // Clustering specific options
                    'cluster' => 'redis',
                    // This tells Redis Client lib to follow redirects (from cluster)
                ]
            ],
            // duplicate of default
            'cache' => [
                [
                    'scheme'   => env('REDIS_SCHEME', 'tcp'),
                    'host' => env('REDIS_HOST', 'localhost'),
                    'password' => env('REDIS_PASSWORD', null),
                    'port' => env('REDIS_PORT', 6379),
                    'database' => env('REDIS_DATABASE', 0),
                ],
                'options' => [
                    // Clustering specific options
                    'cluster' => 'redis',
                    // This tells Redis Client lib to follow redirects (from cluster)
                ]
            ],
        ],
    ],

Using a AWS Redis Cluster with 3 nodes. Any idea where to start to debug?

Hi @Nowi5, thanks for writing in about this issue. This would almost certainly be an issue with Predis and AWS not being compatible with each other.  I would file a bug with Predis with a complete StackTrace and go from there. Please do keep me informed of your developments, in case I need to make any updates here. Best of luck!

I have the same issues when using my local docker including redis. Let see if the Laravel Community can help:
https://github.com/laravel/framework/issues/33733

@Nowi5 Awesome, looks like you got all bases covered. I subscribed to your two other tickets and will follow along to see what comes of it. :)

@mikebronner Thank you for your support as always. Found a temporary solution back from 2017. Do you have any deeper insights to judge if that change makes actually sense? Thank you for your expert opinion.

@Nowi5  My recommendation would be to switch to PHPREDIS, as that is the recommended path forward by Laravel, I believe.

I'm going to work on a release that removes the predis dependency.

@Nowi5 Please give release 0.10.0 a try with PHPRedis and let me know how it goes.


Added cycle 2 subjects to curriculum automation script

Description
Features

Added cycle 2 subjects to curriculum automation script
Also added --remove-options arg to remove options element from DOM (for new MV testing

How to test
Only dev script, no QA required.

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


Fee informations

UI Version: 0.X.X
Description:
For a user is a bit hard to understand that he's paying Gas for transactions and to retrive this information later. It would be nice to have in the Voting, Depsit and Transaction actions and show it in a confirmation box: The fee of this operation is X

I think the user should eventually define the gas and fees (amount + coin denomination) by herself  and also provide the option in the settings to define a default gas and fee

cc: @alessio what's the cmd/parameter to estimate the gas cost ?

absolutely - we need to do a better job of communicating gas and fees!

After the discussion in the sdk channel, I think gas is not relevant to our end users. Clients (voyager) could run a simulation previously and check the estimated gas used and set that value on the gas field.
Regarding fees, imo we should eventually define an input field within the txs modals (Deposit, Vote, Delegate, etc) and have a custom value set as default on the preferences/settings page that's pre-filled on the modals

Proposal:
Don't show the concept of gas to the user. The user only cares about fees he needs to pay (which include gas). Voyager shouldn't care about gas either. Stargate should handle fee calculation as it can reuse calculated minimum fees across multiple requests. A client could request stored minimum fees from Stargate similar to the current "simulate" flag.

Scope:

[ ] Input transaction fees on the tx modals
[ ] Run the tx simulation and propose a minimum fee to the input

use tx simulation to get gas price
convert gas price into atoms
display this price to users
if gas price is too low and transaction is dropped, show button for increasing gas price by x% so user can try again (in action modal)

don't show "gas" to users - just show atoms as tx fee

4. if gas price is too low and transaction is dropped, show button for increasing gas price by x% so user can try again (in action modal)

I am not sure we can identify this. Transactions will go to the mempool ready to be claimed by a block proposer and will only after several blocks be dropped.

moved to #2238


Regenerate REST docs so that the URL is rendered in each page

In order to remove the ability to submit a WS request in the "REST" pages, the plugin needs an update. The update to the plugin, however, hides each API's URL, so that needs to be sorted.

closed in #638


Add curation URL link to .cvs downloads from dashboard

Please add a column in the dashboard download file that includes the URL link to the curation in the VCI/GCI
Added bonus requests:

Please add a column with the CAID in the download file for VCI downloads
Please provide the functionality (and icon) for opening variants and genes from the dashboard into a new tab

Currently not pulling in CAID data per variant in the dashboards. In the future, when we refactor the query for the dashboards, CAIDs will be added to the projected data to be returned in the dashboard tables.

merged to prod 12/18/23

@markmandell , I'm going to keep this open  (but rename it) so we don't loose the other requests. Thanks so much for getting the URL's out so quickly!

Note we've gotten requests from two VCEPs to add in unique IDs (ClinVar/CAR) to the dashboard download in late December 2023.


Regex incorrect for huge numbers

Hi,
I just found out using the range-regex module in pyton is not working to generate regular expressions when dealing with timestamps.
Let's say I want to generate a regex for values from<PHONE_NUMBER> to<PHONE_NUMBER> (unix timestamps) I get the regex: 1420[0-1][6-5][6-3][8-1]\\d{2} which apparently is wrong.
Using he "re" module in python together with the above regex throws an exception with message: "bad character range".
It would make sense to switch the numbers in a range if the left one is bigger than the right one.
Is there a way to get rid of this bug and update the module?
Thank you in advance.

Everybody who encounters the same problem, change the function: range_to_pattern to the following:
def range_to_pattern(start, stop):
    pattern = ''
    any_digit_count = 0

    for start_digit, stop_digit in zip(str(start), str(stop)):
        if start_digit == stop_digit:
            pattern += start_digit
        elif start_digit != '0' or stop_digit != '9':
            if start_digit > stop_digit:
                pattern += '[{}-{}]'.format(stop_digit, start_digit)
            else:
                pattern += '[{}-{}]'.format(start_digit, stop_digit)
        else:
            any_digit_count += 1

    if any_digit_count:
        pattern += r'\d'

    if any_digit_count > 1:
        pattern += '{{{}}}'.format(any_digit_count)

    return pattern


Cerbo GX crashes when writing to grid L1/L2 topics

Note: My current setup is off-grid. I want to validate that I can get the sensor values into ESS before I make the grid connection.
I am able to write to Ac/Energy and Ac/Power without issue. I can also write to L1/Voltage and L2/Voltage. But if I write to L*/Power or L*/Current the screen crashes. If I leave my client connected long enough entire Cerbo will reboot.
dbus-mqtt-device logs:
@4000000063dc161125893314 INFO:device_manager:Received device status message {'clientId': 'ctsensor', 'connected': 1, 'version': '1', 'services': {'L1': 'grid'}}
@4000000063dc1611259a0f7c INFO:device:**** Registering device: ctsensor, services: {'L1': 'grid'} ****
@4000000063dc161125a5db04 INFO:device:Registering Service grid for client ctsensor
@4000000063dc161125b19ad4 INFO:device_service_config:About to open config file
@4000000063dc16112e44eebc INFO:device_service:Unregistered mqtt_ctsensor_L1 from dbus
@4000000063dc16120f1c474c INFO:device_service:Registering service grid for client ctsensor at path com.victronenergy.grid.mqtt_ctsensor_L1
@4000000063dc16121233c07c INFO:settingsdevice:Setting /Settings/Devices/mqtt_ctsensor_L1/ClassAndVrmInstance does not exist yet or must be adjusted
@4000000063dc161217c1a464 INFO:vedbus:registered ourselves on D-Bus as com.victronenergy.grid.mqtt_ctsensor_L1
@4000000063dc161218a6b11c INFO:device_service:Registered Service com.victronenergy.grid.mqtt_ctsensor_L1 under DeviceInstance 1
@4000000063dc161218d81d74 INFO:device_manager:publish {'portalId': '102c6b64af99', 'deviceInstance': {'L1': '1'}} to device/ctsensor/DBus, status is 0
@4000000063dc163d19a44ee4 INFO:device_manager:Received device status message {'clientId': 'ctsensor', 'connected': 0, 'version': '1'}
@4000000063dc163d1d1f5c44 INFO:device_service:Unregistered mqtt_ctsensor_L1 from dbus
@4000000063dc163d1d1f7f6c INFO:device:Removed Service L1 from client ctsensor
@4000000063dc163d1d1f8b24 INFO:device_manager:**** Unregistering device ctsensor ****
^C

MQTT Explorer:

Mosquitto_pub:
❯ mosquitto_sub -h venus.local -t "device/#" -t "W/#" -v
device/ctsensor/Status {"clientId": "ctsensor", "connected": 1, "version": "1", "services": {"L1": "grid"}}
device/ctsensor/DeviceInstance {"L1": "1"}
device/ctsensor/DBus {"portalId": "102c6b64af99", "deviceInstance": {"L1": "1"}}
W/102c6b64af99/grid/1/Ac/L1/Voltage {"value": "120.2"}
W/102c6b64af99/grid/1/Ac/L2/Voltage {"value": "120.2"}
W/102c6b64af99/grid/1/Ac/L1/Current {"value": "11.98"}
W/102c6b64af99/grid/1/Ac/L2/Current {"value": "18.51"}
W/102c6b64af99/grid/1/Ac/L1/Power {"value": "1411.1"}
W/102c6b64af99/grid/1/Ac/L2/Power {"value": "2154.1"}
W/102c6b64af99/grid/1/Ac/Energy/Forward {"value": "30.12"}
W/102c6b64af99/grid/1/Ac/Power {"value": "3565"}
device/ctsensor/Status {"clientId": "ctsensor", "connected": 0, "version": "1"}

Before mqtt client connects:

After mqtt client writes to L1/L2 current/power:

Hi @mtucker502, I've not used grid myself. If this driver is registering your device correctly then it is doing its job, the interface you are using to publish data values is Victron's own dbus-mqtt interface.
Having said that, could the cause of your issue be the same as the one reported earlier this, posting strings instead on numeric values? You have quotes around numeric values.
W/102c6b64af99/grid/1/Ac/L1/Voltage {"value": "120.2"}
W/102c6b64af99/grid/1/Ac/L2/Voltage {"value": "120.2"}
W/102c6b64af99/grid/1/Ac/L1/Current {"value": "11.98"}
W/102c6b64af99/grid/1/Ac/L2/Current {"value": "18.51"}

One more thing that looks a bit odd in your log file:
INFO:device_manager:**** Unregistering device ctsensor ****
Are you publishing data after the driver has stopped or been killed? I'm not sure how the dbus will behave if your device is not connected.

I had the pip install error earlier :)
This one though you were right on the money. I'm sending floats as strings. Is there a preferred method for decoding bytes from paho-mqtt into the proper type?
Currently I'm decoding as "utf-8" and for these sensor values then converting to floats. Example: sensor_value = float(message.payload.decode("UTF-8"))

I couldn't tell you. As far as I know you just need to ensure your numeric values are floats or integers.

As you found the problem was, can this issue be closed?


Convert blogs 2020-08 to relative paths

This PR coverts the following blog entries from August 2020 to use relative paths instead of absolute paths to https://www.coronawarn.app:

blog/2020-08-12-ios-update-1-2-1
blog/2020-08-13-ios-betriebssystem-update
blog/2020-08-25-notes-qr-codes

It follows from the issue https://github.com/corona-warn-app/cwa-website/issues/1819.
Subsequent PRs are planned to deal with later blog entries.

@MikeMcC399 Thanks again!


Sending bug report not possible

Actually I wanted to send a bug report about several missing push notifications, but that was not possible with riot an my iPhone SE, because the keyboard is covering the send button. So instead here is a bug report for not being able to send bug reports.

So feel free to close this one.

I don't think that would be wise. Empirically, someone I know wanted to but submit feedback, but, within a reasonable time, wasn't able to figure out how to send the report. So, if you're interested in receiving bug logs, making the submission process usable is key.


Update to support version 0.2 of aws-amplify-react-native

Version 0.2 of aws-amplify-react-native supports caching login details on the device (amongst other improvements https://github.com/aws/aws-amplify/pull/200)
It would be a great upgrade to this starter if the new library version was supported. Thanks!

@SteveHoggNZ PR #49 is already in review hoping to get that merged right away after a but more testing / review.


Make at least one user managed key available to CI builds

In some of the CI tests, particularly when running against production, we need a valid key from Google Cloud KMS.  We need to create such a key, and safely share it with the Kokoro build.

This is resolved and it is being used in #1131.


fix details in with_run_context

:+1:
Some day we should get chefstyle to standardize us on one block passing style (probably &block) but that can be a battle for another day.

I thought we actually did and I'm surprised that this didn't piss it off.  The &block thing actually has a perf overhead.

👍


Needs corrections after username change (docs link out of date, repo link in docs out of date)

All links to documentation link to https://frelerik.github.io/llama/ but documentation is now at https://freddylist.github.io/llama/ .
Additionally, I noticed the link in the docs to the repo links to https://github.com/Frelerik/llama/ . Luckily, this still works due to Github's automatic redirect, but it should be changed to https://github.com/freddylist/llama .

Fixed in #17


Remove BackendDecorator?

I don't think this serves a purpose anymore with the expanded ControllerDecorator that has been put in place over the last few months so I think it can safely be removed.
The rate limiting decorators currently use it but I think it would be a quick change to update them to no longer use the backend.

I now remember why I created the backend decorator. It's for the limit decorators. There is no way with a traditional class hierarchy to change how the limits are checked for all the limit decorators without extending each one of them and implementing something.
So the backend decorators allows a single unified interface, you override the backend, set it on the parent limit decorator and then all the limit decorators will use that backen. That makes sense so I'm going to leave the decorator in.


Adding ID to a "unknown" obs with withdrawn ID makes your ID a disagreement to withdrawn ID

From https://forum.inaturalist.org/t/disagreeing-with-a-withdrawn-id-doesnt-change-it-from-unknown/7964

Find an "unknown" obs that has a withdrawn ID (or create one).
Add an ID to it.
Your ID is added, then is changed to a disagreeing ID.

If original ID is deleted, the second ID is still a disagreeing one.

Looks like a few things going on here:

[ ] An identification added to an observation without any current identifications should not be a disagreement

[ ] Deleting an identification should update any other identification that was in disagreement to no longer be disagreements

#2769 Addresses the first

While #2769 seems harmless and sensibly defensive, I'm pretty sure the more serious problem is at https://github.com/inaturalist/inaturalist/blob/main/app/models/identification.rb#L182, where we are trying to handle the situation when you are disagreeing with yourself and you are the only identifier, i.e. when there may not be a probable_taxon or a community_taxon. I think what's needed there is an additional test that covers the case where you are identifying an obs with one withdrawn identification by another user, and then those lines that look up a previous identification need to only look up the previous identifications by the user who is adding the current identification.

Deleting an identification should update any other identification that was in disagreement to no longer be disagreements

I'm not entirely sure what this means. Could you provide a concrete example of when this seems appropriate? In my mind, deleting an identification should never change the disagreement state of other identifications. Identifications aren't really disagreements with other identifications. They are statements of what taxon the user thinks the observation depicts, and the disagreement is with another taxon, so if I say it's a flying fish and not a pickleweed, no one else's identification should change that statement.

While #2769 seems harmless and sensibly defensive, I'm pretty sure the more serious problem is at https://github.com/inaturalist/inaturalist/blob/main/app/models/identification.rb#L182, where we are trying to handle the situation when you are disagreeing with yourself and you are the only identifier, i.e. when there may not be a probable_taxon or a community_taxon. I think what's needed there is an additional test that covers the case where you are identifying an obs with one withdrawn identification by another user, and then those lines that look up a previous identification need to only look up the previous identifications by the user who is adding the current identification.

So I'm reading L182-184 to say: Find the most recent identification (current preferred). If that exists, set the previous_observation_taxon_id to match, otherwise set it to the observation's taxon_id (which may be null).
Nothing (right now) explicitly says to find the most recent Identification by the identifying user. Are you thinking we want to have previous_observation_taxon_id only reflect the taxa that the creator of the Identification has previously suggested?

I'm not entirely sure what this means. Could you provide a concrete example of when this seems appropriate? In my mind, deleting an identification should never change the disagreement state of other identifications. Identifications aren't really disagreements with other identifications. They are statements of what taxon the user thinks the observation depicts, and the disagreement is with another taxon, so if I say it's a flying fish and not a pickleweed, no one else's identification should change that statement.

Yeah, it wasn't worded great. My thinking was as follows: Take an observation with no identifications. If Alice suggests pickleweed, and then Bob suggests flying fish, Bob's identification is in disagreement with pickleweed. If Alice withdraws pickleweed, then Bob's identification is no longer disagreeing with anything. However, I can see how leaving the disagreement boolean as true would provide some historical context.

Are you thinking we want to have previous_observation_taxon_id only reflect the taxa that the creator of the Identification has previously suggested?

Only in the situation where there is no observation.taxon (aka the probable_taxon). That's what https://github.com/inaturalist/inaturalist/blob/8ec1f2ffd4f10cde558292277a79dfd62c8b1c8a/app/models/identification.rb#L180-L185 is currently trying to do, but I think it's currently broken b/c it's not looking for the identifier's previous ident, just any previous ident.

though I may have misunderstood what we are trying to accomplish.

Perhaps @tiwane can clarify, but my read is that the original bug is that a new identification is getting counted as a disagreement even if the single prior identification has been withdrawn at the time the new ident gets created. That seems like a bug to me b/c you're basically identifying an unidentified observation at that point. Someone else expressed an opinion but then withdrew it, so you're not disagreeing with anything.
However, if the prior identification was not withdrawn (was current), then you are disagreeing with something, and that statement should persist even if the original identification was withdrawn or deleted, both for record-keeping and because it still provides useful information in determining the community ID, e.g. if people in the future come back with more picklweed identifications.

Ok, I think we share the same understanding of the original issues.

[x] An identification added to an observation without any current identifications should not be a disagreement
Fixed by #2769

[ ] ~Deleting an identification should update any other identification that was in disagreement to no longer be disagreements~
We will leave the historic record of disagreement. With the fix above it should only be a true disagreement that occurred, even if the original identification it disagreed with was withdrawn.

As for the additional issue:
If we can address it simply by adding a user_id check to lines 182 and 183 (&& i.user_id == user_id), I'll add that in, otherwise should we break it off into a separate issue?

Perhaps @tiwane can clarify, but my read is that the original bug is that a new identification is getting counted as a disagreement even if the single prior identification has been withdrawn at the time the new ident gets created.

Yes, to me that's the bug here. I added the second part ("If original ID is deleted...") just as a further detail, in case it was helpful in debugging, I should have been more clear about that.

If we can address it simply by adding a user_id check to lines 182 and 183 (&& i.user_id == user_id), I'll add that in

Yup, that's what I'm proposing. Hopefully all specs will pass with that.


Update quick-create-cli.md

There is an error on the documentation:
oid=$(az ad signed-in-user show --query objectId -o tsv)
az keyvault create --hsm-name "ContosoMHSM" --resource-group "ContosoResourceGroup" --location "westus3" --administrators $oid --retention-days 7
should be
oid=$(az ad signed-in-user show --query id -o tsv)
az keyvault create --hsm-name "ContosoMHSM" --resource-group "ContosoResourceGroup" --location "westus3" --administrators $oid --retention-days 7

@rubenlopesms : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@Jak-MS Can you help here correct this?
Thank you

hi @msmbaldwin - when you have a minute, can you review this or reassign it to someone else? thanks.

Hi @rubenlopesms and thank you for catching this. We appreciate your contribution. #sign-off


Using 8.3 FileName while building boost on windows with MinGW

While building boost with MinGW; even though user.config.jam provides the path to archiver 'b2'
tries to find it based on the path to the compiler. In this process if the path contains any spaces or any other invalid characters that windows use for its long names, it derives a
incorrect path.
For example if the path is "C:\Program Files (x86)\CodeBlocks\MinGW\bin" the path derivation for archiever fails and b2 exits with failure.
To solve this we convert the path to 8.3 FileName format or windows short filename format which does not contain an invalid path characters.

if the path contains any spaces

Just for your information other packages may fail too: https://github.com/ruslo/hunter/wiki/error.spaces.in.hunter.root
@sumedhghaisas I've installed mingw g++ to directory with spaces and your version doesn't help :( Looks like similar fix have to be applied to url_sha1_boost.cmake.in scheme too. I've tested in with boost-filesystem example (see wiki about jenkins.py):
> set PROJECT_DIR=examples\Boost-filesystem
> set TOOLCHAIN=mingw
> set MINGW_PATH=C:\path to mingw\with spaces\bin
> .\jenkins.py --verbose

Also please apply next updates (see contribution):

Use spaces instead of tabs
Remove trailing whitespaces
Set destination branch to ruslo:develop

Let me know if you have any questions, thanks!

Also please set a short summary for the commit message. You can check how it looks using command: git log --pretty=oneline.

Sorry I am little bit tied up with other work. I will try to get back to this issue as soon as I get time.

@sumedhghaisas Thank, no problems :)

Closing this pull request to create a new one.


[BUG]: operationIds are not unique

Some operationIds have the same name, for example:

As far as I know, operationIds must be unique among all operations described in the API.
This issue is kind of messing with our implementation, because some endpoints are being ignored in our GraphQL schema due to duplicate operationIds and we cannot access all the data we need.
Thank you

The operations Ids that you have linked above are from different routes, viz. /workflow/search and /tasks/search`. This does not seem like a bug


Field Customizer:  onInit when navigating between lists

Category

[ ] Question
[ ] Typo
[x] Bug
[ ] Additional article idea

Expected or Desired Behavior
onInit is called once (and every time) when navigating to the list with column that has field customizer.
Observed Behavior
Standard Release

Called once after full page refresh
Called n+1 times when navigating to the list where n - number of times we navigated back.
More details on the 2d one.
Let's say there are List1 and List2. Field Customizer is applied to the column in List2.
Initial state - List2 AllItems.aspx, page refreshed.
Navigate to List1 and back to List2 using left nav - onInit called twice
Navigate to List1 and back to List2 using left nav once again - onInit called 3 times
and so on...

Targeted Release

Called once after full page refresh
Not called at all when navigating between lists.

Related to #3236 as well as #4057, #4056, #4054
I think all these issues are related to some fundamental problems with lifecycles.
Steps to Reproduce

Create simple Field Customizer
in onInit add alert
Create List1
Create List2
Create test column in List2 and apply field customizer to it
Test scenarios mentioned above

So, not sure if this is necessarily incorrect or not.  With the targeted release list views, the view is cached when you navigate back and forth, so the intialization is done on the first load, but then the components should be kept and reused when you navigate back to the list.  Previously there was less caching, and the controls would be torn down then recreated (and reinitialized).
Is there an actual bug here, in that your code can't function correctly? (Let's ignore the dispose issue for now).

@patmill - good question. If it's cached, and if I look at this issue with no connection to others... then, probably, Targeted Release behavior is correct. And should not lead to bugs, if 3d party code is written correctly.
#3236 is more important as Field Customizer can have logic based on current view.
So, I would say in terms of Field Customizer for me correct lifecycle behavior:

call onInit when switching to list/view
if the customizer is cached for list/view - onInit can be skipped
call onDispose at the moment when the cached object will be disposed

Let me know what you think

Added some details to #3236  as well.

Sorry for the delay - working with the dev who is fixing a variety of the list customizer related issues.  The plan is that onInit will fire only when the component is initialized.  If you switch back and forth between multiple lists, and the "fast nav" type of navigation occurs, the onInit will not fire if you return to the original list (or any list where onInit has fired).  This is because the objects will be initialized once and be reused when you return to the list.  However - switching between lists should fire onNavigate events, the context should always be correct when in the context of a given list, and the items selection change should fire when switching lists.  Dispose should be called when the whole app is torn down.
Does that match with your requirements?

Hey @patmill - yes, I think it will work for me.

@patmill - any updates on this one and related issues? :)

Has anyone come across a solution?  This is happening when I navigate between two specific libraries.  I am using the OOB Quick Launch exclusively to navigate.  There is no other custom navigation created. Thank you.

onInit fires when the customizer should be initialized. For example, when you navigate to the list or view with the field for the first time.
It will not fire again if you come back to the same list as the "state" is cached and there is no need to reinitialize it.


Integrated speech recognition with redux and the UI.

Run these changes here: https://github.com/ServiceInnovationLab/korerorero-reverse-proxy/pull/19
This wires the speech recognition into the chat bot. The mic was slow to start up on my machine, so I gave it a couple of seconds before talking.

For me, the Allow Microphone use pop-up appeared after the chatbot finished it's opening sentence. The once I clicked allow, the Start recording button is automatically pressed & when I replied to the question, it "registers" my answer & the Stop recording button is automatically pressed.


fix: vscode-remote support

#41
related doc

Note: Currently the forwarding mechanism in the Codespaces browser-based editor only supports http and https requests. However, you can interact with any TCP connection when connecting to a codespace from VS Code.

Since ws is based on TCP, it works.
But I didn't test whether Codespaces browser-based editor supports ws or not.

Tested on codespaces, the browser-based editor doesn't support ws.

Codespace is known to have issue on websocket forwarding, see https://github.com/orgs/community/discussions/3908. This issue should not block #41, because imo the official browser editor https://typst.app beats web codespace totally.


update patchelf.rb to '~> 1.1' in Gemfile. Replace instance variable access with call to .elf.

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

.elf was introduced in gem release v1.1.0.
Resolves  https://github.com/Homebrew/brew/pull/7678#discussion_r442090941

cc @sjackman @woodruffw

We don’t have version requirements for the other gems. Should we update Gemfile.lock instead?

We don’t have version requirements for the other gems. Should we update Gemfile.lock instead?

Perhaps both? We won't be able to function with versions of patchelf.rb below 1.1 from here on out, so it makes sense to me to enforce it in the Gemfile itself and also to check-in the relevant lockfile changes.
@rmNULL, could you do that?

Perhaps both? We won't be able to function with versions of patchelf.rb below 1.1 from here on out, so it makes sense to me to enforce it in the Gemfile itself and also to check-in the relevant lockfile changes.

Yeah, but it should always update to the latest in the lockfile, since setting HOMEBREW_PATCHELF_RB will always call install_bundler_gems!, which will always install the version specified in the lockfile.

For consistency with the rest of the Gemfile I agree with removing the version dependency.

Yeah, but it should always update to the latest in the lockfile, since setting HOMEBREW_PATCHELF_RB will always call install_bundler_gems!, which will always install the version specified in the lockfile.
I note that patchelf isn't currently specified in Gemfile.lock, so this means that it'll always be up to date assuming it doesn't conflict with other things in the lockfile.

Good points. No objections here!

If anything, we should:

remove the ENV variable test in Gemfile
commit patchelf to Gemfile.lock

This is fine because (and correct me if I'm wrong) we always check for HOMEBREW_PATCHELF_RB and call install_vendor_gems on all codepaths that would use patchelf.rb. This means that we no longer get dirty work trees when HOMEBREW_PATCHELF_RB is set, and anyone actually using the functionality will have the right gems installed on demand.
When we flip the switch so everyone uses patchelf.rb, we can use brew vendor-gems and commit patchelf.rb under vendor/.

This is fine because (and correct me if I'm wrong) we always check for HOMEBREW_PATCHELF_RB and call install_vendor_gems! on all codepaths that would use patchelf.rb. This means that we no longer get dirty work trees when HOMEBREW_PATCHELF_RB is set, and anyone actually using the functionality will have the right gems installed on demand.
When we flip the switch so everyone uses patchelf.rb, we can use brew vendor-gems and commit patchelf.rb under vendor/.

Yeah, this sounds preferable to me. I can't recall why we didn't do this in the first place, other than maybe not wanting to install patchelf.rb unconditionally on all Homebrew boxes. But we'll be doing that when we vendor eventually, so I don't think it's a huge deal.

Now that HOMEBREW_DEVELOPER implies HOMEBREW_PATCHELF_RB there's no reason to avoid committing to the lockfile anymore. But prior to that change I think it made sense.

Now that HOMEBREW_DEVELOPER implies HOMEBREW_PATCHELF_RB there's no reason to avoid committing to the lockfile anymore. But prior to that change I think it made sense.

Would it affect dependabot at all?

Would it affect Dependabot at all?

I asked since Dependabot can purge dependencies no longer used, and I wasn't sure how it did that internally.

I think dependabot basically does bundle update foo on the lockfile, so if we make the Gemfile more "standard" (not changing behavior based on environment variables) it'll make things easier for everyone, including the bots :)

make the Gemfile more "standard" (not changing behavior based on environment variables)

:+1: on this

Yeah, this sounds preferable to me. I can't recall why we didn't do this in the first place, other than maybe not wanting to install patchelf.rb unconditionally on all Homebrew boxes.

The conditional Gemfile was at Mike's request, and yes, that was the reasoning.


Improved ledger address confirmation and added confirm popups

Added function confirmPopup which shows a modal with the provided HTML
Now MPW will ask ledger users to confirm the address and transactions
Made the users go blind with bad CSS

tACK on my part! :tada:
I've done some slight cleanup, also done a small revamp on the new confirmPopup you've created, which is one super useful feature, a list of my changes in short:

Moved confirmPopup to misc.js (similarly to createAlert).
Added an optional HTML title field for popups, the header is hidden if one is not provided.
Refined the buttons: lower cancel opacity, swapped button sides, and aligned to the right of the modal.
Vertically centered the modal on the screen (it was previously at the very top of the screen).
The user's Ledger model is now displayed in applicable areas.


Python2 incompatibilities

Hi,
and many thanks for making miniver available!
I started to use miniver in a project which is still based on python 2.17 and noticed a few incompatibilities in _version.py; basically the use of f-strings (in other places, the older .format() is however still used) as well as a <unicode-string>.contains(). They are however straightforward to fix and now it works beautifully in the older python as well (and under MacOS X, by the way).
I also turned a '-dev' component of the constructed version string into '.dev'; setuptools complained about the hyphen and made that replacement when using the version string.

Just realised that I had to change the code in setup.py as well. Maybe the _setup_template in install_miniver should also be updated?

Hi!
I only just saw this; sorry for the delay.

I also turned a '-dev' component of the constructed version string into '.dev'; setuptools complained about the hyphen and made that replacement when using the version string.

Yeah, I was trying to more strictly adhere to semver, which dictates that:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.

But given that we're only concerned with Python projects probably it does indeed make sense to prefer PEP440.

@cmarquardt thanks for the work that you put in to this! Especially the adherence to PEP440 and fixing the inconsistencies in the use of f-strings vs format.
I thought for a bit about this, and I'm not really sure that I want to include the Python 2 support.
Python 2 will reach its end of life in 2020, and I think that we should encourage the use of Python 3 by making our tools Python 3 only.
Of course I'm happy to add a note to the README pointing to your fork!

@cmarquardt I just opened #3 that incorporates your fixes for the f-strings and PEP440 formatting, but leaves out the Python 2 compatibility.
As these are your changes I set you as the commit author. Is this ok?

Hi,
no worries - and thanks for looking at the pull request at all! Please feel free to take what you find useful.
On the python 2 support - yes, I understand your point. If it's ok for you, I rename the fork to something like minver2, point to your project as the authoritative original, and state that mine is a friendly fork with the sole purpose of supporting the migration of existing python 2 projects to python 3. I'll occasionally check for updates on your side and merge them into the python 2 version until the latter becomes obsolete. Would that be ok?

Sure no problem!
I'll close this MR now.

Great - thanks a lot! The URL has changed, it's https://github.com/cmarquardt/miniver2 now...
Thanks a lot!


Fix missing elements in fflonk calldata

Hello, thanks for this project. I noticed that the fflonk calldata isn't complete so I've added the missing elements and fixed the tests so that it checks that the calldata verifies in the solidity output.
Hopefully the upstream snark js issue gets merged https://github.com/iden3/snarkjs/pull/464

This is awesome, thank you! I will merge it today soon 🙏🏻


chore(main): release 1.0.0

:robot: I have created a release beep boop
1.0.0 (2023-08-18)
Features

集成 release-please (649f778)

Bug Fixes

修改 github action 目录名 (f11bfb6)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/lwsgh/release-please-example/releases/tag/v1.0.0 :sunflower:


Add quotes around example option

PR checklist

[ ] Addresses an existing issue: #0000
[ ] New feature, bugfix, or enhancement
[ ] Includes tests
[x] Documentation update
[ ] Enable CircleCI for your fork (https://circleci.com/add-projects)

What changes did you make?
Fix example configuration
Is there anything you'd like reviewers to focus on?
(optional)

Thanks for your interest in palantir/tslint, @vgrigoriu! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

index.html is generated. Can you edit arrowParenRule.ts, line 38?

index.html is generated. Can you edit arrowParenRule.ts, line 38?

Here you go.

Here you go.

@vgrigoriu thanks!

@vgrigoriu thanks!


Linux dist requires root

Since it doesn't include any dependencies you have to install them with apt-get which requires root.
It would be great to make a linux build that includes everything the core needs, like we do for Mac and Windows.

electron version solves this


[WIP] Dashr needleplot

Issue for app: #[issue number here]
App pull request

[x] This is a new app
[ ] I am improving an existing app (redesigns/code "makeovers")

About

Playground deployment URL (new version):
Current gallery app URL: https://dash-bio.plotly.host/dash-needle-plot/
Python app repository link: https://github.com/plotly/dash-bio/blob/master/tests/dashbio_demos/app_needle_plot.py

Workflow

[ ] I have created a branch in the appropriate monorepo, and the
elements necessary for successful deployment are in place.
[ ] If the app is a redesigned and/or restyled version of an
existing gallery app, I've summarized the changes requested in the
appropriate Streambed issue and confirm that they have been applied.
[ ] If the app is on the Dash Gallery portal, I have added a link to
the GitHub repository for the source code in the portal description.
[ ] If the app is a reimplementation of a Python gallery app for the
DashR gallery, the app in this PR mimics, as closely as possible,
the style and functionality of the existing app.=
[ ] I have removed all Google Analytics code from the app's
assets/ folder.

The pre-review review
I have addressed all of the following questions:

[ ] Does everything in my code serve some purpose? (I have removed
any dead and/or irrelevant code.)
[ ] Does everything in my code have a clear purpose? (My code is
readable and, where it isn't, it has been commented appropriately.)]
[ ] Am I reinventing the wheel? (I have used appropriate packages to
lessen the volume of code that needs to be maintained.)

Nice work! :dancer:


Xfail async test on Windows.

The swifttailcc convention is not supported on Windows right now.

@swift-ci smoke test and merge

@swift-ci smoke test Windows

Unrelated lldb test failure on macOS: lldb-shell :: Reproducer/Swift/TestBridging.test

@swift-ci smoke test macOS

Windows PR tests passed, which is all that matters here. Merged.


added about component and moved styles

Acceptance criteria for 1

[x]  Mentor is added to pr
[x]  AC copied to pr description
[x]  link to deployed version added to pr
[x]  About block (text and image) added to the main page
[ ]  On the widths 390px and 1280px, the site layout corresponds to the design

Acceptance criteria for 1*

[x]  Created separate component About
[x]  Its styles added to .module.css
[x]  For App.tsx styles moved to App.module.css

link to deployed

it is better to place the picture in the center


Review Users resources branch

Code and documentation from https://github.com/slipstream/SlipStreamServer/issues/1239 as written by Konstantin

wring repo


Vinegar doesn't properly apply itself.

Investigated more.
It decrements the amount of gum heart containers, but not the current amount of gum health.
Probably easy enough to fix.

oops, this isn't in release.

ok now it's in release whoops oops whoops oopsie


RFC: std::string::String could provide options about UTF BOM

std::string::String should :

correctly accept byte stream with or without UTF BOM,
when converts to &str or [u8], should be with or without UTF BOM by caller.

p.s. I am not native English speaker, so may what I describe may differ from my original meaning.

Hey there. Thank you for your interest in designing Rust!
I think you can find more interest in the issue if you post it over at: https://internals.rust-lang.org/ :)

String and &str are explicitly designed to store UTF-8 data, so parsing/storing/emitting a BOM doesn't quite make sense. Its use in UTF-8 text is even explicitly discouraged by the Unicode standard itself, as it's essentially useless and it also breaks ASCII-compatibility.

Copy of my comment on https://github.com/rust-lang/rust/issues/50386#issuecomment-386035566
It’s not clear what is being proposed. Which APIs exactly should strip?
And more importantly, why? I tend to think of these standard library API as low-level primitives, and feel that BOM removal would tend to belong more in a higher library that might for example also support multiple encodings and detect the presence of a BOM to help pick one. And even then, maybe not always. https://docs.rs/encoding_rs/0.7.2/encoding_rs/struct.Decoder.html#impl has different methods for different use cases, only some of them remove a BOM.

@H2CO3 @SimonSapin
UTF8 with BOM should be accepted. What I want is just to let BOM go, not disturbing other components.
And it's rather difficult to determine BOM for it does not show up in println!.

String shouldn't have magic treatment for any characters. It makes sense for encoding/decoding methods to have options for handling the BOM, such as those @SimonSapin mentioned, but none of that should happen internally to String.

We may consider adding a method like
pub fn from_utf8_with_bom(vec: Vec<u8>) -> Result<String, FromUtf8Error>

But like comments below, this shouldn't affect String internal.


Added disabler SMG!

About the PR
Added disabler SMG, you can print it on security techfab when you researched advanced riot control technologies.
Why / Balance
Will be useful for security personnel.
Technical details
Disabler SMG has fire rate 4 shoots per second. Disabler SMG uses new type of ammo - that has 2 heat damage and 15 stamina damage. That means that you should fire a shot 7 times for make stamina crit to someone. It has charge for 30 shots and full/semi-auto firing modes.
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl: Stanislav4ix
Added disabler SMG! You should research advanced riot control and then you will be able to print it on security techfab.

More sec content is good, actually

I think the smg could be a possibility if it fires much faster but each shot is also 1/3 the power of a normal disabler. Using fire rate and disabler shots on screen to disable someone if you aint that accurate at the cost of requiring more hits.

This needs a video because it's not really clear how fast this fires and downs people and there is no mention of how the spread is handled.
Imo this is fine, if silly and allows for really low TTKs on armored targets, just needs a bit of spread so it's not overtuned.

This needs a video because it's not really clear how fast this fires and downs people and there is no mention of how the spread is handled.
Imo this is fine, if silly and allows for really low TT_K_s on armored targets, just needs a bit of spread so it's not overtuned.

I will make a video, but for now I will say that it takes the same amount of time (not shots) as a disabler for a person to fall

this is sick but im wondering if this should go into t3 tech or not, might need discussion

Adding a rapid fire, mass producible, disabler is a huge balancing issue. While it could be potentially balanced in the current PR, it could become completely overpowered with one or two tweaks.

Adding a rapid fire, mass producible, disabler is a huge balancing issue. While it could be potentially balanced in the current PR, it could become completely overpowered with one or two tweaks.

can I ask what you mean by this? any gun can indeed become overpowered in a few tweaks, such is the nature of a weapon of that variety

Adding a rapid fire, mass producible, disabler is a huge balancing issue. While it could be potentially balanced in the current PR, it could become completely overpowered with one or two tweaks.

It is perfectly balanced, because it takes the same amount of time for a person to fall, and during this time it will cause less damage than the disabler. One disabler shot deals 5 heat damage and a disabler SMG shot deals 2 heat damage. That is, 4 shots from the disabler (that's enough for a person to fall) will cause 20 thermal damage, while 7 shots from the disabler SMG will cause only 14 thermal damage. Therefore, I believe that this weapon is perfectly balanced in two ways

Adding a rapid fire, mass producible, disabler is a huge balancing issue. While it could be potentially balanced in the current PR, it could become completely overpowered with one or two tweaks.

can I ask what you mean by this? any gun can indeed become overpowered in a few tweaks, such is the nature of a weapon of that variety

It is perfectly balanced, because it takes the same amount of time for a person to fall, and during this time it will cause less damage than the disabler. One disabler shot deals 5 heat damage and a disabler SMG shot deals 2 heat damage. That is, 4 shots from the disabler (that's enough for a person to fall) will cause 20 thermal damage, while 7 shots from the disabler SMG will cause only 14 thermal damage. Therefore, I believe that this weapon is perfectly balanced in two ways

Specifically with guns that can stun, it can be a huge problem to have something so widely available. An old fun combo is a toy LMG + foam riot darts. Both mass producible and they can stun relatively fast. Thankfully the way to mass produce them was locked behind a lot of tech trees and were stuck to lathes that required plastic and you needing to manually reload the mag.
Putting this kind of weapon in the sec lathe is still a huge balance issue.
While any gun can be tweaked yes, it adds another one to the pool. Having too many to keep track of, at least player facing ones, can be a huge pain to balance for future considerations. Let's say if stamina damage was tweaked or disabler blasts themselves were tweaked, it could make this extremely broken.
I do not believe we need any more stun weapons and should focus on what we have currently.
If we absolutely need this, as much as I hate cargo reliance, it should be locked behind ordering in cargo with a few crates. At least then it could be controlled via ordering instead of allowing a mass print.

Adding a second ranged stunning weapon seems hard to justify, especially one that's mass producible
What role is this weapon meant to serve and why can't the disabler be used to fulfil that role? Simply saying "it'll be useful" isn't sufficient justification IMO

I could see a compromise being to give this to the armory, it has same time to stun as disabler but is more forgiving since it rapid fires

I could see a compromise being to give this to the armory, it has same time to stun as disabler but is more forgiving since it rapid fires

disablers are balanced right now by not being weapons you can guarantee landing a bunch of shots with - they're  better for a chase, but aren't impossible to avoid if you juke well
this weapon circumvents that by being an automatic weapon, which is something you can't really juke unless you're practically offscreen
this being a roundstart weapon is pretty imbalanced

if theres only one in the armory it would be fine imo, considering sec is generally underpowered right now

Just do a test merge and revert if it's too busted
Personally a disabler SMG would be more forgiving to use with high ping compared to the normal disabler

im kind of interested in seeing this, definitely as a tech i think though

I could see a compromise being to give this to the armory, it has same time to stun as disabler but is more forgiving since it rapid fires

disablers are balanced right now by not being weapons you can guarantee landing a bunch of shots with - they're better for a chase, but aren't impossible to avoid if you juke well
this weapon circumvents that by being an automatic weapon, which is something you can't really juke unless you're practically offscreen
this being a roundstart weapon is pretty imbalanced

isn't that a whole point of.... research and equipment upgrade? disabler smg aren't round start and are locked behind research, they are rapid fire and are easier to use for people with poor aim. the stun time is still the same so it's only an improvement regarding accuracy forgiveness

this should have lower ttk and be t3 research imo

i guess you get to stun 2 additional people before needing to recharge it
disabler : 4 shots to stun - 10 shots in battery = 2 stun
disabler smg : 7 shots to stun - 30 shots in battery = 4 stuns
and both require 2 seconds of constant firing in order to stun, and all shots need to lands(i suppose the smg have some deviation)

this should have lower ttk and be t3 research imo

makes no sense, because in t3 we have taser

that was removed

the only god damn difference between a disabler and the smg disabler is the accuracy forgiveness AND more stun critable target before recharge, this does not need to be locked behind T3, because all T3 are meant to be balance breaking in some ways

that was removed

ok then i will move disabler SMG to t3 research

If this functions like it does in /tg/ (a sidegrade to the regular disabler) then it should not be a T3 at all. T3 techs are meant for overpowered and round-changing techs, which the automatic disabler most certainly does not fit the criteria of.

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

yes, and no one will want to research arsenal technology just for disabler SMG

it should be made worth using then, just a disabler for people with krill issue (pro hos that cant aim) wouldnt be worth getting.

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

yes, and no one will want to research arsenal technology just for disabler SMG

because you think science will research a T3 and lock themselves out of every other T3 tech branches? T2 is fine and doesn't lock science. imagine there could be sec officers with that bad boy AND bag of holding

typically a thing like this would only be researched during nukies or revs. outside of that the mentality is sec already has disablers so they dont need anything else, up until nukies knock on our door then research every arsenal tech.

it should be made worth using then, just a disabler for people with krill issue (pro hos that cant aim) wouldnt be worth getting.

every "upgrades" doesn't need to be +1 in every stats you know?

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

a normal disabler that does not require good aim is a very very very strong weapon as that is the downside of a disabler

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

a normal disabler that does not require good aim is a very very very strong weapon as that is the downside of a disabler

but both weapons needs 2 seconds of constant firing to stun, the fire rate only balance the lower stun damage you doofus

and the deviation wont guaranty you'll land all your shots despite the fire rate

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

a normal disabler that does not require good aim is a very very very strong weapon as that is the downside of a disabler

but both weapons needs 2 seconds of constant firing to stun, the fire rate only balance the lower stun damage you doofus

landing four shots in a row with a disabler is rather difficult on a strafing and fleeing suspect because of the nature of this game’s combat
landing seven shots with an automatic weapon is an easier task
you are probably going to down them quicker because it is more forgiving to miss shots and it is easier to land shots with an automatic weapon

this is a pointless argument I am banging my head against a brick wall and the relevant people have given this a go ahead so I will not rely further have a good day

that was removed

ok then i will move disabler SMG to t3 research

the SMG isn't worth T3 placement at all, T3 research are meant for items that doesn't require balancing, as of right now it's just a normal disabler that is more forgiving for the user accuracy

a normal disabler that does not require good aim is a very very very strong weapon as that is the downside of a disabler

but both weapons needs 2 seconds of constant firing to stun, the fire rate only balance the lower stun damage you doofus

landing four shots in a row with a disabler is rather difficult on a strafing and fleeing suspect because of the nature of this game’s combat
landing seven shots with an automatic weapon is an easier task
you are probably going to down them quicker because it is more forgiving to miss shots and it is easier to land shots with an automatic weapon

dude, it's SMG.  If you think like that, the full-auto shooting mode for the Bulldog makes it very easy to kill someone.  Like, this is SMG, what else should we expect from it?  And you can also switch between semi-auto and full-auto shooting modes

plus keep in mind that disablers are: roundstart, purchasable in bulk from cargo, unlockable in secfab to print them using resources collected or requested by cargo.
making the SMG T2 is honestly stretching the upgrade format just a little bit, but overall fells like it should still require some work

I've toyed around with rapid fire disablers as admemes  few times. My 2c, is that they're not really that much amazinger.
That said, what I think would be better, is changing the burst fire rate to actually fire a quick burst but then have a longer cooldown between bursts. Its the ideal case for this sorta thing.
Unfortunately right now burst fire is just full auto if you click fast, or terrible. It needs to be reworked to have a real burst functionality.

...considering sec is generally underpowered right now - emisse

Sec isn't underpowered, they've lost their 2-hit batons and better armor but gained roundstart pistols, 12 damage knives, and things like secfab, while retaining the overpowered equipment-check mess like flashes and flashbang, playing sec also doesn't feel like the dept has weak gear for dealing with tasks they are assigned.
Having the disabler SMG (will be referred to as "SMG" from now on) roundstart invalidates its purpose as a flat upgrade kind of item, it is also unclear what is the use case for the SMG on roundstart, which may just lead to the HoS snagging it roundstart.
Now unrelated to quote, the SMG doesn't exactly have the same TTK as the normal disabler in practice, in theory it does as a disabler shoots out 30 stamina damage twice a second, while the SMG shoots out 15 four times a second, when you start accounting for player input this becomes more evident, the most obvious example being how disablers aren't full auto and how people miss disabler shots very often, at this point the SMG is looking more like an upgrade because you actually get to utilize the really low TTK instead of hitting 2 shots out of 5 with ever so slight delays.
This item remains as a sidegradey upgrade to the disabler, it's better in most use cases and a lot more forgiving, having it as T1 raises potential issues with how these can be mass produced, having it as T3 has it underpowered and it'll never see the sun because nobody will research it, so the compromise would be having it as T2, preferably placed in the same research as some other sec items because the item is middling between T1 and T2 in terms of strength. I agree with this compromise.

too many words not enough merg...


Possible regression in .QueryAllRawEvents with .In operator

Hi, I've tried to upgrade from v6.4 to v7.5 and encountered what I think is a regression.
We have the following query:
session.Events.QueryAllRawEvents()
    .Where(e => e.Id.In(eventsIds))
    .Where(e => e.AnyTenant());

In v6.4 it produces the following SQL (which works fine):
select data, type, mt_dotnet_type, seq_id, id, stream_id, version, timestamp, tenant_id, is_archived from public.mt_events as d where ((d.id = ANY(:p0) and  1=1) and  d.is_archived = FALSE)

but in the latest v7.5 it produces SQL checking d.data ->> id, which I believe is incorrect since it should check the ID column instead of going to data:
select data, type, mt_dotnet_type, seq_id, id, stream_id, version, timestamp, tenant_id, is_archived from public.mt_events as d where (1=1 and CAST(d.data ->> 'Id' as uuid) = ANY(:p0) and d.is_archived = FALSE);

As I understand, .QueryAllRawEvents should query IEvent properties (ID column in this case), not the data itself.
Thanks!

Bug. Not a use case where we have a test at all apparently.


Chore: Remove custom transport

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

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


Refresh visual editor on save doesn't work on Vercel

Preview isn't refreshed with new content inside visual editor when project is hosted on Vercel

Expected Behavior
Data should updated when user hit "save" button
Current Behavior
Data isn't updated and new page return an error 404 on visual editor. Hit the button "save" with localhost in visual editor trigger the reload has excepted
Video reproduction
Steps to Reproduce

Follow the tutorial to create a project using Storyblok with Astro
Add vercel adapter
Deploy to Vercel and add URL to your editor
Try to update content and save

// astro.config.mjs

export default defineConfig({
	trailingSlash: "ignore",
	build: {
		format: "directory",
	},
	redirects: {
		"/formations/approches": "/formations",
		"/formations/themes": "/formations",
	},
	integrations: [
		tailwind(),
		storyblok({
			accessToken: "my-token",
			components,
			apiOptions: {
				region: "eu"
			},
			customFallbackComponent: "components/sections/sectionEmpty/index",
			enableFallbackComponent: true,
			bridge: true,
		}),
		react(),
	],
	experimental: {
		viewTransitions: true,
	},
	output: "server",
	adapter: vercel(),
});

Hi @MKlblangenois,
I've just tried to reproduce this behavior, but in my tests, the Bridge works completely fine when using the Vercel Adapter for SSR.
Here's the example repository I used: https://github.com/manuelschroederdev/astro-vercel-adapter-test
Deployed here: https://sb-astro-vercel-adapter-test.vercel.app/
Regarding the 404s: did you create a catch-all route such as [...slug].astro? If not, the errors are expected.

Hey @manuelschroederdev
Thanks for your reproduction!
Yes, I've a [folder]/[...path].astro that should catch-all route, I've tried to set it as [...slug].astro on root of pages, but I got the same issue.
This is my code for [...path].astro :
export const getStaticPaths = async () => {
	const stories = await getAllStories();

	if (!stories) {
		return {
			notFound: true,
		};
	}

	const paths: any = [];

	stories.map((story: any) => {
		const avoided_full_slug = "formations/";
		if (!story.full_slug.startsWith(avoided_full_slug) || story.parent_id !== null) {
			const item = {
				params: {
					folder: story.full_slug.split("/")?.length > 0 ? story.full_slug.split("/")[0] : story.slug,
					path: story.is_startpage || story.full_slug.split("/")?.length <= 1 ? undefined : story.slug,
				},
				props: {
					full_slug: story.full_slug,
				},
			};
			paths.push(item);
		}
	});

	return paths;
};

const { folder, path } = Astro.params;

const story = await getStory([folder, path].filter((x) => x).join("/") || "home");

export const prerender = true;

/**
 * Get all Storyblok stories.
 *
 * Due to limit of 100 stories per request, we need to make a loop until there's no more stories.
 *
 * @param {ISbStoriesParams} [filters={}]
 * @return {any} The Storyblok stories.
 */
export const getAllStories = async (filters: ISbStoriesParams = {}) => {
	const params: ISbStoriesParams = {
		version: "draft",
		excluding_slugs: "site-settings,home,testimonials/*",
		cv: +new Date(),
		...filters,
	};

	try {
		const { data } = await client.get("cdn/stories", params);

		if (data?.stories) {
			let stories = data.stories;

			while (data?.links?.next_page) {
				params.page = data.links.next_page;

				const { data: nextData } = await client.get("cdn/stories", params);

				stories = [...stories, ...nextData.stories];
			}

			return stories;
		}
	} catch (error) {
		console.error(error);
	}

	return false;
};

[!NOTE]
getStory and getAllStories use both useStoryblokApi() and "draft" as version.


Unable to return non-HAL results after disabling default JsonOutputFormatter

Fix for https://github.com/visualeyes/halcyon/issues/54
Since we're replacing the JsonOutputFormatter, pass outputs that we can't handle (i.e. non-HALResponse types) to the JsonOutputFormatter.

Hmm...while this works (i.e. it resolves the 406), just realizing that when requesting "application/hal+json" this returns plain json with an "application/hal+json" content-type.  I don't think that's desirable, but could use some feedback.

Great job, thanks @jmpease!


How to update the CLDR version

Hi @deankarn
It is been a while since you updated this repo to CLDR version 32.0.1, currently, the latest stable version is 36.0.0 which released last Oct. If you are not available, I'd like to help the work if you could share the steps on updating the CLDR for go-playground/locales
many thanks,

Hey @cchung100m here are the instructions https://github.com/go-playground/locales/tree/master/cmd
sorry for the lateness of my reply

@deankarn
Thanks for the reply. I would update it once I am available. :)


fix ludii name

Types of changes

[ ] Docs change / refactoring / dependency upgrade
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context / Related issue
wasn't this a bug ?
How Has This Been Tested (if it applies)

Checklist

[x] The documentation is up-to-date with the changes I made.
[x] I have read the CONTRIBUTING document and completed the CLA (see CONTRIBUTING).
[x] All tests passed, and additional code has been covered with new tests.

Fixed in #18 .


using f2py to fill in the gaps

Hey all, so since getting my python 3 version working, I have been struggling to figure out a way to get the rest of the functions in the exclude list for the wrapper working. I really want to be able to write out CK kernels (ckw0# functions) using pyspice, I even went so far as to start  a rewrite of the entire spice library in python, which is kind of nuts I admit. But earlier today I successfully figured out how to use f2py (http://cens.ioc.ee/projects/f2py2e/) to get a few of those functions working, for example mxmtg and mxvg. All I really needed to do was add a few "intent" lines to both fortran files for the "out" matrix/vector. It should be possible to do this for the entire fortran toolkit, I just haven't written any code to do this for me. Would it be possible to combine the c wrapper with the parts generated by f2py?
Also on an aside, I am not too familiar with how c works, but why is this wrapper wrapping the functions that end with "_c.c", which are just wrappers of the f2c generated code files which end is just ".c". Since python is written in C, wouldn't it be better to wrap the f2c generated code? Maybe because we are preserving Spice types (ie SpiceDouble)?
Edit: I didn't write what I meant to ask here, I was thinking since the .c files are already pure C code (or mostly so), wouldn't it be easier to wrap those functions instead of wrapping the _c.c ones?

I completely forgot about this issue I posted, I will close it now.


escaping hifen

I'm trying to trim minified files that have "-min" at the the end of their name.
i'm using this command: renamer -d --find "-min" *
the problem is renamer is taking -m as an option and obviously fails with unkown option error.
I've tried to escape the hiphen with ^ but it doesnt work...

try renamer -d --find=-min *

It works!
Thanks!


When should REVERT op refund remaining gas?

The following code:
https://github.com/khipu-io/khipu/blob/b5eec4cdfd46373c6c657ef9e51101c04d0afbc7/khipu-eth/src/main/scala/khipu/vm/OpCode.scala#L1226-L1230
refund remaining gas for most transactions, except:

Tx 0xe62a2b4e348e805ec4bddd4dbf9ae9bcf278622ddc5d5a49ff68f8c994e9d36f of block 6020296
Tx 0x6365b34fdc9c4c8024152d18d32b0df581606dbc114b752b2aa51d7453d23e7c of block 6410554

Where is error from?
Which client software caused?
Which miner caused?
Or, my bug

It's my bug. For example, during tx
0x6365b34fdc9c4c8024152d18d32b0df581606dbc114b752b2aa51d7453d23e7c
of block 6410554

the parameters of REVERT are out of bound, should throw exception and cause no refunds of remaing gas.


Error when used within v-else-if

Part of my component looks like this:

  <div v-if="loggedIn || article.restrictions.length < 1" v-html="$options.filters.parseMd(article.content)"/>

      <fa :icon="['fas', 'lock']"/>

      Some warning

The lock icon is rendering correctly, but I'm getting the following error messages in the console:

Parent: [Many lines, highlights the div that contains fa]
Mismatching childNodes vs. VNodes:

[Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside , or missing . Bailing hydration and performing full client-side render.

It seems that this is because the fa icon element is nested inside a conditional block? If I remove it out of the conditional div the error goes away. what am I missing?
Update: if I switch vs-else-if for v-if the error goes way; what gives?

I'll take a closer look, but it seems the problem is not with this plugin or font-awesome, but with with nuxt itself

@vaso2 - thanks. Ill try to do a few tests myself with my limited knowledge. I’m not sure Vue is that smart, but perhaps it fails because the clauses are not necessarily exclusive? Hence why v-if works and v-else-if doesn’t (far fetched, I know)

Looks like this bug: https://github.com/vuejs/vue/issues/11299

I've found this issue with both v-if and v-else-if, both of which can be resolved by using v-show instead.


Send action changeDate.

Currently if we want to do something every time the date changes we
need to use observers, with this approach we can avoid the use of
observers encouraging the use of Actions Up, Data Down.

Thank you for your contribution! At the moment the add-on follows the same strategy that all other Ember input fields use - you bind property to the input field and if you need to do something when the property changes its value, you use observers.
What's the main reason not to use observers?

The input helper has an action that fires when the user makes an edit so you don't need to use observers
http://guides.emberjs.com/v1.11.0/templates/input-helpers/

@solsberg that does not work on this scenario, probably because the action is not really happening on the input.

@soulim observers are expensive and lead to code which is hard to maintain and reason about  code, for example checking if  a value is null or not, with this pattern we avoid that. For upcoming versions of Ember this is the recommended pattern instead of observing

@abuiles Exactly! My comment was intended to be in support of this PR as providing a similar pattern

@solsberg :+1:

Okay, I've got your point. Thank you for the explanation. It will be awesome to add actions support to the add-on.
@abuiles can you also update README? I think this feature needs a short explanation and a code example. You could make a separate section and use "Available options" section as example.
Please squash all commits, when you are satisfied with results.

Thank you @abuiles! :+1:

I would be super grateful if either @soulim or @abuiles could explain how this works in practice!

@westlywright this's an example for you.
Just imagine you a template that uses the component and a controller where you would like to do something with a selected date.
{{!-- app/templates/foo.hbs  --}}

{{bootstrap-datepicker value=model.expiresAt}}

// app/controllers/foo.js
import Ember from 'ember';

export default Ember.Controller.extend({
  actions: {
    changeDate: function (value) {
      // ...
    }
  }
});

Every time you select a new date using the component it will send changeDate action and the controller will handle this action. So you don't need to use an observer to monitor changes of expiresAt value.

@soulim any plans for a new release which will incorporate this functionality?

@solsberg just released 0.5.2 that includes this feature and a couple more interesting things.


 I'm trust you :wink:

Thanks! I'm planning on continuing to support these and fix bugs with them as I use them. https://github.com/Asana/tsutil is already starting to use them.


dependency: remove atomicwrites package

may fix #30765
comma@comma-33e0a0c6:/data/openpilot$ python common/tests/test_file_helpers.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.002s

OK

Can you rebase? There's a conflict with the poetry lockfile now.

Thanks for contributing to the dependency removal project :)
Wanna try the pycurl one?


A problem with npm and webpack

Chart.Zoom.js requires hammer and chart modules:
var Hammer = require('Hammer');
var Chart = require('Chart');

but webpack cant find it, because modules are hammerjs and chart.js. It should be:
var Hammer = require('hammerjs');
var Chart = require('chart.js');

or am i missing something?
Error log:
ERROR in ./~/Chart.Zoom.js/src/chart.zoom.js
Module not found: Error: Cannot resolve module 'Hammer' in /var/www/vvs/node_modules/Chart.Zoom.js/src
 @ ./~/Chart.Zoom.js/src/chart.zoom.js 2:13-30

ERROR in ./~/Chart.Zoom.js/src/chart.zoom.js
Module not found: Error: Cannot resolve module 'Chart' in /var/www/vvs/node_modules/Chart.Zoom.js/src
 @ ./~/Chart.Zoom.js/src/chart.zoom.js 6:12-28

@rokasmi can you PR those changes?


NPC2 and Hazard always have friendly color

No matter the token setting (friendly/neutral/hostile) NPC2 tokens and Hazard tokens always show the friendly color
In the image below this NPC2 is hostile but is showing a friendly green color

Closed as part of old issue cleanup. If you believe this issue hasn't yet been addressed, please re-open it and leave a new comment.
https://github.com/foundryvtt-starfinder/foundryvtt-starfinder/discussions/1148


Deprecate Kubernetes 1.24 dev package bundles

Deprecating Kubernetes 1.24 dev package bundles.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/Woof


Use job summary to improve build output

Recently, GitHub released a new feature for workflows: job summaries.
The org-wide-files workflow that creates the PRs to the tracks is a perfect candidate for using this workflow I feel. It could output a table listing the repos and with a link to the created PR, as well as some additional metadata (whether or not the PR already existed, whether it is a track or tooling repo, etc.).

Absolutely, this would be perfect for the configlet workflow.


Upgraded app to 3.1 but azure app service thinks its still on 2.2

Today I've upgraded an app from dotnet core 2.2 to 3.1
Everything is fine when running locally, but when I attempt to right-click "Deploy to web app..." I get a message that it failed to deploy path that does not exist
/Users/Alex/Sites/Pegcon4/Pegcon/bin/Release/netcoreapp2.2/win-x86/publish
I can't see where it is getting that old path from?

@n-alex-white check the .vscode folder at the root of your workspace. The setting "appService.deploySubpath" controls what folder is deployed and the setting "appService.preDeployTask" controls what task is run before deploy. You probably need to update the subPath setting and the tasks in tasks.json


[BUG] Inconsistent Observation Networks

Describe the bug
We need to standardize how we handle observation networks.
We have the following options:

Have both critic and policy networks update the obs network vars. This would mean that the critic loss and policy loss would compete when updating the observation networks. This could hurt performance.
Have either policy or critic loss update obs networks - need to use stop_gradients carefully here.

Current PPO PR uses option 2 (only critic loss to update the obs variables  - if self._use_single_optimizer=False https://github.com/instadeepai/Mava/blob/cc86102881e5b2799ba78e22877b284a201ce875/mava/systems/tf/mappo/training.py#L520 , while ddpg and d4pg use option 1 (https://github.com/instadeepai/Mava/blob/e00724a84001b8ca9f00d3230d998c786d9d7928/mava/systems/tf/maddpg/training.py#L461).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Consistent, correct handling of obs network vars.
Context (Environment)

Proposal for a fix
Consistent, correct handling of obs network vars.  Possible use utility function.
Definition of done
When all systems handle obs network vars the same way.
Mandatory checklist before making a PR

[ ] The success criteria laid down in “Definition of done” are met.
[ ] Code is documented - docstrings for methods and classes, static types for arguments.
[ ] Code is tested - unit, integration and/or functional tests are added.
[ ] Documentation is updated - README, CONTRIBUTING, or other documentation.
[ ] All functional tests are green.
[ ] Link experiment/benchmarking after implementation (optional).

Links / references / screenshots

Closing all TF issues as we are depreciating our TF systems.


Fix merge of #4468 into master

@obastemur FYI
I will merge this once I have the green light of the CI

@Cellule Thanks for this.


stable diffusionv2 训练有适配计划吗？

If this is your first time, please read our contributor guidelines: https://gitee.com/mindspore/mindspore/blob/master/CONTRIBUTING.md
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Hi, pls check the updates of this repo https://github.com/mindspore-lab/mindone/tree/master/examples/stable_diffusion_v2


Histograms

WIP. Not ready to merge but here are preliminary efforts.

ready for review @howardchung

@howardchung I pushed changes based on comments. Let me know if anything important is missing.


Even after running the localhost:5000 port is saying requested url not found.

from apschedulerui.web import SchedulerUI
scheduler = BackgroundScheduler()
ui = SchedulerUI(scheduler)
ui.start()  # Server available at localhost:5000.```

This is the code that I ran and the result on the page localhost:5000 is saying Not Found.

See my response in #2 and let me know if this solves it for you.
My guess is the process ended, since you're using a background scheduler, and that's why you don't see the UI when you visit localhost:5000. You need to [choose the right scheduler|https://apscheduler.readthedocs.io/en/stable/userguide.html#choosing-the-right-scheduler-job-store-s-executor-s-and-trigger-s] for your project first.

Closing this, as this was solved in #2.


Don't include 'stripe_account' on AccountLink call

This is already provided as the 'account' param. By including stripe_account in the call, the Stripe API call fails.
Happy to tweak the implementation - but this is currently broken.

@ExpDev07

Think perhaps it should be set to false as default, and then in ManagesPayout, set to true only in those methods.

Think perhaps it should be set to false as default, and then in ManagesPayout, set to true only in those methods.

Oh, I was just trying to limit the amount of change.  By setting the param true by default, it'll not affect the if block. So by setting the param to false from the accountLinkUrl method, we're saying:
if(true && false) {

Where $this->hasStripeAccountId() is true, and false is passed in.

I get it, but the piece of code below adds the account id to the Stripe HTTP request header, which is only used for non-specific Connect endpoints such as Payout. This means we'll only have to include the param in those resource calls. Example:
return Payout::create($options, $this->stripeAccountOptions(true));
Then we omit the param in Connect-specific calls such as AccountLink, etc. Also, I believe the the param should be changed from
bool $includeAccountId = true
to
bool $sendAsAccount = false

I need this <3

Closed by https://github.com/ExpDev07/laravel-cashier-stripe-connect/pull/13.


About We tried using ClickHouse as a remote storage for Prometheus

Use case
I tried to store metrics with Nested,  and  expected Calculated Growth Rate.
e.g http://www.silota.com/docs/recipes/sql-mom-growth-rate.html
CREATE TABLE IF NOT EXISTS app_metrics(
   partition Date DEFAULT toDate(timestamp),
   timestamp DateTime DEFAULT now(),
   instance_id String,
   metric String,
   tags Nested
   (
     key String,
     value String
   ),
   value Float64
  ) ENGINE = MergeTree(partition, (timestamp, metric), 8192);

A clear and concise description of what is the intended usage scenario is.
Describe the solution you'd like
Clickhouse is expected to provide functions like MySQL lag() or lead() ?
Describe alternatives you've considered
Or alternatives solution e.g https://rextester.com/ERTQ26880
Additional context
We tried using ClickHouse as a remote storage for Prometheus.
Gauge 、Histogram and so on are satisfied，hower  what should Counter of prometheus do?
ps. https://groups.google.com/forum/#!topic/clickhouse/d5Np4j_nkYk

Thanks for feedback.
lead/lag - you are looking for window functions. They are not supported currently, but there are some workarounds using arrays. Please follow main issue: #1469


Reduce Fastly cache time to 6 hours

Reduce Fastly cache time. That way, if a race condition causes an
obsolete value to be recorded, it will be corrected more quickly.
This reduces the cache time from 24 hours to 6 hours.
Signed-off-by: David A. Wheeler<EMAIL_ADDRESS>

@jdossett @dankohn - this tweak is intended to reduce the impact of a race condition, even if all our other measures fail.

The races don't seem to be happening, and having longer Fastly cache times provides some DDoS protection. So I'm dropping this.


Improve value semantics for LinOp types

This PR improves the value semantics of Ginkgo polymorphic objects by making sure that their contents are always stored on the correct executor. This fixes the issues caused by gko::clone not copying data that is stored in a shared_ptr. Additionally, I added a few helpers to reduce code duplication in solvers.
The PR is still work in progress, I only added the basic implementation and an example for Bicg, but I wanted to open the floor to discussions already
TODO:

[x] moving Preconditionable to solver_base.hpp is interface-breaking, I guess we can do without the move?
[x] Add tests
[x] Bicgstab
[x] Cg
[x] Cgs
[x] Fcg
[x] Gmres
[x] CbGmres
[x] Idr
[x] Ir
[x] Lower/UpperTrs
[x] Ilu/Ic factorizations
[x] Ilu/Ic preconditioners
[x] Isai preconditioner
[x] Jacobi (size members)
[x] Sellp (size members)
[x] Dense (stride-preserving copy)
[x] Hybrid (Coo, Ell, strategy)
[x] Fbcsr (size members)
[x] Ell (size members)
[x] Csr (strategy)
[x] Composition
[x] Combination
[x] Pertubation
[x] Multigrid
[ ] UseComposition is still broken, but there is no interface break-less approach to fix this. EnableMultigridLevel needs access to the object's executor, thus needs to become a mix-in.
[ ] MultigridLevel cloning is currently very hacky, we probably need a better approach here.

Fixes #747

No, this is a technique @MarcelKoch introduced me to: I originally wanted to merge solver-test first, so this PR would only show the differences to solver-test, not all of the changes solver-test itself introduces. If the first PR is merged, the base ref is automatically updated to develop

format-rebase!


I want consistent experience while building wrapper and plugin with envs

Currently, when the wrapper function requires env, we provide it visa function argument while in the case of the plugin, they can get with the this.env module property. We should have a consistent experience between those two and we had a consensus that the env with function argument is a better choice for now.

[ ] #1563
[ ] #1564

PluginModule shouldn't have env as property but inject the env as function param where required


include-meta LUA filter (updated)

This filter addresses https://github.com/pandoc/lua-filters/issues/196.
It should be a complete, functional filter for adding meta-data from external YAML/Markdown files with a new 'include-meta' property for the YAML document header.
You can preview it at https://github.com/mfhepp/lua-filters/tree/master/include-meta.
The merge mechanism is heavily inspired by code contributed by @tarleb in https://github.com/jgm/pandoc/issues/3115#issuecomment-294506221.
Note that this is my very first contribution in LUA, so any ideas for improvement are very welcome!

Thank you, looks good!
Some notes:

The example that contains multiple include-meta fields is, as far as I know, not valid YAML. It would fail with pandoc 2.15 and earlier, as those versions were using a stricter library for YAML parsing.
Some lines in the README are very long. We generally try to keep lines below 80 characters. Depending on which editor you use, editorconfig might be helpful to assist with these details.
Are the tests in test.sh the same as those run with make test? I'm not sure if we need that file.

Thanks for the quick review!

Some notes:

The example that contains multiple include-meta fields is, as far as I know, not valid YAML. It would fail with pandoc 2.15 and earlier, as those versions were using a stricter library for YAML parsing.
Yes, I noticed that - the README is already corrected: https://github.com/mfhepp/lua-filters/tree/master/include-meta#specifying-a-yaml-file-to-be-included

Some lines in the README are very long. We generally try to keep lines below 80 characters. Depending on which editor you use, editorconfig might be helpful to assist with these details.
Fixed in the next commit.

Are the tests in test.sh the same as those run with make test? I'm not sure if we need that file.
Yes, this was before I knew that a Makefile is a requirement. Removed.

I also spotted a bug when using the filter with no include-meta directive.
The behavior for RevealJS properties is only as expected if a value that should replace an earlier value is set to 0 for properties that default to true. But I assume this is more a Pandoc issue than related to my LUA filter.

While I think the filter is pretty mature, I am not pursuing it any further. The reason is that the same effect can be realized with the standard Pandoc mechanism of "default" files with the --defaults=filename.yaml command-line option.
Inside the defaults file, you can specify meta-data defaults, either with the metadata: keyword, the metadata-file: keyword, or the variable: keyword.
So by simply invoking Pandoc with one or more defaults files, one can predefine defaults for meta-data with ease. I do not think it makes sense to develop a filter that does almost the same with slight variants in behavior (e.g. regarding priority rules).
One hint: meta-data values that are path names with underscores (like my_logo.png) cause trouble in some LaTex templates (like in Eisvogel). When you use the variables: keyword in a defaults file, the path will not be parsed as Markdown and those problems will disappear. The same holds for other special characters that Pandoc will escape when it parses them as Markdown.
Same for header-includes sections.
Asking for trouble:
metadata:
    titlepage-logo: "foo_doo_baa/my_logo.pdf"
    header-includes:
        - \usepackage[section]{placeins}

Robust Approach:
variables:
    titlepage-logo: "foo_doo_baa/my_logo.pdf"
    header-includes:
        - \usepackage[section]{placeins}

I think using a defaults.yaml file is more elegant than using the syntax for raw content, like
logo: "`logo_image.pdf`{=latex}"

because this will not work in a metadata value in a defaults file.
See also related issues:

https://github.com/Wandmalfarbe/pandoc-latex-template/issues/100
https://github.com/Wandmalfarbe/pandoc-latex-template/issues/166
https://github.com/jgm/pandoc/issues/1685
https://github.com/jgm/pandoc/issues/3504

That's a great explanation; I agree completely.
Thank you for all the effort, sorry we didn't get merge it.

like this idea, thanks!


Removed automatically adding year to copyright message

Removed automatically adding year to copyright message for file generated by New-ModuleManifest and New-PSRoleCapabilityFile.

It seems new tests not needed - why validate an entity what is absent? Or alternatively we would check a exact format of the copyright string.

@iSazonov fixed.

I agree with @iSazonov - we don't really need a test for this.
If the code were to change, maintainers will want to understand the reasoning behind the change before merging - regardless of the existence of a test.
And you also added a file in your last commit that shouldn't be there.

@iSazonov  @lzybkr Removed tests and files added inadvertently.
We were recommended by CELA (legal) to remove year from copyright strings.


[Docker Desktop] Launch compose stack from file context menu

Tell us about your request
I would like the ability to right-click on a compose file and click on a file action menu item to let me launch the stack. Then, I’d be able to use the GUI to mange the stack.
Which service(s) is this request for?
Docker  Desktop
**Tell us about the problem you're trying to solove
Many folks I work with want to share scripts or applications with others, but those “others” aren’t as familiar or comfortable in the command line. This helps lower the barrier of entry for them to let them easily spin up a stack.
Are you currently working around the issue?
We create batch/shell scripts that then let them double-click to run a script that has the composer commands in it. We’d like to get away from encouraging users from running random batch/shell scripts for obvious reasons. 😉
Additional context
None at this time

I really like the idea! Would you extend it to Dockerfiles as well?

It might, but I definitely wouldn't worry about it being the start. The idea of the context menu would be to help run containers. The compose file could include the build directive to help build the image if needed.
My hesitation with the Dockerfile is that once you have the image, then what? I could eventually see a menu option to "Build and Push" where you are prompted for the name. But, I wouldn't worry about that day one.


Does this project need to download a model from huggingface?

Bug

When I run the code, I encounter the following problem
requests.exceptions.SSLError: (MaxRetryError("HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /api/models/ds4sd/docling-models/revision/v2.1.0 (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)')))"), '(Request ID: 17d20384-a725-4353-8425-f27cb0dc2ff6)')
Does anyone else have the same problem

Got the same problem, tried to update everything but does not work.

same to me, do you know how to fix it?

Was initially using personnal project to launch docling and got that error then executed the main page script which somehow solved my problem, hope that will help you too:
from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # document per local path or URL
converter = DocumentConverter()
result = converter.convert(source)
print(result.document.export_to_markdown())  # output: "## Docling Technical Report[...]"

Was initially using personnal project to launch docling and got that error then executed the main page script which somehow solved my problem, hope that will help you too:
from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # document per local path or URL
converter = DocumentConverter()
result = converter.convert(source)
print(result.document.export_to_markdown())  # output: "## Docling Technical Report[...]"

There's still an error, but I found an alternative solution. You guys can try running it on Google Colab. In my case, installing it on my computer didn’t work, but it worked on Colab. And yes, it downloads some weights from Hugging Face. Somehow, my network blocks Hugging Face, which caused the problem.

Maybe launch the simple python script (picked from the "Use this model" button from https://huggingface.co/ds4sd/docling-models) and then retry with my previous answer:
# Load model directly
from transformers import AutoModel
model = AutoModel.from_pretrained("ds4sd/docling-models")

Yes, There is Layout model and the other one is Table detection model from hugging face
#Example code to only run layout model
from docling_ibm_models.layoutmodel.layout_predictor import LayoutPredictor
test_layout_predictor = LayoutPredictor("/home/your_name/.cache/huggingface/hub/models--ds4sd--docling-models/snapshots/36bebf56681740529abd09f5473a93a69373fbf0/model_artifacts/layout/")
import pypdfium2 as pdfium
test_pdoc = pdfium.PdfDocument("./tests/data/2305.03393v1-pg9.pdf")
layout prediction for one page
test_layout_op = test_layout_predictor.predict(test_pdoc[0].render().to_pil())
print(list(test_layout_op))

I was also getting models errors with 2.14.0
Saw this in the log -
  File "/Users/###/###/.venv/lib/python3.12/site-packages/docling_ibm_models/layoutmodel/layout_predictor.py", line 98, in __init__
    raise FileNotFoundError("Missing ONNX file: {}".format(self._onnx_fn))
FileNotFoundError: Missing ONNX file: /Users/###/.cache/huggingface/hub/models--ds4sd--docling-models/snapshots/36bebf56681740529abd09f5473a93a69373fbf0/model_artifacts/layout/beehive_v0.0.5/model.pt

I'd cleared the hugging face cache but it didn't seem to fix the issue.
Downgrading to 2.13.0 seemed to work, then I went back to 2.14.0 and it works without error now.   😓
https://ds4sd.github.io/docling/usage/#setting-up-a-documentconverter
There's a section in the docs that might be helpful, but these imports don't appear to be valid -
from docling.datamodel.base_models import InputFormat
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.pipeline.standard_pdf_pipeline import StandardPdfPipeline

# # to explicitly prefetch:
# artifacts_path = StandardPdfPipeline.download_models_hf()

artifacts_path = "/local/path/to/artifacts"

pipeline_options = PdfPipelineOptions(artifacts_path=artifacts_path)
doc_converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)
    }
)


[FEATURE]: Mediapipe facemesh

Description
Seems like mediapipe's face mesh has been recently updated with iris features as well. Would love to have this in this project and maybe benchmarked across the rest.
Tensor docs: https://blog.tensorflow.org/2020/11/iris-landmark-tracking-in-browser-with-MediaPipe-and-TensorFlowJS.html
Google docs: https://ai.google.dev/edge/mediapipe/solutions/vision/face_landmarker
Mediapipe docs: https://github.com/google-ai-edge/mediapipe/blob/master/docs/solutions/face_mesh.md
Additional Info
No response

facial landmarks are just being used to align detected faces. for this task, we can do it if we know the positions of eyes and noses. similar to mediapipe, dlib offers much complex landmarks but we don't need this in facial recognition.