Unable to install library

Hello!
For some reasons i was unable to install library properly: it says that "lib_SyndromeDecodingEstimator.so: cannot open shared object file: No such file or directory"

Full trace of the make installation:
kirtsar@kirtsar:~/projects/rosehip/syndrome_decoding_estimator$ sudo make
mkdir -p C/build && cmake -DCMAKE_INSTALL_PREFIX=local/ -B C/build -S C
Running CMAKE in directory: C
-- The C compiler identification is GNU 9.4.0
-- The CXX compiler identification is GNU 9.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- BUILDING IN  MODE
-- COMPILATION FLAGS:
-- Adding the following directories to the project:
-- Adding directory: /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator
Running CMAKE in directory: sd_estimator
-- Adding the following .c files to the source list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_ball_collision_optimizer.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_bjmm_optimizer.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_both_may_depth_2.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_dumer_optimizer.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_estimator.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_helper.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_may_ozerov_optimizer.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_optimizer.cpp
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_stern_optimizer.cpp
-- Adding the following .h files to the header list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_ball_collision_optimizer.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_bjmm_optimizer.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_both_may_depth_2.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_dumer_optimizer.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_estimator.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_helper.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_may_ozerov_optimizer.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_optimizer.h
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/src/sd_estimator/sd_stern_optimizer.h
Running CMAKE in directory: sd_estimator
-- Adding the following .c files to the source list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/tests/sd_estimator/test_sd_estimator.cpp
-- Adding the following .h files to the header list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/tests/sd_estimator/test_sd_estimator.h
Running CMAKE in directory: main
-- Adding the following .cpp files to the source list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/main/main.cpp
-- Adding the following .h files to the header list:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/main/constants.h
-- Including the following directories:
    /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/tests/sd_estimator
-- Linking the following targets to the project1:
    test_sd_estimator
Back to main cmake:
-- Adding the following targets to the project:
    sd_estimator
Targets list:src/sd_estimator/sd_estimator.cppsrc/sd_estimator/sd_helper.cppsrc/sd_estimator/sd_both_may_depth_2.cppsrc/sd_estimator/sd_optimizer.cppsrc/sd_estimator/sd_ball_collision_optimizer.cppsrc/sd_estimator/sd_bjmm_optimizer.cppsrc/sd_estimator/sd_dumer_optimizer.cppsrc/sd_estimator/sd_may_ozerov_optimizer.cppsrc/sd_estimator/sd_stern_optimizer.cppmain/main.cpp$<TARGET_OBJECTS:sd_estimator>
-- Configuring done
-- Generating done
-- Build files have been written to: /home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build
cd C/build && make && make install
make[1]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[2]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
Scanning dependencies of target _SyndromeDecodingEstimator
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[  4%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_estimator.cpp.o
[  9%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_helper.cpp.o
[ 14%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_both_may_depth_2.cpp.o
[ 19%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_optimizer.cpp.o
[ 23%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_ball_collision_optimizer.cpp.o
[ 28%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_bjmm_optimizer.cpp.o
[ 33%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_dumer_optimizer.cpp.o
[ 38%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_may_ozerov_optimizer.cpp.o
[ 42%] Building CXX object CMakeFiles/_SyndromeDecodingEstimator.dir/src/sd_estimator/sd_stern_optimizer.cpp.o
[ 47%] Linking CXX shared library lib_SyndromeDecodingEstimator.so
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 47%] Built target _SyndromeDecodingEstimator
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
Scanning dependencies of target sd_estimator
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 52%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_ball_collision_optimizer.cpp.o
[ 57%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_bjmm_optimizer.cpp.o
[ 61%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_both_may_depth_2.cpp.o
[ 66%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_dumer_optimizer.cpp.o
[ 71%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_estimator.cpp.o
[ 76%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_helper.cpp.o
[ 80%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_may_ozerov_optimizer.cpp.o
[ 85%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_optimizer.cpp.o
[ 90%] Building CXX object src/sd_estimator/CMakeFiles/sd_estimator.dir/sd_stern_optimizer.cpp.o
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 90%] Built target sd_estimator
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
Scanning dependencies of target test_sd_estimator
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 95%] Building CXX object tests/sd_estimator/CMakeFiles/test_sd_estimator.dir/test_sd_estimator.cpp.o
[100%] Linking CXX static library libtest_sd_estimator.a
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[100%] Built target test_sd_estimator
make[2]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[1]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[1]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[2]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 47%] Built target _SyndromeDecodingEstimator
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[ 90%] Built target sd_estimator
make[3]: Entering directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
make[3]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
[100%] Built target test_sd_estimator
make[2]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/lib_SyndromeDecodingEstimator.so
make[1]: Leaving directory '/home/kirtsar/projects/rosehip/syndrome_decoding_estimator/C/build'
python3 -m pip install --upgrade setuptools
Requirement already up-to-date: setuptools in /usr/local/lib/python3.8/dist-packages (65.5.1)
python3 -m pip install .
Processing /home/kirtsar/projects/rosehip/syndrome_decoding_estimator
Requirement already satisfied: progress in /usr/local/lib/python3.8/dist-packages (from sd-estimator==1.0.0) (1.6)
Requirement already satisfied: prettytable in /usr/local/lib/python3.8/dist-packages (from sd-estimator==1.0.0) (3.5.0)
Requirement already satisfied: scipy in /usr/local/lib/python3.8/dist-packages (from sd-estimator==1.0.0) (1.9.3)
Requirement already satisfied: wcwidth in /usr/local/lib/python3.8/dist-packages (from prettytable->sd-estimator==1.0.0) (0.2.5)
Requirement already satisfied: numpy<1.26.0,>=1.18.5 in /usr/local/lib/python3.8/dist-packages (from scipy->sd-estimator==1.0.0) (1.23.4)
Building wheels for collected packages: sd-estimator
  Building wheel for sd-estimator (setup.py) ... done
  Created wheel for sd-estimator: filename=sd_estimator-1.0.0-py3-none-any.whl size=18278 sha256=a98bec269bd2b2ba2cbdf2136a8656aec250b1bbde6b370c293f2c0572525382
  Stored in directory: /tmp/pip-ephem-wheel-cache-fmmc7sqr/wheels/b4/b7/d3/ea49342cd3a16358a4b6a44c08a39b986069c6adcbfbec44bf
Successfully built sd-estimator
Installing collected packages: sd-estimator
  Attempting uninstall: sd-estimator
    Found existing installation: sd-estimator 1.0.0
    Uninstalling sd-estimator-1.0.0:
      Successfully uninstalled sd-estimator-1.0.0
Successfully installed sd-estimator-1.0.0

Hi kirstar,
sorry for the delayed reply. The issue is that the estimator is not finding the C-library. According to the trace it was installed to /usr/local/lib/lib_SyndromeDecodingEstimator.so. We are currently working on a version which does not require any C-code anymore. But until this is released, as a workaround you could try to add the path of the library to your PATH environment variable.

@kirtsar Please try:
LD_LIBRARY_PATH="/usr/local/lib" python estimate_code_based_nist_schemes.py

Have you solved this problem?

He said we need to download this shared library from GitHub, but where exactly do we download it from?


Host preview.png on GitHub's CDN

By the way, you can do this by simply dragging & dropping a file into any markdown-supported textarea on GitHub. It'll give you a URL which you can then use to reference your image:

Awesome, thanks for the tip!


Custom role for principal role

I can see that the logged-in users(for the event) will have almost full access to most of the services. And there is no option for giving the role name for the principal role.
In our case, we want to use a custom policy for that role, so based on the workshop we can assign the permission to the respective services.
Unfortumatly, we have deployed the stack and its running for 3 months. I guess templates/principal_policy.tmpl is the file that has this policy, unfortunately its a running stack.

Yes, the file templates/principal_policy.tmpl in this project is used as initial starting value when deploying the project.
This file is use by the underlying DCE project to define the policy that is deployed into the pool accounts to be assumed by end users.
I am not a part of the DCE project, but if I read their code correctly, each time an account is leased, the policy template is read from the file s3://<your_account_id>-dce-artifacts-dce/fixtures/policies/principal_policy.tmpl on S3. I recommend testing if changing that file in an already deployed environment will be automatically applied when the next lease is created - in this case you could use it to limit down the principal permissions in your existing project.

Closing due to inactivity.


Deleting Products via the Catalog deletes from Draft Site, but not from published

To replicate, delete a product via admin/catalog/
The product is deleted from the Catalog (i.e can't be found there), but

shows in the SiteTree as 'Removed from Draft',
remains live.

Expected behaviour: Product would also be removed from the Live site.
I assume the Product page also needs
->deleteFromStage("Live");
but I'm unsure of how to implement this.

Deleting records doesn't seem to be enabled by default. What did you do to enable deletion of records in the catalog-admin?

Sorry, I mean when you 'edit' a Product from the Catalog - the Delete button there:
e.g.
/admin/catalog/Product/EditForm/field/Product/item/1/edit/

Yeah, somethings seems to be going wrong there… although I get an "Unpublish" button instead of the "Delete" button, and the "Delete" button appears at its place once the product has been unpublished. That seems to be fine, but I get some other PHP errors when trying to unpublish/delete via ModelAdmin.
Not sure if this is a problem with shop, or a bug in handling Versioned records in ModelAdmin.

Thanks Roman, I tracked down my issue to being related to the silvershop-discounts module and the versioned-gridfield.
The baseTable function of the versioned-gridfield was returning 'GiftVoucherProduct' for the ClassName instead of just the Product - which was throwing out the 'published' status.
Overriding that function to just return the ClassName has fixed my problem.

I've come across this too.  it's confusing users a bit.
@beeonlinenz  - do you know if the discount module maintainer knows about this?


expose container memory limits

As a developer i would like to be able to control the memory limit for a container.
This is also exposed in cloud run
See also #1340

The Handler resource exposes a full PodSpec, so the support exists. However, the CLI does not populate these fields.


Some components are missed

1: grid layout (row, col)
2: multi level menu in side bar
3: drop-down menu
4: react-select
5: option menu
The mentioned components will  rise up of the betterment of template

HI @EhsanullahQadari ,
We have components that can solve some of your needs
for
Option menu you can use:
<SelectBox />

for Drop Down Menu you can use:
<MenuBar />

Addons Needed

Multi Level menu bar in Side Bar

Will try to build asap.

React Select as we can add a styled Select component

Will add possibly at next release.

Grid layout (row, col)
As This library is indented to provide Components that as composible and mutable.

You can wrap components according to what best suits to the project.

Hi @EhsanullahQaderi ,
I have added some more components:
1: multi level menu in side bar - NavBarSubMenu
2: drop-down menu - MenuBar
3: react-select - Select
I will suggest you to check the docs for the latest version of react-windows-ui.
If still have some queries you can open this issue whenever you want :)


Last update editor disappears and appears in dynamic editing.

After the update to the new version, the editor does not work dynamically with ajax, but it has to be set with a fixed value.
I need to pass the JSON from the api.
Please analyze and review my code so that you can replicate the error, to see what the error is.
On localhost, you have to reload the page several times until it appears, but on the hosting it does not appear at all, at least after 30 attempts.
https://codepen.io/JordanGarciaDev/pen/jENOVQw

#385 and #384 should have the fixes needed and the codepen now loads:


[admin-theme] Fix permission evaluation when building the menu

Fixes #103

Coverage decreased (-0.6%) to 98.773% when pulling 224d00547162a15f4abd5b632e5d7a59660f640c on TDT-AG:tdt-fix-menu into 6107fcd4fc552971fe3e363e64d70b48b2892db2 on openwisp:master.

Thanks @okraits, merged in #123


Silent Setup /ADDLOCAL values (#53)

Silent setup /ADDLOCAL values

Docs Build status updates of commit 88117ce:
:clock10: Pending: waiting for processors (8 builds ahead of you)
:warning: Docs Build is busy, currently there are 8 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 88117ce:
:warning: Validation status: warnings

File
Status
Preview URL
Details

biztalk/install-and-config-guides/appendix-a-silent-installation.md
:warning:Warning
View
Details

biztalk/install-and-config-guides/appendix-a-silent-installation.md

Line 41: [Warning] Cannot find bookmark '#ADDLOCAL-command-values' in 'install-and-config-guides/appendix-a-silent-installation.md'

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit a663821:
:clock10: Pending: waiting for processors (9 builds ahead of you)
:warning: Docs Build is busy, currently there are 9 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.


Implement elections

What would this contain? Is it just a simple container for leaflets?
How about:

name
url - for more information
date range - when it 'starts' to voting day
hashtag - for when sharing

so something like ...
UK General Election 2015
http://en.wikipedia.org/wiki/United_Kingdom_general_election,_2015
30/03/2015 - 07/05/2015
#ge2015
Aside: Do UK elections have a canonical url anywhere?


Enable LTO by default for OSX builds

Commit #1207 turned off LTO as a default. Subsequent
testing by Sendence found a ~ 10% performance
degradation for some operations with the change.
The change was made in order to get the Travis CI
builds working. Not a wonderful trade-off. This change
turns LTO back on by default on OSX and fixes our
Travis issue.
Eventually, Travis should have a compiler that doesn't
have issue with LTO and we can remove the Travis portion
of this.
This fixes issue #1223.

DO NOT MERGE
Travis changes aren't in yet. I want to see what fails and only fix those issues rather than just blindly "fix" ahead of seeing actual failures.

Ok, all 3 LLVM version release builds fail. I'm adjusting Travis to account for that. I assumed that would be the case but wanted to verify.
@ponylang/committer i only updated travis to have lto=no when doing a release build as it only applies there. I'd also consider doing it on the debug builds I don't see a reason to. If anyone has different ideas, let me know.

During testing, I have started getting errors on OSX related to gmp and homebrew. Specifically homebrew not being able to install it. I'm unsure if we need to update anything or if its a travis issue.
Might need to fix that in another commit then come back to this one.

GMP issue:
==> Pouring gmp-6.1.1.mavericks.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink include/gmp.h
Target /usr/local/include/gmp.h
is a symlink belonging to gmp. You can unlink it:
  brew unlink gmp
To force the link and overwrite all conflicting files:
  brew link --overwrite gmp
To list all files that would be deleted:
  brew link --overwrite --dry-run gmp
Possible conflicting files are:
/usr/local/include/gmp.h -> /usr/local/Cellar/gmp/6.0.0a/include/gmp.h
/usr/local/include/gmpxx.h -> /usr/local/Cellar/gmp/6.0.0a/include/gmpxx.h
/usr/local/share/info/gmp.info -> /usr/local/Cellar/gmp/6.0.0a/share/info/gmp.info
/usr/local/share/info/gmp.info-1 -> /usr/local/Cellar/gmp/6.0.0a/share/info/gmp.info-1
/usr/local/share/info/gmp.info-2 -> /usr/local/Cellar/gmp/6.0.0a/share/info/gmp.info-2
/usr/local/lib/libgmp.10.dylib -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmp.10.dylib
/usr/local/lib/libgmp.a -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmp.a
/usr/local/lib/libgmp.dylib -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmp.dylib
/usr/local/lib/libgmpxx.4.dylib -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmpxx.4.dylib
/usr/local/lib/libgmpxx.a -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmpxx.a
/usr/local/lib/libgmpxx.dylib -> /usr/local/Cellar/gmp/6.0.0a/lib/libgmpxx.dylib

grumble grumble

Ok I have a fix for the GMP issue. I'm doing a separate PR for that. I'm going to merge that PR myself after it passes and will then merge into the branch for this PR so we can continue here AND have a clean history.

This is passing now with the GMP fixes in. Which is good.
DO NOT MERGE YET
I need to merge the actual GMP fix, remove it from here, merge the GMP fix into this and then push this again for a last CI run at which point, if it passes, it can be merged.

Merged master in.

When this passes CI, it will be good to merge

Woot!
This is READY TO MERGE
except you know, appveyor... but the actual change is related to travis so... !!!!!


Experiments/test pr

Another test PR

Can one of the admins verify this patch?

ok to test

ok to test


Bugfix/regex does not match ps output on macos

I don't know exactly why, but on Mac OS my output of ps -o state= -o comm= does not contain any characters in the first state column (or rather, all processes have a space here). Some example lines:
❯ ps -o state= -o comm=
 +   tmux
     -zsh
 s   -zsh
 +   docker
 +   /Applications/Docker.app/Contents/Resources/bin/com.docker.cli
 s   -sh
 +   /nix/store/rj7zvmif800bgg3sbznq6g5g438jx104-bash-5.2p37/bin/bash
 +   /nix/store/rppw7g0g21rm1ayrjiflkjagxmkwmnzh-neovim-unwrapped-0.10.2/bin/nvim
 s+  -sh
 s+  -sh
 s   -sh
 +   /nix/store/rj7zvmif800bgg3sbznq6g5g438jx104-bash-5.2p37/bin/bash
 +   /nix/store/rppw7g0g21rm1ayrjiflkjagxmkwmnzh-neovim-unwrapped-0.10.2/bin/nvim
 s   -zsh
 +   ps

This makes the $is_vim regex fail for me on MacOS, even when there is a (n)vim process running within the tty.
Not sure exactly why   (space) is forbidden in the state column like it is (except as a delimeter to make sure only characters until the column end is counted, but I think the rest of the regex already makes sure the can be no mistakes about what data belongs in what column, so I think it should be safe to scrap it). Doing so solves my issues, and vim-tmux-navigator works beautifully again on MacOS (and should do so as well on Linux I believe).
Please test this and master on MacOS and Linux and see if you think it might be an improvement.

I notice that you've got docker in the process list -- I wonder if that's mucking things up? Would you mind testing outside of docker to see if that impacts the output?

I can certainly run a tests without docker running. Though to be clear, the command was not run inside docker, docker merely happened to be running at the same time.

 Looks like it's only doing this for the nix-installed version of ps. Looks like I'll go open a PR in nixpkgs instead...
Sorry to have bothered you with this!


fill_color returns white

Hello,
With the attached xlsx, rubyXL tells me that cell A1 is white filled, whereas it is grey filled.
require 'rubyXL'
require 'rubyXL/convenience_methods'
wb = RubyXL::Parser.parse('a.xlsx')
puts(wb[0][0][0].fill_color)

--> ffffff

Did i missed something?
Thanks and regards
a.xlsx

It's the same for me.

I found same probrem.
It seems that the fill color specified by index (not RGB) is ignored and fill_color method returns 'ffffff'.


HDDS-2451. Use lazy string evaluation in preconditions

What changes were proposed in this pull request?
Use the version of Preconditions.check... that accepts errorMessageTemplate and errorMessageArgs.
There are occurrences of the errorMessage version left, but they do not seem to be important:

use constant message, or
are infrequently used (eg. one-time init in MetadataKeyFilters), or
only append a plain long (container ID) to the message.

https://issues.apache.org/jira/browse/HDDS-2451
How was this patch tested?
Ran related unit tests and checkstyle.

Thanks @elek for reviewing and committing it.


TypeError in /

Error in localweather-io
TypeError in /
undefined is not an object (evaluating 'e.minutely.icon')
View on Bugsnag
Stacktrace
src/js/modules/templates.js:93 -
src/js/modules/ui.js:394 - ne
src/js/modules/ui.js:406 -

View full stacktrace
Created by Michael Sprague via Bugsnag

An error linked to this issue has been marked as fixed in Bugsnag
TypeError in /


Make home directory optional

What current issue(s) does this address, or what feature is it adding?
Not all users will have a home directory, so only attempt to make the ~/.neopython directory if the user's home directory actually exists. Without this check, startup will fail.
How did you solve this problem?
Implemented it.
How did you make sure your solution works?
Tested it on one of our pyapi nodes.
Are there any special changes in the code that we should be aware of?
No.
Please check the following, if applicable:

[ ] Did you add any tests?
[X] Did you run make lint?
[X] Did you run make test?
[X] Are you making a PR to a feature branch or development rather than master?
[ ] Did you add an entry to CHANGELOG.rst? (if not, please do)

Looks good


Run demo

I intended to solve for the "'NoneType' object is not callable" issue by modifying the import part of DCN, but I find this is not a common issue and it's related to the torchvision version. So I withdraw this request and apologize for the inconvenience caused to you guys :)


React 17 peer dependency

React 17 is listed as a peer dependency of react-multi-select-component. With NPM 7, peer dependencies are now installed by default. In the case of my React 16 app, this results in:
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving<EMAIL_ADDRESS>npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/react
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer react@">=17" from<EMAIL_ADDRESS>npm ERR! node_modules/react-multi-select-component
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!

Does the peer dependency need to be React 17 or can the React version be lowered?
(Thanks for considering.)

I guess 16+ should be fine, I'll downgrade peer dependency to 16+

Thanks!

@justinlittman I have published v4.1.12 that should allow react 16+ as well
also updating all dependencies to 17+ is highly recommend :smile:


Embedded dags - handling deployments

I have just got Airflow working on K8 through the help of this great project, thanks!
I had a question about the embedded DAG's approach. In the event of a deployment or a pod being rescheduled by K8, how would a running DAG survive the process?
Or is the answer quite simply it wouldn't and it would need to retry?
Any other wise words on having a reliable Airflow on K8 are welcome

I can assume this question has been answer at some where. but still looking for an answer.


Adding to quicklisp-dist

Can this library be added to quicklisp?
I've another project polymorphic-functions that I intend to add to quicklisp this month. But it depends on ctype, so ctype would also need to be added.
So, if there are no issues to adding this library to quicklisp, then me or someone could create the issue on quicklisp-projects.

I can't think of any reason not to. I'll file an issue.

Oh, I need to slap a license on it. Would you have any problem with CC0 (https://creativecommons.org/publicdomain/zero/1.0/)?

It seems like CC0 is not recommended for software and BSD2 is almost the same as MIT. So, I definitely do not have any issue with BSD2; compatibility with Eclector helps as well.

ctype does not include anything patented, so that's not really relevant, but i'll just do bsd2

https://github.com/quicklisp/quicklisp-projects/issues/2094


Update the doc of InteractiveBrowserCred and DeviceCodeCred

Update the doc of InteractiveBrowserCred and DeviceCodeCred to state that the best practice is for users to perform their own app registration and role assignment rather than relying on the default value.
Python PR: https://github.com/Azure/azure-sdk-for-python/pull/36308

Fixed in #41396


removed: Updated command from apps workload plugin

Pull request

What this PR does / why we need it
The update sub-command of tanzu apps workload was deprecated and now is being removed
Which issue(s) this PR fixes

Fixes #539
Describe testing done for PR

Local test (make install)
Additional information or special notes for your reviewer

Workload help message without update

Workload help message when update

Please change the commit message to something like removed: Delete "tanzu apps workload update" from apps plugin subcommands, the actual message is a bit unclear. Thanks


Allow for retrieving the index of a SOP constructor

Helios folks propose to introduce a builtin allowing one to get i from Term.Constr i args.
Their reasoning is that sometimes one only needs to check whether the constructor is a specific one, instead of providing a branch for every single constructor. E.g. if you have a big sum type like
data D = C1 | C2 | C3 | C4 | <...> | Cn

then you can define equality checking for such a type in linear amount of matches in, say, Plinth:
C1 == C1 = True
C2 == C2 = True
<...>
Cn == Cn = True
_  == _  = False

but on the UPLC level this will give you a quadratic number of branches, because for each Ci to the left of == you'll need to explicitly handle all of C1 ... Cn, because a case has to explicitly handle all possible constructors and there's can't be a catch-all clause.
There's a number of issues with the proposal, though. Firstly, what if those C* constructors carry some arguments? How will we extract them out of there if we only know the index of the constructor?
Secondly, such a builtin would break parametricity, it's the same issues as we relentlessly discussed in the equalsCanonical PR and in #5776 + #6225. I.e. we've already given up on important things because of the parametricity issue, so it's unlikely we're going to revert on that just for the purpose of having a builtin returning the index of a SOP.
Now given that SOPs are basically on par with builtins and we seem to have a plan on making Data as fast as SOPs, do we even need to worry about SOPs at this point? Maybe it'll turn out that just having fast Data is enough? Sure you can't put functions into Data and such, but does anybody actually care about that? Anyway, I digress.
What we could have is case with a default clause. That'd solve the equality issue described above. Helios folks claim it's not enough in the general case though:

The default case would solve the issue for some common patterns, but having access to the index  is still needed for the most extreme cases

so naturally I wonder what those extreme cases are.
But let's say that instead of introdcing a basic default clause, we introduce a fancy default clause giving you access to the index of the constructor. It's gonna be a bit weird, because the AST doesn't know anything about integers, but let's say we'll pull it off somehow. Would it be good or weird? It's pretty much reflection at this point and UPLC wasn't designed with any reflection capabilities in mind, so maybe that'll screw the metatheory up somehow?
Anyway, I'll mark this as low-priority, because speeding up Data is far more important, but now that Helios folks told us about this problem I do find the lack of default clauses unfortunate, so maybe we should do something about it.

@effectfully Thanks for taking the time to write this up. We are very appreciative of the time you have personally spent to help bring more utility to SOPs.
It's fair that you mark this issue as low priority, making Data faster will indeed provide much more utility.
I wouldn't completely write off SOPs yet though, as they do have their use-case: efficient multiple branches.
On X I mentioned two issues that could be solved with a builtin that can retrieve the case index:

comparing the index
combining multiple SOPs efficiently

1. comparing the index
Without such a builtin function, it will be easier to keep using Data
2. combing multiple SOPs efficiently
This is easier to discuss with an example, typically seen in real-life Helios code.
Assume we the following enum:
enum State {
  A {<fieldsA>}
  B {<fieldsB>}
  C {<fieldsC>}
}

We want to compare the state of a given UTxO being spent with the state of the return UTxO: so state0 vs state1. These states will be stored in the Datums, so are initially in Data format (so State::A will be encoded as ConstrData(0, <fieldsA>), State::B as ConstrData(1, <fieldsB>), etc.)
Let's assume we have the following valid state evolution:

A can become A or C
B can become B or C
C can become A or B

The equivalent in code:
(state0, state1).switch{
  (A, A) => {<branch1>}
  (A, C) => {<branch2>}
  (B, B) => {<branch3>}
  (B, C) => {<branch4>}
  (C, C) => error("illegal state change")
  (C, _) => {<branch5>}
  (_, _) => error("illegal state change")
}

If the State is kept as Data such a branching expression is easy to generate using multiple nested ifThenElse calls that compare the ConstrData tags. This approach is not efficient, requiring many UPLC terms.
Without default case (current situation)
If the State is first converted to SOP, using constr(fstPair(unConstrData(State)), sndPair(unConstrData(State))), we would end up with the following UPLC AST:
case(
  state0AsSOP,
  (fieldsA0) -> {
    case(
      state1AsSOP,
      (fieldsA1) -> {
        <branch1>
      },
      (fieldsB1) -> {
        error("illegal state change")
      },
      (fieldsC1) -> {
        <branch2>
      }
    )
  },
  (fieldsB0) -> {
     case(
      state1AsSOP,
      (fieldsA1) -> {
        error("illegal state change")
      },
      (fieldsB1) -> {
        <branch3>
      },
      (fieldsC1) -> {
        <branch4>
      }
    )
  },
  (fieldsC0) -> {
    case(
      state1AsSOP,
      (fieldsA1) -> {
        <branch5>
      },
      (fieldsB1) -> {
        <branch5>
      },
      (fieldsC1) -> {
        error("illegal state change")
      }
    )
  }
)

Although this particular example doesn't seem so extreme, you should imagine many more variants, which makes the generated code blow up with many duplicate branches.
In summary: we currently consider SOPs only viable for branching over a single ConstrData value, which has been converted using constr immediately before the branching expression.
With default case (proposed by @effectfully)
I'm assuming the last case would always be used as the default. This wouldn't improve anything for this example because there is no situation where 2 or mores final branches are the same.
So for this example implementing a default case isn't worth the effort.
With a builtin that can retrieve the case index
We would be able to keep the State in this example as SOP throughout the code-base, and simply fallback to nested ifThenElse calls for multi-valued branching situations.
Other ideas
If SOP constr/case are only used for efficient branching, maybe it makes sense to implement a variable-args version of ifThenElse instead?
The arguments of such a term could also be implicitly delayed:
varArgsIfThenElseTerm(<cond0>, <case0>, <cond1>, <case1>, <cond2>, <case2>, <default>)

I also think this would be greatly beneficial to languages with advanced pattern matching syntax like Aiken.
Though to be honest I think this is too high-level for UPLC.
Conclusion
SOPs can currently provide some benefit in only a few situations. Are there other situations that I hadn't thought of?
Sorry for being frank, but maybe SOPs aren't worth the complexity they introduce to the CEK machine, and should be removed for UPLC version 4.

I wouldn't completely write off SOPs yet though, as they do have their use-case: efficient multiple branches.

Yes, but this is exactly what I want to bring to Data: #6602

This is easier to discuss with an example, typically seen in real-life Helios code.

Thanks a lot for providing the example, I agree with your assessment that my idea as written of using the default case is basically useless.

With a builtin that can retrieve the case index
A function for retrieving the constr args would also be needed though.

Well, as I'm arguing in the issue description, such builtins have never made it past peer review. Given the relative unimportance of SOPs, I doubt this time would be any different.

Sorry for being frank

Frankness is always appreciated, we're very much interested in users providing honest feedback as that allows us to improve the product.

maybe SOPs aren't worth the complexity they introduce to the CEK machine

I've been gravitating towards the same conclusion. If we can make Data as efficient as SOPs and point people towards Scott-encoding as a fallback solution when putting functions into data types is necessary, then SOPs are perhaps not worth having. But that would only remove the Constr node from the AST, not the Case one (as the latter is gonna be used for Data and other builtins), so it's not like we'd save much. It may be just easier to keep SOPs in the AST anyway, since maintaining them doesn't take much effort. Dunno.
Anyway, we are very much focused on making Data universally better than SOPs, so I'm not just saying these things to avoid improving SOPs.

The branching functionality of SOPs could simply be replaced by allowing builtin lists to contain lambdas

Probably not gonna happen, because it's hard to fit into the current design of UPLC. And if it did, everybody would start complaining that now you can have a list of Integers and a list of terms wrapping Integers, which are two different AST representations for semantically the same thing. Complain like this:

also agree with @nau that we should use either only Data or only SOPs. As SOPs were never able to provide a complete alternative to Data we are now in this awkward situation where we mix both for only minor benefit.

:stuck_out_tongue:
Thank you for this discussion, it really helped me to start disliking SOPs more :slightly_smiling_face:


rendering is not smooth  in scrcpy on 60fps  . i have noticed .. motion blur is not there mirroring

If you record, then play, is it better?
If you show the FPS in the console (press Ctrl+i in the scrcpy window, look at the logs in the console), what happens? (move things randomly on the screen so that the screen keeps updating at a maximum frame rate)

@rom1v  recording not have these problem... but this problem is with live time rendering .. try to to understand there is with your renderer
https://github.com/barry-ran/QtScrcpy @rom1v use this modded scrcpy ..you will understand my point. this modded scrcpy is smoother than original scrcpy .. plzz understand my point

Which version of scrcpy do you use?
Try with a different version of SDL (see #425).

@rom1v i use 1.12.1 scrcpy .  i am talking about g sync and smoothness
in scrcpy .. hope you will understand ..

@rom1v  use this  https://github.com/barry-ran/QtScrcpy ... and play any 60 fps game in mobile you will understand ..plz its will improve you scrcpy project.

https://github.com/barry-ran/QtScrcpy
Can you use this opengl renderer instead of sdl renderer plzzz ..?

SDL uses OpenGL on Linux, Direct3d on Windows, etc.
https://wiki.libsdl.org/SDL_HINT_RENDER_DRIVER
Which platform do you use?
Could you please enable FPS loggkng in the console: https://github.com/Genymobile/scrcpy/issues/1077#issuecomment-573334056

@rom1v I also has this issue while playing a test video clip at 60 fps, I noticed that frame drop on Window10 with i5 PC connecting with USB.
I understand that Android Q together with v1.12.1 could change the fps on encoder side.
However, my project hardware is fixed at Android-9 and cannot be changed.
Will it be possible to change the code on Server side myself to fixed at 30fps ?
Thanks so much.

@dilbert168 yes, https://github.com/Genymobile/scrcpy/issues/488#issuecomment-567439415

Can i use a type-c (android)to type-c (laptop) to use scrcpy

Probably, as soon as adb detects your device, it should work.


Typo: expecter->expected

Small typo; hoping to get this in as a breaking change since it's only two weeks since the flag was added.

LGTM


[Feature Request]: enhance accuracy of min/max statistics

Provide a clear and concise description of what the problem is.
When fetching raster data for statistical analysis, we submit a WCS GetCoverage request with a height and width given.  Limiting the size of the generated GeoTIFF helps protect the server from running out of memory and also ensures a timely response.  However, this can lead to inaccuracies when calculating the extreme values (min or max).  WCS servers (e.g. GeoServer and Open Data Cube) generally use nearest-neighbor interpolation in order to generate the resampled tiff.  If the pixel with the highest or lowest value happens not to be in in the sampled pixels, the the statistical result will be in accurate.  The degree of this inaccuracy will depend on how many pixels have these extreme values.  For example, weather values are generally distributed smoothly and continuously (without large abrupt changes) and therefore are more resistant to these issues.  However, values that depend on landcover could experience larger changes between neighboring pixels and are more susceptible to issues with nearest resampling.
Provide a clear and concise description of what you want to happen.
Action items could include:

determining the level of effort required to add min/max resampling/interpolation to the WCS services that we use (this might require upstream contributions)
assessing adding a configuration option, so we can change the resolution of the requested GeoTIFF depending on the type of calculation
assessing pros/cons for creating lower resolution products that are generated using different resampling algorithms.  For example, we could pre-generate a lower-resolution Cloud-Optimized GeoTIFF using gdal with min resampling.  We would then upload this GeoTIFF to our WCS service and use that one for min calculations.

Is there anything else you can add about the proposal? You might want to link to related issues here, if you haven't already.
No response

Thanks for raising this @DanielJDufour. Another thing to consider is that we recently added STAC support to WFP's Data Cube deployment, which is the primary source for raster data in PRISM. We can now download a GeoTIFF via STAC (see PR https://github.com/WFP-VAM/prism-app/pull/669) but we haven't yet used STAC for stats. I created an issue around this a while ago: https://github.com/WFP-VAM/prism-app/issues/644
Have you worked with STAC? I'm hoping there are methods through the STAC API to address this. Let me know what you think!


Questions related to map_replanner_node

Hello Sikang, I am trying to understand the map_replanner_node and I had the following questions related to it.

By using subscriber callbacks addCloudCallback() and clearCloudCallback(), we are updating the map as the bot is moving. Now, if we use the traditional local_planner/global_planner framework of ROS, we use the Lidar data to update the localmap in odom frame and the local trajectory is planned in the odom frame. But according to your code, it looks like addCloudCallback() and clearCloudCallback() is working in the global frame and updates the global map. So if I use my Lidar data, it would have to be transformed from base_frame ->odom_frame->map_frame before updating the map. Is my understanding correct ?

What topic should clearCloudCallback() subscribe to ? It is obvious that addCloudCallback() would subscribe to the Lidar pointcloud to update the map in it's surrounding based on it's range. What about clearCloudCallback() ? Shouldn't both callbacks subscribe to the same Lidar data topic?

What is the use of subtreeCallback() ?

At what rate is the replanner running ? It looks like planning thread is being run separately.

Thank you.

Hi, sorry for the late response. The map_replanner_node is something else instead of just ``replanner'', it is an implementation of LPA* that is used for incremental trajectory planning. Comparing to replan from scratch every time, it is computationally more efficient to keep the related parts of the old graph and update the corresponding edge costs according to the map update and further plan the trajectory based on the new graph. So the function in this node is actually designed for this planning method:

it is assume the map_frame is not changing, so everything should be in the global map frame;
clearCloud and addCloud are actually some test function for removing and adding points in a map;
subtree is used to prune the old graph and get the sub-graph;
the rate depends on the edge duration `dt', eg. 1/dt Hz.
Since it is not a traditional replanner, I would not recommend to use it for normal replan. A easier way is to replan from scratch every time.

SIkang


HOSTESS_PATH environment variable does not change target file

Specifying the HOSTESS_PATH environment variable does not change hostess' behavior; it still edits /etc/hosts .
To reproduce, set HOSTESS_PATH to point to a different hosts file. execute hostess commands. /etc/hosts is changed instead of the specified file.

Thanks for the report. This is working for me:
$ HOSTESS_PATH=./hosts hostess ls
open ./hosts: no such file or directory

Can you show how you're invoking this and tell me which platform you're using?

Sorry, had failed to export the var, i.e. "export HOSTESS_PATH=file" .. once I did that, it worked as expected. Thank you!

Glad you got this working! Thanks for following up.


Consider all products in response

Most important change:

           for type_ in dashboard_data['product'][0]['measurement']:

       for product in self.get_dashboarddata().get('product', []):

Coverage increased (+1.96%) to 100.0% when pulling fd988875a98ea07b88283cbfcc7626d9b7a859a2 on marthjod:master into 09c6280e69ecc39b7d8eea52d32b2f46edb35d61 on nmesstorff:master.


Support for "full_clone" and "firewall" properties

This fork adds support for the full_clone property so that thin clones can be provisoned for nodes.
It also adds the firewall property so that the firewall may be disabled on the network interface of the nodes.

Unresponsive owner, will fork for good.


I would like to filter events by message or details content

Feature Request
Describe the feature
Currently the events can be filtered by the name of the event.
It would be useful to be able to filter based on the message or details contents as well.
I would like to see a select/dropdown field that allows selecting of the Name, Message, or Details to apply the filter.

This feature has been implemented by PR #6


feat(#262) Set room attributes

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Please provide enough information so that others can review your pull request:

Explain the details for making this change. What existing problem does the pull request solve?

Test plan (required)
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.

Closing issues
List all issues this PR resolves.

closes #XXXX

Pre-Merge checklist
Complete these items before requesting reviews

[ ] Static Analysis Rules Validated
[ ] All commits follow naming conventions

Sub-tasks Checklist

[ ] UI Implementation
[ ] UI Test
[ ] Backend Implementation
[ ] Backend Tests
[ ] Integration Tests
[ ] System Tests
[ ] Documentation

I think you'll need to update the tests in UpdateRoomForm.vue. It's currently giving a 5.9% code coverage on the new code.

I think you'll need to update the tests in UpdateRoomForm.vue. It's currently giving a 5.9% code coverage on the new code.


Cranelift: improper handling of shadow store for winx64 calling convention

What are the steps to reproduce the issue? Can you include a CLIF test case,
ideally reduced with the bugpoint clif-util command?

repro.clif:
set opt_level=speed_and_size
set is_pic
target x86_64 haswell

function %foo() windows_fastcall {
    fn0 = %bar(i64)
    ss0 = explicit_slot 8
block0:
    v1 = stack_addr.i64 ss0
    call fn0(v1)
    return
}

$ clif-util compile -D repro.clif

What do you expect to happen? What does actually happen? Does it panic, and
if so, with which assertion?

Actual output:
.byte 85, 72, 137, 229, 87, 72, 131, 236, 40, 72, 141, 132, 36, 0, 0, 0, 0, 72, 137, 199, 232, 0, 0, 0, 0, 72, 131, 196, 40, 95, 93, 195

Disassembly of 32 bytes:
   0:   55                      push    rbp
   1:   48 89 e5                mov     rbp, rsp
   4:   57                      push    rdi
   5:   48 83 ec 28             sub     rsp, 0x28
   9:   48 8d 84 24 00 00 00 00 lea     rax, [rsp]
  11:   48 89 c7                mov     rdi, rax
  14:   e8 00 00 00 00          call    0x19
  19:   48 83 c4 28             add     rsp, 0x28
  1d:   5f                      pop     rdi
  1e:   5d                      pop     rbp
  1f:   c3                      ret

Note the instruction at offset 9 that is loading the address of the explicit stack slot: lea rax, [rsp].  The address loaded is actually inside the callee's 32 bytes of shadow space.
I expect this instruction to actually account for the calling convention's shadow space: lea rax, [rsp+0x20].
Because of how we're currently saving callee-saved FPRs, we're actually saving the FPRs into this area of the stack as well, meaning that the callee might trash the caller's saved FPRs as they're allowed to use this space freely.
Because Cranelift itself doesn't make use of the caller-provided shadow space, this won't happen for Cranelift-to-Cranelift calls; however, calling into external functions will certainly make use of the shadow space.

Which Cranelift version / commit hash / branch are you using?

26e06297957bbc06b3244bc96d2e92b4246e8d9b

If relevant, can you include some extra information about your environment?
(Rust version, operating system, architecture...)

Rust: 1.43.1
Operating system: Arch Linux
Arch: x86-64

Note that I'm currently in the process of fixing where we store callee saved FPRs as they should not be stored as explicit slots.


Allow specifying electron-prebuilt-compile via URL

Preflight Checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project follows, as appropriate.
[X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description
As discussed in https://github.com/electron-userland/electron-packager/issues/909 the requirement to specify electron-prebuilt-compile as a semver string in package.json makes it difficult/impossible to use one's own tarball instead (especially important as electron-prebuilt-compile appears to be dying). This was partially addressed by https://github.com/electron-userland/electron-packager/pull/932 but that code still attempts to parse the version string.
Proposed Solution
Wrap the call to new semver.Range(electronVersion) in a try  ...  catch and if it can't be parsed then attempt to resolve it like we normally do instead of blowing up. I have done this in my fork here:
https://github.com/electron-userland/electron-packager/compare/master...jacobq:support-alternative-epc-version-strings
Alternatives Considered
When semver fails to parse the version string we could try searching it for a simple dot-delimited version number. For most npm tarball URLs this will produce the right version number, but it is merely by coincidence and won't necessarily work with git repository references, etc.
Additional Information

I appreciate the time you've taken to write this up, but I don't think this is the right solution.
For your specific use case, Electron Packager is not the right level at which to solve this problem. If you weren't using Electron Forge (v5), I would just tell you to programmatically set the electronVersion option instead of trying to change the infer code do something that a very small percentage of users will actually need.
Since you're using Electron Forge v5, I would say that there could be some code added to getElectronVersion to support scoped forks of Electron/electron-prebuilt-compile modules, but that is a topic best suited for the Forge issue tracker, not here.

Yes, once electron-forge v6 is released/stable this shouldn't be needed any more, and it's fine if you don't want to go this route (I can use the fork in the mean time).
Still, I don't understand why it isn't considered a bug that specifying a valid electron-prebuilt-compile dependency (URLs are allowed by npm) whose version is easily resolvable through your existing mechanism causes an exception to be thrown.
Another solution I should've mentioned would be to drop support for versions of electron-prebuilt-compile that aren't resolvable in the usual way.

I was reading this in the context of a feature request. Looking at it again, yes, it's a bug that Electron Packager isn't ignoring the cases where electron or electron-prebuilt-compile refers to a URL or path instead of a version range.

I was reading this in the context of a feature request.

My fault: that is how I filed it. Thanks for fixing. I'll try using the v14-develop branch instead of my fork.


Complains that port is in use when running multiple processes on multiple ports

I have a broccoli (broccoli serve) on port 4200. If I try running a second instance with broccoli server -p 4700, it works like it should, starting a second instance and binding to port 4700, but it has the following output
╰─$ broccoli serve --port 4700                                                                  1 ↵
Serving on http://<IP_ADDRESS>:4700

... Uhoh. Got error listen EADDRINUSE ...
Error: listen EADDRINUSE
    at errnoException (net.js:901:11)
    at Server._listen2 (net.js:1039:14)
    at listen (net.js:1061:10)
    at Server.listen (net.js:1127:5)
    at Server.listen (/Users/dan/Projects/highways/frontend/node_modules/broccoli/node_modules/tiny-l
r/lib/server.js:138:15)

(Stacktrace truncated)
As soon as I stop the instance on 4200, starting the instance on 4700 works without errors. My guess is that it always checks port 4200, regardless of the port option passed in. If I wasn't on the train, I would dig into the code :smile:

This is no longer an issue with this lib


fixed 'package not in GOROOT' errors

fixes #47

more info in the comments https://github.com/nutel65/gobfuscate/commit/3c4bd6c03e9c2a095aabe42a4ce86fa768b5828b


Embed asciinema player

Will do this in the other (SAP) repo, as recordings are not used in this content.


Move types into higher dimensions

Is there an easy way to move a type to a higher dimension easily? For example:
            use na::{Isometry2, Translation2, Unit, Vector2};

            let position_vector =
                position.radius * Vector2::new(position.angle.cos(), position.angle.sin());

            let isometry = Isometry2::new(position_vector.into(), position.angle);

Is there an easy way to turn isometry into an Isometry3?

No, this is not possible since we can't predict how the 2D space represented by Isometry2 is embedded into the 3D space represented by Isometry3. For example, should the 2D rotation corresponding to a 2D rotation on the x,y plane, the y,z plane, or another plane not aligned with any coordinate axis ?
Perhaps we could add a method taking extra arguments (like the normal of the plane on which it is embedded), by I think it is easier for the user to simply do, e.g, Isometry3::new(iso2.translation.vector, normal * iso2.rotation.angle()).

I think it is easier for the user to simply do, e.g,  Isometry3::new(iso2.translation.vector, normal * iso2.rotation.angle())

This doesn't seem quite right. The type of iso2.translation.vector will be a Vector2, not a Vector3 (which is what Isometry3::new expects as its first argument).
I've been performing this conversion like this:
Isometry3::new(
  Vector3::new(isometry2.translation.vector.x,
               isometry2.translation.vector.y, 0.),
  isometry2.rotation.angle() * Vector3::z_axis().to_superset());

(If there's a more elegant way to write that first argument, I'd love to hear it.)


[Multi-Actions] [Process] Experiment with schema inference

Plan is to infer schema from instructions.

Experiments show it works: https://dust.tt/w/0ec9852c2f/a/e78221440d


feat Add option to config file to enable or disable analyze function

Proposed changes
Add this option in conf:
/**
 * If set false, user couldn't submit analyze SQL and FE won't allocate any related resources.
 */
@ConfField
public static boolean enable_stats = true;

It will be checked during analyze of analyze related stmt and init analyze manager
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

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

run buildall


Pre tags render even when the 'content' attribute is missing

In the above the pre tags are rendering irrespective of whether there is content or not, this should be a simple amendment to the partial rendering logic

Opened PR #210

Closed by PR #210


An Org Scope Input

@stubbornella @rockbot thoughts?

I wonder if the "@" symbol would be read by screen readers as CSS content?

Otherwise, looks good.

VoiceOver doesn't read it, but I explicitly put a speak: none in there as well.


Added support for media queries

Hello,
I've tried my chance at adding support for media queries. In our project we're disabling hover states when the pointer does not support hover.
So basically this code:
@media (hover: hover) and (pointer: fine) {
  .self:hover {
    background-color: gray;
  }
}

gets rewritten into:
@media (hover: hover) and (pointer: fine) {
  .self:hover, .self.pseudo-hover, .pseudo-hover .self {
    background-color: gray;
  }
}

But this should also work for multiple rules and other media queries
I haven't written the tests yet, as I wanted to know what's your feedback on it, whether this is actually correct. With the tests I would also need to provide the structure for CSSMediaRule, so didn't bother for now.
I don't want to keep a forked version of the library so looking for review 🙏🏻

I encountered a similar problem in one of my projects. We used media hover to determine if the current device supports hover or not. This approach was dictated by a specific problem: using a hover effect on mobile devices causes buttons to stay stuck in the hovered state when tapped and sometimes it can be really confusing.
Here is an example - https://codepen.io/dansitnikov/pen/eYbOBMY (you can play with it on mobile and desktop devices)
Adding support for "media query" will be really helpful


Count recorder counting calls across type rather than per mock instance

When I have multiple mocks of a specific type in my unit test, and I want to verify calls on each of the individual mocks, the call counts for each individual mock instance are incorrect as they are the sum of calls across all the mock instances of that type. Looking at the fflib_ApexMocks and fflibMethodCountRecorder classes I can see the call recordings are aggregated on a per type basis rather than recording calls per instance.
Of course I can get round this by creating separate fflib_ApexMocks instances and having the separate mocks I wish to verify counts on use their own individual fflib_ApexMocks instance but the behaviour of aggregating call counts on a per type basis rather than counting calls separately for the individual mock object instances seems wrong.

Guess with Apex you can't use memory addresses to uniquely identify mocked instances. Perhaps the fflib_ApexMocks could have some unique ID generator method (e.g. an incremented integer on each call) for the mock objects, and the generated Mock classes could have their constructors call the fflib_ApexMocks arg instance to assign itself an ID for use with method count recorders?

I think the === operator should be able to help with this. @frup42 whats your thoughts on this use case?

If fflib_QualifiedMethod had its member variable String typeName replaced by a member variable Object mockInstance, and the equals() method implementation used === on the mockInstance comparison then that could be an alternative solution.
I guess the hashCode() implementation wouldn't want to call hashCode() on the mockInstance member (especially as this method could be implemented in the generated mock class resulting in null pointer exception if the test hasn't mocked a return value for the method), perhaps it could include the type name of the mocked instance instead in the hashcode calculation.

On the subject of mocks overriding equals/hashcode (if it implements an interface with equals and hashcode), it looks like the recordMethod() in fflib_MethodCountRecorder will fail in the case where the methodArg argument has in its list of objects a mock which has an overridden equals method generated in the generated mock class code.
In this scenario the methodCountByArgs.get(methodArg) call in recordMethod() will call the overridden equals method in fflib_MethodArgValues, which in turn will call the mock instance's equals method which then results in a call back to the fflib_MethodCountRecorder recordMethod() method and we will end up in an infinite cycle of method calls (up till an inevitable crash happens).
I shall raise this as a separate issue to this one.
Perhaps the fflib_MethodArgValues class could do something clever to wrap mock objects and have wrapper implementing equals using referential === for mocked instances to avoid this problem (would need the code generator to make the generated mock classes implement some no-method fflib interface to identify the instances as being an fflib generated mock class for this I imagine).

It's definitely more correct to handle each mock independently.
It could be a breaking change, if existing tests rely on shared stubbing and invocation counts... but you can't make a correct omelette without breaking a few tests.
The most intuitive model would be for each mock to store its own invocation counts, and stubbed return values. But it's a fairly major overhaul.
Instead, I would suggest creating a TokenProvider to generate a unique token for each Object instance, which can be used in the existing ApexMocks map keys.
public class TokenProvider
{
    //List of objects we've provided tokens for.
    //The element index is acts as the token.
    private static List<Object> tokenAllocations = new List<Object>();

    private Integer getToken(Object o)
    {
        for (Integer i=0; i<tokenAllocations.size(); i++)
        {
            if (o === tokenAllocations[i])
            {
                return i;
            }
        }
        tokenAllocations.add(o);
        return tokenAllocations.size() - 1;
    }
}

Should be fixed by #42


TrackedRenderPass internal tracking state reset

Objective
Fixes https://github.com/bevyengine/bevy/issues/13225
Solution
Provide function to manually invalidate TrackedRenderPass internal state.
Testing

Tested by calling set_bind_group on RenderPass returned by TrackedRenderPass::wgpu_pass and checking if in later set_bind_group calls on TrackedRenderPass correct bind group is restored.

@fintelia could I get your review here?

This change looks plausible to me, but I'm not familiar enough with the surrounding code at this point to have much confidence.
The one suggestion I have is that it might make sense to have wgpu_pass always reset the tracking. It would be way less error-prone that way, and it would take a very particular set of circumstances for that not to be the desired behavior.

Applied @fintelia suggestion.

Ping @IceSentry


Fix !mock for channels

!mock currently only works in DMs. Make it work in channels. pls

related to #281

!mock works fine on the uqcstesting server (which may relate this to #432).

Also, this may or may not be relevant:

ERROR:uqcsbot.api:Slack API error calling conversations.history with kwargs {'channel': 'C1HQ3M0C9', 'limit': 7}: missing_scope


Feature: Lottery Factor Chart

Suggested solution
Overview
We want to build a lottery factor chart for our repo pages, so that users can see who the most active contributors are (based on commits) and the % of their contributions over the total.

Endpoint
We have an existing /v2/repos/lotto endpoint that returns a list of lottery factor contributors that can be used to populate this chart
{
  "all_contribs": [
    {
      "contributor": "nickytonline",
      "count": 34,
      "percent_of_total": 0.3269230769230769,
      "lotto_factor": "high"
    },
    {
      "contributor": "brandonroberts",
      "count": 29,
      "percent_of_total": 0.27884615384615385,
      "lotto_factor": "high"
    },
    ...
  ],
  "all_lotto_factor": "high"
}

The Barchart
The goal is for users to put in perspective the contributions of the lottery factor contributors vs the rest of the community.
To achieve this, the metric for the barchart should be the percentage_of_total field on the endpoint, and the chart should:

Show the contributors that make up to 80% of the contributions, and then the rest of the community grouped

BUT, if there's more than 5 contributors that have made 80% of the contributions:

Show only the top 5 contributors + the rest of the community grouped

The reason behind this is to avoid crowding the chart too much.
Two examples of what the bar chart would look like for two different repositories (see color code in next section):

Color Code

The insight subtitle

This looking real nice

For the bar chart you can pull code from the languages chart I built a while back. https://design-insights.netlify.app/?path=/docs/components-graphs-most-used-languages-graph--docs


Using Rapidoc styles inside the slots

Hi,
first of all I want to thank you for maintaining this amazing library!
I was adding a button inside a slot and my question is if there's a way  to use the same styles that RapiDoc it's using for the buttons, etc:

Thanks!

if the goal is to achieve a single style for all buttons then I suggest to use css-parts
for example the below style will change all the buttons border-radius inside rapidoc
you can also individually style or change various sections and UI elements to your need
read about it here https://mrin9.github.io/RapiDoc/css-parts.html
<html>
  ...
  <style>
    rapi-doc::part(btn){ border-radius: 15px; }
  </style>
  <rapi-doc  spec-url = "https://petstore.swagger.io/v2/swagger.json"> </rapi-doc>
  ...
</html>

here is the result of above styling

Hi @mrin9,
sorry if my explanation was not good enough, but the goal was to create a custom button inside a slot space that has the same styling as the rapidoc default buttons.
In my example image I want to achieve that "Download PDF" button has the same style as "Download OpenAPI spec"

No that wont be possible, you cannot extract out the styles from a web-component. there is a hard encapsulation there, instead you can override them with yours


Removed CardView from Tracks

Changelog:

Removed CardView form tracks list. (As per material guidelines, similar content should not be displayed in a card view. Normal list should be displayed.)
Few Typos, and layout naming.

@creativepsyco Please review.

HI @batraabhishek. Please squash the commits into one.

:+1: looks fine.
Just need squashing of commits.

@batraabhishek Resolve conflicts please


[stable/redis] Update labelling strategy

What this PR does / why we need it:

Update home in Chart.yaml to use https://
Update labels, using named templates, to be in line with current best practices. Major version bump, due to the scope and potentially breaking changes.

https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
https://docs.helm.sh/chart_best_practices/#standard-labels
See discussion here: https://github.com/helm/charts/issues/7726

Checklist

[x] DCO signed
[x] Chart Version bumped

/assign @juan131

Should we discuss this during the next meeting? https://github.com/helm/charts/pull/7696 has been closed due to lack of activity.

I could join the discussion on 11/29.


When the parameter changes, public_inputs remain unchanged

BASEDIR=test-vectors RUST_LOG=info ELF_PATH=/mnt/data/xander/test/test_proof/hello_world_mips1.22 SEG_OUTPUT=/tmp/output SEG_SIZE=262144 ARGS="123456 321" cargo run --release --example zkmips split
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.25s
     Running `target/release/examples/zkmips split`
[]string{"123456", "321"}
result 39629376

BASEDIR=test-vectors RUST_LOG=info SEG_FILE_NUM=2 SEG_FILE_DIR=/tmp/output SEG_SIZE=262144 cargo run --release --example zkmips aggregate_proof_all
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.25s
     Running `target/release/examples/zkmips aggregate_proof_all`
[2024-06-17T07:01:19Z INFO  zkmips] Process segment 0
[2024-06-17T07:01:22Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 21030 cycles
[2024-06-17T07:01:23Z INFO  zkm::generation] CPU halted after 283174 cycles
[2024-06-17T07:01:24Z INFO  zkm::generation] CPU trace padded to 524288 cycles
[2024-06-17T07:01:24Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 141876, cpu_len: 524288, poseidon_len: 42058, poseidon_sponge_len: 42058, logic_len: 17928, memory_len: 2714935 }
[2024-06-17T07:02:41Z INFO  plonky2::util::timing] 81.7848s to prove root first
[2024-06-17T07:02:41Z INFO  zkmips] Process segment 1
[2024-06-17T07:02:44Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 27222 cycles
[2024-06-17T07:02:44Z INFO  zkm::generation] CPU halted after 131428 cycles
[2024-06-17T07:02:45Z INFO  zkm::generation] CPU trace padded to 262144 cycles
[2024-06-17T07:02:45Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 41320, cpu_len: 262144, poseidon_len: 54442, poseidon_sponge_len: 54442, logic_len: 4941, memory_len: 2427913 }
[2024-06-17T07:03:43Z INFO  plonky2::util::timing] 62.6836s to prove root second
[2024-06-17T07:03:45Z INFO  plonky2::util::timing] 1.2870s to prove aggression
[2024-06-17T07:03:47Z INFO  zkmips] proof size: 412845
[2024-06-17T07:03:50Z INFO  zkmips] build finish
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote common circuit data to common_circuit_data.json
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote verifier data to verifier_only_circuit_data.json
[2024-06-17T07:03:55Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote proof to proof_with_public_inputs.json
[2024-06-17T07:03:55Z INFO  plonky2::util::timing] 204.8115s to prove total time

public_inputs in proof_with_public_inputs.json
"public_inputs":[3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85,3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85]}

BASEDIR=test-vectors RUST_LOG=info ELF_PATH=/mnt/data/xander/test/test_proof/hello_world_mips1.22 SEG_OUTPUT=/tmp/output SEG_SIZE=262144 ARGS="123 321" cargo run --release --example zkmips split
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.27s
     Running `target/release/examples/zkmips split`
[]string{"123", "321"}
result 39483
[2024-06-17T07:09:36Z INFO  zkmips] Split done 365745

BASEDIR=test-vectors RUST_LOG=info SEG_FILE_NUM=2 SEG_FILE_DIR=/tmp/output SEG_SIZE=262144 cargo run --release --example zkmips aggregate_proof_all
warning: `/mnt/data/.cargo/config` is deprecated in favor of `config.toml`
note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml`
    Finished `release` profile [optimized] target(s) in 0.24s
     Running `target/release/examples/zkmips aggregate_proof_all`
[2024-06-17T07:10:52Z INFO  zkmips] Process segment 0
[2024-06-17T07:10:56Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 21030 cycles
[2024-06-17T07:10:56Z INFO  zkm::generation] CPU halted after 283174 cycles
[2024-06-17T07:10:57Z INFO  zkm::generation] CPU trace padded to 524288 cycles
[2024-06-17T07:10:57Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 141871, cpu_len: 524288, poseidon_len: 42058, poseidon_sponge_len: 42058, logic_len: 17928, memory_len: 2714924 }
[2024-06-17T07:12:15Z INFO  plonky2::util::timing] 82.6788s to prove root first
[2024-06-17T07:12:15Z INFO  zkmips] Process segment 1
[2024-06-17T07:12:18Z INFO  zkm::cpu::bootstrap_kernel] Bootstrapping took 27222 cycles
[2024-06-17T07:12:18Z INFO  zkm::generation] CPU halted after 130823 cycles
[2024-06-17T07:12:20Z INFO  zkm::generation] CPU trace padded to 262144 cycles
[2024-06-17T07:12:20Z INFO  zkm::generation] Trace lengths (before padding): TraceCheckpoint { arithmetic_len: 41008, cpu_len: 262144, poseidon_len: 54442, poseidon_sponge_len: 54442, logic_len: 4923, memory_len: 2425143 }
[2024-06-17T07:13:18Z INFO  plonky2::util::timing] 62.9830s to prove root second
[2024-06-17T07:13:19Z INFO  plonky2::util::timing] 1.2882s to prove aggression
[2024-06-17T07:13:21Z INFO  zkmips] proof size: 412855
[2024-06-17T07:13:25Z INFO  zkmips] build finish
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote common circuit data to common_circuit_data.json
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote verifier data to verifier_only_circuit_data.json
[2024-06-17T07:13:29Z INFO  plonky2x::backend::wrapper::wrap] Succesfully wrote proof to proof_with_public_inputs.json
[2024-06-17T07:13:29Z INFO  plonky2::util::timing] 205.9857s to prove total time

public_inputs in proof_with_public_inputs.json
"public_inputs":[3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85,3,176,196,66,152,252,28,20,154,251,244,200,153,111,185,36,39,174,65,228,100,155,147,76,164,149,153,27,120,82,184,85]}

fixed by https://github.com/zkMIPS/succinctx/commit/885530166fa5895dbcd7e2db57a72e1f2c982c0d


Check for valid credit card object

This fixes https://github.com/thephpleague/omnipay-dummy/issues/2

Imo that validate call should throw an exception if the Card is not valid.

You are right, that's the wrong place for the check


Clock module: Scrolling timezones doesn't seem to work

According to the wiki:

timezones - A list of timezones (as in timezone) to use for time display, changed using the scroll wheel.

I am running Waybar 0.9.8 on sway 1.6.1 and I have trouble getting that to work. Scrolling on the clock does nothing. Scrolling on other modules like pulseaudio seems to work. I would appreciate some help with figuring out what's wrong with my config.
My waybar config:
{
    "layer": "top",
    "modules-left": ["sway/workspaces", "sway/mode", "sway/language"],
    "modules-right": ["pulseaudio", "clock", "tray"],
    "clock": {
        "format": "{:%F %H:%M %Z}",
        "tooltip-format": "<big>{:%Y %B}</big>\n<tt><small>{calendar}</small></tt>",
        "timezones": ["America/New_York", "Europe/Moscow", "Asia/Vladivostok"]
    },
    "tray": {
      "icon-size": 20,
      "spacing": 3
    },
    "pulseaudio": {
      "format": "{volume}% {icon}",
      "format-bluetooth": "{volume}% {icon}",
      "format-muted": "",
      "format-icons": {
          "headphone": "",
          "hands-free": "",
          "headset": "",
          "phone": "",
          "portable": "",
          "car": "",
          "default": ["", ""]
      },
      "scroll-step": 1,
      "on-click": "pavucontrol"
    },
    "height": 24
}

I think #1417 should fix this

Hi @rinpatch can you provide update there? If it's not relevant more please close the issue

Hi @rinpatch , up

Hi @rinpatch , up)

You need to add an "actions" section like
"clock": {
   // your other clock stuff here,
  "actions": {
     "on-scroll-down": "tz_up",
     "on-scroll-down": "tz_down",
  },
}

I had a similar issue but I figured it out via going to this part of the wiki
I suggest that you use on-middle-click instead of on-scroll-up/down if you use a touchpad since it will be user to do one discrete click versus a swipe which will likely scroll several entries at once.

Sorry for inactivity, it has indeed been resolved.


Unable to Successfully Consume Inference Endpoint

[Enter feedback here]
I appears the code within the notebook 02-turbofan_deploy_model.ipynb has some issues both with creating the container image and getting predictions once the model is deployed.
First, I could not get the image creation to work with the myenv.yml. I had to use the docker_file parameter with the below entries to get everything to deploy correctly.

RUN apt-get update
RUN apt-get install -y build-essential python-software-properties software-properties-common gcc

RUN conda install -c r -y pip=20.1.1 && \
  conda install -c conda-forge gxx_linux-64 scikit-learn numpy pandas psutil gcc && \
    conda clean -ay

RUN pip install --no-cache-dir azureml-defaults azureml-sdk azureml-automl-core azureml-automl-dnn-nlp azureml-automl-runtime scikit-learn==0.22.1 xgboost==0.90 plotly

Second, once the model gets deployed to ACI, I get the following error:
{
"error": {
"code": "UserError",
"message": "Expected column(s) 0 not found in fitted data.",
"target": "X",
"inner_error": {
"code": "BadArgument",
"inner_error": {
"code": "MissingColumnsInData"
}
},
"reference_code": "17049f70-3bbe-4060-a63f-f06590e784e5"
}
}
I believed the error to be caused by the training and test dataframes having an unnamed column left over from not having "index=False" in the "to_csv()" method. Upon modifying the code in 01-turbofan_regression.ipynb and retraining the model, I still get the issue.
The Image and ContainerImage classes are deprecated, which may be creating some of these issues. I am working with a customer to fix these issues, but have not had luck in the past couple days.

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

ID: de25b89e-91d8-3df4-c2e8-a98060e0c9b2
Version Independent ID: 55403f3e-4c47-63c7-310c-bd9374c93015
Content: Tutorial: Train and deploy a model - Machine Learning on Azure IoT Edge
Content Source: articles/iot-edge/tutorial-machine-learning-edge-04-train-model.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

Hello @nhwkuhns We are looking into this.

I was able to pinpoint the issue. Turns out the score.py script was sending the dataframe for inferencing as a np.array.
Also, I was able to build and deploy the model using the Environment class. The code in the 02-....ipynb should be updated to include that rather than the ContainerImage class as the latter is deprecated and it does not cache the image for rebuilding on minor code changes (saving roughly 15 minutes per rebuild for code changes).

Hello @nhwkuhns Is this the right Github : https://github.com/Azure-Samples/IoTEdgeAndMlSample/tree/master/AzureNotebooks ?
For the Notebook code sample files?


Nvidia driver

[Enter feedback here]
I have some feedback:
Question:
Why was Nvidia driver version 528.24 pulled?
Bug report
On an Azure VM NVadsA10 v5-series (12CPU) driver version 528.89 crashes application Rhino3D at launch. Rhino 7.29 Release 2023-4-17. It crashes other versions as well.
Reproduction steps:
Install Rhino3D and launch. Crash occurs within 30 seconds.

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

ID: 3c5bc749-3f68-e230-37ff-f74ce72efb59
Version Independent ID: 2a382803-e085-82e2-4139-be5c8b9e1a0d
Content: Azure N-series NVIDIA GPU driver setup for Windows - Azure Virtual Machines
Content Source: articles/virtual-machines/windows/n-series-driver-setup.md
Service: virtual-machines
Sub-service: sizes
GitHub Login: @vikancha-MSFT
Microsoft Alias: vikancha

@clarkry2023 Thank you for sharing the feedback. We always update the main link to point to the latest driver and publish links to all the previous versions for manual installation.  As documented here https://learn.microsoft.com/en-us/azure/virtual-machines/windows/n-series-driver-setup we publish all the previous versions on Git hub(https://github.com/Azure/azhpc-extensions/blob/master/NvidiaGPU/resources.json). Hope this addresses the concern you have.

Ok thank you for clarifying. And my other comment about the driver causing a crash. What is the best way to report that and get help figuring that out?
From: vikancha-MSFT @.>
Sent: Tuesday, May 30, 2023 1:02 PM
To: MicrosoftDocs/azure-docs @.>
Cc: Ryan Clark @.>; Mention @.>
Subject: Re: [MicrosoftDocs/azure-docs] Nvidia driver (Issue #110194)
EXTERNAL EMAIL:  Use caution when opening attachments, clicking links or responding to requests for information.
@clarkry2023https://github.com/clarkry2023 Thank you for sharing the feedback. We always update the main link to point to the latest driver and publish links to all the previous versions for manual installation. As documented here https://learn.microsoft.com/en-us/azure/virtual-machines/windows/n-series-driver-setup we publish all the previous versions on Git hub(https://github.com/Azure/azhpc-extensions/blob/master/NvidiaGPU/resources.json). Hope this addresses the concern you have.
—
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/110194#issuecomment-1568774091, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAGLQ4IPMGBSLGS7GNR5TU3XIYRXNANCNFSM6AAAAAAYUJJFXQ.
You are receiving this because you were mentioned.Message ID: @.***>

@clarkry2023
Thanks for your feedback! We will investigate and update as appropriate.
@vikancha-MSFT
Thank you for your quick responses.

@clarkry2023 Please open a support ticket for the Rhino3D crash issue. Our support team will engage the right teams to investigate the issue.

@clarkry2023
I'd recommend working closer with our support team via an [Azure support request] (https://docs.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request).

@clarkry2023
We are going to close this thread as resolved but if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.


Django 3.2 breaks django-fsm: get_available_FIELD_transitions is empty for abstract models with FSMField in Django 3.2

Hi, first of all, thanks for this great package! I've been using it for all Django apps with approval/QA workflows for 9 years now and it's an absolute game-changer.
I've just noticed that after upgrading Django from 3.1 to 3.2, all django-fsm status transitions vanished. I read the code but didn't find any obvious breakage. There's no error message, the transitions simply don't show up. I can still execute the transition functions from the shell_plus.
Obviously I have to do way more homework before I can file a useful bug report here, but I wanted to share my findings and ask whether any other django-fsm users have run into the same issue.

Django 3.2 with django-fsm is broken (no transitions). requirements.txt with obviously way too many dependencies for a MVE.
Downgrade to Django 3.1 (leave everything else up to latest) works again. requirements.txt

I had to fix a few minor things to upgrade to Django 3.2 (app config and a patch for django-grappelli). The downgrade to Django 3.1 worked without any changes to the upgrade fixes.

Any workarounds to this that don't include downgrading?

yes, for example get_all_FIELD_transitions does not work anymore

We've been trying to solve this issue for a few days and found out that an abstract base class causes the issue. Hope this helps finding the correct solution.
This breaks:
class BlogPostMixin(models.Model):
    state = FSMKeyField(default='new')

    @transition(field=state, source='new', target='published')
    def publish(self):
        pass

    class Meta:
        abstract = True  # this probably causes the issue

class BlogPost(BlogPostMixin):
    ...

Moving the state and transitions to the main model works but there are plenty of code repetition if you are reusing the same state and transitions which a Mixin supposedly solves:
class BlogPost(models.Model):
    state = FSMKeyField(default='new')

    @transition(field=state, source='new', target='published')
    def publish(self):
        pass

@roniemartinez thanks for the follow-up, this is exactly how I use django-fsm. I use abstract models as mixins to keep fsm logic DRY. I assume many others do the same.

For anyone looking for a quick fix, I was able to make it work by overriding django_fsm.FSMFieldMixin._collect_transitions
    def _collect_transitions(self, *args, **kwargs):
        """
        Fix for https://github.com/viewflow/django-fsm/issues/256
        """

        sender = kwargs["sender"]

        if not issubclass(sender, self.base_cls):
            return

        def is_field_transition_method(attr):
            return (
                (inspect.ismethod(attr) or inspect.isfunction(attr))
                and hasattr(attr, "_django_fsm")
                and attr._django_fsm.field.name == self.name
            )

        sender_transitions = {}
        transitions = inspect.getmembers(sender, predicate=is_field_transition_method)
        for method_name, method in transitions:
            method._django_fsm.field = self
            sender_transitions[method_name] = method

        self.transitions[sender] = sender_transitions

The only difference is attr._django_fsm.field.name == self.name vs attr._django_fsm.field in [self, self.name].

That's this commit that introduced the regression for django-fsm
https://github.com/django/django/commit/502e75f9ed5476ffe8229109acf0c23999d4b533
I'm afraid that none of the already proposed solution is the right fix. We need to treat inheritance of fields more explicitly.

Could be that's maybe a regression in django itself. I posted a comment to ask for clarification.
https://code.djangoproject.com/ticket/31750#comment:4

Could be that's maybe a regression in django itself. I posted a comment to ask for clarification.
https://code.djangoproject.com/ticket/31750#comment:4

They clarified it's by design. we will have to provide a fix for django-fsm.

Any progress on this super dangerous issue? :/

Hi,
We also use many abstract classes with our transition to avoid duplication. We had to revert our Django update for the moment to wait for an update on this issue.
Do you have an idea about when it will be fixed? :)

@marine-mb
@ticosax fix (open PR) worked for us.
With several users depending on this project, maybe this is the time to add new maintainers to the project @kmmbvnr

Did anyone try to work on this? 😞

The fix of mentioned by @roniemartinez causes an issue when I run runserver, not sure if it's my setup or not.

@roniemartinez got to the bottom of it: as the check attr._django_fsm.field in [self, self.name] shows, attr._django_fsm.field can sometimes be a string, in which case the check after raises my error.
The correct fix should therefore be (if you want to update the PR):
from django.db.models import Field

    def is_field_transition_method(attr):
            return (inspect.ismethod(attr) or inspect.isfunction(attr)) \
                and hasattr(attr, '_django_fsm') \
                and (attr._django_fsm.field in [self, self.name]
                    or attr._django_fsm.field.creation_counter == self.creation_counter)

This is tested in production, should work. Thank you!

@ticosax

@felixmeziere  thank you for the correct fix! I just released the new version.
I feel that the django-fsm became too complicated than it should be. And the core problem is the 11 years old design decision to combine fsm with Django model class
Compositional approach with class separated fsm simplifies implementation in a many ways, and gives much more flexibility for abstract/base classes hierarchies
I think it was the last release of django-fsm 2.0 an the project reached end of life. The new django-fsm 3.0 ideas is available as viewflow.fsm module To simplify support, new features development, and quickle release cycles I'm moving all my projects into the single viewflow library.
Thank you folks for the help, over all those years!

Still not fixed. https://github.com/viewflow/django-fsm/commit/910ce79cfef1b285ed8fd6e5d7727a98aac7bc1d#r59705075

I don't get into details deep, but current test behavior is consistent between Django versions and previous django-fsm implementation
For better support of fsm inheritance, please consider to switch to viewflow.fsm, that don't have such issues by design.

I would like to reopen this Issue. There is a patch and a merge request for this issue. May I ask why this is not included?
I have seen the reference to viewport. If I need something like a state machine for Django this library (django-fsm) is the first place to go due to its maturity, size, prominence and communiy. The outward appearance of viewport doesnt let me understand what BPMN has to do with a state machine implementation for Django. I could not find any documentation on how to use viewportas a lightweight successor fordjango-fsm`. As a developer I refuse a bit to include a big (external) library of which I only want to use a supporting module.
I ask to reconsider the decision to drop django-fsm just like that, especially since the way to the successor doesn`t seem to be really known.

@hbast I'm just an external contributor, who love and rely on django-fsm.
I don't have any kind of influence on these decisions. I can just say that, if it were to change, I'm interested to take some responsibilities to maintain this project if that would help.

I would love it if the owner transfers this project to the community.


Fixed incorrect Link

I've fixed an incorrect link in your Readme.md. When clicking on "Recipes" your were actually being redirected to "Sprinkles" which now has been fixed.

Thank you!


Update europe-docker.pkg.dev/gardener-project/releases/gardener/alpine-conntrack Docker tag to v3.20.1

This PR contains the following updates:

Package
Update
Change

europe-docker.pkg.dev/gardener-project/releases/gardener/alpine-conntrack
minor
3.19.0 -> 3.20.1

[!WARNING]
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
Because you closed this PR without merging, Renovate will ignore this update (3.20.1). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


Main Page Documentation on Canceling Charges is inaccurate

Hello!
Just noticed this in the readme concerning canceling charges.
$chargeObj = Charge::retrieve(<charge_id>);

if ($chargeObj) {
    $chargeObj->confirm();
}

I believe it should be the following instead.
$chargeObj = Charge::retrieve(<charge_id>);

if ($chargeObj) {
    $chargeObj->cancel();
}

$chargeObj->cancel();

Works as expected.

Merged PR. Thanks @mpoletiek. Will wait to publish when we have any further major changes.


library

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

In the file code/ch01/tests/test_notebooks.py:

Line 1:1: E265 block comment should start with '# '