Examples not compiling in Vitis when copying manually

Using all the latest stuff from Xilinx, Xilinx Unified Installer 2021.2 including the patch released 6 January.
$ uname -rs
Linux 5.4.0-21-generic
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal
HW: U50
It seems that Vitis do not accept the examples if they are not installed via Vitis IDE.
Is it not possible to just copy the files into directory Vitis_examples ? Is some extra needed to be done?
Clone https://github.com/Xilinx/Vitis_Accel_Examples
Copy Vitis_Accel_Examples to usb stick
Copy Vitis_Accel_Examples from usb stick to target machine into the directory ~/.Xilinx/Vitis/201.2/Vitis_examples
Start Vitis
Create a project, slask2, based on Vitis_Example "Hello world"
Compile
This compilation will fail because the main program can not find xcl2.hpp
The xcl2 source files are placed in
~/.Xilinx/Vitis/201.2/Vitis_examples/Vitis_Accel_Examples/common/includes/xcl2
But this directory is not included in the "include" folder in the project,
nor is xcl2.hpp or xcl2.cpp copied to
~/workspace/slask2/src
~/workspace/slask2/Emulation-SW/src (This directory is empty)
Note, it is possible to compile and execute the project if the makefile system is used in a terminal window.

Hi @StefanThorlacius ,
Can you please try following steps to import Locally downloaded repository in Vitis IDE?
In Vitis IDE, open Window > Preferences then select Xilinx > Example Repositories or Library Repositories. Here, you should see a list of library/example repos. Either set the Location of an existing repository to the local dir, or add a new repo, and set the new repository’s location:

That is a good tip, thanks (my path is currently correct)
I can see the examples and I can create projects based on the examples but when I create an project something goes wrong.
However the problem is of slightly different type, one of the libraries in the "include folder" gets messed up.
Note, I manually copied Vitis_Accel_Examples into
/home/xxxxx/.Xilinx/Vitis/2021.2/Vitis_examples/Vitis_Accel_Examples
Should the content in the cloned directory Vitis_Accel_Examples be copied directly into /home/xxxxx/.Xilinx/vitis/2021.2/Vitis_examples?
If you for a project go to properties -> settings -> (folder "tool setting") -> gcc Host compiler (x86_64) -> includes
One of the include directories are defined as
"${workspace_loc:${ProjName}/libs/common/includes/xcl2}
This path is expanded to a mess in the "include" folder for a project, and there is no .../libs/" under the project in ${workspace_loc:${ProjName}
Beside xcl2.hpp and xcl2.cpp is not copied to "${workspace_loc:${ProjName}/libs/common/includes/xcl2"
The are only located in ~/Xilinx/Vitis/2021.2/Vitis_examples/common/include/xcl2/
They are never copied to "${workspace_loc:${ProjName}/libs/common/includes/xcl2}"

@StefanThorlacius  When I tried the steps to import locally downloaded repository things are working fine without any issue. Can you check again if something got messed up with your local directory?
Thanks,
Vishnu

@StefanThorlacius  Can you provide the steps you tried to reproduce the issue.
-Vishnu

Closing this issue as no response to last query. Please re-open the issue if facing same problem. Please provide more information as requested.

The following steps was done

Install Xilinx developement enviroment on Computer X with no access to internet via portable SSD disk

Clone repository https://github.com/Xilinx/Vitis_Accel_Examples onto computer B into
~/.Xilinx/vitis/2021.2/vitis_examples/Vitis_Accel_Examples

Copy ~./Xilinx/vitis/2021.2/vitis_examples/Vitis_Accel_Examples to a USB

Copy from USB to Computer X into
~/.Xilinx/vitis/2021.2/vitis_examples/Vitis_Accel_Examples

Start Xilinx on computer X

Create a project

Add the vitis exmapels to the IDE

Use vitis example vadd (hello_world)  as base to create the project

The IDE setups the project

Now
A) In the the "incude path" part of the project you can not see any references to
~/.Xilinx/vitis/2021.2/vitis_examples/Vitis_Accel_Examples/common/include/xcl2
(where the xcl2.hpp is)
If you go into the projects settings you can see that the IDE try to add a path to
'Emulation-SW/${ProjName}/libs/common/includes/xcl2
Which is not resolvable so the reference to xcl2.h can not be found.
B)
The IDE do not copy (I assume it should) xcl2.cpp to the same directory as host.cpp so it wont be able to compile that either.
Note, if I, in a terminal window, change to ~/.Xilinx/vitis/2021.2/vitis_examples/Vitis_Accel_Examples/hello_world
and do
make all TARGET=sw_emu PLATOFRM=xilinx_u50_gen3x16_xdma_201920_3
Everything works fine.


Use a more precise autoload prefix

As phpdocumentor/guides-markdown provides only classes for the Markdown subnamespace, using a more precise autoload prefix for the PSR-4 configuration will allow the ClassLoader to avoid checking that package for other guides classes.
This won't make much difference when using an optimized autoloader with level 2 optimizations as the classmap will be used instead of checking the filesystem. But it will help a bit when using a non-optimized autoloader (which is common in dev environments as that provide a better DX when your codebase gets edited).
If this is considered good by maintainers, I will update the PR to apply that to other packages rather than just guides-markdown as others could also benefit from it.
Also, maintainers should decide whether they prefer using src/Markdown/ as path in the config or flattening the src folder by removing the Markdown folder entirely (similar to what is done for guides-cli). Both options are valid and I'll happily apply the preferred one when updating this PR to cover all packages.

Thanks for reaching out to us, I think it would be nice to have this optimization in the composer.json files of the projects. A PR for those changes would be very nice.
Regarding the folder structure, I think we prefer the flattest structure, we must have missed that when we were splitting the project into separate packages. However changing this could have the downside of a harder to track history. I'm not sure if we should do that? @linawolf  what do you think?

I think if we are moving the files in their own commit without changing them further in that commit git should be able to realize they were moved and not deleted and then created a new

Ok, let's go for it @stof


PCB Changes

When making a new PCB, consider:

[x] Rotating RF socket 90 degrees for better side clearance
[x] Making a large "ground area" for DSO probe ground connection
[x] Adding single test point pads, ground and other signals
[x] Make PCB smaller

With version 1.4 of the PCB, most of this is done, with the exception of test points.

PCB version 1.5 has all the desired features.


enhance carry use path style info along with cold heat separation to support using minio

Proposed changes
Issue Number: close #xxx
Before this pr when using minio as storage resource in cold heat separation along with use_path_style=true, user would encounter with following error:

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

run buildall

(From new machine)TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 45.52 seconds
stream load tsv:          508 seconds loaded<PHONE_NUMBER>9 Bytes, about 140 MB/s
stream load json:         19 seconds loaded<PHONE_NUMBER> Bytes, about 118 MB/s
stream load orc:          65 seconds loaded<PHONE_NUMBER> Bytes, about 16 MB/s
stream load parquet:          32 seconds loaded 861443392 Bytes, about 25 MB/s
insert into select:          29.2 seconds inserted 10000000 Rows, about 342K ops/s
storage size:<PHONE_NUMBER>2 Bytes


Dependency conflict on Ubuntu 18

Steps to reproduce
Attempted install of deb package for ubuntu 17 on Ubuntu 18.04
output of lsb_release -a:
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu Bionic Beaver (development branch)
Release:	18.04
Codename:	bionic

Not sure what I expected, but Powershell seems to rely on libcurl3. Ubuntu 18.04 uses libcurl4, which seems to conflict with libcurl3. This makes it impossible to have Powershell and the bundled version of curl etc installed at the same time.
It would be awesome if a deb package compatible with Ubuntu 18 was released.

I got PS Core 6.0.1 for 17.10 working on Bionic Beaver Beta.

Yes, but by downgrading libcurl you likely broke it for other tools like curl etc.
For some packages one can work around the problem by manually editing the dependencies in the deb:
$ wget https://downloads.slack-edge.com/linux_releases/slack-desktop-3.1.0-amd64.deb
$ dpkg-deb -R slack-desktop-3.0.1-amd64.deb slack
$ vim slack/DEBIAN/control # and replace libcurl3 with libcurl4
$ dpkg-deb -b slack slack.deb
$ sudo dpkg -i slack.deb

By doing the same as above for Powershell, and editing the dependencies its clear that the powershell deb package directly depends on libcurl3 and an incompatible version of libicu.
By changing these two and repackaging the deb, I was able to install the powershell package just fine without downgrading to libcurl3.
I completely realize that more testing is needed, but as long as Powershell directly depends on libcurl and libicu, @iSazonov 's comment seems to be incorrect.

as a work around, couldn't you install the libcurl3 and libicu to something like /opt/powershelllib/ and then launch PowerShell with LD_LIBRARY_PATH=/opt/powershelllib pwsh?

I was able to successfully install on 18.04 by changing the dependencies for https://github.com/PowerShell/PowerShell/releases/download/v6.1.0-preview.2/powershell_6.1.0-preview.2-1.ubuntu.17.04_amd64.deb
dpkg-deb --raw-exatrct powershell_6.1.0-preview.2-1.ubuntu.17.04_amd64.deb 6.1.0_patched

Then alter two patterns, curl and libicu dependencies to current versions;
sudo awk '{gsub("curl3","curl4");gsub("libicu57","libicu60");print}' 6.1.0_pathched/DEBIAN/control

Repackage as a debian package;
dpkg-deb --build 6.1.0_pathched/ powershell_6.1.0-patched.2-1.ubuntu.18.04_amd64.deb

Now just install the newly patched .deb package, I like to use gdebi to install;
sudo gdebi powershell_6.1.0-patched.2-1.ubuntu.18.04_amd64.deb

I haven't estensively tested this, but seems to be functional and stable so far, but maybe a viable fix for 18.04 install.

Same here, not seeing any problems. .Net core doesn't seem to play into it at all.


[GitHub Stars] authentication/token  support

Extension
https://www.raycast.com/mrmartineau/search-github-stars
Description
reference
https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/setting-your-profile-to-private
Who will benefit from this feature?
everyone
Anything else?
No response

@macoswk what exactly do you want to change here? Please can you provide more information


Allow a JSON configuration file for configuring the SpeedmentLifecycle

Useful for different deployment scenarios. This could make all the .with() methods configurable via a file.

This might be related to #30.


DNS Resolver Option no_default_search_domain Not Working

Our Envoy configuration will at times included a moderate number of non-existent DNS names. Since we generate our configuration to always utilize fully qualified DNS names, we want to minimize hits to our DNS servers by avoiding needless us of the OS-level default search domain(s) specified in /etc/resolv.conf. Per the Envoy  We're attempting to use a typed_dns_resolver_config directly in our bootstrap configuration to disable default search domains:
typed_dns_resolver_config:
  name: envoy.network.dns_resolver.cares
  typed_config:
    '@type': type.googleapis.com/envoy.extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig
    resolvers:
    dns_resolver_options:
      no_default_search_domain: true
      use_tcp_for_dns_lookups: false

Per https://www.envoyproxy.io/docs/envoy/v1.26.2/api-v3/config/core/v3/resolver.proto#envoy-v3-api-msg-config-core-v3-dnsresolveroptions (referenced in https://www.envoyproxy.io/docs/envoy/v1.26.2/api-v3/extensions/network/dns_resolver/cares/v3/cares_dns_resolver.proto#envoy-v3-api-msg-extensions-network-dns-resolver-cares-v3-caresdnsresolverconfig), this sounds like it should work, but alas when running this configuration on Envoy 1.26.2 we still see extra DNS queries corresponding to the /etc/resolv.conf search entries.
Here's a minimal self-contained config.yaml that demonstrates the problem:
node:
  cluster: envoy
  id: envoy-worker
typed_dns_resolver_config:
  name: envoy.network.dns_resolver.cares
  typed_config:
    '@type': type.googleapis.com/envoy.extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig
    resolvers:
    dns_resolver_options:
      no_default_search_domain: true
      use_tcp_for_dns_lookups: false
static_resources:
  clusters:
  -   name: test
      type: STRICT_DNS
      dns_lookup_family: V4_ONLY
      load_assignment:
        cluster_name: test
        endpoints:
        - lb_endpoints:
          - endpoint:
              address:
                socket_address:
                  address: fake123.fmr.com
                  port_value: 443
  listeners:
  - name: listener-8443
    address:
      socket_address:
        address: <IP_ADDRESS>
        port_value: 8443
    filter_chains:
    - filters:
      - name: httpfilter
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              '@type': type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
          stat_prefix: http
          route_config:
            name: local-routes
            virtual_hosts:
            - domains:
              - '*'
              name: http
              routes:
              - match:
                 prefix: /
                route:
                 cluster: test

On startup on a host where /etc/resolve.conf includes a "search fmr.com fmr2.com" line, a tcpdump on port 53 shows 3 distinct queries (I've generalized the hostname running Envoy to myhost and the DNS server name to mydns):
11:52:05.434275 IP myhost.fmr.com.37725 > mydns.fmr.com.domain: 21627+ A? fake123.fmr.com. (33)
11:52:05.434666 IP mydns.fmr.com.domain > myhost.fmr.com.37725: 21627 NXDomain* 0/1/0 (104)
11:52:05.434900 IP myhost.fmr.com.37725 > mydns.fmr.com.domain: 64318+ A? fake123.fmr.com.fmr.com. (41)
11:52:05.435139 IP mydns.fmr.com.domain > myhost.fmr.com.37725: 64318 NXDomain* 0/1/0 (119)
11:52:05.435269 IP myhost.fmr.com.37725 > mydns.fmr.com.domain: 34208+ A? fake123.fmr.com.fmr2.com. (42)
11:52:05.435663 IP mydns.fmr.com.domain > myhost.fmr.com.37725: 34208 NXDomain 0/1/0 (136)

What's especially puzzling is that the problem is very specific to the search domain functionality - if I set use_tcp_for_dns_lookups to true I indeed see TCP connections being used for DNS queries.
I tried the same test using the latest Envoy 1.25, 1.24, and 1.23 versions and got the same result. I even tried changing to the older dns_resolution_config syntax to test on Envoy 1.19 and 1.20:
dns_resolution_config:
  resolvers:
    - socket_address:
          address: <IP_ADDRESS>
          port_value: 53
  dns_resolver_options:
    no_default_search_domain: true
    use_tcp_for_dns_lookups: false

I could see DNS queries flow to the <IP_ADDRESS> (obviously not the real IP) DNS server as expected, but again I saw queries for each search domain suffix.
In Envoy itself the no_default_search_domain flag looks like it should cause Envoy to pass ARES_FLAG_NOSEARCH to c-ares (which Envoy logs are confirming is the DNS resolver we're running) - https://github.com/envoyproxy/envoy/blob/v1.26.2/source/extensions/network/dns_resolver/cares/dns_impl.cc#L86. There's even a test to confirm that this occurs - https://github.com/envoyproxy/envoy/blob/v1.26.2/test/extensions/network/dns_resolver/cares/dns_impl_test.cc#L1930.
I've reproduced this on an Ubuntu 20.04 VM directly on the VM - at first we hit the issue when running in a container, but removing Docker/containerd from the flow made no difference in the behavior.
Am I missing something obvious here - or is this either an Envoy or c-ares bug?

cc @yanavlasov as cares code owner


A playground UI intended for the standalone controller

A UI providing playground functionality for authoring functions and running them in the browser.

Description

Related issue and scope

[ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[x] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[x] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[x] I signed an Apache CLA.
[x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[ ] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #4686 into master will decrease coverage by 5.91%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4686      +/-   ##
==========================================
- Coverage   84.49%   78.57%   -5.92%
==========================================
  Files         193      193
  Lines        8711     8711
  Branches      598      598
==========================================
- Hits         7360     6845     -515
- Misses       1351     1866     +515

Impacted Files
Coverage Δ

...core/database/cosmosdb/RxObservableImplicits.scala
0% <0%> (-100%)
:arrow_down:

...ore/database/cosmosdb/cache/CacheInvalidator.scala
0% <0%> (-100%)
:arrow_down:

...core/database/cosmosdb/CosmosDBArtifactStore.scala
0% <0%> (-95.79%)
:arrow_down:

...tabase/cosmosdb/cache/CacheInvalidatorConfig.scala
0% <0%> (-94.74%)
:arrow_down:

...sk/core/database/cosmosdb/CosmosDBViewMapper.scala
0% <0%> (-92.6%)
:arrow_down:

...e/database/cosmosdb/cache/ChangeFeedListener.scala
0% <0%> (-86.67%)
:arrow_down:

...e/database/cosmosdb/cache/KafkaEventProducer.scala
0% <0%> (-76.48%)
:arrow_down:

...whisk/core/database/cosmosdb/CosmosDBSupport.scala
0% <0%> (-74.08%)
:arrow_down:

...a/org/apache/openwhisk/common/ExecutorCloser.scala
0% <0%> (-66.67%)
:arrow_down:

...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala
7.69% <0%> (-50%)
:arrow_down:

... and 9 more

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 ad4e9ca...c5ccc02. Read the comment docs.

Thanks @chetanmeh for adding the --pg option. I just tried it. ❤

Below is how the ui looks like

Changed the behaviour to launch Playground UI by default (can be disabled with --no-pg flag). Also updated the readme with screenshot see https://github.com/nimbella-corp/openwhisk/tree/playground/core/standalone
PR is now ready for review

One small thing is, I noticed that it pulls nightly runtime images while invoking an action if I did not configure any runtime.json.
How about pulling them at the bootup time?

Yes this aspect needs to be improved. I was thinking to explicitly pull at least the nodejs image before auto  launching the ui in browser so that by the time UI loads its immediately functional

@style95 I have now updated the logic to explicitly prepull the nodejs default image before launching the browser. So after running $ docker image rm openwhisk/action-nodejs-v10:nightly the browser now gets launched only after the pre pull completes and user can start using it.
Please try again

@chetanmeh Thank you for the update.
The reason why all runtime images are not being pulled is to speed up the bootup?

Good call on using /ui. We already have this route reserved in the bundled nginx conf. Eventually could serve the playground there as well.

Good call on using /ui.

Change to ui was only done for cli options. The url is still referring to /playground. Should we change that also?

url I see is /playground/ui/index.html
RE pulling images - when I launched standalone, the ui shows before pulling is done and I get several Rescheduling Run message, too many message in the pool errors when I run (and run via ui doesn't complete). I'm not sure if it is possible to not launch the ui till after the pull completes, but that may be better first time experience for button mashers. At some point it might be cool to have some status endpoint that indicates the first time setup progress (pulling images, creating prewarms, coordinate prewarm config with ui to indicate which types may be slow, etc), this would allow ui to launch, but in a appropriately disabled state till setup is complete. I wouldn't hold up this PR for any of this.
Great stuff! Thanks @rabbah  and @chetanmeh !

when I launched standalone, the ui shows before pulling is done

@tysonnorris did you tried by building the latest from this PR branch or via the pre built jar from fork? As few days ago I added logic to delay launching the UI till at least nodejs image pull is complete. The jars in my fork are bit old, would update them

@chetanmeh yes I checked out master and merged from PR branch;
git checkout -b nimbella-corp-playground master
git pull https://github.com/nimbella-corp/openwhisk.git playground

here are the logs indicating run failures before pulling completed - I don't see the logs indicating prepull happened though [2019-10-23T13:34:29.255Z] [INFO] [#tid_13AlNDg3NYiYfuK55mcIiNZEFis5j7NM] [MemoryArtifactStore]  [marker:database_getDocument_finish:30048:0] [2019-10-23T13:34:29.275Z] [ERROR] [#tid_13AlNDg3NYiYfuK55mcIiNZEFis5j7NM] [ContainerPool] Rescheduling Run message, too many message in the pool, freePoolSize: 0 containers and 0 MB, busyPoolSize: 4 containers and 1024 MB, maxContainersMemory 1024 MB, userNamespace: whisk.system, action<EMAIL_ADDRESS>needed memory: 256 MB, waiting messages: 2 [2019-10-23T13:34:33.366Z] [INFO] [#tid_2fcLKUlymbxpvX7S8koH9mAoYQDuY23A] [MemoryArtifactStore] [GET] 'activations' finding document: 'id: whisk.system/0d634632513f4c07a34632513fcc07ae' [marker:database_getDocument_start:15039] [2019-10-23T13:34:33.366Z] [INFO] [#tid_2fcLKUlymbxpvX7S8koH9mAoYQDuY23A] [MemoryArtifactStore]  [marker:database_getDocument_finish:15039:0] [2019-10-23T13:34:33.755Z] [INFO] [#tid_7ufom2S4DcjJ7OAuMlVnPKHRIggPCM2h] [MemoryArtifactStore] [GET] 'activations' finding document: 'id: whisk.system/4b29fddbe8704422a9fddbe870d42232' [marker:database_getDocument_start:45066] [2019-10-23T13:34:33.755Z] [INFO] [#tid_7ufom2S4DcjJ7OAuMlVnPKHRIggPCM2h] [MemoryArtifactStore]  [marker:database_getDocument_finish:45066:0] [2019-10-23T13:34:35.446Z] [INFO] [#tid_2bn0VghttmXsPv9xIxpWDmfEjcbkKhQ9] [WebActionsApi]  [marker:controller_blockingActivation_finish:60188:60059] [2019-10-23T13:34:35.451Z] [INFO] [#tid_2bn0VghttmXsPv9xIxpWDmfEjcbkKhQ9] [BasicHttpService] [marker:http_post.202_counter:60192:60192] [2019-10-23T13:34:37.509Z] [INFO] [#tid_sid_invokerWarmup] [DockerForMacClient]  [marker:invoker_docker.pull_finish:69379:66218] [2019-10-23T13:34:37.509Z] [INFO] [#tid_sid_invokerWarmup] [DockerForMacClient]  [marker:invoker_docker.pull_finish:69380:66219] [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly [2019-10-23T13:34:37.510Z] [INFO] [#tid_sid_unknown] [StandaloneDockerContainerFactory] Pulled OpenWhisk provided image openwhisk/action-nodejs-v10:nightly

JFYI, I could run UI after pulling the image is done.

@tysonnorris I have improved the logic to now explicitly pull nightly tagged images.
So far the logic was explicitly checking via docker images command to check if image exist locally. This works fine for normal tagged images which in general do not get updated. However as nightly image do get updated this logic did not worked properly. Now for nightly even if the image is present locally it would be explicitly pulled.
Please try again with latest PR branch state

I will merge this once travis passes.


STRING_SPLIT almost useful

Thanks for adding this.
It's deficient somewhat, though.

It's not deterministic, parsing text (eg code) needs the individual lines to be reported in the original order
Having the separator limited to *char(1) means Windows text has leading or trailing extraneous whitespace

Any chance of some enhancements?
One further question, do you believe that there are any use-cases where database order is useful?

@misterstick -- thank you for your feedback.  Please add it here:

SQL Server Feedback

Regarding your question, please see here:

DBA Stack Exchange
Stack Overflow


Convert Inventory UI to dynamically generate 10 items like the DEBUG inventory does

@ClarkStraws is this done? I'm not sure what this task is asking for


Upgrade grafana-plugin-sdk-go

This PR upgrades the grafana-plugin-sdk-go to the latest version. This version had a breaking change in how the proxy client is called, so that has been updated. Additionally, there is now a new function in the sdk that can be used to parse the proxy options

Thanks for the quick review, @adamyeats ! I don't have permission to merge this PR, would you mind merging it for me?

Thank you so much!


Bluetooth seems to not work randomly on target device

Describe the bug
Testing with a bl653_dvk board (nrf52833) using the smp_svr sample application (zephyr/samples/subsys/mgmt/mcumgr/smp_svr) and seeing very strange behaviour whereby, for reasons unknown, the target board is advertising and accepts a connection from a target device but then seems to not respond to it and the connection is dropped very shortly thereafter. I've tested this on the in-built bluetooth of a laptop (intel controller) and an iOS mobile device and I see the same result on both. I was seeing this issue last week, and it seemed to just vanish (I was flipping between main and v2.7-branch for smp_svr samples, not sure if that has any impact on it), I do not know what caused the issue to stop last week nor why it's just started to reappear again now.
Note: this board is using the internal RC for the low frequency clock, not an external 32KHz crystal
To Reproduce
It seems to be very random, but build zephyr/samples/subsys/mgmt/mcumgr/smp_svr with the overlay-bt.conf file and flash it, it might work or it might have the issue.


Cranelift interpreter: handle overflows during division

The Cranelift interpreter appears not to properly handle an overflow (from e.g. INT_MIN / -1), resulting in a panic rather than  an explicit error type returned to the caller. Found via fuzzing.
In the implementation here, it appears that we need to check for this case specifically.

cc @abrown

also cc: @afonso360


New version: TextSearch v0.2.16

Registering package: TextSearch
Repository: https://github.com/sadit/TextSearch.jl
Created by: @sadit
Version: v0.2.16
Commit: 72d129b08e45a0269f9f519be23afe47058c9729
Reviewed by: @sadit
Reference: https://github.com/sadit/TextSearch.jl/commit/72d129b08e45a0269f9f519be23afe47058c9729#commitcomment-35593003

Your new version pull request does not meet all of the guidelines for automatic merging.
Specifically, your pull request does not meet the following guidelines:

The following dependencies do not have a compat entry that has an upper bound: Revise

It is important to note that if your pull request does not meet the guidelines for automatic merging, this does not mean that your pull request will never be merged. It just means that your pull request will require manual review by a human.

These guidelines are intended not as requirements for packages but as very conservative guidelines, which, if your new package or new version of a package meets them, it may be automatically merged.

On a separate note, I see that you are registering a release with a version number of the form v0.X.Y.
Does your package have a stable public API? If so, then it's time for you to register version v1.0.0 of your package. (This is not a requirement. It's just a recommendation.)
If your package does not yet have a stable public API, then of course you are not yet ready to release version v1.0.0.

[noblock]

I don't think you meant to include Revise as a dependency.

I don't think you meant to include Revise as a dependency.
[noblock]

Oh, of course, my mistake. Thanks for the advice

Bump @sadit, did you mean to fix https://github.com/JuliaRegistries/General/pull/4578#issuecomment-547020946 ?
[noblock]

I added Revise for running some tasks (working on the repo) but the package does not need it. I just removed it.

@sadit Can you also retrigger Registrator in order to update this PR then?

The following dependencies do not have a compat entry that has an upper bound: Revise

I thought you wanted to get rid of Revise?

Done, @fredrikekre I triggered the Registrator. I hope that was what you mean; I am not familiar with the management of the package system beyond simple operations.

Sorry if I was unclear; you have to retrigger on a new commit where you have removed Revise. I see that you already have released https://github.com/JuliaRegistries/General/pull/5049 so maybe this PR is not relevant anymore?

Sorry if I was unclear; you have to retrigger on a new commit where you have removed Revise. I see that you already have released #5049 so maybe this PR is not relevant anymore?

Yes, this PR is not relevant anymore, and yes, I got confused about how to update the pull request :(. I need to learn how to do it.


Interface and type being treated differently in overload resolution

TypeScript Version:  2.5.2
Code
type Map<T> = {[key: string]: T};

type Callback<T> = (key: string, value: T) => void;

declare function foo<T>(obj: Map<T>, callback: Callback<T>): void;
declare function foo<C,T>(obj: {[P in keyof C]: T}, callback: Callback<T>): void;

interface SomeInterface {
    a: number;
    b: number;
}

type SomeType = {
    a: number;
    b: number;
}

let x: SomeInterface = {
    a: 42,
    b: 60
};

let y: SomeType = x;

foo(x, (key, value) => console.log(key, value));
foo(y, (key, value) => console.log(key, value));

Expected behavior:
Both calls to foo should use the first overload (and deduce T as number).
Actual behavior:
The first call to foo uses the second overload and both C and T are deduced as {} (i.e foo<{}, {}>). If the second overload is removed, the program fails to compile:
TS2345: Argument of type 'SomeInterface' is not assignable to parameter of type 'Map<{}>'.
  Index signature is missing in type 'SomeInterface'.

(and other 2 errors since key and value would implicitly become any)
This might be some intended difference between interface and type that I didn't see documented anywhere, but I'm posting this here just to be sure.

duplicate of https://github.com/Microsoft/TypeScript/issues/15300

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


Update index.md

Updated first and last name + title

you are in charge of approving your own pull requests if you use them

Thank you!
On Mon, Jun 21, 2021, 7:13 PM Gregor von Laszewski @.***>
wrote:

you are in charge of approving your own pull requests if you use them
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cybertraining-dsc/su21-reu-372/pull/1#issuecomment-865404092,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUM3DB77MJTRJAUYCKWHJYTTT7BQFANCNFSM47CKHDDA
.


Can select date returns true always

From this user.
https://github.com/patchthecode/JTAppleCalendar/issues/16

That being said, I found that result of delegate's calendar(_:, canSelectDate:, cell:, cellState:) method is not used, since the place where it's called (in collectionView(collectionView:, shouldSelectItemAtIndexPath indexPath:), I recall) always returns true instead of using the result. I could create a pull request if you want to, but I afraid my fork deviates too far away from the original 😬 and it wouldn't take much to fix that bug, IMO 😄

Fixed and pushed to master


Union intersect

graphblas.union and graphblas.intersect for vector and matrix
These are the same as GraphBLAS's ewiseAdd and ewistMult, but better named
NOTE: I added a change to empty_like to automatically resize pointers to be the same size as the input, but filled with zeros. This makes it a lot more convenient to use, as empty_like preserves the rank and usually the shape, so having pointers properly sizes for the shape is helpful.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

130 of 133 (97.74%)  changed or added relevant lines in 5 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+1.0%) to 80.697%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

mlir_graphblas/ops.py
33
36
91.67%

Files with Coverage Reduction
New Missed Lines
%

mlir_graphblas/engine.py
1
74.9%

mlir_graphblas/tests/test_profile.py
4
51.95%

Totals

Change from base Build<PHONE_NUMBER>:
1.0%

Covered Lines:
2178

Relevant Lines:
2699

💛  - Coveralls


Exclude /tests/ from generate_sdk_index.sh

We moved the tests in to a folder, let's not export the helper scripts

good catch thank you


JupyterBook

This branch recovered from a corrupted branch. . .  See PR #118

@amsnyder
This is the material that I think is specific to the TOC and jupyterbook stuff.  The original branch has been renamed to DEPRECATED-gt-118-JupterBook-TOC in case there are pieces that I missed... we can pick them up from that branch manually.
In the mean while... you can commit any README or other book-relevant docs to this branch and PR.

Will close #50


Can’t reach an XML value

Hi there! I can’t find the right data structure to decode the following XML string:
<something name="Some name">Some value</something>

I ran out of ideas. May anyone give me a hint?
Thanks!

This is now supported in master with #73 merged. As usual please feel free to reopen this issue if you think there's anything missing.

Trying to use master with the following and still getting an error
<preview_image_time format="24/999 1000/nonDrop">00:00:17:01</preview_image_time>

struct PreviewImageTime: Codable, DynamicNodeEncoding {
var format: String
var value: String
enum CodingKeys: String, CodingKey {
case format
case value = ""
}
static func nodeEncoding(forKey key: CodingKey) -> XMLEncoder.NodeEncoding {
switch key {
case CodingKeys.format:
return .attribute
default:
return .element
}
}
}
could not parse
typeMismatch(Swift.Dictionary<Swift.String, Any>, Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "software", intValue: nil), CodingKeys(stringValue: "software_metadata", intValue: nil), CodingKeys(stringValue: "versions", intValue: nil), CodingKeys(stringValue: "version", intValue: nil), XMLKey(stringValue: "0", intValue: 0), CodingKeys(stringValue: "locales", intValue: nil), CodingKeys(stringValue: "locale", intValue: nil), XMLKey(stringValue: "0", intValue: 0), CodingKeys(stringValue: "app_previews", intValue: nil), CodingKeys(stringValue: "app_preview", intValue: nil), XMLKey(stringValue: "0", intValue: 0), CodingKeys(stringValue: "preview_image_time", intValue: nil)], debugDescription: "Expected to decode Dictionary<String, Any> but found SharedBox instead.", underlyingError: nil))

@thecb4 What happens if you change your string values to something without colons or backslashes.
I think I ran into something similar with UUID strings that had colons. I believe the decoder is attempting to decode a dictionary before a string, based on the ability to convert "k : v " strings to dictionaries.
If that's a case, a workaround may be to provide your own decoder that specifies the type to try.
I would just try a simple test case first with simple strings to see if that is indeed the issue. I have some example code that might help if that is it.

Now I understand the error message! Perfect.

hm, I don't think the attempt to decode that string as a dictionary is something anyone expects to be a default behavior. @thecb4 I hope you don't mind if I add that XML snippet to XMLCoder test suite

Thank you. I have been trying to figure out the appropriate work around. I tried a custom init and was still getting the same error.
struct PreviewImageTime: Codable {

  var format: String
  var value: String

  public init(from decoder: Decoder) throws {

      var values = try decoder.container(keyedBy: CodingKeys.self)

      var unkeyedValues = try values.nestedUnkeyedContainer(forKey: .value) as UnkeyedDecodingContainer

      format = try values.decode(String.self, forKey: .format)
      value = try unkeyedValues.decode(String.self, forKey: .value)

  }

  enum CodingKeys: String, CodingKey {
    case format
    case value = ""
  }

  static func nodeEncoding(forKey key: CodingKey) -> XMLEncoder.NodeEncoding {
    print("node encoding")
    switch key {
      case CodingKeys.format:
        return .attribute
      default:
        return .element
    }
  }
}

FYI - When I create a standalone XML element, it works. When it's embedded in another element. it fails.
// This passes
  let previewTime =
  """
  <?xml version="1.0" encoding="UTF-8"?>
  <preview_image_time format="24/999 1000/nonDrop">00:00:17:01</preview_image_time>
  """.data(using: .utf8)!

  let decoder = XMLDecoder()
  decoder.errorContextLength = 10

  let metadata1 = try decoder.decode(PreviewImageTime.self, from: previewTime)
  print(metadata1)

// this does not pass
  let preview =
  """
  <?xml version="1.0" encoding="UTF-8"?>
  <app_preview display_target="iOS-6.5-in" position="1">
    <preview_image_time format="24/999 1000/nonDrop">00:00:17:01</preview_image_time>
  </app_preview>
  """.data(using: .utf8)!

  let metadata2 = try decoder.decode(AppPreview.self, from: preview)
  print(metadata2)

structs
struct AppPreview: Codable {
  var displayTarget: String
  var position: Int
  var previewImageTime: PreviewImageTime
  // var dataFile: DataFile

  enum CodingKeys: String, CodingKey {
    case displayTarget = "display_target"
    case position
    case previewImageTime = "preview_image_time"
    // case dataFile = "data_file"
  }
}

struct PreviewImageTime: Codable, DynamicNodeEncoding {

  var format: String
  var value: String

  enum CodingKeys: String, CodingKey {
    case format
    case value
  }

  static func nodeEncoding(forKey key: CodingKey) -> XMLEncoder.NodeEncoding {
    print("node encoding")
    switch key {
      case CodingKeys.format:
        return .attribute
      default:
        return .element
    }
  }
}

Thank you @thecb4, that's very helpful! Clearly looks like a bug to me, looking into it right now.


ITKv5_CONST macro for VerifyPreconditions and VerifyInputInformation

ITKv5_CONST was introduced on 2018-11-12 by commit
5141d32e39a277318ca0efbbec2e3f68980d3193.
We now define the same macro in ITK 4.13,
so the user applications can build easily
against either version 4 or 5 of the toolkit.

In #174, the patch was based on release branch instead of release-4.13.

Should we ignore the CI compile warnings and test failures? This patch does not really touch them.

Should we ignore the CI compile warnings and test failures? This patch does not really touch them.

Could you please create issues for each one and start addressing them incrementally? Most should be just backporting (cherry-picking) patches from master.

This was merged to release and master branches subsequently.


add error-404 page

Added a custom error-404 page that is responsive

but footer ( which is not responsive ) is causing a problem in making it completely responsive.

hey @him-raw99 plz mention assigned issue for labelling

sure @Mansi168 it was issue : #124


1.2.6

Remove languageLevel

@chymz : may I ask you to create new npm package and publish the lib folder: npm publish lib.
If you publish only with npm publish the compiled files are saved into libs and cannot be used. Thanks.

@kzimny
Actually if I do a npm publish lib NPM understand that I want to publish a package named lib
If i do npm publish ./lib NPM shows an error that there is no package.json in this folder.
I think a build step is missing, I'll try to investigate...

@kzimny sorry, my mistake, everythin works as expected, 1.2.6 is now plublished

Thanks! It works now.


Implement footer with more details

Description
Implement a footer component with more details. So that user can get more information about our organization.
Changes proposed in the pull request

Implement footer ui
Implement story for footer component

Screenshots

Types of changes

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests have passed and it does not give any unexpected error for the same.

Steps to test

npm i
npm run storybook (story will be displayed in Home/DetailedFooter )

Resolves https://github.com/scorelab/Webiu/issues/233

@charithccmc @dinithminura can you review this PR please?


Parquet Writer: Make column descriptor public on the writer

Which issue does this PR close?
There's no issue currently, because I just had this issue this morning and decided to make a PR for it. I can open up an issue if it helps.

Rationale for this change
This is so that it's possible to gather information from the column we're about to write to. That information was already present in the column but buried inside the internal of the Writer.
Because the ColumnDescPtr is an Arc, it is not expensive to clone the arc and make it publicly available to the column writer.
while let Ok(Some(mut col)) = writer.next_column() {
    let descriptor = col.descriptor();
    let name = descriptor.name();
}

Without this patch, it's required to implement a sort of book keeping by the caller to make sure the data we're about to write to matches the column we have.
With the patch, it removes the need to guess which column the code refers to.

What changes are included in this PR?
The PR is missing tests, I wasn't sure if the test would add any value/safety. I'm more than happy to provide some tests if you think it's important.

Are there any user-facing changes?
None, I believe.

@tustvold Maybe it's possible to do what I'm trying to do using a different API, but currently, what I'm working on is a way for me to aggregate events that comes in from a different thread, and package data into a parquet file using the SerializedColumnWriter.
What this means, is that I have an in-memory cache that I'm holding, and then constructing the parquet file (row group) when it reaches a certain size.
Since the ColumnDescriptor is not really available, as far as I can tell, I have to basically create an index myself to figure out which column I am referring to when I call writer.next_column().
If I had the possibility to gather some kind of information from the columnWriter, it would help understand the context I'm in and avoid some bookkeeping on my side.
Does that make sense?
I apologize for the breaking change, I guess I misinterpreted what "User-facing changes" meant.

Now that I'm looking at the problem again this morning, I believe that moving the getter from SerializedColumnWriter to GenericColumnWriter would solve my problem.
The struct already has that field and so just adding a getter to return a reference to it would work. I believe this would not introduce a breaking change?

If I had the possibility to gather some kind of information from the columnWriter, it would help understand the context I'm in and avoid some bookkeeping on my side.

Makes sense :+1:

I believe this would remove the breaking change of the API and solve my problem, would that be an acceptable solution?

Sounds good to me


Crashes if no Genre selected

URL(s)

https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/forms/Create_book_form
Request type

[x] Correction or update

Details

If you do not select a Genre check box, the code crashes.  I find it quite hard to determine where the problem actually occurs, but it is some where in the sanitizeBody('*').escape() code.  If I comment this line out, then there are no errors and the book is added.
This is the error that is shown:
ValidationError: Book validation failed: genre: Cast to [ObjectId] failed for value "[""]" at path "genre"
at model.Document.invalidate (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\document.js:2574:32)
at model.$set (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\document.js:1246:12)
at model._handleIndex (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\document.js:979:14)
at model.$set (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\document.js:920:22)
at model.Document (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\document.js:139:12)
at model.Model (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\model.js:107:12)
at new model (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\mongoose\lib\model.js:4710:15)
at exports.book_create_post (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\controllers\bookController.js:121:20)
at Layer.handle [as handle_request] (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\express\lib\router\layer.js:95:5)
at next (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\express\lib\router\route.js:137:13)
at middleware (c:\Users\Sam\Documents\Sam_tech\VSCode\express-locallibrary-tutorial\node_modules\express-validator\src\middlewares\sanitize.js:22:13)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
Running this in VSCODE. Version: 1.47.0 (user setup)
Commit: d5e9aa0227e057a60c82568bf31c04730dc15dcd
Date: 2020-07-09T08:02:06.629Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18362
I'm testing using Firefox, not Chrome

Another one for @hamishwillee.

Hi @SJLennon
I can't reproduce this. On Ubuntu 20.04 I installed node12, cloned https://github.com/mdn/express-locallibrary-tutorial, installed the default dependencies and ran this. Created 2 books with genres and 5 without - 3 on firefox and 2 on chrome.
Did you use your own "new" database?
This uses a default database I set up a while ago "by default". This is now filled with people's test books etc. In the past there have been issues where people have modified the code and uploaded incompatible artifacts to the database. It is possible that your book accessed one of these somehow?

I definitely used my own new, shiny database.  I'm running on Win 10 and was using VSCODE for development, if that makes any difference.
It's been a while since I looked at this and I'd moved past the problem, but I'll see if I can reproduce the error over the weekend.

From: Hamish Willee<EMAIL_ADDRESS>Sent: Friday, October 2, 2020 3:31 AM
To: mdn/sprints<EMAIL_ADDRESS>Cc: SJLennon<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [mdn/sprints] Crashes if no Genre selected (#3489)
Hi @SJLennonhttps://github.com/SJLennon
I can't reproduce this. On Ubuntu 20.04 I installed node12, cloned https://github.com/mdn/express-locallibrary-tutorial, installed the default dependencies and ran this. Created 2 books with genres and 5 without - 3 on firefox and 2 on chrome.
Did you use your own "new" database?
This uses a default database I set up a while ago "by default". This is now filled with people's test books etc. In the past there have been issues where people have modified the code and uploaded incompatible artifacts to the database. It is possible that your book accessed one of these somehow?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/mdn/sprints/issues/3489#issuecomment-702574737, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQC3TE2IMNZ4MPSJGXOZZ6LSIV6UTANCNFSM4OZ23AIA.

Thanks very much @SJLennon - it may also be that the issue was fixed by PR in the interim.

I've gone back in to my project and it is still crashing.
First step in the tutorial is to add this code:
const { body,validationResult } = require('express-validator/check');
const { sanitizeBody } = require('express-validator/filter');

That give these messages in the debug console:
express-validator: requires to express-validator/check are deprecated.You should just use require("express-validator") instead.
express-validator: requires to express-validator/filter are deprecated.You should just use require("express-validator") instead.
So I changed the code:
const { body, validationResult } = require('express-validator');
const { sanitizeBody } = require('express-validator');

Debug console messages is now:
express-validator: sanitize(), sanitizeBody() and other sanitization-only middlewares have been deprecated.
Please use check(), body() and others instead, which must offer the same API, and more.
And it still crashes.
I'm a little confused by the code, in that body and sanitizeBody seem to be the same thing.  I suppose this might just be for clarity, but I'm not sure where check() and body() should be used.
What else can I do to assist?
Also in the debug console is this deprecation warning which should perhaps also be fixed:
(node:12704) DeprecationWarning: current Server Discovery and Monitoring engine is deprecated, and will be removed in a future version. To use the new Server Discover and Monitoring engine, pass option { useUnifiedTopology: true } to the MongoClient constructor.

@SJLennon the last point "Also in the debug console is this deprecation warning which should perhaps also be fixed:" - I fixed that on Monday.

@SJLennon OK, so this repo fixes its dependencies in the package.json file. If you use the latest you get the deprecation warning and crash. The fix is to either revert to package.json or in your code you can make the same updates as I have here: https://github.com/mdn/express-locallibrary-tutorial/pull/100
Essentially this removes the use of sanitzeBody - not only deprecated, but causes this crash.

I'm a little confused by the code, in that body and sanitizeBody seem to be the same thing. I suppose this might just be for clarity, but I'm not sure where check() and body() should be used.

that is answered by the PR linked above. Basically sanitizeBody is sanitisation middleware. The latest version deprecates this and the same functionality is in the body or check (validation) middleware. We don't use check in this code. We do use body. So all I had to do was add the santiization commands to the end of those changes - e.g. .escape().
This works :-). I still have to update the docs, which I will  do this afternoon.
Thanks very much for posting and for your help.


Update meta.yaml

this is necessary after we use qtpy abstraction layer, see https://github.com/TomographicImaging/eqt/pull/146

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

ℹ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

For the host section of the recipe, you should usually use python {{ python_min }} for the python entry.
For the run section of the recipe, you should usually use python >={{ python_min }} for the python entry.
For the test.requires section of the recipe, you should usually use python {{ python_min }} for the python entry.
If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

ℹ PyPI default URL is now pypi.org, and not pypi.io. You may want to update the default source url.

This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12280664799. Examine the logs at this URL for more detail.


Should probably update the module summary

When I installed this module, it was not working at all for me. Even after clearing the app data and restarting the phone, it still didn't work. I read some of the tickets here on github, and some solutions said to try the experimental version. Now, I usually try to avoid nightly builds, so it never crossed my mind. The stable wasn't working so I said what the hell, why not. And it works! So I guess that version isn't compatible with some versions of android? Anyways, I thought I would recommend updating the module description to say if the stable doesn't work, try the experimental.

@th3an7 You think it is time to push the experimental as stable? Doesn't seem anyone is having issues with it other than that legacy API issue we had at the start of pushing the experimental that got patched right away.

Well... It was already set as beta...
Anyway - I've set to stable as you wanted me to do so :)
On Tue, Jan 10, 2017 at 9:27 PM Valter Jansons<EMAIL_ADDRESS>wrote:

@th3an7 https://github.com/th3an7 You think it is time to push the
experimental as stable? Doesn't seem anyone is having issues with it
other than that legacy API issue we had at the start of pushing the
experimental that got patched right away.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pylerSM/YouTubeBackgroundPlayback/issues/292#issuecomment-271688409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMxxbIfG0lu6Tnglhyws-UrGHvEN8IhZks5rQ-mygaJpZM4LereJ
.

Thanks!


[BUG] Failed to pull image "gcr.io/spark-operator/spark:v3.1.1"

Description
Unable to create a spark-application

[ ] ✋ I have searched the open/closed issues and my issue is not listed.

Steps to reproduce the behavior:

Set up a new kubenetes cluster. I set up one in gcloud.
Get kubenetes cluster config
Install spark-operator by helm
create spark-pi.yaml by using (https://github.com/kubeflow/spark-operator/blob/master/examples/spark-pi.yaml)
Apply the file

Actual behavior
Pod in status Failed because of ImagePullBackOff
Terminal Output Screenshot(s)
Events:
Type     Reason       Age                From               Message

Normal   Scheduled    12s                default-scheduler  Successfully assigned default/spark-pi-driver to kind-control-plane
Warning  FailedMount  10s (x3 over 11s)  kubelet            MountVolume.SetUp failed for volume "spark-conf-volume-driver" : configmap "spark-drv-cfc48c8f3d591c55-conf-map" not found
Normal   Pulling      4s                 kubelet            Pulling image "gcr.io/spark-operator/spark:v3.1.1"
Warning  Failed       1s                 kubelet            Failed to pull image "gcr.io/spark-operator/spark:v3.1.1": rpc error: code = NotFound desc = failed to pull and unpack image "gcr.io/spark-operator/spark:v3.1.1": failed to resolve reference "gcr.io/spark-operator/spark:v3.1.1": gcr.io/spark-operator/spark:v3.1.1: not found
Warning  Failed       1s                 kubelet            Error: ErrImagePull
Normal   BackOff      1s                 kubelet            Back-off pulling image "gcr.io/spark-operator/spark:v3.1.1"
Warning  Failed       1s                 kubelet            Error: ImagePullBackOff
Environment & Versions

Spark Operator App version: 1.4.5
Helm Chart Version: v3.14.4
Kubernetes Version: v1.27.3
Apache Spark version: 3.5.0

I have the same issue, what image should we use?

Good morning,
As of #2010, the examples have been updated to reference the official spark image available on dockerhub: spark:3.5.0.  Unfortunately, the legacy images are no longer available.  Fortunately, the official spark images are fully compatible with this operator.

Thank you for the  information, but also in spar-pi-prometheus we have the same problem, this image: gcr.io/spark-operator/spark:v3.1.0-gcs-prometheus does not work. could you please help us!

@sidi-elwely #2010 didn't update the prometheus-enabled image, which currently is not published by any of the CI jobs.  I'll defer to a maintainer as to whether this is something worth re-enabling, but I think it's likely to need some rework regardless.  Right now the image is tied specifically to GCP, which I'm comfortable saying isn't optimal.  The meat of the image WRT prometheus is a single jar and a couple of conf files-- perhaps not worth maintaining as a separate image, but I can imagine a few ways to ease usage.

See https://github.com/kubeflow/spark-operator/tree/master/spark-docker if you're interested in creating your own prometheus-enabled image in the mean time.

After updating the base image to spark 3.5.0 and the spark-operator till the last version i have this error and my apps won't start, also the application version was updated from 3.2.0 to 3.5.0
Files local:///opt/spark-jars/spark-3-rules.yaml from /opt/spark-jars/spark-3-rules.yaml to /opt/spark-jars/spark-3-rules.yaml
2024-07-18 12:44:07.005 WARN  [main            ] org.apache.spark.network.util.JavaUtils:112  - Attempt to delete using native Unix OS command failed for path = /opt/spark-jars/spark-3-rules.yaml. Falling back to Java IO way
java.io.IOException: Failed to delete: /opt/spark-jars/spark-3-rules.yaml
at org.apache.spark.network.util.JavaUtils.deleteRecursivelyUsingUnixNative(JavaUtils.java:173) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.network.util.JavaUtils.deleteRecursively(JavaUtils.java:109) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.network.util.JavaUtils.deleteRecursively(JavaUtils.java:90) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.util.SparkFileUtils.deleteRecursively(SparkFileUtils.scala:121) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.util.SparkFileUtils.deleteRecursively$(SparkFileUtils.scala:120) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.util.Utils$.deleteRecursively(Utils.scala:1126) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.$anonfun$prepareSubmitEnvironment$14(SparkSubmit.scala:437) ~[DataAnalyticsReporting.jar:?]
at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286) ~[DataAnalyticsReporting.jar:?]
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62) ~[DataAnalyticsReporting.jar:?]
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55) ~[DataAnalyticsReporting.jar:?]
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49) ~[DataAnalyticsReporting.jar:?]
at scala.collection.TraversableLike.map(TraversableLike.scala:286) ~[DataAnalyticsReporting.jar:?]
at scala.collection.TraversableLike.map$(TraversableLike.scala:279) ~[DataAnalyticsReporting.jar:?]
at scala.collection.AbstractTraversable.map(Traversable.scala:108) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.downloadResourcesToCurrentDirectory$1(SparkSubmit.scala:429) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.$anonfun$prepareSubmitEnvironment$16(SparkSubmit.scala:450) ~[DataAnalyticsReporting.jar:?]
at scala.Option.map(Option.scala:230) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.prepareSubmitEnvironment(SparkSubmit.scala:450) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:964) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:194) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:217) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:91) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:1120) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:1129) ~[DataAnalyticsReporting.jar:?]
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala) ~[DataAnalyticsReporting.jar:?]
Exception in thread "main" java.io.IOException: Failed to delete: /opt/spark-jars/spark-3-rules.yaml
at org.apache.spark.network.util.JavaUtils.deleteRecursivelyUsingJavaIO(JavaUtils.java:146)
at org.apache.spark.network.util.JavaUtils.deleteRecursively(JavaUtils.java:117)
at org.apache.spark.network.util.JavaUtils.deleteRecursively(JavaUtils.java:90)
at org.apache.spark.util.SparkFileUtils.deleteRecursively(SparkFileUtils.scala:121)
at org.apache.spark.util.SparkFileUtils.deleteRecursively$(SparkFileUtils.scala:120)
at org.apache.spark.util.Utils$.deleteRecursively(Utils.scala:1126)
at org.apache.spark.deploy.SparkSubmit.$anonfun$prepareSubmitEnvironment$14(SparkSubmit.scala:437)
at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286)
at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:62)
at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:55)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:49)
at scala.collection.TraversableLike.map(TraversableLike.scala:286)
at scala.collection.TraversableLike.map$(TraversableLike.scala:279)
at scala.collection.AbstractTraversable.map(Traversable.scala:108)
at org.apache.spark.deploy.SparkSubmit.downloadResourcesToCurrentDirectory$1(SparkSubmit.scala:429)
at org.apache.spark.deploy.SparkSubmit.$anonfun$prepareSubmitEnvironment$16(SparkSubmit.scala:450)
at scala.Option.map(Option.scala:230)
at org.apache.spark.deploy.SparkSubmit.prepareSubmitEnvironment(SparkSubmit.scala:450)
at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:964)
at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:194)
at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:217)
at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:91)
at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:1120)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:1129)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)


Add git revisions as labels

Would it be possible to add labels that are like gitrev-XXXXXXXXXXXXXXX that have the full git revision of a specific build?

FYI - @proppy

@PiotrZierhoffer  is this information already available in some way?

@donn git revision of the upstream repo, or the conda-eda repo?
If the former the short rev is already part of the archive name, prefixed with g, see:
https://anaconda.org/LiteX-Hub/openlane/files

That's not entirely an option, as there is no way I'm aware of to translate the long rev into ${version}_g${shortrev} without cloning the repository myself first or maintaining a dictionary somewhere.

@donn - What are you trying to do? The {shortrev} value should work anywhere the full revision value is accepted...

We don't have shortrev set up in the OpenLane tool Docker repo tags (efabless/openlane-tools), so we can't use the shortrevs there. Additionally, shortrevs are not immutable: in the (admittedly small) chance that another revision is generated with the first same 7 characters in the revision hash, the shortrev immediately becomes ambiguous: git will not generate the same shortrev for said revision nor will it accept it as a means of reaching said revision again.
Additionally, that does not solve the version and revision numbers as part of the version tag.
I was wondering if we could just have a direct mapping from the full revision hash to a label. It would make my life a lot easier.


[Device Support Request] Tuya 0-10V dimmer TS110F

Is your feature request related to a problem? Please describe.
Just have received a dimmer https://www.aliexpress.com/item/1005003150502224.html. It works without a quirk, all functionality is available except one setting.
In Tuya smart application is possible to set minimal level of dimming:

Describe the solution you'd like
I'd like to add this setting to zigpy.
Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0101",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0008"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_snlc8jgn",
  "model": "TS110F",
  "class": "zigpy.device.Device"
}

Additional context
As you can see, there are no custom clusters. So, I think the setting is an attribute in one of the standard clusters. All I need to prepare custom quirk is the attribute ID.

THAT I HAVE MISSED !!
I have one dual with no line dimmer and its works great but also not having any extra clusters. https://github.com/MattWestb/tuya-Switches-Dimmer
The problem no one have "finding" the commands / attributes for doing those settings.
Then you is having one tuya ZBGW its good but do you have somthing for sniffing the zigbee traffic like CC-2531 or one EFR32MG module ?
If yes its easy sniffing only need little practice for getting it done done.

By the way is you living  in the AI warehouse then you is getting all the nice devices ?

Then you is having one tuya ZBGW its good but do you have somthing for sniffing the zigbee traffic like CC-2531 or one EFR32MG module ? If yes its easy sniffing only need little practice for getting it done done.

Yes, I've CC2531. Will try to sniff zigbee traffic later.

By the way is you living in the AI warehouse then you is getting all the nice devices ?
Some was giving it 5 starts then using it in ZHA !!

No, I'm just trying to make my new house a bit smarter. I've started with two smart plugs, but appetite comes with eating :)

I have the same experience but have not so large aria for making smarter but i like having the light for my flowers going  with the sun and how much light is outside and also the night light is doing all its self as long me Pi is online.
I was adding your dimmer in my list then its from the same "family".
Interesting what you can finding from sniffing the dimmer !!

For now, my most annoying device is this BLE fingerbot https://www.kickstarter.com/projects/adaprox/fingerbot-control-all-devices-remotely-through-voice-or-app
It is not supported by any of Tuya integrations. I've ever sniffed BLE traffic between my phone and the device. It communicates in very not standard way and all traffic is encrypted. It looks like only one way to integrate it is via cloud, despite I don't like such way.

So, I've sniffed it.
When I set minimal level on 1%, next packet was sent to device:
Frame 1847: 53 bytes on wire (424 bits), 51 bytes captured (408 bits) on interface \\.\pipe\zboss_sniffer_COM4, id 0
IEEE 802.15.4 Data, Dst: 0xa149, Src: 0x0000
ZigBee Network Layer Data, Dst: 0xa149, Src: 0x0000
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
    Destination Endpoint: 1
    Cluster: Level Control (0x0008)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 242
ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 98
    Frame Control Field: Profile-wide (0x10)
    Sequence Number: 98
    Command: Write Attributes (0x02)
    Attribute Field, Uint16: 1023
        Attribute: Unknown (0xfc00)
        Data Type: 16-Bit Unsigned Integer (0x21)
        Uint16: 1023 (0x03ff)

For 10% all the same except the value
Uint16: 6911 (0x1aff)
20%
Uint16: 13055 (0x32ff)
99%
Uint16: 64767 (0xfcff)
It's clear that the first byte of the 16-bit word is minimal dimming level. I suppose that second byte might be maximal dimming level.
How it's better to implement this in quirk? Just expose it as one 16-bit value or create two fields structure?

Nice done ! :-)))
I was thinking making one slider like we have doing for some tuya TRV for setting analogue values like temperature correction and countdowns.
If making one new cluster in tuya INIT you is getting one slide for dim min and one for dim max limit only need using "tuya lightlevel_dim".
I need the absolute min and may values and also the stepping for both dim min and max. Have you trying if you can setting the max level and if its working in real.
The small problem is splitting the values and making 2 functions of it.
You can looking how hi have doing it for me TRV for software calibrating of local temperature (its having one bug after test in in the night but the slider is working).
If you like i asking our tuya TRV dreamcoder if hi can helping doing the new cluster with slides.

Sorry i was forgetting the link to the TRV implementation https://github.com/zigpy/zha-device-handlers/discussions/1084#discussioncomment-1675754

You have  "class": "zigpy.device.Device" do you're not using any quirk at now.
In simple words: what do you want to achieve???
Min level correction??

Its one "normal" zigbee device but have extra attribute on the level cluster that setting the min and max level with one Uint16 for both the min and max level the device shall using.

Some found and used extra attribute used of tuya "normal" Zigbee devices.
https://github.com/zigpy/zigpy/discussions/823#discussioncomment-1539469

I'll prepare quirk in a couple of days and check second byte function. Personally for me, it will be enough. I have no plans to control this dimmer from UI, only from automatization and from external momentary switch. But controlling the dimmer from UI requires some changes if min and max levels will be applied.

@MattWestb could you please point me to latest ZigBee Cluster Library specification. In some documents I see attributes MIN_LEVEL (0x0002) and MAX_LEVEL (0x0003) in Level Control Cluster, but it's not clear to which version of ZCL they belong.

The ZCL ver 7  is the normal but new devices can using ZCL R8 that i was "finding" for one week ago.
Both is in the liked posting https://github.com/zigpy/zigpy/discussions/595#discussioncomment-287276.
On the level cluster its need being one new made for tuya dimmers and i think you dont have any large problems getting the values right but for normal user its no so easy so i think making it with 2 slides is the best method but it can being done in the quirk but but is need 2 end points then its using the same cluster and one end point can only using one cluster of the same type.
If some is good programming i ZHA it have being easy only adding the cluster and ZHA is making the magic but for the moment we dont have one that can doing the ZHA part so best way is making sliders on 2 endpoints so user can easily using the function.

For normal work your device uses standard LevelControl cluster 0x0008
https://github.com/zigpy/zigpy/blob/dev/zigpy/zcl/clusters/general.py#L433
But this is Tuya - they used 0xfc00 attribute to control min/max
So even you have some good looking standard attributes:
        0x0011: ("on_level", t.uint8_t),
        0x4000: ("start_up_current_level", StartUpCurrentLevel),

2.14  St art UpCur r ent Level  Attr ibut e  5382
The StartUpCurrentLevel attribute SHALL define the desired startup level for a device when it is supplied 5383
with power and this level SHALL be reflected in the CurrentLevel attribute. The values of the StartUpCur-5384
rentLevel attribute are listed below: 5385
Table 3-58. Values of the StartUpCurrentLevel attribute

Probably none of them won't work since Tuya is using custom attribute 0xfc00
In my opinion you need to build quirk and extend there that class below with manufacturer attribute 0xfc00
class LevelControl(Cluster):

I've created a quirk and checked behavior of 0xfc00 attribute.

It works, first byte represents min dimming level, second byte - max dimming level. These values remain after power outage.
These min and max values restrict only external momentary switch. It's possible to set any value via ZigBee.

I've checked it with t.uint16_t as type of attribute.
I'm trying to change the type in next way:
class MinMaxLevel(t.Struct):
    """Tuya min and max dimming level attribute."""

    max_level: t.uint8_t
    min_level: t.uint8_t

class TuyaZBLevelControl(CustomCluster, LevelControl):
    """Tuya Zigbee Level Control cluster with extra attributes."""

    attributes = LevelControl.attributes.copy()
    attributes.update({0xFC00: ("min_max_level", MinMaxLevel)})

but getting value of attribute still returns 16-bit value. What is the right way to use Struct?

I think we need writing the min and max to the level cluster attribute so ZHA is knowing them.
From ZCL V7:

If its working like with TRVs and min and max temperature ZHA is using the stored value
for limiting the GUI so not trying sending out of rage values to the device.
The question is ZHA using this attribute or is it not implanted ?
Example from my TRV is making the GUI having 5°C as lowest value instead or 7°C that is standard in ZHA. Its statick then the TRV is not sending this value but its the real limit of the device and cant being updated with the simple code.
    _CONSTANT_ATTRIBUTES = {
        0x0015: 500,  # Min heating SP
        0x0016: 3000,  # Max heating SP

For now, ever zigpy doesn't know about MinLevel and MaxLevel attributes
    cluster_id = 0x0008
    name = "Level control"
    ep_attribute = "level"
    attributes = {
        0x0000: ("current_level", t.uint8_t),
        0x0001: ("remaining_time", t.uint16_t),
        0x0010: ("on_off_transition_time", t.uint16_t),
        0x0011: ("on_level", t.uint8_t),

I think it will be the best solution to map Tuya specific attribute to standard ones.

Looks like min and max is for general OnOff but is not needed for light profile devices :((
But its moderate for" 3.20Pulse Width Modulation" devices so im not sure its working on normal lights.
Mapping tuya attribute to standard ones is great if its possible.
I was thinking that the right  way for the power on state for getting better support for the function.

I was also not finding the attribute in ZHA.
Also the "0x001c Derived Pulse Width Modulation (3.20)" looks not being implanted.

Do your device have support for different load types like this ? https://github.com/Koenkk/zigbee2mqtt/issues/9878
Its looks like they is having one attribute for min and one for max so perhaps tuya have making more versions :-(((

@MattWestb no, mine only has 0-10V output.

And the Z2M is not having that :-))

I'm not sure if this is exactly what you need, but I think it would be possible to map the values of the Tuya cluster to the standard attributes with something like the following:

FC00_MIN_MAX_LEVEL_ATTRIBUTE = 0xFC00

class MinMaxLevel(t.Struct):
    """Tuya min and max dimming level attribute."""

    min_level: t.uint8_t
    max_level: t.uint8_t

class FC00MinMaxLevelControl(CustomCluster, LevelControl):
    """0xFC00 cluster with min_max_level attribute."""

    manufacturer_attributes = {
        FC00_MIN_MAX_LEVEL_ATTRIBUTE: ("manufacturer_min_max_level", MinMaxLevel),  # 0xFC00
    }

    # 0xFC00 reports min&max dim level
    def _update_attribute(self, attrid, value):
        if attrid == FC00_MIN_MAX_LEVEL_ATTRIBUTE:
            self.debug("Getting MIN_MAX %s", value)
            super()._update_attribute(0x0002, value.min_level)
            super()._update_attribute(0x0003, value.max_level)
        else:
            super()._update_attribute(attrid, value)

To modify the range, it should be done through the cluster attribute manufacturer_min_max_level assigning the hexadecimal value (for example: 0x00FF). Not very friendly.
To make it more user friendly (and follow the zigbee standard) the 0x0002 and 0x0003 attributes of the cluster should be used. This would require overriding the write_attributes method. It would be necessary to read the manufacturer_min_max_level value and modify the part of the limit to set before write the value.
I don't have much time available, but if someone wants to explore that path I can try to help as much as I can.

@javicalle thank you for suggested code, I'll try it as I can. I'm from Ukraine and here is a war. I'm a refugee today. When I return, I can find my house (which I try to make smart) damaged, or completely ruined. I have no illusion.

That's not the kind of trouble you expect to find around here 💔
I'm really very, very sorry. I can't even imagine what you must be going through.
Just to say that I hope that you and your relatives are safe and that you may have a good end to your situation.


Reform compare argument parsing

This PR fixes #23 by changing the format of compare arguments.
The TL;DR is
hlarp compare optitype=/path/to/opti_dir athlates=/path/to/ath_dir ...

instead of
hlarp compare --optitype /path/to/opti_dir --athlates /path/to/ath_dir ...

this mostly simplifies some internal logic. There is also a small bug fix for dealing with samples that have no comparisons.

I'm going to hold off on merging this until @ihodes comes back and has a chance to comment on the  target branch.

Sorry, @ihodes , I forgot and merged that branch. I'll merge this one too. Feel free to comment later.


Lots of warning during build

During the build, lots of warnings are emitted. See the attached file for the actual output.
warnings.txt
The resulting module seems to be working fine, but I thought I'd just report this.

This actually fails with node 12.2.0, see the attached messages.
errors.txt

Created https://github.com/swillner/netcdf4-js/pull/22.


[DOCFIX] Fix setTtl and unsetTtl command doc.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/10114/
Test PASSed.

thanks for the fix! LGTM

actually, could you reopen the PR to branch 1.1?

sure, closing this one.


Changed names to make example more clear

I think this example is a little bit clearer. Clarifying that (what was Incident) is a schema and can be reused multiple times.

Codecov Report

Merging #23 into master will increase coverage by <.01%.
The diff coverage is n/a.

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

@rbw I think this should be all set

Sorry about that delay.
The examples are clearer in 0.3 thanks to the introduction of built-in schemas and the Snow.get_table method.
An example from:
https://github.com/rbw/snow/blob/master/examples/table/read/one.py
from snow.schemas.table import IncidentSchema as Incident

async def main(app):
    async with app.get_table(Incident) as inc:
        response = await inc.get_one(Incident.number == "INC0010240")
        print(response["description"])

Thanks for the suggestion.


Enabling Cors + Controlled Start

:tada: This PR is included in version 2.1.3 :tada:
Your semantic-release bot :package::rocket:


News teaser - preview text should not include the different text styles (H1, H2, etc.)

The teasers for the news shows the bigger text (H2) when it's in the description text. That should all be the same small text. See screenshot:

@jcr ready on Dev - https://dev.landportal.info/debate/news

not an ideal fix but I guess that'd do the job.
From what I saw - it forces all font size (p, h1, h2, h3 etc...) to be the same in this teaser.


Remove MultiProgress::join() based on #231

This change moves drawing of MultiProgress from the join() thread to the child ProgressBar updates.  fixes #125, #33 and lay groud work for work on #205
It is backwards-incompatible.
It is based on the work of @marienz  in #231 more discussion and detail on that pull request.

I don't know enough about indicatif to know why it causes the defect, but the current PR does not respect when a progress bar is hidden.
        debug!("Bar Hidden?: {}", hidden_bar.is_hidden());
        let bar_after_add = mp.add(hidden_bar);
        debug!("Hidden after add?: {}", bar_after_add.is_hidden());
        bar_after_add.set_draw_target(ProgressDrawTarget::hidden());
        debug!("Hidden after draw target?: {}", bar_after_add.is_hidden());

Corresponding output:
Bar Hidden?: true
Hidden after add?: false
Hidden after draw target?: true

@boc-tothefuture are you sure this PR actually changed this behavior? See the docs for set_draw_target which note this case explicitly in the current version.

@boc-tothefuture are you sure this PR actually changed this behavior? See the docs for set_draw_target which note this case explicitly in the current version.

You are correct, the same behavior exists in the currently released version.  I did not think I was experiencing that until I switched.  My apologies.

Except for the typos, this is looking pretty good! Thanks for working through my comments.

Typos fixed also fixed the failing CI

I just pushed another test that calls MultiProgress.join(), would you mind rebasing on main and pushing that once more? I can merge it after that.

Rebased on the the latest main (ignore the moment of stupidity where I rebase it on master instead).
Thank for all your help an patience with this.


I can't verify the reddit link, it doesn't do anything when clicking the form

Keybase GUI Version: 1.0.18-20170216112451+a5b6199
Hi, I am using Windows 10 client, when trying to verify my reddit account using the client it doesn't open the form when clicking on the link so I can't verify it.

When trying to do it through the web site, I've got this error message on reddit web site.

@Juvls Reddit is down.

@cjb I can access the rest of the web site, only the keybase part seems down

It's still a server error from their end, we can't fix it.  Try again soon.

Fair enough, thanks! 👍


Close JsonWriters. Caused speed up?

see:
[#148]
I use hap-java for my entire house. Everything is KNX, so pretty much accessories. Sometimes the accessories turn red and says "device not responding" (or something like that, get it in dutch). Also sometimes it takes a while, which makes no sense, because I cache all KNX values. I use a version with another pr request in it [#130]. Also I updated all dependencies in my local build of HAP-Java. No "device not responding" anymore and seems to react a lot faster.
So I'm not sure if closing JsonWriters did the trick. It can't hurt also. And in the close() operation of JsonWriter you see a flush. ByteArrayBuffer was closed, but that doesn't do anything.
I stole this idea from pr [#116]. That pr fixed it on one occurrence, but I found 3 more, by searching on usages of createWriter().

Started my own hap implementation, pr requests are merged waaaay to slow.


Add number property in stage and group

Could simplify getting relative data. No need for ids anymore.

Done in brackets-model.


VS2017?

It seems that BuildFFmpeg.bat wants to use VS2015. Could you please update it to support VS2017?

Yes, the way to detect the tools has changed with VS2017. We are looking at updating the scripts to support VS2017.

Here's the updated Buildffmpeg.bat I used for vs 2017
BuildFFmpeg.zip

Hi, this isn't for VS2017

The code works fine for VS 2017, we just haven't had a chance to fully update the build scripts to support VS 2017. I've got most the necessary changes but need to validate with different install combinations.

In the interim, you could try this.  Worked for me.

I try both, but I got error "VS140COMNTOOLS environment variable is not found. Check your Visual Studio 2015 installation" how to fix this?

This is because the scripts haven't been updated for VS2017.
I've been investigating a new package manager that Microsoft is developing and it does make things a lot easier to get started and works great for both VS2015 and VS2017. That's partly why it's taken me longer to get the scripts updated to VS2017.
The project is vcpkg and it already supports a bunch of different projects with both VS2015 and VS2017. They have already added support for FFmpeg and I've issued a pull request to add the UWP version of FFmpeg.
To try it out is quite simple:

Clone the repo (for now use my fork until my code is merged upstream)
git clone https://github.com/khouzam/vcpkg -b ffmpeg-uwp
Bootstrap the tool:
cd vcpkg
bootstrap-vcpkg.bat
*Build the flavors of FFmpeg that you need for example if your want x86, x64 and arm (the -uwp will build for store whereas -windows will build for desktop).
vcpkg install ffmpeg:x86-uwp ffmpeg:x64-uwp ffmpeg:arm-uwp
Let this run for a while and you will endup with FFmpeg built and available for use (noticed that msys, and all the tools are automatically installed and configured for you.

Now comes the even more interesting part, the integration with VS.

From an elevated command prompt run
vcpkg intergrate install
This configures VS to automatically reference the packages that you have built and have installed. So any project can now reference the FFmpeg headers without having to modify the include path and manually adding references to the dlls. Building a store app will automatically include the required files in the package.

You can see how this has simplified the projects with the vcpkg branch that I just updated.

@khouzam  hey I just wanted to ask that the steps you defined above if I follow them for my VS 2017, I don't need to clone this repo "github.com/Microsoft/FFmpegInterop" and I don't need to follow other details steps mentioned here "https://trac.ffmpeg.org/wiki/CompilationGuide/WinRT" right?

I was able to create all 3 packages for UWP, x86, x64, and arm. I also integrated them with VS according to the steps you mentioned in above comment. Now how can I consume and reference those created packages in my UWP project? Thanks

I just wanted to ask why cant we have a nugget package for this repo? So that it gets simpler to integrate it in any uwp project on any machine instead of building it and then integrating it on a machine whenever we want to use it?

the reason I asked thisis because on some machines it builds successfully but on some machines it gives many errors, so if there was a straight forward package that would simplify things

How do you reference these integrated packages in VS 2017 for C#?

@touseefbsb I think there are legal reasons why no compiled builds of ffmpeg are distributed. Some of the codecs might be covered by patents. The authors of ffmpeg "only show you how this could be decoded" but they do not offer any running decoders/encoders. If you compile yourself, then you are the one who acutally built the decoder assembly...


Improper recognition of older PE files.

Describe the bug
Some older PE files are detected as old-school MZ exectuables
To Reproduce
Steps to reproduce the behavior:

Import a certain valid PE file

Expected behavior
Ghidra should recognize the file as proper PE
Screenshots
If applicable, add screenshots to help explain your problem.

Here is for comparison, summary of this file in Binary Ninja

Attachments
If this is desired I can upload problematic files with WeTransfer
Environment (please complete the following information):

OS: Arch Linux, Linux 5.15.12
Java Version: 11.0.13
Ghidra Version: 10.1
Ghidra Origin: ghidra-sre.org

Additional context
This was discovered initialy here but it isn't a MIPS issue or a MIPS PE
issue as this bug occurs with any dll file (haven't checked any exes)
for any architecture from this certain Windows version.

Is PE in the format list, with MZ being the default?  Or is PE totally missing as a choice?

It is missing.

hexdump.txt

https://we.tl/t-rvERnvKT6p

these are 4 files i tried to reverse in ghidra, and none of which were detected properly


Enderite Items Void Float Problem

Enderite Items Void Float in the overworld on player death but not in the end when player dies in the void.

Fixed as of 1.18. Thanks for the report.


Check go version before export GCFLAGS for debug.

When DEBUG is set to 1, for go higher than or equal to 1.10, add pattern 'all=' in the flag, to apply '-l -N' to all the dependencies.
This is needed for go 1.10 or higher when debugging, since gcflags now needs a pattern to specify the scope to apply the following parameters.
Refs:

https://golang.org/doc/go1.10#build
https://github.com/golang/go/blob/release-branch.go1.10/src/cmd/go/internal/work/build.go#L113-L127

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: geeknoid
Assign the PR to them by writing /assign @geeknoid in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @crystaldust. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

I signed it!

/assign @geeknoid
This is my first PR to istio, so if there are some prerequisites I'm missing, let me know to fix it.
BTW, it's weird that the update of Makefile will decrease the test coverage of go files.


Package request: dut (fast disk usage calculator)

Project description
From the author, via Hacker News:

"dut" is a disk usage calculator that I wrote a couple months ago in C. It is multi-threaded, making it one of the fastest such programs. It beats normal "du" in all cases, and beats all other similar programs when Linux's caches are warm (so, not on the first run). I wrote "dut" as a challenge to beat similar programs that I used a lot, namely pdu and dust.
"dut" displays a tree of the biggest things under your current directory, and it also shows the size of hard-links under each directory as well. The hard-link tallying was inspired by ncdu[3], but I don't like how unintuitive the readout is. Anyone have ideas for a better format?
There's installation instructions in the README. dut is a single source file, so you only need to download it and copy-paste the compiler command, and then copy somewhere on your path like /usr/local/bin.

Metadata

homepage URL: https://codeberg.org/201984/dut
source URL: https://codeberg.org/201984/dut
license: GPL v3
platforms: linux

Add a :+1: reaction to issues you find important.

cool program. @Frontear https://codeberg.org/201984/dut#specs :)

This program already exists since 6066650cb46fd.

Good catch. I searched for it on https://search.nixos.org/packages, but neglected to try the unstable channel.
Thanks.


Test for switch exhaustiveness invocation cutoff.

Adds a test to check that the frontend option -switch-checking-invocation-threshold= works.

@swift-ci test and merge


Add links to the supporters section

Fixes #284

Since they go to external sites, it would be good for the links to have the attributes: target="_blank" rel="noopener"

I prefer to use rel="noopener noreferrer" to avoid any kind of information to the new tab or window to be exploited by malicious JS


Typing issue: 空集合

Category of the typing issue
3. Conversion issue (e.g. "夕日がきれい" is not converted as expected).
Issues
Write issues to the following table. (It's in the markdown format)

input [e.g.ゆうひ]
expected [e.g. 夕日]
actual [e.g. ユウヒ]

くうしゅうごう
空集合
空襲号

Version or commit-id
Mozc-2.23.2815.102+24.2.oss

2e3a445 added the word based on your feedback.
Thank you!


spurious failure in VariousTest.Issue2458

See log here

I haven't seen this happen again, so I assume this is fixed now.


I think mongo connector's not working as expected.

Hi,
I created a mongo db replica set, and a solr node. Following is the command mongo-connector command that I used:
mongo-connector -m isank:27017 -t http://localhost:8983/solr/myMongoReplica -d solr_doc_manager
after pressing return what I get is just - Logging to mongo-connector.log. and nothing else.
I followed everything suggested in wiki, but I can't get it working.

Can you please share:

contents of mongo-connector.log
contents of the logs from Solr

Thanks.

There are no logs generated in mongo-connector.log, it's empty all the time, and not so relevant things coming up from solr even.

Can you please turn up the verbosity on mongo-connector (-v) and report back with any new log information? Thank you.

Nothing comes up even with the verbosity mode on.

Is there anything else need to be done for mongo or solr to make this work, that is not mentioned in the wiki or docs?

Hi Luke, finally I got something useful but the data is still not visible in Solr.
OplogThread: Operation for this entry is i
2015-06-10 01:09:54,583 [DEBUG] pysolr:797 - Starting to build add request...
2015-06-10 01:09:54,584 [DEBUG] pysolr:812 - Built add request of 1 docs in 0.00 seconds.
2015-06-10 01:09:54,584 [DEBUG] pysolr:291 - Starting request to 'http://localhost:8983/solr/mymongoreplica/update/?commit=false' (post) with body 'u'<do'...
2015-06-10 01:09:54,586 [INFO] requests.packages.urllib3.connectionpool:238 - Resetting dropped connection: localhost
2015-06-10 01:09:54,704 [DEBUG] requests.packages.urllib3.connectionpool:383 - "POST /solr/mymongoreplica/update/?commit=false HTTP/1.1" 200 None
2015-06-10 01:09:54,704 [INFO] pysolr:325 - Finished 'http://localhost:8983/solr/mymongoreplica/update/?commit=false' (post) with body 'u'<do' in 0.120 seconds.
2015-06-10 01:09:54,704 [DEBUG] mongo_connector.oplog_manager:290 - OplogThread: Doc is processed.

Thanks for the logs! I see that mongo-connector is not requiring Solr to
commit documents, so changes made to Solr will only be reflected when Solr
does its automatic, periodic commit. This may be why you're not seeing
changes to Solr. See managing commit behavior
in the Solr section of the wiki for how to configure this.
On Tue, Jun 9, 2015 at 12:39 PM, isank<EMAIL_ADDRESS>wrote:

Hi Luke, finally I got something useful but the data is still not visible
in Solr.
OplogThread: Operation for this entry is i
2015-06-10 01:09:54,583 [DEBUG] pysolr:797 - Starting to build add
request...
2015-06-10 01:09:54,584 [DEBUG] pysolr:812 - Built add request of 1 docs
in 0.00 seconds.
2015-06-10 01:09:54,584 [DEBUG] pysolr:291 - Starting request to '
http://localhost:8983/solr/mymongoreplica/update/?commit=false' (post)
with body 'u' 2015-06-10 01:09:54,586 [INFO]
requests.packages.urllib3.connectionpool:238 - Resetting dropped
connection: localhost
2015-06-10 01:09:54,704 [DEBUG]
requests.packages.urllib3.connectionpool:383 - "POST
/solr/mymongoreplica/update/?commit=false HTTP/1.1" 200 None
2015-06-10 01:09:54,704 [INFO] pysolr:325 - Finished '
http://localhost:8983/solr/mymongoreplica/update/?commit=false' (post)
with body 'u'<do' in 0.120 seconds.
2015-06-10 01:09:54,704 [DEBUG] mongo_connector.oplog_manager:290 -
OplogThread: Doc is processed.
—
Reply to this email directly or view it on GitHub
https://github.com/10gen-labs/mongo-connector/issues/265#issuecomment-110480775
.

@llvtt
Thanks for the reply Luke.
Agreed on the periodic commit stuff, but what if I reload the core on Solr?
And also could you please help me with where to place the schema.xml file for solr to read. I am using Solr 5.1.0

@llvtt
This is how I have started my mongo connector
mongo-connector -m isank:27017 -t http://localhost:8983/solr/mymongoreplica -d solr_doc_manager -v --auto-commit-interval=0
but still the logs are same as in above comments, and no data in Solr

This page looks relevant to schema configuration with Solr: https://cwiki.apache.org/confluence/display/solr/Managed+Schema+Definition+in+SolrConfig.

FYI: mongo-connector does not support schema-less Solr right now, as documented here: https://github.com/10gen-labs/mongo-connector/issues/170.

Any updates on this? Are you using schema-less Solr?

Closing this issue due to inactivity. Feel free to reopen or create a new issue if there's more to discuss.


feature(inputs): adds support for path exclusions

see #56

@laxmibaral9 see if this works as expected. You can test with uses: halaslabs/get-changed-files@56-add-regex-exclusion-path-filter


Add support for custom puml keyword (refs: #20)

Hi @legwinskij, please take a look. I've added few comments.

Good job @legwinskij 👍 Will be added to a new release!