Compile Failed (Eigen errors)

Hi, I am getting following Eigen errors when compiling the project:
Error   16  error : calling a host function("Eigen::DenseBase<Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> > ::Zero") from a device function("blockReduceSum<(int)29> ") is not allowed
Error   73  error : calling a host function("Eigen::DenseCoeffsBase<Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> , (int)1> ::operator []") from a device function("Reduction::SquareUpperTriangularProduct<(int)0, (int)0, (int)6> ::apply") is not allowed
Error   18  error : calling a host function("Eigen::DenseCoeffsBase<Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> , (int)1> ::operator []") from a device function("warpReduceSum<(int)29> ") is not allowed
Error   25  error : calling a host function("Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> ::Matrix") from a device function("Reduction::operator ()") is not allowed
Error   15  error : calling a host function("Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> ::MatrixEigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float , Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> > > ") from a device function("blockReduceSum<(int)29> ") is not allowed
Error   51  error : calling a host function("Eigen::MatrixBase<Eigen::Matrix<float, (int)3, (int)3, (int)2, (int)3, (int)3> > ::operator *<Eigen::Matrix<float, (int)3, (int)1, (int)2, (int)3, (int)1> > ") from a device function("Reduction::operator ()") is not allowed
I have built and installed Eigen from source files (CUDA supported). Tried using both github.com/stevenlovegrove/eigen and Eigen 3.3. Also I have installed Eigen, Pangolin, Sophus and ICPCUDA all in Release mode for x64 platform.
Any suggestions ?

What OS, version of CUDA and compiler?

Windows 10, CUDA 7.0, VS 2013

There are some issues with building Eigen within CUDA on Windows, you have to only include the minimal Eigen headers.

I built Eigen with CUDA separately, that part worked. But, calling it in kernal of this project doesn't seems to be working.

By the way, what is recommended OS, CUDA and compiler for this project ?
I built Eigen again, and now getting error of: declaration is incompatible with "void Eigen::BDCSVD..
and if I comment this template I get attached errors.

My guess is its wise to switch OS, please suggest.

I would switch to Ubuntu, the build has not been fully tested on Windows.

Hi, i've got a similar set of errors on Ubuntu 14.04 LTS, gcc 4.8.4 and CUDA V7.5.17.
home/aslab/pkg/ICPCUDA/src/Cuda/estimate.cu(56): error: calling a _host_ function("Eigen::Matrix<float, (int)29, (int)1, (int)2, (int)29, (int)1> ::operator =") from a _device_ function("blockReduceSum<(int)29> ") is not allowed
I'm wondering if it's because I haven't compiled stevenlovegrove/eigen properly. In the CMake GUI it seems to have found all of the Eigen stuff except for CUDA_SDK_ROOT_DIR - is that a problem? I have checked all of the CUDA-related checkboxes except for CUDA_BUILD_EMULATION which causes a problem.
Then for ICPCUDA in CMake I have set the EIGEN_INCLUDE_DIRS to my local build (since I don't want to overwrite the system Eigen installation with the forked version).

CUDA_SDK_ROOT_DIR  wont be a problem. Steven mentioned that they used CUDA 8.0 (pre production), you may try with that. If it works please let me know as well. I am shifting from Windows to Ubuntu.

Thanks for the tip - I tried CUDA 8.0 on a separate partition and it all seems to work well. However, because I hadn't tried CUDA 7.5 on that partition I can't 100% guarantee that it was the version of CUDA that made the difference (though it does seem that way).

Hi, similiar Problems over here.
Running Kubuntu 14.04 with cuda 7.5 (nvcc 7.5.17)
Error Output is like this:
~/git/ICPCUDA/src/Cuda/pyrdown.cu(149): error: calling a host function("Eigen::Matrix<float, (int)3, (int)1, (int)2, (int)3, (int)1> ::Matrix") from a global function("computeNmapKernel") is not allowed
~/git/ICPCUDA/src/Cuda/pyrdown.cu(149): error: calling a host function("Eigen::Matrix<float, (int)3, (int)1, (int)2, (int)3, (int)1> ::Matrix") from a global function("computeNmapKernel") is not allowed
and so on
Tried Cuda 8.0 with no difference, tried some eigen versions (3.0.0, 3.3-beta1 and some others) with also no success. btw. exp-branch seems to compile but i can't finish the testrun (no assosiations.txt file in the testdate so the test runs an infinite loop)
any idea what this could be about?

I have successfully compiled using Ubuntu 14.04 and CUDA 7.5.18. If you are getting EIgen errors, make sure you are building Eigen with CUDA support.

I just got it working with CUDA 7.5.17 too - it turns out that I need to install (sudo make install) my CUDA-enabled Eigen headers.
I'm not sure why it wouldn't work when I directed Pangolin, Sophus and ICPCUDA to my local CUDA-enabled Eigen headers using the CMake EIGEN3_INCLUDE_DIR field - maybe I missed one of them or re-built them in the wrong order..

Hi, I ve got it working to installing eigen in /usr/include instead of /usr/local/include. No matter where i've pointed to the eigen lib in cmake, it has always used the install in /usr/include

I am getting these same errors, has anyone successfully compiled this on windows?

same problem with CUDA 8.0 ubunto 14.04 Eigen 3.2.0, any help?

just found the newest Eigen 3.3.3 involved cuda supporting. So that I build it from source, and removed 3.2.0 by sudo apt-get remove libeigen3-dev, which remove ububtu 14.04 eigen3 as well as pcl-1.72.....(which disabled my Kintinous :( ).
Then I remake ICPCUDA , it passed with a lot of warnings but now I can use it!
BTW, when I remake it, I also click to build EIGEN-CUDA-TEST by using cmake-gui, I am not sure if these help or not....

Hi all, I am on windows, and have Eigen 3.3. I am down to 2 errors, but cannot figure out how to solve them...
Error	"operator=" has already been declared in the current scope	ICP	d:\libs\eigen-eigen-b30b87236a1b\eigen\src\Core\Block.h	111
Error		"operator=" has already been declared in the current scope	ICP	d:\libs\eigen-eigen-b30b87236a1b\eigen\src\Core\Ref.h	155
Does anyone have any ideas here?
Thanks!

@syedharoonalam
I just ran into the same Eigen problems void Eigen::BDCSVD  from windows.
The environment:  Eigen 3.3.3 (has CUDA support), CUDA 8, Windows 7.
The issue for me was including <Eigen/Geometry>  inside CUDA code. As  @mp3guy suggested, switching to minimal <Eigen/Core> is the answer.
If you still need Geometry support (as I did),  you can wrap the header and comment out the problematic includes (SVD and Geometry/Scaling). This assumes that you are not using them and is really nvcc not properly parsing Eigen's code ( eg. you are not doing SVDs on device)
Anyways, instead of including <Eigen/Geometry>  create a file geometry_wrapper.h
and do something like:
#ifndef __CUDACC__
#  include <Eigen/Geometry>
#else
#  ifndef WIN32
#    include <Eigen/Geometry>
#  else //this is the case for CUDA on Windows
     [COPY includes from <Eigen/Geometry> here, and comment out the problematic ones]
#  endif
#endif

This should be okay for all other OS/compilers, as it only changes CUDA on windows.

@randi120 Could you please post the your real geometry_wrapper.h for us?

@Buzzroid, I did not run into these problems with ICPCUDA, so I am not sure if you are having issues with the same headers, that's why I did not post the wrapper in the earlier response (it might not be a one-size fits all kind of solution).
But if you think it could be helpful, see below for the geometry_wrapper.h file
#ifndef __CUDACC__
#  include <Eigen/Geometry>
#else
#  ifndef WIN32
#    include <Eigen/Geometry>
#  else //this is the case for CUDA on Windows
//    RC: the code below code comes from Eigen's 3.3.3 <Eigen/Geometry>
//    with problematic headers commented out (SVD and Scaling)
//    we are not using either functionality on device but for some reason nvcc tries to parse these headers (at least on windows) and fails.
#    ifndef EIGEN_GEOMETRY_MODULE_H
#      define EIGEN_GEOMETRY_MODULE_H
#      include <Eigen/Core>
#      include <Eigen/src/Core/util/DisableStupidWarnings.h>
//#      include <Eigen/SVD>
#      include <Eigen/LU>
#      include <limits>
#      include <Eigen/src/Geometry/OrthoMethods.h>
#      include <Eigen/src/Geometry/EulerAngles.h>
#      include <Eigen/src/Geometry/Homogeneous.h>
#      include <Eigen/src/Geometry/RotationBase.h>
#      include <Eigen/src/Geometry/Rotation2D.h>
#      include <Eigen/src/Geometry/Quaternion.h>
#      include <Eigen/src/Geometry/AngleAxis.h>
#      include <Eigen/src/Geometry/Transform.h>
#      include <Eigen/src/Geometry/Translation.h>
//#      include <Eigen/src/Geometry/Scaling.h>
#      include <Eigen/src/Geometry/Hyperplane.h>
#      include <Eigen/src/Geometry/ParametrizedLine.h>
#      include <Eigen/src/Geometry/AlignedBox.h>
#      include <Eigen/src/Geometry/Umeyama.h>
#      if defined EIGEN_VECTORIZE_SSE && !defined EIGEN_VECTORIZE_AVX
#        include <Eigen/src/Geometry/arch/Geometry_SSE.h>
#      endif
#      include <Eigen/src/Core/util/ReenableStupidWarnings.h>
#    endif // EIGEN_GEOMETRY_MODULE_H
#  endif
#endif

@randi120 Thanks for the post.
I've tried but failed with the same errors.
By the way, it seems that Eigen itself has some issues or bugs.
There is a bug report regarding this:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1412

@randi120 Oh, It seems that your solution works.
Here's what I've done:

Block including the eigen header files in two places: ICPOdometry.h and Cuda/internal.h
Include "geometry_wrapper.h" in the places

Thank @randi120 again.

@Buzzroid  I am glad it works.
Hopefully Eigen fixes that bug (thanks for that, I didn't know about it) and then the wrapper won't be needed.

@randi120 The eigen errors are solved. But I got "undefined symbol 'M_PI' in sophus.hpp". And I have compiled Sophus successfully.
My platform: VS2015, CUDA8.0
Could you help me to solve this problem?

@randi120 I am facing the same problem in ubuntu 14.04 and eigen 3.2. Can you kindly send a pull request or share your changes in a more detailed manner? I will hugely helpful for people stumbling above on this error.
Thanks
Arpit

@StephenGreat,  I am sure you figured this one out. Sometimes windows gets a little silly
You can try adding add_definitions(-D_USE_MATH_DEFINES) to a top-level cmake file.
If that doesn't work, I would modify the source file directly.
#ifndef M_PI
    #define M_PI 3.14159265358979323846
#endif

@arpit15, I am hesitant to create a pull request for code I have never used. As I mentioned above, I did not run into these issues with ICPCUDA. However, this thread was one of the top hits, and once I got something to work (on my own code), I figure it would be worth sharing here.
That said, a possible fix for ICPCUDA could be:

create a file geometry_wrapper.h. Paste the code from my earlier post into the file.
(As stated by @Buzzroid) replace the lines #include <Eigen/Geometry>  in ICPOdometry.h and Cuda/internal.h with #include "geometry_wrapper.h".

Hope that helps.

@randi120 thanks for the details notes. Unfortunately I am still facing the same error on my system.

 But I got "undefined symbol 'M_PI' in sophus.hpp". And I have compiled Sophus successfully.
My platform: VS2015, CUDA8.0
Could you help me to solve this problem?


Got rid of ReadOnly validation

@colemickens @jhendrixMSFT @marstr
PTAL!

I'm good with the change once @colemickens verifies it resolves their issue.

Before we tag this as a release, let's make sure to have @colemickens play with this commit to ensure there aren't other issues.

Actually, instead of immediately putting this on master, let's commit this to a test branch on top of master for @colemickens to play with. That way folks using go get -u github.com/Azure/azure-sdk-for-go don't pull down these bits until they're more validated.

It shouldn't be a problem for me to pull from @mcardosos's remote. No need to put it explicitly on this repo unless you really want to.

Ah, good point. Let us know when you've finished validating.

I apologize for the delay on testing this. Someone hotfixed Kubernetes after this PR was submitted so I deprioritized it a bit.
I can confirm that this (along with removing the workaround) results in successful operation. The PR is good.
Thanks again for this.

No worries!
Thanks for taking the time to verify the PR worked as expected :D

@mcardosos Two follow up quesitons:

Is this "fix" permanent? There's no risk of these popping back up on next re-gen?

Is there any reason you know of that I should not go ahead and move Kubernetes over to the latest commit? Maybe I should wait for a tagged release? Is that coming?

Thanks!

@colemickens
2 - I am tagging this today. If you use the storage dataplane, take a look into the latest commits. For the ARM side you shouldn't have problems.

(I'm not @mcardosos, but I can answer too!)

Yep, we're making this particular change permanent. If we bring back validation, it would look radically different and we'll definitely keep this and related threads in mind.
A tagged release is coming right quick. Expect to see this Monday. (We're currently working on it, and you can see our progress in PR #528 )

Per today's releases, I plan to have Kubernetes move to:

azure-sdk-for-go: v8.0.0-beta
go-autorest: v7.2.5

Please let me know if this is not advisable. Thanks.


please don't force push to haskell-updates

It just unnecessarily creates a lot of merge conflicts.
The commit in question: https://github.com/NixOS/nixpkgs/commit/d4d82d63fa9109374cfd10abfafed21933553a6c
cc @peti

I rebase haskell-updates once per week before I merge to clean up the history. This is kinda important because we have so many automatic commits to the branch that would otherwise create an unreadable mess of back and forth merges.

Maybe we should use the "Rebase and merge" option for haskell-updates then?
cc @cdepillabout

I'm in full support of whatever is easiest for @peti when he does the weekly updates.

Here is what we don‘t do: We don‘t modify the history of haskell-updates during the week.
Here is what we do: On friday evening we cleanup the history of haskell-updates and merge it into master. Then we create a new branch incidentally also called haskell-updates, which at this point is a french branch-off from master. And because there happened a rebase in-between there is no way to fast-forward from the old branch to the new branch.
I don‘t think there is a solution to your problem other than a) not having an ugly history from the start (I don‘t see that happening our whole testing relies on the nightly updates) or b) not rebasing during merge. (Not sure about that solution.)
Incidentally not rebasing would be easier during merge. @peti often has to do some magic incantation to get the rebase right and curses a lot while doing so.^^
Anyways @poscat0x04, I am curious, can you elaborate a bit how that force-pushing actually introduces merge-conflicts which we wouldn‘t have without?

Yeah, that merge conflict on my pull request was caused by hackage-packages.nix which I did not touch at all. While force-pushing doesn't guarantee to create merge conflicts, I think it should be avoided as much as possible on a codebase that multiple people are working on.
If the whole point of rewriting history is to remove merge commits then those merge commits can be entirely avoided by using the "Rebase and merge" option on GitHub and using git pull --rebase instead of git pull --merge.

@poscat0x04 I don't think this is to avoid merge commits.

we have so many automatic commits to the branch

@peti  talks about all commits, not just merge commits. Point is to squash some commits etc.
I also think your suggestion would not help because if you base your branch on a haskell-updates and then the commits from haskell-updates would change which has happen during rebase of haskell-updates against master during merge you would still have the same conflicts. These github options as well as --rebase and --ff-only flags really work only when the target branch doesn't change underneath you. The problem is that haskell-updates must change - it must be rebased so it could be merged to master. As far as I know there is no way around this.
The only solution that would prevent these type of conflicts would IMO be to stop rebasing haskell-updates which means
a. never merge haskell-updates to master
b. merge haskell-updates as --no-ff, do the mess in master (merge commit jazz) and never ever update haskell-updates
Unless I'm missing something (which is possible) I think the current flow is about as sensible as it can be.
What I would recommend is that in case you hit this issue you just force pull haskell-updates, merge haskell-updates to your branch wiith and do git diff --name-only --diff-filter=U | xargs git checkout --theirs

This is indeed not about avoiding merge commits.
@turboMaCk I feel like your options are overcomplicating this a bit. I am pretty sure the by far easiest option would be to just not rebase anything before merging. And it wouldn‘t be that bad. But still I don‘t think rest of nixpkgs-land would be happy about it.

We don‘t do force pushes on haskell-updates anymore.


GPU Delegate Issue !

System information

Have I written custom code (as opposed to using a stock example script
provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Android OS Oreo (API Level 27)
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue
happens on a mobile device: Surveillance Camera with QCS605 Qualcomm ship.
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): 2.5
Python version: 3.8
Bazel version (if compiling from source):
GCC/Compiler version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory: Adreno GPU 615
Exact command to reproduce:

  final Interpreter.Options options = new Interpreter.Options();
  CompatibilityList compatList = new CompatibilityList();

  if (compatList.isDelegateSupportedOnThisDevice()) {
      // if the device has a supported GPU, add the GPU delegate
      GpuDelegate.Options delegateOptions = compatList.getBestOptionsForThisDevice();
      GpuDelegate gpuDelegate = new GpuDelegate(delegateOptions);
      options.addDelegate(gpuDelegate);
      Log.i(LOGTAG, "-----------Running using GPU Delegate-----------");
  } else {
      // if the GPU is not supported, run on numThreads threads
      options.setNumThreads(numThreads)
              .setAllowFp16PrecisionForFp32(allowFp16PrecisionForFp32)
              .setUseNNAPI(useNNAPI);
      Log.i(LOGTAG, "------------Running using CPU Delegate---------");
  }

Describe the problem
Trying to run Movinet  tflite model on a vendor camera with Adreno GPU 615.
The network runs on the CPU without any issues. But it can't be run on the GPU.
I'm using Java TFLite run time with version 2.5. I tried the nightly version but didn't work also.
Source code / logs
I/Adreno: QUALCOMM build                   : e3ea17d, I2eff518144
I/Adreno: Build Config                     : S L 4.0.10 AArch64
I/zygote64: android::hardware::configstore::V1_0::ISurfaceFlingerConfigs::hasWideColorDisplay retrieved: 0
E/libEGL: call to OpenGL ES API with no current context (logged once per thread)

Given
E/libEGL: call to OpenGL ES API with no current context (logged once per thread)

I have the impression you are using a separate thread to asynchronously initialize and speed up things.  You cannot do that with OpenGL because GL context is bound to the thread.

@impjdi The only option i have now is to run the model inference part in background android service . Do you have any suggestions for workarounds  in order to make the GPU delegate run in background service  ?

Hm, I'm not familiar with background services in Android, but as long as you use the same thread, it should be okay.  I'm not up to date with asynchronous programming in Java, but if you don't rely on fancy language structures that take care of the async execution behind your back (and thus has a chance to run your stuff in a different thread), you should be fine.  In other words, have a dedicated thread in which you initialize TFLite GPU and run inference.

@impjdi Thanks for your feedback. I rechecked my app and found that i was running the GPU inference part in a different thread than the main app thread.


Change image host URL

If you were using img.steemconnect.com for display avatars on your app please update to img.busy.org see related post https://steemit.com/steemdev/@fabien/avatar-and-cover-images-for-your-steem-apps

Completed


search bar error

the search bar is getting out of the navbar while resizing.

@coderbabu10 Can you post a GIF or screenshot showing this problem? It's hard to know what exactly is wrong with the description provided here

@coderbabu10 @brenoferreira if this is not yet assigned can I take this?

this issue is closed as pr #567  is merged


Enabling linux_aarch64 builds

Would be great to have linux_aarch64 packages of dgl as well

@conda-forge-admin, please re-render

Good idea! Is there a way to do build native osx-arm64 yet? I am not sure if dgl is set up for cross compilation...

Ah was thinking about Linux
Added to the migrator for macOS ARM ( https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/4821 )
Unfortunately no native macOS ARM builds yet
We can look at cross-compilation changes, but we may still be missing dependencies (metis and nanoflann plus possibly pytorch depending)


Please write comment there when this wonderful tool is fully ready

I am working on this Tool every day and it will take a little more time because I am working alone and understand how difficult it is to work alone, thanks for commenting.🥰


don't swallow Exceptions

When the server is offline the await zero_client.call("hello_world", None) will just return None - I think it would make more sense to throw an exception. Otherwise one does not know if the server returned None or it was a timeout. And even if None would not be a an allowed return value, one would always have to check
https://github.com/Ananto30/zero/blob/e2c69a93981a0efdf3f7faf7e14b28197f73d9fb/zero/client.py#L90-L93

Exceptions on Server Side also seem to result in just None being returned. I (again) think it would be better to make the failing explicit to the client. Normal HTTP-APIs for example would return an 500 Error Response.
https://github.com/Ananto30/zero/blob/e2c69a93981a0efdf3f7faf7e14b28197f73d9fb/zero/server.py#L264-L265

So the idea was the exception should be handled in server and client end, not in the framework itself.
As an example, wrap the server (rpc) function with defined error handler and send specific error_response schema as per your design. So there is a distinction between the actual python client error and error response. wdyt about this @powellnorma ?

When the server is offline the await zero_client.call("hello_world", None) will just return None - I think it would make more sense to throw an exception. Otherwise one does not know if the server returned None or it was a timeout. And even if None would not be a an allowed return value, one would always have to check

Good point! I have added TimeoutException and ConnectionException here #29

So the idea was the exception should be handled in server and client end, not in the framework itself.

But I feel like currently it is handled by the framework - It swallows them and logs them.
I agree that optimally the server would handle these exceptions, but what about bugs that the developer did not think of?
I would argue that this library has to deal with exceptions, since it is the one that calls these functions. So we should ask: what is a good default way of handling exceptions?
And swallowing them and thereby acting to the client as if everything worked just fine (and the function just happened to return None) feels wrong to me. I feel instead being explicit about the failure is more align to what one would expect to happen.

As an example, wrap the server (rpc) function with defined error handler

Yes, but I feel like this would often times cause a lot of boiler plate code. One would have to wrap every server-side function and every client-side function in some way.
What do you think about this PR? https://github.com/Ananto30/zero/pull/35

Good point! I was trying to mimic what HTTP frameworks do, when you get an error in the server, the server just logs it. But I forgot HTTP has a status code to return something to the client to determine the error. And as we don't have status codes (users can always implement their own way of communicating), we need to show something to the client to let the client know the error happened on the server side. I agree!


Always load a gated URL polyfill when testing

Otherwise the tests fail to run in MS Edge, whose user agent doesn't trigger the inclusion of the polyfill without always on polyfill.io.
With this in we are down from 45 failing tests in MS Edge to 1 remaining failure.
See also #5996
Please review.

Travis restarted…

Looks good @marcjansen.
Where did you find information on having to always load this for Edge?  I wonder if there are plans to address this upstream (in polyfill.io).

@tschaub I got it straight from their API, doesn't look like they will remove it in the v2-series.

I've asked the question upstream: https://github.com/Financial-Times/polyfill-service/issues/941


Remove references to and update examples using Filecoin

Now that Filecoin has been deprecated, the remainder of the Web3Signer docs need updating to reflect this.  If needed, the previous content can be accessed via the docs repo on GitHub.

Done.


Abstract claw_verify

The claw_verify crate is currently a binary, meaning it can only be tested with integration tests. (Hence the tests/ folder.) This is a proposal that the logic be abstracted into a library. A binary will then use that library, so the same functionality is exposed.
Library interface
The claw_verify crate would export both schema and definition strings, as well as some form of the Sb3Resolver.
It would also export a two functions, whose signatures would look like this:
// Added for readability
type VerifyResult = Result<(), Vec<ValidationError>>;

pub fn verify_string(script: &str) -> VerifyResult;
pub fn verify_value(script: serde_json::Value) -> VerifyResult;

Binary interface
The only thing that the binary will keep is load_file, some argument parsing, and error handling.

Closed with 4115817d4aeaca124681a96dc4aea1062676df4b


convert/gem: Update convert gem to reflect the state of ruby3.3

Melange Pull Request Template
Functional Changes

[X] This change can build all of Wolfi without errors (describe results in notes)

Notes:
These changes are just in the gem convert pieces and won't effect builds
convert/gem: Update convert gem to reflect the state of ruby3.3
Changes:

Update default ruby to 3.3
Remove keyring entries wolfictl lint rejects them

❯ wolfictl lint ruby3.2-diff-lcs.yaml
2024/11/19 09:51:17 INFO Package: ruby3.2-diff-lcs: [forbidden-repository-used]: forbidden repository https://packages.wolfi.dev/os is used (ERROR)
[forbidden-keyring-used]: forbidden keyring https://packages.wolfi.dev/os/wolfi-signing.rsa.pub is used (ERROR)

Remove README it causes build to fial
Remove patch people will notice when it fails and the sed in pipelines/ruby/build should account for it
Truncate dscription becuase it breaks index generation

2024/11/19 10:01:40 ERRO failed to build package: unable to generate index: updating index: failed to parse package packages/aarch64/ruby3.2-diff-lcs-1.5.1-r0.apk: ini.ShadowLoad(): key-value delimiter not found: McIlroy-Hunt longest common subsequence (LCS) algorithm. It includes utilities

@smoser might be interested since they did the ruby3.3 stuff
@EyeCantCU also might be interested since IIC believe is also working on a PR for adding a ruby require test pipeline.

Current version:
# Generated from https://github.com/halostatue/diff-lcs
package:
  name: ruby3.2-diff-lcs
  version: 1.5.1
  epoch: 0
  description: |-
    Diff::LCS computes the difference between two Enumerable sequences using the
    McIlroy-Hunt longest common subsequence (LCS) algorithm. It includes utilities
    to create a simple HTML diff output format and a standard diff-like tool.

    This is release 1.4.3, providing a simple extension that allows for
    Diff::LCS::Change objects to be treated implicitly as arrays and fixes a
    number of formatting issues.

    Ruby versions below 2.5 are soft-deprecated, which means that older versions
    are no longer part of the CI test suite. If any changes have been introduced
    that break those versions, bug reports and patches will be accepted, but it
    will be up to the reporter to verify any fixes prior to release. The next
    major release will completely break compatibility.
  copyright:
    - license: MIT
    - license: Artistic-2.0
    - license: GPL-2.0-or-later
environment:
  contents:
    build_repositories:
      - https://packages.wolfi.dev/os
    keyring:
      - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
    packages:
      - build-base
      - busybox
      - ca-certificates-bundle
      - git
      - ruby-3.2
      - ruby-3.2-dev
pipeline:
  - uses: fetch
    with:
      README: 'CONFIRM WITH: curl -L https://github.com/halostatue/diff-lcs/archive/refs/tags/v1.5.1.tar.gz | sha256sum'
      expected-sha256: 50c1e43e1cae4bf65c139d628688cd80a29fe6c33bda4a66a98e98d3c8c601c2
      uri: https://github.com/halostatue/diff-lcs/archive/refs/tags/v${{package.version}}.tar.gz
  - uses: patch
    with:
      README: This is only required if the gemspec is using a signing key
      patches: patches/${{package.name}}.patch
  - uses: ruby/build
    with:
      gem: ${{vars.gem}}
  - uses: ruby/install
    with:
      gem: ${{vars.gem}}
      version: ${{package.version}}
  - uses: ruby/clean
vars:
  gem: diff-lcs

New Version:
# Generated from https://github.com/halostatue/diff-lcs
package:
  name: ruby3.3-diff-lcs
  version: 1.5.1
  epoch: 0
  description: Diff::LCS computes the difference between two Enumerable sequences using the
  copyright:
    - license: MIT
    - license: Artistic-2.0
    - license: GPL-2.0-or-later
environment:
  contents:
    packages:
      - build-base
      - busybox
      - ca-certificates-bundle
      - git
      - ruby-${{rubyMM}}
      - ruby-${{rubyMM}}-dev
pipeline:
  - uses: fetch
    with:
      expected-sha256: 50c1e43e1cae4bf65c139d628688cd80a29fe6c33bda4a66a98e98d3c8c601c2
      uri: https://github.com/halostatue/diff-lcs/archive/refs/tags/v${{package.version}}.tar.gz
  - uses: ruby/build
    with:
      gem: ${{vars.gem}}
  - uses: ruby/install
    with:
      gem: ${{vars.gem}}
      version: ${{package.version}}
  - uses: ruby/clean
vars:
  gem: diff-lcs
var-transforms:
  - from: ${{package.name}}
    match: ^ruby(\d.\d+)-.
    replace: $1
    to: rubyMM

Diff:
3c3
<   name: ruby3.2-diff-lcs
---
>   name: ruby3.3-diff-lcs
6,19c6
<   description: |-
<     Diff::LCS computes the difference between two Enumerable sequences using the
<     McIlroy-Hunt longest common subsequence (LCS) algorithm. It includes utilities
<     to create a simple HTML diff output format and a standard diff-like tool.
<
<     This is release 1.4.3, providing a simple extension that allows for
<     Diff::LCS::Change objects to be treated implicitly as arrays and fixes a
<     number of formatting issues.
<
<     Ruby versions below 2.5 are soft-deprecated, which means that older versions
<     are no longer part of the CI test suite. If any changes have been introduced
<     that break those versions, bug reports and patches will be accepted, but it
<     will be up to the reporter to verify any fixes prior to release. The next
<     major release will completely break compatibility.
---
>   description: Diff::LCS computes the difference between two Enumerable sequences using the
26,29d12
<     build_repositories:
<       - https://packages.wolfi.dev/os
<     keyring:
<       - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
35,36c18,19
<       - ruby-3.2
<       - ruby-3.2-dev
---
>       - ruby-${{rubyMM}}
>       - ruby-${{rubyMM}}-dev
40d22
<       README: 'CONFIRM WITH: curl -L https://github.com/halostatue/diff-lcs/archive/refs/tags/v1.5.1.tar.gz | sha256sum'
43,46d24
<   - uses: patch
<     with:
<       README: This is only required if the gemspec is using a signing key
<       patches: patches/${{package.name}}.patch
56a35,39
> var-transforms:
>   - from: ${{package.name}}
>     match: ^ruby(\d.\d+)-.
>     replace: $1
>     to: rubyMM

what is the 'build-repositories' change?

i see. never mind.

did you actually truncate the description like it looks?
yeap, it's not pretty but I used:
Description: strings.Split(g.Info, "\n")[0]

Open to other suggestions but the multi line description seems to annoy whatever generates our index files.

I just put up https://github.com/wolfi-dev/os/pull/34680 which chooses the less fancy use of vars compared to var-transforms

Mmmm it's nice to only change the packages name but I'm using sed to adjust them anyway so might as well make keep it simple.


UI depends on @athenz/auth-core instead

@athenz/auth-core package is available on npm registry now. The UI should
depends on @athenz/auth-core package instead of the relative path. This is
one more change as a part of #250.
See also: https://github.com/yahoo/athenz/pull/250#issuecomment-332199611

👍


Collapsing a group changes the simple polymer number

I can create a peptide and select the middle three monomers to form a group.

If I then collapse the group, the peptide definition changes.

Both HELM definitions are correct, but should not change just because the group was collapsed.

The team agreed that this was acceptable and few users would be concerned.


Update shebang for all bash scripts to #!/usr/bin/env bash

…to better support user-compiled bash installs

Looks like it's been done.
$ grep -Rpi 'bash' * 2>/dev/null
api/bash/repo-list-export.sh:#!/usr/bin/env bash
pre-receive-hooks/always_reject.sh:#!/usr/bin/env bash
pre-receive-hooks/block_file_extensions.sh:#!/usr/bin/env bash
pre-receive-hooks/block_unsigned_commits.sh:#!/usr/bin/env bash


Clarify how server lifetime is handled

Alternatively, it would help to clarify that it's out of scope and link to how current clients do it. Although it seems that it's somewhat in scope, given that shutdown and exit are implemented commands.
Especially: who is responsible for starting a language server (per user? per project? per workspace?)

Makes perfect sense to clarify.

Added
Server lifetime
The current protocol specification defines that the lifetime of a server is managed by the client (e.g. a tool like VS Code or Emacs). It is up to the client to decide when to start (process vise) and when to shutdown a server.


Distribution name with deploygate action

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context

I want to use distribution_name option on deploygate action,
but current action doesn't have it.
API reference here: https://docs.deploygate.com/reference#upload
Description

Refer to the addition of distribution_key (#3840), I added distribution_name.

I signed it!


[Bug]: Failed to Load  8-bit Quantized Model

Your current environment

The output of `python collect_env.py`
Collecting environment information...
WARNING 10-19 11:34:15 cuda.py:22] You are using a deprecated `pynvml` package. Please install `nvidia-ml-py` instead, and make sure to uninstall `pynvml`. When both of them are installed, `pynvml` will take precedence and cause errors. See https://pypi.org/project/pynvml for more information.
PyTorch version: 2.4.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.14 (main, May  6 2024, 19:42:50) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-105-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 12.3.52
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA RTX A5000
GPU 1: NVIDIA RTX A5000
GPU 2: NVIDIA RTX A5000

Nvidia driver version: 545.29.06
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_engines_precompiled.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_engines_runtime_compiled.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_graph.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_heuristic.so.9.2.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops.so.9.2.0
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn.so.8.0.4
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_adv_train.so.8
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8
/usr/local/cuda-11.1/targets/x86_64-linux/lib/libcudnn_ops_train.so.8
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      46 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             104
On-line CPU(s) list:                0-103
Vendor ID:                          GenuineIntel
Model name:                         Intel(R) Xeon(R) Gold 6230R CPU @ 2.10GHz
CPU family:                         6
Model:                              85
Thread(s) per core:                 2
Core(s) per socket:                 26
Socket(s):                          2
Stepping:                           7
CPU max MHz:                        4000.0000
CPU min MHz:                        1000.0000
BogoMIPS:                           4200.00
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities
Virtualization:                     VT-x
L1d cache:                          1.6 MiB (52 instances)
L1i cache:                          1.6 MiB (52 instances)
L2 cache:                           52 MiB (52 instances)
L3 cache:                           71.5 MiB (2 instances)
NUMA node(s):                       2
NUMA node0 CPU(s):                  0-25,52-77
NUMA node1 CPU(s):                  26-51,78-103
Vulnerability Gather data sampling: Mitigation; Microcode
Vulnerability Itlb multihit:        KVM: Mitigation: VMX disabled
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Retbleed:             Mitigation; Enhanced IBRS
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Mitigation; TSX disabled

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] nvidia-cublas-cu12==<IP_ADDRESS>
[pip3] nvidia-cuda-cupti-cu12==12.1.105
[pip3] nvidia-cuda-nvrtc-cu12==12.1.105
[pip3] nvidia-cuda-runtime-cu12==12.1.105
[pip3] nvidia-cudnn-cu12==<IP_ADDRESS>
[pip3] nvidia-cufft-cu12==<IP_ADDRESS>
[pip3] nvidia-curand-cu12==<IP_ADDRESS>
[pip3] nvidia-cusolver-cu12==<IP_ADDRESS>
[pip3] nvidia-cusparse-cu12==<IP_ADDRESS>
[pip3] nvidia-ml-py==12.560.30
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] nvidia-nvjitlink-cu12==12.6.68
[pip3] nvidia-nvtx-cu12==12.1.105
[pip3] pynvml==11.5.3
[pip3] pyzmq==26.2.0
[pip3] torch==2.4.0
[pip3] torchvision==0.19.0
[pip3] transformers==4.45.0
[pip3] triton==3.0.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-cublas-cu12        <IP_ADDRESS>                 pypi_0    pypi
[conda] nvidia-cuda-cupti-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-nvrtc-cu12    12.1.105                 pypi_0    pypi
[conda] nvidia-cuda-runtime-cu12  12.1.105                 pypi_0    pypi
[conda] nvidia-cudnn-cu12         <IP_ADDRESS>                 pypi_0    pypi
[conda] nvidia-cufft-cu12         <IP_ADDRESS>                pypi_0    pypi
[conda] nvidia-curand-cu12        <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-cusolver-cu12      <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-cusparse-cu12      <IP_ADDRESS>               pypi_0    pypi
[conda] nvidia-ml-py              12.560.30                pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] nvidia-nvjitlink-cu12     12.6.68                  pypi_0    pypi
[conda] nvidia-nvtx-cu12          12.1.105                 pypi_0    pypi
[conda] pynvml                    11.5.3                   pypi_0    pypi
[conda] pyzmq                     26.2.0                   pypi_0    pypi
[conda] torch                     2.4.0                    pypi_0    pypi
[conda] torchvision               0.19.0                   pypi_0    pypi
[conda] transformers              4.45.0                   pypi_0    pypi
[conda] triton                    3.0.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.6.1.dev238+ge2c6e0a82
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    GPU2    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      SYS     SYS     0-25,52-77      0               N/A
GPU1    SYS      X      SYS     0-25,52-77      0               N/A
GPU2    SYS     SYS      X      26-51,78-103    1               N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

Model Input Dumps
No response
🐛 Describe the bug
The code is
from datasets import load_dataset
from transformers import AutoTokenizer, AutoModelForCausalLM

from llmcompressor.modifiers.quantization import GPTQModifier
from llmcompressor.modifiers.smoothquant import SmoothQuantModifier
from llmcompressor.transformers import SparseAutoModelForCausalLM, oneshot

# Select model and load it.
MODEL_ID = "meta-llama/Meta-Llama-3.1-8B-Instruct"
model = SparseAutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    device_map="cuda:0",
    torch_dtype="auto",
)
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

# Select calibration dataset.
DATASET_ID = "/data2/liziniu/datasets/AIMO/NuminaMath-CoT"
DATASET_SPLIT = "train"

# Select number of samples. 512 samples is a good place to start.
# Increasing the number of samples can improve accuracy.
NUM_CALIBRATION_SAMPLES = 1024
MAX_SEQUENCE_LENGTH = 4096

# Load dataset and preprocess.
ds = load_dataset(DATASET_ID, split=DATASET_SPLIT)
ds = ds.shuffle(seed=42).select(range(NUM_CALIBRATION_SAMPLES))

def preprocess(example):
    return {
        "text": tokenizer.apply_chat_template(
            example["messages"],
            tokenize=False,
        )
    }

ds = ds.map(preprocess)

# Tokenize inputs.
def tokenize(sample):
    return tokenizer(
        sample["text"],
        padding=False,
        max_length=MAX_SEQUENCE_LENGTH,
        truncation=True,
        add_special_tokens=False,
    )

ds = ds.map(tokenize, remove_columns=ds.column_names)

# Configure algorithms. In this case, we:
#   * apply SmoothQuant to make the activations easier to quantize
#   * quantize the weights to int8 with GPTQ (static per channel)
#   * quantize the activations to int8 (dynamic per token)
recipe = [
    SmoothQuantModifier(smoothing_strength=0.8),
    GPTQModifier(targets="Linear", scheme="W8A8", ignore=["lm_head"]),
]

# Apply algorithms.
oneshot(
    model=model,
    dataset=ds,
    recipe=recipe,
    max_seq_length=MAX_SEQUENCE_LENGTH,
    num_calibration_samples=NUM_CALIBRATION_SAMPLES,
)

# Confirm generations of the quantized model look sane.
print("\n\n")
print("========== SAMPLE GENERATION ==============")
input_ids = tokenizer("Hello my name is", return_tensors="pt").input_ids.to("cuda")
output = model.generate(input_ids, max_new_tokens=100)
print(tokenizer.decode(output[0]))
print("==========================================\n\n")

# Save to disk compressed.
SAVE_DIR = MODEL_ID.split("/")[1] + "-W8A8-Dynamic-Per-Token"
model.save_pretrained(SAVE_DIR, save_compressed=True)
tokenizer.save_pretrained(SAVE_DIR)

from vllm import LLM

model = LLM("Meta-Llama-3.1-8B-Instruct-W8A8-Dynamic-Per-Token")

The error is

[rank0]: Traceback (most recent call last):
[rank0]:   File "<stdin>", line 1, in <module>
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/entrypoints/llm.py", line 214, in __init__
[rank0]:     self.llm_engine = LLMEngine.from_engine_args(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 564, in from_engine_args
[rank0]:     engine = cls(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/engine/llm_engine.py", line 325, in __init__
[rank0]:     self.model_executor = executor_class(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/executor_base.py", line 47, in __init__
[rank0]:     self._init_executor()
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/executor/gpu_executor.py", line 40, in _init_executor
[rank0]:     self.driver_worker.load_model()
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/worker/worker.py", line 183, in load_model
[rank0]:     self.model_runner.load_model()
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/worker/model_runner.py", line 1016, in load_model
[rank0]:     self.model = get_model(model_config=self.model_config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/__init__.py", line 19, in get_model
[rank0]:     return loader.load_model(model_config=model_config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/loader.py", line 399, in load_model
[rank0]:     model = _initialize_model(model_config, self.load_config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/loader.py", line 176, in _initialize_model
[rank0]:     return build_model(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/model_loader/loader.py", line 161, in build_model
[rank0]:     return model_class(config=hf_config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 410, in __init__
[rank0]:     self.model = LlamaModel(config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 292, in __init__
[rank0]:     self.start_layer, self.end_layer, self.layers = make_layers(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/utils.py", line 282, in make_layers
[rank0]:     [PPMissingLayer() for _ in range(start_layer)] + [
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/utils.py", line 283, in <listcomp>
[rank0]:     maybe_offload_to_cpu(layer_fn(prefix=f"{prefix}.{idx}"))
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 294, in <lambda>
[rank0]:     lambda prefix: LlamaDecoderLayer(config=config,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 209, in __init__
[rank0]:     self.self_attn = LlamaAttention(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/models/llama.py", line 134, in __init__
[rank0]:     self.qkv_proj = QKVParallelLinear(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/linear.py", line 683, in __init__
[rank0]:     super().__init__(input_size=input_size,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/linear.py", line 284, in __init__
[rank0]:     super().__init__(input_size, output_size, skip_bias_add, params_dtype,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/linear.py", line 172, in __init__
[rank0]:     self.quant_method = quant_config.get_quant_method(self,
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/quantization/compressed_tensors/compressed_tensors.py", line 70, in get_quant_method
[rank0]:     scheme = self.get_scheme(layer=layer, layer_name=prefix)
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/quantization/compressed_tensors/compressed_tensors.py", line 311, in get_scheme
[rank0]:     scheme = self._get_scheme_from_parts(
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/quantization/compressed_tensors/compressed_tensors.py", line 265, in _get_scheme_from_parts
[rank0]:     if self._is_static_tensor_w8a8(weight_quant, input_quant):
[rank0]:   File "/home/znli/anaconda3/envs/vllm/lib/python3.10/site-packages/vllm/model_executor/layers/quantization/compressed_tensors/compressed_tensors.py", line 135, in _is_static_tensor_w8a8
[rank0]:     is_8_bits = weight_quant.num_bits == input_quant.num_bits == 8
[rank0]: AttributeError: 'NoneType' object has no attribute 'num_bits'
>>>

Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

Getting the same error with a very similar compressing script, just a different model - "Qwen/Qwen2.5-Math-1.5B-Instruct"

cc @dsikka

Is llm-compressor and vllm installed in the same venv? Can you try running in separate venvs? I think we need a certain version of compressed-tensors installed on vllm. @dsikka can comment further

@gmonair Could you confirm what version of compressed-tensors you have installed?

@dsikka nice catch, my vllm env was using 0.6.0. I can confirm that vllm now loads the model just fine with pip install --upgrade compressed-tensors, which brings it to 0.7.1 (the same as the llmcompressor 0.2.0 env).
Thank you!

Thanks!

Can this be fixed in the vllm release too? Seems like trying to load a compressed model fails there too.

@cruzanstx you can pull in the changes from main or nightly. Otherwise, the fix should be in the next release.

@dsikka nice catch, my vllm env was using 0.6.0. I can confirm that vllm now loads the model just fine with pip install --upgrade compressed-tensors, which brings it to 0.7.1 (the same as the llmcompressor 0.2.0 env).
Thank you!

Need requantize model after update package?

@Arcmoon-Hu Nope.

@dsikka nice catch, my vllm env was using 0.6.0. I can confirm that vllm now loads the model just fine with pip install --upgrade compressed-tensors, which brings it to 0.7.1 (the same as the llmcompressor 0.2.0 env).
Thank you!

But it doesn't work for me. And it seems that vllm does not require compressed-tensors?

@dsikka nice catch, my vllm env was using 0.6.0. I can confirm that vllm now loads the model just fine with pip install --upgrade compressed-tensors, which brings it to 0.7.1 (the same as the llmcompressor 0.2.0 env).
Thank you!

But it doesn't work for me. And it seems that vllm(<=0.6.2) does not require compressed-tensors?

I personally had to upgrade vllm first then compressed-tensor to get it to work.

@piamo @cruzanstx yes, we made an update such that compressed-tensors is now used when running compressed-tensor models in vllm. I would update to the latest version of vLLM and compressed-tensors 0.7.1


Just editing a file

Product and Version [VS/VSCode]:
OS Version [macOS/Windows/Linux]:
Live Share Extension Version:
Target Platform or Language [e.g. Node.js]:
What were you doing when you encountered the desync?
How often have you encountered desyncs?

Hi @etothepii , thanks for reaching out. We are tracking this issue over at 3736. I am closing this as duplicate, but please add your comments and join the conversation over there!


Update node version to 18.0.0

Closes #4268
Your pull request should…

[x] have a concise title
[x] close an accompanying issue if one exists
[x] be against the correct branch
[x] include migration scripts and documentation, if appropriate
[ ] pass automated tests
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits

Hi, @gregorydlogan , I made the pr. Waiting for the testing stuff.. Thanks 😄😄

This doesn't work, has conflicts and seems kind of dead.
I'm going to close this.
If anyone is still working on this, please feel free to re-open this pull request.


db2 CHARACTER(16) garbled

data returned from db2 CHARACTER(16) is garbled

The question is what behavior is expected when rendering not-human-readable data in the Text or Grid tabs.  Right now DBeaver will render blob or character data as characters.  The request here is render character data as a hexadecimal string when appropriate.   Below I show how to reproduce with sqlite3 using a blob column.
I suspect that the table schema the reporter shows defines the char(16) column as CHAR(16) FOR BIT DATA, which gives the DB2 client the hint that the data should be rendered as hexadecimal strings.
@serge-rider: is there data type in DBeaver that will render data in hexadecimal instead as characters?  If so it could be that we need to do some JDBC work to determine if the column is "for bit data" and display appropriately.
Here is a DB2 repro case. Note that the "for bit data" changes something about the character interpretation so that "hexstr" and "nothexstr" are different.  "hexstr" matches what we see in the output above and from sqlite.
-- DB2 z/OS v12
CREATE TABLE hextest (
	hexstr char(16) for bit data not null,
	nothexstr char(16) not null
);
INSERT INTO hextest values(X'0000CF5E6ACF5E6ACF5E6ACF5E6A0000',
	X'0000CF5E6ACF5E6ACF5E6ACF5E6A0000');
SELECT * FROM hextest;

Here is a sqlite repro case:
drop table blobdata;

create table blobdata (
	testblob blob not null
);

insert into blobdata values(X'CF5E6ACF5E6ACF5E6ACF5E6A');
insert into blobdata values(X'CF5E6ACF5E6ACF5E6ACF5E6A00000000');
select * from blobdata;

You can change binary data representation in the preferences:

We need to make this option more obvious, e.g. add it in the View/Format context menu of data viewer.


Get rid of EVP_MAX_KEY_LENGTH

Cipher key lengths are currently limited to EVP_MAX_KEY_LENGTH = 512bits (sufficient for all supported ciphers including xts keys).
However, engine modules may need larger keys to store key objects. E.g. wrapped aes keys:
The engines aes implementation can generate such key objects using the EVP_CIPHER_CTX_ctrl interface together with the EVP_CTRL_RAND_KEY control or the (currently undocumented) higher level EVP_CIPHER_CTX_rand_key interface (having the  EVP_CIPH_RAND_KEY flag set).
I propose to change buffers of EVP_MAX_KEY_LENGTH size to dynamically allocated buffers of size EVP_CIPHER_key_length(cipher).
I see EVP_MAX_KEY_LENGTH is part of this versions api such that it would be applications responsibility to either not depend on it or not use engines that generate larger keys. Future releases could get rid of EVP_MAX_KEY_LENGTH.
What do you think ?

I think there is some merit in getting rid of it. But it couldn't go completely until 1.2.0.

Just found a corresponding note in EVP_EncryptInit(3)'s BUG section:

EVP_MAX_KEY_LENGTH and EVP_MAX_IV_LENGTH only refer to the internal
ciphers with default key lengths. If custom ciphers exceed these values the
results are unpredictable.

In case you agree to change this for 1.2.0, i would provide a patch to have internal key buffers dynamically allocated. This wouldnt break the the 1.1.x api and id like to see it on master because im working on an engine which uses keys generated/wrapped by a HSM.
Second part would be to remove EVP_MAX_IV_LENGTH and update EVP_EncryptInit(3) for 1.2.0.

This isn't going to happen in the 1.1.1 timeframe. Pushing to post 1.1.1 milestone.

This one could become obsolete with the new provider model, because the work-around fitting a key-object into EVP_MAX_KEY_LENGTH bytes is not needed anymore, once key-objects/keygen becomes supported also for symmetric crypto, see https://github.com/openssl/openssl/issues/8719

Im closing this in favor of https://github.com/openssl/openssl/issues/10265 which is obviously the better way to do it (compared to allowing arbitrary long keys buffers to hide a key object within).


Unable to terminate driver instance

In the following example, I attempt to quit the driver before invoking the robot, but whether I use driver.close() or driver.quit() the driver instance remains active:
Feature: mixing driver and robot

Background:
    * configure driver = { type: 'chrome', showDriverLog: true }

Scenario: terminate driver before invoking robot
    * driver 'https://google.com'
    * input("input[name=q]", 'karate dsl')
    * submit().click("input[name=btnI]")
    * waitForUrl('https://github.com/intuit/karate')
    * print '>>>>>>>>>>>>>>>>>>>BEFORE CLOSE>>>>>>>>>>>>>>', driver
    * driver.quit()
    * print '>>>>>>>>>>>>>>>>>>>AFTER CLOSE>>>>>>>>>>>>>>', driver

    * robot { window: 'Calculator', fork: 'calc', highlight: true, highlightDuration: 500 }
    * click('Clear')
    * click('One')
    * click('Plus')
    * click('Two')
    * click('Equals')
    * match locate('#CalculatorResults').name == 'Display is 3'
    * screenshot()
    * click('Close Calculator')

And here's the output:
14:02:05.469 [main]  INFO  com.intuit.karate - [print] >>>>>>>>>>>>>>>>>>>BEFORE CLOSE>>>>>>>>>>>>>> com.intuit.karate.driver.chrome.Chrome@93b344
14:02:05.473 [main]  DEBUG c.intuit.karate.driver.DriverOptions - >> {"id":40,"method":"Target.closeTarget","params":{"targetId":"8ED79506743780FF676C52CDFFCCCE69"}}
14:02:05.474 [nioEventLoopGroup-2-1]  DEBUG c.intuit.karate.driver.DriverOptions - << {"id":40,"result":{"success":true}}
14:02:05.477 [nioEventLoopGroup-2-1]  DEBUG c.i.k.http.WebSocketClientHandler - websocket client disconnected
14:02:05.479 [main]  DEBUG com.intuit.karate.shell.Command - closing command: chrome_1618002117493
14:02:05.481 [main]  INFO  com.intuit.karate - [print] >>>>>>>>>>>>>>>>>>>AFTER CLOSE>>>>>>>>>>>>>> com.intuit.karate.driver.chrome.Chrome@93b344
14:02:05.704 [main]  DEBUG c.intuit.karate.robot.win.ComLibrary - loaded: UIAutomationClient, clsid: {944DE083-8FB8-45CF-BCB7-C477ACB2F897}, majorVersion: 1, minorVersion: 0
14:02:05.738 [chrome_1618002117493]  WARN  com.intuit.karate.shell.Command - exit code was non-zero: 1 - [C:\Program Files (x86)\Google\Chrome\Application\chrome.exe, --remote-debugging-port=9222, --no-first-run, --user-data-dir=C:\Users\<redacted>\source\repos\scratchpad\test\target\chrome_1618002117493, --disable-popup-blocking] working dir: target\chrome_1618002117493
14:02:07.073 [main]  DEBUG com.intuit.karate.robot.win.ComUtils - init: {FF48DBA4-60EF-4201-AA87-54103EEF594E}, interface id: {30CBE57D-D9D0-452A-AB13-7AC5AC4825EE}
14:02:07.122 [main]  DEBUG com.intuit.karate - screen dimensions: 0:0(1680:1050)
14:02:09.880 [main]  WARN  com.intuit.karate - failed to find window: Calculator
14:02:09.882 [1618002129881]  DEBUG com.intuit.karate - command: [calc], working dir: null
14:02:11.252 [1618002129881]  DEBUG com.intuit.karate.shell.Command - command complete, exit code: 0 - [calc]
14:02:13.527 [main]  WARN  com.intuit.karate - failed to find window: Calculator
14:02:13.528 [main]  DEBUG com.intuit.karate - find window - retry #1
14:02:22.487 [main]  DEBUG com.intuit.karate - attached to process window: 'Calculator' Window - [calc]
14:02:22.497 [main]  WARN  com.intuit.karate - 'driver' is active, use 'robot.' prefix for robot methods
14:02:22.501 [main]  DEBUG c.intuit.karate.driver.DriverOptions - >> {"id":41,"method":"Runtime.evaluate","params":{"expression":"document.querySelector(\"Clear\").click()","returnByValue":true}}
14:02:52.503 [main]  ERROR c.intuit.karate.driver.DriverOptions - << timed out after milliseconds: 30000 - [id: 41, method: Runtime.evaluate, params: {"expression":"document.querySelector(\"Clear\").click()","returnByValue":true}]
14:02:52.540 [main]  ERROR com.intuit.karate - driver-and-robot.feature:17
* click('Clear')
>>>> js failed:
01: click('Clear')
<<<<
org.graalvm.polyglot.PolyglotException: failed to get reply for: [id: 41, method: Runtime.evaluate, params: {"expression":"document.querySelector(\"Clear\").click()","returnByValue":true}]
- com.intuit.karate.driver.DevToolsDriver.sendAndWait(DevToolsDriver.java:152)
- com.intuit.karate.driver.DevToolsMessage.send(DevToolsMessage.java:216)
- com.intuit.karate.driver.DevToolsMessage.send(DevToolsMessage.java:212)
- com.intuit.karate.driver.DevToolsDriver.evalOnce(DevToolsDriver.java:252)
- com.intuit.karate.driver.DevToolsDriver.eval(DevToolsDriver.java:260)
- com.intuit.karate.driver.DevToolsDriver.eval(DevToolsDriver.java:256)
- com.intuit.karate.driver.DevToolsDriver.click(DevToolsDriver.java:477)

driver-and-robot.feature:17
14:02:52.542 [main]  DEBUG c.intuit.karate.driver.DriverOptions - >> {"id":42,"method":"Page.captureScreenshot"}
14:03:22.545 [main]  ERROR c.intuit.karate.driver.DriverOptions - << timed out after milliseconds: 30000 - [id: 42, method: Page.captureScreenshot]
14:03:22.546 [main]  ERROR com.intuit.karate - driver-and-robot.feature:17
* click('Clear')
scenario [run] failed
failed to get reply for: [id: 42, method: Page.captureScreenshot]
14:03:22.548 [main]  DEBUG com.intuit.karate - after scenario, current window: 'Calculator' Window
14:03:22.557 [main]  DEBUG com.intuit.karate - will attempt to close window for: Calculator
14:03:22.601 [main]  DEBUG com.intuit.karate.shell.Command - closing command:<PHONE_NUMBER>881
---------------------------------------------------------
feature: driver-and-robot.feature
scenarios:  1 | passed:  0 | failed:  1 | time: 25.1373
---------------------------------------------------------

Note the 14:02:22.497 [main]  WARN  com.intuit.karate - 'driver' is active, use 'robot.' prefix for robot methods line in the log.

@treboriwa I'll take some time to look at this. do consider going through the code and submitting a PR

@treboriwa so I realized that there's no problem other than you can't use the "short cut" notation any more. anyway, I've fixed this but haven't tested - so please follow the developer guide and let us know: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
I don't know now if you expect the reverse to work and right now there's no way to "quit" a robot instance. I don't consider either of these cases super important - so please have a go at the code if needed. marking this as fixed

@ptrthomas thank you for looking into this and a quick turnaround! I'll take it for a spin soon and report back if I run into any issues. Regarding the "short cut" notation, I'm assuming you're referring to keywords used by both - driver and robot, like this one * click('Clear')? In the above example, once the driver is in fact terminated, the "short cut" notation should still work, since at that point, it'll only apply to robot, correct?
Noted about not being able to quit a robot instance at this point.

@treboriwa I mean that robot.this() and robot.that() will continue to work no matter what. we do a massive hack internally so that you can skip the robot. part when you don't mix a driver which is 99.9% of users.

Ha! OK, got it. Thanks again, @ptrthomas

I tested it with this fix applied and it works as expected. Thanks again for the quick turnaround @ptrthomas

1.1.0 released


Login fails for normal user i.e without  access to an adminstrator

I created two user account one with admin access and other with normal access(not admin).
After creating user sucessfully when i try to login using normal user it's showing me "User not allowed. Please contact your administrator". but when i login with admin user it's login sucessfully.
I am using portainer 1.14.0

If you go to Endpoints, click manage access in the bottom table and click the user you want authorised, they should be able to log in.
Let me know if this helped.

That is by design. Until a user has been allowes access to an endpoint, they cannot login.
Rgds,
Neil Cresswell
On 30/08/2017, at 3:08 AM, raushansingh629 <notifications<EMAIL_ADDRESS>wrote:
I created two user account one with admin access and other with normal access(not admin).
After creating user sucessfully when i try to login using normal user it's showing me "User not allowed. Please contact your administrator". but when i login with admin user it's login sucessfully.
I am using portainer 1.14.0
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_portainer_portainer_issues_1166&d=DQMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=sJ5PrLMOHeeLPJ_s5nO1TVUFsFzwun9Ql5mgvtZvrMA&s=fUjR1246fR1hyJoamrAcuFDOYbgZpmhTLpi7gzvOsbw&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AWGrlYQtYBM1s-5FzjjOghT0rB6WiNzhcgks5sdClhgaJpZM4PGGZl&d=DQMCaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=0fx0h4vB56iTLpw2McH1ZD6TqG_QGpbggVOB-PfMJpM&m=sJ5PrLMOHeeLPJ_s5nO1TVUFsFzwun9Ql5mgvtZvrMA&s=T_XhXhCsOI6UxqTgNfYcgfgVkbZd9ibHUQrjgrCtIck&e=.

it works by editing manage access.
thank you

@liamcottam Thanks a lot


torch.cuda.OutOfMemoryError happened in the mirror of opensora 1.1 on the cloud platform

Hi, guys
I have rented two a800 and chosen the mirror of opensora 1.1 on the cloud platform.
But when I try to run the command below:
python scripts/inference-long.py configs/opensora-v1-1/inference/sample.py
--num-frames 32 --image-size 832 1110 --loop 1 --condition-frame-length 8 --sample-name husky_2
--prompt 'a group of siberian husky dogs run out from a door to eat dog food and drink milk.'
I find it reports error like this:
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 49.11 GiB. GPU 0 has a total capacty of 79.32 GiB of which 30.63 GiB is free. Process 2924960 has 48.68 GiB memory in use. Of the allocated memory 47.91 GiB is allocated by PyTorch, and 263.60 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF
It seems like that only one GPU is detected. So how to fix this problem?
Thank you!

Stated in the README

我在本地推理也是这样，请问解决了吗？


transition-duration

First Thank You for such a nice flip-book to be able to selfhost. I am happy & pleased with it.
One little issue I like to resolve and got this partially working, but it is still not satisfactory.
The original transition-duration is 200ms (if I am correct here) and I find this very fast.
Looking through the files, I found so far 2 files which have the settings, one is /pdfjs/viewer.js between line 341 - 386 and /turnjs/zoom.min.js line 18
I change the 200ms to 2s but it is not correctly picked up, means, flipping through the book in one direction the NEW duration is not picked up, flipping backwards right after, the new duration is picked up somewhat.
Am I missing some entries somewhere ?
Any hints are very welcome.
Thank you

Dear
just change transaction duration from pdf-flip.js  line 86 and always use ms not seconds


Add prebuilts for optional deps

I have found a minor bug: When installed with the save flag, it will also save all optional deps.
This can still be merged and I will fix the bug in the package.


Add lndg

port 8888 conflicts with the notebook service.

Error on MacOS Docker Desktop Version 3.5.2 (<IP_ADDRESS>)

This should be fixed now!

Got it working on MacOS x86_64

Working on Arm64 MacOS as well...

Here is the change:
https://github.com/RandyMcMillan/plebnet-playground-docker/commit/00645b17e1bd455d5ac481d03a3b3c6ff6ee4095

Update the change: land only need read access:
https://github.com/RandyMcMillan/plebnet-playground-docker/commit/2ffef5fa7cb7bddbc6e7155d62d6decacfde95cc

The link in the change you proposed is not quite right as the site lives at /lndg inside the container but it allows the site to work because it just runs the db file internal to the container instead since there is no longer a path conflict.
Can you verify that you have git pull the last update that changed install.sh and properly initializes the file before running the containers?

I tested ./getcoins.py and the data was detected and displayed....

I could be missing something but...
commit 2ffef5fa7 is working...

Commit should work because the file is running inside the container now I believe. Do you see the db file locally at your ${oc.env:PWD}/volumes/lndg_datadir/db.sqlite3 path?

This is what it looks like...

Let me rebase and check again...

Commit ea9f3dc9a
After running getcoins.py the balance doesn't show up...

Commit ea9f3dc
After running getcoins.py the balance doesn't show up...

This is strange because balances are a direct call to lnd and not related to the db file.
I was able to spin up a new container and use getcoins.py to add funds and open a channel.

Confirm indg that commit ea9f3dc9a
Works on macOS x86_64 and Arn64

ignore comment  https://github.com/PLEBNET-PLAYGROUND/plebnet-playground-docker/pull/41#issuecomment-931814867

PS: @cryptosharks131 - I am going to retool make install and make install nocache=true so there is an option to restart the stack with persistent data using make.

tACK ea9f3dc9af1f89388f3c4b77f6f6d4ff9757abd9
👍🏽


Unable to send email notification without SMTP authentication

This issue is to test https://github.com/rancher/rancher/issues/20060 on v2.3

Tested with rancher/rancher:v2.3.0-alpha3 from May 30
Test:

Deploy rancher v2.3.0-alpha3 and add cluster
Add an email notifier without SMTP authentication
Add an alert

Result:
Alertmanager version is rancher/prom-alertmanager:v0.16.1
Unable to send email notifications.

Tested with rancher/rancher:v2.3.0-alpha3 from May 30
Test:

Freshly deployed rancher:v2.3.0-alpha3 and add cluster
Edit system-charts branch to dev
Add an email notifier without SMTP authentication
Create alerts at the cluster level and project level

Result:

Alertmanager version upgrade to rancher/prom-alertmanager:v0.17.0.
Can send alert email notifications


Fix checkout by tag in revision

The current checkout code does not work well with tags. If revision points to a tag that is not pointing to the latest commit, the old logic does the following:

Try to checkout by interpreting revision as a hash (which is not)
Then find the commit pointed by the tag
Move HEAD to that

This moves the HEAD to the correct commit but leaves the work directory checked out the "invalid" hash which becomes the master head state.
And this inconsistent state can cause even more weird behavior if the cache is not cleaned.
The new logic first determines if revision is a tag or not, and based on that does a proper checkout.

Released as 0.1.3.

Released as 0.1.3.


Improve testing and add code coverage

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@085a24f). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #2   +/-   ##
=======================================
  Coverage        ?   82.19%
=======================================
  Files           ?        6
  Lines           ?       73
  Branches        ?        0
=======================================
  Hits            ?       60
  Misses          ?       13
  Partials        ?        0

Continue to review full report at Codecov.

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


Link plugin

I'm creating this issue to mainly track the development of the Link plugin.
I see that on README it is stated that it's not currently working.  Can you @bergie give some pointers where to go if I'm going to fix it? Is it just buggy or missing half of the implementation?
Thanks.

the improved plugin is here: https://github.com/liip/LiipVieBundle/blob/iks/Resources/halloplugins/link.js
unfortunately, the people who improved the link plugin worked in the compiled js rather than the coffee source file...
there was a guy who started working on porting that back to coffee script and make it accept functions to handle backend communication, similar to the image plugin.
the guy porting it back could be https://twitter.com/#!/albertomusetti but i am not sure. @bergie, do you know who it was?


File resolution issue when path root is a symlink

Here's a weird one.
I have a symlink /jobs which resolves to /Volumes/work/jobs.
If my config's Search Paths reference paths that start with /jobs/..., OCIO isn't able to find anything; but if I use /Volumes/work/jobs/..., everything works fine.
This is on macos-11.3.

This is definitely a macOS-10.15+ issue.
Turns out, those aren't normal symlinks at the root -- they're firmlinks. Long story short, one can edit /etc/synthetic.conf to symlink stuff under /.  There's good info here.
Our issue is resolved with the above workaround (pointing to the resolved, fully-qualified path).
I have a note that this behavior may be a regression from OCIO-1, but I can't verify for myself at the moment.
(It fixes a config that worked with Nuke-11 but broke with Nuke-13.1; but I can't determine if this is an effect of also having upgraded from macOS-10.14 -- i.e., it's possible the config was never tested with Nuke-11 / macOS-10.15+.
Anyway. Noted for posterity.

Closing this as it is not clear that any action is needed in OCIO.


Typo in StatusInformationParser.cs SetCardTechnology

Currently for 0x00 the CardTechnology is parsed to "Magentic" stripe instead of  "Magnetic" stripe. This fixes the typo.

thank you for the fix


Sparrow wallet on Linux w. DWM not showing numeric text

I cannot get Sparrow wallet to show numeric text.
Alphabetic text shows, but has weird spacing.
I tried a few Java opts to address the usual culprits, but no luck so far.
$ Sparrow --version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel -Djdk.gtk.version=3
Sparrow Wallet 1.9.1

No errors in .sparrow/sparrow.log look relevant (only a few connection errors).
I also tried using wmname LG3D as I'm running DWM.
Any tips for what I should do to fix this?

Screenshot for reference:

I suggest trying to update/change your system font, which is getting picked up and used by Sparrow.

I suggest trying to update/change your system font, which is getting picked up and used by Sparrow.

Thanks for the hint! Got it sorted.
In case it helps someone else in future:
My ~/.config/fontconfig/fonts.conf looked a bit bloated with some font names I didn't recognize.
Replaced it with a more sparse one which I copied from this reddit comment. (Already had font-noto-* installed.)
Restarted Sparrow and all was well.


[Dependency] Bump Ben Manes Gradle Versions

Description
This bumps gradle versions to 0.46.0
Review checklist

[x] PR is split into meaningful commits for the ease of reviewing
[ ] Tests have been written
[ ] Screenshots added (where applicable)
[x] Appropriate labels have been applied

Codecov Report

Merging #96 (f242ed4) into main (3a5a390) will increase coverage by 74.9%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           main     #96      +/-   ##
=======================================
+ Coverage      0   74.9%   +74.9%
=======================================
  Files         0      45      +45
  Lines         0    1354    +1354
  Branches      0     400     +400
=======================================
+ Hits          0    1015    +1015
- Misses        0     125     +125
- Partials      0     214     +214


Support Struct datatype parsing for GenericDialect

Fix #1240

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

21 of 21 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 89.214%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
23622

Relevant Lines:
26478

💛  - Coveralls


Small clippy fixes

No issue attached to this PR, this fixes some clippy lints that were complaining on my machine

Sorry for the force push on this, accidentally pushed code I didn't intend to.

I think we should wait with this pr until clippy can run on nightly again.

I agree


Consider creating a template download question that includes the send to court code

This won't be heavily used except for Appeals Court forms. But we should consider automating this.
Suggest making a method that is flexible and can leave the download screen the same whether we do filing by email or e-filing with ECF

See: https://github.com/SuffolkLITLab/docassemble-AssemblyLine/issues/17

See: https://github.com/SuffolkLITLab/docassemble-AssemblyLine/issues/17

Still unclear how useful this will be w/ e-filing, but we should probably start to think about a standardize e-filing flow.

Closing for now. We want something equivalent for e-filing but it's not ready to make into an issue yet--the one for email filing is obsolete.


add favicons and webmanifest

closes #34
tested it on desktop in safari, chrome and firefox

Thank you @noahliechti for your PR!


[SCB-1142] Add acceptance-pack-cluster-spring-demo for alpah cluster

Copy module acceptance-park-spring-demo and make the following modifications
Modify pom.xml to add two alpha server docker nodes
Add alpha_shutdown.btm to pack_success_scenario.feature
Inject alpha-shutdown.btm into the postCarBooking method of Booking trigger stop alpha master node

Coverage decreased (-0.1%) to 89.362% when pulling 3bf777b6444338906cb95a9581796fc199ac129d on coolbeevip:SCB-1142 into c2c049b670ec743c300035f72bc14c8e27fe5190 on apache:master.

Got the iCLA confirmation.
<EMAIL_ADDRESS>


Return to previous version of format on save

After Visual Studio release 17.4 returning to the previous version of format on save will fix #1191 #1099 #1207

fix #1208


sam 2 install failed "libcudnn.so.9: cannot open shared object file: No such file or directory" but libcudnn.so.9 is installed

Hi,
this is a followup of issue #112 as I am not able to reopen the issue as not being a repo collaborator (see https://stackoverflow.com/questions/21333654/how-to-re-open-an-issue-in-github)
Did follow your advice. Some other libs were not found. tried the same fix :
 1004  export LD_LIBRARY_PATH=./venv/lib/python3.10/site-packages/nvidia/cudnn/lib:${LD_LIBRARY_PATH}
 1005  pip install -e .
 1006  find . -name libcupti.so.12
 1007  export LD_LIBRARY_PATH=./venv/lib/python3.10/site-packages/nvidia/cuda_cupti/lib:${LD_LIBRARY_PATH}
 1008  pip install -e .
 1009  find . -name libnccl.so.2
 1010  export LD_LIBRARY_PATH=./venv/lib/python3.10/site-packages/nvidia/nccl/lib/:${LD_LIBRARY_PATH}
 1011  find . -name libnccl.so.2
 1012  pip install -e .
 1013  sudo dnf install g++
 1014  pip install -e .
 1015  find . -iname python.h
 1016  cd ./venv/lib/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/
 1017  ln -sf python.h Python.h
 1018  cd -
 1019  pip install -e .

after that the install kept running until this error
   /usr/local/cuda-12.2/include/crt/host_config.h:136:2: error: #error -- unsupported GNU version! gcc versions later than 12 are not supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check; however, using an unsupported host compiler may cause compilation failure or incorrect run time execution. Use at your own risk.
        136 | #error -- unsupported GNU version! gcc versions later than 12 are not supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check; however, using an unsupported host compiler may cause compilation failure or incorrect run time execution. Use at your own risk.
            |  ^~~~~
      In file included from /tmp/pip-build-env-uyr1owwh/overlay/lib64/python3.10/site-packages/torch/include/torch/csrc/Device.h:4,
                       from /tmp/pip-build-env-uyr1owwh/overlay/lib64/python3.10/site-packages/torch/include/torch/csrc/api/include/torch/python.h:8,
                       from /tmp/pip-build-env-uyr1owwh/overlay/lib64/python3.10/site-packages/torch/include/torch/extension.h:9,
                       from sam2/csrc/connected_components.cu:12:
      /tmp/pip-build-env-uyr1owwh/overlay/lib64/python3.10/site-packages/torch/include/torch/csrc/python_headers.h:12:10: fatal error: Python.h: No such file or directory
         12 | #include <Python.h>
            |          ^~~~~~~~~~
      compilation terminated.

Seems to be the case that my gcc version gcc.x86_64                        13.3.1-1.fc39 is not supported. Sadly I cannot downgrade.
Installed Packages
gcc.x86_64                        13.3.1-1.fc39                         @updates
Available Packages
gcc.x86_64                        13.2.1-3.fc39                         fedora
gcc.x86_64                        13.3.1-1.fc39

any idea when / if gcc 13 will be supported so that I am able to run SAM 2 on Fedora?
Best Regards
Heiko

Hi @loeweh, you seem to have a gcc version incompatible with CUDA kernel building in your system.
For video applications, if the compiler version issue cannot be resolved, to get you unblocked, you may skip the SAM 2 kernel building step by

commenting out the line ext_modules=get_extensions(), in https://github.com/facebookresearch/segment-anything-2/blob/57bc94b7391e47e5968004a0698f8bf793a544d1/setup.py#L70`
replace the fill_holes_in_mask_scores function in the lines https://github.com/facebookresearch/segment-anything-2/blob/57bc94b7391e47e5968004a0698f8bf793a544d1/sam2/utils/misc.py#L216-L227
with a dummy one as follows

def fill_holes_in_mask_scores(mask, max_area):
    # do nothing here since we don't have a CUDA kernel for connected components
    return mask

This workaround disables the optional video post-processing step (small hole filling on GPUs) in SAM 2 and should unblock you for video applications (without the post-processing step using this CUDA kernel, it should still work in most cases).
However, the CUDA kernel above is also needed for automatic mask generation in static image applications of SAM 2. If your use case involves automatic mask generation, you would need to manually replace the get_connected_components function in the lines https://github.com/facebookresearch/segment-anything-2/blob/57bc94b7391e47e5968004a0698f8bf793a544d1/sam2/utils/misc.py#L47-L63 with e.g. an OpenCV implementation like cv2.connectedComponentsWithStats

Follow up: we have recently made the CUDA extension step optional (in https://github.com/facebookresearch/segment-anything-2/pull/155) as a workaround to this problem.
You can pull the latest code and reinstall via
# run the line below inside the SAM 2 repo
git pull;
pip uninstall -y SAM-2;
rm -f sam2/*.so;
pip install -e ".[demo]"

which allows using SAM 2 without CUDA extension (the results should stay the same in most cases, see INSTALL.md for details).


[terra-disclosure-manager] Update docs to use MDX syntax

Summary
Updated terra-disclosure-manager docs to use MDX syntax

@saket2403 These doc changes are updating these to mdx: https://github.com/cerner/terra-framework/pull/1015


Should we map ISC entities to adjectives too?

Why only map the ISC entities to the noun synsets? Why not also map them to the adjectives?
For example isc:Jurassic:
isc:Jurassic skos:relatedMatch wn30en:synset-noun.time-Jurassic .

but maybe we should also have a triple with synet-adj.pert-Jurassic as an object?

I have added mappings.  We need to follow up this with #24


Feature Request:

Analogous to how you would swap workspaces with Win-Ctrl-Arrow keys, holding down shift also takes the currently focused window to the new workspace. (I remember this from my old Ubuntu system)

Duplicate of #16?

Yeah you're right.


Remove AbortSignal event listeners when requests complete

Issue #1318, if available:
Description of changes:
Currently if an AbortSignal is re-used across multiple requests, more and more listeners will accumulate, leading to memory leaks. In order to mitigate this, we should remove any event listeners we add to the AbortSignal when the request completes.
Notes on the code changes

Should we be more defensive and check that removeEventListener is a function before using it?
I don't really like the code changes in the fetch-http-handler so if anyone has any suggestions, please do chime in. It's somewhat tricky because fetch doesn't provide an event-driven API (that I know of).

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

FYI: This commit broke JS SDK v3 in react-native environments.
Details in https://github.com/aws/aws-sdk-js-v3/issues/6269#issuecomment-2252850763
I'll post a fix discussed in comment https://github.com/aws/aws-sdk-js-v3/issues/6269#issuecomment-2252859253

I'll post a fix discussed in comment aws/aws-sdk-js-v3#6269 (comment)

Fix posted in https://github.com/smithy-lang/smithy-typescript/pull/1350


failed to update packages: Cargo.lock

Bug description
Hello, since pushing some new crates commits I've been getting the following error in CI, I've also tried running release-plz locally and also get the error, however I can't seem to fix it because I don't get a new Cargo.lock running cargo update or release-plz update so I don't know how to fix it.
https://github.com/librasn/rasn/actions/runs/11419906730/job/31775006033

Would you like to work on a fix? n

To Reproduce

Steps to reproduce the behavior:

git clone https://github.com/librasn/rasn
release-plz update

Expected behavior

release-plz provides the diff or works.

I'm busy for now. Maybe I can have a look next weekend

I tried to go back in versions with cargo install to see whether this was potentially introduced recently, but it seems like that some dependencies are not defined strictly enough and installation can fail for older versions:
cargo install --version 0.3.91 release-plz

would produce
   Compiling release_plz_core v0.26.2
error[E0063]: missing fields `output` and `render_always` in initializer of `ChangelogConfig`
   --> /Users/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/release_plz_core-0.26.2/src/changelog.rs:375:5
    |
375 |     ChangelogConfig {
    |     ^^^^^^^^^^^^^^^ missing `output` and `render_always`

For more information about this error, try `rustc --explain E0063`.
error: could not compile `release_plz_core` (lib) due to 1 previous error
error: failed to compile `release-plz v0.3.91`, intermediate artifacts can be found at `/tmp/cargobuilds`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.

Commit 99c4f6f9fb78316efd1e387945c1dc971d544966 seems to introduce this issue at least on my machine.

For the installation, you could try adding the --locked flag:
cargo install --version 0.3.91 release-plz --locked

Commit 99c4f6f seems to introduce this issue at least on my machine.

That's very helpful, thanks!
Can you create a small repo to reproduce the error?

For the installation, you could try adding the --locked flag:
cargo install --version 0.3.91 release-plz --locked

Commit 99c4f6f seems to introduce this issue at least on my machine.

That's very helpful, thanks!
Can you create a small repo to reproduce the error or is it too complex?

Ah that helps. So  cargo install --version 0.3.94 release-plz --locked will also introduce the issue (includes the above commit) and cargo install --version 0.3.93 release-plz --locked works. I made a branch with smaller set of changes in my fork of rasn, which introduces the issue: https://github.com/Nicceboy/rasn/tree/release-plz-sample However, I am afraid I cannot spend more time for this right now.

I can't reproduce this issue anymore unfortunately/fortunately :/

I merged #1803
I'll release the new version of the gh action.
If you still experience the same error, please open a new issue or re-open this one 👍

Thank you! It is very odd, I could not reproduce this problem either anymore, with identical process as previously.

github action released 👍

I can't reproduce this issue anymore unfortunately/fortunately :/

If I had a theory, I'd reckon it requires an unreleased crate to be replicated, because that is the only change between me filing and then you attempting.


Fix AWS Client Creation and Credentials Secret

Description
This pr fixes two bugs interacting with EKS clusters:

client creation
AWS credentials secret

How Has This Been Tested?

[x] On EKS cluster peering

/rebase


Aliases improvements

This PR contains some improvements over Aliases functionality, addressing previous UX issues found in QA.

Closing as outdated


Telegram Message to chatID

Is it possible to send the notification to a Telegram group (chatID) in a future version?
Perhaps a Telegram custom config would be possible, where you can enter your own groups with the chatID's, similar to how you already do, e.g. at 'custom type config', only for Telegram.
Best regards
Werner

Version 2.x

Group chatIDs are not in the Telegram adapter. Manual input would be nice
Orlando

Problem is, there is only an authenticated user-entry in the telegram adapter, if you identificate yourself with chatbot in private-message via telegram. If you invite your chatbot in a group, there is no option, to interact with the bot in group for security reasons and get an datapoint in iobroker as authenticated user with group-id.
Because of this security reason, you can give the Chat-ID from group in blockly. To get the Chatgroup-ID you have to open telegram in webbrowser, open the group and get the ID from URL ;-)

Blockly:

As you see the "-" at the beginning of the group-id is important for this feature!


[1.3.x] KOGITO-4444 - cherry pick grafana dashboard regex sanitizer

Cherry pick regex of https://github.com/kiegroup/kogito-cloud-operator/pull/762
Many thanks for submitting your Pull Request :heart:!
Please make sure your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains a link to the JIRA issue
[x] Pull Request contains a description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[x] You've tested the new feature/bug fix in an actual OpenShift cluster
[x] You've added a RELEASE_NOTES.md entry regarding this change

@spolti @ricardozanini can we merge this one so that we have it in 1.3?

@r00ta could you please add a RELEASE NOTES input for this one? A new PR is fine in this branch, don't need to push to master since the feature will be fixed on 1.3.0


Refactor out a HasChildrenAst

... for ElementAst, EmbeddedTemplateAst, and ContainerAst.

There is a lot of code that relies on seeing that .childNodes.isEmpty for non-child stuff.


New Port: Broken pipes

New Port: Broken Pipes
Broken Pipes is a game created during and for the GMTK Game Jam 2020. The jam's theme is out-of-control, so this game is a platformer where the flow of water is out-of-control and the water level increases and decreases constantly.
Download the game from https://cocawsugar-gj2020.itch.io/broken-pipes and extract the data.win file into the game folder
Controls
| Button | Action |
|A|Jump|
|B|Back to menu|
|X|Jump|
|Y|Jump|
|Select|Back to menu|
The game for some reason ignores any bindings for B button, so it is what it is.
CFW Tests
[x] AmberELEC
[x] ArkOS
[x] JELOS / ROCKNIX
[x] muOS
Architecture
[X] aarch64
[] Panfrost (Mainline)
Resolution Tests
Test all major resolutions:
[x] 480x320 (Optional)
[x] 640x480
[x] 720x720 (RGB30)
[x] Higher resolutions (e.g., 1280x720

Gotta stop now, you said only one ^^


Publish the final released zip files to Maven Central also

As discussed here https://lists.apache.org/thread/14xzmfgh6qn8qmlw8fdfbwszpox8gnv0
the desired change is also publish the artifacts to maven central in addition to the currently used Github releases page and the Apache download servers.
The normal maven ends up here
https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.9/apache-maven-3.9.9-bin.zip
I propose to put the mvnd in a similar location with the intent of making it easily findable to others.
https://repo.maven.apache.org/maven2/org/apache/maven/apache-mvnd/1.0.2/...

Sure, could you write a script that does that ?

Maven Central requires artefacts to be signed. Question if it's allowed by ASF policy, to store pgp keys used to sign outside of your own release manager workstation?

Perhaps a semi automated process?
First release it all the current way and then have a separate script that fetches, signs and publishes the artifacts from the developer machine?

The files I see here are already signed https://downloads.apache.org/maven/mvnd/1.0.2/
How do they get there? Where are they signed?

Using the script build/release-candidate.sh which should be run on the release manager laptop.

Maven Central requires artefacts to be signed. Question if it's allowed by ASF policy, to store pgp keys used to sign outside of your own release manager workstation?

I think using GitHub secrets could work.  I managed to fully automate the JLine release process on GitHub, but it does have the ASF voting mechanism.   But if we could semi automate releases for any ASF project , that would be nice.

same issue #707

The files I see here are already signed https://downloads.apache.org/maven/mvnd/1.0.2/
How do they get there? Where are they signed?

Using the script build/release-candidate.sh which should be run on the release manager laptop.

The release process is documented at https://github.com/apache/maven-mvnd/blob/master/RELEASING.adoc
I'm open to any change, as long as it can be scripted.

https://infra.apache.org/release-distribution.html#sigs-and-sums
Looks like, the only limitation is to not store keys on ASF infra.
I haven't found requirements to use the key assigned to the person (but must be in KEYS), and infra recommends to have an automated sign.

The release process is documented at https://github.com/apache/maven-mvnd/blob/master/RELEASING.adoc
I'm open to any change, as long as it can be scripted.

Looking at the scripting I see right now, how about this:

A new script build/publish-on-mavencentral.sh is added and which is called from build/release-publish.sh
This new script simply downloads all published files (including all the signature files and file hashes) from https://downloads.apache.org/maven/mvnd/${VERSION}
And then simply run the maven deploy plugin on each file to publish them as-is to maven central.

Would that work?

The release process is documented at https://github.com/apache/maven-mvnd/blob/master/RELEASING.adoc
I'm open to any change, as long as it can be scripted.

Looking at the scripting I see right now, how about this:

A new script build/publish-on-mavencentral.sh is added and which is called from build/release-publish.sh
This new script simply downloads all published files (including all the signature files and file hashes) from https://downloads.apache.org/maven/mvnd/${VERSION}
And then simply run the maven deploy plugin on each file to publish them as-is to maven central.

Would that work?

I think it would be better if the files would be published to http://repository.apache.org so that they can be linked during the vote.  So maybe rather call it from release-candidate.sh, which would even be easier given we already have all the files available at that time.  So upload all the files to the ASF nexus.  Ideally, the script would close the repo, and  the release-publish.sh would publish the repository to central.  I'm not sure how those last two steps can be done.  @cstamas may know...

i will just leave this here, as we need multiple aspects from it (different binaries built on different runners, etc):
https://gist.github.com/cstamas/69e6365bbb70521923020d68369bf8e5