Build not working?

Is it just for me or is the 0.5.0 build not compiling in Sudio?
Also its not building properly on jitpack.io
log of the build on jitpack.io
find: dirname' terminated by signal 13 find: dirname' terminated by signal 13
Run gradle build
Gradle build script
Downloading https://services.gradle.org/distributions/gradle-2.2.1-all.zip
..................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Unzipping /home/jitpack/.gradle/wrapper/dists/gradle-2.2.1-all/6dibv5rcnnqlfbq9klf8imrndn/gradle-2.2.1-all.zip to /home/jitpack/.gradle/wrapper/dists/gradle-2.2.1-all/6dibv5rcnnqlfbq9klf8imrndn
Set executable permissions for: /home/jitpack/.gradle/wrapper/dists/gradle-2.2.1-all/6dibv5rcnnqlfbq9klf8imrndn/gradle-2.2.1/bin/gradle

Gradle 2.2.1
Build time:   2014-11-24 09:45:35 UTC
Build number: none
Revision:     6fcb59c06f43a4e6b1bcb401f7686a8601a1fb4a
Groovy:       2.3.6
Ant:          Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM:          1.7.0_76 (Oracle Corporation 24.76-b04)
OS:           Linux 3.13.0-36-generic amd64
Getting a list of gradle tasks
Running: ./gradlew clean -Pgroup=com.github.prolificinteractive -Pversion=v0.5.0 -xtest uploadArchives
:library:clean UP-TO-DATE
:sample:clean UP-TO-DATE
:library:compileLint
:library:copyReleaseLint UP-TO-DATE
:library:preBuild UP-TO-DATE
:library:preReleaseBuild UP-TO-DATE
:library:checkReleaseManifest
:library:preDebugAndroidTestBuild UP-TO-DATE
:library:preDebugBuild UP-TO-DATE
:library:preDebugUnitTestBuild UP-TO-DATE
:library:preReleaseUnitTestBuild UP-TO-DATE
:library:prepareComAndroidSupportSupportV42220Library
:library:prepareReleaseDependencies
:library:compileReleaseAidl
:library:compileReleaseRenderscript
:library:generateReleaseBuildConfig
:library:generateReleaseAssets UP-TO-DATE
:library:mergeReleaseAssets
:library:generateReleaseResValues
:library:generateReleaseResources
:library:mergeReleaseResources
:library:processReleaseManifest
:library:processReleaseResources
:library:generateReleaseSources
:library:processReleaseJavaRes UP-TO-DATE
:library:compileReleaseJavaNote: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
:library:extractReleaseAnnotations
:library:mergeReleaseProguardFiles
:library:packageReleaseJar
:library:compileReleaseNdk UP-TO-DATE
:library:packageReleaseJniLibs UP-TO-DATE
:library:packageReleaseLocalJar UP-TO-DATE
:library:packageReleaseRenderscript UP-TO-DATE
:library:packageReleaseResources
:library:bundleRelease
:library:sourcesJar
:library:signArchives SKIPPED
:library:uploadArchivesUploading: com/prolificinteractive/material-calendarview/0.5.0/material-calendarview-0.5.0.aar to repository remote at https://oss.sonatype.org/service/local/staging/deploy/maven2/
Transferring 47K from remote
FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':library:uploadArchives'.

Could not publish configuration 'archives'
Error deploying artifact 'com.prolificinteractive:material-calendarview:aar': Error deploying artifact: Failed to transfer file: https://oss.sonatype.org/service/local/staging/deploy/maven2/com/prolificinteractive/material-calendarview/0.5.0/material-calendarview-0.5.0.aar. Return code is: 401

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED
Total time: 19.643 secs
Trying again without wrapper
Starting a new Gradle Daemon for this build (subsequent builds will be faster).
The message received from the daemon indicates that the daemon has disappeared.
Build request sent: Build{id=cb19a298-3b33-4e7c-8eed-e2501d01999a.1, currentDir=/build}
Attempting to read last messages from the daemon log...
Daemon pid: 204
log file: /home/jitpack/.gradle/daemon/2.4/daemon-204.out.log
----- Last  20 lines from daemon log file - daemon-204.out.log -----
13:48:10.957 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Command execution: started DaemonCommandExecution[command = Build{id=cb19a298-3b33-4e7c-8eed-e2501d01999a.1, currentDir=/build}, connection = org.gradle.launcher.daemon.server.DefaultDaemonConnection@31873729] after 0.0 minutes of idle
13:48:10.958 [INFO] [org.gradle.launcher.daemon.server.DomainRegistryUpdater] Marking the daemon as busy, address: [2482979d-8c63-4cfb-801f-6316ec43c004 port:49651, addresses:[/0:0:0:0:0:0:0:1%1, /<IP_ADDRESS>]]
13:48:10.959 [DEBUG] [org.gradle.launcher.daemon.registry.PersistentDaemonRegistry] Marking busy by address: [2482979d-8c63-4cfb-801f-6316ec43c004 port:49651, addresses:[/0:0:0:0:0:0:0:1%1, /<IP_ADDRESS>]]
13:48:10.960 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on daemon addresses registry.
13:48:10.961 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
13:48:10.965 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
13:48:10.966 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] updating lastActivityAt to<PHONE_NUMBER>966
13:48:10.966 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] Daemon is busy, sleeping until state changes.
13:48:10.967 [INFO] [org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy] Daemon is about to start building Build{id=cb19a298-3b33-4e7c-8eed-e2501d01999a.1, currentDir=/build}. Dispatching build started information...
13:48:10.968 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 15: dispatching class org.gradle.launcher.daemon.protocol.BuildStarted
13:48:10.976 [DEBUG] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Configuring env variables: {HOSTNAME=4a22f13f5471, PWD=/build, OLDPWD=/usr/share/gradle, HOME=/home/jitpack, JAVA8_HOME=/usr/lib/jvm/java-8-oracle, JAVA_HOME=/usr/lib/jvm/java-7-oracle, SHLVL=2, XFILESEARCHPATH=/usr/dt/app-defaults/%L/Dt, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, JAVA7_HOME=/usr/lib/jvm/java-7-oracle, ANDROID_HOME=/android, NLSPATH=/usr/dt/lib/nls/msg/%L/%N.cat}
13:48:10.988 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 13: received class org.gradle.launcher.daemon.protocol.CloseInput
13:48:10.989 [DEBUG] [org.gradle.launcher.daemon.server.DefaultDaemonConnection] Received IO message from client: CloseInput[id=cb19a298-3b33-4e7c-8eed-e2501d01999a.2]
13:48:10.992 [DEBUG] [org.gradle.launcher.daemon.server.exec.LogToClient] About to start relaying all logs to the client via the connection.
13:48:10.993 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] The client will now receive all logging from the daemon (pid: 204). The daemon log file: /home/jitpack/.gradle/daemon/2.4/daemon-204.out.log
13:48:11.002 [INFO] [org.gradle.launcher.daemon.server.health.DaemonHealthTracker] Starting build in new daemon [memory: 954.7 MB]
13:48:11.004 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] Closing daemon's stdin at end of input.
13:48:11.005 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] The daemon will no longer process any standard input.
13:48:11.008 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has started executing the build.
13:48:11.009 [INFO] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=eb3d3b4d-18d6-4b80-b4a0-fc5bf9a17871,javaHome=/usr/lib/jvm/java-7-oracle,daemonRegistryDir=/home/jitpack/.gradle/daemon,pid=204,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=US-ASCII,-Duser.country=US,-Duser.language=en,-Duser.variant]
----- End of the daemon log -----
FAILURE: Build failed with an exception.

What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
No build artifacts found

@Abhiseshan It doesn't work for that version but works with the latest master code: https://jitpack.io/#prolificinteractive/material-calendarview/d00f3e65b2
Shouldn't be a problem with next release.

Released v0.6.0 and it's working again.


Bot token not needed

You don't need to have a bot token for viewing stickers.

Updated .env.example because the token isn't needed.
Updated index.ts to remove headers.

you did when this was created; you don't anymore but Discord limits unauthorized requests much more

you did when this was created; you don't anymore but Discord limits unauthorized requests much more, so it's safer and supported to keep it

ah, really? good to know


Provide backend_config to init command

Fixes issue: #8
Pass backend_config to the init command on init step.
NOTE: It is interesting that the apply job is already running an init. However, to make this change minimal without any unexpected consequences, I am providing the backend_config parameters to the init step.

👍

@KyleTryon @aedifex Please take a look.

Thank you all, this is being resolved in PR #10 and will release as a minor update in just a few moments from writing this comment.


Timing tests

I'd like to time my tests, but the test function exits the program so I can't stick a System.time before and after it

Do you want time being printed for a property or, say, min/max/av of each test in each property?
Or do you want to measure time just once? In this case, you can run checkGroup instead of test?

Detailed timing hadn't occured to me, but that would be cool. I imagine per property or group would be ideal. Thanks for the tip re checkGroup

I guess I could try to contribute this function myself. Would System.time be the best? Millisecond timing would be preferrable

it would require adding IO to the runner. Is that a good idea?

it would require adding IO to the runner. Is that a good idea?

No, it's not. Everything is abstracted in the runner to be able to run Hedgehog in different environment, to test Hedgehog by Hedgehog in particular. So, every functionality is moved to a separate interface, like it's done with HasTerminal and CanInitSeed and similar interfaces.
I personally think there is no need to invent your own interface for this, since there is a library with such interface already: https://github.com/buzden/idris2-time-for-sleep/blob/master/src/System/Time.idr#L151
@stefan-hoeck recently said that he does not mind adding external dependencies to well-maintained well-document libraries. If currently this library is not considered so, well, I can put some effort to document it. Also, this lacks some Interpolation instances for time types to have nicely printable time, but I'll do this, I wanted to do this anyway.

this is more complicated than I expected. I don't have the head space for something non-trivial, sorry

but yes I see the pattern and I see how your lib fits that pattern


add Infinite Lambda to users

@Matt9993 I am wondering if you and Infinite Lambda are open to listing the organization as users of Hera via USERS.md? 🙂 I think it would strengthen Hera's presence in the community and help with adoption!

@flaviuvadan Yeah sure. 🚀

@flaviuvadan Yeah sure. 🚀

thank you and Infinite Lambda, @Matt9993! ❤

Deployed in https://github.com/argoproj-labs/hera-workflows/commit/a3e9262f996ba477a35850c7e4b18ce3d5749687


TSK-4716

TSK-4716 rename builderShowcase to demo

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Katarzyna Dusza seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.


Memory Managment

This is very important to do. This program currently EATS memory.

I can't see anything obviously wrong in ulpm.cpp and a quick check with Valgrind doesn't show any memory leaks. What sort of issues are you having?

When I run the program many tines without restarting the computer, the memory usage starts going up and up.


Avoid NPE

Description
We're not null checking the result of the MDnsObservatoryDiscovery logic, which can return null if there are no records.
Related Issues
Fixes https://github.com/flutter/flutter/issues/31743
Tests
I added the following tests:
Make sure test that this can in fact return null.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

@jonahwilliams - this means if the command is run and no one is publishing anything, it will gracefully continue as if it had never tried to find the mDNS url.
It would have to be tried again after starting the application.

Does this allow us to wait for a flutter view to show up or can it only be run afterwards?

It does! It'll leave observatoryUri as null, which will then fall into the if block underneath which includes:
printStatus('Waiting for a connection from Flutter on ${device.name}...');

I patched it locally and tested the same thing, and it worked fine:
$ flutter attach
Building flutter tool...
Checking for advertised Dart observatories...
Waiting for a connection from Flutter on iPhone XS Max...
Done.
Error 1001 received from application: File system already exists
Syncing files to device iPhone XS Max...
 6,135ms (!)

🔥  To hot reload changes while running, press "r". To hot restart (and rebuild state), press "R".
An Observatory debugger and profiler on iPhone XS Max is available at: http://<IP_ADDRESS>:61265/zJCFlPgRmgo=/
For a more detailed help message, press "h". To detach, press "d"; to quit, press "q".

Initializing hot reload...
Reloaded 0 of 589 libraries in 202ms.

Performing hot restart...
Restarted application in 1,175ms.


feat: outbound message in handle message

This updates to align with changes made upstream in: https://github.com/hyperledger/aries-cloudagent-python/pull/2170
And some other minor tweaks.

This PR doesn't yet account for needing to point to a newer version of ACA-Py, though; I'll defer to the maintainers' preferences for when and how to make that cut-over.

Daniel — could you add a comment to the README — something like this:
Deployments of the main branch of this repository must be used with ACA-Py artifacts created **after** [ACA-Py PR #2170](https://github.com/hyperledger/aries-cloudagent-python/pull/2170)). If you are using an earlier ACA-Py release (e.g., version 0.8.2 and earlier), you **MUST** use the v0.0.1 tag of this repository.


Make phase-banner into real pattern that we might actually use.

The buyer and supplier app are both using their own versions of the phase banner, which are nearly identical.
Talked with @tombye about this yesterday and he said that maybe the thing to do was make the phase into a variable.
Seems to me there's 3 ways forward.

Remove beta-banner pattern: we don't need it, just let the frontend apps do their thing.
Make beta-banner entirely static: both apps are just using the same markup and we don't anticipate a need to change either of them.
Make the phase into a variable: this way we have a pattern, even though for all intensive porpoises, we don't really need the flexibility.

I think we want 2 or 3.  What do you think, @tombye?

Don't forget the version on the homepage that has white on blue.

@ralph-hawkins I was thinking that would be better handled by the app itself, but maybe you're right that it would be better handled by the toolkit.

Having all the styles in the same place sounds good to me

Sorry, @ralph-hawkins, but @tombye has vetoed the frontpage changes.  Keep the styles in the supplier app because the homepage is a special thing.
:boom: :boom: :ralph: :boom: :boom:

I did, sorry Ralph. I just think the home page styles are specific to that cascade so it feels a bit strange viewing them out of that context.
At the least, this forms a good base for 99% of usage across the apps so it can be grown if needed (we can chat about it and see).

@pcraig3 it seems like renaming the macro file makes this a breaking change, shouldn't it be 18.0.0?

ughhhh.
fiiiiiiine.

Once all conflicts are sorted 👍


TypeError: '<' not supported between instances of 'int' and 'str'

getting this while searching, using Python 3.6.0:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/fuse.py", line 495, in _wrapper
    return func(*args, **kwargs) or 0
  File "/usr/local/lib/python3.6/site-packages/fuse.py", line 572, in open
    fi.flags)
  File "/usr/local/lib/python3.6/site-packages/fuse.py", line 800, in __call__
    return getattr(self, op)(*args)
  File "/usr/local/lib/python3.6/site-packages/ytfs/ytfs.py", line 323, in mod
    return method(self, self.__pathToTuple(path), *args)
  File "/usr/local/lib/python3.6/site-packages/ytfs/ytfs.py", line 565, in open
    if yts.obtainInfo(): #FIXME coz it's ugly.
  File "/usr/local/lib/python3.6/site-packages/ytfs/stor.py", line 235, in obtainInfo
    elif self.preferences['audio']: fm = sorted(aud, key=_k)
TypeError: '<' not supported between instances of 'int' and 'str'

Hi, what version do you use? Please try latest version from master. PyPI package needs to be updated, hopefully I'll do this soon


Add xz 5.4.5.bcr.2

This fixes compatibility with incompatible_disallow_empty_glob

Hello @Attempt3035, @Vertexwahn, modules you maintain (xz) have been updated in this PR. Please review the changes.


Decompose tablet thrift svcs main

Decompose tabletserver.thrift into multiple files that contain more targeted services (scan, ingest, tablet management, and tablet server).

Full IT build succeeded

@ctubbsii - did you want to review this further? I'm thinking we should merge this sooner rather than later. FWIW, I ran a full IT build last night again and it succeeded.

@ctubbsii - did you want to review this further? I'm thinking we should merge this sooner rather than later. FWIW, I ran a full IT build last night again and it succeeded.

Delayed response. No. You addressed all the things I had comments on. Thanks :smiley_cat:


Allow all weapons/tools to use either keyboard or mouse

Wow, I thought this would have taken a lot more code.
Good Job!


Fix statement separation

In the ProgramParser class there is a method parse() that parses DSL code line by line. To split input source it uses the following logic:
ProgramParser:parse
Problem
If you pass a source code with a newline after ; of the last statement this logic will throw an exception.
For example, see test

Thank you.


Sync dev to main

Date: 20/06/2023
Developer Name: @chaithraramesh31
PR Number(s):- #373
Issue Ticket Number:- #370
Backend changes
[ ] Yes
[x] No
Frontend Changes
[x] Yes
[ ] No
Database changes
[ ] Yes
[x] No
Breaking changes (If your feature is breaking/missing something please mention pending tickets)
[ ] Yes
[x] No
Deployment notes(Any special instructions for the deployment)
[ ] Yes
[x] No
Tested in staging
[x] Yes
[ ] No
List of PRs going in this Sync: #373
Videos
I have attached the videos of both desktop and mobile views of the discord-group page.
https://github.com/Real-Dev-Squad/website-dashboard/assets/111289485/9ee8e662-be2c-4b2e-a786-659cf5f13fdc
https://github.com/Real-Dev-Squad/website-dashboard/assets/111289485/ace252c8-cab9-4377-9da4-f391eb94d527

Adding videos of the dashboard page on staging site
https://github.com/Real-Dev-Squad/website-dashboard/assets/111289485/3d76f0f0-6e9e-4648-8bdb-e690e1e67fca
https://github.com/Real-Dev-Squad/website-dashboard/assets/111289485/00f38688-89c4-452d-9b56-8627447f97e5


git: 2.26.1 -> 2.26.2 (security, CVE-2020-11008)

See: https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.17.5.txt

Motivation for this change
I did already test the basic functionality and it should be fine, but I'll do some additional checks to be sure. -> LGTM :)
Diffoscope: No file additions/removals.
TODO: Needs port to stable (but 2.25.3 -> 2.25.4 might be better / more appropriate).
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

WIP: Regression in the AArch64 test.

We have an openssl update in staging which should become the new staging-next by the end of the day. I suggest to include this update there as well.

@FRidh I changed the base branch to staging-next, if you meant staging -> staging-next I can also change it to staging (currently you should also be able to do this without any issues/conflicts).


Adding Meme Generator

PR pending #350
Meme Generator made using JS, CSS, HTML5
Take a look @DhanushNehru

Please update the main readme.md file, list of projects section @Tanmay-Giram

Assign to me


The context gets replicated after update

Checklist:

[x] I updated to the latest version available
[x] I cleared the cache of my browser

Release with the issue:
2.2.5
Last working release (if known):
Browser and Operating System:
iOS Safari

Description of problem:

I create a collapsible card with sub cards. At the top level I defined a context.
After update, the context gets copied to all sub card levels.
That should NOT happen. I even have another card where this doesn't happen. 3 examples included below.
Javascript errors shown in the web inspector (if applicable):

Additional information:
The original ll_key card, as I originally created:
ll_key: test_card
ll_context:
  group: sensor.temperatures_koelkasten
  name: Temperatuur
type: custom:collapsable-cards
title_card:
  type: tile
  name: <%= context.name %>
  entity: <%= context.group %>
cards:
  - type: custom:auto-entities
    card:
      type: entities
    filter:
      template: >
        {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
        context.group %>','entity_id') or [] %}  {%- for entity in entities -%}
          {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
        {%- endfor -%}   {{ ns.entries }}
    sort:
      method: none
  - type: custom:auto-entities
    card:
      type: history-graph
      hours_to_show: 48
    filter:
      template: >
        {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
        context.group %>','entity_id') or [] %}  {%- for entity in entities -%}
          {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
        {%- endfor -%}   {{ ns.entries }}
    sort:
      method: none

The same card after update (contains copies of ll_context in the sub cards):
ll_key: test_card
ll_context:
  group: sensor.temperatures_koelkasten
  name: Temperatuur
type: custom:collapsable-cards
title_card:
  type: tile
  name: <%= context.name %>
  entity: <%= context.group %>
cards:
  - type: custom:auto-entities
    card:
      type: entities
      ll_context:
        group: sensor.temperatures_koelkasten
        name: Temperatuur
    filter:
      template: >
        {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
        context.group %>','entity_id') or [] %}  {%- for entity in entities -%}
          {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
        {%- endfor -%}   {{ ns.entries }}
    sort:
      method: none
    ll_context:
      group: sensor.temperatures_koelkasten
      name: Temperatuur
  - type: custom:auto-entities
    card:
      type: history-graph
      hours_to_show: 48
      ll_context:
        group: sensor.temperatures_koelkasten
        name: Temperatuur
    filter:
      template: >
        {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
        context.group %>','entity_id') or [] %}  {%- for entity in entities -%}
          {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
        {%- endfor -%}   {{ ns.entries }}
    sort:
      method: none
    ll_context:
      group: sensor.temperatures_koelkasten
      name: Temperatuur

The same card where ll_context doesn't replicate to all the lower card levels. The only difference is that I start with an entities card on top level:
ll_key: test_card
ll_context:
  group: sensor.temperatures_koelkasten
  name: Temperatuur
type: entities
entities:
  - type: custom:collapsable-cards
    title_card:
      type: tile
      name: <%= context.name %>
      entity: <%= context.group %>
    cards:
      - type: custom:auto-entities
        card:
          type: entities
        filter:
          template: >
            {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
            context.group %>','entity_id') or [] %}  {%- for entity in entities
            -%}
              {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
            {%- endfor -%}   {{ ns.entries }}
        sort:
          method: none
      - type: custom:auto-entities
        card:
          type: history-graph
          hours_to_show: 48
        filter:
          template: >
            {% set ns=namespace(entries=[]) %}  {% set entities=state_attr('<%=
            context.group %>','entity_id') or [] %}  {%- for entity in entities
            -%}
              {%- set ns.entries=ns.entries+[{'entity': entity, }] -%}
            {%- endfor -%}   {{ ns.entries }}
        sort:
          method: none

Update. The copying of the  ll_context is not unique for the collapsible card. Happens with auto-entities as well.

@daredoes please share your thoughts about this issue:

do you agree that modification of ll_key card is a bug (in this case cards gets modified with redundant copies of ll_context)?!
is so I'll be patient and wait for a fix. Otherwise this is not the way forward for me after all.

Best Eric

@erkr Definitely a bug. Just started a new job this week. I'll try to find some time for the fix this weekend. Should be a pretty quick one. Examples to come as well. Appreciate the patience.

Great to hear that, and success with the new job, that will be a challenging period.

I am having the same issue, weirdly only with one card.

I am having the same issue, weirdly only with one card.

I noticed cards that have entities as root are not effected

@daredoes
Hi Daniel, I have decided to use the decluttering card for my new dashboards.

They supports nested templates by design.
From maintenance point of view I like that clean card instances (just two line plus variables). That keeps hosting cards more readable.

Performance wise, your solution looks better.
I will keep the linked Lovelace evaluation card on my system for a while. So I can assist you to verify this issue.
Succes with your new job
Eric

Hé @daredoes
Are you still planning to fix the issue? If not I will remove my dashboard that I preserved for testing

@erkr my bad on ignoring this for awhile. got swept up in the new job and some life stuff. Just took a stab at fixing the problem. Wrote a test that I think confirms the issue.
I need to do a bit more serious testing. Still, back up your system and then gives this a go.

New jobs can be  challenging the first months. Will give it a try in the coming days

I just did a quick test and it seems to work. Although I did have to delete ll_context from a key because it was overwriting the context in the template. Thanks for working on this!

I did a quick check and it is not solved. A key card was still extended with additional context blocks


Error on make command

Hi,
I get the following error on calling asyncdo to make a LaTeX file in Neovim:
Error detected while processing function <lambda>8[1]..<SNR>52_finalize:
line    3:
E40: Can't open errorfile /tmp/nvimwyvfNv/2

I was able to reproduce the issue using this minimal vimrc and calling Make:
set errorformat=%f:%l:\ %m,%f:%l-%\\d%\\+:\ %m
set makeprg=rubber\ -f\ -d\ -q\ -s\ --warn=misc\ '%'
call plug#begin('~/.vim/plugged')
Plug 'hauleth/asyncdo.vim'
call plug#end()
command! -bang -nargs=* Make call asyncdo#run(<bang>0, &makeprg, <f-args>)

Regular make works fine on the same file. Any idea? Thanks!

Do you have write access to /tmp/nvimwyvfNv?

Also does that happen when using other tools (other than rubber whatever this is).

Thanks for the reply. I own the nvim directory (drwx).
Using makeprg=pdflatex\ '%' results in the same issue (regular make works as well).

@vxid I am not speaking about nvim directory but about /tmp directory and /tmp/nvimwyvfNv

Yes I should have been clear that's the one I was mentioning.

Interestingly I just read about makeef and errorfile. I tried to set it manually to tmp/make.log but neovim seems to override that setting (both using plain make and Make).

@vxid this is expected behaviour as I generate new temp filename each time you run asyncdo#* functions. After job is done such file is deleted. For some reason it seems that this file is deleted before it can be loaded.
What OS are you using? And with NeoVim version?

I'm using Antergos (but basically Arch + few extra repos). I use neovim version 0.2.2-1.

I tried it on regular Vim to be sure, same error.

Does touch /tmp/nviXfFSHC/3 returns error? If not then does file exists afterwards?

touch returns no errors. Moreover, if I touch tmp/nvimxxx/i just before try i in make then no error is returned but no compilations takes place (and quickfix window is empty).


Adding style for inktoolbar

Draft PR attempting to debug an issue adding a style for ink toolbar.

/azp run

@ranjeshj Looks like the CI refused to run for some reason :/

@ranjeshj Looks like the CI refused to run for some reason :/

We were just trying to debug something. nothing to see here :)


Basic Professional Portfolio Functionality

HTML/CSS
User Story
AS AN employer
I WANT to view a potential employee's deployed portfolio work samples
SO THAT I can review samples of their work and assess whether they're a good candidate for an open position
Acceptance Criteria
GIVEN I need to sample a potential employee's previous work
WHEN I load their portfolio
THEN I am presented with the developer's name, a recent photo or avatar, and links to sections about them, their work, and how to contact them
WHEN I click one of the links in the navigation
THEN the UI scrolls to the corresponding section
WHEN I click on the link to the section about their work
THEN the UI scrolls to a section with titled images of the developer's applications
WHEN I am presented with the developer's first application
THEN that application's image should be larger in size than the others
WHEN I click on the images of the applications
THEN I am taken to that deployed application

Website meets basic criteria while viewing on monitor


BART directions broken

Directions have not been using BART for a few days. GTFS issue?

Example of itineraries that would obviously use BART, were it available


aria-hidden=true on body breaks Accessibility

Summary:
Screen reader users cannot interact with any modal content because aria-hidden=true is incorrectly placed on the body tag.
Steps to reproduce:

Open a test modal, https://reactcommunity.org/react-modal/examples/minimal.html.
Activate modal dialog.
Check that aria-hidden=true is incorrectly placed on the body tag of the modal's html document.

Expected behavior:
Screen reader user is trapped inside the modal dialog.
Actual behavior:
Screen reader user can't interact with anything on the page at all because of aria-hidden=true on the body.

There's a new aria-modal=true attribute that should be placed on the modal dialog which could remove the need for aria-hidden.

@pauljadam can you do a little research on this topic and/or provide more sources for this?

http://w3c.github.io/aria/aria/aria.html#aria-hidden
aria-hidden (state)
Indicates whether the element is exposed to an accessibility API.
If the body is hidden,  then the whole body tag is no longer exposed to an Accessibility API. You only want to hide the main content container(plus header/footer) of the page not the entire  tag.

http://w3c.github.io/aria-practices/#dialog_modal
This demo uses aria-modal=true rather than aria-hidden. http://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html

I can confirm this behavior. It also looks like focus management isn't happening on the modal, and it's missing the dialog role (though those could be separate issues). Here's how to fix it:

When the modal opens, put aria-hidden="true" on sibling element(s) to the dialog instead of the body, and change it back to false when it closes.
Send focus to the dialog close button on open.
Send focus back to the triggering button on close.

Following the ARIA practices guide is a great suggestion!

Thank you so much @pauljadam and @marcysutton.

Just wanna weigh in here for a moment.  There is a lot of confusion around this behavior in the modal.  I've been working to improve documentation and make things more clear in our 2.0 release which is overdue unfortunately.  I can assure you that when used properly the modal is accessible.  We've used it extensively in Canvas.
@pauljadam The example you linked to is the minimal example. It is the minimal needed to make the modal show up and function.  react-modal uses the concept of the appElement to determine how it hides things from screen readers.  The modal is appended to the body element (by default).  We then hide the element that was provided by Modal.setAppElement(el).  At some point in time that was made to default to the body (a behavior I hate vehemently because it will 100% break screenreaders).  In order to use the modal properly users must set the app element otherwise the modal has no idea what to hide.  For example:

       ....

In this case, we'd want to set the appElement to div#application such that it would get aria-hidden applied to it.  And our final markup would look similar to:

       ....

       ...

That would keep screen readers inside the modal.
In version 2.0 of the modal appElement will be a required prop called getAppElement which should be a function that returns the DOM element that should be aria-hidden.
Thanks also for pointing out aria-modal.  It appears that that is an attribute that can be added to a role="dialog" to force them to be modal in nature.  I'd not seen that before.  It's interesting.
@marcysutton Thanks for adding your input here.  It's super valuable!  When Ryan initially created the modal the state of role="dialog" was a bit interesting.  See his writeup about why not role="dialog" here.  We added role="dialog" to the modal back in 2e806c724e8c0bbd6bc7dc49a8a2e4ba592e9ca6 and it was released as part of version 1.5.0.  It was however removed and made optional because of the concerns listed in #237.  So in short, if people want the dialog role added, they are more than welcome to add it themselves.
I'm not sure why we default to setting the focus to the body.  I'm sure @ryanflorence might recall why it was done.  That being said, we do provide an onAfterOpen prop that can be used to set focus to the close button.  We also provide an onRequestClose prop that can be used to set focus back to the calling element.  This is going to change to an afterClose prop in 2.0 for additional clarity.  There are enough cases I've seen where the element used to open the modal doesn't exist when the modal gets closed for me to feel comfortable with always returning to what triggered the modal.
Sorry all, this was a bit long winded.  Issues like this are very tough for me.  They open my eyes more to the need to have better documentation around different assumptions the modal makes.
@diasbruno - I don't think there's much we can do about this on our 1.x branch.  I think things will be much better and clearer in 2.0.

@claydiffrient what about when you have a header and footer that you need to hide also? Can you do setAppElement on multiple html elements? e.g.  http://codepen.io/anon/pen/jBxwZr
aria-modal=true looks like it would eliminate the need to manage aria-hidden

@pauljadam Currently, it doesn't in all the use cases I've needed it for, there as always been a root-level non-body application container.  What we can do about that though is make it so getAppElement in version 2.0 will handle receiving an array of elements to hide.
aria-modal does look really promising, but that also requires that the modal have a role of dialog which has concerns with screen readers that I mentioned in my lat comment.
I'm sad to hear that about the client sites.  I want to fix that so badly, but it now ends up being a breaking change which necessitates a major version bump.  We've done a poor job of documenting the need for that, something I hope to rectify.

@claydiffrient I would still recommend role=dialog for normal dialogs and role=alertdialog for error type dialogs. This is what the aria spec and practices recommends.
I read the post from 2014 about the worries of role=dialog, that issue has no affect on macOS VoiceOver screen reader or mobile screen readers VoiceOver iOS or Android TalkBack. Only JAWS and NVDA include the automatic switching to application mode vs browse mode and they can switch back to browse mode if they're in application mode, I cover that issue in this blog post under the NVDA Forms Mode Behavior & Insert + Spacebar Key heading http://www.deque.com/blog/aria-modal-alert-dialogs-a11y-support-series-part-2/
In a normal role=”dialog” or “alertdialog” NVDA will go into Forms Mode when focus is sent into the dialog. Forms Mode means NVDA users an only tab around the dialog. They can’t press the up/down arrow keys to read through the dialog with linear navigation.
To exit forms mode NVDA users can press Insert + Spacebar keys and then enter Browse Mode where they can use the arrow keys and quick navigation keys to read through the dialog rather than just the TAB key.
Most accessibility folks are confused by this behavior and wonder if screen reader users understand how the read the dialog or if the dialog code is broken because it’s not working properly with NVDA. This is similar to the problems with using role=”application”. Forms Mode/Browse mode issues don’t affect other screen readers like VoiceOver and TalkBack. I’ve heard that JAWS isn’t affected by the role=”alertdialog” Forms Mode issue like NVDA.

I would just say that I think it's very important to use role=dialog and role=alertdialog to convey the accessibility semantics of the element. It's also the only way to give the dialog an accessible name and description via aria-labelledby and aria-describedby. This is something I regularly treat as an accessibility failure for client websites if it's not present. The 2 roles speak different semantics to a screen reader user, e.g. alertdialog says "Alert" on some screen readers when you enter the dialog.

@sinabahram I was able to get the example working in IE 11 Win 10 using NVDA latest, it appears to trap the modal dialog with NVDA whereas with Narrator you can still navigate to the grayed out content so maybe NVDA likes aria-modal="true" and Narrator still not supporting it. Narrator also has no issues with forms mode or browse mode.

I can see that, but given the two roles which do we use?  The modal is meant to be general purpose so it could potentially be used with either option.  So do we continue with what we have with role being optional and up to the client to implement?  I think perhaps that might be the best course of action.  Consumers will be able to specify if they want role=dialog or role=alertdialog.  In absence of a role prop being passed in we could add a warning and give reference to possible a11y issues without a defined role.

If they're setting the role they should also set the accessible name either via aria-labelledby pointing to the h1 in the dialog or an aria-label if there is no visible title for the dialog. Accessible description via aria-describedby should also be set if possible. If you're adding the accessible name, role, and description, should also do the ARIA 1.1 aria-modal=true attribute.
The biggest problem is still that aria-hidden=true is ending up on the body tag in all of the examples of this modal dialog I've seen in the wild during Accessibility testing. I figured it had to be in a widely used framework after seeing on different sites so I googled "ReactModal__Body--open" and ended up here :) I thought maybe I could fix it at the source rather than telling all my clients individually that aria-hidden has broken their entire application :)

I can totally see that.  I'll see what I can do about the role and other aria attributes.  In version 2.0 of the modal body will not be hidden, that I can for sure promise.

Testing was done with Jaws and IE11, a very popular combination. For nvDA, of course one uses Firefox and Chrome instead of IE given the myriad of performance issues and far better support on Firefox and Chrome.
Jaws18+IE11 does not hide the virtual content outside of the modal.

Worth nothing aria-modal is part of the ARIA 1.1 spec which is still a Candidate Recommendation:
https://www.w3.org/TR/wai-aria-1.1/#aria-modal
that means support is not guaranteed at all, so maybe it's an option for the future. 🙂  Personally, I don't know anything about browsers/Assistive Technologies support for aria-modal, if anyone has data to share that would be super useful.
About the role=dialog debate, that really depends on the content of the modal. I'd suggest to have a look at this post from Mr. Marco Zehe, who's a developer, Mozillian, and a blind person:
https://www.marcozehe.de/2015/02/05/advanced-aria-tip-2-accessible-modal-dialogs/
Basically, when using role=dialog then any text within the modal should be associated to some focusable element with aria-describedby, otherwise it will simply be ignored by screen reader in forms/focus mode. This would be very hard or maybe impossible to do programmatically, since we can't predict the nature of the modal content. VoiceOver (and TalkBack?) is an exception to this de-facto standard behaviour.
Think at a modal with content made exclusively by some long text or images without any interactive elements. It could be a warning, or some long inline help, whatever. Using role=dialog by default would make that content completely ignored by screen readers. A resounding silence. Yes, users could manually switch back to browse mode, but that's not a strong argument. I even doubt users would have any clue they have to switch back to browse mode.
Also about alertdialog opinions may differ 🙂  Personally, I'd second Mr. Zehe when he says:

Don’t use it. Seriously, I’ve been working with ARIA for over seven years now [the article is from 2015 --Ed.], and I still haven’t figured out why role “alertdialog” was ever invented.

aria-modal=true works in VoiceOver on iOS and macOS. It worked in NVDA also. Have you tested the ARIA authoring practices demo?
aria-hidden=true on the body is still the major problem here.

Interesting. Yep, also according to what Mr. Bryan Garaventa says here http://www.ssbbartgroup.com/blog/differences-aria-1-0-1-1-deprecations-additions/
it's only supported on iOS using VoiceOver iOS 9.X [data from January 6th, 2017].
I would wait for ARIA 1.1 to become an approved Recommendation. Then, I'd agree modal dialogs that use role=dialog should also use aria-modal=true to ensure forward compatibility.

Have you tested the ARIA authoring practices demo?

Time (the lack of) is my biggest problem 🙂

I really want to record an accessibility demo with react-modal, but aria-hidden="true" on the body is preventing me from doing that. It will also prevent screen reader users from accessing webpages with react-modal open. Do you have an ETA on when a fix for this will ship?

@marcysutton Sorry for the delay on getting this out.  I was hoping that v2 would ship sooner, but I haven't been able to get it out the door, but it's much closer.  I'm thinking we may pare down a few things and ship with just the biggest things initially.  I wish I could give you a more concrete idea of when it might happen, but I can't really offer much more than two weeks or so perhaps.

Another alternative you could do is use the Modal.setAppElement() method to declare a different appElement to apply aria-hidden="true" to.  This will prevent it from being applied to the body.

Ooh, that should work for now. Thanks!

Really great insights everyone, thank you so much.
For anyone else like me stumbling across the issue....
RE allowing the modal to be read out by screenreaders/voiceover, whilst the body has aria-hidden="true", with the currently latest version (2.2.4):
Nothing suggested was working for me, I was probably doing something wrong. I tried Modal.setAppElement(), role="dialog", aria-modal,  all in various places.
I am now declaring a false ariaHideApp prop, which solves it, with a side effect.
<Modal
  isOpen
  onAfterOpen={this.handleOnAfterOpen}
  ariaHideApp={false}>

    {children}

</Modal>

ariaHideApp is true by default - therefore aria-hidden will be applied to the appElement (default appElement is the body).
Without setting the appElement to something other than the default body, and by also setting ariaHideApp to false, when a modal is open, all content in or outside of the modal could be read out. For my use case this is the desired behaviour. We may manually set some aria-hidden attributes to a couple of elements that we don't want read out in certain instances.
Is there a reason why ariaHideApp isn't documented?
Looking forward to the next version so this can be cleaner, great work! 👍

Sigh....I just wasted a couple days before finding this. I was totally confused about how to use the app element - and now I get this a bit more, but Marcy Sutton is right that there should just be a way to apply it to all sibling elements.
If react-modal didn't assume there should only be 1 "app element", you could probably get the correct behavior by using querySelectorAll and body > :not(.modal-class) or something similar. That's not super simple, but it'd work OK.
IMO, the current default is 100% wrong - the default experience is guaranteed to be inaccessible. If you provide no app element, the screen reader experience isn't great, but it's better than nothing being being accessible.

Hello,
forgive my possible ignorance, however this seems more than just an enhancement to me. A lot of pages, e. g. twitch, some local service pages, are completely inaccessible because of inaccessible pop overs resulting from aria-hidden being set to true. This includes login forms, etc. No screen reader can read the pages and frustrating workarounds have to be used to guesstimate what you're supposed to be doing. Since the webpages in question use react I thought this might be the right place to comment about this. Imagine if you click a pop over the entire screen goes blank. Not exactly pretty.
Is there a chance anything could be done? I know that most devs will take a while to update their libraries but maybe this will lessen the blow in the future. I feel like this is more important than people make it out to be, especially seeing this issue has been open since march. I could be wrong, I'm new to react development in general so I'm speaking mostly from a user's standpoint. I just know that a lot of websites are incredibly frustrating to use because of probably this little oversight.

Hi @Ghorthalon, maybe it was missing to do something about it.
So, what next to improve react-modal accessibility:

[x] allow define role attribute.
[x] allow to pass custom aria-* attributes.
[ ] improve aria-hide-app mechanism.

This issue is still open, was there ever a resolution? It's a pretty big show-stopper, so it would be good to get the docs updated or whatever else needs to happen.

This week, I'm going to start a new branch to address this accessibility issues. Testing and review would be really appreciated.

@diasbruno aria-hidden is not removed at all, because you check for reference count in beforeClose:
https://github.com/reactjs/react-modal/blob/master/src/components/ModalPortal.js#L133
but you decrement this counter is afterClose:
https://github.com/reactjs/react-modal/blob/master/src/components/ModalPortal.js#L140

@sheerun It make sense. So we need to move the logic on beforeClose to afterClose. Can you open a PR?

@diasbruno I've sent one. Could you finish it? I don't have any more time today
It adds aria-modal to modal portal and removes adding aria-hidden to body by default. Also fixes issue I mentioned.

Sure. Thank you!

@pauljadam @marcysutton @afercia If you'd like to test it before @diasbruno releases it, I've published it under following package name on npm: @sheerun/react-modal

Release v3.1.6.

Just to be clear, is it not acceptable in any situation to have ReactModal.setAppElement('body')?
I am asking because I'm building a component library for my company, and since many teams will be using it I cannot guess (or constrict) what their React root element is going to be. Even though this component library will mostly be used internally for the foreseeable future, I don't want to make things inaccessible if I can avoid it.
One solution I thought of was just using the appElement prop and requiring implementers of the component library modal to pass in the root element, but that's fairly tedious to do for every modal in an application.
Another solution was to have ReactModal as a named export of the component library so that implementors could have ReactModal.setAppElement(document.getElementById('root')) defined just once in their app, but that's a weird api to make them adhere to.
Basically my question is what is the status quo for setting appElement when it is unknown what the app element is going to be?

This should be closed, no?

@kylemh no, I don't think this should not be closed.
Google Lighthouse reports setting aria-hidden=true on the body as an accessibility fault: https://web.dev/aria-hidden-body/

Screen readers and other assistive technologies don't announce content that's marked as hidden. Applying the aria-hidden="true" attribute to your  element hides your entire web page from assistive technology users.

Sure, but that would only happen if you incorrectly do: ReactModal.setAppElement('body')

@diasbruno you closed and then reopened this, but announced a release as if the fix was out. I believe you meant for this to be closed because setting the appElement no longer was optional and you hoped people wouldn't set it to be document.body.
I think one way to definitely mark this as closed would be to expand documentation or the dev warning here to ensure that nobody is hiding the body.

@kylemh apologies, I must have been looking at an older version of ariaAppHider.js:
https://github.com/reactjs/react-modal/blob/5641f4088bf99163ab9f7fb2e3b01431de00e184/src/helpers/ariaAppHider.js#L1
but looking at the the newer code, I see it is fixed:
https://github.com/reactjs/react-modal/blob/5189e5b6928319a831edad27cecd964ebd59ec33/src/helpers/ariaAppHider.js#L4
I checked a small personal example and did see that aria-hidden is not set on  by react-modal, so yeah it seems this issue should be closed.
Perhaps a new issue should be opened to update the docs. For example, the "minimal example" doc links to this codepen which seems to indicate that aria-hidden is true on the ... but that example is using an old version of react-modal.

We also have docs/examples/set_app_element.md which says:

You'll notice in this example that the aria-hidden attribute is applied to the #main div rather than the document body.

Thanks for confirming, @techieshark


Integrate Zero Trust Auth

[ ] Remove single process bottleneck: https://github.com/livebook-dev/livebook/pull/1938#discussion_r1236788315

[x] Move current_user_id as part of "identity_data" (the current logic should be moved to our Cookies store (and we should rename Cookies to Session)

[ ] Retrieve both name and email from providers

@cristineguadelupe Identity is too vague because we know it is an identity provider but we don't know where its source come from.


put_change/3, put_new_change/3 and change/2 should check if the value is different from the one in the model

If the value is the same as in the model, we won't add it to the list of changes. If it is different, we add it.
We will also introduce force_change/3 which works as put_change/3 today.
Is someone interested in picking this up? We should release v0.11.1 afterwards with those fixes.

@josevalim I will try to come up with something tonight. :)


[Removal]: I need help to remove my machine from the denylist , my machine is at real location, long time no rewards~~~~Please!!

Hotspot Name
Rapid Merlot Snail
Hotspot b58 Address
112ijMLYAq4QQKgFPsAzqUJazuS2WcwgeRYfhbvQKTfLEdkXBjR6
Discord Handle
╲⎝⧹🅼🅰🆇™⧸⎠╱ -#7113
Hotspot Manufacturer
Bobcat
Removal Reason
I set my machine at real location,but I dont know why my machine is in the deny list, so please remove it form the deny list please !!
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information

together sanction China miner! they are friend of Evil Russia.

together sanction China miner! they are friend of Evil Russia.

 This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


Feat/add legal docs table

[x] Adds a new table and model for LegalDocuments
[x] Adds a new table and model for RequiredLegalDocument
[x] Adds a cron job to send HelloWorks document requests to users who need to fill out a document.
[x] Exposes some extra info in graphql on Expense so that hosts can avoid paying out users who need to fill in their forms. There's a new field userTaxFormRequiredBeforePayment.

A user collective can have many LegalDocuments (they can fill in many of them over the years and of different document types)
LegalDocuments has a composite unique constraint so that there will only be one record for a given combination of year, CollectiveId(the collective filling in the form) and documentType.
A host collective can have many RequiredLegalDocuments.
eg. Open Source Collective will have a required document of type US_TAX_FORM. Note that:

it only has one at the moment but the data model supports adding more in the future.
some other host might require the same document type and the user will not have to fill in another form.

Part of the work for fixing how open source collective collects tax forms

Coverage increased (+0.07%) to 64.636% when pulling a0cae13469e394c5e6edcc275432c450c10026b9 on feat/add-legal-docs-table into 69e4bf3439ff427324c90276d39b6a825c3b68bd on master.

Looks great! Good to merge from my perspective.


Finalize About page

almost done for the first release. All that is missing is the link to the Apple AppStore and Android PlayStore. This can only be done when we have released the app, I think?

Removed the links that are not ready yet (app store review, buymeacoffee). we can release a new version once those links are available.
A separate issue has been created for that.


All I/O must happen through recvmsg, with room for a cmsg

I think that explains the mysterious ERRNO=5 Input/Output errors we've all been seeing intermittently.
It's that little load-bearing sentence from the Linux kTLS docs:

If no cmsg buffer is provided, an error is returned if a control message is received.

I'm going to test my theory but for now I believe if a control message is received (such as a TLS 1.3 session ticket) then we get this error:
--- STDERR:              ktls::integration_test ktls_client_rustls_server_tls_1_3_aes_256_gcm ---
thread 'ktls_client_rustls_server_tls_1_3_aes_256_gcm' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: Uncategorized, message: "Input/output error" }', tests/integration_test.rs:346:39
stack backtrace:

However if we configure the server not to send session tickets, like so:
    server_config.send_tls13_tickets = 0;

Then the same test passes. The logs show that four tickets are sent by default:

And Wireshark confirms that:

This was closed by #28


Permission issue when rebuilding

PLEASE DO NOT INCLUDE ANY PASSWORDS OR TOKENS IN YOUR ISSUE!!!
Describe the issue
When trying to remake a container the script fails as it doesn't have the proper permissions.
I've been developing using an 18.2 version of BC. Now we wanted to make sure that everything still works on the 19.1 OnPrem version, so I wanted to remove to old container and create a new.
Scripts used to create container and cause the issue
$containerName = 'lanitol'
$password = 'P@ssw0rd'
$securePassword = ConvertTo-SecureString -String $password -AsPlainText -Force
$credential = New-Object pscredential 'admin', $securePassword
$auth = 'UserPassword'
$artifactUrl = Get-BcArtifactUrl -type 'OnPrem' -version '19.1' -country 'dk' -select 'Latest'
$licenseFile = 'd:\nav\infar\udvikling\bc19.flf'
New-BcContainer `
    -accept_eula `
    -containerName $containerName `
    -credential $credential `
    -auth $auth `
    -artifactUrl $artifactUrl `
    -imageName 'bc19cu1' `
    -licenseFile $licenseFile `
    -shortcuts DesktopFolder `
    -updateHosts

Full output of scripts
BcContainerHelper is version 2.0.22
BcContainerHelper is running as administrator
Host is Microsoft Windows 11 Pro - 21H2
Docker Client Version is 20.10.10
Docker Server Version is 20.10.10
Removing container lanitol
Removing lanitol from container hosts file
Removing lanitol-* from container hosts file
Remove-Item : Adgang til cloudfilen blev nægtet
At C:\Program Files\WindowsPowerShell\Modules\BcContainerHelper\2.0.22\Misc\Remove-DesktopShortcut.ps1:26 char:21
+                     Remove-Item $folderName -Recurse -force
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Remove-Item], Win32Exception
    + FullyQualifiedErrorId : System.ComponentModel.Win32Exception,Microsoft.PowerShell.Commands.RemoveItemCommand...

Additional context
The problem is the Desktop folder, or the files within. For some reason the files now need administrator rights to delete. And even though I run powershell as Admin the script fails.
As soon as I manually delete the folder, everything is fine.

I am puzzled by the "access to the cloud-file was denied"
Is your desktop setup with something special?

Define special :)
OneDrive synchronizes Pictures, Documents, Teams-chatfiles and Desktop. But other than that there is nothing touching the files.

Does it work if you place the shortcuts on the desktop (not in a folder)?
I will try to setup onedrive sync of my desktop.

Seems to be only if the shortcuts are inside the folder.
Using -shortcuts Desktop allows for deleting them when recreating the container; regardless of shortcuts setting. There however I get an error from OneDrive asking me to check if I had enough permissions for the shortcuts to by synchronised. The script and I are allowed to delete the shortcuts, so it is somehow OneDrive trying to "take ownership" of the files that fails.
Manually deleting the shortcuts from the folder also lets the script recreate the container. Here it ignores the folder when deleting the old setup, and just reuses the folder when creating the shortcuts.
Using CommonDesktopFolder allows the script to delete shortcuts and folder when recreating the container.

I have added some resilience to the code in order to avoid failing when removing the folder (which is the problem)

shipped in 2.0.23


about AUC

Hi! Thanks for your great work.
It seems that there may be an error in the AUC calculation. Since the result of logits has a shape of [n, 2], the input for calculating the AUC score should be the values from either logits[:, 1] or logits[:, 0], which would serve as the score values. Using torch.max(logits, dim=1)[0] as the AUC score input might not be correct in this context.
# evaluate the performance
logits, labels = model.predict(target_data)

maxvalue, maxindex = torch.max(logits, dim=1)

preds = logits.argmax(dim=1)

mi_f1 = eval_micro_f1(labels, preds)
ma_f1 = eval_macro_f1(labels, preds)

if args.source in {'DE', 'EN', 'ES', 'FR', 'PT', 'RU'}:
    auc = eval_roc_auc(labels, maxvalue)
else:
    auc = 0.0

Hi!
Thanks for pointing this out.
You are right. This is a typo. It should be maxindex.
Thanks for your feedback.

Thank you for your reply!
To clarify, the AUC calculation ideally requires a continuous score to assess the model’s performance across various thresholds, rather than using a discrete label output. In this case, logits[:, 1] would serve as the continuous score representing the confidence for the positive class. Therefore, using maxindex (which contains 0 or 1 values) might not provide the most accurate AUC measurement, as it essentially reduces the calculation to a single threshold.
Thank you again for considering this!

Thanks for your reply! You are right. We should use logits[:, 1] instead of maxindex for more accurate evaluation.
Thanks for your suggestion! We will update the scripts later.


Add CHANGELOG.md

Remove no-longer updated roadmap.md file and expose changes info in a proper CHANGELOG.md

Changelog is now present


webpackChunkName invalid

🐛 Bug Report
Use @loadable/webpack-plugin for packaging and introduce components in the following way
const Home = loadable(() => import(/* webpackChunkName: "my-chunk-name" */ '@mobile/pages/Home'));
But after packaging, the file name is still xxx-bundle-xxxxx.js It seems that the configured file name does not take effect.
I use"webpack": "^5.36.2",
To Reproduce
Generate a file according to the specified name.
Expected behavior
A clear and concise description of what you expected to happen.
Link to repl or repo (highly encouraged)
Please provide a minimal repository on GitHub.
Issues without a reproduction link are likely to stall.
Run npx envinfo --system --binaries --npmPackages @loadable/component,@loadable/server,@loadable/webpack-plugin,@loadable/babel-plugin --markdown --clipboard
Paste the results here:
## System:
 - OS: macOS 10.15.7
 - CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
 - Memory: 1.27 GB / 16.00 GB
 - Shell: 5.7.1 - /bin/zsh
## Binaries:
 - Node: 12.16.2 - ~/.nvm/versions/node/v12.16.2/bin/node
 - Yarn: 1.22.4 - ~/.nvm/versions/node/v12.16.2/bin/yarn
 - npm: 6.14.4 - ~/.nvm/versions/node/v12.16.2/bin/npm
## npmPackages:
 - @loadable/component: ^5.15.0 => 5.15.0
 - @loadable/server: ^5.15.0 => 5.15.0
 - @loadable/webpack-plugin: ^5.15.0 => 5.15.0

Related: #750. Webpack chunk naming is not always controllable


Add options for background grids

It should be easily possible to change the background of the stroke order diagram.
Examples:

Bounding Box
Cross
Diagonals
3x3 grid

Reopening due to the request in https://github.com/chill-chinese/stroke-order-animator/issues/94#issuecomment-2296081697.

I think this feature should be implemented by consumers of the library to fit their specific needs. Otherwise, people will probably want to customize every aspect of the grid (dashed vs. solid lines, dash length, gap length between dashes, line width, line color, ...) which sounds like a maintenance nightmare.
Here is some example code to draw an outline and a combination of the cross and diagonals with dashed lines:
class StrokeOrderDiagramBackgroundPainter extends CustomPainter {
  const StrokeOrderDiagramBackgroundPainter(this.theme);

  final StrokeOrderDiagramTheme theme;

  @override
  void paint(Canvas canvas, Size size) {
    const color = Colors.black;
    final paint = Paint()..color = color;

    const dashLength = 10.0;
    const dashSpace = 5.0;

    const topLeftCorner = Offset.zero;
    final topRightCorner = Offset(size.width, 0);
    final bottomLeftCorner = Offset(0, size.height);
    final bottomRightCorner = Offset(size.width, size.height);
    final topMiddle = Offset(size.width / 2, 0);
    final bottomMiddle = Offset(size.width / 2, size.height);
    final leftMiddle = Offset(0, size.height / 2);
    final rightMiddle = Offset(size.width, size.height / 2);

    void paintDashedLine(Offset p1, Offset p2) {
      double getOffset(double length) {
        double d = 0.0;
        while (d + dashLength < length) {
          d += dashLength + dashSpace;
        }
        d -= dashSpace;
        return (length - d) / 2;
      }

      final dx = p2.dx - p1.dx;
      final dy = p2.dy - p1.dy;
      final length = sqrt(dx * dx + dy * dy);

      final unitDx = dx / length;
      final unitDy = dy / length;

      double p = getOffset(length);

      while (p < length) {
        final p1d = Offset(p1.dx + p * unitDx, p1.dy + p * unitDy);
        final p2d = Offset(
          p1.dx + (p + dashLength) * unitDx,
          p1.dy + (p + dashLength) * unitDy,
        );
        canvas.drawLine(p1d, p2d, paint);
        p += dashLength + dashSpace;
      }
    }

    // Outline
    canvas.drawLine(topLeftCorner, topRightCorner, paint);
    canvas.drawLine(topRightCorner, bottomRightCorner, paint);
    canvas.drawLine(bottomRightCorner, bottomLeftCorner, paint);
    canvas.drawLine(bottomLeftCorner, topLeftCorner, paint);

    // Cross
    paintDashedLine(topMiddle, bottomMiddle);
    paintDashedLine(leftMiddle, rightMiddle);

    // Diagonals
    paintDashedLine(topLeftCorner, bottomRightCorner);
    paintDashedLine(topRightCorner, bottomLeftCorner);
  }

  @override
  bool shouldRepaint(covariant CustomPainter oldDelegate) => false;
}

Wrap the painter in a CustomPaint widget and stack it with the StrokeOrderAnimator:
Container(
  constraints: BoxConstraints.loose(const Size.square(diagramSize)),
  child: Stack(
    children: [
      CustomPaint(
        size: const Size.square(diagramSize),
        painter: StrokeOrderDiagramBackgroundPainter(diagramTheme),
      ),
      StrokeOrderAnimator(
        controller,
        size: const Size.square(diagramSize),
      ),
    ],
  ),
)


Pagerank crash

There seems to be an intermittent segfault in the pagerank test.  So far I can only reproduce it on Linux with:
pytest -v --forked -k test_pagerank

(--forked comes from the pytest-forked plugin, which allows pytest to run each test in a sub-process for better isolation.)
I get no useful output besides:
==================================================================== test session starts ====================================================================
platform linux -- Python 3.8.10, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 -- /home/sseibert/miniconda3/envs/mgng/bin/python
cachedir: .pytest_cache
rootdir: /home/sseibert/repo/mlir-graphblas, configfile: setup.cfg, testpaths: mlir_graphblas/tests
plugins: forked-1.3.0, cov-2.12.1
collected 178 items / 177 deselected / 1 selected

mlir_graphblas/tests/test_algorithms.py::test_pagerank Fatal Python error: Segmentation fault

Current thread 0x00007f0a3f9af740 (most recent call first):
  File "/home/sseibert/repo/mlir-graphblas/mlir_graphblas/engine.py", line 980 in python_callable
  File "/home/sseibert/repo/mlir-graphblas/mlir_graphblas/algorithms.py", line 470 in pagerank
  File "/home/sseibert/repo/mlir-graphblas/mlir_graphblas/tests/test_algorithms.py", line 160 in test_pagerank
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/python.py", line 183 in pytest_pyfunc_call
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 84 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/python.py", line 1641 in runtest
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 162 in pytest_runtest_call
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 84 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 255 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 311 in from_call
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 254 in call_runtest_hook
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 215 in call_and_report
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/runner.py", line 126 in runtestprotocol
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pytest_forked/__init__.py", line 62 in runforked
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/py/_process/forkedfunc.py", line 65 in _child
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/py/_process/forkedfunc.py", line 50 in __init__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pytest_forked/__init__.py", line 67 in forked_run_report
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pytest_forked/__init__.py", line 46 in pytest_runtest_protocol
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 84 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/main.py", line 348 in pytest_runtestloop
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 84 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/main.py", line 323 in _main
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/main.py", line 269 in wrap_session
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/main.py", line 316 in pytest_cmdline_main
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 84 in <lambda>
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/config/__init__.py", line 162 in main
  File "/home/sseibert/miniconda3/envs/mgng/lib/python3.8/site-packages/_pytest/config/__init__.py", line 185 in console_main
  File "/home/sseibert/miniconda3/envs/mgng/bin/pytest", line 11 in <module>
FAILED                                                                                [100%]

========================================================================= FAILURES ==========================================================================
_______________________________________________________________________ test_pagerank _______________________________________________________________________
:-1: running the test CRASHED with signal 11

I should note that if I leave out --forked, the test passes.

Some bizarre findings. The segfault is happening in the 2nd call to mlalgo.pagerank. A single call is always fine, but the next call causes the segfault.
The problem goes away if any of the following are true:

Remove the line irb.util.del_sparse_tensor(prev_score)
Force recompilation of the algorithm each time it is run (by setting _pagerank = None prior to 2nd call)
Call scipy.sparse.csr_matrix() anytime prior to the compilation of pagerank
Set a Python breakpoint prior to pr = _pagerank(graph, damping, tol, maxiter), then simply continue
Run on a Mac

Suffice it to say that I'm completely baffled. For now, I'm going to remove the del_sparse_tensor line.


Consul is not populated on Orc startup

This might be a re-open of #497.
Steps:

Have MySQL Master/Slave cluster running (cluster alias is 'enterprise')
Have Consul running (In my test, running in -dev mode
Start Orc ("ConsulAddress": "<IP_ADDRESS>:8500")
Query consul

$ consul kv get mysql/master/enterprise
Error! No key exists at: mysql/master/enterprise

I had to manually execute submit-masters-to-kv-stores in order to see the info in consul

#549 has been merged 17 days ago, which addressed this exact issue. Can you please make sure you have the latest master?

My apologies, I did not pay attention to merge dates. I'm using releases in my training classes cause that is easier for students to install. I'll have to wait for 3.0.14 then.


Only Version.MajorMinorPatch is available as variable

When the SDK-Style project file contains this:

net461;netstandard2.0
0.6.0-pre
DESC

then only the variable Version.MajorMinorPatch is filled. Version.Full for example is empty. I guess it has something to do with "-pre" ?

@BenjaminBest I used the original project as a base for my extension, since I needed support for custom XML attributes. I have since discovered that it's a lot easier to just use PowerShell script to do this.
Here's a quick script to parse your XML structure and write the value to build variable.
[xml]$doc = Get-Content -Path .\path\to\MyProject.csproj
$env:MyBuildVar = $doc.Project.PropertyGroup.AssemblyVersion

That's it, two lines.


ci: update workflow, fix to TDengine branch main

Codecov Report

Merging #176 (a027521) into main (4159cfb) will increase coverage by 1.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #176      +/-   ##
==========================================
+ Coverage   79.14%   80.25%   +1.11%
==========================================
  Files          20       20
  Lines        2474     2472       -2
==========================================
+ Hits         1958     1984      +26
+ Misses        516      488      -28

see 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Add High-Level Editing Handlers

detect cursor changes with onDidChangeCursorSelection
direct all changes through one of onPointInsert, onPointBackspace, onPointDelete, onRangeReplace, and onRangeDelete
create and save editor state

@ccullip take a look at the changes and comment if you see anything suspicious

Is there an easy way for me to test the brick-editor.js? I'm a little confused on how deleting a character if the editor is unparsable would work. Right now it seems like the backspaceHandler would call onPointBackspace which would then call UpdateEditorState which wouldn't do anything. Unless I'm missing something.

You can checkout my branch and run it?

Did you intend to make backspace and delete not work if unparsable?

Yes within the region we allow edits. There's probably another function we need to write that checks both parseable and if the cursor is in that region.

Okay, looks fine to me then.


Browser mode throws "Failed to fetch dynamically imported module" errors on files from repo or sometimes even dependencies

Describe the bug
I'm in the process of comparing all of the test runners on a very basic vue 3 composition API + TS app. So i setup testing lib and a basic test, it worked. Then I tried to add @vitest/browser and I updated vitest.config.ts to use playwright and chromium but vitest started errors like

ReferenceError: Vue is not defined

Reproduction
I haven't seen this error anywhere else but I reproduced it in StackBlitz, the setup is fairly similar to the one on my machine and gives the same result
https://stackblitz.com/edit/vitest-dev-vitest-urjsz7
Could it be a setup error on my part ? Or is it a bug ?
System Info
 System:
    OS: macOS 14.3
    CPU: (8) arm64 Apple M2
    Memory: 532.70 MB / 24.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.14.2 - ~/.nvm/versions/node/v18.14.2/bin/node
    npm: 9.5.0 - ~/.nvm/versions/node/v18.14.2/bin/npm
    pnpm: 8.15.3 - /opt/homebrew/bin/pnpm
    bun: 1.1.0 - ~/.bun/bin/bun
  Browsers:
    Chrome: 123.0.6312.87
    Safari: 17.3
  npmPackages:
    @vitejs/plugin-vue: ^4.6.2 => 4.6.2
    @vitest/browser: ^1.4.0 => 1.4.0
    @vitest/ui: ^1.4.0 => 1.4.0
    vite: ^4.5.3 => 4.5.3
    vitest: ^1.4.0 => 1.4.

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

@vue/test-utils expects Vue to be defined on a global object (UMD) in its browser build for some reason. Try deduping Vue in the config instead:
export default {
  resolve: {
    dedupe: ['vue'],
  }
}

it solves the Vue import issue and now it's another package. I updated the stackblitz

TypeError: Failed to fetch dynamically imported module: https://vitestdevvitesturjsz7-5l23--5179--7dbe22a9.local-credentialless.webcontainer.io/home/projects/vitest-dev-vitest-urjsz7/test/Hello.spec.ts?browserv=0

I'm also facing this issue but with importing http://localhost:5173/@id/@vitest/coverage-v8/browser?import and only in GitHub actions: https://github.com/sapphiredev/shapeshift/actions/runs/10980564537?pr=396. This is clearly not something I can influence, because it's a vitest library. I also get the same issue with coverage Istanbul as seen here: https://github.com/sapphiredev/shapeshift/actions/runs/10979357381/job/30483626781?pr=396.
I have no idea what I can do to resolve this.


update rest_api

add ui to read a product from a shopcart

How can we check whether this UI is working for read?

How can we check whether this UI is working for read?

I think Yufei

Codecov Report

Merging #103 (8cc088f) into main (941622b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #103   +/-   ##
=======================================
  Coverage   94.77%   94.77%
=======================================
  Files           5        5
  Lines         268      268
=======================================
  Hits          254      254
  Misses         14       14

Continue to review full report at Codecov.

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

BDD will test the UI wheather work. We should write both UI and BDD.

IBM Cloud toolchain: Delivery Pipeline deployed shopcarts to dev, including commit ba7087c19c44c253edf50276b4cf8bc41270d664

IBM Cloud toolchain: Delivery Pipeline deployed shopcarts to prod, including commit ba7087c19c44c253edf50276b4cf8bc41270d664


Implementation

Dear authors,
Thank you for sharing a post about your solution. When are you planning to release your implementation and corresponding checkpoints?

Hi Magauiya,
Thank you for being so interested.
This work is done during my internship at Alibaba. Due to the legal limitation, I have no right to release my implementation. Thus I detail the implementation in the blog.
If you have any questions, please get in touch with me.
If I am permitted to release the implementation, I will notify you here.

Hi @Magauiya,,
I get permission to release models. Sorry for being late.
Models: https://github.com/ryanxingql/winner-ntire22-vqe/releases/tag/v1.0
README: https://github.com/ryanxingql/winner-ntire22-vqe/blob/main/README_test.md


Suggestion to modify Author and Title based mostly on the youtube video title

Hello,
I've already implemented this feature locally in my bot, but it might be a nice addition in general. Perhaps we could also give users the option to enable or disable this feature using an option in the application.yml file, such as replaceTrackCredentials: true/false.
Many YouTube songs are often uploaded by users who might incorrectly space out the original author's name or include collaborating authors in the title that aren't reflected in the YouTube author field. Here are some examples:

Song: Purple Disco Machine - Substitution
Video URL: https://www.youtube.com/watch?v=7x5lqqji9ww
Actual video title: Purple Disco Machine, Kungs - Substitution (Official Music Video) ft. Julian Perretta
Current result if any bot uses "track.author - track.title": Purple Disco Machine - Purple Disco Machine, Kungs - Substitution (Official Music Video) ft. Julian Perretta)

Song: CCR - Fortunate Son (MOONLGHT Remix)
Video URL: https://www.youtube.com/watch?v=Fg2G8SIb7n4
Actual video title: CCR - Fortunate Son (MOONLGHT Remix)
Current result if any bot uses "track.author - track.title": MOONLGHT - CCR - Fortunate Son (MOONLGHT Remix)

Song: Rarin - GTA
Video URL: https://www.youtube.com/watch?v=m5wel03bCk4
Actual video title: Rarin - GTA (Official Lyric Video)
Current result if any bot uses "track.author - track.title": rarin - Rarin - GTA (Official Lyric Video)

What I'm suggesting is that the plugin compares the video author with the title and then decides (mostly because of the "-") what the author and title are (because the author is in general on youtube videos infront of the dash). This would allow us as bot users to simply use "track.author - track.title" without needing to manually check if the video author is different or includes co-authors.

Also I forgot to mention this:
If the video title has no "dash", then just keep it as is

I don't believe this is the duty of the source manager to do. Not only are YouTube title formats generally inconsistent, but occasionally the videos are not uploaded by the artists themselves. This means it's difficult to 'clean' the titles whilst avoiding erroneous string replacements.
For these reasons, I do not think this would be a good idea to include within the source manager/plugin itself. This should remain user-land code so the user can best choose how to proceed with title sanitisation whilst avoiding opinionated replacements done by the source.

Same could be also done with youtube videos which are generated:
Remove this if it exists from the author: - topic
And remove this if it exists from the title: Topic -

Ah sry, mb.
I didnt notice you replied already..


Validate physical device API version returned

The AMD beta driver has been returning VkPhysicalDeviceProperties with an apiVersion of 0.0.1. A test case should be added to ensure that a sane API version is returned.

Thanks for the suggestion. We will take a look at adding a test for this.

This should be checked by vulkan-cts-1.0.2 release.


[feature] control input devices

I would like to see a feature which adds the support for Input Devices. I would like to control the volume and/or mute (with the M-key) my microphone with my nanoKontrol.

would like too

additionally it would be nice to control the output volume of an Input Device that has been set to "listen to this device"


Liminglong/develop

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.10 out of 11 committers have signed the CLA.:white_check_mark: lijicheng123:white_check_mark: JackLian:white_check_mark: liujuping:white_check_mark: LeoYuan:white_check_mark: eternalsky:white_check_mark: wendell0316:white_check_mark: BARMPlus:white_check_mark: milocooper:white_check_mark: duoduoObama:white_check_mark: StringKe:x: proclmlYou have signed the CLA already but the status is still pending? Let us recheck it.


[de] HassLightSet with satellite area

To set the brightness in the area of the activated satellite does not work.
I think it should be something like this:
language: de
intents:
  HassLightSet:
    data:
      # Change brightness of all lights in the same area as a satellite device
      - sentences:
          - "<setzen>[ <artikel>] Helligkeit[ auf] <brightness>"
          - "[<artikel> ]Helligkeit[ auf] <brightness>[ <setzen>]"
          - "dimme[ <artikel> Helligkeit][ (auf|zu)] <brightness>"
          - "[Helligkeit][ (auf|zu)] <brightness> dimmen"
        response: "brightness"
        requires_context:
          area:
            slot: true

But even when I'm using this in custom_sentences to extend the build in HassLightSet, this is conflicting with the current
- "[<setzen> ]<artikel> Helligkeit[ (<lichter>|<alle_lichter>)][ <area>][ auf] <brightness>[ ein]"
(https://github.com/home-assistant/intents/blob/main/sentences/de/light_HassLightSet.yaml#L15)
I think the above sentence needs to be changed, because without all optional parts it reduces to
- "Helligkeit <brightness>"
which I think does not make sense without
        requires_context:
          area:
            slot: true

for custom sentence, you need to create your own intent and script.
This example works:
language: de
intents:
  BrightnessSet:
    data:
      - sentences:
          - "Helligkeit <brightness>"
        requires_context:
          area:
            slot: true

BrightnessSet:
  action:
    service: light.turn_on
    data:
      brightness_pct: "{{brightness}}"
    target:
      area_id: "{{ area_id(area) }}"
  speech:
    text: "Ok"


often recieving "rpc error: code = 13 desc = transport is closing" when fetching or putting data in datastore

I'm constantly getting "rpc error: code = 13 desc = transport is closing"
It usually happens after my connection is ideal for a few minutes. I even tried running a noop against datastore (delete a key that will never exist every minute) but to no avail.
What is this error (seems Docker related according to Google search)? Why am I getting it?

I am seeing this as well against bigtable.  I had assumed it would retry as code 13 is listed here:
https://github.com/GoogleCloudPlatform/google-cloud-go/blob/master/bigtable/bigtable.go#L76
13 is codes.Internal
Any reason why this error is propagating up? Do I have to explicitly turn on retries?
Also very minor note, looks like that file I linked to above is not go fmt'ed

Retrying on internal errors was added very recently to Bigtable. Are you using the latest code? Also, what ops are you seeing fail without retries?

Last week we updated our vendoring as we saw the retries were added.  We were hoping it would eliminate all our errors as they seemed retryable (we were seeing code 14 as well).  It actually eliminated a number of code 14 errors for us but we are still occasionally seeing these code 13 transport is closing errors.
We have seen this on ApplyBulk and ReadRows.
Thanks

Can you provide any of the logging that you're seeing? As of the current bigtable client code, every error 13 and 14 (INTERNAL and UNAVAILABLE) should be retried for ReadRows. ApplyBulk will also be retried unless the mutations have the timestamp set to ServerTime and therefore aren't idempotent. You should see logging like "Retryable error: <error details>". If you see this but the error doesn't bubble up to your application, OR you see some retries but the request deadline is reached before a retry is successful, then from the client's perspective it's working ok. If you see that these errors aren't be retried at all then something strange is going on.

I am seeing this while using the datastore package. If I don't use the open datastore.Client for a while and send a query after a long time (I haven't measured) being idle, I get this error.
It causes calls to methods like datastore.Get/GetAll to return this error. So if the caller code is not doing retries around these things, I don't think it's being retried in the datastore package.

Our logs are also full of these nowadays, and I'm trying to figure out whether we need to build our own retry or not. Would be nice to know what's the future of these internal, clearly temporal errors - are they retried by Datastore package internally or not?

I'm also encountering an rpc error: code = 13 desc = transport is closing error while reading from the datastore using delay.
Here is some stackdrive log info that might help:
app_engine_release=1.9.48

insertId: "58bd97d8000bb8414ec9ff53"

requestId: "58bd97d300ff0b4697d8a690700001737e666176656c6166756e000131000100"

instanceId: "00c61b117c29b9d1145756713c24440d3dd19d089bf89b045e642984b25cd0fca50f7c10118f1430"
  line: [
   0: {
    time: "2017-03-06T17:09:44.710185Z"
    severity: "ERROR"
    logMessage: "rpc error: code = 13 desc = transport is closing"
   }
  ]

@GregorioDiStefano @ahmetb @teelahti Are you still experiencing this against datastore?

By the way, the datastore docs specifically say not to retry INTERNAL errors (code 13).

@jba Not anymore it seems, I just see a lot of this now:
 2017/06/11 21:00:07 transport: http2Client.notifyError got notified that the client transport was broken EOF.
but not sure if this is related or not.

That error is harmless and either will go away or has already.
Closing due to lack of activity.

@jba I am still seeing this against datastore.

related, but not exactly the same: i'm getting 2-3 such errors per hour

rpc error: code = Internal desc = transport: oauth2/google: incomplete token received from metadata

the line of code is doing client.Get with a datastore.NameKey. vast majority of the same call works, so i don't suppose there's real oauth config issue

A couple of things are clear: 1. these errors aren't coming from the datastore client, and 2. the only remedy that the client could take is to retry. Besides the warning in the docs against retrying INTERNAL errors, there is the issue that adding retry when the error is permanent could result in a hanging RPC if no deadline has been set on the context. Since datastore is heavily used, I don't think it wise to introduce that bad behavior in the hope that it will smooth over some of these rare problems.
I suggest that datastore users experiencing INTERNAL errors on idempotent calls should implement their own retry logic that gives up after a certain amount of time or number of tries.

@jba it seems this error happened to other langs' clients too. https://github.com/GoogleCloudPlatform/google-cloud-node/issues/2039
we are still getting this a few per day with latest grpc and cloud-go. (bigtable)

@uschen Note: if you are still seeing these kinds of errors, we welcome you to file a new issue so that we can triage.


doubts / questions / suggest / request

I have Dragon Naturally speaking 12 professional installed and i create a UNIVERSAL VOICE PROFILE, i have author rights about it, this is a recent video (sorry for spanish audio)
https://youtu.be/wvVl1eeMBRo?t=117

What is delay, why?, broadband?
Is possible have this offline?
What is accuracy
Is possible add new vocabulary
What is maximum of record in time
.
.
.

Tnks

So, to answer these briefly,

There is a brief delay because you have to upload the audio over the internet, and then there is a much shorter processing time. However, I believe both are acceptably small.

Broadband vs narrowband refers to the audio sample rate; narrowband is 8khz (8000 samples per second), while broadband is 16khz and up.
Narrowband is generally used with telephone voice recognition, browsers brovide broadband-quality audio.

No, this is an online-only service.
The accuracy is very good and continually improving
It is not possible to add new vocabulary today, but I will pass the request along to the team. It may be added in a future update.
The maximum is actually determined by file size rather than audio length. Up to 100mb may be uploaded for a single transcription. For broadband WAV audio, this is around 20 minutes. But for audio compressed with Opus or FLAC, it is considerably longer, easily several hours.

Oh, and thanks for that video - I can't comment on the quality, but it looks like Watson over the internet is faster than dragon running locally which surprised me!

Is possible reproduce online final transcript, something like this:
https://app.voicebase.com/autonotes/private_detail/17519536/hash=apuaYW1qaW6WaG7FlmaTcWuPmJ2YlWZsmGjHkZluxZhmlpaUl2ebmptrl5vE?vbt=0

Color by speaker, if different speaker then different color

Yes, set timestamps: true in your opening JSON and it will include the start and end time of each word. You'll have to create the highlighting/illumination part, but that gives you all the data you need to do it.

Not currently, but as with the custom vocabulary, I'll pass the request along and it may be added in a future update.

about hightlighting pls show me how or share me a link with example

Well, you have the link you provided that can serve as an example. There's also https://github.com/watson-developer-cloud/speech-javascript-sdk/blob/master/speech-to-text/timing-stream.js which does something similar. That's about all I've got though.


Ivy preview

Hi! Check this issue please.
https://github.com/angular/angular/issues/30981#issuecomment-501009207

This comment seems to indicate that private inputs are not allowed.

@bstaley yes, we need to get fix.

This library is updated to latest version of angular with ivy support.
Thanks All


fix: save correct version in the package.json

:tada: This PR is included in version 1.4.4 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: