Select function for points not working for non-numeric

In the SciPy2017 presentation using parameters and widgets, there was a select statement to get points based on passenger_count:
selected = points.select(passenger_count=self.passengers)
Is this function limited to only accept numeric arguments.  I tried the select statement that I was expecting would pick points based upon an event type in my dataset, but it did not select the data.  All data was selected.  It wasn't limited to just "Sag" data.
plot        = param.ObjectSelector(default="Sag", objects=["Sag","Swell"])
selected = points.select(points.EventType=self.plot )
Also, does this select function allow multiple conditions?  For example, if I wanted to select "Sag" data with an event count range, would the select function handle that?

Not sure if this  a typo but could you try simply:
selected = points.select(EventType=self.plot )

where EventType should match a column in your data.

For example, if I wanted to select "Sag" data with an event count range, would the select function handle that?

Yes you can select ranges by supplying a tuple, e.g. this selects values between 0 and 10:
points.select(EventType=self.plot, Sag=(0, 10))

It doesn't seem to select based upon the EventType.  It includes every point no matter the EventType that is specified in the select.
The EventType field is a string that can be "Sag" or "Swell".

Can you paste the exact line of code you were trying and the output of print(points) because the code you posted above contains a syntax error so can't be what you actually tried.

Below is what I had, but your question made me realize I only had EVENT_COUNT defined under vdims. I added the EventType to vdims and it works great.
Thanks for pointing me in the right direction.
class SagSwellExplorer(hv.streams.Stream):
alpha       = param.Magnitude(default=0.75, doc="Alpha value for the map opacity")
plot        = param.ObjectSelector(default="Sag", objects=["Sag","Swell"])
colormap    = param.ObjectSelector(default=cm["fire"], objects=cm.values())
numEvents  = param.Range(default=(1, 300), bounds=(1, 300), doc="""Filter for event count""")

def make_view(self, x_range=None, y_range=None, **kwargs):
    map_tiles = tiles.opts(style=dict(alpha=self.alpha), plot=options)

    points = hv.Points(df, kdims=['X_CORD', 'Y_CORD'], vdims=['EVENT_COUNT'])
    selected = points.select(EventType=self.plot,EVENT_COUNT=self.numEvents )
    SagSwellPts = datashade(selected, x_sampling=1, y_sampling=1, cmap=self.colormap,
                           dynamic=False, x_range=x_range, y_range=y_range,
                           width=800, height=475)
    return map_tiles * SagSwellPts

Glad you figured it out!
I'll close this issue now but that doesn't mean we can't continue discussion here if necessary.


fix(form): replace aria-errormessage with aria-describedby

fix #1420

Deploy preview for pf-next ready!
Built with commit<PHONE_NUMBER>dde9f1e83d6f5fc73091cd8fdac277
https://deploy-preview-1479--pf-next.netlify.com

Thanks for making this update! I just had a suggestion for the documentation. Feel free to revise.

Agreed @jgiardino updated it

I'd say it's not a breaking change in core since core only distributes css.  If react adopts this and has to modify attributes, they can just add a new one and mark the old one as deprecated so as not to introduce a breaking change (with an issue to be cleaned up later that would remove the deprecated propType if it exists).

Just FYI, this update was previously made in the React component (https://github.com/patternfly/patternfly-react/pull/917). A react issue isn't needed for this one.


Update some core tests to use new API

Convert low hanging fruit to new API.  Note that this points to non-master branch on fhir_client, so you need to merge that PR in first then change this Gemfile to point back to fhir_client-master.

waiting on review of client pull request

Updated to incorporate @asross vread suggestion.


failed to got error - UnknownReason Resume

hi, Thanks for great LiveKit! Those two days, I always got errors like below. I'm very confused because it always works and I have not change anything. Could you please give me some tips to solve it. thanks!
DEBUG:livekit:tungstenite::protocol:666:tungstenite::protocol - Received close frame: Some(CloseFrame { code: Normal, reason: "" })
DEBUG:livekit:tungstenite::protocol:683:tungstenite::protocol - Replying to close with Frame { header: FrameHeader { is_final: true, rsv1: false, rsv2: false, rsv3: false, opcode: Control(Close), mask: None }, payload: [3, 232] }
WARNING:livekit:livekit::rtc_engine:430:livekit::rtc_engine - received session close: "signal client closed: "stream closed"" UnknownReason Resume
WARNING:livekit:livekit::rtc_engine:430:livekit::rtc_engine - received session close: "signal client closed: "stream closed"" UnknownReason Resume
{"message": "livekit::rtc_engine:430:livekit::rtc_engine - received session close: "signal client closed: \"stream closed\"" UnknownReason Resume", "level": "WARNING", "name": "livekit", "pid": 24307, "job_id": "AJ_8bL9Cj6xqoNH", "timestamp": "2024-11-25T15:51:29.543078+00:00"}
DEBUG:livekit.agents:shutting down job task
INFO:livekit.agents:job exiting
{"message": "job exiting", "level": "INFO", "name": "livekit.agents", "reason": "", "pid": 24307, "job_id": "AJ_8bL9Cj6xqoNH", "timestamp": "2024-11-25T15:51:29.546678+00:00"}
DEBUG:livekit.agents:http_session(): closing the httpclient ctx
DEBUG:livekit.agents:http_session(): creating a new httpclient ctx

and this:
DEBUG:livekit:tokio_tungstenite:390:tokio_tungstenite - websocket close error: IO error: Broken pipe (os error 32)
DEBUG:livekit:tungstenite::protocol:666:tungstenite::protocol - Received close frame: Some(CloseFrame { code: Normal, reason: "" })


Added LuisAdaptiveRecognizer

Fixes #1637
Description
Added missing LuisAdaptiveRecognizer class

Pull Request Test Coverage Report for Build 127110

8 of 21 (38.1%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 79.851%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

libraries/botbuilder-dialogs-adaptive/src/luis/luisAdaptiveRecognizer.ts
4
17
23.53%

Totals

Change from base Build 127038:
-0.07%

Covered Lines:
12427

Relevant Lines:
14850

💛  - Coveralls


Update launchdarkly-js-client-sdk to newer version

We're happily using this addon, but we need some newer features from the underlying LD SDK, namey:

auto aliasing from 2.19.0
LDOptions.requestHeaderTransform from 2.20

Would it be feasible to upgrade? Is it supported to install the SDK in our own package.json deps?

Hi @Ramblurr . Thanks for the heads up. Let me look in to this and get back to you. It might take me a couple of days. Thanks in advance for your patience.

just released a new version with the updated SDK: https://github.com/adopted-ember-addons/ember-launch-darkly/releases/tag/v2.1.0


Does it support the HarmonyOS system?

Is this framework purely fluent? Does it support the HarmonyOS system?

鸿蒙可以看下这个： https://github.com/xdd666t/ohos_smart_dialog


[Request]: android_alarm_manager_plus Integration test

Plugin
android_alarm_manager_plus
Use case
Current test implementation in packages/android_alarm_manager_plus/example/integration_test/android_alarm_manager_plus_test.dart does nothing.
Proposal
Write working integration_test for android_alarm_manager_plus and enable the CI job to run it on an Android emulator

Hello, do I need to assign myself to the issue or do I start working on it right away?

There's no ticket "reservation". Whoever gets the PR approved gets it.


Updates for the latest API of ouroboros-network

Update hashes in cabal.project and slack.yaml to latest versions
of ouroboros-network and other dependencies.
Update then code to API changes in ouroboros-network.

Issue Number

Overview

[ ] I have ...

Comments

I'll have a deeper look at this in a few days / weeks. Thanks for updating this @MarcFontaine although this comes pretty low on our priority list. So, if the PR stays open, it's not because we have forget it, but simply because focus is elsewhere at the moment.

No problem.

Superseded by https://github.com/input-output-hk/cardano-rest/pull/42


🗜  Added Eslint

no issue
Added linting to the repository for more consistent code styles.

Coverage remained the same at 100.0% when pulling 3b77733755c275057efc67f84771e34dc008a891 on AileenCGN:add-linting into 8aa271da842e2ae5fcb85b3e9e68a64d81bfeb17 on jbhannah:master.

Coverage remained the same at 100.0% when pulling e6b16a2a4cfb5f8b59cb925ae6d75d0fb4cbb80e on AileenCGN:add-linting into 8aa271da842e2ae5fcb85b3e9e68a64d81bfeb17 on jbhannah:master.

Did you consider eslint?

Yeah, you're right! I changed it to eslint!

Coverage remained the same at 100.0% when pulling 6a8434d22a820dfc35284c954b9d6d4556d53685 on AileenCGN:add-linting into 1938ec3687170ea6f5dd0b7ed5f680e6f446ca5d on jbhannah:master.

rebase needed

Coverage remained the same at 100.0% when pulling 83c3de25fbfcaa6bb9af171a8cd5f0c5ffffb12a on AileenCGN:add-linting into 9544a1105d9695b227257acf1ef3c3502928d486 on jbhannah:master.

Coverage remained the same at 100.0% when pulling 83c3de25fbfcaa6bb9af171a8cd5f0c5ffffb12a on AileenCGN:add-linting into 9544a1105d9695b227257acf1ef3c3502928d486 on jbhannah:master.

Coverage remained the same at 100.0% when pulling 83c3de25fbfcaa6bb9af171a8cd5f0c5ffffb12a on AileenCGN:add-linting into 9544a1105d9695b227257acf1ef3c3502928d486 on jbhannah:master.

Done!


[WIP]Move doc changes to a fork while dealing with auth issues

Description

Update documentation string for utils.
Minor code changes to reduce complexity.
Add mlflow util for automatically setting the tracking uri to: pick up AzureML when available or protect against directory changes causing downstream bugs.
Related Issues

Checklist:

[ ] My code follows the code style of this project, as detailed in our contribution guidelines.
[ ] I have added tests.
[ ] I have updated the documentation accordingly.

PR stale. Needs to be reopened with new changes


Merging In-Box Package Resource with xPackage

This merge is part of #160.
The in-box Package resource has been changed a lot since it was originally posted on GitHub, including a change to the schema of the resource. There were also quite a few changes from the community, most of which have been retained.
There is an HTTPS test added which is currently getting skipped. It seems to have problems with the local SSL connection. The test did not work with the original community resource either. Skipping it for now so the resource can get the needed updates and tests.

This change is

The new Package tests have added 50 MINUTES to the overall xPSDesiredStateConfiguration tests. :-1: This is ridiculous. Looking at the cause of the crazy time delay now to see if anything can be done about it.

Test time reduced back down to around 5 minutes. :+1:

@kwirkykat I noticed that the ability to test the installation status using a registry key (using the InstalledCheckReg* properties) didn't survive the merge. Are there plans to restore it at some point or is that still up in the air?

@kwirkykat @brantb DOH! We use that feature extensively as developers do some wacky stuff with their packages. Any idea why it was dropped and can this be added back in?

@iainbrighton @brantb These parameters are no longer in the in-box Package resource. I'm not really sure why. I can add them back into xPackage if you guys would like.
Can you guys post some tests/scripts that should work with these parameters added back in?

@iainbrighton @brantb Can one of you guys please submit an issue for this if you would like the params added back in?

@kwirkykat @brantb Done (https://github.com/PowerShell/xPSDesiredStateConfiguration/issues/187) :smile:


Q: Can ServerConfig.setJars() method support wildcard ?

Currently ServerConfig.setJars()  must give the full name of jar like example-1.6.jar , can support example-*.jar or something kindly support update dependence

It already does/should but you need to leave off the *.jar suffix ... so just use "example-" and it should work as expected.

That should sort it. I'll close assuming that is the case.


Adopt http\type\property\value-types from cadl ranch

Fixes: https://github.com/microsoft/typespec/issues/4010

API change check
API changes are not detected in this pull request.


Update generic-table-dev with dev branch workflows

Dummy PR to just check whether the changes work on the dev branch. Will be creating a PR for main branch for this change instead

Hi @saynb did you need someone to approve this for test purposes?

Hi @saynb did you need someone to approve this for test purposes?

Hi @chrispsommers , I am still making changes on this and trying out what works and what doesn't with the CI. It will be probably a few tried before it is ready for review and so I converted it to draft. I think CI is able to run even without approvals. Is it fine if I use the same PR for the CI changes and also sync main to this branch?

Hi @saynb Do you need any actions/decisions to move this forward? Regarding:

Would you prefer we make this change only in dev branch or test it here and make the change in main instead

I don't think it matters much either way, but I am in favor of pushing the CI/CD rules changes to main then syncing back to -dev. That way all future -dev branches will gain the benefits if they branch off main. You'd need to make a new PR of course, this one has catchup-commits from main.
Did you test this to your satisfaction?

Closing this since have tested this enough and have raised https://github.com/p4lang/p4runtime/pull/443. @chrispsommers FYI


Write automated tests: Test folder missing

I have the same Problem as the first discribers. There is no "test" in the downloaded *zip file for the codelab. Can't continue....
And there is a solution from:
https://github.com/joeShuff
you have to download the zip from "solution" branch not the main branch....thanks to joe!

Hello @AAB999,
Thank you for reaching out to us and sharing your concern. Please check out the latest fixes in the repository, as well as the codelab content update.


Make mysql client history survive a ddev restart

The Problem/Issue/Bug:
It would be nice if the SQL statements written to the client history file were still there after a ddev restart.
Currently they are not.
How this PR Solves The Problem:
It sets an environment variable so the mysql client will write
its history to a location on a persistent volume.
That location is shared between the web and the db container.
Manual Testing Instructions:

Remove the existing history files with ddev start && ddev exec rm -rf /mnt/ddev-global-cache/mysqlhistory
ddev restart and verify that the directories now exist, ddev exec ls -lR /mnt/ddev-global-cache/mysqlhistory
ddev drush sqlc
Issue an SQL statement
Quit
ddev restart
ddev drush sqlc
Hit arrow up -> Statement should still be there, in v1.17.7 it is not.

Notes:

There is no variable to limit the size of the file like there is for bash. From https://planet.mysql.com/entry/?id=5991652 :

Despite the similarities to Bash, there is no MYSQL_HISTSIZE environment variable
to be like Bash's HISTSIZE. With some unreliable fiddling,
one can try to tell the underlying library what the maximum history size should be
[...]
Usually this particular trick is best avoided because of its side effects.

The directory is not created automatically, if it doesn't already exist the history file is not written.

I've finally gotten around to testing it. It works as expected from inside the containers (my-built-ddev ssh then drush sqlc). It survives a my-built-ddev restart and sharing the file with the command line mysql client in the DB container works, too). But it does not work when I use my-built-ddev drush sqlc or my-built-ddev exec drush sqlc from the host machine. I guess in that case the bashrc file with the environment variable is not read.
These are the changes I've made locally to the pkg/version/version.go file:
diff --git a/pkg/version/version.go b/pkg/version/version.go
index c669e743..a4b83cbc 100644
--- a/pkg/version/version.go
+++ b/pkg/version/version.go
@@ -40,13 +40,13 @@ var DockerComposeFileFormatVersion = "3.6"
 var WebImg = "drud/ddev-webserver"

 // WebTag defines the default web image tag for drud dev
-var WebTag = "v1.17.7" // Note that this can be overridden by make
+var WebTag = "20210722_cspitzlay_mysql_history" // Note that this can be overridden by make

 // DBImg defines the default db image used for applications.
 var DBImg = "drud/ddev-dbserver"

 // BaseDBTag is the main tag, DBTag is constructed from it
-var BaseDBTag = "20210709_mariadb_versions"
+var BaseDBTag = "20210722_cspitzlay_mysql_history"

Thanks, great progress!
If you want to make it work with ddev drush sql-cli the answer would be in fixing https://github.com/drud/ddev/issues/2998, and I'd be OK with sneaking that in here.
I'll try to push your images later today.

I think the "writing on top of each other" is to be expected if you mean that "the last one wins". There is no live-sync. The same happens if you open two mysql command line clients on the same system, and I guess the same thing will happen with the bash history file if you have two shells in parallel.
The only situation where we make things worse it that it now extends to clients on web and db. But I'd consider the feature that the user is able to reuse a statement on db that he used on web earlier outweighs this issue with possibly conflicting writes.

What I found was that using mysql in the web container corrupted the file so it couldn't be used in the db container if the file was shared between them. I have no idea why, unless it keeps the file open and has an index in it or something.
Anyway, it's easy to try out, just edit so they have the same file and build the binary and try it out using clients in both the web container and the db container. Maybe your experience will be different from what I thought happened.
I actually examined the file and was horrified by what I saw :)

I'm not sure if we're both seeing the same kind of corruption but it's certainly different from what I've seen in my earlier tests. I hadn't looked at the actual contents of the file but given that the feature worked in all three use cases I'd say there hadn't been any corruption at the time.  But maybe I just didn't test thoroughly enough.
What I am seeing now is that the web container encodes spaces differently than the db container and the db container cannot read the format while the web container still can. The file written from web also has a 'HiStOrY_V2' header that the db version does not.
The clients are using different libraries:
On web:
$ mysql --version
mysql  Ver 15.1 Distrib 10.5.10-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

On db:
$ mysql --version
mysql  Ver 15.1 Distrib 10.5.11-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

I think this difference in encoding is related to this mysql issue: https://bugs.mysql.com/bug.php?id=72108
One comment even says "AFAIR this is a readline vs. libedit problem ...?"
I suggest we go with separate files then to stay clear of these version / config / library issues.
Which is what your latest version does.
There is one TODO left: Creation of the parent directory. If it does not already exist no history file is created. Do you know a good place to do that?
mkdir -p /mnt/ddev-global-cache/mysqlhistory/${DDEV_PROJECT}

Excellent. I think separate files won't inconvenience many people. Glad you were able to sort out what's going on with the conflict. I have no idea offhand why the versions would be different, except that in the db container we install everything with server of course, and on the web we just install the client.
Are you sure we have to pre-create the directory? I never did that, but did wonder how it worked. If we had to do it it would be in the start script of the container I think.

Yes, I tested it a couple of minutes ago:

The feature worked with your latest version.
Then I removed the code. No history was stored any more.
Then I manually created the directory again. History was stored again.

Could it be that you tested my version at least once before you started working on a better place to set the var?
In that case the dir had been created and since the whole point is that it is located on the persistent volume you already had it when you ran your version.

Yes, I definitely used your version. So I guess we have to add the mkdir -p to the startup script in both the web and db containers.

Do you mean the docker-entrypoint.sh? That's where the bash history dir is created.
Is the variable $DDEV_PROJECT known in that script?

It's start.sh in the webserver, and you'll see that DDEV_PROJECT is used there.
DDEV_PROJECT and DDEV_SITENAME are also available in the db container, where the start script is docker-entrypoint.sh

How about making the structure like the one for the bash history? Since the file is no longer shared there is no reason to use a different naming.

Totally agreed. In fact, you can just add to the mkdir -p command used for bash history.

Thanks for the great work on this. I've always secretly wished for it. And I'm very impressed with your persistence and care in manual testing. It would be great if everybody was that careful.

Thanks for your support in this. I couldn't have done it alone.


Flatpak not recognizing nvidia-410-79

Hello,
when I try to open Deezer I get following error:
Graphics driver 'nvidia-410-79' for Flatpak has not been found on your system
but I have that driver version

Hello. I'm cleaning stale tickets after the release of Nuvola 4.16. If this ticket still concerns you, feel free to reopen it.

Related: tiliado/nuvolaruntime#513 (Nvidia 418.40.04)


Can you please re-enable your old API for couple more days.

I'm writing on behalf of a big app which been using your old API. We were late updating our app and just noticed users are getting an error message when using our app.
Happy to help you with anything you'd like to, but really need your favour today!

Hi @narekgevorgyan,
We notified on various channels since March about the scheduled shutdown

Github announcement
Website
Deprecation message in JSON response of api.fixer.io

We are aware that this is a tough decision, but we are not able to enable the legacy API again.


[RFC] Add generic perf Instrument

DO NOT MERGE: This PR is a WIP
Introduction
As discussed in #971, this PR tries to modify the perf instrument so that it accepts any perf command. It is related with ARM-software/devlib#388 which implements its back-end. It also requires ARM-software/devlib#387 to properly run some perf subcommands (ARM-software/devlib#386).
The idea is to accept a YAML input (part of the agenda) that is in the format of what perf expects:
$ perf help

 usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]

Which then only requires formatting this command based on the input and doesn't require having logic in the WA instrument to handle every COMMAND.
Single Command
An excerpt from an agenda describing a command (here, perf record) would look like:
                command: record
                flags:
                    - all-cpus
                    - no-inherit
                kwflags:
                    freq: 1000
                    event:
                        - r8
                        - cs
                    cpu:
                        - 0
                        - 4
                args:
                    command: sleep
                    args: 1000
                stdout: '/dev/null'
                stderr: '&1'

the accepted keys (command, flags, kwflags, ...) being the names of the parameters to devlib.utils.cli.Command.__init__ (see the back-end implementation). This allows the highest level of flexibility, will support any version of perf and any perf subcommand, is relatively simple to implement and maintain and relatively robust (see the following discussion about fail cases). Having such a level of control over the parts of the perf command allows us to take full advantage of YAML anchors. The readability (as seen from the agenda) of this approach partially comes from the expressiveness of the perf flags. As an example, notice that events are passed as clearly as in the previous implementation, yet no specific logic had to be implemented for it in the instrument.
Full Run
On top of this, the proposed perf instrument takes 3 dictionaries of commands (pre_commands, commands, post_commands) based on when these commands have to be run: instead of hardcoding this information in the instrument for each subcommand (cfr. #971), we let the user input it, which is a small amount of low-risk work for them. The keys of the command dictionaries are their labels (as introduced by the previous implementation, see further discussion in the back-end PR).
For example, a full agenda:
config:
    augmentations:
    - perf
    iterations: 1
    perf:
        force_install: true
        commands:
            first:
                command: record
                flags:
                    - all-cpus
                    - no-inherit
                kwflags:
                    freq: 1000
                    event:
                        - r8
                        - cs
                    cpu:
                        - 0
                        - 4
                args:
                    command: sleep
                    args: 1000
                stdout: '/dev/null'
                stderr: '&1'
        post_commands:
            first:
                command: report
                kwflags:
                    sort: dso
                    field-separator: ;
                stdout: report.stdout

workloads:
-   name: dhrystone
    params:
        cleanup_assets: true
        cpus: 0
        delay: 0
        duration: 0
        mloops: 0
        threads: 4

which will run the following on the device (notice the properly escaped --field-separator):
# perf record --all-cpus --no-inherit --freq=1000 --event=r8,cs --cpu=0,4 -- sleep 1000 1>/dev/null 2>&1
# perf report --sort=dso '--field-separator=;' -- 1>report.stdout

according to the following rules:

flags are prepended with - or -- based on their length;
kwflags are CSV lists linked with = (valid for all perf commands; seems to be a (sometimes implicit) standard for flags taking values. This is probably because they all use the same front-end);
args is recursively parsed as a command, allowing to use perf in its original usage (i.e. by launching a command through it and only capturing that command);
stdout and stderr are used as expected and handle the UNIX &-based pipe redirection (see discussion about file names, labels, and which files which commands can see); extra flags could be considered such as stdin or pipes but I'm wondering how generic we should go, here ...

NB: The user (writing the agenda) needs to have access to the file names so that they can use the -o/-i flags to properly pipe their record/report.
The force_install flag is kept from the previous implementation. However, what is the "standard WA way" of providing the perf binary? We could write the path in the agenda (e.g. for comparing versions of perf), we could have a collection of perf binaries in a standard location and pick the ideal one (e.g. based on kernel version of the target) from within the WA perf instrument, we could (but this requires automating the automation, WA, and feels messy) have WA get the binary from a standard location on the host and overwrite that one between runs... Ideally, it would be useful to have both control of which binaries are being used and automation for finding the optimal version (as I believe the perf-kernel interface evolves with the kernel).
Parsing of the output into WA metrics hasn't been started yet. I propose to have, in this case, a per-command logic (I don't think there is another way) for the perf subcommands that are supported (probably stat and report). Because of how flexible and variable the output of perf report can be (typically a table or a graph), what would be the expected output in terms of WA metrics? I currently have a parser that generates a pandas.DataFrame from the tabular output of perf report but this seems to be "too different" from the JSON-based outputs WA instrument seem to be using. Feedback required!
Full Run (with the power of YAML)
Another agenda, similar to the example mentioned in the docstring of the previous implementation, runs the same perf stat on the big and LITTLE clusters (using YAML anchors; #976):
    perf:
        commands:
            little: &little
                command: stat
                flags:
                    - all-cpus
                    - no-inherit
                kwflags: &little_kwflags
                    freq: 1000
                    event:
                        - r8
                        - cs
                    cpu: 0-3
                args:
                    command: sleep
                    args: 1000
                stdout: 'little.stat'
                stderr: '&1'
            big:
                <<: *little
                kwflags:
                    <<: *little_kwflags
                    cpu: 4-7
                stdout: 'big.data'

Drawbacks
Obviously, the flexibility of this instrument comes at a cost as this approach won't necessarily fail early:

Errors at the first "YAML dictionary level" (post_commands, commands, pre_commands, force_install) fail early as usual (through using the Parameter class);
Errors at the second "YAML dictionary level" (command, flags, kwflags, ...) fail relatively early, at instantiation-time of Command (almost same behaviour as Parameter);
Errors at the third "YAML dictionary level" (values of flags, keys of kwflags, format of the final command string) fail late, only once the corresponding command is run on the device.

Secondly, because perf is a tool intended to run another command, this instrument is implemented while making the assumption that the user of the agenda file is allowed by the owner of the target to run arbitrary commands on it. In the case they are not, additional security should be implemented. For example, it is possible to write an agenda running the following destructive performance-investigating command:
perf record -- rm -rf /

TODO:

[ ] Write a "porting guide" from old-PerfInstrument to PerfStatInstrument
[ ] Deprecate PerfStatInstrument
[ ] Document the instrument
[ ] Decide how labels are used on the device and the host, how output files are named (and how much control the user has over it) and if there are per-label subdirectories;
[ ] Implement parsers for stat and report
[ ] Figure out why Parameter(..., kind=YamlCommandDescriptor) behaves weirdly and required somewhat hacking the constructor
[ ] Unlock teardown: should we remove everything from the target?
[ ] Change (or not) force_install

This is too opaque. Configuring this for someone unfamiliar would be a nightmare. Rather than having a single "command" map, parameters should be exposed individually, validated, and populated with sensible defaults whenever possible.
As a rule of thumb -- I should be able to run wa show perf, and the resulting page should be enough to allow me to at least start using the instrument without also having to look up the man page for perf and/or devlib docs. When I run wa create create agenda perf dhrystone, the resulting agenda should generate some kind of reasonable output for perf.

You're right, this was written while making the assumption that the user would know how to use perf (and this is the reason for which this PR is trying to give to them as much control as possible).
The difficulty with replicating perf parameters individually at the input of WA comes from how many subcommands there are, and how each has many flags. It becomes even more complicated to get right once we try to validate them as the simple availability of a flag (let alone the validity of the passed value) depends not only on the kernel version but also on the build flags of perf itself.
About the defaults, perf already provides a default behaviour for each subcommand (and default values for flags that require values e.g. event); isn't it confusing to add our own WA defaults, different from the perf defaults? Obviously, there's no default subcommand (running perf is equivalent to perf --help) but having one would barely make sense, in my opinion, because of how different they are.
I really like wa show as it's an easy way to figure out what to put in the agenda without having to go through documentation (or source code!). For this tool, it would give the meaning of force_install, pre_commands, commands, post_commands and define the formats they are expected to be in and how these relate to what ends up being run on the device. Of course, because we can't clearly define what goes inside of the values of the pairs in the commands dicts (see above), there's little we can tell about them in the output of wa show. In fact, as you say, I intend the help of this instrument to end with a RTFM-ish recommendation to refer to perf --help. Documentation of devlib isn't necessary for knowing how to use this instrument, though.
In the end, if the issue is with wa create perf, couldn't we simply have a default commands (probably calling stat -a -- sleep 1000 as in the previous implementation)? I haven't looked at how create was implemented so this could be hard to do (e.g. if it simply takes all default values of the Parameters).

The difficulty with replicating perf parameters individually at the input of WA comes from how many subcommands there are, and how each has many flags. It becomes even more complicated to get right once we try to validate them as the simple availability of a flag (let alone the validity of the passed value) depends not only on the kernel version but also on the build flags of perf itself.

Yes, I would not suggests trying to handle everything in perf that way  -- that would ultimately be futile. Instead I would consider some higher-level use cases for why someone might want to use pref (e.g.  "I want to get PMU counter values for the execution of this workload) and create a high level interface for that, which would work, say, 90% of the time. Then allow it to be augmented with the pass-though configuration you have at the moment, which will be the fallback for  when the simple setup fails (or when the user that knows what they are doing wants to do something different).
But the pass-though configuration really should be treated as a fall back, not as the intended primary was of using the instrument in the "common case".

In the end, if the issue is with wa create perf, couldn't we simply have a default commands (probably calling stat -a -- sleep 1000 as in the previous implementation)? I haven't looked at how create was implemented so this could be hard to do (e.g. if it simply takes all default values of the Parameters).

Yes, that's pretty much how create command works, hence exposing parameters with sensible defaults is important to usability.

But the pass-though configuration really should be treated as a fall back, not as the intended primary was of using the instrument in the "common case".

That's feasible ... and would make everyone happy.
So this means effectively merging the current implementation of the instrument (from master) with this new one? We would have the "clear and easy-to-use" parameters for stat (with nice default values, allowing to easily create agendas) and the (pre_| |post_)commands (defaulting to None) for advanced usage (which includes any subcommands other than stat) with the "old" parameters being ignored once commands is not None?
This approach could then also allow backward compatibility (instead of what I'm doing right now) and is very easy to integrate as the constructor could simply build a command dictionary from these parameters and the rest of the execution flow would remain unchanged!

Yes, that's the sort of thing I had in mind!

I've added logging of the artefacts extracted from the device.

Due to the complexity of this implementation and the resulting instability of the solution I have experienced, combined with the difficulties of integrating it with the WA framework, this PR will be closed in favour of an upcoming one, built on top of the Python scripts provided for simpleperf. Concerning perf, #971 may be enough to cover the needs of the users.


FourthLayer_FirstOffTrial

First version of fourth Layer made of 24 modules is prepared.

Can one of the admins verify this patch?

New pull request was prepared by Sushil - this one will be closed


civo shell plugin added

Overview

Type of change

[x] Created a new plugin
[ ] Improved an existing plugin
[ ] Fixed a bug in an existing plugin
[ ] Improved contributor utilities or experience

Related Issue(s)

Resolves: #
Relates: #

How To Test

Changelog

Additional information

[x] Check this box if this is a Hashnode Hackathon submission

Don't forget to write your Hashnode blog post to accompany this PR. The full submissions instructions are on the Hackathon page.
Note: use the Hashnode tagging system to tag the article with 1Password and BuildWith1Password


Add the 'force: yes' to the code checkout

GitHub Issue: N/A

Other Relevant Links N/A

What does this Pull Request do?
This adds force: yes to the git clone of the crayfish code.  This allows the code to be re-cloned and the role becomes properly re-runable.
What's new?
The only change is to allow the role to properly over-write any already existing code so that the role becomes properly re-runable.

Added force: yes to code clone
Does this change require documentation to be updated? No
Does this change add any new dependencies?  No
Does this change require any other modifications to be made to the repository
(ie. Regeneration activity, etc.)?  No
Could this change impact execution of existing code? Maybe.  It's not clear what impact this will have is you re-run the role on  an existing system.

How should this be tested?
If you re-run this role on a system where it has already been run, it will fail with local mods to the repository as the role changes things in the code it checks out.  If you add the option added by this PR, that error will go away.  It's not clear what implications this has for an already existing system.  For example, if you run this role again on a system which already has crayfish on it, what will happen?
One of the main ideas behind ansible is re-runability of ansible plays/tasks/roles/etc.   This mod will at least allow the role to be re runable, but the consequences are not yet clear.  Testing of those consequences is still needed but I'm afraid I don't have the expertise with crayfish to do that testing..
Additional Notes:
Interested parties
@Islandora-Devops/committers

@jhujasonw thank you for this! Since (I think?) this is your first commit to Islandora, I'm afraid there's a little bit of red tape: We ask all contributors to Islandora to sign a contributor license agreement, reserving their rights to their contributions while granting us a license to include those contributions in Islandora. You can find the CLA, and a list of all who have signed one, here:  https://github.com/Islandora/islandora/wiki/Contributor-License-Agreements.
If you can fill out an iCLA and send it to me (manez@islandora.ca), we can check that box and move along with having this reviewed and merged.

@manez Thanks for the quick reply.  I did see that, and do intend to get one signed.  It might take me a day or so, I don't have a scanner at home.... yet.

@manez I just sent you the signed CLA.  Let me know if that looks good.

Yes I have run into this before and this is exactly how I fixed it.
Could I get you to remove the comment, no point in leaving a question like that in there. If it wasn't okay we wouldn't merge it or we'd remove it.

Thanks @jhujasonw. Waiting on @manez for CLA confirmation.

all set with the CLA!


[RFC] Extendable Portal functionality

This PR offers an alternative way of creating a Portal component.
Based on @Bugaa92's PRs https://github.com/stardust-ui/react/pull/144/, https://github.com/stardust-ui/react/pull/150/,

Popup uses Portal inside during rendering
Open/Close logic is enclosed in a Portal, so Popup has no access to it
if to use trigger element outside of Portal, some logic can be missed and will need to be repeated, like handling document click

Alternative way
The alternative way is to have all common logic from Portal in some abstract component, let's name it PortalGeneric. And then it can be inherited from Popup, Portal or any other specific custom component.
PortalGeneric has logic of renderPortal, renderTrigger, open, close. So then it can be simply called from child component.

Pros:

Base functionality stays in one place, can be overridden by children if needed
Inherited components have a cleaner look
From the Accessibility perspective, keydown action handlers can have access to open/close methods and manipulate focus, by passing afterRenderClbk to those methods

Cons:

for accessibility it will be needed to extend renderTrigger method to pass extra aria-* attributes and keydown handlers. Not sure, if it is related to cons, but probably breaks some consistency.

Please, guys, feel free to share your opinion on this proposal, so we can have a broader discussion to see if this worth doing it.
P.S.: during a review, better concentrate on PortalGeneric.tsx, Portal.tsx and Popup.tsx files, as the main changes were made there. The rest is just the same as in Alex's PRs.

@sophieH29 pls don't merge this anyway before I come up with a final solution for opening the Popup using react-popper; also, I'm in the process of adding UTs for the Portal in #144 and Popup in #150  and I'm afraid now this will create complicated merges and the tests might not be viable here;
@mnajdova @kuzhelov - I'm thinking to check out @sophieH29 's branch and add my UTs here if we feel her proposal will be accepted

@Bugaa92 I haven't planned to merge it. Just want to hear more people's opinions on it and to see if this approach is worth doing.

@levithomason thank you for the recap and sharing your thoughts on it! Will check those references.


Group print hierarchy

Consider implementing a method on the Group class like "describe" or "ls" which will print whole hierarchy for a given hierarchy depth.

Maybe something like a visitor pattern ( https://github.com/alimanfoo/zarr/issues/92 ) would help with this.

Yep that could be useful. I was just thinking to produce some ASCII art
showing the hierarchy down to a specified level, with node names and node
types (Array/Group) as a minimum.
On Wednesday, November 30, 2016, jakirkham<EMAIL_ADDRESS>wrote:

Maybe something like a visitor pattern ( #92
https://github.com/alimanfoo/zarr/issues/92 ) would help with this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alimanfoo/zarr/issues/82#issuecomment-263967668, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAq8QiKa8pKAvmzS4-jJZRIG4KKeU9p8ks5rDcxLgaJpZM4KQ6jg
.

--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Email<EMAIL_ADDRESS>Web: http://purl.org/net/aliman
Twitter: https://twitter.com/alimanfoo
Tel: +44 (0)1865 287721

Sure, that would be good too. Maybe diagrams could be made akin to those used in Dask's graphs. Wonder if @mrocklin has any suggestions.

I would personally stick to ASCII.  I would look at what PyTables does as well as bash tools like tree
mrocklin@carbon:~/workspace$ tree zarr
zarr
├── appveyor.yml
├── bench
│   ├── compress_normal.py
│   └── compress_normal.txt
├── build.cmd
├── c-blosc
├── cpuinfo.py
├── docs
│   ├── api
│   │   ├── codecs.rst
│   │   ├── core.rst
│   │   ├── creation.rst
│   │   ├── hierarchy.rst
│   │   ├── storage.rst
│   │   └── sync.rst
│   ├── api.rst
│   ├── conf.py
│   ├── index.rst
│   ├── Makefile
│   ├── release.rst
│   ├── spec
│   │   ├── v1.rst
│   │   └── v2.rst
│   ├── spec.rst
│   ├── _static
│   │   └── donotdelete
│   └── tutorial.rst
├── LICENSE
├── MANIFEST.in
├── notebooks
│   ├── blosc_microbench.ipynb
│   ├── dask_2d_subset.ipynb
│   ├── dask_copy.ipynb
│   ├── dask_count_alleles.ipynb
│   ├── genotype_benchmark_compressors.ipynb
│   └── zip_benchmark.ipynb
├── README.rst
├── release.txt
├── requirements_rtfd.txt
├── requirements_test.txt
├── requirements.txt
├── setup.py
├── tox.ini
└── zarr
    ├── attrs.py
    ├── blosc.c
    ├── blosc.pyx
    ├── codecs.py
    ├── compat.py
    ├── core.py
    ├── creation.py
    ├── errors.py
    ├── hierarchy.py
    ├── __init__.py
    ├── meta.py
    ├── meta_v1.py
    ├── storage.py
    ├── sync.py
    ├── tests
    │   ├── __init__.py
    │   ├── test_attrs.py
    │   ├── test_codecs.py
    │   ├── test_core.py
    │   ├── test_creation.py
    │   ├── test_filters.py
    │   ├── test_hierarchy.py
    │   ├── test_meta.py
    │   ├── test_storage.py
    │   ├── test_sync.py
    │   └── test_util.py
    └── util.py

9 directories, 62 files

This may be an option. ( https://github.com/mbr/asciitree )

mbr/asciitree looks good. Already on conda-forge too I see.
On Wed, 30 Nov 2016 at 21:49, jakirkham<EMAIL_ADDRESS>wrote:

This may be an option. ( https://github.com/mbr/asciitree )
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alimanfoo/zarr/issues/82#issuecomment-264006526, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAq8QsYv3KLzFXhxDQOSFor4GKoVu2-mks5rDe9ygaJpZM4KQ6jg
.

If you want to go the standard library way, maybe pprint would work. Though IMHO asciitree still looks pretty good.

Yep asciitree looks good. Can be configured to produce output very similar to linux tree command:
>>> box_tr = LeftAligned(draw=BoxStyle(gfx=BOX_LIGHT, horiz_len=2, label_space=1))
>>> print(box_tr(tree))
asciitree
 ├── sometimes
 │   └── you
 ├── just
 │   └── want
 │       ├── to
 │       └── draw
 ├── trees
 └── in
     └── your
         └── terminal

Wanted to see how easy this would be now that we have visitor-style methods. Went ahead and threw together PR ( https://github.com/alimanfoo/zarr/pull/140 ). FWICT it seems to work ok.
That said, I don't know that I will be able to do lots of iteration on it near term. So if you are wanting to get it in quickly, please feel free to run with it.


Plg 97 rename

Purpose of this pull request
This pull request...
Select the type of change

[x] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions, updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)
https://sumologic.atlassian.net/browse/PLG-157

@kimsauce, could you review this PR, since you're already working on this feature? (PR #4612)

closing this since i used an older base branch, will open again after updating


Failure to import settings when using localised URL

Toolbox silently fails to import settings from a wiki when using Reddit with a localised URL such as “https://fr.reddit.com/”. Clicking on the “import” button has no effect.
Reloading Reddit from the URL “https://www.reddit.com/” then importing settings works fine.
This is a tricky behaviour: Toolbox should provides a warning when it fails to import settings.

Sorry, this is by design.

   That does need to be fixed.
BTW, in case you're wondering why it's 'by design' it has to do with how browsers treat subdomains and localStorage.
I'm going to reopen this to fix the lack of an error, but we can't do much about this issue itself.


Enable backup of cwa-android for places, people, certificates and so on

Avoid duplicates

[x] This enhancement request has not already been raised before
[x] Enhancement request is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in CWA-Wishlist
[x] If you are proposing a new feature, please do so in CWA-Wishlist

Current Implementation
The Android app explicitly disables app backups in the manifest, supposedly due to privacy concerns. This makes it impossible to migrate CWA settings to a new smartphone. Note that I'm not talking about hashes exchanged to detect infections, I'm talking about vaccination certificates, tests, the location diary and people I've met, manual entries like these.
Of course this data is "private", but is it more private than my Google Fit health data, my Google Mail emails, my cloud based Fitness tracker, my Google Maps favourite places, all my domnestic smart devices, my diary (which gets backed up too), and the 101 other apps that store personal information and can backup too? I don't think so.
Suggested Enhancement
Enable backup in the app manifest.
Exclude the anonymous infection hashes from the backup if necessary, but backup the rest.
Expected Benefits
Migration to a new smartphone is possible without data loss.
You still need to keep the old phone around for 14 days to see alerts, but your manually entered, non-volatile data is migrated.

Internal Tracking ID: EXPOSUREAPP-11168

Why not add hashes too? If it is my choice to back them up or not, there should be no privacy concern. Keeping the old phone is only possible if you actually change phones. If you just do a clean reinstall of your phone (which might be necessary for whatever reason), the hash data of the last 14 days are gone

I had the impression that these hashes were somehow connected to, encrypted with, or hidden in the actual smartphone hardware, "secure enclave" or whatever, only accessible by Google & Apple, and cwa-android would only be notified by the OS if there was a match, but not perform the matching.
If this is not the case, by all means backup everything!

Thanks for your suggestion @jensb and @deesnook. We have created an internal ticket for it and will raise this topic internally.
Internal Tracking ID: EXPOSUREAPP-11168

Corona-Warn-App Open Source Team

This seems to be very closely related to https://github.com/corona-warn-app/cwa-wishlist/issues/8 & https://github.com/corona-warn-app/cwa-wishlist/issues/500

@jensb  This feature is in our backlog , and is planned to be done in the near future.
Thanks for contribution!

new ticket: Internal Tracking ID: EXPOSUREAPP-10053

@dsarkar
You might like to "spread the good news" @mtwalli shared in the above mentioned related issues (-:


"track by" for ng-repeat over an object's properties does not work

There currently seems to be no way to ng-repeat over an object's properties if the object is created anew in the ng-repeat expression.
<button ng-click="console.log(key)" ng-repeat="(key, value) in localStorage.getItem('ls.accountKeys') track by value">

throws:
Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: (key, value) in localStorage.getItem('ls.accountKeys') track by value, Duplicate key: o, Duplicate value: "o"

Removing the "track by" part of the expression causes the digest limit to be reached with every cycle, as a new object is returned by localStorage every time.

localStorage is a key value store, so you must serialize your objects with JSON.stringify() first before storing them. Here is an example: https://jsfiddle.net/aqvrx9q9/
In case localStorage is just an example here, here is another simple example that illustrates things seem to be working as intended: https://jsfiddle.net/c298m629/
If this is not what you were asking, can you please provide an executable example?

My object stored in localStorage (which is indeed an example, in my code I transformed the string into an object) is an array-like object containing objects, with each child object containing only literals. It can be found here: http://codebeautify.org/jsonviewer/daf62c.
I have not tested making a scope variable an object reference that never changes and then overwriting it's values with the object stored in local storage; I believe that will work, but it seems very un-angular.
I will be able to post the code tomorrow.

Hi, track by must point to an expression that uniquely identifies an element in the collection. Are you sure that you did not intend to write track by key ?

Closing because of lack of response.


chore: remove installation details in README.md

The README.md file contained duplicated installation details from the documentation. It is rather hard to keep this up-to-date and the only added-value would be that people who didn't via our documentation site know how certain modules have to be installed. This information is already available on our documentation site and we would rather guide people to the documentation than to our GitHub root path, I guess.

✅ Deploy Preview for arcus-scripting canceled.
Name 	Link
🔨 Latest commit 	024dd9e
🔍 Latest deploy log 	app.netlify.com/sites/arcus-scripting/deploys/639033e43213ac0009b5b95d

@stijnmoreels this deploy seems to have failed, any idea why? Log seems empty.

@stijnmoreels this deploy seems to have failed, any idea why? Log seems empty.

I think it's bc there are no changes in the source. The logs also has this:
7:34:36 AM: No changes detected in base directory. Returning early from build.

So there is no change in deploy too.


How to run GRPC c++ compiled code on google cloud server

I have been trying running GRPC application on google cloud server but it gives me error
error while loading shared libraries: libgrpc++.so.3 : cannot open shared object file:No such directory/file exist
I have made this example run on local linux server where i have installed protoc and protoc c++ plugin. From this local server i have compiled the code and trying to make it run on google cloud server which does not have this installed packages i.e. protoc and protoc c++ plugin.
Do i need to install protoc and protoc c++ plugin on google cloud server also.
Or i just need to put the required libs somewhere in google cloud server machine ?

As mentioned in https://github.com/grpc/grpc/blob/master/INSTALL.md, you should build and install grpc from source to use grpc C++ at the GCE instance.


New features on mirror-siyuan

Maintainers may post possible new features here.

Sync files to jCloud S3 service (add backend for mirror-clone)
lug scheduling algorithm
lug persistence
mirror monitor expose

auto deploy (with Jenkins?)


Cross-diag inversions

Main changes:
Issues:
Fixes, in devel, issue #958

Hello @dvezinet! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file tofu/data/_class08_concatenate_data.py:

Line 263:80: E501 line too long (82 > 79 characters)
Line 336:72: W292 no newline at end of file

In the file tofu/data/_class10_checks.py:

Line 1321:36: W292 no newline at end of file

In the file tofu/data/_class10_compute.py:

Line 1489:6: W292 no newline at end of file

In the file tofu/data/_class10_refs.py:

Line 97:80: E501 line too long (82 > 79 characters)
Line 212:10: W292 no newline at end of file


remove tilde from import

tildes in imports for scss are deprecated, can cause compilation issues. can just be removed now.

The editor appears to be working fine. we can merge this!


Add unit tests

https://github.com/opencypher/cypher-for-apache-spark/blob/3afbaabb55d6ec808e7b181f80911e332fef8aa1/src/main/scala/org/opencypher/caps/api/util/parsePathOrURI.scala#L20

This code does not exist any more


add example to search for AS set messages

Overview
Search for all RouteViews RIB dump files for one timestamp, and collect collectors and origins that announces AS Set messages.
Run the example
cargo run --release --example find_as_set_messages

Other changes
Add utility function is_announce to ElemType struct to avoid matching on the enum's sub types.

Output:
start parsing 32 ribs in parallel
found 9 origins with AS set from route-views.phoix collector
found 147 origins with AS set from route-views.chile collector
found 144 origins with AS set from route-views.kixp collector
found 150 origins with AS set from route-views.ny collector
found 165 origins with AS set from route-views.nwax collector
found 183 origins with AS set from route-views.rio collector
found 185 origins with AS set from route-views.isc collector
found 39 origins with AS set from route-views6 collector
found 145 origins with AS set from route-views.uaeix collector
found 14 origins with AS set from route-views.soxrs collector
found 175 origins with AS set from route-views.fortaleza collector
found 163 origins with AS set from route-views.wide collector
found 188 origins with AS set from route-views.telxatl collector
found 182 origins with AS set from route-views.napafrica collector
found 198 origins with AS set from route-views5 collector
found 187 origins with AS set from route-views.perth collector
found 166 origins with AS set from route-views.sfmix collector
found 205 origins with AS set from route-views.sg collector
found 202 origins with AS set from route-views.chicago collector
found 182 origins with AS set from route-views.flix collector
found 203 origins with AS set from route-views.eqix collector
found 194 origins with AS set from route-views.sydney collector
found 216 origins with AS set from route-views4 collector
found 189 origins with AS set from route-views2.saopaulo collector
found 206 origins with AS set from route-views.amsix collector
found 196 origins with AS set from route-views2 collector
found 211 origins with AS set from route-views3 collector
found 211 origins with AS set from route-views.linx collector


support errorMessage field for mined but reverted userops

This commit adds support for handling error messages in mined transactions. The MinedTransaction type in types.ts now includes an optional errorMessage field. In the mineTransactionWorker.ts file, the code has been updated to retrieve and store the error message if the userOpReceipt is not successful. This allows for better error handling and reporting for mined transactions.

PR-Codex overview
This PR adds functionality to capture error messages for mined transactions and updates mineUserOp function to handle user operation receipts.
Detailed summary

Added errorMessage field to transaction types
Updated mineTransactionWorker.ts to handle error messages for user operation receipts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

tested:
{
	"result": {
		"queueId": "346eff2c-8fab-4f89-b6e1-0888d7e765aa",
		"status": "mined",
		"chainId": "421614",
		"fromAddress": "0xEf553047b160395c2e14268860660A3F55f09141",
		"toAddress": "0x71B6267b5b2b0B64EE058C3D27D58e4E14e7327f",
		...
		"errorMessage": "UserOp failed with reason: 'not minter.' at txHash: 0x21904b8721a876711444788a8ec81d11cde7ad42c6a5a07ec1349a65af6150b0",
		...
	}
}


Strange bug with 3 sprites, where one of them uses gdshader - Android 10

Godot version
4.0, 4.1, 4.1.1
System information
Godot v4.1.1.stable (bd6af8e0e) - Fedora Linux 37 (Workstation Edition) - Vulkan (Mobile) - integrated Intel(R) Graphics (ADL GT2) () - 12th Gen Intel(R) Core(TM) i5-12500H (16 Threads)
Issue description
Hi guys,
I am porting circle android jump game from kids can code tutorial using vulkan renderer.
I am using an old phone Xiaomi mi a2 (Android 10, it support vulkan 1.0 and gles3.2)
I found a strange bug, where I am rendering 3 sprites, two sprites use png, third use png with gdshader.
Tested situations:

When I hide one of them (nvm which one) everything is working. So, in this case, if there is one sprite with png, and a second with gdshader, everything is working.

When I remove gdshader from the sprite, everything is working.

When I remove gdshader, but add more sprites, everything is working.

I will send github repo to see details.
I did tests on other phones, like moto g5(android 12) and samsung a52(android 12), and on pc as well, and everything is working.
It's working in compatibility renderer!
logcat:
https://pastebin.com/Z8H5tDUQ
Currently, I am trying to build editor and export a template with debugging symbols to find the line where it's crashing, but I found nothing.
I am open to any suggestions to fix this error because it has very unpredictable behavior.
Steps to reproduce

Create circle scene, add sprite, and add png.
Create jumper scene, add sprite, add png and add gdshader on that sprite:

shader_type canvas_item;

uniform vec4 color : source_color;

void fragment() {
	COLOR .rgb = color.rgb;
}

Create main scene, where you add one jumper scene, and two circle scenes.

Minimal reproduction project
I removed all unnecessary files.
https://github.com/marko995/CircleJumpGodot4

Since only a single device-type shows this problem, it might be hardware-related. That would make it difficult to fix this on the Godot-side.

Since only a single device-type shows this problem, it might be hardware-related. That would make it difficult to fix this on the Godot-side.

Can you help me with debugging?
Because same game created in godot 3.5, works in both gles3 and gles2

Can you help me with debugging?

@marko995  i don't believe so, because without the specific device I can't replicate the problem.

yeah, I know, but can you give me guidelines on how to debug the issue? I already tried to build godot editor from source with debugging symbols, but I got same error message :/

For these kind of questions I suggest to join the contributors chat at https://chat.godotengine.org/
It is difficult to discuss these things here on Github.

I experience a similar issue on Sony Xperia XZ1 Compact running Android 11. I narrowed down the problem to the uniform feature. If I hardcode the value, the game no longer crashes.

The issue is present on 4.1.1.stable and on v4.2.dev2.official [da81ca62a]; 3.5.2 works as expected.

Minimal reproduction project: https://github.com/marko995/CircleJumpGodot4
is no longer found
Some bugs have been fixed in the last few weeks, you might be able to test again soon with version 4.2.x or 4.3.

it still crashes

and v 4.2.1?

Akien - 13:22
We just released Godot 4.2.1, as the first maintenance update to the 4.2 feature branch.

This version contains the bug fixes that I meant

still crashing..kk

@Alex2782 same link
https://github.com/marko995/CircleJumpGodot4

@Alex2782
is there any tutorial on how to get better errors from vulkan driver?

@Alex2782 same link https://github.com/marko995/CircleJumpGodot4

ok thanks, 2 days ago Github showed 404 error (not found), today it works again

@Alex2782 crash happens because of this line:
uniform vec4 color : source_color;
when I don't use it, works fine

logcat: https://pastebin.com/Z8H5tDUQ
AudioTrack              org.godotengine.game                 V  processAudioBuffer(351): obtainBuffer(882) returned 1772 = 882 + 890 err 0
but in the project I can't find any audio files that are played

You could also try starting an empty 2D project (maybe with only 1 text label, no gdshader) via remote debugging and log everything without filters

adb logcat > logs.txt
(press Ctrl + C after crash, redirected all logs from the last 2 hours to one file)

@Alex2782 crash happens because of this line: uniform vec4 color : source_color;
when I don't use it, works fine

ok on my Samsung Tab S7 no problems (newer Vulkan version)

problem happens when I use
3 sprites, and one of them use uniform vec4 color : source_color;
if I use 2 sprites, everything works.
Probably the problem is in vulkan driver, because when I use the newer phone, motorola g5, works fine.

strange, and if only COLOR is not initialized, it also crashes?
void fragment() {
	COLOR.rgb = color.rgb;
}

@Alex2782
you didn't understand me :D if I don't use color, and use hardcoded color, it is working

I just wanted to narrow down the error. I understood the rest.😄

problem happens when I use 3 sprites, and one of them use uniform vec4 color : source_color;

without COLOR.rgb = color.rgb;, crash or not?
shader_type canvas_item;
uniform vec4 color : source_color;

void fragment() {

}

doesn't work:

uniform vec4 color : source_color;

void fragment() {
	COLOR .rgb = color.rgb;
}

it works:

void fragment() {
	COLOR.rgb = vec3(1.0, 0.0, 0.0);
}

the idea is to manipulate colors through material parameter, which is not working.

@Alex2782 is it possible to use  source_color without uniform ?

@Alex2782
also this doesn't work
shader_type canvas_item;

uniform vec3 color : source_color;

void fragment() {

}

yup, problem is in word uniform :/
this doesn't work as well:
shader_type canvas_item;

uniform vec4 color;

void fragment() {

}

Github: uniform + android 14 issues open

@Alex2782 Ok, but I think this won't be fixed soon :/

@Alex2782 is it possible to use  source_color without uniform ?

Unfortunately, I don't know much about shaders at all, after a short research I couldn't find any examples without "uniform".

There are also compute shaders, where different uniform types can be specified via GdScript. Maybe it would also be interesting to catch the errors.
https://docs.godotengine.org/en/stable/tutorials/shaders/compute_shaders.html
# Create a uniform to assign the buffer to the rendering device
var uniform := RDUniform.new()
uniform.uniform_type = RenderingDevice.UNIFORM_TYPE_STORAGE_BUFFER

https://docs.godotengine.org/en/stable/classes/class_renderingdevice.html#enum-renderingdevice-uniformtype

Samsung Galaxy Tab A (2016) SM-T580, Android 8, armeabi-v7a: no problems with Vulkan and uniform 😃

Vulkan API 1.0.61 - Forward Mobile - Using Vulkan Device #0: ARM - Mali-T830
https://vulkan.gpuinfo.org/
The tablet is so old that there is no information about it, I can't install the gpuinfo app either (arm-v8)

This comparison could perhaps be useful:
Samsung Galaxy Tab A (2016, Android 10, arm-v8)  vs. Xiaomi Mi A2 Lite
https://vulkan.gpuinfo.org/compare.php?reports=10941,9320#extensions

VK_KHR_16bit_storage
VK_KHR_image_format_list

For example, Samsung has these 2 'extensions'. They are also queried by Godot (optional). If I find more time again, I'll try to experiment with the sources.

@Alex2782
If you need device to test it, ping me

ShaderTest.zip
@marko995:  if you find the time at some point, please try it out. Are the crashes reproducible? I need a project where I can debug the functions at the push of a button.

button "Compute" is this example: compute_shaders
button "Add ShaderMaterial" adds dynamically via GdScript the file global_color_canvas_item.gdshader -> global uniform vec4 global_color;

On my Samsung Galaxy Tab A (2016) SM-T580, there are no problems with the color shaders, but with the compute shader (output = input).

@Alex2782
when i press compute once it works but if i press 25 times the app crashes.
logcat: https://pastebin.com/fYeKr2c9
But when I pressed Add ShaderMaterial first (or after compute), app crashed instantly.
logcat: https://pastebin.com/SFZmHzKT

@Alex2782 any luck?

I will release a debug APK for it soon, last I checked OpenGL ES3. I found some debug settings in the Godot sources, I still have to try if this is also possible with Vulkan.

Firebase - Test Lab has also Mi A2 Lite: full logs (search for 22258 pid)
I have tried with Validation Layer, but I can't see any new useful information yet.
01-06 19:23:09.259: I/godot(22258): _on_timer_timeout
......
01-06 19:23:09.532: I/godot(22258): Shader loaded in 273 ms
......
01-06 19:23:09.587: F/libc(22258): Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 22746 (VkThread), pid 22258 (com.godot.game)
......
01-06 19:23:09.833: F/DEBUG(23682): ABI: 'arm64'
01-06 19:23:09.835: F/DEBUG(23682): Timestamp: 2024-01-06 19:23:09-0800
01-06 19:23:09.835: F/DEBUG(23682): pid: 22258, tid: 22746, name: VkThread  >>> com.godot.game <<<
01-06 19:23:09.835: F/DEBUG(23682): uid: 10160
01-06 19:23:09.835: F/DEBUG(23682): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
01-06 19:23:09.835: F/DEBUG(23682): Cause: null pointer dereference
01-06 19:23:09.835: F/DEBUG(23682):     x0<PHONE_NUMBER>000000  x1<PHONE_NUMBER>000003  x2<PHONE_NUMBER>966e80  x3  000000780f7b3058
01-06 19:23:09.836: F/DEBUG(23682):     x4  000000783cdb2000  x5<PHONE_NUMBER>000000  x6<PHONE_NUMBER>000000  x7<PHONE_NUMBER>000001
01-06 19:23:09.836: F/DEBUG(23682):     x8<PHONE_NUMBER>000002  x9<PHONE_NUMBER>000001  x10<PHONE_NUMBER>000001  x11<PHONE_NUMBER>000004
01-06 19:23:09.836: F/DEBUG(23682):     x12<PHONE_NUMBER>6bbef0  x13<PHONE_NUMBER>000000  x14<PHONE_NUMBER>000000  x15<PHONE_NUMBER>000002
01-06 19:23:09.836: F/DEBUG(23682):     x16 000000783d62eef8  x17<PHONE_NUMBER>6db800  x18<PHONE_NUMBER>4d2000  x19<PHONE_NUMBER>6db800
01-06 19:23:09.836: F/DEBUG(23682):     x20<PHONE_NUMBER>966e80  x21 000000789b174d10  x22<PHONE_NUMBER>000000  x23 000000789b174a10
01-06 19:23:09.836: F/DEBUG(23682):     x24<PHONE_NUMBER>000001  x25 000000780f03e100  x26<PHONE_NUMBER>000028  x27<PHONE_NUMBER>eb8580
01-06 19:23:09.836: F/DEBUG(23682):     x28<PHONE_NUMBER>000000  x29 000000789b177b70
01-06 19:23:09.836: F/DEBUG(23682):     sp  000000789b1740f0  lr  000000789b174a10  pc<PHONE_NUMBER>5d0004
01-06 19:23:09.829: W/Studio:PollNet(21316): type=1400 audit(0.0:4593): avc: denied { read } for name="stats" dev="proc" ino=4026532884 scontext=u:r:shell:s0 tcontext=u:object_r:proc_qtaguid_stat:s0 tclass=file permissive=0
01-06 19:23:09.844: F/DEBUG(23682): backtrace:
01-06 19:23:09.844: F/DEBUG(23682):       #00 pc<PHONE_NUMBER>0f5004  /vendor/lib64/hw/vulkan.msm8953.so (BuildId: 4059f276877a7a61cc16b085624608be)
01-06 19:23:09.844: F/DEBUG(23682):       #01 pc<PHONE_NUMBER>0a0468  /vendor/lib64/hw/vulkan.msm8953.so (qglinternal::vkCmdDrawIndexed(VkCommandBuffer_T*, unsigned int, unsigned int, unsigned int, int, unsigned int)+232) (BuildId: 4059f276877a7a61cc16b085624608be)
01-06 19:23:09.844: F/DEBUG(23682):       #02 pc<PHONE_NUMBER>9fd5e0  /data/app/com.godot.game-KJNnqiAlqU7OqrGjjechwQ==/lib/arm64/libVkLayer_khronos_validation.so (DispatchCmdDrawIndexed(VkCommandBuffer_T*, unsigned int, unsigned int, unsigned int, int, unsigned int)+156) (BuildId: 74b81aeab8816fc078cb99b8199b6b561a30c09b)
01-06 19:23:09.844: F/DEBUG(23682):       #03 pc<PHONE_NUMBER>7e8e94  /data/app/com.godot.game-KJNnqiAlqU7OqrGjjechwQ==/lib/arm64/libVkLayer_khronos_validation.so (vulkan_layer_chassis::CmdDrawIndexed(VkCommandBuffer_T*, unsigned int, unsigned int, unsigned int, int, unsigned int)+452) (BuildId: 74b81aeab8816fc078cb99b8199b6b561a30c09b)

Next week I'll try to add debug_callback. I can test 5 x per day for free at Firebase on real devices, there are also a lot of virtual ones, which are probably unsuitable because of software renderer.

I'm looking for a shader-related crash and I'm not sure if this issue is about it, because nor the title nor the description explicitly mention a crash.
The title says "strange bug". Then again in the description line:

I found a strange bug, where I am rendering 3 sprites, two sprites use png, third use png with gdshader.

The first and only mention of crash is when trying to fix it:

Currently, I am trying to build editor and export a template with debugging symbols to find the line where it's crashing, but I found nothing.

and in the label: crash
I think it would be clearer to add the words crash in both the title and bug description instead of "strange bug" because it's not clear what the issue is without running the MRP (esp. if it only happens on a certain device).
Anyway, I'll be following the other shader-related crash issues, so this is just to help other users find things more easily.

@hsandt: uniform crash on some android devices (Xiaomi Redmi 7A, Google Pixel 2 XL)
#85097
#82602
#86037

I've had this on my TODO list for a while, but haven't found enough time to check it out again. I would have to try it on Firebase Test Lab because I don't have the hardware to reproduce it.

maybe only Adreno 5xx affected by the uniform crash

Google Pixel 2 XL: Adreno (TM) 540
Xiaomi Redmi 7A: Adreno (TM) 505
Mi A2 Lite: Vulkan 1.1.87 - Forward Mobile - Using Device #0: Qualcomm - Adreno (TM) 506

Test on Firebase (Mi A2 Lite)
https://github.com/godotengine/godot/assets/41921395/b515c0e9-5ee7-4bf2-9234-de00cb5fc1af

Is there any update on this crash? I am facing it on Godot version 4.2.1 also which is the latest stable version

OnePlus 3: Adreno (TM) 530

I gave up 3 weeks ago, it takes too much time to test on Firebase (cloud service). I only have Adreno 6xx and 4xx. On Adreno 4xx Godot Vulkan apps do not start at all, the official demo app from Google does, so I will prefer the Adreno 4xx problems first, as long as I don't have Adreno 5xx yet.

Adreno Validation Layer VK_LAYER_ADRENO_debug (on my Samsung Tab S7 - Adreno 6xx):
RuleBundleDescriptorSets: Developers should avoid making multiple API calls to bind descriptor sets for any draw
operation in a command buffer. Instead, descriptor sets should be bundled into a single API call to bind them.
In primary command buffer [0xb400007059be6040] there is(are) [1] violation(s) to this rule for draw operations.
The first violation occurs in render pass [0xb400007046d17e00] and subpass [0] when [3] calls to bind descriptor
sets happen before the draw command [vkCmdDrawIndexed(0xb400007059be6040, 6, 1, 0, 0, 0)].

I will try it out soon, reduce the vkCmdBindDescriptorSets calls before vkCmdDrawIndexed.
@clayjohn:  Or do you know if there are good reasons to pass only one VkDescriptorSet?
// descriptorSetCount = 1
vkCmdBindDescriptorSets(..., ..., ..., p_set_index, 1, &usi->vk_descriptor_set, 0, nullptr);

In the logs I see that after GdShader assignment VkDescriptorSet is always set for 'Instancing' (SET2), even for nodes without GdShader.
 Would it work without it?
vkCmdBindDescriptorSets: p_set_index:  0
vkCmdBindDescriptorSets: p_set_index:  2
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 6 1 0 0 0
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 6 1 0 0 0
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 9 1 0 0 0
vkCmdBindDescriptorSets: p_set_index:  0
vkCmdDrawIndexed: 6 1 0 0 0

set_shader_parameter
Shader loaded in 283 ms

vkCmdBindDescriptorSets: p_set_index:  0
vkCmdBindDescriptorSets: p_set_index:  2
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 6 1 0 0 0
vkCmdBindDescriptorSets: p_set_index:  1  <--- GdShader Uniform
vkCmdBindDescriptorSets: p_set_index:  2  <--- ???
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 6 1 0 0 0
vkCmdBindDescriptorSets: p_set_index:  2  <--- ???
vkCmdBindDescriptorSets: p_set_index:  3
vkCmdDrawIndexed: 9 1 0 0 0

00-00 00:00:00.000     0     0 ? (none)  : --------- beginning of crash
05-07 08:55:08.271 22821 23179 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0

 More details /  logs

Canvas uniforms:

SET0: Light, shadow, etc.
SET1: Is reserved for the material
SET2: Instancing and Skeleton
SET3: Texture

 GdShader /  GdScript

shader_type canvas_item;

uniform vec4 color;

void fragment() {
	COLOR = color;
}

Note: GDScript is not necessary to reproduce the crash. If GdShader is assigned via Editor, the app crashes immediately on startup.
	var mat := ShaderMaterial.new()

	var start_time = Time.get_ticks_msec()
	mat.shader = load("res://global_color_canvas_item.gdshader")

	print("set_shader_parameter")
	mat.set_shader_parameter("color", Vector4(1.0, 0.5, 0.5, 0.5))
	var time = Time.get_ticks_msec() - start_time
	print("Shader loaded in %s ms" % time)

	spriteIcon.material = mat

No crash on Adreno 5xx, with only 1 node (Mi A2 Lite - Firebase Test Lab)
05-07 08:07:10.004 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:07:10.006 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:07:10.007 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:07:10.018 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:07:10.051 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:07:10.051 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0

05-07 08:07:10.759 20316 20586 I godot   : set_shader_parameter
05-07 08:07:10.766 20316 20586 I godot   : Shader loaded in 557 ms

05-07 08:07:11.002 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:07:11.002 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  1
05-07 08:07:11.002 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:07:11.002 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:07:11.002 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:07:11.003 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:07:11.003 20316 20586 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0

Crash (Fatal signal 11) on Adreno 5xx, with 3 nodes (Mi A2 Lite - Firebase Test Lab)

05-07 08:55:07.120 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:55:07.120 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:55:07.121 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:07.121 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:55:07.121 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:07.121 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:55:07.121 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:07.122 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 9 1 0 0 0
05-07 08:55:07.122 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:55:07.123 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0

05-07 08:55:08.202 22821 23179 I godot   : set_shader_parameter
05-07 08:55:08.203 22821 23179 I godot   : Shader loaded in 283 ms

05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  1
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 08:55:08.270 22821 23179 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 9 1 0 0 0

00-00 00:00:00.000     0     0 ? (none)  : --------- beginning of crash
05-07 08:55:08.271 22821 23179 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 23179 (VkThread), pid 22821 (lex.shader_test)

No crash on Adreno 6xx (Samsung Tab S7)

05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 9 1 0 0 0
05-07 18:24:36.987 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 18:24:36.988 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0

05-07 18:24:37.223 29259 29298 I godot   : set_shader_parameter
05-07 18:24:37.223 29259 29298 I godot   : Shader loaded in 36 ms

05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  1
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  2
05-07 18:24:37.238 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  3
05-07 18:24:37.239 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 9 1 0 0 0
05-07 18:24:37.239 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_bind_render_uniform_set -> vkCmdBindDescriptorSets: p_set_index:  0
05-07 18:24:37.239 29259 29298 I godot   : RenderingDeviceDriverVulkan::command_render_draw_indexed -> vkCmdDrawIndexed: 6 1 0 0 0

no crash if all nodes have a uniform shader.
Video: Firebase Test Lab
https://github.com/godotengine/godot/assets/41921395/8eafa7db-0268-4555-9cf0-a1ff734abfad

It looks to me as if the commands have to be executed in the correct order (on Adreno 5xx):
RenderingDeviceGraph::_run_draw_list_command


Select fu

replacing a sub-select w/ a join
@gunnarmorling mind checking  ? :)
PS: of course, the test-case was tested with the old version as well :)

Looks good to me 👍


Module build failed after update from 1.1.4 to 1.1.5

I understand this Error throw from another module. Maybe stylis or maybe styled-jsx.
But 1.1.5 is a patch semver update. It introduce a break change.
I downgrade to 1.1.4. It no problem.
Module build failed: Error: /pages/room.js?entry: Nesting detected at 11:34. Unfortunately nesting is not supported by styled-jsx.
    at Function.disableNestingPlugin (/node_modules/styled-jsx/dist/lib/style-transform.js:19:13)
    at proxy (/node_modules/stylis/stylis.js:1133:30)
    at compile (/node_modules/stylis/stylis.js:679:10)
    at compile (/node_modules/stylis/stylis.js:319:17)
    at stylis (/node_modules/stylis/stylis.js:1270:16)
    at preprocessHelper (/node_modules/babel-plugin-styled-components/lib/css/preprocessUtils.js:95:43)
    at exports.default (/node_modules/babel-plugin-styled-components/lib/css/preprocess.js:12:96)
    at exports.default (/node_modules/babel-plugin-styled-components/lib/visitors/templateLiterals/preprocess.js:48:41)
    at exports.default (/node_modules/babel-plugin-styled-components/lib/visitors/templateLiterals/index.js:23:30)
    at PluginPass.TaggedTemplateExpression (/node_modules/babel-plugin-styled-components/lib/index.js:21:40)
    at newFn (/node_modules/babel-traverse/lib/visitors.js:276:21)
    at NodePath._call (/node_modules/babel-traverse/lib/path/context.js:76:18)
    at NodePath.call (/node_modules/babel-traverse/lib/path/context.js:48:17)
    at NodePath.visit (/node_modules/babel-traverse/lib/path/context.js:105:12)
    at TraversalContext.visitQueue (/node_modules/babel-traverse/lib/context.js:150:16)
    at TraversalContext.visitSingle (/node_modules/babel-traverse/lib/context.js:108:19)
    at TraversalContext.visit (/node_modules/babel-traverse/lib/context.js:192:19)
    at Function.traverse.node (/node_modules/babel-traverse/lib/index.js:114:17)
    at NodePath.visit (/node_modules/babel-traverse/lib/path/context.js:115:19)
    at TraversalContext.visitQueue (/node_modules/babel-traverse/lib/context.js:150:16)
    at TraversalContext.visitMultiple (/node_modules/babel-traverse/lib/context.js:103:17)
    at TraversalContext.visit (/node_modules/babel-traverse/lib/context.js:190:19)
    at Function.traverse.node (/node_modules/babel-traverse/lib/index.js:114:17)

My code used styled-components
const StyledGrid = styled(Grid)`
  .am-flexbox .am-flexbox-item .am-grid-item-content .am-grid-item-inner-content .am-grid-icon {
    width: 33%;
    height: 33%;
  }
`

const ListCenterItem = styled(List.Item)`
  .am-list-line .am-list-content {
    text-align: center;
  }
`

const ListCenterLargeItem = styled(ListCenterItem)`
  .am-list-line .am-list-content {
    font-size: .5rem;
  }
`

const ShareQRCode = styled(Result)`
  .am-result-pic {
    width: auto;
    height: auto;
    margin: 0;
    line-height: inherit;
    background-size: auto auto;
  }
`

My babel setting
{
    "presets": [
        "next/babel"
    ],
    "plugins": [
        [
            "import",
            [
                {
                    "libraryName": "antd-mobile"
                },
                {
                    "libraryName": "recompose",
                    "libraryDirectory": "",
                    "camel2DashComponentName": false
                }
            ]
        ],
        [
            "styled-components",
            {
                "ssr": true,
                "displayName": true,
                "preprocess": true
            }
        ]
    ]
}

I've seen this before and I'm not quite sure why it's happening but it's somehow related to styled-jsx.
Can you try to turn the preprocess option off? It might cause conflicts with the styled-jsx plugin. I haven't raised an issue on next.js yet, since I'm not sure what's causing this.
But on the other hand, preprocess is experimental and if it's what's causing the incompatibility, you should just leave it off for now.

Duplicate of #934

It's not duplicate.
<EMAIL_ADDRESS>dep stylis@2
<EMAIL_ADDRESS>dep stylis@3
stylis has release a major version.
So I think we need publish as<EMAIL_ADDRESS>

@cncolder 1.1.5 upgrade to stylis 3, but stylis is only used for experimental preprocesing.
Apart from that, if the same bug manifests in two different versions, it's still the same bug :wink:


Add Code of Conduct

We recommend that every repo has a code of conduct. If you don’t feel comfortable creating your own Code of Conduct from scratch we highly recommend using one of the templates provided by GitHub. If you do use a template, please read through the template and ensure that you can and will abide by the Code of Conduct.
Please follow these instructions on how to add a Code of Conduct.
Sample: https://github.com/Recode-Hive/Stackoverflow-Analysis/blob/main/CODE_OF_CONDUCT.md

I would like to work on this issue. Please assign me this task.

Can u pls assign me the task

Hi @Princegupta101 !
I have previously worked with quality documentations and have also written medium articles, hence I would like to work on this issue. Could you please assign me this issue?


Gossiper on rampage

Observing last 6 hours on my monitoring solution, I notice table items are significantly increased.
First thoughts it was someone spamming allot of deploys, but observing deploys count I figure out this is not the issue.
Here is some screenshots from my monitor ( 6 hour frame ):
Items finished:

Items current:

Deploys onward:

Table items finished:

Unpleasant consequences:
CPU utilization:

Memory usage:

Interrupts/s:

On load average we can observe strange behavior where in same 6 hours time frame 5 and 15 minutes decrease, but small momentum 1 minute spikes is growing.

Some stepped memory decrease ( is upside down in zabbix ):

Some portional incoming packages here as well, this is zoom 1 hour:

And here is 6 hours frame:

This should be fixed by #697.

This should be fixed by #697.


hardedcoded number of shards in ShardedLRUCache can cause file descriptor exhaustion

If the minimum of 20 is used for options.max_open_files, each shard of the
table cache will only have one entry. This can lead to a quick exhaustion of
file descriptors when there are two L0 tables and many iterators opened at
once. Each iterator effectively uses two file descriptors because the cache is
constantly turning over.

I'm going to work around this problem in chrome by increasing max_open_files
but it seems like accommodating 20 in this case wouldn't require much change to
cache.cc.

There are more details in this comment:
https://code.google.com/p/chromium/issues/detail?id=227313#c11

I haven't yet looked into why the keys used by indexeddb end up in the same
shard. It might just be the same key for every iterator.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 22 Apr 2013 at 11:44

The floor of max_open_files was changed to 74 in leveldb 1.11.0. LevelDB
reserves 10 files for non-sst purposes, leaving 64 for ssts.

Original comment by<EMAIL_ADDRESS>on 13 Jun 2013 at 11:29

Changed state: Fixed

Original comment by<EMAIL_ADDRESS>on 22 Apr 2013 at 11:46


[OAP-TOOLS-1]Add docs and scripts

Add docs and scripts in order to build documentation on website.

@yao531441  Please review and help merge it.

@yao531441  Please review and help merge it.


show namespaces alongside url_name in request panel

As far as I know, no one really asked for this, but I work on projects that make heavy use of namespaces with repetitive urls (e.g. create, edit, index) and having namespaces available in the request panel helps disambiguate and makes for a quicker grep.
Before this PR:

After this PR:

I used : as a separator because that's what you'd pass to e.g. reverse("admin:login"). We can alternatively add a separate 'namespace' title/content section, but this seemed cleaner to me

Thanks, this is great. I think including namespaces directly in the URL name is fine.
However, the new test seems to fail quite often. @AlexCLeduc  Do you have an idea why?

Thanks, this is great. I think including namespaces directly in the URL name is fine.
However, the new test seems to fail quite often. @AlexCLeduc  Do you have an idea why?

@matthiask  Sorry about that, I had trouble running tests locally and figured CI was misconfigured. Turns out the test app never included the admin URLs, looks like it works now.

@matthiask  Sorry about that, I had trouble running tests locally and figured CI was misconfigured. Turns out the test app never included the admin URLs, looks like it works now.

@AlexCLeduc If possible, could you move this test to the RequestPanelTestCase test case in tests/panels/test_request.py? If we don't need it in the integration test case, I'd like to avoid that.

@AlexCLeduc If possible, could you move this test to the RequestPanelTestCase test case in tests/panels/test_request.py? If we don't need it in the integration test case, I'd like to avoid that.

Thank you! 💪🎉

Thank you! 💪🎉


[5.0] Moved From Boris To Psysh

Replaces #6684.
This moves us from boris to psysh. Psysh is better than boris, and more importantly, supports windows, and doesn't have a hard requirement on certain extensions that would cause the framework to be unusable because composer with cry.
This pull also upgrades us from super closure ~1.0 to ~2.0, and from class preloader 1.0.x to ~1.2.
NB, under the hood, all these changes mean that we're moving from php parser 0.9 to ~1.0.

And we're good to go now. Everything is green!

:+1: for windows support

Yeh. This was a big problem before. composer.lock files generated on linux would mean that the dependencies wouldn't even install on windows.

Ping @taylorotwell. All dependencies are stable now.

@GrahamCampbell maybe do a rebase?

I'm not at my PC atm. It might be faster for Taylor to rebase and merge.

Done.

:smile: :smile: :smile:

:smile:

//cc @bobthecow Laravel 5's now shipping with psysh.

@GrahamCampbell Nice!

It seems this PR has introduced some trouble in Mail::queue(). When trying to pass a closure to Mail::queue(), you'll get an InvalidArgumentException in Mailer.php line 393: Callback is not valid.
E.g. try this on a fresh install (latest L5 commit):
Route::get('/queuetest', function () {
	Mail::queue('emails.password', ['token' => '1234'], function ($message) {
<EMAIL_ADDRESS>'test');
<EMAIL_ADDRESS>'test')->subject('Queue test)');
	});
});

If we could change the line
https://github.com/laravel/framework/blob/master/src/Illuminate/Mail/Mailer.php#L384
from
	if ($callback instanceof Closure)

to
	if ($callback instanceof SerializableClosure)

things would work out normal.
Or will this introduce other issues?
Anyway, thanks @GrahamCampbell for the great effort!

Thanks for the catch. I'll fix this.

See #7167.


Crossentropy loss and sigmoid output

Comparing to Keras, it looks like the gradient calculated with "crossentropy" loss function and "sigmoid" output layer activation functions is off by a scale of n-number of outputs. I believe that the derivative of the loss function should take the mean of the outputs.
There are several ways to solve this. We can either make a special case sigmoid_crossentropy_derviative(), or we can make a special sigmoid_crossentropy_loss(). Not sure what I prefer.

This is now fixed by splitting crossentropy into categorical_crossentropy and binary_crossentropy.
categorical_crossentropy matches softmax
binary_crossentropy matches sigmoid
This is hence solved by commit d98bd2b